导读：折叠的隐性代价
折叠不是把 12 个盒子塞进 1 个盒子。它是把 12 道隔离墙拆掉，然后在同一个房间里重新划区。
这句话源自 Anthropic 应用 AI 团队的文章《Building agents: When to fold subagents into your main agent loop》。文章详细阐述了何时保留子智能体、如何折叠及团队协作方法，但其核心代价仅以注脚形式提及：
将子智能体折叠进主循环后，虽然延迟降低，但破坏了一条原本正常的流程——主 Agent 持有订单查询工具后，自行编造了交付日期，而未咨询物流专家。这种错误具有偶发性，仅在部分运行中出现。
错误的本质在于：没有报错，没有超时，没有异常栈。用户询问“订单何时到达”，Agent 查询订单后，依据“通常三天”的经验给出了格式、语气均正常的答案。唯一的问题是，交付日期是虚构的。这并非模型能力退化，而是流程约束消失：原本在调用图中明确的“需咨询物流专家”规则，折叠后需依靠提示词、工具和评测重新构建。
本文旨在探讨：折叠会移除哪些结构性保障，以及重建这些保障所需付出的工程成本。
一、收益核算：折叠省下的三样资源
折叠带来的真实收益主要体现在以下三个维度：
| 维度 | 多智能体架构 | 折叠后架构 | 收益分析 |
|---|---|---|---|
| 上下文保真 | 每次交接返回摘要，细节丢失 | 原始结果直接进入主窗口，由模型自行连接 | 跨步骤归纳类任务收益最大 |
| 延迟 | N 层嵌套模型循环，每层需等待 | 单层循环，轮内工具并行执行 | 公开案例显示速度提升约 2 倍（受限于任务串行度） |
| 维护面 | N 份提示词、N 套评测、N 个归属团队 | 1 份系统提示 + 1 套端到端评测 | 最易被低估，但长期收益最持久 |
其中，“维护面”的优化值得重点关注。多智能体系统的隐性成本不仅是算力，更是一致性。各团队独立维护提示词会导致规则冲突（即“弗兰肯提示”现象），且分散的评测体系会使整体评分失真。折叠通过统一提示词和评测集，一次性解决了这些问题。
然而，收益与代价并存。下图展示了折叠交易的两面性：
二、代价之一：上下文从“有边界”变为“无边界”
子智能体的核心价值常被误解为“隔离”，更准确的说法是它提供了一次性丢弃权。子智能体的窗口在任务完成后可整体丢弃，其中的试错过程和垃圾数据不会进入主循环，主循环仅接收有损但可控的摘要。
折叠后，主循环窗口累积且每轮完整读取，导致三类数据性质发生改变：
- 工具返回的失败载荷：如 502 页面或长篇堆栈信息。在子循环中随循环结束消失；在主循环中永久占用位置。
- 检索回来的无关文档：RAG 召回的多篇文档中，主循环需全文读取所有文档，包括无用部分，并在后续轮次重复读取。
- 试错过程：多次参数尝试的错误记录会成为“历史”，影响模型对后续步骤的判断，导致过度谨慎或误判。
这是一种交换：用“摘要的有损损耗”换取“污染的完全暴露”。摘要损耗是可预测的，而污染损耗是不可预测的。若任务失败代价低（如检索筛选），折叠划算；若失败会写入下游（如审批结论），则应保留摘要机制以避免脏数据干扰。
三、代价之二：并行能力的局限取决于扇出宽度
单循环并非完全无法并行，其瓶颈在于扇出宽度（同时处理的独立支路数）。由于模型缺乏全局任务清单，面对多源数据查询时，往往采取“查几个看结果再决定下一步”的策略，将本可并行的任务压制成串行。
粗略估算表明，交叉点位于扇出宽度 W≈3 附近。对于客服、代码修改等串行任务（W=1），折叠优势明显；而对于尽调、多源比价等宽扇出任务（W≥8），折叠后反而变慢。建议通过统计会话中的工具调用依赖关系来判断：若 80% 会话为串行依赖，可放心折叠；若存在高扇出尾部，需保留子智能体或改为批量工具调用。
四、代价之三和四：权限边界与故障域扩大
权限：从“配置错误”变为“逻辑遗漏”
在多智能体结构中，权限由编排层集中控制（1 个检查点）。折叠后，权限检查下沉至每个工具内部（N 个检查点）。风险性质随之改变：
- 旧结构风险为“配错”，通常导致功能大面积不可用，易被发现。
- 新结构风险为“漏写”，即某工具未进行权限检查，导致敏感数据泄露。此类错误不报错、不告警，难以察觉。
因此，代码规范应强制要求工具权限检查默认拒绝。可见的故障（无法访问）远比不可见的越权（成功返回非法数据）更具工程安全性。
故障域：局部错误扩散至全局
子智能体崩溃仅为局部事件，主循环可重试或降级。而在主循环中，工具返回的“看似成功实则错误”的结果会进入上下文，污染后续所有推理步骤。此外，折叠降低了可测试性：端到端测试难以捕捉“跳过步骤”等局部逻辑错误，需通过增加运行次数来弥补统计上的不足。
五、折叠后必须重建的四道防线
针对上述代价，需主动构建以下四道防线：
防线一：工具级权限，默认拒绝
from functools import wraps
def guarded(tool_name: str):
"""工具级权限闸门。注意：没有显式授权就是不许，不是「先放行再看」。"""
def deco(fn):
@wraps(fn)
def wrapper(ctx, *args, **kwargs):
# 默认拒绝：allowed_tools 里没有，就是无权
if tool_name not in ctx.allowed_tools:
return {
"ok": False,
"reason": f"当前用户无权调用 {tool_name}。",
# 关键：返回模型能读懂的拒绝，而不是抛异常
"hint": "请告知用户联系管理员开通，或改用其他方式回答。",
}
if not ctx.rate_limiter.allow(tool_name):
return {"ok": False, "reason": "调用过于频繁，请稍后再试。"}
return fn(ctx, *args, **kwargs)
return wrapper
return deco关键点：默认拒绝、返回模型可理解的提示信息、在同一层处理限流以避免模型误判工具故障。
防线二：上下文卫生
MAX_TOOL_CHARS = 4000
def sanitize(raw: str, ok: bool) -> str:
"""工具结果进主上下文之前，先过这一道。"""
if not ok:
# 失败载荷不进正文，只留一行定位信息
return "[工具失败] 已记录，不要基于此结果回答。请换一种方式获取。"
if len(raw) <= MAX_TOOL_CHARS:
return raw
# 超长结果保留头尾：头给结构，尾给结论，中间通常是重复数据
head, tail = raw[:2500], raw[-1000:]
return f"{head}\n…[已省略 {len(raw) - 3500} 字符]…\n{tail}"补充规则：
- 去重：合并同一轮次中重复的工具返回结果。
- 定期摘要：长会话中将已确认事实结构化归档，由 Agent 主动管理上下文。
防线三：链路覆盖评测
建议建立中央端到端评测集，并遵循以下折叠特有规则：
- 按调用链建用例：覆盖真实生产环境中的每一条调用链，检测顺序约束是否被破坏。
- 红线规则用例：针对“绝对不可违反”的规则（如未查物流不得回答日期）设立专用用例。
- 多次运行验证：每个用例至少运行 3 次，以捕捉偶发性逻辑跳过错误。
防线四：决策日志
折叠后需通过日志还原内部结构，重点记录：
| 记录内容 | 目的 | 典型定位问题 |
|---|---|---|
| 本轮加载的 Skill | 替代原有的“路由准确率”指标 | 流程错乱（如退款走成换货） |
| 工具调用列表及顺序 | 监控顺序约束的执行情况 | 未查物流即回答日期 |
| Token 消耗分布 | 识别上下文膨胀的渐进过程 | 后期判断能力下降 |
六、将保留条件转化为可测判据
Anthropic 提出的三条保留条件需量化执行：
判据 1：上下文长度扫描，关注切片而非均值
def probe_context_ceiling(tasks, lengths=(8_000, 16_000, 32_000, 64_000, 128_000)):
rows = []
for L in lengths:
for task in tasks:
ctx = fill_history(task.prompt, target_tokens=L) # 人为灌到指定长度
out = run_agent(ctx)
rows.append({
"len": L,
"task_type": task.type, # 关键：按任务类型切片
"score": judge(out, task.rubric),
})
# 每个任务类型单独找拐点，不要只看总体均值
return pivot_by_type(rows)
许多团队误以为无上下文膨胀，是因为简单任务拉高了平均分。正确做法是按任务类型切片，确定各类任务的性能拐点基线。
判据 2：统计扇出分布
通过分析日志，统计会话中工具调用的数量及依赖关系。若 80% 会话扇出 ≤2，可折叠；若尾部 10% 会话扇出 ≥8，需单独处理。
判据 3：工具选择能力扫描
逐步增加工具集规模（10/20/30...），观察工具选择准确率。若在较少工具时准确率即下降，说明工具描述存在歧义，应先优化描述或进行工具分组，而非直接折叠。
七、折叠时机本质上是评测问题
模型能力的提升由供应商推动，而评测能力的建设则由团队自主掌控。折叠时机取决于两者斜率的差异：
危险区的特征是：模型足够强，但评测体系仍沿用旧架构，无法覆盖折叠后的新失败模式（如步骤跳过、字段编造）。此时折叠可能导致隐性质量下降。
折叠将“可局部验证的结构”转换为“只能整体验证的结构”。评测能力是进行此交易的保证金。保证金不足，即便模型再强也不应折叠。
反之，若评测能力强大，可更早尝试折叠，因为能快速发现并回滚错误。
结语：墙拆掉之后，线由谁来划
折叠确实简化了架构图，但也将被结构隐含保护的约束转变为需显式维护的规则。复杂度并未消失，只是从“结构复杂度”转移为“规则复杂度”。
决策顺序应为：先建立黄金用例基线，再统计扇出分布，最后逐个折叠子智能体并验证。那些为了拆墙而建立的检查、用例和日志，既是折叠的成本，也是真正的技术门槛。