从“不占上下文”的误区，看 Harness 架构的隐形陷阱
从“不占上下文”的误区，看 Harness 架构的隐形陷阱
我曾和许多开发者一样，陷入过一个看似无害的认知误区：认为挂载的工具（Tool Call）说明书只是“配置”，并不占用宝贵的上下文窗口。这种想法让我们在设计 Harness 时变得“贪婪”——试图一次性挂载所有能力，期待模型能像超级英雄一样随时调用。
然而，现实是残酷的。正如 Anthropic 工程师在博客中披露的数据：仅仅挂载 5 个常见的 MCP 服务（包含 58 个工具），其定义文件就消耗了约55k tokens的上下文预算。
这个“55k 的教训”不仅粉碎了“工具不占空间”的幻想，更暴露了 Harness 架构在实际开发中那些容易被忽视的致命陷阱。今天，我们就以这个误区为起点，深入剖析 Harness 架构在编程过程中必须警惕的“三大隐形陷阱”及应对策略。
陷阱一：上下文预算的“隐形通胀”
误区根源：认为工具定义是“元数据”，不占“数据”空间。
现实打击：工具定义是上下文中的“静态巨石”，直接挤压了对话和推理的空间。
在开发 Harness 时，我们往往只计算用户的输入和模型的输出，却忽略了 System Prompt 中那些冗长的 JSON Schema。当你为了让 Agent 更强大，接入了 100 个工具时，你可能在还没开始对话前，就已经耗尽了 128k 上下文的一半。
编程注意事项：
- 拒绝“全量挂载”</