Agent的瓶颈从来不是模型智力

现阶段Agent的瓶颈从来不是模型智力，失败的原因大多来自于不被模型理解的上下文，如模式/规约/问题设定等。

如今，这一层被harness包裹起来。比如上下文的存取与管理，提示词的缓存，工具的识别与调用，上下文冗余信息的最小化，会话信息的结构化，多agent等。

这些基础设施，不在于让模型更聪明，而是让模型接受到正确/可控的上下文，避免被噪音/杂音淹没。

所以很多人说，同样的模型，用了不同的harness之后，效果可能差10倍。

需要注意的是，这种差距不直接来源于更大的模型或更好的prompt，而是来自于更好的上下文完整/工具可复用/记忆可整理/skill 可固化/流程可编排/结果可验证。

比如以往给模型足够多的上下文，但推理过程和推理质量不尽人意，如果可以给一个快而精的定制工具，效率可能差百倍。

给你 40 个工具，可能工具定义就占用了一半的上下文窗口，每个工具执行往返都需要 2-3 秒，消耗了 3 倍 token，带来了 3 倍延迟，失败率提升了 3 倍。

这背后是将“一堆上下文+模型的概率性推理”转而为“确定性任务执行”的原则改变。

通用 agent 的通用性在于 harness，如文件管理/上下文读取与加载/安全校验与审计，而专有领域 agent 的上限来源于各种 skill，这些 skill 中包含了逻辑判断/业务流程/领域知识，代表了 90% 的价值。

也就是说，将智能向上推入 skill，将执行向下固化到 tools。

harness 的核心能力围绕于调度不应该承载过多的业务逻辑，保持轻量，比如做文件的读写/状态机的驱动（ReAct or Plan-and-Execute 模式）/上下文管理（历史对话维护/控制 token 上下文/适时的上下文压缩与截断总结）/边界的安全控制（越权/异常管理/重试机制等）。

这样看起来 harness 能做什么，职责就非常清晰，比如跑 ReAct Loop/管理上下文 Token/文件读写/守护安全边界与异常重试，完全没有业务逻辑。

Resolver 可以视为解析器，在发布之前先读取 docs/EVALS.md文件进行评估，其中包含了各种评估套件，基线分数，准确率信息等，只有经过评估器评估的发布才是授信的。

同时解析器还是一个路由表，为了避免一次性将所有 skill 塞进上下文，解析器可以实现判断当任务类型 x 时，加载 y 文档的逻辑。

所以解析器是一个决策中枢，面对用户请求和提示词可以基于向量检索和语义路由，找到匹配当前任务的特定 skill。

在 Claude Code 中的解析器，可以基于用户意图与技能描述进行匹配。

Tools 是确定性的工具层，为什么需要确定性？确定性的含义是面对同样的输入，每次输出也应该是一样的，工具可以很好的实现这一效果。

确定性的工具层，有助于消除模型的幻觉，可以确保 agent 可控，判断力交给模型，执行力交给工具。

为了确保 Agent 在专有业务领域下跑的更好更快，应该避免给模型讲大道理或堆砌所有的 SOP，更好的方式是提炼与沉淀业务流程，固化为 skill。

这些 skill 文件的组成，就像编程语言的类和方法一样，明确了输入输出规范，明确了前置校验逻辑，明确了执行的逻辑，明确了约束与预期输出。

高度结构化的 md 文件，让模型的注意力机制更聚焦，显著降低执行漂移的概率和幻觉问题。

所以要对业务逻辑进行抽象，明确出输入是什么/前置条件是什么/执行标准是什么/输出格式是什么。

将这些业务逻辑沉淀到文件中，大模型读起来才会更专注，不易跑偏。