Agent 不需要框架，它需要身体：为什么我越来越相信 Harness，而不是 LangChain

我越来越明确地相信一件事：

Agent 开发真正需要的不是框架，而是 harness。

这里说的“框架”，指的是那类试图把 Agent 工作流整体框架化、状态机化、编排平台化的东西，比如 LangChain、LangGraph、AutoGen 一类。它们当然不是一无是处，但如果问题是“我该如何构建真正可控、可调试、可扩展的 Agent 系统”，那么我的答案已经越来越偏向另一边：

少一点框架，多一点身体。

我非常赞成 Anthropic 在《Building effective agents》里的判断。他们明确建议开发者先直接使用 LLM API，因为很多模式其实几行代码就能实现；同时也提醒，框架往往会增加额外抽象层，把底层 prompt 与 response 遮蔽起来，最后让调试变得更难。

我也同样赞成 OpenAI 最近一系列关于 Codex 的文章里表达出来的方向：

• Agent 的核心不是“神秘智能体框架”，而是那条清晰的 harness / agent loop
• 工具、线程、权限、事件流、状态恢复、客户端协议，都应该围绕这条 loop 组织
• 真正强的系统，不是抽象层最多的系统，而是让模型、工具、上下文和验证闭环尽可能直接可见的系统

这不只是 coding agent 的问题。
我觉得它几乎是在审问整个 agent 生态：

我们到底需要框架，还是需要去框架化？

我现在越来越倾向后者。
不是因为“框架不好”，而是因为大多数 Agent 问题，最终都不是框架问题，而是身体问题。

框架真正提供了什么

先说清楚一点：我不是在喊“所有框架都没用”。

Agent 框架确实能提供一些立刻可见的便利：

• 帮你封装模型调用
• 帮你定义工具
• 帮你串联多轮调用
• 帮你画出 workflow / state graph
• 帮你快速把 demo 跑起来

问题在于，这些便利很容易让人误以为：
Agent 的核心是编排图。

但真实世界里，Agent 的核心通常不是图，而是这一串非常朴素、也非常残酷的问题：

• 这轮 prompt 到底长什么样？
• 模型为什么决定调这个 tool，而不是那个？
• tool result 是怎么回流进下一轮上下文的？
• 权限是在什么层拦截的？
• 多 agent 到底是显式委派，还是隐式嵌套？
• 会话状态怎么保存、压缩、切换、恢复？
• 哪些知识是 repo-local artifact，哪些只是聊天废话？
• 出错时我到底应该看哪里？

一旦你真的开始做长任务、做多工具、做多 Agent、做 MCP、做技能系统、做 RAG、做权限审批，你就会发现：

你迟早要回到最底下那条 harness loop。

框架只能帮你晚一点面对它，不能替你消灭它。

为什么我越来越不相信“框架化 Agent”

1. 抽象层越厚，真实系统越难看清

Anthropic 说得很对：框架经常会制造额外的抽象层，让底层 prompt 和 response 变得更难观察。

这件事在 Agent 世界里尤其致命。

因为普通应用开发里，抽象层带来的问题大多是“理解成本高一点”；
但 Agent 系统里，抽象层带来的问题往往是：

• 你不知道模型真正收到了什么
• 你不知道 tool schema 是如何被改写的
• 你不知道某次重试是不是框架自动帮你做的
• 你不知道中间 memory / scratchpad / state 是按什么规则注入的
• 你不知道调度器和模型，到底是谁在做决策

最后你看到的是一个“会动的系统”，但看不见它的神经、骨骼和血液循环。

这会让调试变得极其痛苦。

2. Agent 不是状态机应用，它更像带工具的推理循环

很多框架最容易让人走偏的一点，是把 Agent 问题过早理解成“状态图编排问题”。

当然，有些固定流程确实适合状态机。
但只要你做的是开放式任务，尤其是 coding、research、ops、automation 这类任务，系统的核心往往不是“预定义每一步应该去哪”，而是：

让模型在一个清晰、稳定、可控的循环中，自主决定下一步。

OpenAI 在《Unrolling the Codex agent loop》里把这件事拆得很明白：用户输入进来，模型要么直接回答，要么请求 tool call；harness 执行工具；结果回流；然后继续下一轮，直到模型停止调用工具。

这条 loop 才是核心。

不是某个方框连某个方框，
不是某个节点再跳某个节点，
而是：

input
-> inference
-> tool call
-> tool result
-> next inference
-> ...
-> final answer

如果这一层是清楚的，那上面可以长出很多能力。
如果这一层本身是糊的，那上面堆再多 workflow builder，也只是“更复杂地糊”。

3. 多 Agent 不是更大的框架，而是更好的委派

我对 multi-agent 这件事的看法，也越来越反框架化。

很多人一说多 Agent，就开始想：

• 要不要上专门的 multi-agent framework
• 要不要做大而全的 agent router
• 要不要画出复杂协作状态图

但在我最近自己的实践里，更有效的路径反而很简单：

把“委派”当成一个 tool。

模型在主 loop 里决定：

• 这件事自己做
• 还是调用 delegate，把任务交给一个子 Agent

这其实比“框架式多 Agent 编排”自然得多，因为它保留了最重要的东西：

• 主 Agent 依然在控制 loop
• 子 Agent 只是能力扩展，不是另一个神秘系统
• 委派是显式的、可记录的、可审计的
• 失败、重试、回传都还是 harness 内部的一部分

Anthropic 讲 subagents 的时候，本质上也是这个方向：不是把世界变成一张巨大工作流图，而是让主 Agent 在需要时，把任务交给有独立上下文窗口和工具权限的专业子角色。

这不是“更多框架”，而是“更好的身体组织”。

4. 真正重要的不是框架能力，而是 legibility

OpenAI 最近几篇文章里，我最认同的一个词是：legibility。

他们反复强调，Agent 是否有效，很大程度取决于系统对 Agent 是否“可读”。

代码仓库、文档、日志、UI、指标、线程状态、工具接口，这些东西是不是对 Agent 清晰可见，决定了 Agent 能不能真的完成长任务。

而很多框架式 Agent 方案，恰恰在做相反的事：

• 把 prompt 隐藏进框架内部
• 把 tool call 包在高层封装里
• 把 session state 存在一堆不透明对象里
• 把错误定位变成“去看框架源码吧”

这对“写个 demo”没问题。
但对真正要长期演化的 Agent 系统来说，这种不透明会越来越像技术债。

我越来越相信，Agent 系统的第一原则不是功能多，而是可见、可查、可改、可验证。

而 harness，恰好天然偏向这种透明性。

我最近在怎么做：零框架，不等于没结构

我最近做 Agent 开发，基本是完全零框架化的方向。

这里的“零框架”不是说我什么都裸写，而是：

不把控制权交给一个外部 Agent 框架。

我的做法更接近这样一套统一心智模型：

所有 Phase 统一基于 harness 架构，零框架依赖。

• RAG = tools/rag_search.js 注册到 registry，模型自己决定何时搜索文档
• Agent = harness.run() 的扩展 可以是 chain、parallel、orchestrated，但不是 LangGraph 状态机
• Multi-Agent = tools/delegate.js 模型通过 tool call 委派子 Agent
• 代码解释器 = tools/code_interpreter.js
• MCP = tools/mcp_bridge.js MCP Server 的 tools 自动注入 registry
• Skills 是 repo-local 的能力文档和规则注入，而不是一个框架里的隐藏黑箱
• Prompt 就是显式 artifact，不藏在抽象层底下

一句话总结就是：

一切都是 registry.add()，一切都在 harness 的 while loop 里。

这套做法为什么让我越来越舒服？
因为它把系统重新压回到了几个极其清楚的原语上：

• model
• tools
• registry
• thread / state
• loop
• approval
• artifact

一旦原语清楚了，很多看上去复杂的东西就会自动降维。

RAG 不是一个系统，它首先只是一个工具

很多 Agent 框架喜欢把 RAG 单独做成一个“能力层”。

但在 harness 思路里，RAG 往往根本不需要拥有那么重的地位。

它完全可以只是一个 tool：

• 模型判断是否缺文档上下文
• 如果缺，就调用 rag_search
• 返回检索结果
• 结果进入下一轮推理

这件事不需要特殊神学。
它只是“工具使用”的一个具体实例。

当你用这种视角看 RAG，会发现很多原来被说得很重的系统设计，其实都能退回到简单原语：

retrieval 只是 tool use，关键在于 tool interface 和 result injection 是否清楚。

MCP 也不是另一个宇宙，它只是工具入口标准

我对 MCP 的理解也越来越接近这个方向。

MCP 很重要，但它重要的地方，不是让你再引入一整套新的抽象宇宙。

它真正重要的地方，是给工具生态一个统一入口。

如果你的 harness 本身已经有：

• tool registry
• tool schema
• tool call execution
• approval / permission
• tool result 回流机制

那么 MCP 最自然的位置，就是 bridge：

MCP server tools
-> mcp_bridge
-> registry.add(...)
-> harness loop

这时 MCP 不是框架核心，
它只是把“外部工具”接到“内部身体”的接口。

我觉得这是非常健康的关系。

因为一旦 MCP 反过来主导你的整个 Agent 架构，你很容易开始围绕协议本身设计系统，而不是围绕任务闭环设计系统。

Skills、Prompt、Memory，本质上都应该是 Harness 的器官

我现在越来越不喜欢把 Skills、Prompt、Memory 看成几个彼此独立的大系统。

更准确地说，它们都应该是 harness 里的器官。

Prompt

Prompt 不是魔法。
它应该是显式的、可读的、可版本化的 artifact。

Skills

Skills 不是“框架特性”。
它更像 repo-local 的能力包、规则包、工作流文档包，让 Agent 在需要时获得更强的先验和更低的错误率。

Memory

Memory 也不应该是另一个神秘黑箱。
它本质上是：

• 哪些状态要跨会话保留
• 哪些观察值得结构化存储
• 哪些决策应该在下一次 loop 里变成可用上下文

你把这些东西都放回 harness 视角里看，系统会突然变得非常统一。

不再是十几个名词打架，
而是一具身体里不同器官在协同工作。

为什么我说：Agent 不需要枷锁，它需要身体

我现在最强烈的感受是，很多所谓 Agent 框架，其实更像“枷锁”。

它们的问题不在于不能用，
而在于它们常常在太早的时候，替你决定了这些事情：

• 任务应该怎么流动
• 状态应该怎么表达
• 多 Agent 应该怎么协作
• 工具应该怎么封装
• memory 应该怎么注入
• prompt 应该怎么被框架拼装

而这些恰恰是 Agent 系统里最应该由你自己掌握的部分。

因为它们不是样板代码问题，
它们是系统哲学问题。

你到底相信：

• Agent 是 workflow graph 上的节点消费者
• 还是一个在循环里做决策、调用器官、推进任务的“具身系统”？

我的答案越来越明确：

Agent 不是一个需要被框架预定义完毕的流程图对象。
Agent 是一个需要身体的系统。

这个身体包括：

• 眼睛：RAG、搜索、UI、日志、指标
• 手：shell、file edit、browser、MCP tools
• 记忆：session、artifacts、structured observations
• 神经系统：prompt、skills、rules、approvals
• 循环系统：harness 的 while loop

有了身体，Agent 才能真正行动。
没有身体，再多框架也只是把一个“会说话的脑袋”包得更复杂。

我并不反对框架，但我反对先把自己交给框架

这篇文章不是在鼓吹“所有人都该从零造轮子”。

如果你只是做一个小型 demo，
如果你只是想快速验证某个 workflow，
如果你已经非常理解某个框架的底层行为，
那用框架没有问题。

但我的立场是：

不要在还没理解 Agent 的身体之前，就先把自己交给框架。

Anthropic 建议开发者先直接用 API。
OpenAI 则在不断把注意力拉回 harness、agent loop、thread、tool、protocol、legibility。

我觉得这不是巧合。
这是同一条路线的两个表达方式：

真正成熟的 Agent 系统，最后一定会回到原语，回到 loop，回到 harness。

框架也许能帮你起步，
但 harness 才决定你能走多远。

结语

如果今天有人问我：

“Agent 开发到底应该继续框架化，还是去框架化？”

我的答案会是：

不是不要结构，而是不要把结构错交给框架。

我们真正需要的，不是一个越来越厚、越来越神秘、越来越不可调试的 Agent 框架宇宙。
我们真正需要的是一套清晰、透明、可组合、可验证、可演化的 harness。

RAG 也好，MCP 也好，Skills 也好，Subagents 也好，Prompt 也好，Memory 也好，最后都应该回到同一个事实：

它们不是新的神。
它们只是身体的一部分。

所以我现在越来越愿意用一句话来概括我的立场：

Agent 不需要枷锁，它需要身体。

参考资料

• Anthropic: Building effective agents
• OpenAI: Unrolling the Codex agent loop
• OpenAI: Harness engineering: leveraging Codex in an agent-first world
• OpenAI: Unlocking the Codex harness: how we built the App Server