当前位置：首页 > news >正文

解密Prompt系列67. 智能体的经济学：从架构选型到工具预算

news 2026/5/12 17:57:22

导读：2025年是智能体爆发的一年。然而，随着模型能力的提升，工业界开始反思：盲目增加智能体、盲目增加工具调用次数真的能“大力出奇迹”吗？本文串联了两篇Google论文，从宏观的架构选择到微观的工具预算感知，探讨如何科学地构建高效的Agent系统。

Part 1. 宏观选型：多智能体的科学定律

Towards a Science of Scaling Agent Systems

最近在很多分享交流上对于究竟使用单智能体vs多智能体有很多不同的声音。24年其实以多智能体架构为主，但是随着模型能力的提升，不少论文发现，多智能体带来的边际收益在递减，同时多智能体之间的沟通成本和信息碎片化，导致在部分任务上甚至不如单智能体的效果。

而Google这篇论文没有停留在理论争辩，而是通过严谨的控制变量实验，揭示了架构选择与任务特征之间的深层数学关系。论文试图回答：

影响智能体系统表现的决定性变量是什么？
智能体间的“沟通”何时是蜜糖，何时是砒霜？
是否存在一个通用的“最优架构”？

实验设计：解耦与控制

为了得出上述结论，作者设计了一个非常严谨的控制变量实验。以下是其具体的实验步骤：
步骤一：明确的Agentic任务范围

论文明确剔除了所有非智能体任务，毕竟多智能体隐式带来的Ensenble等推理效果很容易在HumanEval等任务上带来提升。这里智能体任务包含三个特点

多步和环境交互
基于部分观测的反复信息收集
基于反馈的策略优化

缺少以上条件的任务，其实都是在测试模型自身的推理能力，而非智能体在动态非确定环境性下工具调用和多步动态规划能力。基于以上条件论文选择了下面四个测试实验

Finance-Agent: 高可分解性，需多视角数据聚合。
BrowseComp-Plus: 动态网页浏览，具有高熵搜索空间。
PlanCraft: 基于《我的世界》GUI界面的合成数据集，包含时空数据的规划任务，具有严格的序列依赖性。
Workbench: 评估业务流程自动化，涉及确定的代码执行和工具使用，例如发邮件、安排会议。

步骤二：梳理智能体架构分类
为了解耦“多智能体”这个概念，作者将其拆解为 5 种标准架构进行对比：

SAS：单智能体架构
MAS：多智能体架构，论文按照信息流动方式和结构分成以下几类
- Independent：所有智能体之间没有沟通，各干各个的，等同于Ensemble模型
- Centralized：中心化模式，Cluade称之为Orchestrator，主智能体负责规划分发任务给子智能体并汇总信息，整个信息流动中存在主导者和信息瓶颈。
- DeCentralized：去中心化，所有智能体All to All通信，论文使用的是辩论模式，其实也有也有像圆桌讨论、多角色讨论等其他模式，只不过是智能体的角色和所站论点的差异。
- Hybrid：兼顾中心规划和子智能体的横向沟通的混合模式

更具体的不同智能体架构的交互深度、沟通复杂度如下

步骤三：变量控制
所有架构使用完全相同的工具、指令和任务描述，和相同的总推理Token预算。所以会存在MAS下子智能体越多，那每个子智能体分配到的轮次就更少。

实验结论和分析

如上图是不同智能体结构在不同任务上的实验效果，实验结果并未给出一个“万能架构”，反而揭示了信息流结构（Information Flow Structure）才是决定架构优劣的根本。

多智能体收益高度依赖任务结构，不存在永远最优的智能体架构

正收益：在可分解、并行的任务上，例如需要多角度信息收集的Finance Agent任务上，MAS 表现出色，中心化架构（Centralized）比单体（SAS）提升了 80.9% 。
微收益：在动态搜索任务（BrowseComp-Plus）上，去中心化架构仅带来 9.2% 的提升。
负收益：在强序列依赖的规划任务（PlanCraft）上，所有 MAS 架构都导致性能下降，降幅在 39% 到 70% 之间。

为什么多智能体在序列任务重失效？

作为算法工程师，我们需要透过现象看本质：这是Context Fragmentation（上下文碎片化）带来的必然结果。

高可分解性任务：类比Finance Agent，以及单段落的大纲写作等任务

这类任务的信息流特征是正交且独立，所以
\(P(task2|task1)\sim P(task2)\)，也意味着子智能体之前几乎无需沟通交流或者状态同步，因此中心化结构能带来并发效率提升，以及覆盖更广的搜索空间。

强序列依赖任务：类比PlanCraft，以及Coding等任务

这类任务的信息流特征是马尔科夫或者更长程的序列依赖，所以\(State_2=f(State_1, Action_1)\)，意味着每个智能体都要能获取前面智能体任务执行的全部输出以及隐含假设，才能继续执行。依赖全面完整的信息传递和大量的信息传输交流。而这正是SAS单智能体的模式

重要的Scaling法则

同时论文还尝试进一步归因除架构之外的其他影响因素，包括

工具-协作权衡（Tool-Coordination Trade-off）：这是一个强负相关因素 (\(\beta=-0.330\))。任务涉及的工具越多（Tool-heavy），多智能体的通信开销（Overhead）就越严重，导致效率骤降。一个可能原因在于工具越多，复杂的tool schema会和复杂的协作指令抢夺模型有限的注意力空间（类似注意力抢占在多轮对话vs工具调用中也能观测到）。
能力饱和效应（Capability Saturation）：当单体 Agent 的基线准确率已经超过 45% 时，增加更多 Agent 反而会因为协调成本带来负收益。因为高水平模型在同一任务上的一致性较高，而额外的沟通返回会引入语义漂移（类似传话过程中的传递误差）。除非是多智能体独立查询不同数据独立完成任务，否则只是推理协作提升不大。（所以本质还是信息流动的问题）
架构相关的错误放大（Error Amplification）： Independent架构会将错误放大 17.2倍（因为缺乏错误验证机制）,而中心化架构能显著通过中心的规划智能体作为verifier对所有子智能体的返回信息尽心验证提升系统鲁棒性。

所以整体上在智能体设计上几个点很明确，第一明确你任务的信息流结构、再评估单智能体的效果、最后评估你工具的复杂度再考虑使用什么类型的多智能体结构。

Part 2. 微观执行：单智能体的预算感知

Budget aware Tool-USE Effective Agent Scaling

聊完多智能体选型，接下来我们看下如何最大化单智能体在有限工具调用下的执行效果。论文揭示了实际应用中的一个现实问题，既我们不会无限等待模型去循环往复的调用工具，我们依旧是在追寻效率和效果的帕累托最优。

那Agent执行，本质就变成了一个条件优化问题，如何在有限的工具调用次数下，最大化智能体的执行效果。

2.1 核心痛点：盲目的Hard Stop

现有Agent框架通常设置 max_steps（iteration）=XX 作为兜底，来强制截断模型超长的工具调用链路，但 Agent 本身不知道自己还剩多少次机会。这也导致简单的增加 step 限制并不能线性提升效果，因为 Agent 不知道自己“钱（Budget）”还剩多少，在实际任务执行时我们往往观测到两种失败模式

Agent过早放弃没有收集到完整信息
Agent在错误，或者很难成功的道路上反复尝试导致资源耗尽

2.2 解决方案Level1 - 显式感知

作者提出的 BATS (Budget Aware Test-time Scaling) 框架，本质上是在 Prompt Engineering 和控制流层面引入了模型可感知的预算条件约束。

指令如下，论文在Prompt中动态加入了工具调用Budget，在每轮模型进行工具调用时，显式告知模型，当前可用的工具调用次数，以及针对不同的预算剩余，模型应该如何动态调整自己的工具调用策略。

## Budget
You have two independent budgets:
- Query Budget (for search)
- URL Budget (for browse)
Each string in 'query' or 'url' consumes 1 unit respectively.
After each <tool_response>, a <budget> tag shows remaining units.
You must ADAPT your strategy dynamically to the current budget state.
### HIGH Budget (>=70% remaining)
- Search: 3-5 diverse queries in one batch.
- Browse: up to 2-3 high-value URLs.
- Goal: Broad exploration, build context fast.
### MEDIUM Budget (30%-70%)
- Search: 2-3 precise, refined queries per cycle.
- Browse: 1-2 URLs that close key knowledge gaps.
- Goal: Converge; eliminate uncertainty efficiently.
### LOW Budget (10%-30%)
- Search: 1 tightly focused query.
- Browse: at most 1 most promising URL.
- Goal: Verify a single critical fact or finalize answer.
### CRITICAL (<10% remaining or 0 in one budget)
- Avoid using the depleted tool.
- Only perform 1 minimal-cost query or browse if absolutely essential.
- If uncertainty remains and no tool use is possible, output <answer>None</answer>.

论文使用多个模型，在多个任务上对比了单纯使用ReACT，和加入Budget的ReACT的效果。

相同预算下，Budget Tracker可以实现更高的任务完成准确率
相同的准确率下，Budget Tracker的工具调用轮次更低
加入Budget Tracker后，提升工具调用次数可以更加持续地带来效果提升。换言之引入Budget Tracker可以提升智能体在单任务的执行上限。

解决方案Level2 - 策略使用

Budget Tracker只是第一步，它负责“报账”让模型了解自己还有多少次机会，剩余全靠模型自己发挥，而再进一步我们可以系统告知模型如何利用这笔预算来规划复杂路径，包括如何优化Planning和Verification的效果。

论文选用的智能体架构，是两个单线程的智能体，第一个智能体Planner负责规划，并根据规划步骤逐步调用工具回答并给出答案, 第二个整体Verification负责对第一个智能体给出的答案进行校验，并判断是否需要答案已经合格，后者需要深入挖掘、或者更换搜索方向。

我们就单看下和Plan模块的结合，Budget预算对这个模块的影响包括

Exploration：预算决定了搜索树的宽度。预算足 \(\rightarrow\) 制定多分支探索计划；预算紧 \(\rightarrow\) 制定单点验证计划
Verification：预算决定了回溯的深度。预算足 \(\rightarrow\) 深入挖掘；预算紧 \(\rightarrow\) 立刻转换方向或者直接输出答案

具体规划相关的指令如下：

## About questions
Questions contain two types of constraints: exploration and verification.
* Exploration: Broad, core requirements (e.g., birthday, profession). Use these for initial
searches to surface candidates. You may combine 1-2 to form stronger queries.
* Verification: Narrow, specific details. Apply these only after you have candidates, to
confirm or filter them. Never begin with verification constraints.
Start with exploration queries, then use verification to validate the results.
## About planning
Maintain a tree-structured checklist of actionable steps (each may require several tool calls).
- Mark each step with its status: [ ] pending, [x] done, [!] failed, [~] partial.
- Use numbered branches (1.1, 1.2) to represent alternative paths or candidate leads.
- Log resource usage after execution: (Query=#, URL=#).
- Keep all executed steps, never delete them, retain history to avoid repeats.
- Update dynamically as you reason and gather info, adding or revising steps as needed.
- Always consider current and remaining budget when updating the plan.

引入以上指令和Budget Tracker后，会观测到模型在不同预算前提下做出的如下行为改变。