Agent 落地的瓶颈在架构，模型只是其中一块

2026年8月24日

AI Agent架构设计开发工具harness

数据源：earendil.com

「用户保留自由与选择权」

「By building a relationship to and using a harness rather than an application published by an AI lab, the user retains freedom and choice.」这是 Earendil 在 2026 年 8 月 20 日发布的架构文章里最核心的一句话。它揭示的问题并非关于某个模型有多强——而是关于谁在掌控 agent 的行为边界。

AI lab 发布的应用天然以自家模型为中心，切换模型代价高昂，用户的可控性从一开始就被锁死在产品设计里。Earendil 的答案是把这层控制权交还出来：用 harness 包裹模型，而不是把模型和应用逻辑绑死在一起。

模型之上，还有一层

Earendil 给 agent 下了一个简洁定义：Agent = Model + Harness。模型本身是 agent 的推理内核，harness 是模型运行的环境与容器——处理上下文注入、工具调用、循环逻辑和跨模型适配。大多数 agent 框架把这四件事混在一起实现，Earendil 则将其拆成四个明确的模块。

这个拆分的目的是可替换性。当 GPT-4o、Claude Sonnet、开源权重模型的 benchmark 差距已经缩小到个位数百分点时，lock-in 到某个模型 API 的风险就从「技术劣势」变成了「业务风险」。

四个模块，各司其职

System prompt 的角色类似新员工入职手册——每次请求都会注入，定义 agent 的身份、边界与默认行为。这一层由 harness 管理，意味着同一个 system prompt 可以在不同模型上运行，行为保持一致。

Tools 是模型可调用的代码能力。harness 负责向模型描述工具的签名和用法，也负责实际执行。这里的关键分工在于：模型决定「调什么」，harness 决定「怎么调」，两者解耦后，工具集的扩展和模型的迭代可以独立进行。

Agentic loop 是让 agent 区别于单次问答的核心机制——模型根据上一步的执行结果自主判断下一步，形成循环。loop 的逻辑由 harness 维护，从而使同一套 loop 逻辑可以搭配不同的推理内核，调试和优化 loop 行为时也不需要动模型。

Translation layer 是可替换性的技术基础。同一个 harness 通过这一层可以将调用路由到 Anthropic、OpenAI 或本地开源权重模型，API 差异在这里被吸收掉。这一层的存在，使得「换模型」从一个工程项目降格为一个配置选项。

开源生态已经跑通

Earendil 的论点有实际落地案例支撑。Pi（一个开源终端 coding harness）用户已分享超过 5,000 个 extensions，说明围绕 harness 抽象层的生态构建是可行的——开发者愿意在这一层之上创作和共享，而不是在某个具体 app 内部定制。

Pi 之外，OpenClaw、OpenCode、Hermes、Lefos（邮件交互场景）是基于同一 harness 概念构建的不同产品。这些产品覆盖编程助手、通用对话、邮件工作流等场景，共用 harness 架构而非共用模型——这是「harness 而非应用」这一范式的实际落地形态。社区中也存在不同声音：有人认为 5,000 个 extensions 的质量参差，生态成熟度仍需观察；也有人指出 translation layer 在处理模型间 function calling 差异时仍存在边缘问题，标准化程度不及预期。

四个接口的标准化仍是难题

harness 架构面临的核心挑战是接口定义。System prompt 格式、tool schema 规范、loop 状态机的信号设计，这些接口一旦定义得不好，模块的可替换性就是空谈。从目前公开的实现来看，这一层的标准化程度仍存在不确定性，各 harness 实现之间的互操作性尚未达到「生态级」的统一。

另一个现实问题是调试复杂性。当 agent 行为出问题时，问题可能出在任意一层：system prompt 的指令冲突、tool 的返回格式错误、loop 的终止条件设计，或是 translation layer 的适配缺陷。模块化降低了单层的耦合，但提高了跨层调试的认知成本——这是架构分层始终要面对的权衡。