Agent瓶颈解析：模型智力并非关键因素

现阶段Agent的落地瓶颈，核心并非模型本身的推理能力。多数失败案例的根源，在于模型无法准确解析上下文中的隐性规则——比如行业惯例、任务隐含假设、操作约束等，这些内容完全处于模型的理解盲区。

如今，这一层被封装为“harness”架构。它负责管理上下文的存取与缓存，优化提示词结构，识别并调用工具，过滤上下文中的冗余噪声，实现会话信息结构化，并协调多个Agent之间的协作。

本质上，这些基础设施的目标不是提升模型的智能水平，而是确保模型接收到的上下文准确、可控，避免被无关信息干扰。行业内一个共识是：同样的模型，换一套harness，效果差距可达十倍。

这种差距无法通过更换更大参数的模型或撰写更精细的Prompt来弥补。关键变量在于：上下文完整性、工具可复用性、记忆组织能力、技能固化程度、流程编排合理性以及结果验证机制。

以实际案例说明：过去我们倾向于为模型提供尽可能多的上下文，结果发现推理过程和质量依然不理想。但如果换一种思路，为模型配备一个快速且精准的定制工具，效率差距可能达到百倍。

另一个典型问题：一次性向模型注入40个工具，仅工具定义就消耗了近半的上下文窗口。每个工具调用一次需2到3秒（仅单次往返）。最终导致Token消耗增加3倍，延迟增加3倍，失败率同步飙升3倍。

因此，底层逻辑正在发生原则性转变：从“依赖模型概率化推理大规模上下文”转向“让模型执行确定性任务”。

通用Agent的“通用性”体现在harness层——包括文件管理、上下文读写与加载、安全校验与审计。而专有领域Agent的价值上限，则来自那些凝结了逻辑判断、业务流程和领域知识的skill文件，这部分贡献了90%的业务价值。

换言之，智能能力向上收敛到skill层，执行能力向下沉淀到tools层。

由此，harness的职责边界清晰起来。其核心是调度，不应承载过多业务逻辑，必须保持轻量化。主要任务包括：文件读写、状态机驱动（无论是ReAct模式还是Plan-and-Execute模式）、上下文管理（维护历史对话、控制Token预算、必要时压缩或截断总结）以及边界守卫（权限越界检测、异常处理、重试机制等）。

再看Resolver层，它既是解析器也是决策中枢。在发布之前，Resolver会读取docs/EVALS.md文件进行评估，该文件包含评估套件、基线分数、准确率数据。只有通过评估器校验的发布才被认为是可信的。

Resolver同时充当路由表。为避免将所有skill一股脑塞入上下文，它能基于用户请求和提示词，通过向量检索与语义路由，智能判断当前任务类型（如X类型）并加载对应的Y文档。在Claude Code的实现中，Resolver的核心工作就是根据用户意图与技能描述进行匹配。

Tools层强调确定性。为什么必须确定？因为同一输入应当每次都产生一致输出，工具天然具备这一特性。确定性的工具层是消除模型幻觉的关键武器，使Agent变得可控：判断力交给模型，执行力交给工具。

想让Agent在专有业务领域稳定高效运行，最有效的方式不是灌输大量理论或堆砌所有SOP，而是将业务流程提炼、沉淀并固化为一个个skill文件。

这些skill文件类似编程语言中的类和方法：包含明确的输入输出规范、清晰的前置校验逻辑、完整的执行流程、以及严格的约束条件和预期输出。高度结构化的Markdown格式能使模型的注意力机制更聚焦，显著降低执行过程中的漂移概率和幻觉问题。

因此，对业务逻辑进行抽象至关重要：明确输入是什么、前置条件有哪些、执行标准如何定义、输出格式必须怎样。将这些内容沉淀到文件中，大模型读取时才不会跑偏。

来源：互联网