核心摘要

“Agent 牧羊人”可以形容软件工作的一种变化，但它不是每个开发者的必然终点，也不代表工程能力被替代。更准确的表达是 Agent 编排者：开发者继续掌握目标、约束、架构、证据和后果，只把边界明确的执行交给 Agent。

理解当前变化，需要守住三条证据边界：

  • Anthropic 在 2026 年分析了约 40 万次 Claude Code 会话，发现典型会话中用户作出约 70% 的规划决策，而 Claude 作出约 80% 的执行决策。这描述的是一个产品中的实际使用样本，不代表所有团队或未来岗位。
  • METR 2026 年 2 月更新指出，新一轮生产力实验受到参与者选择、任务选择和并行 Agent 时间测量问题影响，无法给出可靠的当前加速幅度。2025 年的减速结果不能直接外推到 2026 年，新数据也不能证明“普遍加速”。
  • DORA 2025 报告把 AI 定义为组织现有优势与弱点的放大器。工具无法替代清晰所有权、快速反馈和可靠交付系统。

因此，严谨结论不是“开发者不再写代码”，而是工作分配可能变化：人更多保留规划与判断，Agent 可以承担更多实现与工具执行。实际分工必须由风险和证据决定。

研究能证明什么，不能证明什么

交互式 Agent 会话中的分工

Anthropic 使用隐私保护的分类器和遥测，分析了 2025 年 10 月到 2026 年 4 月的会话。它区分了 做什么 的规划决策和 怎样做 的执行决策，因此比“生成了多少代码”更接近真实协作。

研究还发现，任务领域经验越强，Agent 每次指令后的动作链通常越长，成功率也略高。这里的经验是任务特定的：资深工程师面对陌生领域仍可能是新手，没有编程职业背景的人也可能非常熟悉财务或法律流程。

这支持一个务实判断：高质量委托依赖对问题的理解，以及识别错误输出的能力。它不能证明软件工程训练不再重要，也不能证明每次会话都达到生产质量，更不能直接推广到其他工具。

生产力仍然难以用一个数字表示

任务完成更快，不代表系统交付一定更好；它可能同时增加审阅时间、缺陷、运维负担或未来维护成本。并行 Agent 也会让“花了多少小时”变得难以归因。

METR 2026 更新的价值，正在于它公开了为什么当前估计不可靠：

  • 预期 AI 价值较高的开发者更不愿接受禁用 AI 的任务；
  • 参与者会跳过自己非常希望用 AI 完成的任务；
  • 并行使用多个 Agent 时，时间记录不准确；
  • AI 允许与否可能改变任务类型和最终质量。

正确做法不是挑选最符合立场的标题，而是对自己的任务组合进行测量，并把质量、审阅、恢复和交付结果一起纳入。

组织系统仍然决定结果

DORA 的“放大器”框架解释了为什么同一工具会带来相反结果。测试快速、接口清晰、变更较小、部署可靠的团队，能让 Agent 快速获得反馈；所有权模糊、CI 缓慢的团队，只会把等待与歧义放大。

所以，引入 Agent 同时是软件交付和知识管理问题，而不只是选择哪款 IDE。

责任边界：可以委托执行，不能委托问责

不要默认把整个 Ticket 交给 Agent，应按责任拆分：

责任 人或组织负责 Agent 可以协助
问题选择 用户价值、优先级、非目标 收集证据、总结选项
架构 边界、取舍、长期适配 探索代码、草拟方案
安全与隐私 风险接受、策略、授权 识别模式、运行已批准检查
实现 接受最终变更 草拟代码、测试、迁移、文档
验证 决定何种证据足够 运行工具、生成产物、提出质疑
发布 审批、影响面、回滚 准备变更、监控获准信号
事故响应 指挥、沟通、责任 关联证据、提出假设

模型可以推荐决策，但不能因为生成了看似合理的答案，就自动承担法律、运维或产品责任。

面向生产环境的协作工作流

1. 定义任务契约

说明用户结果、当前行为、允许修改的文件或服务、非目标、约束、验收测试和回滚边界。把事实和假设分开。

2. 建立基线

修改前先复现问题或记录当前行为，运行最小相关测试并保存目标版本。没有基线，人和 Agent 都无法证明结果变好。

3. 选择委托等级

等级 Agent 权限 适合起步的工作
辅助 只解释或起草 探索、测试矩阵、文档
编辑 修改有界工作区 局部重构、测试、低风险修复
执行 运行获准工具 构建、Lint、Fixture 校验
提议副作用 准备 PR 或部署计划 可审阅的集成工作
执行副作用 执行已批准动作 必须有身份、确认、幂等与恢复

授予完成任务所需的最低等级，而不是工具支持的最高权限。

4. 审查证据，而不是语言流畅度

检查 diff、测试相关性、失败路径、授权、数据迁移、可观测性、无障碍、本地化和依赖变化，并主动问“什么证据能推翻这个实现”。

同一个 Agent 生成的测试，可能复制实现中的错误假设。风险较高时，至少加入一个独立 Fixture、确定性门禁或独立审阅者。

5. 只合并团队能够运维的变更

团队必须在不重放原始对话的情况下，理解、调试、回滚和继续修改这项变更。变更影响契约时，还要更新持久化的架构与运维记录。

真正重要的能力组合

任务特定的领域知识

领域规则决定软件是否正确。理解清结算、身份、医疗流程或搜索排序的开发者，能给出精确约束并识别细微错误。熟练操作 Agent 不能替代这种知识。

规范与上下文工程

好规范应当精确到可以验收，又不会无谓限定实现。上下文工程负责选择当前、权威的信息，并区分指令、知识、记忆和任务证据。

系统设计

Agent 可以提出架构，但所有权、兼容性、故障隔离、数据生命周期、成本和组织约束仍需要开发者判断。这些信息通常不会同时出现在一次仓库快照中。

验证与评测

审查不等于快速读代码，而是设计证据：复现步骤、不变量、负向测试、属性测试、安全检查、Canary、回滚和用户结果指标。必须区分“命令通过”和“结论已经被证明”。

调试与运维

生成代码仍会在并发、部分故障、陈旧数据和真实流量下失败。开发者需要能追踪请求、检查状态、提出竞争性假设并验证，而不是只能求助于生成缺陷的同一个 Agent。

安全与治理

理解身份、授权、密钥、供应链、租户隔离、日志、留存和审批。工具访问遵循最小权限，检索到的指令不能改变执行权限。

测量完整交付系统

按任务类别看结果，不要发布一个覆盖全公司的“AI 生产力数字”：

维度 示例指标
流动效率 Lead Time、等待审阅时间、返工轮次
质量 线上缺陷、回滚、测试不稳定
审阅 人工时间、变更规模、未解决发现
运维 变更失败率、恢复时间、告警
安全 漏洞发现、策略拒绝、密钥泄露
经济性 每个有效变更的工具、审阅与恢复成本
学习 解释、修改和调试结果所需时间

比较相似任务随时间的变化，并记录模型、工具、仓库与工作流版本。代码行数、Prompt 数、Agent 动作或 PR 数都只是活动指标，不能证明用户价值。

按能力门槛推进，而不是承诺固定月份

不要声称每个开发者都能在固定六个月内“完成转型”。应按可证明能力推进：

门槛 1：辅助工作

  • 对比有无工具时的任务基线；
  • 识别 Agent 带来的收益或额外审阅成本；
  • 保护密钥并限制工具权限；
  • 拒绝自己无法解释的输出。

门槛 2：有界编辑

  • 编写带验收标准的任务契约；
  • 委托小而可逆的变更；
  • 用独立测试和 diff 审阅验证；
  • 从一个刻意引入的失败中恢复。

门槛 3：端到端提案

  • 让 Agent 在隔离环境中探索、编辑并运行检查；
  • 要求返回证据与不确定性；
  • 审查架构、安全和运维影响；
  • 合并与发布审批继续由人负责。

门槛 4：并行或后台执行

  • 拆分任务，避免共享状态冲突；
  • 把进度持久化到对话之外；
  • 强制预算、租约与停止条件；
  • 测量集成和审阅负担，而不只看 Agent 吞吐。

门槛 5：受控副作用

  • 把审批绑定到精确参数与版本；
  • 使用幂等与权威回读；
  • 测试取消、写入后超时和回滚；
  • 代表性评测通过后才扩大权限。

日历只是次要因素。同一个开发者在不同仓库和风险等级上，完全可以停留在不同门槛。

常见失败模式

“岗位必然消失”的叙事

这类结论忽略任务差异、组织约束和测量缺陷。应使用场景和证据，不使用必然性语言。

审阅成为瓶颈

生成超过团队理解和验证能力的变更，会增加队列与风险。并行 Agent 数量应受审阅能力限制。

理解债

团队无法解释的软件，会在事故和迁移时付出代价。应保留持久设计上下文，并对样本变更做深度审阅。

自动化偏见

流畅解释与生成测试通过，容易让弱证据显得可信。需要负向用例和独立检查。

能力退化

不必规定统一的“手写代码比例”。在调试、陌生系统、性能、安全关键变更和基础学习中，保留对岗位有价值的动手实践。

常见问题

“Agent 牧羊人”是正式职业吗？

不是，它是描述工作模式的非正式标签。现有开发者岗位可以增加 Agent 委托，而不必改成一个新头衔。

写代码会变得不重要吗？

某些工作流中，人工实现时间可能下降；但代码理解仍是评估、调试、保护和演进 Agent 产物的基础。

每项任务都应该交给 Agent 吗？

不应该。简单且确定的工作继续使用确定性工具，高影响判断由人负责，只在灵活执行有实测价值时使用 Agent。

最持久的职业优势是什么？

深入理解有价值的问题，并把理解转化成约束与证据。熟练使用工具有帮助，但工具变化远快于领域知识和工程判断。

参考资料

延伸阅读

总结

Agentic Coding 可以把大量执行工作交给软件，但不会消除选择正确问题、设置约束、验证现实和承担后果的需要。开发者持久的竞争力，不在于同时启动多少 Agent，而在于围绕它们建立了怎样的决策、证据与交付系统。