从 Vibe Coding 到 Harness Engineering：2026 年 AI 编程工程化的完整地图

零、先读懂 22 个关键术语

方法论四层

术语	一句话解释	核心问题	类比
提示工程（Prompt Engineering）	优化”怎么说”	我该怎么提问？	写考试题目
上下文工程（Context Engineering）	优化”模型看到什么”	模型需要知道什么？	编教材
Harness 工程	优化”模型运行在什么样的系统里”	它必须看到什么、做什么、验证什么？	建一所学校
Loop 工程	优化”什么时候跑、跑什么、谁判定完成”	什么触发一次运行，谁检查，何时停？	学校的学期与考试制度

工程概念

术语	一句话解释	类比
Vibe Coding	用自然语言描述想要什么，接受 AI 输出而不逐行审阅	凭感觉装修
Agentic Engineering	人类编排自治智能体来生产软件，自己写规范、审结果	包工头管施工队
Harness	把一个模型变成能干活、能自检的 Agent 的那层运行时脚手架	给发动机装上底盘、方向盘和仪表盘
Agent = Model + Harness	同一个模型配不同 Harness，表现天差地别	同一台发动机，装进卡车和装进赛车是两回事
Coding Runtime	面向软件工作打包好的 Harness（自带工具、权限、沙箱、会话存储）	整车出厂，插钥匙就走
Skill	一段写在模型每次都能读到的地方的意图与流程说明（含脚本）	岗位操作手册
Sub-agent（子智能体）	独立的子 Agent，与主 Agent 上下文隔离	分工的组员
Worktree	Git 的独立工作目录，让多个 Agent 并行却不互相踩文件	每人一间独立办公室
上下文压缩（Compaction）	历史太长时，把较早的部分蒸馏成紧凑摘要	会议纪要做完就扔录音
Progress File	跨会话的进度记录文件，让下一个会话知道做到哪了	交接班记录
沙箱（Sandbox）	隔离执行模型写出来的代码	化学实验的通风橱
MCP	模型上下文协议，让 Agent 以标准方式发现并调用外部工具/数据	USB 接口
Sensors / Guides	Harness 的两类组件：引导（让正确结果更可能）与传感器（抓住错误结果）	路标 + 测速摄像头
Agent Legibility	让代码库/系统对 Agent 可读、可操作、可验证的程度	说明书是否写着机器能懂的格式
Inner Loop	Agent 一次”改代码→看结果”的最短循环	心跳间隔
Ralph Wiggum Loop	让 Agent 自我审查→请其他 Agent 复审→响应反馈，迭代直到所有评审者满意	反复打磨直到所有审核人签字
Maker / Checker 分离	写代码的 Agent 与检查的 Agent 必须是不同的	运动员不能当自己的裁判
Control Plane	在多个 Runtime 之上的治理层：有什么任务、谁负责、依赖什么、能花多少	项目管理办公室
Software 3.0	Karpathy 的说法：程序的基本单位从代码库变成上下文窗口	—

---

一、全景：四层演进，与一条贯穿的主线

1.1 四个词，每隔约一年出现一个

这四个方法论词汇不是同时出现的，而是每当上一层不再能解释杠杆在哪，下一层就被命名[citation:4]：

graph LR
    A["提示工程<br/>怎么说"] --> B["上下文工程<br/>2025.6<br/>看到什么"]
    B --> C["Harness 工程<br/>2026.2<br/>在什么系统里跑"]
    C --> D["Loop 工程<br/>2026.6<br/>何时跑、谁判定完成"]

层	工作单元	核心问题	主要杠杆	典型产物	典型失败
上下文工程	一次会话/一次模型调用	模型需要看到什么？	指令、检索文件、示例、历史、工具结果	AGENTS.md、CLAUDE.md、skills、prompts	Agent 因为缺了什么而瞎猜
Harness 工程	一个 Agent	它需要什么才能行动并检查自己的工作？	工具、测试、linter、沙箱、setup 脚本、权限	CI 检查、自定义 lint 规则、MCP 服务器、worktree 与容器	Agent 无法判断自己是否成功了
Loop 工程	跨越时间的许多次运行	何时跑、跑什么、谁判定完成？	触发器、排程、工作队列、独立检查者、记忆、预算	/loop、/goal、定时任务、自动化、manager agent	循环漂移，或在无人看管时空烧 token

命名时间线[citation:4][citation:10]：

时间	事件
2025.6	Tobi Lütke（Shopify CEO）说他更喜欢”上下文工程”而非”提示工程”，因为它描述的是”为让任务对 LLM 而言可解而提供全部上下文的艺术”。Karpathy 表示赞同
2026.2.5	Mitchell Hashimoto（HashiCorp 联合创始人、Ghostty 终端开发者）在《My AI Adoption Journey》中给出名字：harness engineering
2026.2.11	Ryan Lopopolo（OpenAI 工程团队）发表正式文章，系统化定义 harness engineering
2026.6	Boris Cherny（Anthropic，Claude Code 负责人）说他已经不再直接提示 Claude，因为循环替他做了；数日内这个实践被命名为 loop engineering（由 Peter Steinberger 与 Addy Osmani 命名）

两个人在几乎同一时间、独立地想到了同一个概念。这不是巧合——一旦 AI Agent 进入生产，“我们怎么管理 Agent”就变成一个无法回避的问题[citation:10]。

1.2 贯穿全文的那条主线

模型被视为给定的、短期内不可控的；于是所有杠杆都转移到了”模型周围的系统”上。

这句话可以用三种说法表达，它们是同一件事：

说法	出处/场景
“把模型当作固定的，改进环境而不是改进模型”	OpenAI 的 harness engineering 实践[citation:4]
“Agent = Model + Harness”	Birgitta Böckeler（martinfowler.com）[citation:4]
“Harness 由两类组件构成：guides（让正确结果更可能发生）与 sensors（抓住错误结果）”	同上[citation:4]

guides 与 sensors 这个划分极其有用，后面所有组件都可以按它归类：

类别	包含什么	作用
Guides（引导）	指令、示例、规范、skill、类型定义	让正确结果更容易发生
Sensors（传感器）	测试、linter、结构检查、审查 Agent、编译器、运行时观测	在错误结果漏出去之前抓住它

1.3 与第七篇的连接

第七篇列的七个痛点，正好对应这一篇的七类解法组件：

第七篇的痛点	这一篇的对应组件
验证瓶颈	Sensors：测试/linter/审查 Agent；Ralph Wiggum Loop
安全停滞	Sensors：SAST、密钥扫描；权限与沙箱
仓库级理解	Guides：AGENTS.md 分层、代码图谱、混合检索
依赖/API 幻觉	Sensors：注册表校验；沙箱无密钥环境
智能体失控	Loop：进度文件、单特性会话、/goal 的独立判定者
运行时假设	Sensors：把可观测性暴露给 Agent（LogQL/PromQL）
认知债	Guides：规范驱动（SDD）、skill 外化意图

---

二、Vibe Coding：起因、本义、走红与失效边界

2.1 起因与本义

2025 年 2 月 2 日，Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 总监）发了一条推文[citation:2][citation:8]：

“有一种新的编码方式我称之为 vibe coding，你完全沉浸在氛围里，拥抱指数级增长，忘记代码本身的存在。”

一个被立刻丢掉的关键限定[citation:2]：Karpathy 明确把它限定在一次性的周末项目上，不是生产软件。这个词一 viral，这个限定就没了。

真正流传下来的定义来自 Simon Willison 的区分[citation:2][citation:8]，判断标准只有一个：

你有没有审阅代码。

如果 AI 写了但你读过、测过、理解了每一部分——那只是”AI 辅助开发”。 “vibe coding”这个标签只在审阅从未发生时才成立。

2.2 它为什么爆发：三件事同时发生

[citation:5]

因素	说明
① Agent 真的变好用了	前沿模型解决真实 GitHub issue 的比率很高，Agent 工具能胜任多文件改动规划
② 上下文被接上了	MCP 这类标准让 Agent 能读你的代码库、调真实工具——在真实上下文里操作，而不是猜
③ 门槛塌了	非工程师和缺时间的构建者一个下午就能做出能跑的原型

规模[citation:2][citation:5]：

指标	数字
使用 AI 编码工具的开发者	80%+（约一半专业开发者每天用）
GitHub 上新代码的 AI 生成/辅助占比	约 40–50%
AI 辅助编码工具市场规模（2025–2026）	约 47 亿美元
Collins Dictionary	将 vibe coding 选为年度词汇[citation:2]
实践 vibe coding 的人群	很大比例不是专业开发者[citation:2]

2.3 现在这个词有三种含义

[citation:2]

含义	适用者
① Karpathy 的原义：完全不审阅，只用于原型和一次性代码	原教旨派
② 日常含义：任何 AI 辅助编码，即使完全审阅测试过	大多数人
③ 营销含义：面向非开发者的无代码应用构建器的卖点	厂商

关于”vibe coding 到底行不行”的多数争论，其实只是人们在用同一个词指三种不同的东西。[citation:2]

2.4 它在哪里真的成立，在哪里必然崩

成立[citation:2][citation:5]：

场景	为什么
原型与一次性项目	正是 Karpathy 原本限定的范围
边界清晰、定义良好的实现	错误输出容易被发现
非开发者做简单内部工具	出 bug 的代价低
周末项目与黑客松	速度比长期可维护性重要
胶水代码与样板（CRUD 端点、表单、配置、脚手架）	天然适合委托
你不熟悉的语言/框架	Agent 帮你跨过门槛
一次性脚本与自动化	原本不值得花时间

崩掉[citation:5]——而且原因集中在同一个根因：你交付了自己不理解的代码：

失败模式	具体表现
安全漏洞	Agent 乐于产出注入缺陷、泄露密钥、缺失鉴权；提示词注入甚至能把 Agent 本身变成攻击向量
“几乎对”的 bug	调查显示三分之二开发者被”几乎正确”的输出困扰——这些微妙的 bug 才是最贵的
不可维护的蔓延	没有架构意图生成出来的代码，变成没人敢安全修改的乱麻
能力鸿沟	你看不懂代码，Agent 卡住时你就无法调试——而它一定会卡住

量化[citation:2]：

指标	数字
含 OWASP Top 10 漏洞的 AI 生成代码	45%（Veracode）
失败率按语言差异	Java 约 72%，最可靠的 Python 仍有约 38%
220 万个 AI 生成代码片段中，引用不存在的包的次数	超过 44 万次
表示不完全信任 AI 生成代码的 IT 从业者	96%
使用 vibe coding 的医疗健康机构 / 金融服务机构	仅 28% / 34%——受监管行业仍需要大量治理

最后一行很说明问题：不是他们不想用，是治理还没跟上。

2.5 关于生产力：必须把两次实验一起讲

[citation:2]

实验	结果
METR 2025.7（16 位资深开源开发者，246 个真实任务，在他们已熟悉的仓库，用 2025 年初的工具）	用 AI 慢 19%，尽管事前预测会快 24%
METR 2026.2（同一方法论，换更新的工具）	估计快约 18%（新招募开发者 4%），但置信区间跨零

诚实的结论既不是”AI 让人变慢”也不是”AI 让人变快”，而是：答案严重依赖工具的成熟度、开发者对工具的熟悉度、以及任务被界定的清晰程度——而这恰恰是 vibe coding 的原始定义刻意忽略的三个变量。

---

三、从 Vibe 到 Agentic Engineering：为什么必须改名

3.1 改名这件事本身

2026 年 2 月 4 日——恰好是他原始 vibe coding 推文的一年后——Karpathy 提出 “agentic engineering”[citation:28]。同年 4 月 30 日，他在 Sequoia Ascent 2026 的炉边谈话中正式阐述[citation:28]。

他给的核心区分[citation:28]：

	Vibe Coding	Agentic Engineering
定位	抬高了地板（raise the floor）——让非专家程序员也能做东西	抬高了天花板（raise the ceiling）——把实现整个特性、重构子系统委托给自治 Agent
人机界面	人类仍是作者，逐行接受/拒绝建议	人类成为**“艺术与科学”的实践者**：写规范、监控 Agent 行为、审计结果
产出	原型	生产特性

时间点判断[citation:28]：他把 2025 年 12 月确定为”智能体拐点”——Agent 开始可靠地处理更大块、更连贯的代码，足以改变工作流。

有意思的是他自己的感受[citation:28]：

他承认这个拐点让他觉得”作为程序员，我从未如此落后过”。

3.2 他自己的翻车故事（这个最值得记）

[citation:28]

Karpathy 没有把 agentic engineering 描绘成无摩擦的。他举了自己的 MenuGen 项目——一个菜单生成应用——Agent 产出的支付集成里有一个 bug：Stripe 与 Google 认证之间的邮箱不匹配，开发期间未被发现。

为什么这个案例重要？ 因为它展示的失败模式不是幻觉，也不是逻辑错误，而是一个人类审阅者同样可能漏掉的微妙集成错配。

结论：agentic engineering 的瓶颈不是 Agent 的能力，而是验证基础设施。

这一点与第七篇的判断完全吻合。

3.3 Software 3.0：一个更大的框架

[citation:28]

	基本单位	应用逻辑由什么构成
Software 1.0	显式代码	人写的指令
Software 2.0	训练好的神经权重	数据
Software 3.0	上下文窗口	提示与工具配置

含义是架构性的：如果上下文窗口成为新的”程序”，那么在长上下文上维持连贯状态的能力就成了关键性能指标——而不是孤立任务上的基准分数。

3.4 业界的回应

[citation:32]

观点	内容
Gene Kim（《Vibe Coding》作者）	“vibe coding 会是被记住的那个词——精灵已经放出来了。“（他原本想给书起名”vibe engineering”，但”没人知道那是什么”）
Andrew Cornwall（Forrester）	“vibe coding 很适合原型，但对棕地或生产代码就不太妙了。”
Diego Lo Giudice（Forrester）	2024 年 Q4 就预测”vibe coding 将在 2026 年底前转变为 vibe engineering”。两个维度：公司只有在后面跟着强工程化产品化流程时才能采用；以及”有一种只有懂软件工程的人才能真正成功的工程艺术”
David Mytton（Arcjet CEO）	“只有在有明确护栏时才奏效——好的代码文档，以及 Agent 可以运行的全面测试。这正是 vibe coding 与 vibe engineering 的区别。”
Mayank Agarwal（Resolve AI CTO）	“产出代码的速度赶不上有效吸收它的速度，没有正确的工程实践，agentic 工作流只会以机器的速度制造技术债。”

最后一句是我见过对这个领域最精准的概括之一。

---

四、Harness Engineering：两个源头，一个定义

4.1 Hashimoto 的定义（最实用的一句）

[citation:10]

“任何时候你发现 Agent 犯了一个错误，你就花时间去设计一套解决方案，使得这个 Agent 永远不会再犯这个错误。”

这句话的实践价值在于它给出了一个可执行的动作：不是改提示词重试，而是改系统。

4.2 为什么它和上下文工程容易混淆

Birgitta Böckeler 的模型说得很清楚[citation:4]：

上下文是 Harness 中”模型读的那部分”；Harness 还包括那些会行动和验证的部分。

	提示工程	上下文工程	Harness 工程
管什么	怎么跟 AI 说	AI 看到什么信息	AI 运行在什么环境里
范围	单条提示	单次调用的全部输入	工具 + 权限 + 验证 + 状态 + 可观测性
失败信号	输出含糊、格式错	缺背景、答非所问	多步崩溃、死循环、结果不可预测
修法	改写提示词	重组输入数据	重新设计系统架构

一个实用的诊断流程[citation:10]：

单步任务上输出含糊或格式错误      → 提示工程问题。收紧指令。
Agent 缺关键背景、答错了问题       → 上下文工程问题。调整输入组装。
Agent 中途崩溃、进入循环、跨多步不可预测 → Harness 工程问题。重新设计系统。

这个诊断能防止白费力气。 很多开发者在 Agent 搞砸一个多步任务时去改提示词——真正的问题几乎总是缺失的验证循环或坏掉的状态管理，那是任何提示词改动都修不了的 Harness 层问题[citation:10]。

4.3 三层是叠加而非替代

[citation:10]

有效的 harness 工程师必须懂上下文工程；有效的上下文工程师必须懂提示工程。 建一所学校，需要知道怎么编教材和怎么出考题。

---

五、Harness 的解剖：六层结构与四个子系统

5.1 六层结构

[citation:1]

graph TD
    A["① 说明 Instructions<br/>AGENTS.md / CLAUDE.md"] --> B["② 上下文 Context<br/>给正确的信息，而非更多"]
    B --> C["③ 工具 Tools<br/>文件、终端、检索、MCP"]
    C --> D["④ 权限 Permissions<br/>能做什么、什么需要批准"]
    D --> E["⑤ 工作流 Workflow<br/>计划→执行→验证的循环"]
    E --> F["⑥ 状态与检查 State & Checks<br/>进度、会话、判定是否完成"]

层	做什么	关键原则
① 说明	定规则。保持简洁明晰，并提供指向架构、测试、安全、产品行为文档的链接	一段简短的 AGENTS.md / CLAUDE.md 是给 Agent 的入口指南
② 上下文	给正确的信息	不是越多越好
③ 工具	文件访问、终端、检索、MCP 服务器	工具即能力边界
④ 权限	什么能自动做、什么必须人类批准	最小权限
⑤ 工作流	计划 → 执行 → 验证的循环	每一轮循环后上下文被重建，所以模型永远能看到最新结果
⑥ 状态与检查	会话状态、进度、完成判定	模型可以说”我干完了”，但”是否通过检查”由 Harness 说了算

最关键的一句[citation:1]：

提示可以叫模型去跑测试，但真正能跑测试、并把结果回报给模型的那套系统，得由 Harness 提供。

5.2 四个子系统

另一种切法（更适合做架构设计）[citation:10]：

子系统	内容	对应
① 工具与权限	Agent 能调用什么、在什么沙箱里、什么需要批准	能力边界
② 上下文与记忆	看到什么、记住什么、怎么压缩	Guides
③ 验证与反馈	测试、linter、审查 Agent、运行时观测	Sensors
④ 可观测性	循环是否在漂移、烧了多少 token、失败模式是什么	运维

5.3 Guides 与 Sensors 的清单（最重要的一张表）

把 Harness 拆成这两类，是所有实践里最可用的心智模型[citation:4]：

Guides（让正确结果更可能）	Sensors（抓住错误结果）
AGENTS.md / CLAUDE.md	单元测试 / 集成测试
Skills（意图与流程外化）	类型检查器
规范文档（SDD，见第七篇）	Linter / 格式化器
代码示例与既有模式	SAST / 密钥扫描
代码图谱与检索索引	架构约束测试（architectural fitness functions）
类型定义与接口契约	审查 Agent（与执行者分离）
提交模板与 PR 规范	运行时观测（日志/指标/追踪）

判断一个 Harness 好不好，就问：这两类各自有几件？ 只有 Guides 没有 Sensors，Agent 会自信地跑偏；只有 Sensors 没有 Guides，Agent 会反复撞墙。

---

六、案例深读一：OpenAI 的百万行零手写实验

这是 2026 年这个领域被引用最多的实践，值得完整拆一遍。

6.1 实验设定与结果

[citation:19][citation:27]

项	数字
起点	一个空的 git 仓库
人工手写代码	0 行（这是刻意设的约束）
初始脚手架（仓库结构、CI 配置、格式化规则、包管理器、应用框架）	由 Codex CLI + GPT-5 生成
连最初的 AGENTS.md 都是 Codex 自己写的	—
5 个月后代码量	约 100 万行（应用逻辑、基础设施、工具、文档、内部开发工具）
PR 数	约 1500 个，已合并
团队规模	起步 3 名工程师驱动 Codex，后增长到 7 名
人均吞吐	3.5 PR/人/天，且随团队变大而提高
时间估算	团队估计约为手写所需时间的 1/10
使用情况	数百名内部用户，包括每日重度用户；产品上线、部署、出过故障、被修好，全部由 Agent 驱动
人工代码审查	不要求（人类可以审，但不是必须）

⚠️ 需要说明：这是 OpenAI 自己的工程博客自报，无独立验证。而且这是一个绿地项目（从空仓库起），不是棕地改造。

6.2 核心心法：不问”怎么让它更努力”，而问”缺什么能力”

[citation:19][citation:23]

早期进度比预期慢，不是因为 Codex 不行，而是因为环境被欠指定了（underspecified）——Agent 缺少朝高层目标推进所需的工具、抽象与内部结构。

于是工程团队的主要工作变成了让 Agent 能做有用的事。实践中表现为深度优先：

把大目标拆成更小的积木（设计、代码、审查、测试…）
    ↓
提示 Agent 去构造这些积木
    ↓
用这些积木解锁更复杂的任务

当某件事失败时，修复方案几乎从不可能是”再努力一点”。 因为唯一的推进途径是让 Codex 做完，人类工程师总是会介入并问： “到底缺的是哪一种能力，我们怎么让它同时对 Agent 既可读（legible）又可强制（enforceable）？”

一段要记住的经历[citation:23]：

头一个多月，速度大概只有 Ryan 自己正常写代码的十分之一。但正因为前面付了这笔”学费”，后面才搭出一整套工具与构建栈，让 Agent 最终能把整件事做下来。一旦这套东西成型，它的生产力就远远超过任何一个单独的工程师。

6.3 六个具体做法

① Ralph Wiggum Loop（PR 迭代闭环）[citation:19]

工程师描述任务 → 跑 Agent → 让它开 PR
    ↓
驱动一个 PR 走到完成：
    · 指示 Codex 在本地审查自己的改动
    · 请求额外的、特定的 Agent 评审（本地 + 云端）
    · 响应任何人类或 Agent 给出的反馈
    · 【循环迭代，直到所有 Agent 评审者都满意】

注意”直到所有 Agent 评审者都满意”这个终止条件——它是一个契约，不是感觉。

Codex 直接用标准开发工具（gh、本地脚本、仓库内嵌的 skills）来收集上下文，不需要人类把东西复制粘贴进 CLI。

② 把应用本身变得对 Agent 可读（Agent Legibility）[citation:27]

随着代码吞吐提高，瓶颈转移到人类 QA 的容量。因为人类时间和注意力是固定约束，团队转而让应用本身直接对 Codex 可读：

做法	效果
让应用按 git worktree 可启动	Codex 能为每个改动启动并驱动一个独立实例
把 Chrome DevTools Protocol 接入 Agent 运行时	给 Codex 提供操作 DOM 快照、截图、导航的 skills——它能自己复现 bug、验证修复、推理 UI 行为，不需要人类盯着
把可观测性暴露给 Agent：本地观测栈，每个 worktree 一个临时实例	Codex 能用 LogQL 查日志、PromQL 查指标

后者让这类提示变得直接可解：

• “确保服务启动在 800ms 内完成”
• “这四个关键用户旅程中，没有任何 span 超过 2 秒”

团队经常看到单个 Codex 运行在一个任务上工作长达 6 小时，常常发生在人类睡觉的时候。

③ 仓库知识作为”记录系统”——但不是大手册[citation:27]

团队试过”一个巨大的 AGENTS.md”方案，它以四种可预测的方式失败了：

失败方式	说明
上下文是稀缺资源	巨大的指令文件挤掉了任务、代码和相关文档，Agent 于是漏掉关键约束、或优化了错误的约束
过多的指导变成没有指导	当一切都是”重要的”，就什么都不重要。Agent 转为局部模式匹配，而不是有意地导航
它瞬间腐烂	单体手册变成陈旧规则的墓地。Agent 分不清什么还成立，人类停止维护，文件悄悄变成一个”诱人的麻烦”（attractive nuisance）
难以验证	一个大块头不适合覆盖率、新鲜度、归属权这类机械化检查，于是漂移不可避免

正确做法[citation:27]：

把 AGENTS.md 当作目录，而不是百科全书。

规模参考[citation:24]：OpenAI 的主仓库里有 88 个独立的 AGENTS.md 文件，每个包一个。这个按包拆分比看上去更重要——单个根文件在大型代码库上会撞到天花板。

社区里最常见的抱怨是：“AGENTS.md 在超过中等规模的代码库后就扩展不了。” 解法不是更大的文件，而是更多的文件：一个简短的根文件 + 每个包里一个嵌套文件，这样 Agent 总是读到与它正在碰的东西相匹配的指令[citation:24]。

④ 用测试强制架构与品味[citation:19]

架构约束不是写在文档里，而是由测试强制执行——这是把 Guide 变成 Sensor 的关键手法。

⑤ 合并哲学随吞吐改变[citation:19]

吞吐量变了，对”什么算一次好的合并”的判断也要跟着变。

⑥ 熵与垃圾回收[citation:19]

团队设置了后台 Agent 每天开小的清理 PR——持续对抗熵增。这对应 Loop 工程里的定时任务。

6.4 一分钟内部循环（Inner Loop）

[citation:23]

一个很有意思的工程决策：

问题	做法
为什么是”一分钟”？	想把 inner loop 压到尽可能快。“一分钟”是个很整、也确实能达到的目标
超过一分钟会 kill 掉吗？	不会。只是把它当作一个信号：现在得停下来重新梳理任务，把构建图谱拆得更细，直到复杂度降到阈值以下

Ryan 的原话：这是个棘轮机制——用强硬方式逼自己死守构建速度底线。 他提到自己现在做的软件构建时间已经 12 分钟了，“那体验特别差”。

还有一个模型换代带来的意外[citation:23]：

在 5.2 那一代，Codex harness 还没有后台 shell 能力，所以团队还能依赖阻塞式脚本做长任务。但到了 5.3 有了后台 shell 之后，模型变得没那么有耐心了，不太愿意一直卡在那儿等。

→ 模型升级时需要连代码库一起”换挡”。每一代模型都有自己的怪脾气。

6.5 关于成本

[citation:23]

Ryan 甚至直言：如果你现在每天还不用超过十亿 tokens，那几乎都快算得上”失职”了。按当前市场价格和缓存假设估算，这大概意味着每天两三千美元的 token 成本。

⚠️ 这是他个人的激进口径，不是行业基准。但它说明了这套打法的一个前提假设：token 足够便宜，于是人力注意力成为唯一真正的约束。

---

七、案例深读二：Anthropic 的长时运行双智能体

OpenAI 的案例是”绿地 + 无限 token”。Anthropic 给的是一套更通用、任何团队都能抄的两阶段模式。

7.1 要解决的问题

[citation:26]

简单地把一个能干的编码模型在项目上循环，不足以可靠地从一条宽泛指令产出生产质量的 Web 应用。实验中 Agent 经常：

• 一次试图实现太多，在中途耗尽上下文，留下半成品给后续会话去收拾；
• 后面的实例看到一个”看起来能跑”的项目，就过早宣布完成。

而上下文压缩（compaction）有帮助，但不能持续地给下一个会话一个清晰的”发生了什么”的账目[citation:26]。

7.2 两阶段结构

graph TD
    A["初始化 Agent<br/>只在任务开始时跑一次"] --> A1["写 init.sh 环境脚本"]
    A --> A2["创建 claude-progress.txt"]
    A --> A3["做一个基线 git commit"]
    A --> A4["把宽泛请求翻译成 200+ 条<br/>独立特性需求（初始状态=失败）"]
    A4 --> B["编码 Agent<br/>每个会话一次"]
    B --> B1["读 git log"]
    B --> B2["读 progress 文件"]
    B --> B3["读特性列表"]
    B --> B4["选最高优先级未完成项<br/>一次只做一个特性"]
    B4 --> B5["浏览器自动化验证"]
    B5 --> B6["descriptive commit + 更新进度"]
    B6 --> B

初始化 Agent（只跑一次，不是每会话一次）[citation:22][citation:26]：

动作	作用
跑环境 setup 脚本（如 init.sh）并验证就绪	冷启动可复现
创建 claude-progress.txt	记录已开始、已完成、剩余
做一个基线 git commit	给编码 Agent 一个干净的起点
把宽泛请求翻译成 200+ 条独立特性需求	每条初始状态为”失败”，这样后续会话拿到的是一份具体的未完成清单，而不是”请根据项目外观判断是否完成”的邀请

编码 Agent（每次会话）[citation:22][citation:26]：

每个会话开始时，先读定位工件，再碰任何代码：
    git log --oneline -10      # 自基线以来提交了什么？
    cat claude-progress.txt    # 当前任务状态？
    cat features.md            # 还剩哪些特性，优先级如何？

一次只做一个特性，并且只更新 JSON 需求文件里的 passes 字段。Anthropic 明确警告 Agent 不要删除或编辑测试[citation:26]。

7.3 Git 提交作为跨会话记忆

[citation:22]

每条提交信息都是一份结构化的交接说明，记录：

• 实现了什么
• 哪些测试通过
• 下一个未完成的任务是什么

git log 成为人类与 Agent 都可读的会话进度审计轨迹。

一份 claude-progress.txt 长这样[citation:22]：

claude-progress.txt — updated 2026-03-10T14:32Z

Completed
  feat: user authentication flow (commit a3f92c1)
  feat: session management and token refresh (commit b87de04)

In Progress
  feat: profile page — INCOMPLETE, do not mark done until tests pass

Next Priority
  feat: notification preferences

Setup and gate reminders
  Run ./init.sh if environment is cold-started
  Use pytest tests/ as the completion gate before updating this file

7.4 两类失败与对应修复

[citation:22]

失败	修复
Agent 一次会话做太多——中途耗尽上下文，留下半成品	告诉编码 Agent 一次会话只做一个特性。Anthropic 的实践证实这个约束能防止上下文中途耗尽
Agent 过早宣布完成——测试还没过就标记特性完成	要求测试通过作为完成闸门，并在系统提示里写明这条规则。没有这条规则的 Agent 会乐观地自我报告

7.5 浏览器测试：一个被低估的传感器

[citation:26]

在 Web 应用实验中，Agent 会：

1. 启动本地开发服务器；
2. 检查现有应用仍然工作；
3. 用浏览器自动化创建对话、发送消息、接收响应，然后才继续。

Anthropic 说：显式的、人类风格的浏览器测试暴露了那些从代码检查、单元测试或 curl 请求中看不出来的 bug。

但这个方法不完整[citation:26]：Puppeteer MCP 看不到浏览器原生的 alert 弹窗，依赖它的特性更容易出错。Anthropic 也把”专门的测试/QA/清理 Agent 是否会最终胜过单一通用编码 Agent”留作开放问题。

7.6 什么时候不该用这套

[citation:22]

场景	为什么
短期或可预测的任务	一次上下文窗口能装下的任务，不需要初始化器、进度文件、多会话交接机制。维护成本超过收益
人类在环的工作流	如果人每个子任务后都审查并重定向，僵化的”单特性会话”增加了不必要的检查点摩擦
没有可靠 git 的环境	这个模式依赖 git log 历史作为跨会话记忆。没有 git，交接就退化为手工文件管理，且没有审计轨迹

7.7 惰性工具发现（Lazy Tool Discovery）

[citation:22]

保持活动工具集小，而不是一开始就把所有 schema 加载进来。

OPENDEV Agent 用惰性工具发现来压制上下文膨胀与推理退化：工具按需呈现给模型，而不是在构造时全部注册。子 Agent 仍从 spec 编译到运行时并共享工具注册表，但每个子 Agent 通过 schema 过滤只暴露它实际会用到的那些。

一次会话只为它真正去拿的那些工具付 schema 成本。 这与第七篇讲的”上下文里放 5–8 个工具优于 40+ 个”是同一条原则。

7.8 内循环六阶段

[citation:22]

阶段	内容
① 预检与压缩	评估上下文压力，必要时压缩
② 思考	可选的扩展推理
③ 自我批评	在提交之前评估方案
④ 行动	带工具 schema 的 LLM 调用
⑤ 工具执行	运行被选中的工具
⑥ 后处理	更新状态，检查终止条件

---

八、五层技术栈：Framework / Harness / Runtime / Sandbox / Control Plane

这是 2026 年最容易搞混的一组概念。按”做什么”而不是”叫什么”来定义[citation:6][citation:9]。

8.1 四层（加控制平面为五层）

graph TD
    A["Purpose<br/>指令 + 工具，加在模型上"] --> B["Harness：循环<br/>（直接采用现成的，或用 framework 自建）"]
    B --> C["Runtime：状态、唤醒、伸缩、恢复"]
    C --> D["Sandbox：隔离执行模型写的代码"]
    E["Control Plane<br/>任务、归属、依赖、预算、评审"] -.治理.-> B
    E -.治理.-> C

层	做什么	典型例子	什么时候需要
Framework	给你造循环的零件：模型适配器、工具 schema、状态、图	LangGraph、CrewAI、Mastra、Pydantic AI、OpenAI Agents SDK、Google ADK	你想拥有控制流
Harness	一个已经造好的循环：调模型、跑工具、管理与压缩上下文	Claude Agent SDK / Claude Code、Codex、Pi、OpenCode、Deep Agents、Strands harness	你想要已被验证的 Agent 行为，而不想设计循环
Runtime	让 Agent 跨时间存活：持久状态、身份、唤醒、伸缩、恢复	camelRun、AgentCore Runtime、Cloudflare Agents、LangSmith Deployment	Agent 活得比一次请求长
Sandbox	隔离模型写的代码：文件系统、网络、CPU、内存限制	E2B、Modal Sandboxes、Vercel Sandbox、Firecracker、gVisor	模型写或运行了没人审阅的代码
Control Plane	治理工作本身：有哪些任务、谁负责、依赖什么、能花多少、谁必须审	Paperclip 这类组织工作层	多个 Runtime 协作、需要归属与预算

Framework 不是独立的一层，它是产出 Harness 层的一种方式。 Sandbox 挂在旁边，因为它为模型的代码而存在，不是为你的代码[citation:6]。

8.2 Framework vs Harness：一句判据

[citation:3]

判据	结论
你写不写那个循环？	如果你在声明边、条件、步骤序列 → Framework。如果你只提供工具和指令然后按开始 → Harness
它替你管理上下文吗？	Harness 必须管理，因为它拥有循环，长跑否则会填满窗口然后停止工作。如果文档里完全没提压缩、卸载、惰性工具加载，你大概在看一个 Framework[citation:3]

维度	Framework	Harness
你得到什么	组装用的原语	一个成品运行时
谁写循环	你	它自带
控制流	显式、由你编写	在固定循环内由模型驱动
上下文管理	通常要你自己建	内置且非可选
沙箱	自带你的	通常已包含
审批	你自己接闸门	可配置，开箱即用
首个 Agent 的时间	天	小时
上限	你能设计出来的任何东西	这个循环允许的任何东西
何时失效	需求超出了你的图	你的流程需要循环不支持的形状[citation:3]

8.3 为什么这两个词会被混用

[citation:3]

原因	说明
① 有些产品两者都是	deepagents 是 LangChain 建在 LangGraph（framework）之上的 harness——自带完整循环、规划、虚拟文件系统、子 Agent 与记忆，行为像 harness；底下是个图。Microsoft Agent Framework 也类似，既发编排原语，也在上面发一个有主张的 harness 层
② 营销跟着搜索量走	“Framework”是多年既定术语、流量更大；“Harness”从 2026 年才开始出现。很多 harness 仍自称 framework
③ 界线随产品成熟而移动	Framework 加有主张的默认值，开始像 harness；Harness 暴露 hook，开始像 framework

结论：别看标签，看行为。[citation:3]

8.4 一个”谁拦得住”的责任表

这是判断该在哪一层加控制的关键[citation:9]：

层	能拦住一次工具调用吗？	能恢复一次运行吗？	会话结束后还保留任务归属吗？
Framework	只在你自己建了的地方	是，如果你建在它的持久化上	不天然具备，需要工作记录层
Harness	是，通过其审批策略	是，在它自己的会话状态内	不天然具备，需要工作记录层
Coding Runtime	是：权限规则 + 沙箱	是：自己的会话	不天然具备，需要工作记录层
Control Plane	自己原生的 shell/文件工具：否；接入的 MCP/HTTP 工具：是	可以再次运行负责人，但不重放另一个 runtime 的状态	是

最后这一列是 2026 年最容易被忽略的一层：会话会结束，知识不应该结束（见第九组件 ⑧）。

---

九、组件目录：12 个可插拔零件

这一节是全文最实用的部分。每个零件给出：是什么 / 解决什么 / 怎么做 / 关键细节。

① 指令文件：AGENTS.md / CLAUDE.md / .cursor/rules

解决：Agent 因为不知道测试命令、命名约定、“哪个模块谁都不能碰”而瞎猜。

三种格式的对照[citation:20]：

维度	AGENTS.md	CLAUDE.md	.cursor/rules/
维护方	多工具社区标准	Anthropic	Cursor
被谁读	Claude Code（通过 import）、Codex CLI、Gemini CLI、OpenCode、Cursor	仅 Claude Code	仅 Cursor
格式	纯 Markdown	纯 Markdown + @imports	.md/.mdc + YAML frontmatter
嵌套	分层目录中的 AGENTS.md 会被逐级走访	子目录 CLAUDE.md 惰性加载	项目根单一目录
路径作用域	隐式（放在子目录里）	.claude/rules/ + paths: glob	globs: frontmatter
导入	无	@path（最多 5 跳）	无
规模建议	惯例不一	200 行以内（Anthropic 文档）	无明确限制
多工具友好	✅ 为此而设计	❌	❌

写什么[citation:24]：项目概览、构建与测试命令、代码风格、测试说明、安全注意事项、PR/提交规则。

关键细节[citation:24]：

你列进去的测试命令会被自动执行。 Agent 会尝试运行相关检查并在完成前修好失败。所以一行精确的 pnpm test 不是一条备注，是一条 Agent 会执行的指令。

四条写作原则[citation:24]：

原则	例子
短	目标 200 行以内；更长的文件会吃掉上下文，且实际上降低 Agent 的遵循度
具体	“用 2 空格缩进”胜过”好好排版”；“提交前跑 npm test”胜过”测一下你的改动”
可验证	把规则写得具体到能被机械检查
一致	两条规则矛盾时 Claude 可能任意挑一条，定期检查嵌套文件

分层策略[citation:24]：根 AGENTS.md 简短 + 每个包一个嵌套文件。OpenAI 主仓库有 88 个 AGENTS.md，一包一个。

⚠️ 一个反直觉的坑：把 CLAUDE.md 拆成 @import 不会减少 token——被导入的文件仍在启动时加载。它帮助的是组织，不是体积[citation:24]。

社区评价[citation:24]：

“AGENTS.md 极其重要——它大概是你能给 Agent 的杠杆最高的东西。它被注入每一轮，而 Agent 是被训练来遵循指令的。如果说有什么问题，我觉得人们在 AGENTS.md 上投入不足，过于依赖感觉。“（Hacker News）

② Skills（意图外化）

解决：Agent 每次运行都是冷启动，会用自信的猜测填补你意图里的任何缺口。

格式（两家工具一致）[citation:25]：

.claude/skills/triage/SKILL.md    （Codex: ~/.agents/skills/triage/SKILL.md）
---
name: triage
description: 读取昨天的 CI 失败、开放 issue 与近期提交；
             把每条发现写成 STATUS.md 中的一个任务。
---
1. 拉取失败的 CI 并按根因聚类
2. 把每条匹配到导致它的开放 issue 或提交
3. 每个真实发现写一条 STATUS.md 任务。跳过噪音。

触发机制[citation:25]：你按名字调用它，或当你的任务匹配它的 description 时自动触发——这正是一个平实、字面的 description 胜过巧妙的 description的原因。

没有 skill，每个循环都从零重新学习你的项目；有了 skill，循环每天早上都更锋利一点。

③ MCP（连接器）

解决：只能看文件系统的循环是个玩具。

# Claude Code
claude mcp add --transport http linear https://mcp.linear.app/mcp
# Codex
codex mcp add linear --url https://mcp.linear.app/mcp

[citation:25]

这是”Agent 说’这是修复方案‘“与”循环自己开 PR、关联工单、报告绿灯”之间的分界线。 因为两家工具都说 MCP，你为一家接的连接器通常能直接放进另一家。

详见第十二章。

④ Worktrees（并行隔离）

解决：两个 Agent 写同一个文件——就像两个工程师往同样的行上提交，却谁也不跟谁说话[citation:25]。

# Claude Code：每个 Agent 一个独立检出
claude --worktree feature-auth
# 或在子 Agent 的 frontmatter 里：isolation: worktree

# Codex：开线程时选 "Worktree"（每个一个 detached HEAD）

关键提醒[citation:25]：

Worktree 消除了碰撞，但没有消除瓶颈。你自己仍然是天花板。 无论你启动多少个 Agent，你自己的审阅带宽决定了你能信任多少个。

⑤ 子 Agent：Maker / Checker 分离

解决：一个模型审查自己的工作，每次都会给自己通过。

[citation:25]

# Codex: .codex/agents/reviewer.toml
name = "reviewer"
description = "对抗式 PR 审查者：正确性、安全、缺失的测试。"
developer_instructions = "像所有者一样审查。除非 diff 证明作者是对的，否则假定作者是错的。"
model_reasoning_effort = "high"

# Claude Code: .claude/agents/reviewer.md frontmatter
# name: reviewer
# description: 对抗式审查者。任何代码改动后使用。
# model: opus

成本提醒[citation:25]：第二意见要花 token，因为每个 Agent 跑自己的模型和工具——把这笔钱花在”错了代价高”的地方。

⑥ /loop 与 /goal（循环原语）

[citation:25]

原语	是什么	细节
/loop	一个 skill（不是内置命令），在你的会话开着时按节奏重复运行一个提示	—
/schedule	recurring cloud jobs 叫 Routines，最小间隔 1 小时，合上笔记本也继续跑。没有本地 crontab
/goal	运行到你写的条件为真为止；每一轮之后由一个独立的、更小的模型检查你是否真的完成了	写代码的 Agent 不给自己打分

# Claude Code：跑到真正完成，而不是"感觉完成"
/goal all tests in test/auth pass and the lint step is clean
# Claude Code：定时云任务（最小 1 小时）
/schedule daily PR triage at 9am

把停止条件写成一份契约。 “所有 test/auth 里的测试通过”是一份契约；“让它更好”是让循环跑到发薪日的写法[citation:25]。

⑦ 上下文压缩与惰性工具加载

见第七章 7.7。核心是保持活动工具集小。

⑧ 进度文件与 git 作为跨会话记忆

见第七章 7.2–7.3。

会话结束就丢弃符号图、约定、“这里为什么这么怪”的注释、被否决的设计，相当于对你团队辛苦换来的判断执行 rm -rf .git（第七篇第四章引过这句话，放在这里更贴切）。

⑨ 沙箱

见第十一章。

⑩ 权限与审批

• Harness 通过审批策略决定一次工具调用能否执行[citation:9]；
• 原则：最小权限 + 不可逆动作人工确认（第七篇第十三章）；
• 一个具体教训：给 Agent 的 shell 环境里不要放密钥（第七篇第十二章）。

⑪ 把可观测性暴露给 Agent

见第六章 6.3。这是把”运行时假设”这类最难的失败变成可验证项的关键一步——直接对应第七篇的痛点六。

⑫ Spec / SDD（规范驱动）

见第七篇第十一章。规范是最高杠杆的 Guide，因为它把意图从”每次对话里重新说一遍”变成”写在仓库里、可版本化、可机械检查”。

零件速查表

零件	类别	解决	代价
AGENTS.md（分层）	Guide	不知道约定/命令	需要维护，会腐烂
Skills	Guide	每次冷启动	需要写好 description
Spec / SDD	Guide	意图模糊	前期投入
代码图谱/检索	Guide	仓库太大	需要索引基建
MCP 连接器	能力	只能看文件系统	每个连接器是攻击面
Worktree	隔离	多 Agent 互相踩	你的审阅带宽仍是瓶颈
子 Agent 审查	Sensor	自己审自己必过	token 成本
测试/linter/类型	Sensor	缺陷与回归	需要已有测试文化
/goal 独立判定	Sensor	过早宣布完成	停止条件要写得像契约
进度文件 + git	记忆	会话结束即失忆	短任务上是负担
沙箱	隔离	执行未审阅代码	冷启动与成本
可观测性暴露	Sensor	运行时假设	需要先把日志/指标建好

---

十、框架生态实测对照

10.1 综合评分（2026 年 7 月 8 日测量）

[citation:30]

排名	框架	定位	最终分
1	LangGraph	图编排，企业默认选择；v1.2.8，1.0 GA 于 2025 年 10 月，Uber/LinkedIn/Klarna 在生产	8.5
2	OpenAI Agents SDK	OpenAI 模型上的轻量 handoff 式 Agent	8.3
3	Microsoft Agent Framework	AutoGen + Semantic Kernel 的继任者，.NET 与 Python；1.0 GA 于 2026 年 4 月带 LTS	8.1
4	CrewAI	角色式多 Agent 团队，业务流程友好	7.8
5	Claude Agent SDK	Harness 范式：给模型一台电脑	7.7
6	Google ADK	接入 Google Cloud 的多语言 Agent 工具包	7.3
7	n8n	带嵌入式 Agent 节点的可视化工作流自动化	7.1
8	Pydantic AI	面向 Python 团队的类型安全 Agent 流水线	7.0
9	smolagents	极简 code-first，写 Python	6.7
10	Mastra	TypeScript 原生 Agent 框架	6.5

两个观察[citation:30]：

1. 前三名只差 0.4 分——LangGraph 赢在生态广度与已验证的生产规模，不是因为替代品弱；
2. AutoGen 完全没出现，它的继任者在第 3 名。AutoGPT、SuperAGI、Fixie 这些 2025 年榜单上的常客也都不在了。

10.2 一份很能说明问题的实测

同一台 Linux 机器、同一模型（claude-haiku-4-5）、同一个问题、每家跑 10 次，做一个”带一个自定义工具的账单助手”[citation:34]：

框架	安装	依赖包数	体积	代码行数	中位延迟	输入 token（均值）	工具调用成功
Vercel AI SDK	11s	15	53 MB	~16	2.5s	1,371	10/10
Pydantic AI	11s	28	58 MB	15	2.2s	1,338	10/10
LangGraph	19s	39	81 MB	~14	2.5s	1,288	10/10
OpenAI Agents SDK	23s	43	88 MB	16	2.5s	1,352	10/10
AG2	20s	36	93 MB	~28	2.8s	1,336	10/10
Google ADK	~1min	53	115 MB	~20	3.4s	1,394	10/10
Mastra	~45s	240	176 MB	29	2.2s	1,371	10/10
Claude Agent SDK	~40s	33	299 MB	~28	8.5s	34,989	10/10
CrewAI	~2min	143	856 MB	21	4.0s	1,432	10/10

四个读法[citation:34]：

观察	含义
① 可靠性是九方平局	90 次运行全部正确调用了工具。在这个难度上，框架之间无差别——差别在别处
② Claude Agent SDK 的输入 token 是别人的 25 倍（34,989 vs ~1,300）	这是整套数据里最重要的一行。因为它不是”一个库”，它是一台电脑——自带完整的文件系统、终端、工具链上下文
③ 延迟 8.5s vs 2.2s	同上，是”harness 自带世界”的代价
④ 安装体积差异巨大	CrewAI 为了一个单工具账单机器人，装进了 Kubernetes client、Apache Arrow 和一个向量数据库[citation:34]

这张表把”Framework vs Harness”的抽象区别变成了可测量的东西：Harness 让你少写控制流，但要为它自带的世界付 token、延迟和体积。

10.3 选型建议（按场景）

[citation:34]

场景	首选
TypeScript 团队交付生产 Agent	Mastra
Python 里复杂的有状态工作流	LangGraph
全押 OpenAI 模型	OpenAI Agents SDK
JS/TS 应用逐步长 Agent 能力	Vercel AI SDK
Python 类型安全	Pydantic AI
快速做多 Agent 原型	CrewAI
开箱即用的 Harness（且你原生用 Claude）	Claude Agent SDK
已深度使用 Google Cloud	Google ADK
新项目	⚠️ AutoGen / AG2：历史上重要，2026 年难推荐

---

十一、沙箱对照：四家的数字

每个会写代码、跑测试、处理 CSV 的 Agent 都需要一个亚秒级启动、任务结束就销毁的隔离环境[citation:31]。

11.1 三家核心指标

[citation:31]

指标	Daytona	E2B	Modal	Vercel Sandbox
冷启动	~90ms（优化配置 27ms）	~150ms	亚秒级	快（未公布）
隔离技术	容器（Docker/Kata/Sysbox）	Firecracker microVM（每沙箱独立内核）	gVisor	Vercel 基础设施（专有）
沙箱内 GPU	是	否	是（T4 到 H100）	否
语言	Python、TypeScript	Python、JS/TS、R、Java、Bash	Python、JS/TS(beta)、Go(beta)	TypeScript、Python(受限)
CPU 价格	$0.0504/vCPU-hr	$0.0504/vCPU-hr	$0.1419/core-hr（3× 溢价）	$0.128/vCPU-hr（仅活跃 CPU）
内存价格	$0.0162/GiB-hr	$0.0162/GiB-hr	$0.0242/GiB-hr	$0.0212/GB-hr
免费额度	$200 计算额度	$100 额度 + 20 并发	月度免费计算	Hobby 配额

11.2 各自优化什么

产品	定位	关键细节
Daytona	速度领先者	亚 90ms 冷启动（营销称优化配置 27ms）。容器为默认，需要更强隔离时可切 Kata 或 Sysbox。预置集成面比 E2B 小，销售动作偏企业向[citation:31]
E2B	代码解释器老兵	第一个围绕 OpenAI Code Interpreter 模式建的沙箱。每次 runCode() 调用与上一次共享状态——Agent 能在同一会话里跨轮次累积变量、dataframe、训练好的模型。Firecracker microVM + 每沙箱独立内核，是本类中最强的硬件级边界。5 种语言运行时。Pro $150/月，会话时长提到 24 小时。如果 Agent 的主循环是”写 Python → 执行 → 观察 → 重复”，E2B 仍是阻力最小的集成[citation:31]
Modal	唯一沙箱内带 GPU	如果 Agent 需要在跑模型工具调用的同一个隔离进程里做推理、微调或图像处理，Modal 是目前唯一严肃的选项。亚秒冷启动也适用于 GPU 沙箱，宣称可自动扩展到 5 万并发会话。代价：Sandbox CPU 费率是标准 Modal Functions 的 3 倍（$0.00003942 vs $0.0000131/核秒）；GPU 不乘这个系数（沙箱内 A100 40GB 仍是 $2.10/小时），但美国非抢占式负载还有区域与抢占系数合计 3.75×。第三方报告的真实数字：宣传的 10,000 CPU 小时 $471.60 月基价，叠加系数后变成 $1,768.50[citation:31]
Vercel Sandbox	爆发式、I/O 密集	最晚入局，带来最主张的计费模型：Active CPU——等待 I/O（网络调用、数据库查询、模型 API 响应）的时间不计入 CPU 计费。宣称对 I/O 密集负载比按墙钟计费省最多 95%，而这正是多数 Agent 循环的真实形态。无 GPU，Python 标为受限。结构性卖点：如果 Agent 已经活在一个 Vercel 部署的 Next.js 应用里，沙箱就在一次 import 之外，共享认证、可观测性与带宽池[citation:31]

选型一句话：纯 CPU 且循环是”写-执行-观察”→ E2B；要极致冷启动 → Daytona；循环里要 GPU → Modal（唯一）；Agent 已在 Vercel 上且循环 I/O 密集 → Vercel。

---

十二、MCP：这套体系的连接标准

📖 MCP（Model Context Protocol）：定义 Agent 如何发现并使用工具、读取资源、调用提示的开放协议。Anthropic 于 2024 年 11 月发布初始规范[citation:33]。

12.1 当前状态（2026-10 核实）

[citation:33]

项	状态
当前规范版本	2026-07-28
核心特性	无状态核心、无初始化握手、无协议会话
Tier 1 SDK	TypeScript、Python、C#、Go、Rust、Ruby 全部支持
传输	stdio（本地进程）+ Streamable HTTP（远程服务器）
授权	受保护的 HTTP 服务器用基于 OAuth 的授权发现
三个核心原语	tools（模型控制）、resources（应用控制）、prompts（用户控制）
治理	现归 Linux 基金会下的 Agentic AI Foundation（AAIF）（2025-12-09 成立，MCP、goose、AGENTS.md 为锚定项目）

12.2 三个官方扩展

[citation:33]

扩展	编号与状态	作用
MCP Apps	SEP-1865，Stable 2026-01-26	在兼容客户端（ChatGPT、Claude、VS Code、Goose、Postman）内加入交互式 UI 界面
Skills	SEP-2640，Final 2026-09-13	让服务器通过 MCP 发布可复用指令、脚本、参考资料与资产
Server Cards	SEP-2127，Final 2026-10-06	可选扩展，用于在连接之前描述一个远程服务器

Skills 扩展尤其值得注意：它把第九章组件 ② 从”本地文件”提升为”可通过协议分发”，这意味着团队可以把自己的工程规范作为一个 MCP 服务器发布出去。

12.3 路线图（尚未落地）

[citation:33]

方向	内容
服务器发起的事件	webhooks 与 channels，取代轮询
统一 HTTP 原生传输	把 Streamable HTTP 扩展到目前只能用 stdio 访问的本地服务器
Agent 身份	DPoP 采纳与 Workload Identity Federation，实现无长期令牌的委托
标准化工具结果处理与渐进式发现	服务器可以先暴露一个小入口，随对话收窄再逐步揭示大型工具目录

⚠️ 以上都还不是已发布的规范行为，只针对已发布特性构建。 发布时间上，SEP-3398（2026-10-14 接受）把规范发布改为三月与九月的节奏，周期重叠八个月；原定 2026 年 12 月的版本目标推迟到 2027 年 3 月 30 日——这是目标，不是承诺[citation:33]。

12.4 什么时候优先用 MCP

[citation:33]

当你把远程工具、数据或工作流暴露给外部 Agent 时，先实现 MCP。

它与第七篇讲的”MCP 作为确定性神谕的载体”（docker-mcp、safe-shell-mcp、jest-mcp）是同一个思路的两面：MCP 既让 Agent 能拿到数据，也让 Agent 能用确定性工具验证自己。

---

十三、如何组装：决策树与三档配置

13.1 先回答两个问题

[citation:3]

问题一：你的流程是"被发现"的还是"被设计"的？
    → 下一步取决于上一步发现了什么        → Harness
    → 有必需的形状，偏离就是正确性问题     → Framework

问题二：运行会长到让上下文管理成为最先崩掉的东西吗？
    → 会                                 → Harness（必须自带压缩）
    → 不会                               → Framework 也够用

13.2 三档配置（按团队成熟度）

第一档：个人 / 小团队起步（1–2 天）

组件	做法
指令文件	用 /init 生成初版 AGENTS.md，控制在 200 行内；monorepo 每包一个
Sensors	CI 里跑类型检查 + linter + 测试；把命令写进 AGENTS.md（会被自动执行）
规范	至少对”活过 6 个月 / 超过 2 人碰”的东西写简短 spec
供应链	依赖走校验脚本（第七篇第十二章）+ 锁文件入库
权限	不可逆动作人工确认

第二档：团队规模化（2–4 周）

组件	做法
Skills	把重复流程写成 skill（triage、review、release）
子 Agent	Maker/Checker 分离，审查者用不同模型
Worktree	多 Agent 并行时每人一个 worktree
沙箱	Agent 执行未审阅代码一律进沙箱（E2B / Daytona）
仓库索引	代码图谱 + 向量混合检索（别指望长上下文）
MCP	接 issue 追踪、CI、内部数据
完成判定	用 /goal 这类”独立小模型判定”的机制，而非 Agent 自报

第三档：长期自治（1–3 个月）

组件	做法
循环	/schedule 定时任务 + /loop 周期任务：每日 issue 分诊、CI 失败摘要、清理 PR
跨会话记忆	进度文件 + 结构化 commit 作为交接说明
可观测性暴露	Agent 能查日志（LogQL）与指标（PromQL）
应用可启动性	每个 worktree 可独立启动应用，Agent 能自己复现与验证
架构约束	由测试强制，而不是写在文档里
熵管理	后台 Agent 定期开小的清理 PR
Control Plane	记录任务归属、依赖、预算、谁必须审

13.3 一个完整的循环长什么样

[citation:25]

早上 9:00，一个定时自动化在仓库上启动
    ↓
调用 triage skill：读取夜间 CI 失败、开放 issue、近期提交
    ↓ 把每条真实发现写进 STATUS.md
    ↓
对每个值得做的发现：
    · 开一个隔离的 worktree
    · 派一个子 Agent 起草修复
    · 派【第二个】子 Agent 对照你的 skills 和测试审查它
    ↓
连接器开 PR 并更新工单
    ↓
处理不了的留在你的分诊收件箱
    ↓
STATUS.md 记住什么过了、什么还开着 → 明天从今天停下的地方继续

你醒来看到的是一份简短的交接，而不是一堵日志墙[citation:25]：

# 9:00am — 循环的夜间交接（你的分诊收件箱）
READY TO MERGE
  PR #218 fix flaky test in test/charts      CI green
  PR #219 retry webhook on 429, add backoff test   CI green
NEEDS YOU
  auth/session.ts — 有两种安全的修法，需要你定

13.4 什么时候不要用这套

[citation:21][citation:22]

场景	建议
一行修复、改名、配置微调	跳过循环。明确说”快速修复，跳过 brainstorming”是合法操作[citation:21]
探索性 spike（做完就扔）	规范与测试会拖慢你”搞清楚想要什么”的速度[citation:21]
短期、可预测的任务	不需要初始化器、进度文件、多会话交接[citation:22]
人类每步都在环	僵化的”单特性会话”增加无用摩擦[citation:22]
已有严格自有 workflow skills 的仓库	重叠的 skill 会互相打架——选一种方法论[citation:21]

---

十四、总结：总表、落地清单与三个判断

14.1 概念总表

概念	出现时间	解决什么	关键产物	与上一层的关系
提示工程	长期	怎么说	提示模板、结构化输出	—
上下文工程	2025.6	模型看到什么	AGENTS.md、skills、检索	包住提示工程
Harness 工程	2026.2	在什么系统里跑、能否自检	工具、权限、测试、沙箱、CI	包住上下文工程
Loop 工程	2026.6	何时跑、谁判定完成	/loop、/goal、定时任务、manager agent	包住 Harness 工程
Vibe Coding	2025.2	降低门槛	—	被”是否审阅”定义
Agentic Engineering	2026.2	抬天花板：委托生产特性	规范 + 编排 + 审计	Vibe 的继承者

14.2 落地清单（可直接勾选）

Guides（让正确结果更可能）

• 分层 AGENTS.md（根简短 + 每包一个），200 行内
• 把构建/测试命令写进去（会被自动执行）
• 重复流程写成 skill（description 平实字面）
• 长期项目写 spec，验收标准一对一映射到测试
• 仓库索引：代码图谱 + 混合检索

Sensors（在错误漏出前抓住）

• CI：类型检查 + linter + 测试 + SAST + 密钥扫描
• 子 Agent 审查（不同模型），Maker/Checker 分离
• /goal 式独立判定者，停止条件写成契约
• 依赖校验 + 内部镜像
• 沙箱执行未审阅代码
• 可观测性暴露给 Agent（这是唯一能抓”运行时假设”的传感器）

记忆与循环

• 进度文件 + 结构化 commit 作为跨会话交接
• 一次会话只做一个特性
• 后台定时任务：分诊、CI 摘要、清理 PR
• 每个 worktree 可独立启动应用

治理

• 权限最小化；Agent shell 里不放密钥
• 记录任务归属与预算（Control Plane 层）
• 度量完整周期时间，而不是”代码多快出现”

14.3 三个判断

判断一：这四个词不是术语通胀，是一条”杠杆转移”的时间线。

每过约一年，人们发现杠杆不在当前这一层了，于是给下一层命名：

怎么说（提示）→ 看到什么（上下文）→ 在什么系统里跑（Harness）→ 何时跑、谁判定（Loop）

驱动这条线的只有一个事实：模型能力在短期内是给定的、买来的、所有人都能拿到的。于是唯一能产生差异的，是模型周围的那套系统。

这也解释了为什么 Birgitta Böckeler 的”Agent = Model + Harness”是这两年最重要的一句公式——它把竞争力从”你用哪个模型”移到了”你给模型配了什么”。

判断二：Harness 的本质是把”工程判断”从人的脑子里搬到仓库里。

看 OpenAI 那个实验最反直觉的地方：三个工程师、零手写代码、1500 个 PR、百万行。表面上是”AI 在写代码”，实际上是——

原本在工程师脑子里的东西	被搬到了哪里
架构约定	由测试强制
“这里为什么这么怪”	分层 AGENTS.md
怎么复现 bug、怎么验证 UI	Chrome DevTools Protocol 接入
怎么判断”服务够快”	LogQL/PromQL 暴露给 Agent
什么算做完	Ralph Wiggum Loop 的终止契约
代码整洁度	后台清理 Agent

所以 harness engineering 的产出不是代码，是一套”能被 Agent 读取、执行和验证的组织知识”。 这也正是为什么第七篇说”AI 让写代码变廉价，但没有让确认代码正确变廉价”——Harness 就是那个让确认变廉价的东西。

判断三：Vibe Coding 没有消失，它只是被划到了正确的边界内。

Karpathy 的原义（不审阅、只用于一次性项目）至今仍然成立——问题从来不是它错了，而是它被用错了地方。

三件事共同完成了这个”划界”：

事件	意义
Simon Willison 的定义	用”是否审阅”划出清晰边界
Karpathy 自己改名为 agentic engineering	“抬高地板”→“抬高天花板”，把生产场景正式分开
他自己的 MenuGen 翻车（Stripe/Google 邮箱不匹配）	最诚实的证据：不是幻觉，不是逻辑错误，而是一个人类审阅者同样可能漏掉的微妙集成错配

最后这件事最重要。它说明：进入 agentic engineering 之后，瓶颈已经不在 Agent 能不能写出来，而在我们有没有能力验证它写对了。

一句话总结：2025–2026 这一年半，软件工程真正在做的事情，是把”怎么写代码”这门手艺，改造成”怎么设计一个让代码能被可靠地写出来、并被确定性地验证”的系统——而 vibe coding 是这条路上第一个、也是最响亮的路标，不是终点。

---

附：本文关键来源说明

类型	来源性质	使用原则
方法论四层与时间线	行业综述（Agentastic、AI Workflow Pro）[citation:4][citation:10]	直接采用，含命名时间与人物
OpenAI 百万行实验	OpenAI 官方工程博客[citation:19]，及 InfoQ 对作者播客的整理[citation:23]	标注为厂商自报，且明确是绿地项目
Anthropic 双智能体	Anthropic 工程博客及解读[citation:22][citation:26]	直接采用，含”方法不完整”的自述
Vibe coding 与 agentic engineering	多方报道与 Karpathy 本人公开表述[citation:2][citation:5][citation:8][citation:28][citation:32]	三种定义并存已说明；生产力数据含 METR 两次结果
五层技术栈	技术博客（camelAI、TrueFoundry、Paperclip）[citation:3][citation:6][citation:9]	采用”按行为定义”的划分
框架实测	O-mega 评分（2026-07-08）[citation:30]、AgentMail 实测[citation:34]	标注测量日期与方法；九方可靠性平局已如实说明
沙箱对照	StartupHub 对照（2026）[citation:31]	价格与冷启动为厂商文档口径
MCP	Agent Surface 文档（2026-10-29 核实）[citation:33]	明确区分已发布与路线图
指令文件三-way 对照	The Prompt Shelf、eesel AI[citation:20][citation:24]	直接采用

⚠️ 四点必读提醒：

1. OpenAI 的百万行实验是厂商自报的绿地极端案例（空仓库、无历史包袱、内部无限 token、无速率限制）。它证明的是可能性上限，不是典型团队的可复制路径——同一个团队也承认”头一个月只有人工速度的十分之一”；
2. 框架评分与实测都是单一时点（2026 年 7 月）。而且实测显示在简单任务上九方可靠性平局——差异只在 token、延迟、体积与生态，不在能不能做对；
3. “Harness”与”Framework”的界线随产品成熟而移动，很多产品自称 framework 实为 harness。请以行为（谁写循环、是否管理上下文）而非标签判断；
4. 本文事实截至 2026 年 10 月 29 日。MCP 规范、框架生态与沙箱定价更新极快，落地时应以当期官方文档为准。