Agent出错时，团队如何划分责任边界?

Agent 把代码改坏、越权访问资源，或者高效地执行了一套已经过时的流程时，团队最容易陷入的问题是：到底该怪谁？如果答案只是“Agent 出错了”，责任就会被技术黑箱吞掉；如果一律追究下发任务的人，又可能把所有问题都归结为操作失误。真正需要划清的，不是“人还是机器”的二选一，而是每个环节分别承担什么责任。

先按控制权划分责任

Agent 不应成为责任主体，它只能按照权限、任务描述和既定流程行动。团队成员负责判断任务是否适合交给 Agent，是否写清了目标、约束和验收标准；流程设计者负责设置审批、审查和回滚边界；权限管理者负责限制 Agent 能接触的仓库、服务和数据；最终的业务或技术负责人，则要对是否允许结果进入下一环节作出判断。

这种划分也意味着，不能把所有问题都归咎于最后点击确认的人。假如一个 Agent 被授予了明显超出任务需要的访问范围，或者高风险操作没有人工确认，那么问题更接近权限和流程设计，而不只是执行者粗心。相反，如果任务边界清楚、权限合理、审查要求明确，却有人跳过检查直接合并结果，责任才更偏向具体操作。

出错后要追“边界在哪里失效”

复盘时可以连续追问几件事：任务是否本来就不适合自动执行？Agent 是否准确理解了约束？它是否改动了预期之外的地方？团队有没有能力及时验证结果？某个技能是否把陈旧做法固化成了标准流程？这些问题比“谁写的代码”更容易找到真正的失效点。

责任边界还应和风险等级匹配。批量重构、测试补齐这类结果较快可验证的任务，可以允许更高程度的自主执行；涉及模糊需求、重要数据或高出错成本的操作，就应保留人工确认。移动端适合查看进度和轻量审批，深度审查仍应回到完整环境中完成。

Agent 时代的问责，不是把机器当成替罪羊，也不是要求每个人为系统的一切行为背锅，而是让任务、权限、审查和决策各有对应的负责人。一个团队若只能在事故发生后寻找“最后碰过代码的人”，说明它设计的不是协作边界，而是一条甩锅路径。