读 Anthropic 的 Harness 文章有感:AI 工程像极了培训一个新员工

最近细读了 Anthropic 工程博客上的一篇文章:《Effective harnesses for long-running agents》。读完在椅子上坐了很久——它讲的是 agent,我想到的却是人。

这篇文章讲了什么(说人话版)

长时间干活的 agent 有个天生的毛病:它是分场次工作的,而每场开始时,它对上一场发生了什么一无所知。 文章里的比喻很传神:像一个靠轮班工程师维护的软件项目,每个新来接班的人,对前一班的事毫不知情。

Anthropic 的解法,不是把模型变聪明,而是把环境搭好。这套环境,他们叫 harness(我姑且译作「驾驭工程」):

• 先派一个「开荒 agent」:第一班不写业务代码,专门搭基础设施——把需求展开成一份两百多项的功能清单(JSON 格式,因为模型不容易乱改 JSON),每项先标成「未完成」;
• 留一份交班日志:claude-progress.txt,让下一班一进门就知道干到哪了;
• 用 git 交接:每班结束都提交一次,写清楚做了什么,出问题能回滚;
• 一班只干一件事:每个会话只完成一个功能,绝不贪多,避免上下文撑爆;
• 验收要动真格:用浏览器自动化真点真测,不能只跑单元测试就算过。

新一班 agent 上工的标准动作是:看目录、读交班日志、查功能清单、翻 git 记录、把服务跑起来确认没坏——然后才开始干活。这不就是工厂里的交接班清单吗?

我真正被击中的地方

合上文章,我把这几年的「XX 工程」排了个队,忽然看清了一条线:

• Prompt Engineering,教的是「如何沟通」;
• Context Engineering,教的是「给什么资料」;
• Harness Engineering,教的是「怎么搭环境」。

但真正决定产出质量的,从来不是这三样本身,而是使用这些工具的那个人——他对任务的理解深度、对标准的把控能力、对边界的判断直觉。环境搭得再好,清单列什么、验收卡多严、哪里绝不能越线,还是人来定的。

像极了一个新员工的生命周期

所以整个 AI 工程范式的演进,在我眼里像极了培训一个新员工的完整过程:

1. 提示词工程 = 学会沟通、互相了解。 刚入职,先把话说明白:你是谁,我要什么,按什么格式交。
2. 上下文工程 = 给资料、带上手。 熟了以后,把行业背景、历史文档、过往案例整理好递过去,让他懂业务再干活。
3. 驾驭工程 = 搭工位、配工具、定流程。 到这一步,重点已经不是「教他」了,而是给他一个好环境:工位(工作目录和代码库)、工具(测试、浏览器、git)、流程(功能清单、交班日志、验收标准)——然后放手让他独立当班。

带过团队的人都知道,新人能不能出活,一半看他自己,一半看你给他搭的环境。现在轮到我们给 AI 当这个「带教师傅」了。

那我的下一步也清楚了

读懂这条线,我就知道自己该干什么:别再停留在「聊得好」,要开始「搭得好」。

把我最熟的领域——法律 AI 的活儿——按这套思路重新架一遍:任务怎么拆成清单,标准怎么写成验收,边界怎么变成规则,进度怎么留成日志。把二十多年攒下的行业判断,从我的脑子里,搬进 agent 的工位里。

搭出什么来,照例记在手记里。

想看珂的下一个作品?