AI Agent 的“操作系统”之争：DeepSeek 与 Codex 同月开源 Harness，Agent 运行时正在独立成赛道

开篇：为什么“Agent 的操作系统”突然成了显词

2026 年 8 月到 10 月这三个月，Agent 基础设施层出现了几件方向一致、彼此咬合的事。据一篇 CSDN 生态观察文称，DeepSeek 与 Codex 在同月把各自智能体产品的执行框架推到开源，该文由此判断“Agent 运行时正在独立成赛道”[1]。同期，GitHub 上出现了一批自称为“指挥中心”“多 Agent 编排服务器”的项目：agentpulse 提供自托管的会话仪表盘、编排能力与一个用于程序化 fleet 控制的 MCP server[3]，PowerSpawn 则以“跨模型 Agent 编排 MCP server + 共享黑板”的形态出现[4]。再往前一点，据掘金的行业汇总文称，2026 年 10 月 22 日 Anthropic 将 Agent Skills 的名称、Logo、GitHub 组织和域名移交给 Linux Foundation 下的 Agentic AI Foundation（AAIF），推进厂商中立治理[7]。

三件事分别落在产品形态、编排形态和资产形态上，指向同一个结构性变化：模型之下的执行与编排层，正在从“某个 Agent 框架里的一个模块”，剥离为可以被独立选型、独立治理、独立演进的一层。这层常被称作 harness（执行框架/运行时），也有人直接类比为“Agent 的操作系统”。

本文是基础设施层的生态观察与技术分层解析，不是产品评测，也不做热度排名——本次采集的 36 条来源中所有热度字段均为 0，无法支持任何“热度第一”式结论，本文仅以多源交叉印证与时间密度作为判断依据。另需声明：部分来源的发布日期晚于数据集标注的基准月份，时间线存在异常，本文一律以来源自述日期为准，并对关键日期标注核验状态[1][7]。

一、一个赛道成型的三个标志

1.1 模型层竞争者同月开源各自的 harness

据来源 [1] 的描述，2026 年 8 月，两家在模型层竞争最直接的公司把各自智能体产品的执行框架开源。这件事值得单独拎出来看：过去两年开源竞争的重心是权重、推理优化和评测，而这次被开源的是模型如何被组织起来干活的那一层——循环怎么转、工具怎么调、上下文怎么装、任务怎么中断和恢复。

开源模型解决“聪明程度”的可得性，开源 harness 解决“可控性”的可得性。这与 2026 年 10 月上中旬 GitHub Trending 解读文中反复提到的叙事一致：Hermes Agent、Microsoft Agent Framework、Codex CLI 等框架与 CLI 的更新，把“可控性”推到了台前[2]。

需要特别说明的是，来源 [1] 自身就标注了一处时间线出入：其正文称 release 来自 GitHub 官方 Release（2026-08-19/20），但引用的另一篇文章发布于 2026-10-05，因此 rc.8 的准确发布日期应以 GitHub release 页为准[1]。本文不替它补齐事实。可以确定的只有两点：一是“同月开源”这一事件描述来自该文；二是确切的仓库名、开源范围（整套运行时还是部分组件）、许可证、release 日期，均属待核实项，读者引用前应回 GitHub release 页与仓库 LICENSE 核对。

在核实完成之前，更稳妥的表述是：模型厂商开始把 harness 当作可开放的竞争面，而不是把这件事当作某个具体版本号的新闻。

1.2 选型话语已经定型：框架 / harness / 低代码 / 企业平台

一个赛道成熟的标志之一，是讨论它时的分类语言稳定下来。《AI Agent 原理与实战》2026 版第 15 课把 Agent 框架全景划分为四类：框架、harness、低代码、企业平台[5]。这套分类被后续内容反复沿用，说明“我要买的到底是哪一层”已经成为一个被普遍追问的问题。

四类形态解决的问题边界大致如下：

类别	主要解决什么	控制点归属	典型形态（来源提及，非推荐）
框架	提供 Agent 构造原语：状态机、循环、工具抽象、记忆组件	应用开发者	LangGraph、smolagents 等（来源 [5] 列出）
harness	提供执行运行时：会话、工具路由、审批门、中断恢复、审计	harness 运行时 / 部署方	Codex CLI、DeepSeek Harness 等（来源 [1][2] 提及）
低代码	降低搭建门槛，面向非深度工程团队	平台方	来源未给出稳定代表，本文不列举
企业平台	组织级权限、合规、集成与治理	企业 IT	来源未给出稳定代表，本文不列举

需要提醒：来源 [5] 称该四分法“源自微软课程思想”，但课程原表述与作者二次归纳的边界并不清楚，本文将其视为社区已成型的选型话语，而非任何官方标准。真正有意义的不是分类本身，而是分类揭示的分工：框架回答“怎么写出一个 Agent”，harness 回答“这个 Agent 长期运行时由谁兜底”，低代码回答“谁来搭”，企业平台回答“组织敢不敢放行”。

1.3 “指挥中心”品类出现：从单 Agent 到 Fleet 管理

第三个标志是产品形态上冒出的新层。GitHub 项目 agentpulse 把自己定义为“面向 AI 编码智能体的自托管指挥中心”，覆盖 Claude Code、Codex CLI、GitHub Copilot CLI，提供实时仪表盘、会话历史、WebSocket 实时更新、编排工具（启动 Agent、对运行中会话发提示/停止）以及人类介入（HITL）收件箱决策；其 MCP server 的访问受 scoped API key 约束，并提供 observe-only（只读）模式[3]。PowerSpawn 则定位为“通用多 Agent MCP server”，在一个协调者之下拉起 Claude、Codex、Copilot 等不同模型的 Agent，采用共享黑板设计，Agent 交互历史可被 Git 追踪[4]。

这两类项目的能力侧重并不相同，可以并排看：

能力维度	agentpulse[3]	PowerSpawn[4]
会话可见性	实时仪表盘 + 可滚动会话历史	未见披露（以黑板留痕为主）
跨模型调度	面向多种编码 Agent CLI	明确支持 Claude Code / Copilot / 任意 MCP 客户端，模型覆盖 GPT、Claude、Gemini、Grok、Mistral
HITL 审批	明确提供 inbox 决策	未见披露
权限分级	scoped API key，observe-only 只读档	未见披露
历史留痕	WebSocket 实时记录	Git 可版本化追踪

此外，第三方日报项目 daily-diff 在 2026-10-26 的条目中以“逐日 diff”方式跟踪 16 个 Agent 工程项目，覆盖 Claude Code、Gemini CLI、Kilo Code、DeepSeek Harness、OpenShell 等，并记录了 Hermes Agent 的一处凭据泄露问题（CLI 参数绕过聊天出口与审批卡脱敏、gateway status 明文打印 MCP 配置）[6]。一个能被“逐日 diff”的生态，本身就是该层已经活跃起来的旁证。

这一层是 harness 的竞争者还是补充？从现有形态看更像补充：harness 负责一个 Agent 怎么可靠地跑完任务，指挥中心负责多个 Agent 的可见性、调度与放行。但二者的边界尚未稳定——下文会展开。

二、harness 到底管什么：把运行时从模型和框架里剥出来

2.1 一次 Agent 任务在 harness 里经历了什么

模型只负责一件事：在给定上下文下产生下一步输出。它不负责判断该不该执行、执行到一半断了怎么办、这次调用算不算越权。这些确定性职责落在 harness 上，大致包括：任务循环控制、上下文组装与裁剪、工具路由与参数校验、审批门、中断恢复与检查点、会话与历史管理、审计留痕。

这与 2026 年 10 月一篇趋势文的判断方向一致：Agent 行业的重心正从“模型能不能调用工具”，转向“Agent 能不能在受控环境中长期完成任务”，包括任务中断后能否恢复、工具选错后能否纠正[8]。

用一段语言无关的伪代码描述这个骨架（示意伪代码，非任何真实 API）：

while task not finished:
    context = assemble(session_history, skills, tool_results)
    decision = model.step(context)          # 模型只产出决策

    if decision.kind == "tool_call":
        tool = mcp_route(decision.tool)     # 走 MCP
        check = approval_gate(tool, decision.args, policy)
        if check.need_human:
            enqueue_hitl(check)             # 人工放行/驳回
        result = execute_with_timeout(tool, decision.args)
        checkpoint(session, result)         # 断点与审计

    elif decision.kind == "delegate":
        peer = a2a_resolve(decision.agent)  # 走 A2A
        result = a2a_send(peer, decision.task)

    else:
        finish(task)

把这段骨架与“直接调模型 API + 自己写 while 循环”对比，差别不在代码量，而在每一步是否有人兜底：工具参数是否被校验、危险操作是否过门、失败是否可恢复、历史是否可追溯。这正是 harness 与“框架里的一个循环组件”的分野。

2.2 harness 与模型、框架、编排器的边界

可以把整个栈理解为六层，每一层的控制点归属不同：

层	职责	控制点归属
模型层	产生决策	模型厂商
harness 运行时	循环、工具路由、审批、恢复、审计	运行时部署方
编排 / 指挥中心	多 Agent 调度、可见性、fleet 控制	编排层运维方
协议层（MCP + A2A）	工具互联与 Agent 互联	协议社区 / 基金会
资产层（Skills / workflow）	可复用工件	资产作者与治理组织
企业平台	组织权限、合规、集成	企业 IT

为什么 harness 不能被框架吸收？因为框架是开发期抽象，harness 是运行期抽象。框架让你写出 Agent，harness 决定这个 Agent 在生产环境中以什么权限、什么恢复语义、什么审计要求运行。agentpulse 的 scoped API key 设计是一个很具体的说明：同一套编排能力，用 observe-only 密钥时只读、不可执行，用高权限密钥时才能启动与停止会话[3]。控制点被具象成密钥范围，这正是 harness 层该做的事。

2.3 模型公司为什么开源 harness：两种解读与可证伪的观察点

分析（本文推断，非事实陈述）。一种合理解读是：执行框架的开放有助于把开发者锁定在模型生态内——当你的 Agent 资产（工具配置、Skills、工作流）都在某套 harness 的语义下组织，换模型的成本会低于换 harness 的成本。另一种可能是：模型能力趋同后，差异化竞争点确实下移到可控性、可靠性与工程生态，开源是加速生态形成的常规手段，未必指向锁定。

两种解读并不互斥。判断哪一种更接近现实，可以观察几个可证伪的信号：第三方 harness 是否获得主流模型的官方支持；开源 harness 的许可证是否允许商业托管与二次分发；模型厂商是否在 harness 之外继续收取可观的运行时费用。在这些信号出现之前，把“开源 harness”解读为行业开放为时尚早，解读为控制权之争的延伸则较为稳妥。

这一推断也与协议层和资产层的动作方向一致：标准外移（Skills 捐基金会[7]）、执行层开放（harness 开源[1]）——两者都在把“可迁移性”做高，而迁移成本最高的部分（会话、权限、审计策略）恰恰留在运行时。

2.4 选型决策速查

团队情况	建议起点	主要风险
小团队、快速验证、定制需求高	框架 + 自建薄 harness	循环、审批、恢复语义自研成本易被低估
中型团队、多 Agent 长期运行	harness + 轻量指挥中心	两层控制点重叠，权限口径易打架
多模型、多 CLI 并存	跨模型编排层（如 PowerSpawn 形态[4]）	抽象层归属未定，切换成本仍高
强合规、组织级治理	企业平台 + 可审计 harness	灵活性受限，需保留自研逃生通道

这张表给的是方法论，不点名“最佳产品”。要点是先明确控制点归谁，再谈技术选型。

三、协议层收敛：MCP 管工具，A2A 管协作

3.1 MCP：Agent 与工具/数据之间

MCP（Model Context Protocol）在 2025–2026 年的工程内容中被一致描述为“Agent 与工具/数据源的连接标准”：统一工具定义与调用格式，使不同 AI 应用共享同一套 MCP server，并在协议侧提供权限与沙箱相关的工程约定[9][10]。它先于 A2A 普及并不难理解——工具接入是单 Agent 就会遇到的问题，收益即时、改造面小，而且形态接近“给模型装通用接口”[10]。

MCP 没有解决的问题同样清楚：它不负责 Agent 之间的任务分发、能力发现与结果交接；它也不负责跨组织的信任与身份。把这些塞进 MCP 会让协议承担不属于它的职责。

工程上已经出现稳定的范式。一篇实战文描述了“统一 MCP 入口”的做法：把 Wiki、Dify、GitLab 等内部系统收敛到一个 MCP server，Agent 端只配一条连接，凭据集中在 server 端，新增系统只需在 server 加一个工具即可全局生效[11]。这是私有系统、自维护场景下的合理取舍：牺牲了一些隔离粒度，换取凭据集中与配置简化。需要注意的是，MCP server 的具体配置字段名应以官方文档为准，本文不提供未经核实的字段名。

3.2 A2A：Agent 与 Agent 之间

据掘金一篇架构演进文称，A2A（Agent2Agent）由 Google 于 2025 年 4 月发起，同年 6 月捐给 Linux 基金会，2026 年 3 月发布 v1.0.0，目前获得超过 150 家组织支持，包括 Google Cloud、AWS Bedrock、Microsoft Azure AI Foundry 等云平台的原生支持[12]。这组数字与日期均来自该文转述，本文未回 A2A 官方仓库逐项核验，引用时请以官方仓库与公告为准。

即便暂不采信具体数字，双轨分工本身是清楚的：

维度	MCP	A2A
面向对象	Agent ↔ 工具/数据源	Agent ↔ Agent
解决问题	工具发现、调用、上下文注入	能力发现、任务分发、结果交接
典型场景	查询数据库、调用内部 API、读文件	跨团队/跨厂商委托任务、结果汇总
成熟度信号	大量工程教程与统一入口实践[11]	版本化标准 + 云平台原生支持（据文 [12] 称）

实践侧也出现了同时使用两者的案例：一篇 Hermes Agent 实战文描述了注册 MCP 服务并跑通 A2A 消息路由的流程，用于解决多 Agent 场景下“消息没送到、上下文缺失、重跑结果不一致”的问题[13]。需要说明的是，该文导向同一付费 Key 通道产品，属软文集群的一部分，本文只取其对 MCP/A2A 分工的描述，不采信其产品推荐。

3.3 双轨如何在 harness 里衔接

在一个跨 Agent 任务中，分工大致是：本地工具调用走 MCP，远端或异构 Agent 的委托与交接走 A2A，Skills 注入到两侧的上下文组装环节。harness 在其中扮演“会话与策略的唯一落点”——无论请求来自工具还是来自另一个 Agent，都要经过同一套审批门与审计链。

PowerSpawn 的设计可作为编排侧的样本：一个协调者拉起不同模型的 Agent，Agent 通过共享黑板交换中间结果，交互历史可被 Git 追踪[4]。agentpulse 则提供观察与控制面：看得到每个会话在做什么，也能对运行中会话发提示、停止或做 HITL 决策[3]。

示意场景（非真实客户案例）：一个代码分析任务由协调 Agent 拆成两部分，分别派给两个不同模型的编码 Agent；A 负责静态检查，需调用本地扫描工具（走 MCP）；B 负责依赖影响面分析，需委托另一个团队的 Agent 查询（走 A2A）；两份结果回到协调者处汇总。在这个流程里，harness 负责给两个子任务分配各自的工具权限、在写操作处设审批门、为两次跨 Agent 交接留下审计记录。缺了这一层，MCP 与 A2A 只是两条能通的线，谈不上可控。

四、Skills 资产化：从本地文件夹到基金会治理

4.1 Skill 是什么形态的可复用工件

Skill 与 prompt 片段、workflow、MCP server 的区别在于复用单位：prompt 是一段文本，workflow 是一套编排好的步骤，MCP server 是一个可调用的服务，而 Skill 是把操作规程、约束、检查清单和配套脚本打包成可被 Agent 按需加载的知识工件[14]。它介于“配置”和“代码”之间，因而具备资产属性：可版本化、可共享、可弃用、可审计。

社区已经用目录结构表达了这种资产化。据一篇项目剖析文称，mattpocock/skills 仓库按 engineering / productivity / misc / in-progress / deprecated 分类管理技能，并附带 Claude Code 插件清单与调用文档[15]。文中标称的“246K+ Stars”数量异常高，属来源自述，本文未回 GitHub 实时核验，不作为生态规模论据。

资产谱系可以这样看：

工件	复用单位	移植难度	版本化程度
Prompt 片段	文本	低	低
Skill 包	知识 + 约束 + 脚本	中	中，且正在标准化
Workflow 仓库	编排好的流程	中高	中（如 OpenWork 形态[16]）
MCP server	可调用服务	高（需部署）	高

4.2 捐给 AAIF 意味着什么

据行业汇总文称，2026 年 10 月 22 日，Anthropic 将 Agent Skills 的名称、Logo、GitHub 组织和域名移交给 Linux Foundation 下的 AAIF（Agentic AI Foundation），以推进厂商中立治理[7]。移交内容与日期来自该文，本文未回原始公告核验。

这一步的实际意义有三点。其一，命名与标识的中立化：技能库不再依附单一厂商的品牌，企业在采购与集成时的政治成本下降。其二，治理路径的可预期性：参照 A2A 的先例——据文 [12] 称其 2025 年 6 月捐给 Linux 基金会、2026 年 3 月发布 v1.0.0——“捐基金会”通常伴随规范版本化与多方治理的路径，但这是类比推断，不是对 Skills 的任何承诺。其三，规范开放程度是关键变量：名称与组织移交不等于规范已经中立，Skills 的格式规范、兼容性承诺与治理章程是否同步开放，仍需观察，本文不作断言。

4.3 资产化的工程含义

一旦 Skills 可以被共享与分发，harness 需要新增一组此前不太存在的能力：版本解析（这个 Skill 是哪个版本、与当前 Agent 是否兼容）、来源信任（来自哪里、是否签名、是否过审核）、权限声明（这个 Skill 允许调用哪些工具、是否需要审批门）、生命周期（in-progress / deprecated 的处理）。

OpenWork 提供了一个共享仓库的样本：据其项目介绍文称，它把 AI 工作流做成可共享资产，通过 MCP 接入 Codex、Claude Code、OpenCode 等不同 Agent 工具，非技术同事可通过桌面应用使用[16]。PowerSpawn 把 Agent 交互历史纳入 Git 追踪[4]，则提供了可追溯性的一种做法。这两点合起来指向同一件事：资产层的成熟度，取决于 harness 能不能把“谁写的、谁改的、谁批准的、用在哪”这条链记全。

五、收敛了吗？一份“已定 / 未定”清单

5.1 已收敛的三件事

结论	支持来源	反例或不确定性
运行时/编排层独立成赛道	双 harness 同月开源[1]、指挥中心类项目[3][4]、逐日 diff 生态[6]、四分类选型话语[5]	关键 release 日期与开源范围仍待核验[1]
MCP + A2A 分工清晰	多篇工程内容一致描述 MCP 管工具、A2A 管协作[9][10][12][13]	A2A 版本与支持组织数为转述数据[12]
Skills 走向资产化与中立治理	目录化资产管理[15]、共享 workflow 仓库[16]、移交 AAIF[7]	规范是否同步开放未核实

5.2 未收敛的三件事

第一，跨模型编排的抽象层归属。 agentpulse 是自托管指挥中心[3]，PowerSpawn 是 MCP 形态的编排 server[4]，前者偏观察与控制面，后者偏任务分发与黑板共享。两者都可能被吸收进 harness，也可能被企业平台收编。未来 6–12 个月可观察的信号：主流 harness 是否内置 fleet 管理；企业平台是否直接提供跨模型调度而非通过插件。

第二，harness 的商业模式与许可证边界。 开源的究竟是整套运行时还是部分组件、许可证是否允许商业托管，目前缺乏可靠材料[1]。可观察信号：是否出现基于开源 harness 的托管服务，以及模型厂商对第三方 harness 的官方态度。

第三，Skills 的分发与信任标准。 仓库形态的技能库[15]说明需求存在，但 registry 规范、签名机制、权限声明格式都未见成型。生态规模目前也没有可靠度量——像“246K Stars”这类数字在核验前不应被引用[15]。

5.3 给三类读者的落地建议

平台架构师：现在做的是把控制点写清楚——会话归谁、权限怎么分级、审计落到哪、断点怎么恢复，这些比选框架更重要；观望的是跨模型编排的抽象层归属；避免的是把编排逻辑写死在某个 CLI 的调用细节里。

Agent 产品团队：现在做的是把 Skill 与工具配置当作可版本化的资产管理，接入层尽量走 MCP 这类已有收敛度的协议；观望的是 A2A 的实际成熟度（跨组织协作场景再上）；避免的是自造一套不兼容的技能格式。

企业技术管理者：现在做的是评估部署形态与合规落点，要求运行时提供审计与 HITL 能力；观望的是 harness 的许可证与商业模式；避免的是在规范治理尚未清晰时把全部技能资产绑定到单一厂商的私有格式。

结语

Agent 基础设施层的收敛不是单点事件，而是三条线同时推进：执行与编排层独立成产品形态，协议层分成 MCP 与 A2A 两条互补轨道，技能层从本地文件夹走向基金会治理。这套结构的最大价值，是让“我要建的是哪一层、控制点归谁”第一次变得可以精确讨论；最大的风险，则是在许可证、信任标准与抽象层归属都未定的阶段过早押注。

本文的判断中，事实、二手转述与推断是分开的：双 harness 开源、指挥中心类项目的能力描述、Skills 移交 AAIF 等属来源自述的事件[1][3][4][7]；A2A 的版本与组织数、社区 star 数等属二手转述[12][15]；关于模型厂商动机与收敛方向的分析属本文推断。所有标注“待核验”的日期与数字，建议在做技术决策前回到原始仓库与公告核对。

参考资料

[1] AI Agent 的“操作系统”之争：DeepSeek Harness 与 Codex Harness 同月开源，Agent 运行时正在独立成赛道，CSDN，https://blog.csdn.net/m0_74899094/article/details/168654791

[2] GitHub Trending 连续霸榜的「智能体逆向工程」：AI Agent 开源生态正在发生什么（2026-10-12~10-15 榜单解读），CSDN，https://blog.csdn.net/m0_74899094/article/details/168143665

[3] jstuart0/agentpulse：Self-hosted command center for AI coding agents，GitHub，https://github.com/jstuart0/agentpulse

[4] CynaCons/PowerSpawn：MCP for cross-model agents orchestration, with novel shared blackboard design，GitHub，https://github.com/CynaCons/PowerSpawn

[5] 《AI Agent 原理与实战》2026 版 第 15 课：Agent 框架全景与选型，CSDN，https://blog.csdn.net/weixin_40192882/article/details/167283137

[6] AI Agents 2026-10-26 · Issue #157 · dboeter/daily-diff，GitHub，https://github.com/dboeter/daily-diff/issues/157

[7] 最新 AI 资讯截至 2026-10-23（OpenAI Decisions API / Patch the Planet / Anthropic 捐 Agent Skills），掘金，https://juejin.cn/post/7699476211433226240

[8] 2026 年的 AI Agent，正在从“会调用工具”走向“能长期工作”，CSDN，https://blog.csdn.net/2301_81316824/article/details/167469787

[9] 深入理解 AI Agent 架构：从理论到 MCP 协议实践，掘金，https://juejin.cn/post/7623768662602121225

[10] 告别魔法：Agent Loop、Skills、Teams 与 MCP 协议，掘金，https://juejin.cn/post/7618916024856576054

[11] 从零到一：给 AI Agent 开发一个统一 MCP 服务器（实战全记录），掘金，https://juejin.cn/post/7668564914921078820

[12] 从 ReAct 到多 Agent 协作：AI Agent 的架构演进与工程化实践，掘金，https://juejin.cn/post/7694016286323310633

[13] Hermes Agent 实战：用 MCP 与 A2A 让 AI 智能体越用越聪明，CSDN，https://blog.csdn.net/weixin_42591413/article/details/168224217（注：该文含产品推广成分，本文仅采信其对 MCP/A2A 分工的描述）

[14] 《AI Agent 原理与实战》系列相关工程概念描述，见 [5][10]

[15] mattpocock/skills 深度剖析：AI Agent Skills 生态，掘金，https://juejin.cn/post/7678231767486939188（注：文中 Star 数为来源自述，未核验）

[16] 空降 GitHub 第 4！18.7K Star 开源项目要做 AI 工作流的“共享仓库”（OpenWork），掘金，https://juejin.cn/post/7668568406279618598

剔除说明：S5、S9、S11 三篇为同一付费 Key 通道产品的同题推广内容集群，S14（Yandatini/mcp-agent-framework）描述含明显下载营销模板痕迹，S3 自述为预测清单而非事实记录，均不作为本文核心论据。