Nine Practical Rules for Agents Doing Real Work

为实际工作的代理制定九条实用规则 - 梯度流动

为实际工作的代理制定九条实用规则

作者：

Ben Lorica

2026年8月26日

2026年8月5日

分类：

未分类

.meta-info

.post-thumbnail

在与构建代理团队的近期交流中，我不断听到相同的教训。产品差异显著的团队却独立得出了几乎相同的架构选择。这种趋同现象显得尤为重要。在之前的帖子中，我曾论述过通过评估并不意味着AI系统是安全的，许多最关键的风险实际上存在于模型之外。这是建设性的后续内容：当代理开始承担实际工作时，你应当围绕它构建哪些内容？我认为一个实用的架构指南正在逐渐成形。

梯度流动的存在得益于读者的支持。考虑成为付费支持者 🙏

##### 1. 将硬性约束置于软件中，而非提示语中

模型擅长灵活推理，而普通软件在状态管理、权限控制、计算、重试和可预测的控制流方面表现优异。可靠的系统会明确区分这两者，而不是要求提示语来保证关键事项。提示语是指导性信息，无论措辞多么坚定，它始终具有可协商性，这在需要判断时是合理的，但对于任何不能出错的事项来说却是真正的难题。

分界线很简单：让模型处理模糊性，这是其创造价值的领域。将计算交给可信代码，通过策略系统强制权限，使用编译器和测试验证代码，并通过权威来源核查重要事实声明。思考模型当前可能违反而普通软件可以预防的规则。当失败会导致实质性后果时，架构设计应使违规行为变得不可能，或要求明确批准。

##### 2. 仅根据工作需求赋予代理必要自主权

我反复看到的一个模式是，团队赋予代理的自主权超过了工作实际需要。这种过度的自主权会创造更多可能路径、更多出错机会、更高的运营成本以及更复杂的治理问题。对于许多应用来说，常规软件应控制工作流程，而模型只需处理真正需要判断的少数步骤。当任务需要探索、开放式规划或创建新工具时，才可合理赋予更多自主权。

我将自主权视为一种有意的设计选择，而非默认设置。从灵活的工作流程开始，观察哪些路径可靠重复，将这些稳定路径转化为普通代码。列出代理选择下一步行动的每个节点，然后询问这些选择中哪些是任务真正需要的。随着代理成熟，其面临的开放式选择会逐渐减少，而非增加。

##### 3. 围绕领域内可信流程构建代理

一个支持工作流已经规定了如何处理请求、收集哪些信息、何时升级以及哪些操作需要批准。医疗工作流则通过诊断协议实现类似目标。当领域已有经过验证的检查表、协议或决策流程时，应将其作为代理的结构，而非从一个通用循环开始，让模型制定计划并持续执行直到完成。

这使系统更加可靠，因为结构已经在实际场景中经过验证。它也使系统更容易被需要信任并批准该系统的人员理解。最优秀的代理架构往往看起来不像一个通用型数字员工，而是更接近于将领域现有最佳实践转化为可执行方案的结构。

##### 4. 设计恢复机制，而非追求首次无误

在长流程中，小错误会迅速累积。一个在每个步骤中成功率达95%的系统，完成十个独立步骤而不出现错误的概率仅有约60%。这有助于解释为什么一个三步演示可能看起来非常出色，而更长的业务流程却可能崩溃。

不要假设模型会停止犯错。添加检查点、确认每个操作是否产生预期结果的验证机制、重试机制、可逆操作，以及从已知良好状态恢复的能力。将恢复能力与首次尝试的准确性分开衡量。能够检测偏差并自我修正的系统，比看起来完美直到遇到第一个意外工具响应的系统更有价值。

##### 5. 将模型与配套系统作为一个整体进行评估

当你测试代理时，你究竟在评估什么？配套系统是围绕模型的软件，包括其工具、上下文管理、记忆、策略和恢复逻辑。这个外围系统对性能的影响可能与更换模型本身一样显著。在一项比较中，同一开源模型在最佳和最差配套系统配置下的表现差异高达18个百分点。这是我在比较模型时最应重视的发现之一。

排行榜只是一个起点。使用你的工具、上下文、权限和失败模式对模型进行评估。当模型或配套系统发生变更时，重新运行评估。更改任一半部分都意味着你在评估一个全新的系统。

##### 6. 保持多代理团队规模较小，并允许存在异议

多代理系统可能看起来很复杂，但通常只是增加了协调开销。更有效的模式通常是明确的协调者加少量专家，每个专家都有明确的角色、工具集、权限范围，以及仅需的信息。当工作真正并行或需要独立视角时，更大的团队可能有帮助，但大规模群体往往导致重复工作，并使故障更难追踪。一个角色需要特殊保护：具有明确标准和权限阻止或升级问题的批评者或破坏者。知道何时不回答是系统必须被设计实现的能力，而不是仅仅通过提示请求某种个性。

##### 7. 更大的工具箱可能让代理表现更差

在一项测试中，工具集更大的系统速度更慢且准确性略低，尽管它包含了小工具集中的所有工具。这可能是列表中最反直觉的规则。额外的工具本身并不差。问题在于重叠。当多个工具都可能处理相同请求时，模型会耗费注意力在近似重复的选项间选择，而不是直接执行任务。

更多工具会赋予代理系统更多的读写能力，同时也会产生更多需要团队测试的工具调用序列。应优先选择功能紧凑的工具集，确保每个工具都有明确且不同的职责。自动运行必要的初始化工具，并记录被选中的工具、输入输出内容以及失败频率。如果两个工具可能处理相同的请求，应将其合并、通过软件进行路由切换，或直接移除其中一个。

##### 8. 上下文、记忆与企业知识是不同的系统

这一区别体现在操作层面：上下文是模型在当前运行过程中需要的信息，记忆是系统需要从先前工作中延续的内容，而企业知识则是受管控的文档、记录和政策的集合。将它们视为一个未区分的存储库会引发质量和安全问题。它们可以共享基础设施，但默认情况下不应共享相同的保留策略、检索规则和访问权限。

记忆功能尤其应保存经验教训而非对话记录。关键在于需要避免的错误、值得复用的技术，或需要改变未来行为的偏好。衡量标准不是系统能记住多少内容，而是检查它保存了什么信息、后续检索了什么信息，以及这些信息是否真正影响了结果。

##### 9. 在升级模型之前先优化知识库

当代理表现不佳时，常见的默认反应往往是购买更强的模型或开始微调。但在更换模型之前，我会仔细检查它实际需要处理的内容。有团队将一堆原始支持文档替换为诊断手册，路由器将客户投诉转化为症状，再映射为问题类型，最后定位到相关手册。在不更换模型的情况下，token使用量下降了43%，错误率下降了48%。

检索功能不是一次安装后就可忽略的特性。当用户表述与文档内容不匹配、信息隐藏在表格或PDF中，或来源存在冲突时，检索会失效。在更换模型之前，应优先优化知识库的结构、路由规则和治理机制。模型是你可以购买的组件，而围绕模型的系统才是你真正拥有的核心资产。