你的第一个 AI Agent 应该“笨拙”地做成一件事

我们最高效的 Agent 系统，起初都极其简单。更少的 Agent，更聚焦的任务，并且运行起来甚至有点“笨拙”😂。

这背后是有原因的，这也突显了传统软件开发生命周期与 Agent 系统开发生命周期之间的关键差异。

事实证明，通过迭代方式构建 Agent 系统效果要好得多。爬、走、跑。那些理解并完全拥抱这一点的团队，如今已经将其投入生产，而其他人还在苦苦打磨演示版本。

POC（概念验证）的坟场

这是一种常见的情况：一个由资深工程师组成的团队决定构建一个 Agent。他们精通多 Agent 协作、思维链推理、工具编排、提示工程以及所有相关技术。

他们从一开始就设计出了他们认为完美的系统，从一开始就规划好所有 Agent。例如：研究员 Agent 为规划员 Agent 提供输入，规划员与执行者 Agent 协调，并由质量检查员验证结果。架构文档齐全，配有详细的图表、复杂的交接流程和各种异常处理机制。

三个月后，项目仍卡在开发阶段。文档写得漂亮，但生产流量为零（因此 ROI 也是 0 🤷）。

我不认为问题在于野心，而是因为他们正试图为一个自己尚未完全理解的系统进行优化。

使这些系统变得极其强大的核心能力——编排智能并将其指向复杂问题的能力——也是它区别于我们过去构建的其他系统的原因。这意味着在构建方式上，它在某种程度上是截然不同的。

在高风险领域从简单做起

一家医疗人事公司带着一个关于资质认证的有趣用例找到了我们，这已成为他们的主要瓶颈。每当他们引入一名新医生时，必须核实执照、查询医疗委员会、检查制裁清单并验证身份。这个涉及多个数据源的手动过程通常需要几天才能完成。最重要的是，在医疗人事领域，清理医生资格的延误可能导致收入损失之外的严重后果。

他们没有从自动化整个入职流程入手，而是只挑了一件事：背景调查工作流。

最初的版本非常直接：收集供应商数据、查询相关来源、将输出结构化为 JSON、基于数据做出决策，并将结果推送到 Snowflake。并没有解决每一个边缘情况。

他们本可以花费数月时间预判各种场景，但最终只用了几周就交付了解决方案。经过实战检验后，他们现在可以实现许多其他质量杠杆，以平衡负载、纳入人工审核并运行并行工作流。所有这些都是从真实的执行中学习，而不是通过漫长的规划会议得到的。

现在，他们已经实现了针对幻觉检测的护栏、合规审计追踪，并且将原本需要几天完成的流程缩短至几小时。第二个用例已经在开发中了。

如果他们从一开始就实现所有的制衡机制，他们可能会错过许多优化实际用例和架构的机会，这就像在传统应用解决性能问题之前先加入缓存一样。

如果我是今天开始做，我会怎么做

缩小 Agent 的范畴，减少任务量，以本周而不是本季度为目标。 目标不是构建令人印象深刻的东西，而是构建一个足够快以供你从中学习的东西。如果耗时超过几周，你可能做得太多了。迭代成本太低了，你不应错过这一点。

“人在回路”（Human-in-the-loop）是功能，而不是限制。 如果需要，从尽可能多地进行人工审核开始。这就是你构建反馈回路的方法，它能让其他一切变得更好。审核输出的人会告诉你到底哪里出错了，而不是你想象中会出错的地方。然后，随着系统赢得信任，你可以逐渐减少人工参与，从 100% 变成 80%，再到 50%，最终实现自主运行。

让失败变得显而易见。 测试时不要过早构建复杂的错误恢复机制，要构建明显的错误呈现。你希望清晰地看到失败，以便理解它们。在传统软件中，你可能想要优雅降级；但在 Agent 系统中，你希望在开发和测试初期就出现大声的失败，这样你才能修复根本原因。

每周迭代 vs 季度路线图。 观察上周实际失败了什么，然后优化 Prompt、修复模糊的部分、添加护栏。专注于真正出现问题的环节，并利用你掌握的所有控制手段。

在有证据而非直觉时再添加 Agent。 “我认为我们需要一个验证器”只是一个猜测。最好能列出类似“47% 的错误是验证器可以捕获的格式问题”这样的理由。多 Agent 架构虽然强大，但也会成倍增加调试难度，所以要考虑到这些系统的演进过程，你是通过证明自己确实需要，才一步步增加复杂度。

使 Agent 系统强大的因素——编排智能并将其指向模糊问题的能力——也是使其成为一种难以构建的“怪兽”的原因。你无法预先完全明确行为，因为行为是从提示词、工具、数据、MCP 和模型本身的相互作用中涌现出来的。理解这种相互作用的唯一方法就是针对真实输入运行它，看看会发生什么。

这并不是技术的局限性，这就是它的工作方式。一旦你拥抱这一点，交付就会变得简单得多。

为什么这感觉不对（以及为什么它有效）

我理解为什么这种方法可能感觉违反直觉。工程师习惯于尝试预判边缘情况，并从第一天起就为规模化设计。因此，甚至考虑发布一个你还没把每个像素都打磨得闪闪发光的产品，感觉是很奇怪的。

但我们不断看到的是：困在 POC 炼狱中的团队并非能力不足，问题在于他们正在为一个自己尚未完全理解的系统进行优化。他们正在为不会发生的错误编写错误处理代码，同时错过了真正会发生的失败；有时甚至在知道什么值得规模化之前就进行了规模化建设。

你的第一个 Agent 应该“笨拙”地做成一件事。

这大概就是通往你心中所想那个复杂系统的途径，只是顺序与你预期的不同。