Agent Harness 实践 - Digivolve 你的Agent工程

这段时间AI圈又整了个新词给AI hype续续命,叫Agent Harness,虽然我觉得它和Context Engineering没有什么本质的区别,但Harness的侧重点在于怎么构造一个系统,在跑长文多轮Agent的时候能更有效的约束输出和验收效果。

Andrej Karparthy搞了个 autoresearch,我前几天研究了一下觉得思路蛮好玩的,特别简单粗暴力大砖飞,其实就是在任务开始时给AI一个很明确的目标和评分benchmark方式,然后就可以让Agent 反复修改,失败了就重来,以greedy的方式持续往更高分的方向推。

我觉得这套思路完全可以往日常 Agent 使用里泛化。因为平时很多任务都有或主观或客观的评价方式,但我们在和Agent开始构建时,脑子里通常只有一些模糊的判断。这些判断一开始不是确定的,而是必须和 Agent vibe coding 的过程中逐渐完善。

所以 Digivolve 想解决的,就是这一层。先和用户对齐聊清楚,尽量把这些判断外化出来,变成一个可以反复复用的验收和打分机制。等这层东西相对稳定之后,再让 Agent 自己一直跑,一轮轮去改,一轮轮去评,一轮轮决定保留还是回退。这样整个过程就不会只靠上下文记忆和当下感觉往前冲,边界会更清楚,状态会被保留下来,回溯和比较也都会容易很多。

Anthropic 昨天也刚发布了一篇Agent Harness的文章,其实讲的也是一个很接近的方向。任务一旦变长,Agent 光靠上下文是撑不住的,所以需要额外的Harness去控制它。

目前整个idea还非常早期,先搓了个demo出来,但我已经开始拿来迭代我自己项目做的Agent,效果还不错,可以通过SKILL下到自己的Claude Code或者Codex,欢迎大家一起玩玩,一起学习:

1 个赞

日常项目中这个思路已经用过好几次了,难以解决的问题,人陪着 AI 测试人都麻了。于是就让他对准目标,loop 到绿为止。

对,本质都只是prompt而已,所以如果用户自己有这方面的意识,那根本不需要它了。就和大部分skill一样,主要方便做一个方法论的复用。现在做harness也很多是通过pipeline来控制ai的长输出,不然你可能一开始聊着它还是听话对准目标loop,但聊了两小时后他已经完全忘记最开始的目标是啥了。

对的,尤其是claude自己的 memory.md 还不靠谱😂

嗯,这就是2026年上半年做Agent Harness还蛮有意思的原因,还是因为模型自己能力不够,外力来凑。

感兴趣可以一起玩玩,当前这个项目是通过阶段性披露步骤和git worktree的形式在控制,可以研究研究有没有更好使的方法

我没用过AI,这种完全对准目标的策略会不会导致对测试的故意造假? 因为管理人的时候就会遇到这种情况 :rofl:

会,有几种情况我都做了限制,比如AI会先修 bug 再补测试,测试内容写死使得一直绿,比如过度防御性编程,不让错误冒泡等等,其他的网友可以补充一下。规则如下。

Error Handling and Testing Discipline

  • Errors must surface, not hide: Do not add fallback/default returns that silently swallow failures. Let errors propagate immediately.
  • Catch at the boundary, nowhere else: Only the outermost API layer (process loop, top-level command handler) should catch and convert exceptions to error responses. Business logic must not catch around internal calls.
  • Tests must fail when the code is wrong: If deleting or breaking the function under test does not turn the test red, the test is worthless. Assert specific, distinguishable output values.
  • No hard-coded expectations: Use diverse inputs — multiple data sets, random values, boundary cases — so that a hard-coded return cannot satisfy all assertions.
  • Red before green: When fixing a bug, first write a failing test that reproduces it. Confirm it fails. Then fix the code. A test written after the fix has never been proven to catch the bug.

所以有时候 autoresearch 这类更多的是在通用性上比较占优,如果自己思路清晰,完全可以自己总结适合自己项目的规则。我平时总结更多的在这里,部分规则还是从论坛中看到的。 GitHub - LuciusChen/coding-guidelines · GitHub

嗯,测试造假overfit是个问题,但这个问题现在比以前好了很多,因为大模型厂商主要就是靠Benchmark来自证,有一定优化这方面