转载说明：本文译自 Tony Kipkemboi 于 2026-03-09 发布在 X 的文章 https://x.com/i/status/2031068470922670471。由于 X 镜像提取中个别实体名丢失，正文对照作者的 LinkedIn 同文版本做了补全校对：https://www.linkedin.com/pulse/difference-between-agent-harnesses-frameworks-tony-kipkemboi-bnpxf/。Agent Harness 与 Agent Framework 的区别 文章配图 如果你最近老听到有人把 “agent framework” 和 “agent harness” 挂在嘴边，却一直分不清两者有什么区别，那这篇就是写给你的。它们听起来像是可以互换的词，但其实不是。我曾在 CrewAI 工作，而它本身就是一个 agent framework，所以我大致知道这条边界画在哪里。 Agent framework 和 agent harness 处在同一条“预设程度”光谱的不同位置。对正在构建 agent 的人来说，搞清楚它们分别处在哪一端很重要，因为这会决定哪些事情由你负责，哪些事情由工具替你处理。 如果把 agent 开发放在一条线上，最左边是完全没有抽象层的原始代码：你直接调用 API、自己管理状态、从零搭每一个组件。灵活性最高，责任也全部在你手里。 Agent framework 位于中间地带。它会给你结构和抽象，但你仍然要自己做很多决定。你要选择 memory system、配置 tools、定义 orchestration logic。Framework 对这些部件如何连接有自己的看法，但它依然是模块化的，你可以替换组件。 Agent harness 位于最右侧。它的预设程度最高。几乎所有东西都已经内建好了。你填上 API key，也许再接几个工具，它就能跑起来。Memory、context management、agent loop、safety checks，这些都已经替你决定好了。 Framework 给你的是一套“构建 agent 的抽象”。你定义 roles、tasks、tools，指定 agent 之间如何协作，是顺序执行还是层级执行。Framework 替你处理底层 plumbing，比如调用 LLM、路由工具输出、管理执行循环。但架构层面的决定仍然由你来做。 Framework 对“构件应该长什么样”也是有预设的。它有 memory abstraction、tool interface、task structure。但这些部分都可以替换。如果你不喜欢默认的 memory implementation，可以自己换掉；如果你想用别的 LLM provider，也可以自己配置。Framework 提供的是标准接口，但系统仍然是你自己组装出来的。 这种可替换性正是重点。Framework 是为那些“想自己构建 agent”的人准备的，而不只是给“想直接使用 agent”的人。它默认你会理解各个部件之间如何配合，因为最终决定使用哪些部件的人就是你。 Harness 不会把构件交给你，它直接交给你一个完整系统。 最近最典型的例子就是 OpenClaw。几周前它在圈子里迅速走红。它就是一个 harness：你把它下载下来，填上 API key，立刻就能得到一个可以在 WhatsApp、Telegram 以及其他平台上聊天的 agent。Memory 已经处理好了，context management 也处理好了，agent loop 也处理好了。Tool calling、permissions、state persistence，全都是内置的。 你不会去配置 memory system，也不会决定 tools 要怎么注册，更不会设计 agent 在出错后怎样恢复。这些决定早就由 harness 的作者替你做完了。你的工作只是把任务交给它，然后让它跑。 这就是权衡所在。你得到的是“马上就能工作”的系统，但代价是你不能轻易改动它的内部实现。Harness 对几乎所有事情都有自己的判断，而一旦你选择使用它，就等于接受了这些判断。 这条光谱之所以重要，是因为它对应的是不同类型的问题。 如果你在做原型、实验，或者要构建高度定制的东西，那你需要 framework。你需要更换组件、测试不同方案、掌控细节。Framework 给你结构，但不会把你锁死。 如果你需要的是一个现在就能稳定工作的系统，用来解决一个非常明确的 use case，那你需要 harness。你是在用控制权换速度。Harness 已经把最难的工程问题提前解决了：context manageme…