生产级 Agent 系统实战总结：七个 lessons

过去一年，我一直在 TryCook.ai 担任核心工程师——这是一个 AI 操作系统，取代了每年 300 万美元的履约团队，为 348 位创始人提供支持。这意味着 Agent 每天都在做真实的、可计费的工作——不是 Demo。以下是经过生产环境验证的七条经验。

1. Agent 只占系统的 20%

LLM 调用只是简单的部分。剩下的 80% 是队列、重试、幂等性密钥、状态机、审计日志和回滚路径。如果你把 Agent 设计成无聊的、可观测管道中的一个无状态函数，那么失败就变得可恢复。如果 Agent 就是管道本身，每一次幻觉都是一次故障。

2. 用结构约束输出，而不是修辞约束

提示词请求模型"只返回有效 JSON"在大规模下会失败。Schema 强制的输出（工具调用、JSON 模式、语法约束）几乎从不失败。我们栈中每个 Agent 边界都是一个类型化契约——如果模型无法填充 Schema，那是重试，而不是下游的解析错误。

3. 先针对 2% 的失败场景设计

一个 98% 自主的 Agent 在大规模下每天仍然会失败数十次。产品和负债的区别在于失败时会发生什么：任务是否带着完整上下文进入人工审核队列，还是悄然消失？先建升级路径，再建愉快路径。

4. 小模型做路由，大模型做判断

大多数 Agent 步骤是分类、提取或格式化——这是便宜模型的工作。把前沿模型留给少数需要真正判断力的步骤。这是 LLM 产品成本工程的核心，通常可以把支出削减 5-10 倍而不损失质量。

5. 记忆是数据库问题，不是提示词问题

长期运行的 Agent 需要持久化状态：它们做了什么、学到了什么、客户偏好什么。把历史塞进上下文窗口既不能扩展，也无法查询。把 Agent 记忆建模为普通的数据行——事件、事实、偏好——然后有选择地检索。检索的纪律和构建有效 RAG 是同一套技能。

6. 评测是你的回归测试

每次提示词变更都针对一组固定的真实（匿名化）案例与分级输出进行发布。没有评测，提示词工程就是凭感觉；有评测，它就是工程。从 30 个案例和通过/失败评分标准开始——你可以之后增加复杂度，但你无法事后补救置信度。

7. 人类是特性，不是备选

赢家系统不是移除人类——而是把人类往上移。在一个设计良好的 Agentic 系统中，一个操作员监督着过去需要一个团队的吞吐量，只在标记的异常上进行干预。以这种方式定位，采纳就不再是一场战斗。

Agent 不会取代工程纪律。它们以机器速度惩罚缺乏工程纪律的行为。

Originally published at haiderfarooq.dev.