Harness 把模型输出接入真实环境。
Agent 除了生成文字，还要打开文件、运行命令、访问网络、保存进度并处理失败。Harness Engineering 关注上下文怎样进入模型、动作怎样受到约束，以及系统怎样依据环境返回的证据判断任务是否完成。
一次代码修改
Agent 修复 bug 时，模型判断可能原因；Harness 找到相关文件、运行测试、把报错送回下一轮，再保存修改和检查结果。少了这套流程，模型只能给建议，不能确认建议是否有效。
同一模型接入不同系统
同一个模型接入不同的仓库检索、工具协议、权限和测试系统后，完成率、成本和风险都会变化。评估 Agent 时，需要把模型与 Harness 一起看。
环境反馈影响下一步
一个工具能把准确诊断和短日志交给模型，另一个只返回一句“执行失败”；一个任务有测试和停止条件，另一个只能靠模型猜。两套系统由此可能得到不同结果。
一次任务的结果 同时受模型、Harness、执行环境和任务要求影响。
Prompt 不能代替系统约束
系统提示负责交代规则，外层还要处理工具协议、命令权限、沙箱、超时、重试、checkpoint、费用、日志和人工接管。能用程序确定的边界，应由系统落实，不应只写在提示词里。
框架与工具处在不同层级
LangGraph、OpenAI Agents SDK、AutoGen 是构建材料；Codex CLI、Claude Code、Cursor 是可以直接使用的 Agent 工具；OpenClaw、Hermes 更接近常驻网关和个人 Agent。它们都可能带有 Harness，但所处层级不同。
同一模型的结果也会变化
有的工具能给模型准确符号、短工具输出和可运行测试；有的把整仓代码和万行日志一起塞进去，也没有清楚的停止条件。研究里常把这种差异称为 scaffold effect 或 harness effect。
用一次修复任务来走完整个流程
假设任务是“修复登录接口偶发超时”。Harness 先读取项目规则和相关代码，再让模型提出一个很小的排查步骤，例如只运行登录模块测试。测试报错后，系统把退出码、关键日志和改动前状态送回下一轮；模型据此缩小范围，修改代码，再重新运行同一组测试。
测试通过后，Harness 还要检查 diff 是否超出允许目录、有没有意外改动依赖、完整构建是否通过，并按任务要求决定交给人审查还是继续提交。模型提出动作，工具返回事实，权限限制影响范围，验证步骤负责确认结果。
比较 Agent 工具时可以沿着五个问题往下看：资料从哪里取，命令在哪里跑，报错怎样返回，修改怎样撤销，最后靠什么证明完成。能把这五件事说清楚，才算看懂了一套 Harness。
从八个环节检查一项 Agent 任务。
这八层是本文使用的分析视角，不是行业标准。四种视图分别展示单 Agent Loop、状态 Graph、多 Agent 协作和安全边界；拖动节点或用方向键微调位置，可以查看数据来源、动作位置和结果回传路径。
把目标写成输入、禁止事项、验收与停止规则。
设计问题：能否用机器可观察的信号判断完成？上下文要随着任务推进不断更新。
工具刚返回的新日志，可能推翻上一轮计划；代码一改，旧的符号索引和测试结果也可能过期。运行中的 Harness 需要持续发现、挑选、排序、标注和压缩信息，而不能把所有历史消息原样拼在一起。
- 发现：从当前文件、仓库图、搜索、文档、记忆和环境中列出候选证据。
- 排名：按当前子目标、依赖距离、新鲜度、可信度和成本挑选。Aider repo map 用依赖图排名；IDE 工具还会利用光标和诊断。
- 预算：为项目规则、代码、工具结果和历史分别保留 token。窗口快满时，优先压缩过程叙述，保留目标、约束、未决问题和原始证据位置。
- 出处：让模型知道内容来自用户指令、可信项目规则、未知网页还是工具输出。来源不同，服从优先级和安全等级不同。
- 失效：文件改了就不能继续信旧 diff，依赖更新后旧构建也不再是证据。没有失效机制的记忆越多，反而越可能误导。
工具接口越清楚，模型越不容易猜错。
工具名要能说明动作，参数要有 schema，结果也要分清成功、失败、部分成功和“尚未执行”。如果工具只返回一句“看起来完成了”，模型很容易把计划误当成结果。
- 前置条件：路径是否存在、分支是否干净、账户是否有权、资源版本是否匹配。
- 结构化结果：返回状态码、变更对象、证据位置、可重试性和建议的下一观察，而不只是万行 stdout。
- 幂等与预览：重复调用不会重复付款或重复发消息；写操作能先 dry-run，提交后能获得稳定 operation id。
- 超时与取消：长命令必须能中断并说明当前状态，不能让主 Loop 误以为无输出就是失败。
- 最小暴露：让“读文件”“应用补丁”“运行测试”成为窄工具，比允许任意命令更容易授权和审计。
记忆要能过期、纠错，也要说得清来源。
工作记忆保存本轮目标和最近观察；会话状态保存计划、检查点与未决问题；情景记忆记录过去发生过什么；语义记忆保存相对稳定的项目事实；技能则把反复成功的步骤固化成可执行流程。五者生命周期不同，混在一段聊天摘要里会制造陈旧事实。
写入记忆之前要问：这是用户明确偏好、环境验证事实，还是模型猜测？读取时要带时间、作用域和来源；事实被新证据否定时要覆盖或留冲突记录。Hermes 等长期 Agent 把技能和记忆当核心功能，也因此需要比短会话编码 CLI 更强的治理与删除能力。
八类常见失败，分别应该修哪一层？
| 症状 | 可能原因 | 可以改哪一层 | 不要只做 |
|---|---|---|---|
| 读了很多仍改错文件 | 上下文召回和范围判断错误 | 仓库图、符号检索、显式文件清单、来源标记 | 盲目扩大上下文窗口 |
| 工具说成功但没有产物 | 结果协议模糊或异步状态未确认 | 结构化状态、产物校验、operation id、轮询 | 要求模型“更仔细” |
| 做着做着换了目标 | 任务说明与停止条件丢失 | 每轮保留验收清单、检查点和偏离检测 | 写更长人格提示 |
| 同一个测试反复失败 | 循环没有总结新信息 | 失败指纹、重试上限、策略切换、人工门 | 无限 loop-until-done |
| 自己写、自己评都说好 | 评估者共享生成者偏见 | 确定性测试、独立上下文 critic、对抗样例 | 再问一次“你确定吗” |
| 多 Agent 互相覆盖 | 工作区和所有权未隔离 | worktree、文件锁、状态合并与冲突协议 | 只给不同角色名字 |
| 网页文本触发危险命令 | 不可信内容进入控制通道 | 输入标记、最小权限、网络/写入分离、审批 | 提示模型忽略注入 |
| 长任务无法解释花费 | 没有轨迹、指标和成本归因 | 每轮 span、工具事件、token、墙钟时间与回放 | 只看最终答案 |
轨迹：还原每一步执行
按轮次保存上下文摘要、模型选择、工具参数、审批决定、工具结果和状态迁移。轨迹用于复盘单次失败，最好能从某个 checkpoint 重放，而不是重新运行完整任务。
指标：比较改版前后的结果
至少同时看任务完成率、一次通过率、人工接管时间、Token/费用、总耗时、危险动作和恢复率。只优化 Token 可能增加人工时间；只优化成功率可能让成本失控。
产物：保留对话之外的证据
代码 diff、测试报告、构建包、数据库事务、浏览器截图或外部 API 回执，才是环境证据。模型说“已完成”只是一个待验证的结论。
评测：区分离线回归与在线监控
离线任务集用于重复比较模型—Harness 组合；线上监控关注真实失败、成本变化和安全事件。线上问题脱敏后可以加入离线任务集，供后续回归测试使用。
Loop 负责推进，Graph 负责组织分支。
Loop 关心下一轮怎么继续，Graph 关心工作在哪些节点之间流动。一个 Graph 节点内部可以跑自己的 Loop，整张 Graph 外面也可以再套一层评估循环。设计时更值得问的是：状态存在哪里，控制权由谁拿着，失败后从哪一步恢复。
一次只推进一个可验证动作
把“做好它”改写成输入、约束、可观察的完成条件与停止规则。
把分支、并行、汇合与恢复显式化
- 入口
- 路由
- 并行 Worker
- 状态汇合
- Evaluator
- 人工门 / 回环
| 问题 | Loop | Graph |
|---|---|---|
| 适合 | 局部、顺序、反馈快 | 分支、并行、长时、有状态 |
| 主要风险 | 无休止重试、目标漂移 | 状态爆炸、编排过度 |
| 恢复 | 最近 checkpoint | 从失败节点或边重放 |
| 调试 | 看每轮观察和动作 | 看状态、节点、边和路由 |
Prompt chaining（顺序链）
先提取事实，再生成方案，再检查格式。每一步输出都能验证，适合固定且可分解的任务。
Routing（路由）
先判断任务类型，再选择工具、模型或流程。路由错误会影响后续步骤，因此要记录理由并允许回退。
Parallelization（并行）
把互不依赖的检索、测试或候选方案并行。它能缩短总耗时，也会增加 Token、合并冲突和证据去重成本。
Orchestrator–workers（调度与执行）
主 Agent 动态拆解任务，worker 在隔离上下文工作，再由主 Agent 汇总。适合文件范围事先不确定的复杂改造。
Evaluator–optimizer（评估与改进）
生成者与评估者轮流工作，直到达到量化门槛。评估标准模糊时，循环只会增加调用和费用。
Dependency DAG（依赖图）
长任务先明确步骤依赖，再只调度已满足前置条件的节点。LoopsBench 等研究将它用于长时软件任务。
按使用方式筛选 Agent 工具。
以下是 2026-08-13 整理的工具资料快照，2026-09-05 合并为同页条目；本次未对全部工具重新安装验证。使用前请核对各条官方来源和当前版本。终端运行位置与模型端点的数据去向需要分别确认，不能由“本机运行”推定数据留在内网。
Codex CLI
交互式 TUI 与 codex exec 共用代理循环；AGENTS.md 分层注入项目规则；沙箱和审批策略位于模型与操作系统之间；review、skills、MCP 与子代理围绕主循环扩展。
- 使用入口
- 终端 / CI / 编辑器
- 模型连接
- OpenAI 模型为主；可通过 --oss 连接受支持的本地提供方
- 使用前核对
- 最佳体验偏 OpenAI 模型生态；长任务仍需要清晰验收与检查点；高权限模式不应在未知仓库或主力环境随意启用
运行边界与资料
可配置只读、工作区写入、网络和审批；危险的“绕过审批与沙箱”开关明确存在，因此安全取决于运行配置而不只是工具名称。
能运行测试、构建、静态检查和 diff review；质量上限取决于仓库是否给出可执行验收标准，以及任务是否允许它得到真实反馈。
Claude Code
主代理循环外侧可叠加确定性 Hooks；子代理隔离上下文；动态工作流可以用脚本组织 fan-out、对抗验证、生成—筛选与 loop-until-done。
- 使用入口
- 终端 / 编辑器 / 桌面应用 / 网页
- 模型连接
- Claude 模型深度集成
- 使用前核对
- 与 Claude 模型生态绑定较深；工作流越复杂，成本与调试难度越高；“多代理”不会自动修复模糊目标或错误验收
运行边界与资料
权限规则、沙箱、Hooks 和人工确认共同约束执行。Hooks 是确定性控制点，但脚本本身也需要维护和测试。
官方工作流文章强调 evaluator、adversarial verification 和 loop-until-done；这会增加 token 与时延，适合高价值复杂任务，不应无差别套用。
Cursor
IDE Agent 连接编辑、搜索、终端与 MCP；Rules 保存项目偏好；checkpoints 和 diff review 支撑回退；Background Agents 在隔离的远程 Ubuntu 环境和独立分支执行。
- 使用入口
- 编辑器 / 终端 / 远程任务
- 模型连接
- 多模型托管选择，能力随服务计划与策略变化
- 使用前核对
- 核心平台闭源且价格、模型策略会变；后台 Agent 的网络与凭据边界需仔细治理；过度依赖索引可能掩盖上下文选择错误
运行边界与资料
本地操作依赖确认和 diff；后台代理隔离主机并走独立分支，但其互联网访问和自动命令也带来提示词注入与数据外传风险。
IDE 诊断、终端测试、checkpoints 与最终 diff 是主要反馈面。编辑器体验好不等于验证充分，仍需把真实构建和测试写进任务合同。
Grok Build
TUI、headless 与 ACP 三条入口复用代理运行时；AGENTS.md、skills 和 memory 组织上下文；sandbox、hooks、subagents 与 worktrees 承担执行和隔离。
- 使用入口
- 终端 / CI / 编辑器
- 模型连接
- Grok 模型深度集成
- 使用前核对
- 模型体验偏向 Grok；较新的项目需要观察长期兼容性；自行部署并不自动等于数据安全
运行边界与资料
沙箱与 Hook 能约束命令，但默认安全性仍取决于部署者如何配置网络、密钥、权限与插件来源。
支持 review 和在真实仓库执行测试。开源 Harness 的优势是能做可重复实验；弱点是用户需要自己承担更多版本和运行治理。
OpenCode
客户端/服务器结构暴露 SDK；Plan 与 Build 区分只读分析和改动；permissions、LSP、MCP、ACP、plugins 与 skills 形成扩展面。
- 使用入口
- 终端 / 桌面应用 / 编辑器 / 服务器
- 模型连接
- 提供方中立，可接多家云模型与本地端点
- 使用前核对
- 多提供方意味着配置与兼容矩阵更复杂；最佳模型体验可能落后于厂商原生特性；插件治理需要额外纪律
运行边界与资料
权限策略能按工具或路径控制，但插件和 MCP 扩大供应链面；自带密钥时需要区分模型数据路径与本地执行权限。
可运行测试和检查，也适合通过 SDK 接入自定义评测。中立性便于 A/B，但模型输出格式与工具调用兼容仍会影响结果。
Oh My Pi
TypeScript 主体配合 Rust 核心；工具循环连接 LSP/DAP、代码搜索、编辑与 Shell；hash-anchored edits 用内容锚点降低错误定位。
- 使用入口
- 终端
- 模型连接
- 多提供方与本地模型
- 使用前核对
- 社区项目的稳定性与文档成熟度需持续观察；功能密度高会增加配置学习成本；主要面向熟悉终端的技术用户
运行边界与资料
本地优先和源码可见便于审计，但终端代理仍能触达真实文件和进程；密钥、网络与危险命令需要部署者自行收紧。
调试器和语言服务器把运行态与静态诊断带入循环，适合定位复杂 bug；最终仍应以项目测试和 diff 为准。
Qwen Code
终端主循环围绕文件、Shell、上下文和模型 API 展开；项目从 Gemini CLI 系谱演化，重点适配 Qwen Coder 的代理编码能力。
- 使用入口
- 终端 / 编辑器 / CI
- 模型连接
- 面向 Qwen Coder 优化，也支持兼容端点
- 使用前核对
- 生态与扩展成熟度需结合版本核验；非 Qwen 模型未必获得同等优化；需要用户自己建设企业级权限和审计
运行边界与资料
开源 CLI 便于在内网部署和审计；数据是否离开内网，还要看模型 API 落点、遥测、网络和 Shell 权限配置。
可把编译、测试和静态检查纳入循环。评估时应同时比较 Qwen 模型与 CLI 配置，不能把一次表现全部归因于其中一方。
Qoder
Editor 与 Quest 面向交互和异步任务；CLI/SDK 面向终端及自动化；知识库、规则、MCP 与权限围绕工具层组织。
- 使用入口
- 编辑器 / 终端 / CI
- 模型连接
- 托管多模型与自动路由，以官方当前说明为准
- 使用前核对
- 与开源 Qwen Code 是两套不同工具；核心实现闭源；长期任务的成本、可解释性和数据边界需实测
运行边界与资料
商业托管降低安装门槛，但数据路径、模型路由、远程执行和企业策略需要结合合同与管理后台核验。
Quest 适合长任务，但仍需要清晰的完成定义、构建结果和人工验收；“运行更久”不等于“更正确”。
TRAE / Trae Agent
桌面端以 TraeCode/IDE 体验为主；开源 Trae Agent 用模块化工具和代理类运行任务，支持 Docker、MCP、最大步数和 trajectory 记录。
- 使用入口
- 编辑器 / 终端 / 研究环境
- 模型连接
- 桌面端多模型；开源 Agent 支持多 LLM
- 使用前核对
- TRAE 与 Trae Agent 功能不能一一等同；开源 Agent 更新节奏与桌面端可能不同；需要自行补充生产级策略
运行边界与资料
Docker 提供执行隔离，但镜像、挂载、网络和凭据仍需最小化；最大步数是成本保险丝，不是质量保证。
轨迹记录便于离线评测和错误归因。实际开发仍要关注 diff、测试、审查和发布门禁。
WorkBuddy / CodeBuddy
WorkBuddy 用任务规划、多 Agent、Skills 与 MCP 连接桌面工作；CodeBuddy 提供插件、IDE 与 CLI 路径。两者共享品牌语境但目标用户和工具风险不同。
- 使用入口
- 桌面应用 / 编辑器 / 终端
- 模型连接
- 托管模型与自动路由，以官方当前支持为准
- 使用前核对
- 定位覆盖通用桌面任务，超出纯代码 CLI；功能与计费会更新；通用文件访问扩大隐私与误操作面
运行边界与资料
官方文档提到高风险命令拦截；企业仍需检查本地文件上传边界、MCP 来源、凭据和外发操作的人工确认。
办公任务的验收常是格式、数字和事实一致性；代码任务则是测试和构建。两种 Harness 应使用不同评测集。
OpenClaw（“龙虾”）
单操作者 Gateway 管理渠道、会话、事件、插件和工具；可把不同聊天入口映射到代理；沙箱是可选边界，而非“安装即安全”。
- 使用入口
- 消息渠道 / 网关 / 服务器
- 模型连接
- 多模型与多代理接入
- 使用前核对
- 定位是个人代理网关而非专用编码 CLI；长期运行与广泛工具带来高安全责任；插件质量与版本差异大
运行边界与资料
官方文档明确主会话工具可能直接运行在宿主机，除非配置沙箱。把来自聊天、网页或邮件的内容当作不可信输入是最低要求。
通用 Agent 的结果常跨系统，不能只看一句回复。需要审计日志、动作回执、幂等设计和对外发送前确认。
Hermes Agent
CLI 与消息 Gateway 共用运行时；skills、记忆、会话搜索和用户模型形成学习层；本地、Docker、SSH、Modal、Daytona 等后端承载执行。
- 使用入口
- 终端 / 消息渠道 / 桌面应用 / 网关
- 模型连接
- 多提供方、可自定义端点
- 使用前核对
- “自我改进”带来漂移与审计难题；系统面广，运维责任大；长期个人数据需要严格治理
运行边界与资料
远程或 serverless 隔离降低本机风险，但账户、渠道身份、长期记忆和云凭据形成新的信任边界。
技能自改进应配套版本、回放和评测，否则一次偶然成功可能被固化成错误规则。
OpenHands
Agent/SDK、runtime sandbox、事件与会话层、Web/CLI/Cloud 使用入口分离；适合从本地实验扩展到批量任务。
- 使用入口
- 网页 / 终端 / SDK / cloud
- 模型连接
- 模型中立
- 使用前核对
- 部署比单一 CLI 更重；平台功能面增加运维成本；云与本地能力可能不同步
运行边界与资料
沙箱降低宿主风险，但镜像供应链、网络出口、密钥注入和租户隔离仍需平台层处理。
常用于 SWE 类任务和研究评测；规模化时需要保存轨迹、资源消耗和失败分类。
Cline
IDE 扩展连接模型和本地工具；用户可逐步批准读写与命令；后续扩展 CLI、SDK、并行任务与 worktree。
- 使用入口
- 编辑器 / 终端 / SDK
- 模型连接
- 多提供方与 BYOK
- 使用前核对
- 确认过多时效率下降；IDE 入口不适合所有 CI；插件拥有较大本地权限
运行边界与资料
默认的人在环是优势，但频繁确认会造成批准疲劳；允许自动批准后必须按工具和项目分级。
用户能逐步看 diff 和命令结果，适合教学与谨慎改动；自动化任务仍需要测试门禁。
Roo Code
VS Code 扩展以 Modes 控制提示、工具与文件权限；MCP 和模型提供方扩展能力；任务可在不同角色间切换。
- 使用入口
- 编辑器
- 模型连接
- 多提供方与本地模型
- 使用前核对
- 模式过多会增加认知负担；主要依赖 VS Code；配置质量直接影响安全
运行边界与资料
工具分配比单纯提示“不要修改”更可靠；仍需防止模式配置过宽和第三方 MCP 风险。
可用独立审查模式复核实现，但审查者若共享同一错误上下文，仍可能形成一致性幻觉。
Aider
聊天循环连接 repo map、模型特定编辑格式、文件集、lint/test 与 Git；仓库图排名在有限 token 内挑选关键符号。
- 使用入口
- 终端
- 模型连接
- 多提供方
- 使用前核对
- 界面与多代理能力相对克制；一次主要面向一个仓库；复杂编排需外部系统
运行边界与资料
Git 回退保护改动，但不能阻止命令或数据外发；运行命令与模型 API 仍需独立权限治理。
lint/test 自动反馈和 Git diff 构成紧凑循环，尤其适合范围清楚的代码任务。
Goose
核心代理循环通过 extensions/MCP 获得工具，提供 Desktop 与 CLI；项目进入 AAIF/LF 生态后更强调开放协议与治理。
- 使用入口
- 桌面应用 / 终端 / API
- 模型连接
- 模型中立
- 使用前核对
- 扩展面增大风险；不如专用编码工具聚焦；体验依赖模型和扩展组合
运行边界与资料
本地运行不能消除外部模型和扩展的数据流；必须逐个审查扩展权限、网络与凭据。
适合通过真实工具结果纠错；跨办公系统动作要使用回执、预览和可逆操作。
Gemini CLI
终端代理循环调用 Gemini API 与内置工具；配置、commands、extensions、MCP、headless 和 sandbox 构成运行层。
- 使用入口
- 终端 / CI
- 模型连接
- Gemini 模型深度集成
- 使用前核对
- 体验偏 Gemini 生态；预览版本可能回归；联网研究增加提示注入面
运行边界与资料
开源便于审查；搜索和 Web 内容是不可信输入，不能直接驱动高权限命令。沙箱配置应与 API 凭据隔离。
代码任务用测试，研究任务要保留来源与时间戳；大上下文不能替代事实核验。
Kimi Code CLI
Agent Shell 组织模型、文件、Shell、会话与工具；ACP 将代理能力与编辑器客户端解耦。
- 使用入口
- 终端 / 编辑器
- 模型连接
- Kimi 模型优化，也支持兼容配置
- 使用前核对
- 生态仍在快速演化；与 Kimi 服务关联较深；企业治理需自建
运行边界与资料
本地开源外壳不等于模型本地；权限、遥测、API 和命令执行应分别核验。
适合把中文需求、代码和测试放进同一闭环；最终以仓库运行结果为准。
Crush
单体 CLI 将 TUI、会话、模型提供方、LSP、MCP 与工具循环组合，重点保持终端体验和可移植性。
- 使用入口
- 终端
- 模型连接
- 多提供方
- 使用前核对
- 更聚焦单用户 CLI；企业策略面相对轻；项目更新快需关注兼容性
运行边界与资料
终端美观不改变权限事实；需要按项目限制命令、网络和密钥，尤其是第三方 MCP。
适合在当前工作流中运行测试与查看 diff；复杂后台编排不是其主要定位。
SWE-agent
Agent-Computer Interface 规定观察、命令和编辑动作；运行器、环境和轨迹记录围绕 benchmark 任务组织。
- 使用入口
- 终端 / 研究环境
- 模型连接
- 多模型研究配置
- 使用前核对
- 定位偏研究与教学；benchmark 成功不等同生产可用；UI 与企业集成有限
运行边界与资料
通常在容器/隔离环境运行 benchmark；切勿把研究配置无审查搬到生产凭据环境。
依赖测试和任务补丁判定，适合可复现比较。真实项目还需要需求沟通、人工审查与部署门禁。
Continue
VS Code/JetBrains 客户端、模型配置、context providers、MCP/工具与 CLI/CI checks 组合；配置可进入版本控制。
- 使用入口
- 编辑器 / 终端 / CI
- 模型连接
- 多模型与自定义配置
- 使用前核对
- AI checks 有误报漏报；配置生态需要维护；不同模型可重复性有限
运行边界与资料
CI 中的模型检查应定位为辅助信号，不能替代确定性测试和安全扫描；外部上下文仍需防注入。
其特色是把 AI 规则放入持续集成，适合评审规范和迁移检查；结果应可追踪到具体证据。
同时看三个工具，更容易发现差别。
两个工具都写着支持 MCP，权限粒度、上下文开销和失败后的处理方式仍可能完全不同。下面主要比较使用入口、模型策略、合适场景和需要接受的代价。在上面的卡片里勾选，内容会立即更新。
从上面的卡片里选 2 到 3 个工具，这里会列出它们的主要差别。
终端原生
Codex CLI、Claude Code、Grok Build、OpenCode、Aider、Gemini CLI、Qwen Code 更容易进入脚本和 CI。不熟悉终端的用户需要先了解目录、命令和权限。
IDE 内协作
Cursor、Cline、Roo Code、Qoder、TRAE、Continue 把光标、诊断和 diff 放在编辑器内，便于人工检查，但平台与插件权限也更复杂。
通用常驻
OpenClaw、Hermes、Goose、WorkBuddy 跨渠道、文档和日常自动化。它们不是“更大的代码 CLI”，需要独立的身份、记忆和外部动作治理。
用同一任务比较候选工具
先按使用入口和开放性筛选，再在相同仓库版本上运行一次有明确预期结果的小任务。分别记录所用模型端点、允许目录、工具版本、测试结果、人工修正时间、耗时与实际账单。没有匹配项时放宽明确的一项条件，不用加权分数掩盖不满足的要求。
“在本机执行命令”只说明工具运行位置。代码是否上传、检索索引存在哪里、日志保留多久，取决于模型提供方、插件、遥测和部署配置，须逐项核对。
权限边界要写进系统，不要只靠提示词。
仓库 README、Issue、网页、邮件和工具输出里都可能混入提示词注入。模型不一定能稳定分清哪些内容只供阅读，哪些指令才应该执行。安全的 Harness 会把权限边界落实在系统层，即使模型受到了影响，也不应轻易越权。
最小权限
读和写分开、仓库内和仓库外分开、网络读和外部提交分开。权限应跟当前动作走，不跟整个会话永久走。
执行隔离
容器、VM、远程工作区和 Git worktree 降低污染半径。沙箱不是魔法：挂载目录、Docker socket、网络和云凭据都可能穿透边界。
凭据隔离
让 Agent 只拿短期、最小范围凭据；不要把全局环境变量和家目录默认暴露。能代理签名的服务优于把原始密钥交给模型进程。
出口控制
读取公开网页与向外发送数据是两种权限。后台代理拥有互联网时，要限制可访问域名、上传体积和敏感文件。
可逆优先
先预览再发送、先分支再合并、先软删除再永久删除。数据库、支付、发布和对外消息必须设置明确人工门。
轨迹与回放
记录模型版本、提示、工具参数、结构化结果、权限决定和成本。没有轨迹的“自主”系统，失败后只剩猜测。
先把单 Agent Loop 做稳定，再考虑 Graph。
Anthropic 建议从简单方案开始。Graph 和多 Agent 用来处理确实存在的分支、并行和职责隔离，不必一开始就加。可行的顺序是写清任务、接入窄工具和真实测试，测到瓶颈后再增加路由、记忆或并行。
写任务说明
列输入、允许范围、禁止动作、完成证据、预算、超时和请求人工帮助的条件。
做一个窄工具
参数要有 schema，结果要带状态、证据和可重试错误；避免让模型拼接任意 Shell 字符串。
接真实反馈
代码用测试和构建，数据用约束和对账，网页用可访问性和关键流程。不要用模型自评代替环境证据。
加策略层
把路径、网络、费用和不可逆动作写成系统规则。关键约束不要只存在自然语言提示里。
保存轨迹
记录每轮输入、动作、结果、耗时与费用，并能从 checkpoint 恢复。先能解释失败，再谈自主更久。
建立任务集
收集真实成功、失败和边界案例；同时统计完成率、人工接管、成本、延迟与安全事件。
发现瓶颈
上下文错就做检索；工具错就改协议；循环漂移就改验收；任务互不依赖才并行。
再引入 Graph
只有当分支、汇合、恢复或职责隔离带来可测收益时，再付出状态模型和编排调试成本。
算成本，要把整个任务算进去。
一次 Agent 任务的模型成本，近似等于每轮输入上下文与输出 token 的总和；加上并行 worker、评估者、压缩模型和失败重试后，调用次数会成倍增加。墙钟时间还包含搜索、安装依赖、构建、测试、排队和人工等待。便宜模型如果需要更多轮、更多人工纠错，任务总成本可能更高；昂贵模型若一次选对文件并通过测试，反而可能更省。
因此运营面板至少要把费用拆到任务、轮次、模型、工具和失败类型。优化顺序通常是：先消除无意义重试和重复上下文，再用更窄工具减少输出，随后才讨论是否换小模型。多 Agent 也应按“增加一个 worker 带来的边际成功率”决策，而不是把并行数量当自主性指标。
同一个模型换一套 Harness，表现可能不同。
官方工程文章、开源实现和近年的论文都在讨论这个问题。文中引用的数字只代表论文给定的模型、预算和运行环境，不能直接拿来排商业工具；较新的结论也需要更多独立复现。
Anthropic：从简单组合开始
区分 workflow（预定义路径）与 Agent（动态控制）。常用模式包括顺序链、路由、并行、调度与执行、评估与改进；增加复杂度前要先确认收益能否测量。
LangGraph：把状态明确保存下来
Graph API 用 state、node 和 edge 表达执行；persistence 通过 checkpoint 支持持久执行、人工介入、状态回看和故障恢复。
Aider：上下文是图问题
repo map 把文件视为节点、依赖视为边，在 token 预算内用图排名挑关键符号。它证明“看多少”不如“挑什么”重要。
LoopsBench：长时任务是依赖问题
该研究把软件任务建模为依赖 DAG，并关注循环如何持续获取证据、恢复和推进。长时间运行不是指标，完成依赖且不破坏已有状态才是。
Scaffold Effect：评测不能只报模型名
相关研究把模型与 Harness 的组合作为影响结果的变量。同一模型在不同运行系统中可能得到不同结果，因此评测报告应公开工具、提示、环境、步数、权限与重试设置。
可观测性：失败要能归因
Harness 迭代的收益常来自工具、中间件、记忆、输出控制和反馈，而不是把系统提示写得更长。轨迹、指标和回放让这种迭代可证伪。
这些资料有一个共同方向：Agent 需要在环境反馈中反复观察、执行和检查。编译器、测试、数据库约束和浏览器状态可以提供可核验的结果；缺少这类反馈的开放式任务，更适合停在草稿、建议或人工协作阶段。
常见问题
Harness 和大模型是什么关系？
模型负责推理与生成；Harness 负责给模型上下文、工具、权限、执行环境、记忆和验证。实际效果来自四者与任务说明的组合。
Loop 和 Graph 有什么区别？
Loop 描述一次又一次观察、决策、执行和验证；Graph 描述多个步骤或代理如何分支、并行、汇合和回环。一个单 Agent Loop 完全可以是 Graph 的节点。
开源 Harness 一定更安全吗？
不一定。开源提高可审计性，但模型端点、网络、插件、密钥和系统权限决定实际风险。错误配置的开源 Agent 可以比受管商业工具危险。
为什么不直接给 Codex、Claude Code、Cursor 排总分？
它们的使用入口、模型策略和适用任务不同。可以用自己的任务集记录一次通过率、人工复核时间、费用、延迟和风险操作，再按实际需求选择。
新手从哪里开始？
先用只读或逐步批准模式，给一个小而可验证的任务，要求工具说明每次调用并展示 diff。熟悉执行过程后，再增加权限和任务长度。