跳到主要内容
投机取巧 投机取巧

Harness · AI coding agent atlas

Agent Harness 图谱

Agent 运行时 / 编排框架 / SDK 的责任边界、状态持久化能力与权限模型。收录标准：提供 Agent 运行时或编排层、有官方文档可回溯、近 30 天有实质更新。

10 个对象 8 个固定维度 5 个已完整核验 最后核验 2026-10-01

先回答一件事：你要不要自己搭

这是本站存在的唯一理由。如果现成产品已经够用，正确答案是「不要搭」——那就去 IDE 图谱 或 CLI 图谱，不用往下看。真要自己搭，第一步是认清你要的抽象层。

  1. 1我要最细的控制权，文件系统我自己管
    原语型（primitives-only）只给你 agent loop 的原语，不替你决定文件系统 / 规划 / 记忆怎么做 —— OpenAI Agents SDK 是这一类。
  2. 2我要一个成熟 CLI 直接变成 API 对象
    包装既有 CLIClaude Agent SDK 捆绑完整 CLI，默认给全工具无沙箱 —— 你省了造轮子，但权限模型是继承来的。
  3. 3我要开箱即跑的通用长任务助手
    batteries-includedDeep Agents 官方自述 opinionated：预置更多东西，也替你做了更多决定。
  4. 4流程要图、要能中断恢复、要多 Agent 协作
    编排框架：LangGraph / Google ADK / CrewAILangGraph 的落盘粒度最明确（每superstep 存一次图状态），ADK 的图执行引擎最完整，CrewAI 用「角色分工 + 事件流程」两套抽象。
  5. 5我要它常驻、跨平台、能定时跑
    平台型/ 常驻型：OpenHands / Hermes AgentOpenHands 是带 Web UI 的自托管控制中心；Hermes 更进一步——能挂Telegram/Discord/Slack/WhatsApp/Signal/Email 六平台，还能 cron 无人值守。
  6. 6我只想要个工具用，不想维护
    不该来这个站这属于「不自建」那一侧，见 IDE 图谱。

⚠ 三个最容易踩的坑：「状态」和「上下文」不是一回事——压缩上下文会丢信息，状态持久化才是长期可靠运行的前提（各家在这两层的完备程度差别很大）；「provider 无关」不等于「本地模型可用」（Claude Agent SDK 只支持 Claude，CrewAI 则点名支持 Ollama）；编排框架不给沙箱——权限边界要自己确认。

按抽象层分组

同一层里也能差很远 —— 两个「编程底座」一个是纯原语、一个是全托管包装 CLI，所以先按抽象层分，再看具体对象。

编程底座 3

给你 agent loop 或现成 CLI 的编程接口。这层的差别不在功能多少，而在它替你做多少决定 —— 一个只给原语，一个把整套 CLI 连权限模型一起打包给你。

Claude Agent SDK

Anthropic

「Claude Code 的编程接口」 —— 不是自建 agent 框架，是把一个成熟的 coding CLI 变成 Pyt

已核验 详情 →

Codex SDK

OpenAI

「把 Codex CLI 变成 Node 进程里可驱动的对象」 —— 官方 README 首句就是

已核验 详情 →

编排框架 4

把多步骤、多 Agent、要中断恢复的流程显式建成图。给的是控制力，代价是接线与状态管理都归你。

CrewAI

CrewAI Inc

「用角色分工和业务流程来组织多 agent 协作」 —— 官方自述：

部分核验 详情 →

LangGraph

LangChain Inc

「低层编排框架」 —— 官方自述用词很克制，注意那个 low-level：

已核验 详情 →

LlamaIndex Framework

LlamaIndex（run-llama）

⚠ 但先得说清一件事：官方已明确把公司重心从「编排框架」移走了。

部分核验 详情 →

通用 Harness 3

预置了规划、文件系统、记忆等一整套，面向通用长任务。开箱程度最高，可改性最低。

Deep Agents

LangChain

「batteries-included agent harness」 —— 官方自述：开箱即跑、面向长任务多步流程、

已核验 详情 →

Hermes Agent

Nous Research

「唯一带学习闭环的常驻个人助手」 —— 官方 README 这么写：

部分核验 详情 →

OpenHands Agent Canvas

OpenHands（All-Hands-AI）

「自托管的 agent 控制中心」 —— 官方 README 现在给它起的名字是 Agent Canvas，

部分核验 详情 →

本站目前是「核验快照」，还没有实测数据

下面每一个字段都能回到官方原文核对，但我们还没有在同一批任务上跑过这些工具。 实测协议已经写好（统一任务、统一验收、记录人工介入与返工次数），任务清单也已就绪， 尚未执行。

所以本站给的是能力边界与证据，不是「哪个更好用」的结论。 真正的选型请用你自己的输入、预算与验收标准跑一遍。

8 个维度，每格都能回溯

所有对象在同一坐标系下被描述。 点开任一对象，每一格下面都有官方源链接与核验日期——不认同可以自己回去查。

01

模型与开放条件

用谁的模型？能不能换第三方？多模型路由怎么配？

02

运行位置

本地 / 云端 / 混合？索引在本地还是云端？远程控制不等于云端执行。

03

本地文件

能访问多大范围？未打开的大文件怎么读？符号级能力如何？

04

关机后的任务

电脑关了还能继续跑吗？这是本地形态最常见的误解来源。

05

工具与扩展

工具链有多宽：MCP · LSP · 插件 · Hooks · 自定义指令。

06

上下文与记忆

索引算法、上下文窗口、会话恢复与分叉、跨会话记忆边界。

07

权限与限制

沙箱与审批边界、凭据管理、数据是否出境、额度如何计算。

08

适合什么任务

最擅长什么任务？什么情况下别用它？

全部数据一览

同一张表横向对比。点对象名进详情页看逐格证据。

对象厂商适合核验日状态
CAClaude Agent SDK Anthropic 适合：想要一个已经被打磨过的 coding agent（工具集、权限链、hooks、session fork 都在） 并且团队用 Pytho 2026-09-30 verified
CXCodex SDK OpenAI 适合：要把 Codex 塞进自己的 Node 应用 / Electron 应用 / CI； 需要非交互执行；需要精确的文件级权限规则；Typ 2026-10-01 verified
CACrewAI CrewAI Inc 适合：任务能被表述成「一支有角色分工的团队」（Crews）； 需要业务逻辑留在普通 Python 里并显式控制执行路径（Flows）； 想在 2026-10-01 partial
DADeep Agents LangChain 适合：要一个开箱即用、默认调优好、面向长任务多步流程的通用 Agent； 不想自己拼 filesystem / 记忆 / 子代理；已经在 L 2026-09-30 verified
GAGoogle ADK（Agent Development Kit） Google 适合：需要把多个 agent 组织成有分支、有循环、有人工介入的确定性流程； 要用代码优先（code-first）定义 agent 与工具， 2026-10-01 partial
HAHermes Agent Nous Research 适合：想要一个常驻的跨平台个人助手（Telegram/Discord/Slack/WhatsApp/Signal/Email）； 把它放在云 2026-10-01 partial
LGLangGraph LangChain Inc 适合：agent 流程要跑很久且必须能从中断处精确恢复； 需要人工在流程中间介入并修改状态；要把「工作记忆」与「跨会话长期记忆」分开管理； 2026-10-01 verified
LILlamaIndex Framework LlamaIndex（run-llama） 适合：核心任务是把外部数据源（API / PDF / 文档 / SQL）接进来做检索与问答， 且需要 300+ 现成集成里的某一个；团队 P 2026-10-01 partial
OAOpenAI Agents SDK OpenAI 适合：想要「薄 harness」—— 只要 agent loop 原语，filesystem / 规划 / 记忆都想自己挑； 需要 guar 2026-09-30 verified
OHOpenHands Agent Canvas OpenHands（All-Hands-AI） 适合：要把agent 放到自己服务器上 7×24 跑；需要定时或 webhook 触发（Slack / GitHub / Linear / 2026-10-01 partial

为什么这里不给总分排名

这不是省略，是方法上的明确取舍。

  • 缺统一实测，就不给分。跨工具的跑分口径不同——题目、预算、执行环境都不一样，A 的 90 分和 B 的 88 分不可比。
  • 「未知」是合法答案。查不到就写「未知」并说明为什么，不用推测填充。缺信息本身也是信息。
  • 每条判断挂官方源。来源链接、类型与核验日都在详情页里，可以逐条回去复核。
  • lifecycle 单独标注。核验日新不等于数据有效——上游归档后数据会失效，所以单独标 active / maintenance / archived。
  • 不同层级不混排。面向使用者的产品（IDE / CLI）与面向开发者的框架（MCP server）分开两个站，各按自己的坐标系。

可信度标记怎么读

详情页与上表都带 confidence，它反映本站数据的完整度，不是对产品的评价。

verified8 个维度均有官方源支撑，且核验日在 90 天内
partial部分维度标为未知，或官方文档不可访问，或核验日超过 90 天
stale官方已发布重大变化，本站尚未核验

本站当前的完整度

数据层用 node scripts/audit-gaps.mjs 可随时复核这个数字。 以下是最近一次核验的快照（核验日 2026-09-29）：

赛道已补齐说明
MCP 服务器 69/99 官方 README 信息充分，70% 维度已核验
CLI 工具 22/48 部分对象的官方文档不完整
IDE 工具 29/64 多为闭源产品，索引策略等细节官方不公开

全赛道合计 120/211 维度已补齐（57%）

剩余未补齐项分三类：官方未公开（索引算法、沙箱实现细节本就不对外说明）、 需实测才能确定（大仓库表现、CI 无 TTY 行为）、 客观渠道不可达。

我们选择留白而不是填「已支持」——错误的成本最终由使用者承担。

数据来源与复核方式

全部数据来自开源仓库 speculcom/ai-coding-agent-atlas（CC BY 4.0）。

每个条目都是纯 Markdown + frontmatter，含 8 个维度、证据链接、核验日与可信度标记。仓库内含：

  • METHODOLOGY.md —— 方法论总纲与四条核心规则
  • axes/ —— 每个维度的定义与判定标准（含正反例）
  • SCHEMA.md —— 数据格式规范与构建校验规则
  • tracks/*/tasks/_protocol.md —— 实测协议（尚未执行，故本站暂无实测结论）

发现错误或有新证据，欢迎提 Issue 或 PR——每条修正都会注明依据与影响范围。