AI 模型提供推理与生成能力；Agent harness 提供指令、上下文、工具、权限、状态和执行循环，把这种能力变成实际工作。
这就是 Agent harness vs model 的简短答案。它也解释了为什么选择“最好的模型”不会自动带来最好的编程工作流，以及为什么工具失效、文件缺失或权限请求出错时，单纯更换模型往往解决不了问题。
Agent.Space 的可用 Agent 包括 Codex、Claude Code、OpenCode 与 DeepSeek Harness 等产品。它们不只是模型名称，而是编程 Agent 产品或 harness，负责组织一个或多个兼容模型如何与真实开发环境交互。GPT、Claude、Grok 与 DeepSeek 的具体模型版本属于另一层；Agent.Space 的工作方式则说明项目文件、Session 与交接如何围绕这些层级协作。
分清这两层，可以让你分别做出两个决定：工作应该怎样执行，以及由哪个模型在系统内部承担推理。
一句话分清 Agent harness 与模型
可以使用下面的工作定义：
模型根据提供的上下文生成回复或工具请求；harness 决定周围的上下文、工具、权限、状态与执行过程。
现代模型可以生成结构化 Tool Call 请求，但请求不等于命令已经执行。仍然需要某个系统暴露工具、校验参数、在必要时请求权限、在环境中运行工具、把结果返回给模型，并决定哪些信息进入下一次模型调用。这个周围系统就是 harness。
DeepSeek 将两者关系概括为“Agent = Model + Harness”。只要把 harness 理解为完整运行循环，而不只是薄薄一层 UI，这个公式就很有用。
AI 编程任务背后的四个层级
理解 Coding Agent 最清楚的方法，是把四个层级拆开。不同产品的边界会有所不同；本文把“harness”定义为编排层，把“Workspace/Runtime”定义为执行边界，即使某个产品同时打包了两者。
箭头不表示某层比另一层更重要，而是说明一个任务成功依赖多份合同同时工作。
Provider 也不等于模型。Provider 是访问、Hosting，通常还包括计费的路径；模型则是通过这条路径调用的具体能力。
如果你是在选择 Agent 使用的 Provider API，而不是完整 harness，可以从状态、工具、流式事件、用量和迁移层面比较 Coding Agent 使用的 OpenAI 与 Anthropic API 合同。
模型负责什么
模型处理给定上下文并生成下一次回复。依据模型能力和外围 API，回复可能包含文本、代码、结构化数据或工具调用请求。
模型选择会实际影响：
- 复杂问题的推理质量；
- 代码生成与审查质量；
- 指令遵循；
- 支持的输入与输出模态；
- 上下文上限，以及信息被利用的质量；
- 延迟与成本特征，这也受 Provider 和调用模式影响；
- 所提出 Tool Call 的质量。
模型不会独立决定哪些仓库文件对它可见、Shell 命令是否获准、浏览器是否存在，或进程停止后如何恢复状态。它只能使用外围系统提供的界面与上下文。
因此，即使模型更强，只要相关文件没有进入上下文、必要工具不可用或执行环境缺少依赖，任务仍会失败。
Harness 负责什么
Agent harness 把模型输出连接到真实工作流。Anthropic 的工程说明把 harness 描述为处理输入、编排 Tool Call 并返回结果的系统，因此评估 Agent 实际上是在评估模型与 harness 的组合。OpenAI 对 Codex harness 的说明也涵盖持久 Thread、配置与认证、工具执行、Sandbox、MCP 与 Skills。
Codex 在同一 harness 内提供不止一种集成入口。单独的指南可以帮助你比较 Codex SDK、app-server 与 exec，而不会把三种接口误当成不同模型。
Coding harness 可能负责：
- 组装系统指令与项目上下文；
- 决定哪些文件或摘要进入模型请求；
- 暴露 Shell、Editor、Browser、MCP 或其他工具；
- 执行审批与权限边界；
- 执行 Tool Call 并返回观察结果；
- 跟踪 Turn、Plan 与任务状态；
- 压缩长上下文；
- 重试或停止工作循环；
- 在展示结果前运行验证；
- 把 Session 连接到 Workspace 或 Runtime。
并非所有 harness 都实现每一项，具体行为也会随版本或部署变化。“有工具”不等于“拥有全部工具”，“支持某模型”也不表示所有模型与 Provider 组合都有效。
ACP 连接客户端与 Coding Agent，MCP 则把 AI 应用连接到外部工具和上下文；ACP 与 MCP 的对比说明两者为何可以同时围绕同一个 Harness 工作，却不能互换。
模型、Harness、Agent 与 Workspace 各不相同
行业中常常宽泛使用“Agent”一词。实际评估产品时，最好保留四个独立标签：
- 模型： 推理与生成引擎。
- Harness： 编排模型、上下文、工具、权限与循环的软件。
- Agent： 模型在 harness 内带着目标和工具运行时形成的组合。
- Workspace/Runtime： 保存项目文件并执行动作的环境。
Workspace 并不是一个更大的 harness。它有自己的责任：算力、文件系统行为、进程生命周期、协作、数据导出与访问控制。本地 harness 可以使用本地 Workspace，托管产品也可以把 harness 连接到托管云端 Workspace。
分开这些层级，可以避免两个常见误区：以为有模型访问权就自动拥有托管开发环境，以及以为云端 Workspace 会自动授予所有上游订阅或模型的访问权。
真实例子：各个名称分别属于哪一层？
人们经常比较的名字，实际上可能位于不同列。下表中的“Codex”指编程 Agent 产品与 harness 入口，不指名称中含有 Codex 的某个具体模型。
这些是类别映射，不是性能排名。每个产品都有自己的入口、权限、工具、状态模型与兼容规则。购买或迁移前，应在对应官方文档中检查最新细节。
如果需要具体例子，可以继续比较 Codex 与 Claude Code，了解 OpenCode 在云端 Workspace 中会改变什么，并查看 DeepSeek Harness 的集成边界。产品事实来自官方 Codex、Claude Code、OpenCode 与 DeepSeek Harness 信源。
为什么同一个模型会在不同 Harness 中表现不同
两个产品即使调用同一个模型，也可能产出明显不同的结果。模型没有改变，但工作条件变了。
指令不同
Harness 会提供不同系统指令、任务模板和约定。一个可能优先规划和审批，另一个可能倾向立即编辑；这会改变模型提出的动作。
上下文组装不同
一个 harness 可能在调用模型前搜索仓库，另一个只提供当前文件或摘要。Session 变长后，不同 Context Compaction 也可能保留不同细节。
工具不同
即使模型能请求 Shell 命令，它仍依赖可用的 Shell、文件系统、Browser、MCP Server 或验证工具。缺少工具首先是 harness 或环境约束，不一定是推理失败。
权限与 Sandbox 规则不同
同一个提议动作可能自动执行、要求审批或被阻止。这些政策同时影响速度与风险。
执行与验证循环不同
一个 harness 可能写完代码就停止，另一个会运行测试、检查失败、修改文件并再次尝试。即使底层模型相同，额外循环也可能改善最终结果。
这不代表 harness 能让所有模型达到相同能力。模型仍然决定推理、语言、模态、速度和成本等重要上限。重点是：观察到的 Agent 质量来自整个系统。
更换产品前，先诊断失败层级
Agent 失败时，应从症状开始，而不是立刻换模型。
这张表只是指出第一个排查位置，不保证诊断结果。复杂失败可能跨越多个层级，例如权限规则可能隐藏上下文，糟糕计划也可能导致工具调用过量。
如何选择 Harness 与模型
按下面顺序评估两者的组合。
1. 从任务开始
先定义工作属于代码生成、全仓库重构、Debug、研究、Review 还是长期工作流。一个孤立小改动和多阶段迁移并不需要相同的 harness 行为。
2. 列出必要工具与权限
明确任务需要的文件系统、Shell、Browser、MCP Server、Credentials、网络访问、审批规则和验证命令。如果某个 harness 无法安全提供必要路径，就先排除它。
3. 决定状态与执行放在哪里
选择本地或托管执行，再分别验证项目持久化、Session 恢复、导出、协作与进程生命周期。不要从模型名推断这些能力。
4. 检查兼容性
使用当前 harness、Provider 与模型的准确兼容列表。某个模型能通过一个 Provider 访问，不代表它一定受每个 Agent 产品支持。
5. 用真实任务比较模型
工作流要求满足后，可以用 Coding Agent 模型选择框架，在相同起始文件、指令、权限与验收检查下比较兼容模型。测量当前任务真正需要的质量，而不是依赖通用排行榜。
6. 比较总运营成本
同时考虑模型用量、harness 或 Workspace 收费、重试次数、人工 Review 时间与失败任务成本。一次请求更便宜，不一定意味着一个验收结果更便宜；这是需要测量的决策指标，不是本文声称的 Benchmark。
Agent.Space 如何把两项选择分开
Agent.Space 的一项核心设计，是在启动 Session 时把 Agent harness 与兼容模型作为不同选择。产品模型因而更明确：先选择工作界面与执行方式，再从该 harness 可用的模型中选择。
当前选择器是兼容关系、名称与路由的最终依据。分开选择不代表可以任意组合 harness 与模型，也不代表能够使用某个上游个人订阅。
实际下一步，是选择符合任务的 Agent，再从当前选择器标记为兼容的模型中选择一个，用包含明确验收检查的边界任务测试这组组合。
核心结论
模型是推理与生成层；Agent harness 决定这种能力如何接收上下文、使用工具、遵循权限、维持状态和执行工作流；Workspace 决定文件与进程在哪里。
选择时要把它们看作一个系统，诊断时则要拆成不同层级。这是理解 Coding Agent 为何出现某种行为，以及接下来究竟该换哪一部分的可靠方法。
准备好后，可以先查看可用 Agents，再用一个边界明确的任务测试一组兼容的 harness 与模型。
FAQ
AI Agent 和 AI 模型是同一个东西吗？
不是。模型提供推理与生成能力；Agent 通常由 harness 协调，把模型和指令、工具、状态、权限及执行过程组合起来。
Coding Agent 和 Agent harness 是同一个东西吗？
产品语言中，两者经常混用。更准确地说，harness 是编排软件；模型在 harness 中带着目标与工具运行时，形成 Agent 系统。
同一个模型在两个 Coding Agent 里会表现不同吗？
会。不同指令、上下文选择、工具、权限、Compaction、执行环境和验证循环都会改变结果。但这并不会抹去模型本身的能力差异。
应该先选模型还是先选 Harness？
先看工作方式、必要工具、权限、Runtime 与持久化需求。选择能安全支持这些要求的 harness，再用真实任务比较兼容模型的质量、速度与成本。
任何模型都能在任何 Harness 中运行吗？
不能。兼容性取决于 harness 版本、Provider 接口、模型能力、模态、Tool Calling 支持与产品集成。应检查当前兼容列表。