最近 DeepSeek 开源了 DeepSeek Harness。

单看功能清单，它很容易被当成"又一个 Agent 框架"：有模型、有 Tool、有 Skill、有 SubAgent、有上下文管理、有 Sandbox，还有 Web UI。

但这样的理解价值有限。真正值得研究的问题是：

为什么到了 2026 年，DeepSeek、OpenAI、Anthropic 都开始认真建设"模型外面"的这套系统？

一个越来越强的大模型，为什么还需要如此复杂的一层软件？

想清楚这个问题，DeepSeek Harness 的代码结构、Codex 的 Agent Loop、Claude Code 的 Hooks / Skills / Subagents，才会串成一条完整的技术演进路线。

一、从一次函数调用，到 Agent Loop

最早的大模型应用非常简单：用户给一段 Prompt，模型返回一段回答。

f(prompt) → response

本质上就是一次函数调用。这种架构适合问答、摘要、翻译、文案生成、信息提取——但它有一个天然限制：模型只能"想"和"说"，无法真正改变外部世界。

于是出现了 Tool Calling。

比如模型发现"我需要知道昆明今天的天气"，就会产生一次 get_weather("昆明") 调用。程序负责执行工具，把结果交还模型，模型继续作答。

这一刻，Agent 最原始的形态出现了：理解 → 行动 → 观察 → 再理解。也就是经典的 Think → Act → Observe 循环。OpenAI 在解释 Codex 架构时，同样把 Agent Loop 描述为连接用户、模型和工具的核心运行机制。

图 1 ｜ Agent Loop：思考 → 行动 → 观察，循环直到任务完成

把所有花哨概念拿掉，一个 Agent 最基本的只需要五样东西：目标（Goal）、大脑（LLM）、行动（Tool）、观察（Observation），再加上一个终止条件。写成伪代码就是：

while 任务未完成:
    理解当前状态
    决定下一步
    执行动作
    获取结果

从这里能得出全文最重要的一句判断：

Agent 的智能主要来自模型，Agent 的可靠运行主要来自 Harness。
这两件事，需要分开理解。

二、Harness 到底是什么

把一个 Agent 想象成一个非常聪明的人：模型是他的大脑。但一个真正在干活的人，还需要眼睛和耳朵、双手、电脑、记事本、过往经验、同事、办公环境、规章制度、工作日志。

把这些一一映射到 Agent 系统，就得到了 Harness 的全貌：

图 2 ｜ 人类工作系统与 Agent 系统的对应关系

所以 Harness 可以用一句话定义：

Harness 是围绕模型建立的一整套执行环境，
负责让模型能够持续、安全、有状态地完成真实任务。

模型负责聪明，Harness 负责让这份聪明落地。

三、模型越强，Harness 为什么反而越重要

乍看有些反直觉：模型越聪明，软件逻辑不应该越来越少吗？

这个判断只对了一半。

模型越聪明，确实能省掉大量人写的判断规则。以前要写一长串 if A ... elif B ... elif C ...，现在一句"请结合当前情况决定下一步"就够了。

但另一个变化同时发生：

模型能力越强
  → 能承担的任务越复杂
  → 能调用的能力越多
  → 执行时间越来越长
  → 对真实世界的影响越来越大
  → 运行时治理越来越重要

于是，软件复杂度开始从"业务判断逻辑"迁移到"Agent Runtime"：

图 3 ｜ 复杂度迁移：从人写死的业务逻辑，到模型驱动的动态决策

过去，工程师提前规定每一步必须干什么；现在，越来越多系统允许模型根据当前状态自己决定下一步。系统设计的重点随之改变——以前的关键问题是"如何规定每一步"，以后的关键问题变成：

模型能看见什么？能做什么？在什么边界内做？

做错了怎么办？如何知道它做过什么？如何中断它？如何恢复？

什么时候需要人介入？

这才是 Agent Harness 真正解决的问题。

四、Claude Code 与 Codex：早就在走这条路

很多人用完 Claude Code 会产生一种感觉：Claude 模型是不是突然变强了很多？

模型当然重要，但 Coding Agent 的能力其实可以拆成三块：LLM × Context × Tools，跑在同一个 Agent Loop 上。

Claude Code 官方把核心工作过程概括为三个阶段：Gather Context → Take Action → Verify Results，循环往复。它拥有文件操作、搜索、Shell、Web、代码智能等工具，并在每次行动的结果之上继续决策。Anthropic 的 Agent SDK 说得更直接：它运行的就是 Claude Code 所使用的那个自主 Agent Loop——Prompt → Claude → Tool Call → Tool Result → Claude → ……同时在外围加上权限、Hooks、上下文压缩（Compaction）、Session 和 Subagent。

所以 Claude Code 的核心价值，不能简单归因于"Claude + Bash"。它已经是一套成熟的 Agent Runtime。

Codex 也在走同一条路。OpenAI 把 Harness 描述为提供核心 Agent Loop 和执行逻辑的系统，支撑 Codex CLI、Codex Cloud 和 VS Code 等不同产品形态。观察它的工程体系，会发现越来越多东西进入这一层：AGENTS.md、Skills、Sandbox、Approval、MCP、Hooks、Context 管理、Compaction、Multi-Agent。

Codex 仓库甚至明确了 Context 工程原则：上下文必须有界、避免频繁变化导致缓存失效、注入项需要硬上限。

这透露出一个重要变化：

Agent 的竞争，正在从单纯的模型竞争，
扩大为 Model + Harness 的系统竞争。

五、DeepSeek Harness：Everything is a Plugin

有了前面的铺垫，再看 DeepSeek Harness 就清晰多了。

它没有重新发明 Agent，而是提出了一种关于"Harness 应该如何组织"的强烈观点：

Everything is a Plugin。

传统框架的形态是 Core + Extensions：中心是一个不可动的 Agent Core（Agent Loop、Memory、Tool Manager、Prompt 都在里面），外围挂一些插件。而 DeepSeek Harness 基于 Cordis 构建，把 LLM Adapter、Tool Registry、Session Log——连 Agent Loop 本身——全部做成了 Plugin。

图 4 ｜ 两种 Runtime 组织方式：特权核心 vs 全插件化

官方架构文档里有句很硬的话：There is no privileged core to patch——没有需要打补丁的特权核心。所有扩展行为，都通过挂载新的 Plugin 和事件扩展点完成。

为什么要做得这么激进？

因为 Agent 的能力边界很难提前预测。

今天需要 Tool、Skill、Memory，明天可能需要 Computer Use、Browser、长期目标、Agent Team、人工审批、远程沙箱、后台任务、知识图谱……如果 Runtime 写成一个巨大的 AgentManager，每出现一种新能力就要改一次核心，很快就会膨胀失控。DeepSeek Harness 给出的答案是：Agent 是一组运行时能力的组合结果。

但这里必须保持审慎

"Everything is a Plugin"听起来优雅，可软件架构有个长期存在的规律：抽象是有成本的。极端模块化会带来新的复杂度——调用链变长、调试变难、运行时行为更隐式、学习曲线更陡。第一次读它的源码，并不轻松。

同时还要警惕：框架复杂度可能超过业务复杂度。对于"用户 → LLM → 查数据库 → 回答"这样的场景，一个 LLM ↔ Tools 的简单循环完全够用，引入完整 Harness 属于杀鸡用牛刀。

更实用的思考框架，是一条复杂度谱系：

图 5 ｜ Agent 复杂度谱系：层级越高 ≠ 架构越好

从 Level 1 的单次 LLM 调用，到 Level 6 的多 Agent 分布式运行时，每一层解决不同的问题。设计 Agent 系统时，真正重要的问题不是"怎么上到最高层"，而是：

当前场景需要走到哪一层？
层级越高，并不天然代表架构越好。

六、三种哲学，一个共识

把三个系统放在一起看，会发现它们代表三种不同的哲学。

系统	哲学，一句话	更值得关注的设计点
DeepSeek Harness	打造可以组装各种 Agent 的 Runtime	可组合性
Claude Code	打造越来越强的单个 Agent	使用体验与扩展生态
Codex	从 Coding Agent 走向通用 Runtime	安全执行
LangGraph	显式状态与流程编排	确定性控制

Claude Code 的哲学是"增强一个强大的 Agent"。中心始终是 Claude Agent 这个明确的主体，CLAUDE.md、Skills、Tools、MCP、Hooks、Subagents、Plugins 全都在增强它。Anthropic 官方把这些能力放在基础 Agent Loop 之上：Skills 提供可复用知识，MCP 连接外部服务，Subagents 用独立上下文执行任务，Hooks 在生命周期事件里插入确定性逻辑，Plugins 负责打包分发。

DeepSeek Harness 的哲学是"Runtime 本身可重组"。连 Agent Loop 都只是一个可替换实现——官方文档明确区分了稳定的 Agent 接口和默认的 Agent Loop 实现。它想打造的，是一个可以组装各种 Agent 的 Runtime。

Codex 处在一个很有意思的中间位置。一方面有明确的 Agent Loop，另一方面不断吸收 Sandbox、Approvals、Skills、Hooks、Multi-Agent、Memory、Remote Execution，正在从 Coding Agent 演进为 General Agent Runtime。

但如果把产品名字全部拿掉，会发现它们正在收敛到同一个结构：

图 6 ｜ 收敛中的共识：Agent 时代的"应用运行时标准形态"

这张图可能比任何一个具体框架都重要。因为它已经开始像Agent 时代的应用运行时标准形态：Context、Tools、Skills 喂给 Agent Loop；Session、Permission、Hooks 负责状态与治理；往下是执行环境；旁边是 SubAgents。

七、Agent 架构的五个演进方向

方向一: 模型和 Harness 会越来越分离

未来模型类似 CPU，Harness 更接近操作系统。同一个 Harness 可以切换 DeepSeek、Claude、GPT、Gemini，而模型越来越依赖 Harness 获得真实世界能力。长期看，Model 和 Agent Runtime 会成为两个相对独立的技术层。

方向二: Agent 会越来越"长时间运行"

早期 Agent 跑几秒，Coding Agent 跑几十分钟，未来企业级 Agent 可能跑数小时、数天，甚至持续运行——AI 运维工程师、AI 项目经理、AI 客户经理。这时核心问题就从"回答得好不好"扩展为：状态如何保存、任务如何恢复、失败如何重试、人何时介入、如何处理外部事件。这也是 Session、Event Log、Job、Goal、Schedule 这些传统软件概念，重新大量进入 Agent Runtime 的原因。

方向三: Context Engineering 成为核心基础设施

Agent 的智能上限，很大程度取决于模型知道什么。Context 会从"拼 Prompt"升级成完整系统：System Instruction、对话、文件、Memory、Skill、RAG、Tool Result、用户画像、当前目标……Harness 必须决定：什么信息进入、何时进入、以什么格式、保留多久、何时压缩、何时丢弃。Codex 的上下文硬约束和 Claude Code 的自动 Compaction 都说明——Context 已经成为独立的工程问题。

方向四: 控制权成为架构真正的核心

理解权、规划权、路由权、执行权、终止权——这五种控制权可以在 LLM、程序、规则、人之间分配。成熟的 Agent 系统很少把所有控制权都交给模型：理解与规划给 LLM，高风险审批给人，权限判断给 Policy，命令执行给 Runtime，超时终止给程序。Claude Code 和 Codex 越来越复杂的权限与 Sandbox 体系，正是在回答这个问题。

方向五: 多 Agent 的价值会被重新定义

未来有价值的 Multi-Agent，不是"Agent A 和 Agent B 聊天"，而是上下文隔离、能力隔离、权限隔离、并行执行、专业化分工。Claude Code 的 Subagent 是最好的例子：一个 Subagent 拥有自己的 Context Window、System Prompt、Tools 和 Permissions，完成后只把结果交还主 Agent。SubAgent 的核心价值其实是上下文隔离——这比"模拟一个专家角色"重要得多。

八学习 DeepSeek Harness 的正确姿势

到这里，才能比较客观地评价 DeepSeek Harness。它目前最值得学习的有四点：

1. 把 Agent 看作 Runtime 问题。认真解决 Session、Context、Execution、Permission、Sandbox、SubAgent、持久化，而不停留在 Prompt + Tools。
2. 极强的能力解耦意识。Service Definition、Provider、Consumer 的能力接缝设计，对大型 Agent 平台如何避免能力耦合很有参考价值。
3. Event Log 作为状态基础。Session 被设计成 append-only 事件日志，模型消息从日志投影得到，Fork、Resume、Replay、遥测都围绕它建立。
4. Agent Loop 本身可替换。对未来探索 Workflow Agent、Planning Agent、长期运行 Agent 很有启发。

它同样有明显风险：目前仍是 Developer Preview，官方明确提示后续存在破坏性变更。插件化是否过度、Cordis 学习成本是否值得、复杂事件链能否保持可调试性、生产环境相对更简单 Runtime 的收益究竟多大——这些问题，都不能因为架构漂亮就提前下结论。

所以，学它的目标不该是"学会 DeepSeek Harness"，而是借它看清 Agent Runtime 正在变成什么。最终，你应该形成一张自己的认知地图：

图 7 ｜ Agent 架构认知地图：智能 × 运行时 × 治理

有了这张地图，面对任何 Agent 框架，都可以用同一套问题去审视：

它如何管理 Context？如何组织 Agent Loop？如何定义 Tool？

如何保存状态、处理中断和恢复？如何做权限和沙箱隔离？

SubAgent 怎么用？如何做可观测和审计？

哪些控制权交给模型？哪些保留给程序和人？

做到这一点之后，无论下一个流行的是 DeepSeek Harness、Claude Agent SDK、Codex、LangGraph 还是 OpenHands，你看到的都会是同一句话：

同一个 Agent 架构问题的不同解法。

这才是研究这些开源项目，最有价值的地方。