发布首个AI智能体的九个工程习惯
防止智能体在运行中失败的九个习惯：先进行评估、设定上下文预算、限制自主权、进行追踪、对提示词进行版本控制、估算成本以及对故障进行分类处理。
来源: *9 AI Engineering Rules I Wish I Knew Before Shipping My First Agent*
在智能体工程领域流传着一个关于47,000美元账单的故事。这个故事被讲述时并未详细说明具体情况，因此应将其视为一个示例，而非经过核实的真实案例。某个智能体在所有演示中表现都极为出色。但当将其应用于真实的客户工作流程后，它却陷入了退款循环，连续六小时不断重复相同的操作，而无人监督。该模型的能力其实并不差，问题出在构建系统的人忽略了所有能告诉模型何时停止的机制。
这正是从事人工智能系统工程工作的残酷现实：即便你精通Python、RAG、智能体、向量数据库、提示词技术以及各类模型版本，仍可能无法准备好将其投入实际应用。在演示失败后能挽救局面的技能往往不会出现在教程中——它们枯燥乏味且容易被忽视，却决定了一个看似出色的系统是否真正可靠。在发布任何自主运行系统之前，以下九种工作习惯值得养成。
为何掌握更多知识并不代表你就更资深
一些数据展示了项目从演示到部署之间停滞的频率。这些数据来自第三方，且统计方法各异，因此仅可作为大致参考：
- Gartner在2025年中期预测，到2027年底前将有超过40%的智能体人工智能项目被取消，原因在于成本上升、价值不明确以及风险控制不足。
没有任何模型的推理能力会突然下降40%。从演示到正式上线之间一定存在问题。目前的理论认为，生产环境中的故障往往是由模型所处的系统导致的，或是被该系统放大的，而并非仅仅由模型本身的输出造成：比如缺乏约束机制、数据质量差、验证不充分、可观测性不足以及支出失控等问题。
基准测试只能表明趋势，却无法证明背后的原因。在tau-bench中，该测试旨在评估智能体处理诸如预订航班和解决支持工单等任务的能力，有份总结指出即便是最优秀的模型也仅能完成不到一半的任务，而且重复执行同一任务时其一致性会降至约四分之一。这仅能衡量能力，却无法诊断问题所在——它只能说明智能体不可靠，但说不出原因。
请牢记一个关键区别，因为它贯穿了以下所有观点：上述循环并非错误答案，也没有任何因素阻碍它的运行。模型输出与系统允许基于该输出实现的结果之间的差距，正是这些问题的根源所在。
1. 先设计评估标准，再开发功能
初学者会先编写提示词，尝试几次，看看效果如何后再发布。而经验更丰富的工程师则会首先将“正确”的标准以测试用例的形式写下来，之后才着手实现相关功能。
评估可以很简单：从实际使用中收集20到30个真实案例，每个案例都标注预期结果，每当有变动时就用该提示词去测试所有案例。如果不能通过查看输出结果并推理来判断改动是否有帮助，那只是凭感觉而非真正的评估。养成这个习惯是避免发布无法察觉的缺陷的最快方法。
2. 像对待金钱一样对待上下文信息
初学者的习惯是把所有内容都塞进去：整份文档、全部对话记录，再加上五个“以防万一”的示例。觉得信息越全就越安全，但实际上并非如此。每多一个元素都会争夺模型的注意力，让它不得不去处理更多错误的细节。应将输入窗口视为一项预算：
- 将检索到的文档仅保留相关部分。
- 对之前的对话内容进行总结，不必完整重现。
- 删除那些没有实际作用的示例。
如果不确定窗口里有什么内容，就把发送的完整提示语打印出来仔细阅读。很多人会发现其中有很多冗余信息。
3. 在使用前限制模型的自主性
这就是本可以打破退款循环的习惯。由“操作员集体”这一组织对那些代价高昂的代理失误进行的分析将相关案例分为五类：对自主行为的无限制、过时或错误的数据、不加验证便轻信输出结果、将安全性视为事后才考虑的问题，以及因缺乏监控而无人察觉的故障。这五类中没有任何一类属于“模型推理错误”。这只是单一的一项分析，并非自然法则，但它揭示了某些现实情况。错误的输出本身很少会单独造成危害，真正的危害在于后续没有机制能够及时发现它、限制它或防止其再次发生。
从数学角度来看，这是无可商量的。如果智能体工作流的每一步都有95%的成功率，而任务包含20步，那么整个流程并不能有95%的概率正确完成，因为各种概率会相互叠加。如果每步的成功率为90%，那么20步的流程只有大约12%的概率能成功完成。仅能顺利执行三步的演示，对于包含二十步的实际生产流程来说几乎没有任何参考价值。
在任何自主系统投入运行之前，都应为其设定步骤限制、成本上限、超时时间以及自我停止机制。这并非因为无法信任该模型，而是因为概率永远不会消失。
4. 像要在凌晨两点盲目调试一样记录日志
最危险的故障并不会发出巨大的崩溃声。智能体会采取错误的操作，却报告成功，控制面板仍显示正常状态，而客户却在无人察觉的情况下蒙受损失或得到错误建议。
初学者总是在出问题后才添加日志记录。而经验丰富的工程师从一开始就会构建结构化的追踪系统：所有的输入、工具调用以及中间推理步骤都会被标记时间戳并便于搜索。三周后，如果你希望准确重现智能体所看到和做出的决策，而非凭记忆拼凑信息，那就必须先弥补这一缺陷。
5. 逐步提升：提示、检索，再微调
当准确率不尽如人意时，初学者往往直接选择微调，因为这看起来像是“真正的”工程手段。但这通常不是正确的第一步，有一个著名的案例可以说明原因。微软的研究人员采用了GPT-4，并加入了一组名为Medprompt的提示技术，随后将其与经过临床数据训练、并配有专家编写提示语的谷歌医疗专用模型Med-PaLM 2进行比较。在MedQA测试中，经过微调的Med-PaLM 2得分率为86.5%，而仅使用Medprompt提示技术的GPT-4则达到了90.2%。这意味着错误率降低了27%，而且所需的模型调用次数也比微调方法少一个数量级。
合理的操作顺序应该是从成本低且可逆的方法开始，逐步过渡到成本高且耗时的方法：
Prompting Retrieval (RAG) Fine-tuning
(cheap, fast, → (add missing → (expensive, slow,
reversible) knowledge) last resort)
先修正提示词并对其进行测试。如果模型缺乏相关事实，就需要加入信息检索功能。只有在你拥有大量干净的数据集，并且存在提示词确实无法实现的具体行为时，才需要进行微调。大多数团队其实无需这么做，因为前面的步骤就已经能解决问题。
6. 将决策与执行分开
初学者的智能体通常是一个庞大的提示词，它会在同一过程中完成规划、决策和执行。一旦出错，就很难区分是“模型思考有误”还是“代码运行出了问题”，因为这一切都混在了一起。
经验丰富的开发者会将系统分为两部分。其中一部分是模型，它充当“大脑”负责选择下一步操作；另一部分则是简单的确定性代码，相当于“执行机构”，负责实际执行操作：它调用API、检查响应结果、在限定次数内重试，并遵循第三条准则中的约束规则。正是这种分离结构使得系统具备可调试性——你可以立刻判断是模型选错了动作，还是执行代码把正确的动作搞砸了，这两种错误需要不同的解决方法。
7. 将提示语视为代码并对其进行版本控制
那个需要修改四次的提示词就是生产环境逻辑。如果把它当作草稿纸来处理，一旦有人试图“改进”它，你就會失去可用的版本。应像对待其他文件一样将提示词纳入版本控制，在合并任何更改之前，先用第一个习惯中的评估集进行测试，并记录下哪些内容发生了变化以及原因。这听起来太基础了，正因如此大多数团队都会忽略它，直到提示词出现退化问题影响到生产环境，而没人能说清楚到底发生了什么变化。
8. 先确定功能的价格
这里有一个具体的例子。一个执行单一软件任务的无人监管智能体需要支付5到8美元的API费用，而包含整个生产流程、重试操作以及工具调用在内的总成本则在10到100美元之间。不同模型、任务及优化策略会导致具体数值有所差异，但总体趋势不变：单次任务看似微不足道的成本，在大规模应用时就会变得相当可观；在测试阶段看似便宜的试点方案，也可能悄悄成为项目被搁置的原因。
初学者通常先动手开发，之后再查看账单。经验丰富的工程师则会在编写代码之前就估算每项任务的成本：输入的token数量、输出的token数量、每项任务预计需要的调用次数以及每日预期处理量。如果10个用户时的成本就已经不合理，那么1万个用户时情况只会更糟。成本并非可在项目上线后再处理的财务问题，而是你在设计架构时就已做出的决定，无论你是否意识到这一点。
9. 先诊断再猜测
当出现故障时，初学者的第一反应往往是指向模型，换一个更大的模型或编写更长的提示词。千万别这么做。在第三条习惯中提到的那些失败案例，根源在于缺乏约束机制、数据质量差、过度信任、安全措施不足，或是出现了没人注意到的故障，而非模型本身出错。这只是从部分案例中得出的观察结果，无法保证适用于你的情况，但相比重新编写代码，这是个成本低廉的排查方法。在修改提示词之前，先检查获取的数据是否过时或错误，工具调用是否静默失败，以及重试次数是否有限制。很多时候问题出在周围的系统中，而进行检查只需五分钟，远比重新编写要快。
何时可以跳过其中一半
这九种习惯没有一种是免费的。评估机制的建立需要时间，约束规则会增加代码量，而成本建模则会占用本可用于开发的下午时间。如果你只是在周末进行原型设计且只有自己使用，那就不必过多考虑这些。等到其他人开始依赖你的成果时，再引入评估套件、约束规则以及版本化的提示语即可，无需提前这么做。以正式的生产流程来开展单人实验，只会浪费本可用于探索有效方法的宝贵时间。唯有在那些涉及真实用户、真实资金或真实决策的系统中，这种自律才能带来回报。
一句话概括转变
根据该描述，没有任何更智能的模型能够解决这个循环问题。真正解决问题的是一套书面规则：对自主性的限制、每项操作前的检查以及专人负责查看日志。这是治理机制，而非智能技术。初学者试图用更优秀的模型来克服故障，而经验丰富的工程师则会构建一个在模型出错时能安全失效的系统，因为迟早模型都会出错。