在生产环境中运行 AI Agent 的心得体会

我构建 AI 系统。我与负责交付代码的工程师交流。在华丽的 Demo 与真实的生产系统之间，存在着巨大的鸿沟。

现在人们把一切都称为 Agent。带循环的脚本是 Agent，带记忆的聊天机器人也是 Agent。这种误解会导致糟糕的工程实践。

团队往往会对简单的任务进行过度设计。他们为只需要一个优质 Prompt 的工作流添加了复杂的编排。

一个 Agent 必须有一个目标，而不仅仅是一条指令。它必须能够决定下一步做什么，必须能够处理失败，并且必须知道何时结束。

其余的一切都只是函数调用。

• 如果每一步都需要人类引导，那它只是一个聊天界面。 • 如果系统能从失败的工具调用中恢复，那它是一个 Agent。 • 如果系统能将目标分解为子任务，那它才是真正的 Agent。

真正的 Agent 部署通常是垂直领域的。它们擅长做一件事，比如文档提取或代码审查，而不是通用的推理引擎。

成功的团队专注于以下三点：

• 工具设计：为 Agent 调用的功能提供简洁的接口。
• 错误处理：当工具返回空结果时该如何应对。
• 可观测性：追踪 Agent 做出特定决策的原因。

像 LangChain 或 CrewAI 这样的框架每月都在变化。相比框架，模式（patterns）更为重要。

使用这些模式来取得成功：

• 先规划后执行：使用一个步骤进行规划，使用另一个独立的步骤进行执行。
• 将检索与推理分离：获取上下文和使用上下文是两项不同的任务。
• 明确的任务移交：当一个 Agent 将工作传递给另一个 Agent 时，使用结构化日志。

RAG 已成为标准，但大多数人在分块（chunking）上栽了跟头。如果你文本切分得不好，模型就会丢失上下文。如果你的 RAG 结果毫无用处，在责怪模型之前，先检查你的元数据和分块策略。

模型会变得越来越好、越来越便宜。但这并不会改变核心的工程挑战。你必须构建出在无人监管时也能正确运行的系统。

专注于治理和可观测性。真正重要的工程师是那些能够构建出让别人信任的系统的人。这是系统设计，而不是模型研究。

Source: https://dev.to/aibughunter/what-i-learned-after-running-ai-agents-in-production-for-a-year-49n