生产就绪的 AI 智能体：从重构单体架构中汲取的 5 个教训

📌 One-Sentence Summary

本文详细介绍了将一个脆弱的 AI 智能体原型重构为生产就绪系统的五个关键工程教训，涵盖编排、结构化输出、动态 RAG、可观测性和使用 Google Agent Development Kit 的成本控制。

📝 Summary

本文介绍了来自 Google AI Agent Clinic 的一个案例研究，其中将一个名为 'Titanium' 的脆弱销售研究智能体重构为生产就绪系统。原始的 Python 单体脚本运行缓慢，容易出现静默故障，并且受限于硬编码数据。重构过程得出了五个关键教训：1) 使用像 Google Agent Development Kit 这样的框架，用编排的子智能体取代单体架构，以提高可靠性和关注点分离。2) 使用 Pydantic 模型强制执行结构化输出，而不是脆弱的基于提示词的 JSON 解析。3) 将硬编码的上下文替换为具有自主数据摄取和混合向量搜索的动态 RAG 管道。4) 使用 OpenTelemetry 实现不可妥协的可观测性，用于追踪和调试。5) 利用框架内置的重试逻辑和熔断器来控制成本。文章强调，从原型到生产的转变需要从关注功能转向确保健壮性、可扩展性和操作可见性。

💡 Main Points

1. 对于生产可靠性而言，编排的子智能体优于单体脚本。 使用像 ADK 这样的框架将复杂任务分解为由专业智能体（研究员、规划器等）组成的管道，可以防止单点故障，并且与单一、庞大的 LLM 提示相比，更容易调试和扩展。
2. 通过 Pydantic 实现的结构化输出对于数据完整性和可维护性至关重要。 注入 Pydantic 模型作为模式定义，而不是在提示词中描述 JSON 格式，可以保证结构完整性，减少令牌浪费，并消除脆弱的自定义解析逻辑。
3. 具有自主数据摄取功能的动态 RAG 管道是实现智能体可扩展性的关键。 用一个能够自主抓取、索引（例如使用 Google Cloud Vector Search）并执行混合搜索的系统来取代硬编码的上下文，使得智能体能够扩展其知识，而无需手动更新代码。
4. 使用 OpenTelemetry 实现全面的可观测性对于生产 AI 智能体是不可妥协的。 对模型调用、工具执行和令牌使用进行分布式追踪，对于从 '黑盒' 故障模式转变为能够诊断复杂智能体工作流中的延迟问题、成本驱动因素和确切故障点至关重要。
5. 成本优化必须通过框架管理的重试和熔断器内置到架构中。 依赖编排框架原生的指数退避、超时和重试逻辑，可以防止因无限循环或持续错误导致的令牌消耗失控，这是一个主要的操作风险。

💬 Key Quotes

• 构建一个在本地机器上运行良好的 AI 智能体很容易。构建一个能在现实中存活——处理速率限制、避免无限循环、超越硬编码数据进行扩展——的智能体则完全是另一回事。
• 教训：关注点分离。执行狭窄任务的专用智能体比试图执行庞大、多步骤提示的单一 LLM 运行得更可靠。
• 通过将 '契约' 从模糊的自然语言请求转变为经过运行时验证的 Python 对象，我们保证了结构完整性，并消除了脆弱的自定义解析。
• 硬编码对于原型来说没问题，但生产管道需要自我更新。真正的智能体价值来自于赋予智能体通过向量搜索自主获取、扩展和查询的工具。
• 没有实时诊断，你就无法将智能体投入生产。你需要 OpenTelemetry 追踪来解决事实争议并调试单个组件的延迟。

📊 Article Meta

Read Full Article