Harness Engineering 从入门到实战

—— 给 Agent 造一副好鞍：理论教案 + 亲手搭建实例教案

作者：小周

---

主要参考文章（先读这篇）

本教程的理论框架主要基于 Martin Fowler / Thoughtworks 的《Harness Engineering for Coding Agent Users》（作者 Birgitta Böckeler，2026 年 4 月发表）：

📄 Harness Engineering for Coding Agent Users

https://martinfowler.com/articles/harness-engineering.html

这篇文章第一次给出了清晰的定义 Agent ≈ Model + Harness，并把 Harness 拆成 Guides（导航）+ Sensors（传感器） 两大支柱——本教程的"理论教案"部分就是围绕这篇展开的。

说明： 后续正文中出现的"第 N 章"（如第 9 章、第 10 章、第 22 章），均指这篇 Fowler 文章中的章节编号，不再重复标注。其他参考文章（OpenAI、Anthropic 等）见文末完整参考文献列表。

---

作者：小周（本文基于对 Harness Engineering 方法论的学习，结合一次完整的从零搭建实战写成，可直接作为博客发表）

---

写在前面

如果你用过 Claude Code、Codex、OpenClaw 这类 AI 编程工具，你一定有过这样的体验：

• 让 AI 改代码，它说"完成了"，结果测试一跑全红；
• 明明叮嘱了"别乱改文件"，它还是动了不该动的地方；
• 给它越长的提示词，它反而越容易"迷失"。

问题出在哪？出在我们把希望寄托在了模型的自觉上，而不是工程系统上。

这就是 Harness Engineering 要解决的问题。

---

第一部分：理论教案

1. Harness 是什么？

一句话定义：

Harness Engineering 是设计一个工程环境，让 AI Agent 能够持续、可靠、可验证地完成复杂任务。

核心公式：

Agent = Model + Harness
模型        鞍具（模型之外的整套工程系统）

"Harness" 英文原意是马鞍。马力气很大，但要让它朝着你要的方向跑、走对的路线、随时知道它状态，光靠喊没用，得靠鞍具。AI Agent 也一样——模型是那匹马，Harness 是那副鞍。

Harness 不是某一个软件，不是 AGENTS.md，不是 MCP，不是 Claude Code。它是这些组件背后的整套方法论。

2. 核心思想：Guides + Sensors

整个 Harness 可以简化成两部分：

Guides（导航）—— 告诉 Agent 应该怎么做：

• AGENTS.md、架构文档、需求文档、编码规范、示例、Runbook

作用是：降低 Agent 犯错概率。

Sensors（传感器）—— 告诉 Agent 做得对不对：

• 编译器、测试、Linter、类型检查、架构检查、安全检查、AI Reviewer

作用是：发现已经发生的错误。

两者组成基本闭环：

Guides → Agent → 执行 → Sensors → 对了吗？
                                  ├─ 对 → 完成 ✅
                                  └─ 错 → 修复 → 再验证 ↺

3. 一个重要的观念转变

旧认知： AI 说"做完了" = 做完了

新认知： 验证通过 = 做完了

Task Completion ≠ Agent 说完成了。真正的完成条件只有一个：Verification passed.

4. AGENTS.md：入口地图，不是百科全书

AGENTS.md 是 Agent 的入口地图——告诉它"去哪找"，而不是把所有内容塞进去。

一份合格的 AGENTS.md 包含 7 个部分：

核心写法：写行动指令（读…跑…不碰…），不写项目介绍。

5. 可执行约束：能写成代码的规则，不要只写自然语言

"请保持良好的架构" —— 几乎没有意义。

"CLI 层不得 import utils" —— 有意义，但只是人看的。

真正有用的是机器可执行的检查：

if grep -R "from utils" src/cli; then
  echo "架构违规"
  exit 1
fi

这是 Harness 最重要的原则之一：

能写成 executable constraint 的规则，不要停留在自然语言里。

6. Verification：Harness 的核心

scripts/verify.sh 是任务的唯一裁判：

#!/bin/bash
set -e   # 任一检查失败，立即终止（一票否决）

pytest
ruff check .
mypy src
bash scripts/architecture-check.sh

为什么必须 set -e？

如果架构检查都失败了，还继续跑测试，万一测试恰好全过，Agent 就能宣称"验证通过"——闸门就被骗过了。所以验证闸门必须短路：发现一个错，立刻亮红灯。

7. 权限比语言约束可靠

告诉 Agent"不要删除生产数据库" —— 语言约束。

让 Agent 根本没有生产库的写权限 —— 权限约束。

Harness 的原则：

Prompt restriction 不要只告诉 Agent 不要做坏事，而是尽量让它做不到。

8. 状态（State）：长任务的存档点

Agent 工作几十轮，单靠上下文不够，必须保存状态：

agent/feature-state.json   ← 任务进度（哪个 feature 做完了）
agent/progress.md          ← 工作日志
state/members.json         ← 业务数据（名单等）
git history                ← 提交历史/检查点

每轮 Agent 循环：

读进度 → 读 git → 找下一个任务 → 实现 → 验证 → 更新状态 → 提交

即使 session 被重置，Agent 也不会失忆。

9. Git：非常重要的 Harness 组件

Git 对 Agent 来说不只是版本管理，还是：

Memory（记忆） / Checkpoint（检查点）/ Audit trail（审计）
Rollback（回滚）/ Diff sensor（差异传感器）

完成一个阶段后：git diff 检查 → 确认无无关改动 → commit 存档。

10. Human in the Loop vs Human on the Loop

Human in the loop（传统）： AI 写一点 → 人检查 → AI 再写 → 人再查。人是吞吐瓶颈。

Human on the loop（Harness 倾向）：

• 人设计：规则、传感器、架构、权限、验收标准
• Agent 独立执行
• 人观察整体系统

人的价值，从"逐行盯 AI"，转向"设计 AI 的工作环境"。

11. CI：第二层保险

本地 Agent 跑 bash scripts/verify.sh，但不要完全信任本地。GitHub CI 再跑一遍：

on: [push, pull_request]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: bash scripts/verify.sh

Agent 验证 + CI 验证 = 双重检查。

12. 错误处理：Turn failures into infrastructure

Agent 犯错时，不要只说"下次别这样"。要问：

为什么 Harness 没有阻止这个错误？

比如 Agent 又直接访问数据库。不要只往 prompt 里加一句"不要直接访问数据库"，而是：

加一条架构规则 → 加自动化架构测试 → CI 强制执行

一次错误：

Error → Harness improvement → Permanent protection

这叫 Turn failures into infrastructure——把失败变成基础设施（永久防护）。

13. Harness 的 10 大模块

一个成熟的 Harness 要回答 Agent 的 10 个问题：

14. 成熟度五级（自检清单）

15. 你应该记住的 7 条原则

• 不要追求 AI 一次做对，要设计系统让它错了能修。
• AGENTS.md 应该是导航，不是百科全书。
• Repository 应该成为工程知识的 system of record。
• 能自动检查的规则，不要只写自然语言。
• Verification 比"AI 说完成了"更可信。
• Agent 每犯一次重要错误，都应该考虑升级 Harness。
• 人的价值逐渐从直接执行，转向设计环境、规则、反馈和评价体系。

---

第二部分：实战教案

用 30 分钟，从零搭一个带 Harness 的排班系统

理论讲完，我们来真的。下面这个案例，是我完整亲手走过一遍的实战：搭一个"轮值排班通知系统"（duty-rotator）。整个过程中我踩了坑、被闸门拦住过、也亲手修好了——每一步都是真实发生的。

场景与需求

做一个轮值排班工具：

• 输入一组名字（张三、李四、王五…）
• 按固定顺序每天轮转值班
• 增删人员后，后续排班自动重排
• 目标是以后能自动通知值班人（v1 先做核心逻辑，通知留接口）

示例命令：
python3 src/main.py list        # 列出全部成员
python3 src/main.py today       # 今日值班：张三
python3 src/main.py next        # 下一位：李四
python3 src/main.py add 赵六    # 加入成员，后续轮值自动重排
python3 src/main.py remove 李四 # 移除成员，后续轮值自动重排

第 1 步：搭骨架

按 Harness 推荐目录结构（AGENTS.md + 架构 + docs + agent + src + tests + scripts + CI）：

mkdir -p duty-rotator/src/service duty-rotator/tests duty-rotator/scripts \
         duty-rotator/docs/requirements duty-rotator/docs/design \
         duty-rotator/docs/decisions duty-rotator/docs/runbooks \
         duty-rotator/agent duty-rotator/state duty-rotator/.github/workflows

小贴士： state/ 目录专门放名单数据（members.json）——状态与代码分离，这是 Harness 的重要原则（Fowler 文章第 11 章 State）。

第 2 步：写 AGENTS.md（7 部分）

我们项目的 AGENTS.md（我亲手写的）：

# AGENTS.md — 轮值排班系统 Agent 指南

## Role
你是轮值排班系统的编码 Agent。完成标准 = `bash scripts/verify.sh` 全绿。

## Before making changes
1. 读ARCHITECTURE.md  搞清分层（CLI → Service → Notify），不许跳层
2. 读 docs/requirements/ 找对应需求
3. 读相关代码（按需）

## Implementation rules
- 最小改动，只改任务文件
- 名单数据在 state/members.json，代码在 src/，不混放
- 一次只做一个小目标

## Verification
- 完成前必须跑 `bash scripts/verify.sh`
- 未通过 = 未完成；失败 → 修 → 重新验证

## 权限边界
- ❌ 无权修改 scripts/ 和 .github/（Harness 本体）
- ❌ v1 不真发短信，只模拟打印；不得引入真实短信 SDK
- ❌ 不得绕过 Service 直接改 members.json（必须走 CLI/Service 的增删命令）

## Completion criteria
报告：改了哪些文件 / 实现摘要 / 验证输出 / 遗留风险

## State
- state/members.json 是轮值名单（跨 session 状态）
- 每个任务完成后更新 agent/feature-state.json

第 3 步：写核心算法（Service 层）

src/service/rotator.py —— 轮值调度核心：

"""轮值调度核心：固定顺序轮转 + 增删后自动重排。"""
import json
from pathlib import Path
from typing import List


class Rotator:
    def __init__(self, members_file: Path):
        self.members_file = members_file
        self.members = self._load()

    def _load(self) -> List[str]:
        if not self.members_file.exists():
            return []
        return json.loads(self.members_file.read_text(encoding="utf-8"))

    def _save(self) -> None:
        self.members_file.write_text(
            json.dumps(self.members, ensure_ascii=False, indent=2),
            encoding="utf-8",
        )

    def on_duty(self, day_index: int) -> str:
        """第 day_index 天轮到谁（固定顺序轮转，循环取模）。"""
        if not self.members:
            raise ValueError("member list is empty")
        return self.members[day_index % len(self.members)]

    def add(self, name: str) -> None:
        """新增成员，后续轮值自动重排。"""
        if name not in self.members:
            self.members.append(name)
            self._save()

    def remove(self, name: str) -> None:
        """移除成员，后续轮值自动重排。"""
        if name in self.members:
            self.members.remove(name)
            self._save()
        else:
            raise ValueError(f"{name} not in members")

关键设计： 为什么增删会自动重排？因为轮转是 day_index % len(members)——名单长度一变，取模结果就变，后续排班自然跟着变。没有"手动重排"这个动作，重排是数据结构天然保证的。

第 4 步：写测试（Sensor）

tests/test_rotator.py —— 5 个用例覆盖核心行为：

def test_on_duty_rotates_in_order(members_file):
    """固定顺序轮转：第0天张三，第1天李四，第2天王五。"""
    r = Rotator(members_file)
    assert r.on_duty(0) == "张三"
    assert r.on_duty(1) == "李四"
    assert r.on_duty(2) == "王五"

def test_on_duty_cycles_after_exhausted(members_file):
    """轮一圈后再回到第一个人。"""
    r = Rotator(members_file)
    assert r.on_duty(3) == "张三"

def test_add_reorders_subsequent_duty(members_file):
    """新增成员后，后续轮值自动重排。"""
    r = Rotator(members_file)
    r.add("赵六")
    assert "赵六" in r.members
    assert r.on_duty(3) == "赵六"

def test_remove_reorders_subsequent_duty(members_file):
    """删除成员后，后续轮值自动重排。"""
    r = Rotator(members_file)
    r.remove("李四")
    assert "李四" not in r.members
    assert r.on_duty(3) == "王五"

def test_on_duty_empty_raises(tmp_path):
    """空名单调用报错（保护）。"""
    f = tmp_path / "empty.json"
    f.write_text("[]", encoding="utf-8")
    r = Rotator(f)
    with pytest.raises(ValueError):
        r.on_duty(0)

踩坑记录： 第一次跑测试报 ModuleNotFoundError: No module named 'service' —— pytest 找不到 src/ 下的模块。解决：加 tests/conftest.py 把 src/ 加入 sys.path。这是 Python 项目的经典坑，Harness 的意义就是让这类坑在测试阶段暴露，而不是上线后。

第 5 步：写 CLI 入口

src/main.py：

#!/usr/bin/env python3
"""轮值排班 CLI：list / today / next / add / remove。"""
import argparse
import sys
from pathlib import Path

from service.rotator import Rotator

STATE_FILE = Path(__file__).resolve().parent.parent / "state" / "members.json"


def main(argv=None) -> int:
    parser = argparse.ArgumentParser(prog="duty", description="轮值排班工具")
    sub = parser.add_subparsers(dest="cmd", required=True)

    sub.add_parser("list", help="列出全部成员")
    sub.add_parser("today", help="今天轮到谁")
    sub.add_parser("next", help="下一个是谁")

    p_add = sub.add_parser("add", help="新增成员")
    p_add.add_argument("name")
    p_rm = sub.add_parser("remove", help="移除成员")
    p_rm.add_argument("name")

    args = parser.parse_args(argv)
    r = Rotator(STATE_FILE)

    try:
        if args.cmd == "list":
            for i, name in enumerate(r.members):
                print(f"{i + 1}. {name}")
        elif args.cmd == "today":
            print(f"今日值班：{r.on_duty(0)}")
        elif args.cmd == "next":
            print(f"下一位：{r.on_duty(1)}")
        elif args.cmd == "add":
            r.add(args.name)
            print(f"已加入：{args.name}，当前 {len(r.members)} 人")
        elif args.cmd == "remove":
            r.remove(args.name)
            print(f"已移除：{args.name}")
    except ValueError as exc:
        print(f"error: {exc}", file=sys.stderr)
        return 1
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

第 6 步：写验证闸门（Verification）

scripts/architecture-check.sh（可执行约束）：

#!/bin/bash
# 架构边界检查：src/ 里禁止危险调用
set -euo pipefail
cd "$(dirname "$0")/.."
fail=0

danger=$(grep -RnE "os\.system|subprocess|\beval\(" src/ 2>/dev/null || true)
if [ -n "$danger" ]; then
  echo "$danger"
  echo "❌ [architecture] 禁止 os.system/subprocess/eval"
  fail=1
fi

if [ "$fail" -eq 0 ]; then
  echo "✅ [architecture] 边界满足"
fi
exit $fail

scripts/verify.sh（总闸门，一票否决）：

#!/bin/bash
set -euo pipefail
cd "$(dirname "$0")/.."

echo "════ 开始验证 ════"
python3 -m py_compile src/main.py src/service/*.py
echo "✅ [lint] 语法通过"
bash scripts/architecture-check.sh
python3 -m pytest tests/ -q
echo ""
echo "✅✅ verify.sh 全部通过 — 任务完成 ✅✅"

第 7 步：见证奇迹——错误注入演示

这是整篇最精彩的部分。 我第一次跑通后，做了个实验：往代码里注入危险代码，模拟一个"不守规矩的 Agent"。

echo 'import os' >> src/main.py
echo 'os.system("rm -rf /")' >> src/main.py

然后跑闸门：

════ 开始验证 ════
✅ [lint] 语法通过
src/main.py:51:os.system("rm -rf /")
❌ [architecture] 禁止 os.system/subprocess/eval
EXIT=1

看清楚了：

• 第一关语法检查过了（语法没错）
• 第二关架构检查当场抓住了 os.system
• 因为 set -e，测试根本没跑——整个验证直接失败

这就是可执行约束的威力： 一个恶意 os.system，连测试都不用跑，直接被拒之门外。Agent 想假装"我完成了"？门都没有。

清理注入后：

════ 开始验证 ════
✅ [lint] 语法通过
✅ [architecture] 边界满足
..... [100%]
5 passed in 0.01s
✅✅ verify.sh 全部通过 — 任务完成 ✅✅

实战踩坑记录（都是真实发生的）

完成后的目录结构

duty-rotator/
├── AGENTS.md                  # 入口地图（7部分）
├── src/
│   ├── main.py                # CLI 层
│   └── service/
│       └── rotator.py         # Service 层（轮值算法）
├── tests/
│   ├── conftest.py            # 测试路径配置
│   └── test_rotator.py        # 5 个测试
├── scripts/
│   ├── architecture-check.sh  # 架构检查（可执行约束）
│   └── verify.sh              # 总验证闸门
├── state/
│   └── members.json           # 名单数据（状态与代码分离）
├── docs/                      # 需求/设计/决策/runbook
├── agent/
│   ├── feature-state.json     # 任务进度状态
│   └── progress.md            # 工作日志
└── .github/workflows/ci.yml   # CI 第二层保险（可加）

对照成熟度：这个实例处于什么水平？

用本教程第一部分第 14 节（成熟度五级）的自检清单：

这是一个 Level 2~3 的 Harness，而且完全是自己从零搭出来的。

接下来还能做什么（升级路线）

• 加 CI：把 .github/workflows/ci.yml 配好，GitHub 自动跑 verify
• 真发短信：v1 是模拟打印，v2 接短信 SDK（记得更新 AGENTS.md 权限边界）
• 用真实日期：today 现在是写死第 0 天，可改为按真实日期计算
• 加 Review Agent：让第二个 Agent 审查第一个 Agent 的代码（Inferential Sensor）

---

第三部分：Level 4 进阶实战

从 Level 3 冲到 Level 4（Agent Platform），还差什么、怎么做

1. 差距分析：Level 4 的 7 个特征，我们缺哪些？

按 Fowler 文章第 22 章的 Level 4 = Agent Platform，特征包括：MCP、Permissions、Sandboxes、Review agents、Observability、Multiple agents、Orchestration。对照我们的排班项目逐个盘点：

核心结论：从 Level 3 → 4，要加 4 样东西——Reviewer Agent（审查）、真正的权限/沙箱（隔离）、Observability（可观测）、Orchestration（编排）。

2. 实操一：加 Review Agent（最推荐，最见 Level 4 功力）

原理：确定性检查（测试/lint/架构）抓不到"代码质量、可读性、重复、设计一致性"这类问题。这一类是 Inferential Sensor（Fowler 文章第 9 章），适合交给另一个 LLM 来判断——这就是 Review Agent。

做法：写一个 scripts/review-agent.sh，把 git diff 发给 LLM，让它找问题：

#!/bin/bash
# Review Agent：AI 代码审查（Inferential Sensor）
# 依赖：一个可用的 LLM API（示例用 OpenAI 兼容接口）
set -euo pipefail
cd "$(dirname "$0")/.."

DIFF=$(git diff HEAD~1 -- src/ 2>/dev/null || git diff -- src/)
if [ -z "$DIFF" ]; then
  echo "✅ [review] 没有代码改动需要审查"
  exit 0
fi

# 把 diff 发给 LLM（这里用 curl 调 OpenAI 兼容 API 做演示）
curl -s https://api.xxx.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"gpt-4o-mini\",\"messages\":[{\"role\":\"system\",\"content\":\"你是资深代码审查员，找 bug、安全问题、架构违规，输出简洁清单\"},{\"role\":\"user\",\"content\":\"审查以下 diff：\\n$DIFF\"}]}" | python3 -c "import sys,json; print(json.load(sys.stdin)['choices'][0]['message']['content'])"

echo "✅ [review] 审查完成（请人工确认上述意见）"

把它挂进 verify.sh，成为第 4 道闸门（注意 Review Agent 通常只警告、不阻断，或只阻断严重问题）：

bash scripts/review-agent.sh   # 追加到 verify.sh 里

3. 实操二：真正的权限，不只是文字

AGENTS.md 里的"权限边界"是文字约束（Guides），Level 4 要的是系统级权限（Permissions）：

文件权限——让 Agent 物理上碰不到 Harness 本体：

chmod 644 scripts/verify.sh        # 只读，Agent 改不了
chmod 644 .github/workflows/ci.yml
chmod 777 state/                   # 名单目录可写（业务数据）
chmod 555 scripts/                 # 脚本目录只读+可执行

命令权限——在 OpenClaw / Claude Code 的权限配置里加 deny 规则（我在 OpenClaw 里见过这类配置）：

{
  "tools": {
    "nodes": {
      "denyCommands": ["rm -rf", "sudo", "git push", "curl *evil*"]
    }
  }
}

原则（Fowler 文章第 10 章）：

不让它做不到，而不是告诉它别做。

4. 实操三：加 Observability（可观测性）

让 Agent 的每个动作留痕，出事能回溯：

运行历史——verify.sh 每次运行追加日志：

# verify.sh 里加一行
mkdir -p logs
{ echo "[$(date '+%F %T')] verify result: $? (by $USER)"; } >> logs/verify-history.log

审计追踪——关键操作记录：

# scripts/audit.sh — 记录名单变更
#!/bin/bash
echo "[$(date '+%F %T')] members.json changed, new list: $(cat state/members.json)" >> logs/audit.log

配合 Git（Fowler 文章第 13 章）：

git log --oneline              # 谁在什么时候改了什么
// git diff                     # 这次改了什么

5. 实操四：Orchestration（多 Agent 编排）

这是 Level 4 的天花板。不引入复杂框架，先在现有环境里做"角色分工"：

Orchestrator（规划 Agent）
  ├── Coder Agent（写代码）
  ├── Tester Agent（写测试）
  └── Reviewer Agent（审查）

在 OpenClaw 里的落地方式（我现在就在 OpenClaw 环境里）：

• 用 sessions_spawn 派子任务：主 Agent 规划，子 Agent 执行，再回收结果
• 例如：主 Agent 说"写一个 remove 接口" → Coder 子 Agent 实现 → Reviewer 子 Agent 审查 → 主 Agent 验证合并

编排流程示例：

User goal → Orchestrator 拆解 → 派给 Coder
→ Coder 提交代码 → 派给 Reviewer
→ Reviewer 给意见 → Coder 修改
→ 跑 verify.sh → 通过 → 合并

6. 升级后的完整目录（Level 4 形态）

duty-rotator/
├── AGENTS.md                  # 入口地图（不变）
├── src/                       # 代码
├── tests/                     # 测试（Deterministic Sensor）
├── scripts/
│   ├── verify.sh              # 总闸门
│   ├── architecture-check.sh  # 架构检查
│   ├── review-agent.sh        # AI 审查（Inferential Sensor）← 新增
│   └── audit.sh               # 审计日志 ← 新增
├── logs/                      # 运行历史/审计 ← 新增
├── state/members.json         # 名单（状态）
├── agent/                     # 进度状态
└── .github/workflows/ci.yml   # CI

7. 升级到 Level 4 后的自检表

做完实操一到三，你就是 Level 4 的入门者；做完实操四，你就是 Level 4 的熟练者。

---

结语

回到开头的问题：AI 说"做完了"，你信吗？

学完这套方法论、亲手搭完这个实例，我的答案是：不信它说的，信 verify.sh 的退出码。

Harness Engineering 的全部精髓，可以压缩成一句话：

把"希望 AI 做对"，变成"通过工程系统让 AI 更容易做对，并且做错时能被自动发现和纠正"。

而人的价值，也从"逐行盯 AI"，变成了"设计 AI 的工作环境、规则、反馈和评价体系"——这正是未来工程师的样子。

---

参考：基于 Agent Harness Engineering 相关方法论综合整理，结合个人从零搭建实战写成。

作者：小周

参考文献

本教程的理论部分综合自以下文章（由 GPT 对 14 篇业内文章进行浓缩整理，原始对话见 ChatGPT 分享链接）：

原始来源： [ChatGPT 分享 — 介绍 Harness Engineering](https://chatgpt.com/share/6a9287f4-ea04-83ee-9354-62b9157517e3)

核心文章

• OpenAI — Harness Engineering

https://openai.com/index/harness-engineering/

• Martin Fowler / Thoughtworks — Harness Engineering for Coding Agent Users（Birgitta Böckeler，2026）

https://martinfowler.com/articles/harness-engineering.html

• Martin Fowler — Context Engineering for Coding Agents（2026）

https://martinfowler.com/articles/exploring-gen-ai/context-engineering-coding-agents.html

• Anthropic — Effective Harnesses for Long-Running Agents（2025）

https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• OpenAI — Unrolling the Codex Agent Loop

https://openai.com/index/unrolling-the-codex-agent-loop/

• Martin Fowler — Maintainability Sensors for Coding Agents（2026）

https://www.martinfowler.com/articles/sensors-for-coding-agents.html

• Martin Fowler — Humans and Agents in Software Engineering Loops

https://www.martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html

• OpenAI — Symphony（Codex Orchestration）

https://openai.com/index/open-source-codex-orchestration-symphony/

• Anthropic — Claude Code CLI Reference

https://docs.anthropic.com/en/docs/claude-code/cli-usage

• Anthropic — Model Context Protocol（MCP）

https://docs.anthropic.com/en/docs/mcp

补充主题（源自同一份 GPT 浓缩，未提供独立链接）

• Claude Code SDK / Agent SDK 思路
• LLM Gateway Configuration
• OpenAI Codex / AGENTS.md 实践
• Martin Fowler — 2026 年 Harness Engineering 后续观察