从写代码到查问题：agentic engineering 四个环节的职责边界

把 agentic engineering 理解成“更强的代码生成”，边界一定会失守。GitHub 博客那篇开发者指南的标题与摘要给出的划分更实用：写代码变快了，但围绕写代码的工作没有同步变快；文章按规划、写代码、审查变更、排查生产问题四个环节展开（来源，据其摘要转述）。据此，职责边界不该按“agent 能不能做”来划，而该按“这一步做错了，能否在本环节内被发现”来划。

说明：本次材料只包含该文标题与摘要，未包含原文对各环节工具能力的具体描述，因此下文不引用其产品细节；涉及具体能力处标注待核实。

三个判断维度#

• 可逆性：改错了能否低成本撤回。可逆的操作适合下放，不可逆的（改配置、动数据、对外发布）保留人工确认。
• 验证成本：有没有便宜的检查手段。有测试、有类型、有 lint 的改动，错误在环节内就会暴露；只能靠“看起来对”判断的改动不行。
• 上下文位置：判断所需信息是否都在可读材料里。仓库内的依赖关系可读，组织里的优先级和取舍不可读。

四个环节各自交付什么#

规划：交付假设，不交付决心

agent 适合把模糊需求拆成可验证假设、列出受影响的模块、给出验收条件与风险点。人保留的是：这件事要不要做、先做哪个、接受哪个取舍。越界信号是把 agent 写出的方案直接当成已决定的架构。

写代码：边界在“一步能回滚”

在明确契约下改小范围、补测试、做机械重构，属于可下放区间。接口形态、数据模型、跨模块约定这类改动，一旦合入就要别人跟着改，应保留人工决策。越界信号是一次提交横跨多个不相关模块——出了问题无法二分定位。

审查变更：agent 查一致性，人查意图

一致性是机械问题：命名与约定是否统一、调用点是否漏改、测试是否覆盖新增分支、边界条件是否处理。意图是另一回事：这个改动是否符合本意、是否该现在合、是否引入产品层面风险。agent 给出的审查意见应视为待复核线索，而不是结论。

排查生产问题：agent 收敛证据，人定因果与止损

从日志、指标、最近变更里收敛候选原因，列出待验证假设，是 agent 的强项，因为它是收敛型工作。人保留两件：先止损还是先定位，以及因果是否成立。把相关性当因果、直接回滚或改配置，是这一环节最常见的越界。

边界要落在交接物上#

只写在文档里的边界会退化成口头约定。每个环节应留下一个下游能直接用的物件：

最小交接模板（示例）#

以下为演示用文本模板，未执行，也不对应任何真实系统；方括号内为占位内容。

环节: [规划 / 写代码 / 审查 / 排查]
假设: [一句话，可被证伪]
证据: [日志行、指标名、文件路径]
验证方式: [命令或检查项]
可逆性: [可回滚 / 不可逆，需人工确认]
未决问题: [需要人判断的取舍]

三条常见越界#

1. 把“能生成”当成“已验证”。生成只是产出了候选，验证仍是独立步骤。
2. 只声明边界，不产出交接物。下游拿不到可复核的东西，边界等于没有。
3. 在不可逆操作上让 agent 自主执行。改配置、动数据、对外发布应先停在人工确认。

至于各环节里具体工具能覆盖到哪一步，取决于所用产品与版本，本次材料未提供可核验细节，相关能力待核实。可操作的判断顺序仍是：先看这一步错了能否被发现，再看能否低成本撤回，最后才看 agent 做得多快。