好。换成 Linus / Musk / Mario 的视角，直接开砍。

---

## 0. 先问最危险的问题

> **这个 harness 真的需要存在吗？**

第一性原理下的答案，先不是“怎么设计 harness”，而是：

> **一个 agent 要可靠地改代码，物理上、信息上、组织上，最少需要什么？**

答案就三件事：

1. **一个能跑代码和测试的隔离环境**（否则无法验证）；
2. **一个能产生 diff 并回滚的版本控制**（否则无法收敛、无法安全）；
3. **一个能在关键节点说“yes/no”的人**（否则无法承担责任）。

**就这三件。** 其他全部是工程修饰。

你上一版那 13 个模块？**先全部假设不存在。** 然后一个一个加回来，加不回来的那个，就是该删的。

> Musk: “如果你删掉的东西里没有 10% 后来要加回来，说明你删得不够狠。”

---

## 1. 砍掉之前那套架构，先列出“看起来必要”的东西

上一版里的模块：

1. Task Intake & Contract Builder
2. Agent Kernel
3. Self-Reflection Ledger
4. ACI / Tool Registry
5. Sandbox
6. Policy Engine
7. Tool Gateway
8. Verification Engine
9. Auto-Repair Loop
10. Human Review Console
11. PR Workflow
12. Repo Memory / AGENTS.md
13. Observer / Stability Monitor / Risk Scorer / Learning Loop / ...

**听起来都对。但 90% 是“给屎抛光”。**

第一性原理拷问每一个：**没有它，agent 还能不能完成任务？**

---

## 2. 一个一个砍

### ❌ 砍掉：Task Intake & Contract Builder

**质疑**：你为什么要一个“合同构建器”？

issue 本身就是合同。acceptance criteria 写不清楚，是**人**的问题，不是 harness 的问题。  
做一个 contract builder 只是把“人写不清需求”这个事实包装成一个组件而已。

**保留的最小核**：agent 启动时，必须能回答一句话——

> “完成的判定标准是什么命令返回 0？”

如果回答不出来，停。让人补。**这就是全部 intake 逻辑。**

不需要 schema，不需要 builder，不需要服务。一个字段：`done_when: <shell command>`。

---

### ❌ 砍掉：Self-Reflection Ledger（那个十几个字段的 JSON）

**质疑**：agent 真的需要维护 assumptions、confidence、context_map、risk.score 这些东西吗？

不需要。这些是**给人看的安慰剂**。

真正驱动 agent 下一步决策的，物理上只有两样：

1. **上一次动作的输出**（test 输出、编译错误、diff）；
2. **目标是否达成**（`done_when` 是否返回 0）。

LLM 自己会在 context 里推理这些。你把它结构化成 20 个字段，只是为了让 dashboard 好看。

**保留的最小核**：一个 append-only 的事件流。

```
event = {ts, action, output, done_check_result}
```

就这样。**没有 confidence、没有 risk score、没有 assumption list。** 需要的时候 grep。

---

### ❌ 砍掉：Policy Engine + Tool Gateway 的复杂 YAML

**质疑**：你列了 20 条 allow/ask/deny 规则。物理上，危险动作的本质是什么？

危险动作的第一性定义只有一个：

> **离开 sandbox 影响外部世界的动作。**

不是“修改 auth 目录”。auth 目录在 sandbox 里改，改坏了 rollback 就行，**它不危险**。

真正危险的是：

- `git push` 到 protected branch
- 网络出站到非白名单
- 读 secret
- 调用生产 API
- merge / deploy

**这些都在 sandbox 边界上。**

所以 policy engine 不需要 200 行 YAML。需要的是：

> **sandbox 默认什么都不能出去。要出去的东西，列一个白名单。**

白名单大概 5 行：

```
allowed_egress:
  - github.com/api  (read-only token)
  - npm/pypi registry
allowed_writes:
  - branch: agent/*
forbidden:
  - everything else
```

**Default deny。这一条规则替代了你上一版整个 policy matrix。**

> Linus: “你的策略矩阵品味有问题。20 条规则说明你没想清楚边界在哪。”

---

### ❌ 砍掉：Stability Monitor / Lyapunov V / Risk Scorer

**质疑**：你真的要给 agent 算一个 Lyapunov 函数吗？

不要。这是控制论隐喻用过头了。

物理上，agent 失控只有三种表现：

1. **同一个测试连续失败 N 次**（振荡）；
2. **diff 越改越大**（发散）；
3. **超过 token / time / $ 预算**（资源耗尽）。

三个 if 语句解决：

```python
if same_check_failed_n_times(3): stop_and_ask_human()
if diff_lines > budget: stop_and_ask_human()
if cost > budget or time > budget: stop_and_ask_human()
```

**不需要 V 函数，不需要 7 个权重，不需要 risk scorer。** 三个计数器。

---

### ❌ 砍掉：Auto-Repair Loop 作为独立模块

**质疑**：repair 和正常 implement 有什么本质区别？

没有。都是“看 observation，决定下一步”。

把它做成独立模块，是工程师的强迫症。Agent 自己在 loop 里看见测试失败，自然会修。**唯一需要的是 retry budget。**

**保留的最小核**：上面那三个计数器之一。**不需要 FailureKind 枚举，不需要分类器，不需要 hypothesis generator。** 这些都是 LLM 本来就会做的事，你不要替它做。

---

### ❌ 砍掉：Observer / State Estimator / Context Model / Risk Model / Human Model / ...

**质疑**：这些“model”物理上存在吗？

不存在。它们是文档，不是运行时对象。

LLM 的 context window 就是它的 state estimator。你做一个外部 state estimator，本质是在和 LLM 抢工作，而且做得比它差。

**保留的最小核**：只保留 LLM 自己拿不到的信息：

- 上次运行的命令输出（已经在事件流里）；
- repo 的根目录约定（一个 `AGENTS.md`）；
- 当前 diff（`git diff` 就够）。

**就这三个。不要 Repo Model，不要 Context Model。**

---

### ❌ 砍掉：Specialist Agents（Reviewer / Tester / Security / Docs sub-agents）

**质疑**：为什么需要多个 agent？

90% 的情况下，不需要。多 agent 是 2024 年的时髦病。

真正需要“另一个视角”的场景只有一个：**当前 agent 卡住了，需要 fresh context 重新看问题。** 这时候开一个新 session，把 failure ledger 喂进去，**这不是 sub-agent，这是 retry with reset**。

**保留的最小核**：一个 `reset_and_retry(with_summary)` 动作。**不要 ReviewerAgent class，不要 SecurityAgent class。**

---

### ❌ 砍掉：Evidence Pack / Review Cockpit / 复杂 HITL UI

**质疑**：人 review 的时候，物理上需要什么？

需要：

1. **diff**；
2. **测试结果**；
3. **agent 说的一句话：我做了什么、为什么、卡在哪**。

**这就是 GitHub PR。** 已经存在了 15 年。

不要做 review cockpit。不要做 evidence pack schema。**让 agent 开 PR，人在 PR 里 review。** 你做的所有 dashboard，没有人会用第二次。

> Linus: “GitHub PR 已经把这事解决了。你重新发明一个，只是为了在简历上写一行。”

---

### ❌ 砍掉：Learning Loop / Eval Pipeline / Trajectory Store（在 v0/v1 阶段）

**质疑**：你都还没让 10 个任务跑通，learning loop 学什么？

先跑 100 个真实任务，**手工**看失败模式，**手工**改 prompt 和 AGENTS.md。等手工改不动了，再做自动化。

> Musk 第 5 步：“自动化放在最后，不要先自动化错误的流程。”

---

## 3. 砍完之后，剩下什么？

```
┌─────────────────────────────────────────────────┐
│  1. Sandbox（container + git worktree）         │
│     - default-deny egress                       │
│     - 只能 push 到 agent/* branch               │
├─────────────────────────────────────────────────┤
│  2. Agent loop（一个 while 循环）               │
│     while not done_when_passes():               │
│         action = llm.decide(history, AGENTS.md) │
│         output = run_in_sandbox(action)         │
│         history.append((action, output))        │
│         if stuck(): break_and_open_pr()         │
├─────────────────────────────────────────────────┤
│  3. Tools（5 个，不是 15 个）                   │
│     - shell (in sandbox)                        │
│     - read_file / write_file (=patch)           │
│     - run_tests (= shell, 但显式语义)           │
│     - open_pr                                   │
│     - ask_human(question)                       │
├─────────────────────────────────────────────────┤
│  4. 三个 if 语句（stuck 检测）                  │
│     - same failure x3                           │
│     - diff > budget                             │
│     - cost/time > budget                        │
├─────────────────────────────────────────────────┤
│  5. GitHub PR（review 界面，免费的）            │
├─────────────────────────────────────────────────┤
│  6. AGENTS.md（repo-level 配置，一个文件）       │
└─────────────────────────────────────────────────┘
```

**就这 6 件事。** 不到 500 行代码可以跑起来。

---

## 4. 一张表：砍前 vs 砍后

| 上一版 | 砍后 | 原因 |
|---|---|---|
| Task Intake & Contract Builder | 一个 `done_when` 字段 | issue 就是合同 |
| Self-Reflection Ledger (20 字段) | append-only 事件流 | LLM 自己会反思 |
| Policy Engine (200 行 YAML) | sandbox 边界 + 5 行白名单 | 危险 = 出 sandbox |
| Tool Gateway + Registry | 5 个工具函数 | 不需要 registry 抽象 |
| Verification Engine | `done_when` 命令 | 一个 shell command |
| Auto-Repair Loop | 同一个 loop | repair 不是独立阶段 |
| Stability Monitor / Lyapunov | 3 个计数器 | 不需要控制论隐喻 |
| Observer / State Estimator | git diff + 事件流 | LLM context 就是 state |
| Repo / Risk / Human Model | AGENTS.md | 一个 markdown 文件 |
| Specialist sub-agents | reset_and_retry | 多 agent 是病 |
| Review Cockpit / Evidence Pack | GitHub PR | 已经存在 |
| Learning Loop / Eval | 先手工 | 自动化放最后 |
| Trajectory Store / OpenTelemetry | 事件流写文件 | 等有规模再说 |
| Risk-Adaptive Autonomy (v2) | 删 | 过早抽象 |

**模块数：13 → 6。代码量大概砍掉 80%。功能损失：0。**

---

## 5. 加回来的部分（≤10%）

砍完之后跑一阵，**真的不够用的时候**，按这个顺序加：

1. **第一个加回来的，几乎一定是：事件流的查询 UI**。因为你会需要 debug 失败 case。但是是 `grep + jq`，不是 dashboard。
2. **第二个可能加回来的：cost dashboard**。因为账单会让你心疼。
3. **第三个可能加回来的：protected path 列表**。但只有在你**真的被烫到一次**之后才加，而不是预防性地加 200 行 YAML。
4. **Eval set**：当你改 prompt 不知道有没有 regression 的时候。

**注意：Specialist agents、Risk Scorer、Stability Monitor、Contract Builder 这些，大概率永远不会加回来。** 这就是它们该被删的证据。

---

## 6. 第一性原理的几条硬规则

砍完之后，留下这几条作为防止反弹的纪律：

1. **任何模块，先证明没有它系统会坏，再加。** 不是“有了会更好”就加。
2. **任何抽象层，先有 3 个具体用例，再抽。** 不是预想中可能有用就抽。
3. **任何 schema，字段先少后多。** 加字段容易，删字段难。
4. **任何 policy，default deny。** 白名单永远比黑名单短。
5. **任何 dashboard，先用 grep。** grep 不够用了再做 UI。
6. **任何 sub-agent，先用 reset。** reset 不够用了再做 sub-agent。
7. **任何自动化，先手工跑 100 次。** 手工烦死了再自动化。

---

## 7. 留给你的挑战

去看你上一版那 13 个模块。对每一个，回答三个问题：

1. **删掉它，第一个会坏掉的具体场景是什么？** 写不出来 → 删。
2. **这个场景一年发生几次？** < 10 次 → 删，发生时手工处理。
3. **LLM 自己能不能在 prompt 里做这件事？** 能 → 删，让 LLM 做。

我赌你能再砍掉 30%。

然后：**先写 500 行让它跑起来，跑 50 个真实任务，再来谈架构。**

> Talk is cheap. Show me the harness running on real PRs.