Table of contents
Open Table of contents
三篇文章改变了我对 AI Agent 的理解
2026 年 2 月，三篇博客几乎同时出现：
- Ramp 的 Inspect — 每个 coding task 跑在 Modal 沙箱里，任务隔离，自我验证，人看到之前先过一遍自检。
- Stripe 的 Minions — 他们提出 “Blueprint” 模式（确定性脚手架包裹 LLM 推理），限制 CI 迭代次数（因为收益递减很快），shift-left feedback（本地先跑测试再 push）。
- 一篇 USCardForum 的帖子 — 这篇最触动我。作者说 AI Agent 有一个结构性盲区：它不能质疑自己的前提。它优化的目标是”完成任务”，而不是”确认自己是对的”。
我之前一直在跑自己的 issue-hunter 工具 — 单 agent 脚本，自动找 GitHub issue，写修复，开 PR。能用，有时候。但失败的模式永远一样：agent 陷入循环、重复造已有的函数、或者自信满满地提交一个根本没修对的 fix。
这三篇文章帮我理解了为什么。
一个 Agent 做所有事，注定失败
一个 agent 同时负责读 issue、探索代码库、写实现、跑测试、创建 PR — 就像让一个人同时当架构师、开发、测试和 code reviewer。看同一份代码。用同一个脑子。
失败模式是可预测的：
信息茧房。 Agent 早期锁定方案 A。A 不 work，它就试 A’、A”、A'''。它永远不会退一步问”我应该试试 B 吗？” 人类自然会做这件事 — 我们叫它”睡一觉再想”或者”问下同事”。Agent 不睡觉，也没有同事。
没有元认知。 Agent 无法思考”自己在想什么”。它无法判断当前方向是有希望的还是死路一条。它就是……继续往前走。USCardForum 那篇帖子说得精准：人有能力判断当下的状态，拒绝将错就错。Agent 没有这种能力。
上下文污染。 一个 agent 连续处理多个任务时，状态在任务间泄漏。我曾经收到一个 PR，里面包含了完全不相关的另一个 issue 的改动，因为 agent 的工作目录没清干净。
Orbit：不是更聪明的 Agent，是更聪明的使用方式
你（编排者）
│
├── Scout agent → 探索 repo，保存约定
│
├── Router → 评估复杂度，选择 agent 类型
│
├── Hunter agent（后台）← 简单 issue
├── Hunter agent（后台）← 简单 issue
├── Hunter-Pro agent（后台）← 复杂 issue
│
├── Verifier agent ← 独立审查
│
└── Reworker agent ← 根据 verifier 反馈修复
核心思路，从那三篇文章里偷来的：
1. 状态存在文件里，不存在 Agent 脑子里
受 Ramp 和 lean-collab 的 “Ensue Memory” 模式启发。每个任务的全生命周期存在 .orbit/tasks.json 里：
{
"id": "4a5266b3",
"state": "rework",
"pr_url": "https://github.com/tw93/Kaku/pull/155",
"verify_feedback": "实现过重，复制了整个文件",
"rework_attempts": 1
}
Agent 不需要记住发生了什么。文件替它记。Agent 崩溃、超时、context 爆了 — 状态依然在。另一个 agent 可以接着干。
这是最关键的设计决策。Context window 又贵又脆弱。文件免费且永久。
2. 一个任务，一个目录
每个 agent clone 到 /tmp/orbit-{task_id}/。不是当前目录，不是共享工作区。
这是血的教训。第二轮跑的时候，两个 agent 都把 googleworkspace/cli clone 到了同一个 cli/ 目录。Agent B 捡到了 Agent A 的未提交改动。PR 里两个不同 issue 的修复混在了一起。Verifier 抓到了 — “Scope: 1/2，包含了无关的 gmail scope 改动。”
隔离不是可选的。是结构性的。
3. 复杂度路由
不是每个 issue 都需要高级工程师。Router 评估每个 issue，按需分配：
| 信号 | Agent |
|---|---|
| 拼写错误、文档、配置 | Hunter（快速，最多 2 轮） |
| 有明确复现步骤的 bug | Hunter（快速，最多 2 轮） |
| 多文件、跨模块 | Hunter-Pro（深度分析，10 轮） |
| 架构变更 | 跳过 — 报告给人 |
简单 issue 的通过率：100%。复杂 issue：75%。知道什么时候不该用复杂 agent，和有这个 agent 一样重要。
4. 独立验证
USCardForum 那篇文章的核心论点：写代码的 agent 永远不应该是验证代码的 agent。
Verifier 是一个独立的 agent。它从没见过实现过程。它读 issue，读 PR diff，在四个维度打分：
- 相关性 (0-2)：改动是否对应 issue？
- 完整性 (0-2)：修复是否完整？
- 正确性 (0-2)：逻辑是否正确？
- 范围 (0-2)：改动是否最小化、聚焦？
PASS 要求 ≥ 6/8 且没有任何维度为 0。实际抓到的问题：
- 一个 PR 重复实现了已存在的
get_logs_dir()函数（2/8 — FAIL） - 一个 PR 复制了整个 137 行文件只为改 3 行（5/8 — FAIL）
- 跨任务污染，不相关改动泄漏进来（6/8 — 勉强 PASS）
Verifier 不比实现者更聪明。它只是从不同角度看。这就够了。
5. 反馈闭环
Verifier 失败时，任务进入 “rework” 状态。Reworker agent checkout 已有的 PR 分支，读 verifier 的具体批评，做外科手术式的修复。不是重写 — 是定向改进。
Agent 提交 PR → Verifier: FAIL "过度工程化，复制了整个文件"
→ Reworker: checkout 分支，简化为 3 行 patch，push
→ Verifier: PASS (8/8)
最多一次 rework。失败两次，那是人该介入的问题。
6. Repo Knowledge — 学会规则的 Agent
这是三篇文章都没有准备我面对的。
我把 Orbit 跑在 openclaw/openclaw 上。Agent 提了个 PR。五分钟后，一个 bot 关掉了它：
“Closing this PR because the author has more than 10 active PRs in this repo.”
Agent 不知道这个规则存在。它怎么可能知道？不在 issue 里，不在 README 里，不在任何代码里。这是一个 bot 配置，你只有撞墙了才会发现。
所以我加了 Scout agent。在往新 repo 派遣任何工人之前，scout 先去探索：
- 分支命名规范
- 测试命令
- PR 模板
- Bot 规则（PR 数量限制、CLA 要求）
- 从最近被关闭的 PR 里发现的坑
全部保存到 .orbit/repo-knowledge/openclaw-openclaw.md。后续 agent 开工前先读这个文件。它们在踩坑之前就知道规则。
这是让 agent 真正能给开源项目做贡献的那块拼图。每个 repo 不一样。每个 repo 有不成文的规则。不学这些规则的 agent 会反复撞墙。
数据
两轮跑了 4 个 repo（HKUDS/nanobot, tw93/Kaku, openclaw/openclaw, googleworkspace/cli），共 10 个 issue：
| 指标 | 结果 |
|---|---|
| 创建 PR | 10/10 (100%) |
| 验证通过 | 8/10 (80%) |
| 满分 (8/8) | 3 个 PR |
| 平均分（通过的） | 7.0/8 |
| 简单 issue 通过率 | 100% |
| 复杂 issue 通过率 | 75% |
第一轮（单 repo，无 harness 优化）：67% 通过率。 第二轮（多 repo，有隔离 + 验证）：86% 通过率。
提升完全来自 harness，不是更好的模型。
天花板在哪
方向问题
Verifier 能抓住烂实现。但抓不住错方向。如果 agent 决定通过新建 utility 文件来解决一个应该改已有模块的 issue，verifier 可能还是会 pass — 逻辑对了，测试过了，范围合理。但路子是错的。
人会看着这个 PR 说”等等，你为什么不直接改已有的 helper？” Agent 没有这种直觉。
卡住循环
即使有迭代限制，agent 还是会卡住。它用同一个方向的微小变体反复尝试，烧完迭代预算但不换策略。同一个 bug，人类会起身去倒杯水，重新读一遍报错信息，然后试一个完全不同的东西。
Agent 的 context window 是它的牢笼。它尝试过的所有方法都在那里，偏置它继续做类似的事。人类会忘记自己失败的尝试 — 而那种遗忘其实是有用的。
不成文规则（部分解决）
Scout agent 有帮助，但它只能抓到 repo 历史里可见的规则。有些规则是社群知识 — “别碰那个模块，正在重构”、“维护者偏好函数式风格”。这些存在 Slack 频道里，在贡献者的脑子里，agent 找不到。
插座与 Harness
Claude Code、Codex、OpenCode — 这些是 AI 时代的插座。标准化的 coding runtime，提供 LLM 推理、工具调用、agent 机制。
直接用插座也能工作。但就像直接拿电钻打孔 — 效率取决于你的手稳不稳。
Orbit、Ramp 的系统、Stripe 的 Minions — 这些是 harness。导轨、限位器、验证器。它们不让电钻更强力，但让每一钻都打在对的地方。
但 harness 不决定在哪打孔。那是人的事。
AI 的天花板不是算力，不是参数量，是它无法跳出自己的框架问”这个框架对吗？” 它能在约束内优化，但不能评估约束本身是否正确。
最高效的模式不是”人 vs AI”，而是：
人：方向、判断、策略
↓
Harness：编排、隔离、验证
↓
Agent：实现、测试、迭代
Harness 放大人的判断力。一个人，通过 Orbit，同时指挥 7 个 agent 跨 3 个 repo 干活。杠杆不在 agent 有多聪明 — 在人的判断力被乘了多少倍。
云计算时代，EC2 是插座，Kubernetes 是 harness。真正的价值在编排层，不在算力。
AI 时代，一样。