AI Agent的Harness不会消失：从决策到提供的架构转变

一条被忽视的架构洞察

随着大语言模型能力不断增强，一个流传甚广的假设是：模型越聪明，外围的脚手架（harness）就越不重要，最终会被模型本身吸收甚至彻底消失。但一篇由 @pirroh 撰写、并在 Twitter 上获得关注的文章提出了相反的观点——harness 并不会消失，它只是发生了角色转变。

原推文的核心论断非常凝练："harness doesn't disappear as models get smarter - it shifts from deciding to offering"（随着模型变聪明，harness 并不消失，而是从"决策"转向"提供"）。这句话点出了 AI Agent 系统设计中一个容易被误解的趋势。

从"决策"到"提供"意味着什么

在早期的 Agent 架构中，harness 往往承担了大量硬编码的决策逻辑：什么时候调用哪个工具、遵循怎样的流程、在何种条件下终止循环。这类系统本质上是把智能"外置"在框架里，模型只是被调度的执行单元。

当模型能力增强后，很多人预期这些决策逻辑可以直接交给模型自主完成，harness 因此变得多余。而 @pirroh 的观点是：harness 的价值并没有消失，而是从替模型做决定（deciding），转变为为模型提供选项与能力边界（offering）。

换句话说，框架不再告诉模型"必须这样做"，而是向模型"提供"一组可用的工具、权限和子系统，由模型在运行时自行选择。这是一种控制权的下放，但框架依然在定义可能性的空间。

这一转变在软件工程领域有其对应的思想渊源。传统的编排框架（如早期的 LangChain Agents 或 AutoGPT）倾向于用有限状态机或硬编码的工具调用顺序来驱动模型，本质上是一种"控制流优先"的设计。而"offering"模式更接近于"能力注册表"（capability registry）的概念：框架声明哪些工具、子系统或权限可用，模型在推理时根据任务语境自主决定调用哪些资源。这与函数式编程中"高阶函数"的思路类似——调用者提供可组合的原语，具体的组合逻辑由运行时决定。在实践中，这要求框架设计者将精力从"编写正确的流程"转移到"定义边界清晰、语义明确的能力单元"，因为模型需要足够清晰的工具描述才能做出合理的自主选择。

deepagents 的实现思路

推文以 deepagents 为例说明这种设计哲学的落地方式。在 deepagents 中：

• 每个子代理（subagent）都拥有独立的模型、工具集和权限配置；
• 主循环（main loop）负责决定在什么时候生成哪个子代理。

这套架构把"提供"体现得很清晰：主循环并不深度介入子代理内部如何推理，而是负责编排——决定何时唤起某个具备特定能力和权限的子代理来处理任务。每个子代理是一个被精心界定能力范围的"能力单元"，主循环则是在这些单元之间做调度。

独立模型与权限的意义

为每个子代理分配独立的模型和权限，带来了几个实际价值。不同任务可以匹配不同规格的模型，兼顾成本与效果；权限隔离让系统在安全性上更可控，避免单一 Agent 拥有过大的操作面；工具的模块化也让能力可以按需组合。这正是"offering"思路的具体化——框架提供的是一个结构化的能力菜单，而非一条僵硬的执行流水线。

权限隔离的概念借鉴自操作系统安全设计中的最小权限原则（Principle of Least Privilege，PoLP）：每个组件只应拥有完成其任务所必需的最小权限集合，以限制单点失陷后的影响范围。在多 Agent 系统中，若所有子代理共享同一套工具和访问凭证，一旦某个子代理被恶意输入操控（即"提示注入"攻击），攻击面将波及整个系统。为每个子代理单独配置权限和工具集，相当于在系统内部建立了"沙箱"边界。与此同时，为不同子代理分配不同规格的模型（如将简单分类任务交给小模型、将复杂推理交给大模型），这一做法也被称为"模型路由"（model routing），是降低推理成本的重要工程手段，在 RouteLLM 等开源项目中有系统化的实现。

为什么这个视角值得关注

关于"模型变强后框架是否会消失"的争论，在 AI 工程社区一直存在。一派认为随着模型上下文和推理能力提升，复杂的编排层会逐渐退化；另一派则强调工程约束、安全边界和可控性始终需要外部结构来保障。

@pirroh 的表述提供了一个折中而务实的框架：harness 的形态在变，但它的必要性没有变。它从充当"大脑"退居为"提供舞台的编导"。对于正在构建多 Agent 系统的开发者来说，这意味着设计重心应从"写死流程逻辑"转向"设计良好的能力供给与编排机制"。

需要说明的是，本文基于一条 Twitter 推文及其引用的文章摘要，原始信息有限。deepagents 的完整设计细节可参考推文中提及的官方文档，以获得更严谨的技术理解。

这场争论的背后，有一个具体的技术参照点值得了解。Anthropic 在其 2024 年发布的 Agent 设计指南中将编排层区分为"orchestrator"（协调器）和"subagent"（执行代理）两个角色，明确指出协调层的职责是任务分解与上下文管理，而非替代模型推理。同期，OpenAI 在 Assistants API 中引入的"Tool Call"机制，也体现了由模型自主决定调用时机的设计理念，而非框架强制路由。这些主流厂商的架构选择，在某种程度上印证了"offering"模式正在成为行业共识——框架的价值在于提供结构与边界，而非替模型思考。