下面把 10 个 axes 按性质分成 3 组结构组这个 harness 是什么形状、行为组它怎么动、资源组它用什么、记什么。结构组 StructureAxis取值范围典型实例1. topologysingle ↔ multiClaude Code 默认 singlesubagent 可扩展Anthropic research system 是 multiStripe minions 是 multi2. coordinationorchestration ↔ cooperationorchestration中心化 lead agent 派发任务Anthropic research systemcooperation去中心化通过共享状态协作Stripe minions 通过 PR/CI。两者可混合3. session spansingle-session ↔ multi-session单次对话 vs 跨多次对话。一个 artifact 跨 session 协作系统就是 multi-session 的例子。这个 axis 很关键它说明跨 session 是 Harness 的一个设计选择行为组 BehaviorAxis取值范围典型实例4. control loopReAct / Plan-Execute / Tree Search / ...ReAct观察 → 推理 → 行动Plan-Execute先规划整体再逐步执行。Inside the Scaffold论文把 5 种 loop primitivesReAct、generate-test-repair、plan-execute、multi-attempt retry、tree search视为可组合 building blocks5. autonomyfully-autonomous ↔ approval-required ↔ supervised信任边界——决定哪些操作需要人工审批destructive action、force push、生产部署等6. execution isolationnone ↔ git-worktree ↔ sandbox ↔ full VMCline 的 git-worktree轻隔离、Claude Code 的本地 sandbox中隔离、Daytona/远程 VM重隔离。决定了一次错误的rm -rf会影响什么资源组 ResourcesAxis取值范围典型实例7. memoryworking / long-term / sharedworking当前 session 临时记忆long-term磁盘持久化shared多 agent 共享 Artifact Network。Hu Wei 综述指出file-persistent、hybrid、hierarchical 是生产主流纯 ephemeral in-memory 很少见8. tool typefunction / env / verify / workflowfunction纯函数工具计算、查询env环境交互文件系统、bashverify验证工具测试、lintworkflow复杂工具开 PR、部署9. verificationcomputational ↔ inferentialcomputational确定性验证typecheck、unit testinferentialLLM-as-judgecode review、语义验证10. compaction7 种策略Inside the Scaffold论文统计的 7 种策略summarization、sliding window、retrieval-based、hierarchical 等这 10 个 axes 的价值当你说Anthropic research system时你可以精确描述它Axis选择topologymulticoordinationorchestrationsession spansinglecontrol loopplan-executeautonomyapproval-requiredexecution isolationsandboxmemorysharedverificationcomputational inferential......这比笼统地说它是个 multi-agent 系统清晰得多。第 4 层Pattern可复用的设计模式从现有的一些Harness中我们可以抽象出一些跨领域可复用的结构性设计。这些 Pattern 不是某个具体项目的配置而是经过验证的、可以在不同场景下重复使用的设计蓝图。这一层类似于软件工程中的 GoF 设计模式——你不会说我在用单例模式这个产品你会说我在这个项目里应用了单例模式。Anup Jadhav 总结的 5 个基础 Pattern#Pattern解决的问题关键做法1Plan-Act-Verify几乎所有 agent 的基础模式分解任务 → 执行 → 自检的基础循环2Progressive Disclosure对抗 context rot上下文膨胀导致 agent 混乱Skill 按需加载而不是一次性把所有指令塞进 context3State Outside Context持久状态不污染 context window持久状态放磁盘/artifactAnthropic 长任务 harness 明确推荐用feature_list.jsonclaude-progress.txt做跨 session 共享文件4Clean-Context Continuation避免 context 累积导致模型性能退化长任务执行中定期 reset context从任务简介重启5Approval Checkpoints关键操作需要 human-in-the-loop在 destructive action 前暂停等待审批学术界和工业界补充的 Pattern#Pattern解决的问题关键做法6Initializer Coding Agent长任务需要 spec 增量实现分离Anthropic 长任务 harness 的标志性模式Initializer agent 写 spec/TODOCoding agent 增量实现。现在的很多 SDD 框架就使用了这个 Pattern7Planner / Evaluator Split对抗 agent 自己批自己作业太宽松写代码的模型和审代码的模型分开8Approved Fixtures避免 agent 自己生成测试、自己通过的循环自嗨用固定测试数据对抗 agent 自评9Ralph Loop实现 agent 的自迭代Hook 截断退出 重注入 promptPattern 层的特殊性这一层是 Harness Engineering 的核心。它承上启下向下组合 Design Components 中的能力和设计轴向上被具体的 Instance 实例化当你在设计一个新的 agent 系统时不应该从零开始发明而应该先看看这些 Pattern 中哪些适用然后组合、调整。第 5 层Design Instance最具体的现实这一层是现实世界中真正跑起来的 agent 系统。当你打开 Claude Code、看到 Stripe 的 PR 机器人、或者部署一个 CI/CD 自动修复系统时你看到的就是 Design Instance。几个典型例子Instance关键特征对应的 axes 选择Anthropic Multi-Agent Research SystemClaude Opus 作为 lead agent 协调多个 Claude Sonnet subagent 并行Lead agent 把研究任务分解并写入虚拟文件系统作为 TODO3 个 Sonnet subagent 并行执行搜索和分析相比单个 Opus agent 在复杂研究任务上展现显著性能提升topologymulti、coordinationorchestrationStripe Minions每周自动合并 1300 PRBlueprint 架构deterministic node agentic nodeCI 严格的 two-strike rule失败两次立即升级到人工PR webhook 触发事件驱动topologymulti、coordinationcooperation多个 agent 通过 PR/CI 这个共享状态协作CI/CD Auto-Triage Auto-FixCron 定时扫描 CI 失败/新 issue代码自动生成 prompt 描述问题Skill 自动分类问题类型Agent 在 worktree 中自动修复Checker 判断修复是否完成自动开 PR等 CI green 后通知 Slack channel状态持久化到文件系统自动化 agent 系统实例叠加 Loop PatternOpenAI Codex 长期项目实例OpenAI 团队用 5 个月构建并交付一个内部 beta 产品人工手写代码为 0 行团队起初由 3 名工程师驱动 Codex后续扩展到 7 名系统持续跨多个 session 工作OpenAI 称之为 harness engineering——通过代码外壳管理 agent loop持续运行的 agent 系统实例这一层的价值在于它是抽象概念的锚点。当我们讨论 Pattern 或 Primitives 时可以随时回到这些具体例子来验证理解是否正确。三个关键认知有了这个分层结构我们可以回答几个容易混淆的问题。认知 1Multi-agent 的位置我之前一直在考虑multi-agent到底处于什么位置 是不是应该在harness 之上的独立层。有了我自己的分层后就可以简单定义:Multi-agent 只是topology 这个 design axis上的一个选项。Anthropic research system harness(topologymulti, coordinationorchestration, ...)Stripe minions harness(topologymulti, coordinationcooperation, ...)基于RAG的智能问答 harness(topologysingle, ...)它们都是 harness只是在 topology 轴上的选择不同。认知 2Harness这个词的三种用法现在我们可以精确区分Claude Code 是一个 Harness→ 指的是 Framework 层的产品解决问题和评估的agent分开 是一个好的 Harness 设计→ 指的是 Pattern 层我们项目的 Harness 配置在 AGENT.md 里→ 指的是 Design Instance 层的具体配置三个人说的都是Harness但分别在不同层。Harness Engineering 解决的问题Context Engineering 无法回答的问题Harness Engineering 都能回答Agent 怎么自己去找信息工具调用的控制Agent 如何安全地运行沙箱、权限管理Agent 如何跨多个 session 协作状态持久化、调度什么时候触发 compaction生命周期管理这些问题都能在 Harness Engineering 的框架内得到回答。这个分层解决了什么问题?概念边界清晰说Harness时明确在说哪一层设计决策明确知道在哪一层做什么决策复用性提升Pattern 层可以跨项目复用沟通效率提升团队讨论时不会鸡同鸭讲终于轮到最近突然火起来的Loop Engineering了我把它定位成一个特殊的Pattern四、Loop Engineering让 Harness 自主运转的 PatternLoop Engineering 解决什么问题在 Harness Engineering 的基础上我们已经能构建出功能完整的 Agent 系统。但还有一个关键问题没有解决谁来启动 Agent谁来决定什么时候让 Agent 工作传统的 Agent 工作模式是人发现问题比如 CI 失败、有新 issue、PR 需要 review人打开 Claude Code输入 promptAgent 执行任务人查看结果决定下一步这个模式有几个问题问题 1人是瓶颈你得盯着 GitHub、Slack、CI 系统发现问题才能让 Agent 行动半夜 CI 失败了Agent 不会自己修得等你早上醒来问题 2上下文断裂每次都要重新告诉 Agent 背景、规则、注意事项Agent 不记得上次做了什么每次都是新员工问题 3无法持续工作你不可能 24 小时坐在电脑前给 Agent 分配任务大型项目的 Agent 协作需要持续数天人无法全程盯着Loop Engineering 就是为了解决这些问题把 Harness 从人工启动的工具升级为自主运行的 Agent。典型场景对比有 Loop 和没 Loop 的区别为了更具体地理解 Loop Engineering 的价值我们对比两个场景场景CI/CD Auto-Triage Auto-Fix场景CI/CD Auto-Triage Auto-Fix把没 Loop和有 Loop两条流程平行对齐步骤没有 Loop Engineering人工驱动有 Loop Engineering系统驱动触发CI 失败了你收到 Slack 通知Cron 每 10 分钟触发一次Self-triggering发现问题你打开 Claude Code系统自动扫描 CI 失败和新 issue生成 prompt你输入 /fix the failing CI代码生成 prompt 启动 AgentSelf-prompting修复Agent 在 worktree 里修复Agent 在 worktree 里修复判断完成你 review、mergeChecker 判断是否修复完成Stop condition check开 PR你开 PR自动开 PR状态记录无状态写入文件State persistence通知你盯着 CICI green 后自动通知 Slack 已修复请 review你的角色盯着监控、手动启动、半夜失败了得等早上只需要最后 review不需要盯着监控关键区别维度没 Loop有 Loop谁盯着监控你系统谁启动 Agent你手动系统自动谁判断完成你Checker工作时间受你作息限制24/7Stripe Minions 实例每周自动合并 1300 PRPR webhook 触发Event-driven LoopBlueprint 架构把工作流拆成 deterministic node 和 agentic nodeCI 严格的 two-strike rule失败两次立即升级到人工多个 agent 通过 PR/CI 这个共享状态协作Loop Engineering 的核心能力与依赖Loop Engineering 的本质是一个 orchestration pattern。它真正新增的核心能力只有一个Self-Triggering系统自动触发。但要让这个 pattern 工作它需要依赖 Harness 已有的三个基础能力。下面按依赖关系展开核心能力Self-triggering系统自动触发这是 Loop Engineering 唯一真正新增的能力不需要人手动启动系统自己决定何时启动 Agent。实现方式Cron定时触发每 10 分钟扫描 CI、每天早上生成报告Event事件触发PR created、issue opened、CI failed、webhook 推送Condition check条件触发当某个指标达到阈值根据触发的主动性可以分为Polling-based系统主动扫描Cron、condition monitoringEvent-driven外部事件推送webhook、file watch、message queue技术实现依赖Framework 层的 Trigger 系统cron / event / hook 机制具体什么时候触发、触发什么是Pattern / Design Instance 层的 决策例子# Cron: 每 10 分钟检查一次 */10 * * * * agent run scan and fix CI failures # Event: GitHub webhook on PR.opened - agent run review PR # Condition: 监控指标 when error_rate 5% - agent run investigate and alert关键区别不是 Loop人手动打开 Claude Code 输入 /fix CI人触发是 LoopEvent-drivenStripe Minions 的 PR webhook 自动触发 agent 处理是 LoopPolling-basedCron 每 10 分钟主动扫描 CI 状态并决定是否修复依赖能力 1Self-prompting系统生成 prompt为什么 Loop 需要它触发后Agent得有输入才能知道做什么。重要澄清Self-prompting不是 Loop 发明的——任何 Harness 都可以代码生成 prompt比如根据 tool schema 生成 system prompt。但 Loop必须用它否则触发后 Agent 不知道干什么。实现方式读取外部状态CI 状态、issue 列表、PR diff根据状态生成结构化的 prompt注入 context相关代码、历史修复记录依赖Framework 层的 Trigger 能力依赖能力 2State persistence跨 session 状态传递为什么 Loop 需要它Loop 通常跨多个 session 工作一次修不完、需要等外部状态变化得有地方存状态。重要澄清State persistence不是 Loop 发明的——这是 Harness 的session span axismulti-sessionState Outside Context pattern。任何需要跨 session 的 Harness 都可以用。但 Loop大概率需要它。与 Harness 的关系跨 session 能力来自 Harness 的 session span 设计轴single-session ↔ multi-sessionState Outside Context 是 Harness Pattern 层的一个成员Loop Engineering 只是让这个跨 session 流程自动化触发举例说明Harness 的 multi-session非 Loop用户手动起一个新 session 读 artifact 继续工作Loop Engineering系统定时自动起 session 检查 artifact 并推进工作区别在于谁触发而不是能否跨 session。实现方式Session 1Agent 写状态到文件feature_list.json、progress.txt、artifactSession 1 结束Session 2自动触发读取文件继续工作Session 2更新文件状态依赖Framework 层的 Memory 能力State Outside Context pattern每个 session 读这个文件知道该做什么做完后更新状态。Loop Engineering 的价值不是发明新的能力而是通过 Self-triggering 把 Harness 从人工启动的工具升级为自主发现问题并解决的 Agent。这是从被动响应到主动监控的范式转变。Loop Engineering 在 Harness 分层中的位置现在可以回头再看看Loop Engineering 到底是什么它是 Pattern 层的成员在上一节的分层结构中Loop Engineering 位于Pattern 层和 Plan-Act-Verify、Initializer Coding Agent 平级。Addy Osmani 的 51 building blocks 验证了这一点Addy 说 Loop Engineering 依赖 6 个 building blocksAutomations定时/事件触发Worktrees隔离工作空间Skills固化知识Plugins/connectorsMCPSub-agentsmaker/checker 分离Memory这 6 个里其实都已经在 Harness 里了Automations → Framework 层 Trigger的能力Worktrees → Framework 的 sandbox runtimeSkills → Framework 的 skill registry Pattern 的 progressive disclosurePlugins → Framework 的 MCP clientSub-agents → Framework 的 subagent spawn Pattern 的 Planner/EvaluatorMemory → Framework 层 Memory 能力 Pattern 的 State Outside Context那为什么很多人说Loop 在 Harness 之上这是个好问题。Addy、Boris 的文章确实给人Loop 是更高层的感觉。三个非概念性的原因修辞/传播原因从手动 prompting 到自动 prompting 是个范式转变包装成新一层更有冲击力便于传播技术文章需要吸引眼球产品原因Claude Code 和 Codex 把 Automations 做成 first-class feature产品上需要突出这个新功能/loop命令看起来像是新能力历史原因Harness engineering 这个词 2025 年才定型Loop engineering 是 2026 年的新词新词自然要在它之上才显得新但从概念本质讲Loop Engineering 是 Harness 内部的一个 Pattern主要依赖 Framework 层的 Trigger 能力通过组合现有能力实现自驱动。Loop 的真正价值不是层级更高而是范式转变从人工启动的工具到自主运行的 Agent这个跃迁的价值不在于引入了新的技术能力而在于改变了人与 Agent 的协作模式过去你是 Agent 的老板发现问题、分配任务、检查结果现在你是系统的架构师设计规则让系统自己发现问题、分配任务、检查结果这个转变的意义不亚于从手动部署到CI/CD 自动部署、从人工监控到自动告警。