Agent vs Harnessed Agent

这两天越看越觉得，Agent 一旦开始往生产环境走，迟早会碰到 Harness 这个问题。

先说一下这个词。Harness 原意是马具，也就是用来控制和驾驭马匹的那套装备。放到 Agent 语境里，它更接近“给一个足够强的智能体加上可控的边界、流程和状态机制”。

Harnessed Agent 可以直接理解成一种被工程结构管起来的 Agent。它照样能自主做事，只是不会脱离边界、状态和流程自己乱跑。

我一开始以为这事可以做得很轻

最开始我以为 Harness 这件事可以很轻地实现。

当时我的判断是：有了 Claude Code，再配合文件系统和 CLAUDE.md，理论上已经能做 multi-agent 调度、workflow 协调、状态持久化这些事。

后来实际试了一轮，我的看法变了。

简单、短期的 Harness 当然能靠提示词和文件系统先跑起来，但一旦你要做长期、复杂、可恢复、可审计的工程，核心还是代码逻辑，而不是提示词本身。

现在回头看，我更愿意把它们当成两种不同阶段的工具：

• Claude Code：人工干预很强，适合 PoC、探索、人工 debug
• Agent Harness：人工干预更弱，适合端到端执行明确目标，也更容易接进生产流水线或 CI/CD

真正跑起来以后，差别先出现在这几件事上

运行时长

我跑过最长的一次 Claude Code 任务，大概在 40 分钟左右。

而代码实现的 Harness，我实际跑到过 8 个小时。这个差距本身不代表代码质量高低，但它确实说明：当任务变成长程执行问题时，单会话交互式 Agent 和工程化 Harness 已经不是一类东西了。

断点续做

如果 Claude Code 中途断了，通常需要人重新介入，把任务接回去。

代码实现的 Harness 则可以把异常当作运行时状态的一部分处理。我测试时遇到过 minimax 的 token plan 在 5 小时窗口内触发限额，流程没有直接崩掉，而是停在原地等待额度恢复，然后继续从断点往后跑。

状态管理

Claude Code 当然也能借文件系统做状态管理，但当一个 session 拉得很长，上下文越来越大，compaction 越来越频繁，重要信息丢失的概率也会越来越高，状态就会开始变乱。

而代码实现的 Harness 可以更明确地做 session 切分。每个 session 都分配一个新的 context window，状态靠文件系统快照传递，而不是把所有东西都压在同一段对话历史里。

可审计性

Claude Code 这类交互式 Agent 很容易一路做完整个任务，最后再统一提交 Git。

Harness 的做法则更像工程流水线：先把任务拆开，再让 Agent 一次只做一件事，做完一个 feature 就提交一次。这样 Git 历史天然更细，也更容易回看和审计。

我为什么会去看 autonomous-coding

让我继续往下看的，是 Anthropic 的 demo 项目 autonomous-coding。

我更在意的是，它把约束层放到了代码里，没有继续往提示词上堆。

单靠提示词约束 Agent，就算一时能跑通，后面维护起来也会很贵，因为同样的行为很难稳定复现。代码逻辑的价值就在这里：它能把约束写进执行流程。

autonomous-coding 的做法可以拆成两段：

1. 先用 init agent 把需求整理成 feature list，同时准备测试、初始化项目、写好一键配置脚本，并建立进度文件
2. 初始化结束后进入新的 session，由 coding agent 开始执行 coding -> test -> debug -> update progress 的循环，而且一次只做一个 feature

每完成一个 feature，代码逻辑就继续推进到下一个 session，直到 feature 清空。

我最在意的两个约束

• coding agent 一次只做一个 feature
• 每个 session 都使用全新的 context window

这两件事是绑在一起的。没有后面那条，前面那条很难长期成立。

模型会天然更偏向首尾出现的内容。如果你把一堆历史都拖进同一个 session，随着上下文变长，指令遵从会越来越不稳定。相反，如果每轮都用新的 context window 启动 coding 任务，再把状态快照以文件形式塞进去，当前任务的信号密度就会高很多。

它要处理的，其实就是单轮会话里的上下文爆炸。

假设 Session 1 输出了 50 个 feature，开始 Session 2：

传统方式：
Context = [Session 1 的所有历史] + [Session 2 新内容]
        = 50 个 feature 的实现细节 + 新任务
        = 上下文过长，关键信息被淹没

autonomous-coding 方式：
Context = [当前 Session 的提示词] + [读取 feature_list.json]
        = 精简的当前任务 + 完整的状态快照
        = 上下文更清晰，信息密度更高

跑完这个 demo 之后，我的判断没有变得更乐观，只是更具体了

我平时用 Claude Code 也有类似习惯。两个完全不同的功能，我一般会手动开两个 session，把上下文分开。autonomous-coding 只是把这个动作自动化了。

我用 minimax 跑过一次这个 demo，任务是做一个像素风地牢 rogue-like 游戏。整个 coding 任务前后跑了 8 个小时，最后生成的结果也不算空壳，已经有战斗系统、经济系统，甚至还有拿钥匙开门这样的机制。

但它离生产级产品还有距离，整体复杂度偏低。无论是 UI/UE 还是玩法设计，都还比较简单。当然，这也和前期产品设计本身不够复杂有关。

通过代码工程去约束 Agent，并让它执行超长任务，这件事本身是可行的。

但“能跑 8 小时”不等于“代码质量高”，也不等于“产物复杂度高”。后面真正难的，还是这几个问题：

1. multi-agent 架构本身的代码质量怎么继续提高？
2. 它应该怎么和 Claude Code 这类 Agent 产品协作？
3. 它怎么接进现有的 CI/CD 自动化流水线？

References

1. anthropics/claude-quickstarts: autonomous-coding
2. Anthropic: Effective harnesses for long-running agents