Michael Johnson你可以把任务交给代理，等待它修改代码仓库，然后拿到一份拉取请求草稿进行审查。但代码之外，还会出现一个问题：结果是否符合任务要求，测试是否漏掉了重要问题？
2026年2月4日，GitHub宣布 Claude 和 Codex 编码代理开放公开预览。公司表示，可以将 issue 和拉取请求中的任务分配给代理，随后检查代理准备的 PR 草稿。这证实了这种工作流程已进入开发界面，但并不能证明它节省了时间或提高了代码质量。
因此，问题不只是代理能否编写代码。重要的是，人们还需要围绕委派出去的任务做哪些工作：设定限制、关注进展并评估结果。
监督不只是最后的审查
在2026年9月21日发布于 arXiv 的一篇预印本中，研究人员提出，应将对编码代理的监督视为一个连续过程。论文委派背后的工作依据对19名资深开发者的观察及其工作流程图，描述了监督的七个阶段，并将这一框架用于分析 Reddit 上开发者的公开讨论。
作者描述的做法包括：更加重视规划、把部分监督任务交给其他代理，以及将重复性指示转化为可重复使用的材料。这是一个分析框架，而非时间成本测量：该研究没有确定开发者花多少时间监督，也没有说明这种流程是否比手动工作更快。arXiv 页面将这篇预印本标注为正在同行评审，因此其结论应视为初步结果。
在实践中，可以区分三项工作。任务设定明确目标与限制。过程监督有助于发现代理是否偏离预期。结果检查则用于根据需求、代码和测试评估是否可以接受结果。某一阶段做得成功，并不保证下一阶段也成功：补丁看起来可能合情合理，却可能没有解决正确的问题，或需要大幅返工。
社区经验不等于统计数据
在r/LocalLLaMA 上的一场讨论中，一名参与者表示，自己使用本地模型和代理的体验令人失望：据其所说，他不得不修正结果，并反复提醒代理遵守指示。同一讨论串中的其他参与者则描述了对自己更有帮助的流程：限制任务范围、分阶段推进，并仔细检查代码。这些只是个别用户的观察，并非对模型进行的可比测试，也不是对团队生产力的测量。
这些不同的反馈表明，体验可能取决于任务、模型、运行环境和工作方式。但仅凭一场讨论，无法判断哪些做法平均而言更有效，也无法得知问题出现的频率。该讨论针对的是本地模型，因此不应将其中的观察自动推广到所有代理工具。
有人参与并不意味着委派毫无用处。开发者可以拆分任务、检查变更并 уточ清需求，同时仍对最终结果负责。但如果不计算任务设定、修正和代码审查所花的时间，就无法判断总工作量是否减少。
PR 草稿尚不等于已接受的 PR
在 GitHub 描述的工作流程中，可以给代理分配 issue，并获得一份拉取请求草稿。从草稿创建到最终接受之间，还有几个问题需要回答：变更是否符合要求，是否考虑了边界情况，测试是否充分，以及解决方案是否适合项目架构。
这些标准无法归结为单一指标。创建的变更数量不等于可用变更的数量，而测试通过也未必能证明补丁具备所有重要属性。即使结果看起来质量很高，也不能仅凭这一点看出准备和检查它花了多少工作。
要评估整体效果，就需要考虑完整周期：任务设定、等待结果、审查、修正以及后续代码维护。本文所涉及的资料没有提供这样的整体比较。
可以得出什么结论
这篇预印本提供了讨论监督工作的框架；GitHub 则介绍了一种给代理分配任务并检查其准备的 PR 的工作流程。Reddit 上的讨论显示，个别用户既谈到了使用本地模型时遇到的困难，也分享了有用的做法。综合来看，这些材料有助于提出如何组织委派代码审查的问题，但并不能回答净生产力是否提升。
这些资料无法证明开发者整体上已经从编写代码转向监督，也无法证明代理总是会增加工作量，或提升整个行业的生产力。要得出这类结论，需要在不同任务和团队中，对时间与质量进行可比测量。
对团队而言，实际问题更具体：哪些变更可以由代理自行准备，合并之前需要检查什么，以及由谁负责确保结果解决了最初的问题？委派不会取消这项工程工作——它改变的是工作的起点和关注重点。