我受够了 Claude Code 的黑箱，所以自己造了一个

Harness系列： AI早知道 · 第四篇

Mario Zechner 在 DOS 时代长大。

那时候的程序，你能看到所有东西。Doom 的安装程序，Borland 的开发工具，每一行输出都暴露在你眼前，没有黑箱，没有后台进程，没有"正在处理，请稍候"。

三十年后，他在用 Claude Code。

他开始注意到一件事：Claude Code 的后台进程没有任何可见性。子 agent 在做什么，你看不到。系统提示在每个版本之间悄悄改变，没有 changelog，没有说明。工具在你背后往上下文里注入东西，你不知道注入了什么，也不知道有多少。

对很多用户来说，这也许不是问题。对 Mario 来说，这是不可接受的。

于是他花了几个月，自己造了一个。

先算一笔账

在解释 Mario 的解法之前，先来算一笔他觉得大多数人没有认真算过的账。

你在用 Playwright MCP 吗？它是现成的 MCP 工具，让 agent 能控制浏览器、做自动化测试、截图验证 UI。非常方便。

但它有 21 个工具，工具描述加起来占用 13,700 个 token。

这意味着：在你和 agent 说第一句话之前，你的 context 窗口已经消耗了 9%。

不只是 Playwright。Chrome DevTools MCP 有 26 个工具，18,000 token。很多人会同时装五六个 MCP 服务。算下来，agent 还没开始工作，一大块上下文就已经不见了。

"你以为你在做 context engineering，但你连 context 里有什么都不知道。"

这是 Mario 决定不支持 MCP 的原因。他的替代方案是：用 CLI 工具 + README 文件。需要浏览器自动化？写一个 CLI 脚本，附上一份 README 说明怎么用。agent 在需要的时候读 README，按需加载，只有真正用到的工具才消耗 context。这叫渐进式披露，而不是一次性倾倒。

4 个工具，900 token

Mario 的 agent 叫 pi。它的核心工具集是：

read   — 读文件
write  — 写文件
edit   — 精准修改文件的某段文字
bash   — 执行命令

就这四个。

系统提示加上工具描述，加起来不到 1000 token。

对比 Claude Code 的系统提示（几万 token）、opencode（清晰地复制了 Claude Code 的 prompt 结构）——差了几十倍。

你可能会想：工具这么少，系统提示这么短，能用吗？

Mario 把 pi 拿去跑了 Terminal-Bench 2.0，这是一个评测 coding agent 能力的公开 benchmark。结果：pi 和 Claude Code、Codex、Cursor、Windsurf 几乎不相上下，甚至在某些任务上更好。

他的解释很直接：2026 年的前沿模型，已经被 RL 训练到"天生懂 coding agent"了。 你不需要用 10,000 token 的操作手册来告诉它怎么用 bash、怎么读文件、写代码的时候应该注意什么。模型已经知道了。你喂它的那些额外的 prompt，在大多数情况下，只是在浪费 context。

这个结论很刺耳，但 benchmark 数据放在那里。

文件是唯一诚实的状态

Mario 砍掉的不只是工具。他还砍掉了两个几乎所有 coding agent 都有的内置功能：Plan Mode 和内置 Todo 列表。

砍掉 Plan Mode 的理由：

Claude Code 的 Plan Mode，本质上是一个只读分析模式——agent 在规划阶段不修改文件，只是"想"。问题是，你对 agent 在想什么完全没有可见性。它看了哪些文件、漏掉了哪些、做出了什么假设——你不知道。等它说"好了，我规划完了"，你拿到的是一个结论，不是一个过程。

Mario 的替代方案：让 agent 把规划写进 PLAN.md。你能实时看到它在写什么，能随时介入修改，规划文件可以在不同 session 之间传递，可以用 git 追踪变更。

砍掉内置 Todo 的理由更简单：内置 Todo 是 agent 需要额外维护的状态。状态越多，出错的地方越多。

替代方案：写一个 TODO.md 文件。

# TODO.md
 
- [x] 实现用户认证
- [x] 添加数据库迁移
- [ ] 编写 API 文档
- [ ] 添加限流

agent 直接读这个文件，改完一条就更新 [x]，所有人——包括你——都能看到最新状态。

这不是偷懒，是一个更深的判断：文件是唯一同时满足"agent 可读"、"人类可读"、"跨 session 持久"、"可版本控制"这四个条件的状态载体。 任何把状态放在内存里、放在 UI 组件里、放在 agent 内部表示里的做法，都在为自己创造隐患。

后台进程的解法叫 tmux

Claude Code 有一个内置的后台 bash 功能，可以启动开发服务器、在后台跑测试。

Mario 不支持这个。他的理由是：后台进程管理是可见性的天敌。

早期版本的 Claude Code 里，agent 会把它启动的后台进程忘掉——context compaction 之后，它不记得自己开了哪些进程，也没有工具去查询。你必须手动 kill。

Mario 的解法是：用 tmux。

tmux 是一个终端复用工具，不是 AI 产品，它 1987 年就存在了。但它天然解决了所有可见性问题：你能看到 agent 在另一个窗格里运行的命令，能看到输出，能介入，甚至能和 agent 在同一个 LLDB 调试会话里协作。

"Claude Code 也可以用 tmux，你懂吧。bash 就够了。"

子 agent 是被误用最多的功能

Mario 最强烈的反对意见，来自对子 agent 的使用方式。

Claude Code 的子 agent 功能，让主 agent 可以在处理复杂任务时派生一个新 agent 来处理其中一部分。很多用户觉得这很方便：并行开多个子 agent 同时实现不同功能，速度快，看起来很强大。

Mario 的判断：这是一个反模式。

原因有两个。

第一是可见性。子 agent 在做什么，主 agent 不清楚，你更不清楚。主 agent 决定给子 agent 什么初始上下文，你没有控制权。子 agent 出了问题，调试起来非常痛苦——你看不到完整的对话过程。

第二是更根本的问题：多数人在 session 中途开子 agent，是因为没有提前规划好上下文。

他的建议是：如果你需要收集上下文，先单独跑一个 session 专门做这件事，产出一个结构化的 artifact。然后在一个新的 fresh session 里，把这个 artifact 作为输入，开始真正的实现工作。

这比 mid-session 开子 agent 更干净：上下文更完整、可见性更好、artifact 下次还能复用、整个过程你都能看到。

他说得很直白："人们以为子 agent 省了 context，其实是你没有把工作规划好的信号。"

对安全机制诚实

最后一个 Mario 的设计决定，也是最有争议的：pi 默认运行在完全 YOLO 模式下。

没有文件操作的权限确认，没有命令执行的安全检查，没有 Haiku 预审 bash 命令是否恶意，完整的文件系统访问权，可以以你的用户权限运行任何命令。

他给出的理由不是"这很方便"，而是一个更直接的工程判断：

coding agent 的安全护栏，本质上是安全剧场。

一旦你给了 agent 写代码和运行代码的能力，游戏就结束了。如果 agent 能读取数据、运行代码、还有网络访问——你在打地鼠。Claude Code 检查每一个命令，询问你是否确认，然后照样能访问你的文件系统，照样能 curl 外部地址。这些确认弹窗的存在，更多是让用户感到"系统在保护我"，不是真的在保护。

"大家都在跑 YOLO 模式来做任何有效率的工作，那为什么不干脆把它设为默认，而且是唯一选项？"

这句话很刺，但逻辑是清晰的。比起假装有护栏，他选择告诉你：这个工具有完整权限，请在你了解风险的前提下使用。

Mario 真正在说什么

表面上，这篇文章是一个工程师嫌弃现有工具太复杂、自己重造了一遍的故事。

但 Mario 真正在说的东西，值得认真对待：

可见性不是锦上添花，而是 harness 的基本条件。

你看不见的，对你来说就不存在——这不只是 Mario 的个人偏好，而是一个关于工程实践的根本判断。如果 agent 在后台注入了你不知道的 context，你的 context engineering 就是在盲人摸象。如果子 agent 的行为对你是黑箱，你对整个系统行为的理解就是有缺陷的。如果安全机制是表演，你对风险的认知就是扭曲的。

前几篇讲的是 Anthropic 和 OpenAI 如何用复杂的多 agent 结构突破能力天花板。Mario 讲的是另一面：在你真正需要那些复杂度之前，你首先需要对 agent 的行为有清晰的掌控感。 没有掌控感的复杂系统，不是 harness，是噩梦。

他的工具只有 4 个，系统提示不到 1000 token，benchmark 跑分和顶级工具不相上下。这不是因为他偷了懒，而是因为他一直在做减法——减掉每一个不能给他提供真实价值、或者损害可见性的组件。

剩下的，才是他真正信任的东西。

下一篇：OpenClaw 怎么做 Harness？本土独立开发者的实践方案