Humans steer. Agents execute.
本页目录
Humans steer. Agents execute.
这句话让我越来越觉得，它不是一句产品口号，而是在描述程序员职责的真实变化。
过去，软件工程团队的主要工作是直接写代码。现在，至少在一部分前沿场景里，重点已经慢慢转向另一件事：设计一个让 Agent 能持续推进的环境，明确地表达意图，并且搭好足够可靠的反馈回路。代码仍然重要，但程序员真正负责的，已经不只是代码本身，而是那套让 AI 可以稳定工作的运行条件。
如果要问，怎样才能让 AI Agent 编码工具自主、流畅、并且长期地工作下去，我现在更愿意先从几个现实开始说起。
开发形式会不断变化
先认清一个现实：底层模型的发展，一定会持续改变开发的形式。
今天适合当前模型能力的工作流，不一定适合下一代模型；更糟的是，它甚至可能在未来反过来变成一种约束。很多人喜欢在一个阶段里总结“标准方法论”，然后急着把它固化下来。但 Agent 时代的软件工程，很难长期依赖固定套路。你今天为了解决模型上下文短、执行不稳、推理浅的问题设计出来的一整套流程，等模型能力往前再走一截，可能就会显得笨重。
所以真正重要的，不是死守某种流程，而是保持对变化的适应力。你设计的不是一条永恒不变的流水线，而是一套能够随着模型能力变化而继续演化的环境。
少一点方法论崇拜，多一点工具现实主义
第二个现实是，前沿公司往往更接近真实可行的方案。
原因并不神秘。他们有更强的模型、更长的上下文、更密集的真实使用反馈，也更有机会在高成本条件下把产品磨到可用。很多人喜欢沉迷于各种新的“解决方案”“框架”“哲学”，好像只要方法论够新，就能绕开模型本身的能力边界。但在这件事上，我越来越偏向一种更朴素的判断：先把手头真正强的工具用好，比不断追逐二手思路更重要。
像 Codex、Claude Code 这样的产品，本身已经在吸收那些真正有用的经验。很多后来被人反复讨论的东西，比如 skill、agent scaffold、任务拆分、反馈闭环，最终都会被这些工具以产品形式继承下来。与其沉迷于一层又一层的外部包装，不如把注意力放回最基本的问题：你有没有真的理解手里的工具，它在什么条件下工作得最好，它又会在什么情况下失真。
less is more 在这里不是审美口号，而是一种工程判断。
上下文就是一切
如果只让我保留一个判断，我大概会选这个：上下文就是一切。
模型能力的上限，不只取决于模型本身，也取决于你到底给了它什么上下文。正因为模型“好像什么都懂”，所以你的需求才更需要明确。否则它看起来像理解了，其实只是从一团模糊输入里拼出了一个貌似合理的回答。
这也是为什么“研究”和“实现”最好分开。研究阶段要做的是梳理问题空间、收集约束、理解代码结构、形成判断；实现阶段才是基于这些上下文去具体改动代码。如果把两者混在一起，Agent 很容易一边摸索、一边改写，最后把上下文污染得越来越重，任务也越来越失焦。
很多时候，不是模型不会做，而是你让它在错误的上下文里做本来就不该一起做的事。
需求要尽量中立，反馈要可以裁决
还有一个常被忽略的问题：模型有明显的讨好倾向。
如果你对它说“识别数据库中的所有 bug”，它很容易把这个命令理解成一种期待，然后努力给你更多“像 bug 的东西”。这并不意味着它在撒谎，而是它天然会往更像“完成任务”的方向靠拢。于是问题就变成了，你究竟是在设计任务，还是在诱导模型迎合你。
更稳妥的说法通常应该更中立一些。比如不是要求它“找出所有 bug”，而是要求它“梳理当前数据库中每个组件的运行逻辑，并反馈所有发现”。前者在奖励“结论”，后者在奖励“过程”。
我很喜欢一个相关的例子：如果想让 Agent 更充分地帮助我们发现 bug，可以故意把它放进一个带有对抗结构的评估环境里。
一种做法是设计三个不同目标的 Agent：
- 第一个 Agent 专门找 bug。它的奖励机制是，只要识别出 bug 就得分，影响越大的 bug 分数越高。这样一来，它自然会倾向于给出一个“现有 bug 的超集”。
- 第二个 Agent 专门负责反驳。每成功证伪一个 bug，就得到对应分数；如果反驳失败，就要付出更高代价。这样它会逼近“现有 bug 的子集”。
- 第三个 Agent 是裁判。它面对前两个 Agent 的输出，根据一套更明确的基准去判断哪些问题成立、哪些不成立，再对双方结果评分。
这个例子真正有意思的地方，不在于分数设计本身，而在于它说明了一件事：既然模型会被激励牵着走，那就不要假装这种倾向不存在，而是应该主动设计一个更好的评估环境，让它的倾向互相制衡，最后逼近更可靠的结果。
能结束的任务，才可能长时间运行
很多人讨论如何让 Agent 长时间运行，但我越来越觉得，问题的关键根本不在“长时间”这三个字，而在于任务是否知道自己什么时候该结束。
一个真正可持续的 Agent 任务，必须有清晰的终止条件。比如：
- 所有测试用例通过
- 截图验证 UI 改动是否落在正确位置
- 某个文件、某个接口、某个页面的验收标准被满足
说到底，可靠运行依赖两个东西：
- 明确的需求
- 明确的终止
没有这两点，所谓“让 Agent 一直跑下去”，通常只是让它在越来越脏的上下文里继续漂移。
不要迷信长会话，把功夫放在 Harness engineering 上
最后一个判断是：我并不推荐单个智能体长时间持续运行。
原因还是回到前面那句老话，上下文就是一切。会话一长，上下文就会不可避免地腐化。信息堆得越来越多，任务边界变得越来越模糊，早期错误无法及时清算，模型对“自己正在做什么”的理解也会越来越松。与其指望一个 Agent 在漫长上下文里保持清醒，不如主动把工作拆成 issue 式的短周期任务，在隔离的执行空间里完成，再把结果拼回来。
这也是为什么我越来越觉得，真正值得下功夫的，不是把一个 Agent 调教成“永动机”，而是把对应的 harness engineering 做扎实：任务如何定义、上下文如何准备、研究与实现如何切分、验收与退出条件如何写清、不同 Agent 如何被组织和比较、失败后如何快速回到一个干净状态。
程序员的职责，正在从代码的直接生产者，转向这套环境的设计者与维护者。
代码当然还在写，只是越来越多时候，真正决定产出质量的，不再是你亲手敲下了多少行，而是你有没有把环境搭到足够好，好到 Agent 可以在里面持续、清晰、可验证地工作下去。