I keep hearing the same advice about agents

我一直在听到关于代理的相同建议 - 梯度流

我一直在听到关于代理的相同建议

作者

Ben Lorica

2026年8月25日

2026年8月24日

分类

未分类

标签：

通讯

.meta-info

.post-thumbnail

订阅 • 前期问题

代理执行实际工作的九条实用规则

在最近与构建代理团队的交流中，我不断听到相同的教训。产品差异很大的团队几乎独立得出了相同的架构选择。这种趋同令人印象深刻。在之前的帖子中，我曾论述过通过评估并不意味着AI系统是安全的，许多最严重的风险实际上存在于模型之外。这是建设性的后续：当代理开始执行实际工作时，你应该围绕它构建什么？我认为一个实用的架构手册正在逐渐形成。

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

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

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

分界线很简单：让模型处理模糊性，这是它创造价值的地方。将计算放在可信代码中，通过策略系统强制执行权限，使用编译器和测试验证代码，将重要事实声明与权威来源进行核对。询问模型当前可能违反而普通软件可以预防的事项。当失败会导致实质性后果时，架构应使这种违规行为不可能发生，或需要明确批准。

##### 2. 仅给予代理工作所需的自主权

我一直在看到的一个模式是，团队给予代理比工作需要的更多自主权。这种过度的自主权会创造更多可能的路径、更多出错机会、更高的运营成本和更难治理的问题。对于许多应用来说，传统软件应控制工作流程，而模型只处理少数真正需要判断的步骤。当任务需要探索、开放式规划或创建新工具时，更大的自主权才可被证明是合理的。

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

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

##### 4. 设计恢复机制，而非追求完美的一次性通过

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

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

##### 5. 将模型与工具集作为一个系统进行评估

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

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

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

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

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

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

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

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

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

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

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

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

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

如果代理和现实世界的AI部署在你的规划路线图中，欢迎来与已实践的团队共度两天。AI大会，旧金山，9月30日–10月1日。使用代码gradientflow20可享受20%折扣。

没有人讲好的AI数据中心论点

来源：“The AI Data Center Backlash Has a Blind Spot”

前沿AI中的内存瓶颈

来源：“What AI Teams Should Know About HBF and Tiered Memory”