10 个 Design Axes，分 3 组：
下面把 10 个 axes 按性质分成 3 组：结构组（这个 harness 是什么形状）、行为组（它怎么动）、资源组（它用什么、记什么）。
结构组 Structure
| Axis | 取值范围 | 典型实例 |
|---|---|---|
| 1. topology | single ↔ multi | Claude Code 默认 single（subagent 可扩展）；Anthropic research system 是 multi；Stripe minions 是 multi |
| 2. coordination | orchestration ↔ cooperation | orchestration：中心化 lead agent 派发任务（Anthropic research system）；cooperation：去中心化，通过共享状态协作（Stripe minions 通过 PR/CI）。两者可混合 |
| 3. session span | single-session ↔ multi-session | 单次对话 vs 跨多次对话。一个 artifact 跨 session 协作系统就是 multi-session 的例子。这个 axis 很关键：它说明跨 session 是 Harness 的一个设计选择 |
行为组 Behavior
| Axis | 取值范围 | 典型实例 |
|---|---|---|
| 4. control loop | ReAct / Plan-Execute / Tree Search / ... | ReAct：观察 → 推理 → 行动；Plan-Execute：先规划整体，再逐步执行。Inside the Scaffold论文把 5 种 loop primitives（ReAct、generate-test-repair、plan-execute、multi-attempt retry、tree search）视为可组合 building blocks |
| 5. autonomy | fully-autonomous ↔ approval-required ↔ supervised | "信任边界"——决定哪些操作需要人工审批（destructive action、force push、生产部署等） |
| 6. execution isolation | none ↔ git-worktree ↔ sandbox ↔ full VM | Cline 的 git-worktree（轻隔离）、Claude Code 的本地 sandbox（中隔离）、Daytona/远程 VM（重隔离）。决定了一次错误的rm -rf会影响什么 |
资源组 Resources
| Axis | 取值范围 | 典型实例 |
|---|---|---|
| 7. memory | working / long-term / shared | working：当前 session 临时记忆；long-term：磁盘持久化；shared：多 agent 共享 Artifact Network。Hu Wei 综述指出：file-persistent、hybrid、hierarchical 是生产主流，纯 ephemeral in-memory 很少见 |
| 8. tool type | function / env / verify / workflow | function：纯函数工具（计算、查询）；env：环境交互（文件系统、bash）；verify：验证工具（测试、lint）；workflow：复杂工具（开 PR、部署） |
| 9. verification | computational ↔ inferential | computational：确定性验证（typecheck、unit test）；inferential：LLM-as-judge（code review、语义验证） |
| 10. compaction | 7 种策略 | Inside the Scaffold论文统计的 7 种策略：summarization、sliding window、retrieval-based、hierarchical 等 |
这 10 个 axes 的价值：
当你说"Anthropic research system"时，你可以精确描述它：
| Axis | 选择 |
|---|---|
| topology | multi |
| coordination | orchestration |
| session span | single |
| control loop | plan-execute |
| autonomy | approval-required |
| execution isolation | sandbox |
| memory | shared |
| verification | computational + inferential |
| ... | ... |
这比笼统地说"它是个 multi-agent 系统"清晰得多。
第 4 层：Pattern（可复用的设计模式）
从现有的一些Harness中，我们可以抽象出一些跨领域可复用的结构性设计。这些 Pattern 不是某个具体项目的配置，而是经过验证的、可以在不同场景下重复使用的设计蓝图。
这一层类似于软件工程中的 GoF 设计模式——你不会说"我在用单例模式这个产品"，你会说"我在这个项目里应用了单例模式"。
Anup Jadhav 总结的 5 个基础 Pattern：
| # | Pattern | 解决的问题 | 关键做法 |
|---|---|---|---|
| 1 | Plan-Act-Verify | 几乎所有 agent 的基础模式 | 分解任务 → 执行 → 自检的基础循环 |
| 2 | Progressive Disclosure | 对抗 context rot（上下文膨胀导致 agent 混乱） | Skill 按需加载，而不是一次性把所有指令塞进 context |
| 3 | State Outside Context | 持久状态不污染 context window | 持久状态放磁盘/artifact；Anthropic 长任务 harness 明确推荐用feature_list.json+claude-progress.txt做跨 session 共享文件 |
| 4 | Clean-Context Continuation | 避免 context 累积导致模型性能退化 | 长任务执行中，定期 reset context，从任务简介重启 |
| 5 | Approval Checkpoints | 关键操作需要 human-in-the-loop | 在 destructive action 前暂停等待审批 |
学术界和工业界补充的 Pattern：
| # | Pattern | 解决的问题 | 关键做法 |
|---|---|---|---|
| 6 | Initializer + Coding Agent | 长任务需要 spec + 增量实现分离 | Anthropic 长任务 harness 的标志性模式：Initializer agent 写 spec/TODO，Coding agent 增量实现。现在的很多 SDD 框架就使用了这个 Pattern |
| 7 | Planner / Evaluator Split | 对抗 agent "自己批自己作业太宽松" | 写代码的模型和审代码的模型分开 |
| 8 | Approved Fixtures | 避免 agent 自己生成测试、自己通过的循环自嗨 | 用固定测试数据对抗 agent 自评 |
| 9 | Ralph Loop | 实现 agent 的自迭代 | Hook 截断退出 + 重注入 prompt |
Pattern 层的特殊性：
这一层是 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 System | Claude Opus 作为 lead agent 协调多个 Claude Sonnet subagent 并行；Lead agent 把研究任务分解并写入虚拟文件系统作为 TODO；3 个 Sonnet subagent 并行执行搜索和分析；相比单个 Opus agent 在复杂研究任务上展现显著性能提升 | topology=multi、coordination=orchestration |
| Stripe Minions | 每周自动合并 1300+ PR；Blueprint 架构（deterministic node + agentic node）；CI 严格的 two-strike rule（失败两次立即升级到人工）；PR webhook 触发，事件驱动 | topology=multi、coordination=cooperation（多个 agent 通过 PR/CI 这个共享状态协作） |
| CI/CD Auto-Triage + Auto-Fix | Cron 定时扫描 CI 失败/新 issue；代码自动生成 prompt 描述问题；Skill 自动分类问题类型；Agent 在 worktree 中自动修复；Checker 判断修复是否完成；自动开 PR，等 CI green 后通知 Slack channel；状态持久化到文件系统 | （自动化 agent 系统实例，叠加 Loop Pattern） |
| OpenAI Codex 长期项目实例 | OpenAI 团队用 5 个月构建并交付一个内部 beta 产品，人工手写代码为 0 行；团队起初由 3 名工程师驱动 Codex，后续扩展到 7 名；系统持续跨多个 session 工作；OpenAI 称之为 "harness engineering"——通过代码外壳管理 agent loop | （持续运行的 agent 系统实例） |
这一层的价值在于：它是抽象概念的锚点。当我们讨论 Pattern 或 Primitives 时，可以随时回到这些具体例子来验证理解是否正确。
三个关键认知
有了这个分层结构，我们可以回答几个容易混淆的问题。
认知 1：Multi-agent 的位置
我之前一直在考虑，multi-agent到底处于什么位置， 是不是应该在harness 之上的独立层。
有了我自己的分层后，就可以简单定义:
Multi-agent 只是topology 这个 design axis上的一个选项。
- Anthropic research system = harness(topology=multi, coordination=orchestration, ...)
- Stripe minions = harness(topology=multi, coordination=cooperation, ...)
- 基于RAG的智能问答 = harness(topology=single, ...)
它们都是 harness，只是在 topology 轴上的选择不同。
认知 2："Harness"这个词的三种用法
现在我们可以精确区分：
- "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 自主运转的 Pattern
Loop Engineering 解决什么问题？
在 Harness Engineering 的基础上，我们已经能构建出功能完整的 Agent 系统。但还有一个关键问题没有解决：
谁来启动 Agent？谁来决定什么时候让 Agent 工作？
传统的 Agent 工作模式是：
- 人发现问题（比如 CI 失败、有新 issue、PR 需要 review）
- 人打开 Claude Code，输入 prompt
- Agent 执行任务
- 人查看结果，决定下一步
这个模式有几个问题：
问题 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 启动 Agent（Self-prompting） |
| 修复 | Agent 在 worktree 里修复 | Agent 在 worktree 里修复 |
| 判断完成 | 你 review、merge | Checker 判断是否修复完成（Stop condition check） |
| 开 PR | 你开 PR | 自动开 PR |
| 状态记录 | 无 | 状态写入文件（State persistence） |
| 通知 | 你盯着 CI | CI green 后自动通知 Slack "已修复，请 review" |
| 你的角色 | 盯着监控、手动启动、半夜失败了得等早上 | 只需要最后 review，不需要盯着监控 |
关键区别：
| 维度 | 没 Loop | 有 Loop |
|---|---|---|
| 谁盯着监控 | 你 | 系统 |
| 谁启动 Agent | 你手动 | 系统自动 |
| 谁判断完成 | 你 | Checker |
| 工作时间 | 受你作息限制 | 24/7 |
Stripe Minions 实例：
- 每周自动合并 1300+ PR
- PR webhook 触发（Event-driven Loop）
- Blueprint 架构：把工作流拆成 deterministic node 和 agentic node
- CI 严格的 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 monitoring）
- Event-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"（人触发）
- 是 Loop（Event-driven）：Stripe Minions 的 PR webhook 自动触发 agent 处理
- 是 Loop（Polling-based）：Cron 每 10 分钟主动扫描 CI 状态并决定是否修复
依赖能力 1：Self-prompting（系统生成 prompt）
为什么 Loop 需要它：触发后，Agent得有输入才能知道做什么。
重要澄清：Self-prompting不是 Loop 发明的——任何 Harness 都可以代码生成 prompt（比如根据 tool schema 生成 system prompt）。但 Loop必须用它，否则触发后 Agent 不知道干什么。
实现方式：
- 读取外部状态（CI 状态、issue 列表、PR diff）
- 根据状态生成结构化的 prompt
- 注入 context（相关代码、历史修复记录）
- 依赖Framework 层的 Trigger 能力
依赖能力 2：State persistence（跨 session 状态传递）
为什么 Loop 需要它：Loop 通常跨多个 session 工作（一次修不完、需要等外部状态变化），得有地方存状态。
重要澄清：State persistence不是 Loop 发明的——这是 Harness 的session span axis（multi-session）+State Outside Context pattern。任何需要跨 session 的 Harness 都可以用。但 Loop大概率需要它。
与 Harness 的关系：
- 跨 session 能力来自 Harness 的 session span 设计轴（single-session ↔ multi-session）
- State Outside Context 是 Harness Pattern 层的一个成员
- Loop Engineering 只是让这个跨 session 流程自动化触发
举例说明：
- Harness 的 multi-session（非 Loop）：用户手动起一个新 session 读 artifact 继续工作
- Loop Engineering：系统定时自动起 session 检查 artifact 并推进工作
区别在于"谁触发"，而不是"能否跨 session"。
实现方式：
- Session 1：Agent 写状态到文件（
feature_list.json、progress.txt、artifact） - Session 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 的 5+1 building blocks 验证了这一点：
Addy 说 Loop Engineering 依赖 6 个 building blocks：
- Automations（定时/事件触发）
- Worktrees（隔离工作空间）
- Skills（固化知识）
- Plugins/connectors（MCP）
- Sub-agents（maker/checker 分离）
- Memory
这 6 个里，其实都已经在 Harness 里了：
- Automations → Framework 层 Trigger的能力
- Worktrees → Framework 的 sandbox runtime
- Skills → Framework 的 skill registry + Pattern 的 progressive disclosure
- Plugins → Framework 的 MCP client
- Sub-agents → Framework 的 subagent spawn + Pattern 的 Planner/Evaluator
- Memory → 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 自动部署"、从"人工监控"到"自动告警"。
