假设现在有一个 Agent 接到任务，要修改支付模块，补上测试，再把结果交给人审查。
这句话听着很简单。Agent 开始动手以后，问题一下子就多了。它得先找到相关文件，弄清项目规则，再决定要不要把检索交给别的 Agent。等它运行 Shell、访问网络，问题又变成了谁来划边界，出了错怎样还原过程。
Claude Code、Codex 和 DeepSeek Harness 都在回答这些问题。把三家的官方文档逐项对在一起，七个常见能力确实都能找到对应机制。表格大概会长成这样。
| 能力 | Claude Code | Codex | DeepSeek Harness |
|---|---|---|---|
| 模型 | 使用 Claude 系列，Subagent 可单独选择模型 | 按任务选择 Codex 模型，Subagent 可独立配置 | 通过 LLM Adapter 接入和替换模型 |
| 工具 | 内置文件、Shell 和搜索工具，可用 MCP 扩展 | 内置执行工具，可用 MCP、App 和 Plugin 扩展 | 工具注册到 ctx.tools，由插件提供实现 |
| 上下文 | CLAUDE.md 和 Rules 常驻，Skill 按需加载 |
AGENTS.md 提供项目规则，Skill 渐进加载 |
从 Session Log 生成模型历史，也可动态注入内容 |
| 会话 | 本地保存，支持恢复、分叉和压缩 | 以 Task 和 Thread 保存工作过程，可继续和分叉 | 使用追加式 Session Log，支持恢复、分叉和回放 |
| 权限 | Allow、Ask、Deny 规则配合 Permission Mode 和 Hook | OS Sandbox 划定边界，Approval Policy 管理越界动作 | 在工具执行前接入审批策略，也能替换 Sandbox 后端 |
| 技能 | SKILL.md ，支持自动匹配和手动调用 |
SKILL.md ，按任务逐步加载完整内容 |
ctx.skills 汇总多个 Provider，再由 Skill 工具加载 |
| 子 Agent | 独立上下文运行，完成后向主会话返回摘要 | 支持生成、分叉、通信和等待多个 Subagent | ctx.subagents 接入不同 Provider，也可以调用 Codex 或 Claude Code |
表里每一格都有内容，但三家的实现层级并不相同。Claude Code 多用工作过程里的约定和扩展来组织能力。Codex 把权限做成执行环境的硬边界。DeepSeek Harness 进一步把能力拆成可替换的 Provider 和插件。
这张表能说明三者都有什么，却仍然解释不了它们为什么长得不一样。差别藏在这些能力由谁控制，以及控制发生在哪一层。
我把三家的文档对在一起看，最在意的差别落在一个很朴素的问题上。面对同一项任务，系统愿意把工程复杂度花在哪里。
Claude Code 把大量复杂度花在 Agent 怎样理解任务、调用经验和组织协作上。Codex 把执行边界做得很重，让 Agent 能在真实计算环境里持续干活。DeepSeek Harness 则继续往下拆，连 Agent Loop 都可以从配置里换掉。
三家的控制权分配由此分开。
Claude Code 先照顾工作过程
先别急着写。还是回到支付模块的任务。
一个 Agent 想把这件事做对，通常要先弄清项目，再动代码。它得知道怎样启动，测试命令怎么跑。哪些目录不能碰，团队怎样处理 API 兼容性，也要提前交代。Claude Code 把这类长期有效的信息放进 CLAUDE.md 和规则文件，需要时才用的方法则放进 Skill。
这两类上下文用法不同。项目约定每次会话都需要，发布流程、Code Review 清单和某套 API 文档只在特定任务里有用。后者做成 Skill，需要时再加载，主会话会轻很多。
任务继续变大，主 Agent 还可以派出 Subagent。一个读支付接口，一个查测试，调用方另外交给第三个。每个 Subagent 有自己的上下文、工具和权限，完成后只把结论送回来。过程被隔开了。Anthropic 的文档也把这一点写得很清楚，主会话只收结果。
Subagent 的工程价值主要在隔离。高噪声的检索和试错留在独立上下文里，主会话只接收后面还会用到的信息，整理成本会低很多。至于产品经理、架构师、程序员这些角色名，它们只是在提示词里分了工，本身不会带来上下文隔离。
模型负责灵活判断以后，总有一些动作不能只靠提醒。代码改完要跑格式化，敏感文件也得拦住。工具留下的执行记录再交给日志。Claude Code 用 Hook 接住这些确定性要求。Hook 会在工具调用和会话启动时运行，也能管住 Subagent 启停与上下文压缩，触发动作由系统保证。
这里已经能看见 Claude Code 的控制分配。模型拿着较多的理解权、规划权和工具选择权，Skill 提供经验，Subagent 分担过程，Hook 守住必须执行的节点。
Claude Code 最值得学的是这套完整的工作系统。模型处理模糊任务，确定性程序在关键节点接管，单独看其中任何一个功能，很难看出它们怎样配合。
Codex 先划清行动范围
支付模块进了 Shell，事情就变了。
Agent 会运行测试、安装依赖，也可能改 Git 状态。再碰到网络访问，它的动作已经有了现实后果。提示词管不住进程，系统级限制必须跟上。
Codex 把 Sandbox 和 Approval 分成两个层次。Sandbox 决定 Agent 在技术上能碰到什么，包含可写目录、网络访问和受保护路径。Approval 决定哪些动作必须停下来等人或策略放行。
这一区分很实用。假如 Agent 只在当前工作区里改文件、跑已有测试，它可以连续完成任务。假如它要访问工作区外的目录或连接网络，审批流程再介入。运行中的 git、包管理器和测试进程也会继承同一套沙箱边界，不会因为工具换了名字就绕出去。
很多 Agent 产品早期会把安全写进 System Prompt，告诉模型谨慎使用命令。那仍是一段要求模型自行遵守的文字。沙箱把限制落到操作系统和执行环境上，即使模型判断错了，进程也只能在允许的范围内活动。
Codex 已经有 Skill、Plugin、MCP 和 Subagent，工作流早就超出了一台安全终端。它的架构气质仍然很清楚。Agent 能做多少事，需要和它受什么边界约束一起设计。
对企业来说，这个问题甚至会盖过模型能力。Agent 做完任务，团队要查得到它用过哪些工具，也要知道哪次动作触发了审批。网络请求被拒绝以后，相关过程还得能够还原。执行轨迹和审批记录就这样进入了 Runtime，日志也开始围绕 Agent 的行为来记。
Codex 给出的启发很直接。Agent 一旦获得行动能力，安全就不能留到产品上线前补。执行权从模型交给工具的那一刻，Sandbox、Approval、Network Policy 和审计就该同时出现。
DeepSeek Harness 连固定中心也愿意拆开
Claude Code 和 Codex 都可以扩展，但它们仍然让人感到有一只明确的 Agent 在工作。
DeepSeek Harness 把问题又往下推了一层。它在开发者预览版里提出 Everything is a plugin。模型适配器、工具、Skill 和会话由插件提供，沙箱与 Agent Loop 也能替换。存储、调度和界面同样放在插件体系里。
底下的 Cordis 负责插件装载、卸载和依赖关系。插件通过共享 Context 提供 Service、事件和可回收的 Effect。工具可以依赖一个文件系统 Service，却不用知道后面接的是本地目录、容器还是远程环境。换掉 Provider，上层工具仍可保持原样。
Loop 也能换。这一点最吸引我。
一个 Coding Agent 可以使用持续调用工具的循环。企业流程可能希望先走固定 Workflow，再在某个节点把判断交给模型。长期运行的 Agent 还会涉及目标、计划、后台任务和恢复机制。如果 Loop 自身也能替换，同一套 Runtime 就有机会组装出不同形态的 Agent。
DeepSeek Harness 还把模型看到的内容写入追加式 Session Log，其中包含系统提示、推理、工具调用、Subagent 调度和上下文注入；恢复、分叉、检索与回放都围绕同一条事件流进行。这里的可组合性已经超过一般插件系统里给稳定核心增加几个扩展点的做法。
自由不便宜。开发者需要理解 Context、Service、Provider、Event、Effect、Bundle 和 Profile 等概念。系统可以替换的部分越多，配置、调试和版本兼容的负担也越大。
如果团队只想把一个 Coding Agent 做好，这份自由未必划算。如果团队要同时承载本地与远程执行、多个模型、不同沙箱和几套 Agent Loop，这些抽象才开始显示价值。
三种系统都在决定哪里必须确定
把三个产品放在一起看，我更愿意用控制权来理解它们。
Claude Code 让模型掌握较多的理解和规划，工具路由也主要由模型决定。Skill 补经验，Subagent 隔离过程，Hook 则固定关键动作。
Codex 允许模型持续行动，同时把执行权放进受约束的环境。Sandbox 负责技术边界，越界动作交给 Approval 和 Policy，人保留最终授权。
到了 DeepSeek Harness，控制机制也成了可组合部件。Loop 和工具可以重新组装，会话、沙箱与调度跟着运行模式变化。Runtime 本身成了设计对象。
单 Agent 和多 Agent 这个维度，经常排不到最前面。一个系统有十个 Agent，如果它们共享同一套无限权限，风险并不会减少。另一个系统只有主 Agent，只要上下文、执行边界和确定性检查处理得好，仍然可以完成很长的任务。
以后再看一个新的 Agent 框架，我会先看模型可以决定到哪一步，程序又会强制执行什么。策略和人在哪些位置介入，也得写清楚。任务失败以后，系统能还原多少过程，往往比它支持多少模型更能说明架构水平。
该用哪一种取决于眼前的问题
做专业 Agent 时，用户最在意任务理解是否准确、上下文是否干净。工具用起来顺不顺，也会直接影响体验。Claude Code 的经验组织方式很值得研究。先把主 Agent 的工作过程做好，再决定哪里需要 Subagent 和 Hook。
Agent 要修改代码、操作数据库，甚至会改变业务状态时，Codex 的路径更重要。先画执行边界，确定凭据怎样管理。网络怎样开放、越界动作由谁批准，也要在提高自主性之前定下来。
至于 Agent 平台，它往往要适配多种模型和工具，执行环境也不止一种。DeepSeek Harness 提供了一种很激进也很完整的参考。采用这条路，就要承担自由组合带来的理解成本，还得考虑它目前仍在开发者预览阶段。
三条路线也在互相吸收。Claude Code 的权限、Hook 和隔离能力越来越细，Codex 已经把 Skill 与 Plugin 纳入扩展体系；DeepSeek Harness 则提供了完整的 Coding Agent 模式，沙箱、Subagent 和 Workflow 也已经在里面。
它们最后也许会靠得很近。好用的 Agent 体验、安全的执行环境和可替换的能力组件，成熟系统大概率都需要，区别会留在产品最先解决什么问题，以及哪一部分被当成长期稳定的中心。
以后再判断一个 Agent 产品，我会先看控制权最后落在哪里。模型能走到哪一步，程序怎样约束它，什么时候必须等人，这几件事会直接决定系统能不能长期工作。