agentic engineering 的分工：规划、编码、评审与问题定位各留多少给人

先把结论说清楚：agentic engineering 的分工不是“把写代码交给 agent、人退到旁边看”，而是把规划、编码、评审、问题定位四个环节分开，逐个判断可委托程度。判断依据可以落在两个轴上——这一步的产出能不能被快速验证，以及这一步做错了是否容易回退。可验证、可回退的环节适合多交给 agent；不可验证或不可逆的环节，人必须保留决定权。

先交代材料范围。GitHub Blog 于 2026 年 11 月 6 日发布 Beyond code generation: A developer’s guide to agentic engineering。据其摘要，文章讨论借助 GitHub Copilot 做规划、写代码、评审变更和调查生产问题，并指出仍有一部分工作依赖人的判断。本次材料只有标题与摘要，抓取到的正文片段并未覆盖该文内容，因此下文不引述其具体方法、功能名称或效果数据；涉及该文主张的部分以摘要为限，其余是标注为推断与建议的内容。

一个判断轴：可验证性与可逆性#

把“agent 能不能做”换成“这一步错了会怎样”，分工就变得可操作。

• 可验证性：产出有没有机器可判定的对错信号。编译、类型检查、单元测试、lint 属于这一类，反馈周期通常在秒到分钟级。
• 可逆性：错误发生后能否低成本撤回。改一个分支、加一个开关、revert 一次提交，可逆性高；改线上数据、变更权限、动共享基础设施，可逆性低。

两轴都高的环节，委托成本最低；任一轴低的环节，人的介入点就应该前移，而不是等 agent 交付后再补审。

四个环节怎么分#

规划：agent 出草案，人定验收

规划阶段的特殊之处在于没有自动反馈信号：任务拆得对不对，要到编码和评审阶段才会暴露。更麻烦的是，如果验收标准本身写错了，后面所有验证都在验证一个错误的前提。

建议的分工是：让 agent 生成任务拆解、备选方案和风险点，人只审两样东西——目标是否可判定完成，以及明确不做什么。前者决定后续能否自动验证，后者决定范围会不会在编码阶段膨胀。这一步属于建议，不是材料中的结论。

编码：可委托度最高，但要带验收命令

编码环节反馈最快，回退也最容易，是四步中最适合交给 agent 的。但“可委托”不等于“不用交代上下文”：委托前最好给出一条可执行的验收命令，让 agent 自己能判断是否做完。没有验收命令的委托，实际是把判断推回给人，节省的时间会以评审成本的形式还回来。

评审：拆成一致性与必要性两类问题

评审常被当成一件整体的事，其实至少包含两类问题：

• 一致性：命名是否统一、错误处理是否遵循现有约定、是否复用了已有的工具函数。这类检查靠模式匹配，适合 agent 先过一遍。
• 必要性：这个改动是否应该存在、是否应该现在做、是否引入了不必要的抽象。这类判断依赖对业务和历史的了解，测试通过并不能证明它对。

评审的反馈信号弱，是它不适合整体委托的原因：测试全绿只说明已覆盖的路径没坏，不说明改动方向正确。

问题定位：agent 收集证据，人裁决假设

定位生产问题通常要在日志、堆栈、近期变更和代码路径之间来回关联，这正是 agent 擅长的检索与串联工作。但有两件事建议留给人：一是提出假设并决定验证顺序，因为验证顺序决定了排查成本和影响范围；二是执行任何触及线上环境的操作，因为这一步可逆性最低。

分工要落在交接物上#

只口头说“这一步人来把关”往往落不了地。更实际的做法是给每个环节定义一份交接物，下面是一个演示模板，内容是占位示例，未在任何工具中执行：

# 任务卡（示例，占位内容）
目标：<一句话，可判定完成与否>
约束：<不能改动的模块 / 兼容性要求>
验收：
  - 命令：<可执行命令>
  - 期望：<通过或失败的具体判据>
不做什么：<明确排除的范围>
回退方式：<revert / 开关 / 数据回滚>
待确认假设：
  - <假设一>
  - <假设二>

这张卡的作用不是流程仪式，而是把“可验证”和“可逆”从抽象判断变成字段：没有验收命令，说明这一步还不适合委托；没有回退方式，说明这一步需要人先介入。

边界与待核实#

• GitHub 那篇文章的具体方法、所涉功能与任何效果数据，本次材料未提供，待核实。
• “四个环节”来自该文摘要的表述，它是文章的组织方式，不等于业界统一分类。
• “用可验证性与可逆性划分委托程度”是本文提出的推断性框架，不是来源结论，也没有配套的对照实验数据。

可以确定的一点是：把“agent 能生成”当成“agent 能负责”，是分工里最容易出错的地方。生成的成本已经降下来了，验证与回退的成本没有同步下降，而后者才是决定哪些环节该交给谁的实际约束。