第一个智能体,先做一件事,做不好也没关系

我们见过最有效的智能体系统,起步都简单得有点尴尬。智能体数量少,任务范围窄,做得还不怎么样。
这背后有个重要原因,它揭示了传统软件开发生命周期与智能体系统开发生命周期的关键差异。
事实证明,智能体系统更适合迭代构建:爬、走、跑。那些想明白并彻底拥抱这一点的团队,已经在生产环境里跑起来了,而其他人还在打磨他们的演示版。
POC 坟场
一个常见场景:一支技术精湛的工程师团队决定构建一个智能体。他们精通多智能体协作、思维链推理、工具编排、提示工程等等。
他们从一开始就设计出心中理想的系统,比如:研究员智能体为规划师智能体提供输入,规划师与执行者智能体协调,再通过质量检查器验证结果。架构文档详尽,流程图精美,交接流程复杂,还带点错误处理。
三个月后,项目仍卡在开发阶段。README 写得漂亮,但生产流量为零(投资回报率自然也是零)。
问题不在于野心太大,而在于他们正在为一个尚未完全理解的系统做优化。
正是这种能够编排智能、指向复杂问题的能力,让这些系统无比强大,也让它与我们以前构建的其他系统不同。这意味着,构建方式也需要有所不同。
高风险领域,从简单开始
一家医疗人力公司找到我们,他们有个关于资质认证的有趣用例,这已成为主要瓶颈。每次入职一名医生,他们必须核实执照、查询医疗委员会、检查制裁名单、验证身份。这个涉及多个数据源的手动流程,往往需要数天才能完成。更重要的是,在医疗人力行业,医生审核延迟带来的后果远不止收入损失。
他们没有一开始就自动化整个入职流程,而是选了一件事:背景核查工作流。
初始版本很简单:收集提供者数据,查询相关来源,将输出结构化为 JSON,基于数据做决策,并将结果推送到 Snowflake。并非每个边缘情况都处理了。
他们本可以花几个月预想所有场景,但实际在几周内就交付了解决方案。经过实战测试,他们现在可以实施许多其他质量杠杆来平衡负载、纳入人工审核、运行并行工作流——所有这些都让他们能从真实执行中学习,而不是延长规划会议。
如今,他们已经为模型幻觉检测实现了安全护栏(Guardrails),为合规性设置了审计追踪,整个流程从几天缩短到几小时。第二个用例已经在开发中。
如果他们一开始就实施所有制衡措施,很可能就错过了让实际用例和架构变得更好的机会。这就像在传统应用中,还没解决性能问题就先加缓存。
如果今天从头开始
智能体范围要窄,任务要少,本周搞定,别拖到本季度。 目标不是构建令人印象深刻的东西,而是构建你能足够快交付、并能从中学习的东西。如果耗时超过几周,你可能做得太多了。迭代成本太低,不利用这点就亏了。
人机协同(Human-in-the-Loop)是特性,不是限制。 开始时,在你能接受的范围内尽可能多地加入人工审核。这是构建反馈循环的方式,能让其他一切变得更好。审核输出的人会告诉你实际哪里错了,而不是你想象中会错的地方。然后随着系统赢得信任,逐步降低人工比例,从 100% 到 80% 再到 50%,最终实现自主运行。
让失败显而易见。 测试时,先别构建复杂的错误恢复机制,先构建明显的错误暴露。你需要清晰地看到失败,才能理解它们。在传统软件中,你可能想要优雅降级;在智能体系统中,你希望在开发和测试早期就看到“响亮”的失败,以便修复真正的根本原因。
每周迭代,而非季度路线图。 看看上周实际哪里失败了,然后优化提示词,修复模糊部分,添加安全护栏(Guardrails),专注于真实问题出现的地方,并利用你掌握的所有控制杠杆。
有证据再加智能体,别凭直觉。 “我觉得我们需要一个验证器”只是猜测,不如能说出“47% 的错误是格式问题,验证器能捕捉到”这样的具体数据。多智能体架构可能很强大,但也会成倍增加调试面。所以,把这些系统的演进看作是你通过证明需要复杂性,来赢得进入复杂性的资格。
让智能体系统强大的能力——即编排智能并将其指向模糊问题的能力——也正是让它们成为不同“野兽”来构建的原因。你无法预先完全规定其行为,因为行为产生于提示词、工具、数据、MCP 和模型本身之间的交互。理解这种交互的唯一方法,就是用真实输入运行它,并观察会发生什么。
这不是技术的局限。它本来就是这样运作的。一旦你接受这一点,交付就变得直接多了。
为什么这感觉不对(但又有效)
我理解这种方法为何让人觉得反直觉。工程师被训练得要去预想边缘情况,并从第一天就为扩展性设计。所以,考虑交付一个尚未打磨到最闪亮状态的东西,感觉很奇怪。
但我们不断看到的是:困在 POC 炼狱中的团队并非能力不足,问题在于他们正在优化一个尚未理解的系统。他们在为不会发生的错误编写错误处理,却漏掉了会发生的故障,有时甚至在知道什么值得扩展之前就为扩展而构建。
你的第一个智能体,应该先做一件事,做不好也没关系。
这很可能就是通往你想象中的复杂系统的路径,只是顺序和你预期的不一样。
觉得有用?分享给更多人