我用于构建生产级 AI Agent 的完整技术栈

Demo 展示的是一回事，生产系统展示的是另一回事。两者之间存在着许多人忽略的差距。

现在人们把一切都称为 Agent。一个带有记忆的聊天机器人是 Agent，一个带有循环的脚本也是 Agent。这种错误会导致糟糕的工程实践。你最终会发现自己对简单任务过度设计，而对复杂任务设计不足。

一个 Agent 必须有一个目标。它不应仅仅是遵循指令。真正的 Agent 会决定下一步该做什么。它能处理失败，并知道工作何时完成。

根据以下规则检查你的系统：

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

成功的团队不会构建通用的推理引擎。他们构建的是针对特定用途的窄领域流水线。他们专注于三件事：

  • 工具设计：为 Agent 创建简洁的调用接口。
  • 错误处理：决定当工具返回空结果时该怎么办。
  • 可观测性：追踪 Agent 为何做出特定决策。

像 LangChain 或 CrewAI 这样的框架每月都在变化。框架的重要性不如模式（patterns）重要。利用这些模式来取得成功：

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

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

挑战不在于追求基准测试（benchmarks）。挑战在于构建即使在你不在场时也能让你信任其运行的系统。专注于治理、可观测性和可靠的工具使用。

最优秀的工程师会专注于系统设计，而不仅仅是提示词工程（prompt engineering）。构建其他人可以维护的系统。

来源：https://dev.to/aibughunter/the-exact-stack-i-use-to-build-production-ai-agents-no-fluff-2lmp