4 篇博文 含有标签「agent-engineering」

我认识的一个团队在某个周二向他们的支持智能体目录发布了一个新的 lookup_customer_v2 工具。这个工具的作用范围很窄，经过了充分的隔离测试，并通过了评审。到了周四，一个毫不相关的流程——退款处理——在之前一直运行良好的案例中出现了约 4% 的失败。退款工具没有变。退款提示词没有变。模型也没有变。改变的是规划器（planner）现在在处理退款资格查询时选择了 lookup_customer_v2，而以前这些查询都会清晰地路由到 get_account_status。原因是新工具的描述中恰好包含 "eligibility"（资格）这个词，并在模型内部使用的某种相似性启发式算法下获得了更高的排名。

这就是依赖炸弹。团队通常将工具注册表视为增量式的——“我们只是增加了一个东西，能出什么问题”——但规划器并不将你的注册表视为独立能力的列表。它看到的是各种选择上的概率分布，而每一个条目都会重新分配权重。增加一个工具可能会悄悄地削弱其他地方的行为，而你的评估套件（eval suite）可能会漏掉这一点，因为没有人写过回归测试来规定“在这种情况下，智能体应该仍然选择 旧 工具”。

大多数构建智能体（agent）的团队将数据库模式（schema）视为后端关注的问题。这种模式是由工程师为工程师设计的，遵循了数十年关系型数据库的最佳实践：积极规范化、避免冗余、拆分引用表、强制执行外键。这种方法对于联机事务处理（OLTP）系统是正确的，但对于 AI 智能体来说通常是错误的。

当智能体读取你的模式以确定如何回答问题时，它并不是在解析数据结构，而是在构建你业务的心智模型。如果你的模式是为已经理解该领域的应用程序代码构建的，那么智能体将根据为别人绘制的地图进行工作。结果就是幻觉式的联接、错误的聚合，以及原本只需两步却需要八步的工具调用链。

大多数智能体系统在生产环境中失败，并不是因为底层模型能力不足。它们失败是因为围绕模型构建的工程设计过于草率。模型在第三步偏离了方向，但没人注意到，直到第八步，最终答案虽然言之凿凿却是错误的，而且没有任何护栏来拦截它。这不是模型问题，而是架构问题。

智能体工程在三年内至少经历了两个完整的炒作周期。AutoGPT 和 BabyAGI 在 2023 年春季引发了巨大的狂热，随后在 GPT-4 不可靠的工具调用现实面前折戟。第二波浪潮随 2024 年的多智能体框架和智能体 RAG 而来。现在，到了 2026 年，超过半数的受访工程团队报告已有智能体在生产环境中运行——其中大多数团队也发现，部署一个智能体与维持一个可靠的智能体是完全不同的问题。成功的团队将智能体工程视为一门严谨的学科，而挣扎中的团队仍将其视为一种“感觉”（vibe）。

多数构建 AI 代理的工程师将 80% 的时间花在思考使用哪种模型上，20% 的时间花在其他所有事情上。这个比例应该反过来。模型在这一点上几乎是可以互换的——决定你的代理是否能在生产环境中实际工作的是“线束（harness）”。

这个等式很简单：**代理 = 模型 + 线束。**如果你不是模型，你就是线束。而几乎所有真正的工程工作都存在于线束中。