2,800 Token 的推理链 → 280 Token 的结构化事实。同样的发现，1/10 的上下文。

子代理返回 3,000 token 的叙述性响应加完整推理链，4 个响应就填满了编排器的上下文。编排器需要的是结论，不是思考过程。切换到结构化输出（关键事实、引用、置信度评分）后，每个代理的 token 从 2,800 降到 280——减少 90%——综合准确率从 68% 升到 91%。

数据：三种输出格式

每一级结构化同时改善所有指标。紧凑的、可解析的数据比冗长文本更容易让编排器整合——准确率提升是因为相关信息更容易获取，而不是因为提供了更少的信息。

结构化输出 Schema

{
  "finding": "SQL injection vulnerability in user input handling",
  "category": "security",
  "severity": "HIGH",
  "citation": "auth/handler.py:42",
  "confidence": 0.95
}

跨所有子代理的统一 schema 让编排器能够用相同的字段结构合并和优先排序来自 8 个专业代理的发现。发现可以跨代理按 severity 和 confidence 排序，无需格式特定的解析。

子代理不应该返回什么

完整推理链。 编排器需要结果，不需要决策过程。关于被否定假说的推理在编排器未请求的信息上浪费了上下文。

原始数据。 强迫编排器重新推导结论是重复劳动，还消耗更多上下文。子代理应该提供处理过的结果。

完整文档文本。 编排器需要知道哪条策略适用、在哪里能找到它——不需要完整文档。一条引用（“policy-guide.md:section-3.2”）用最少的 token 提供了可追溯性。

置信度评分替代推理验证

有人提议返回完整推理链以便编排器验证正确性。但通过审查推理来验证既昂贵又不可靠——编排器的工作是综合，不是审计逻辑。

置信度评分高效地服务于验证目的：低置信度触发重新委派给另一个子代理或人工审查。高置信度允许编排器继续推进。不需要推理链。

通过引用实现可追溯性

每条发现都必须链接到来源证据以便审计追踪。引用（如 auth.py:42、policy-guide.md:section-3.2）用最少的 token 提供了这种可追溯性。推理链不是可追溯性所必需的——它们解释思考过程，而引用指向证据。

上下文效率和可追溯性不是互斥的。带引用的结构化事实同时满足两个约束。

第一步

如果子代理目前返回自由文本：定义一个结构化输出 schema。这同时解决两个问题——上下文效率（结构化 < 自由文本）和可靠提取（解析字段 vs 文本挖掘）。后处理摘要是变通方案；从源头修复输出格式才是根因解决方案。

一句话总结： 要求子代理返回带引用和置信度评分的结构化事实，而不是叙述性推理——这减少 90% 的每代理 token，综合准确率从 68% 升到 91%，通过引用而非冗长推理链实现可追溯性。