开发者使用 Agent 的困境与思维转变如果一名开发者用不好 Agent问题或许不在开发者而在于公司未为 Agent 准备好能工作的系统。很多企业所谓的 AI 转型不过是给开发者买 Cursor、Claude Code 等工具办几场培训再让大家自行摸索。若 Agent 效果不佳责任还会落到使用者头上。但 DevOps 提出者 Patrick Debois 认为开发者要完成重要思维转变当 Agent 未按预期完成任务别修改其生成的代码而要改进整个系统而非只改 Prompt。在他看来这是软件工程从确定性系统转向非确定性、概率性系统和工作流的必经变化不仅涉及技术还会重塑开发者、团队和组织的工作方式。这种变化无法靠单个工程师也不能仅停留在单个团队层面和 DevOps 一样需规模化落地才能实现。核心观点与发展阻力问题核心不只是开发者会不会用 Agent而是公司能否围绕 Agent 重新组织团队、平台和协作方式。核心观点如下1. 别修 Agent 产出的代码去修产出代码的系统。若团队里有人用“YOLO先跑通再说”的野路子搞 vibe coding应立刻制止。工程实践对维护系统和 Agent 持续变好都至关重要。2. 暗工厂可能不是全暗而是保留一点微光dim factory这意味着要决定对什么功能承担多少风险并非所有功能都适合完全自治。3. 能极致用 AI、有扎实工程功底、愿意分享和协作将这三点组合的人才是所需之人。4. 组织的护城河是抓住沉淀下来的知识即注入到 skill、Context 甚至 Harness 约束里的业务上下文。2009 年很多人觉得持续交付的想法疯了。如今暗工厂遇到了同样阻力。人们常说“这东西在我们这儿行不通”实际传达的是“我们还没准备好”是组织设置无法支持这种模式。技术发展与组织协作变化现在大家讨论怎么用循环优化 Agent、搭 Harness这很棒。但最终技术会成为标准商品甚至被前沿实验室打包成服务。那时技术无壁垒真正的差异化在于组织围绕此重构协作方式。假设都往暗工厂方向发展在 Tessl 等公司观察到人采用这些技术时协作动态关系会彻底改变。组织方式和工具相互塑造今天不讲让 Agent 变好而是讲其对团队动态、平台和组织的改变。开发者的身份转变与新机遇开发者最终会成为指挥家、Agent 的编排者但很多开发者觉得入行不是为了花大量时间优化 Prompt、写更好的 SPEC这让他们有身份摩擦感。“Context engineering”概念给开发者台阶下但很多开发者仍觉得只与 Prompt 和 SPEC 打交道很空虚感觉从工程师变成“提示词管理员”。引入 Harness、循环让组织走向更高程度自治时新的技术路径打开开发者帮 Agent 造工具重新点燃了一批人让他们找到了硬核工程工作的新空间。应对怀疑者与开发者建议经常有人问如何搞定持怀疑态度的人回答是这些人是宝贝要把他们的隐性知识和判断力灌进 Agent。可让他们拿出知识和挑剔把抗拒者的愤怒和怀疑变成改进系统的动力。给公司开发者的建议是要有巨大心态转变别修 Agent 产出的代码去修产出代码的系统。要通过 Context、Harness、循环造“能造东西的东西”停留在“Human in the Loop”、自动补全、调 Prompt 阶段的人要提升到系统思维。工程实践与团队协作新变化要用好的工程实践最小化人类干预次数。“vibe coding”前期爽但现在要对 Agent 提带测试、更新文档、遵守代码规范等要求。若团队有人用“YOLO”野路子搞 vibe coding应立刻制止。走得靠前的团队有新仪式回顾会讨论系统问题而非代码问题。计划会上定义清晰的任务给 Agent 做边界模糊的留给人类出现自然分工。开发者学习周期与生产力指标开发者有学习周期团队 Lead 要设定节奏和约束如让开发者把 Context 做成可复用的。团队生产率暴涨下游和用户可能跟不上要用自动化帮助他们框架要延伸到下游上游需求输入环节也要卷入新工作流。衡量生产力的两个指标一是让 Agent 做对一件事所需的人工干预次数应持续下降二是从单兵作战转向共享系统有乘数效应一次对 Agent 系统的优化能让所有人受益。可先在小团队内共享 Context、改进 Harness再扩展到整个组织这就涉及平台团队。平台团队的角色与共享组件管理平台团队是共享型组织现在没太关注 Agent 相关新事物如技能注册中心、Context 评估系统、coding agent 的护栏和身份管理等。需有人推动平台团队成长到新的中心角色明确负责人否则团队各自为政不会有“Paved Road铺装路”。共享组件应放进注册中心避免各团队重复发明。但中心仓库需有人明确拥有某个领域确保东西可测试、模块化别人能扩展。建立共识难可能有多条铺装路供团队选择集中维护的是“轻松路径”。要让使用共享能力的人看到成本平台团队要让花费透明化这是优化的前提。组织转型与人才招聘核心主张是从单打独斗的开发者到团队层面共享 Context 和组件再到组织内部的“多人游戏系统”乘数效应会在组织层面爆发。VP 工程部思考转型时黑客松、午餐分享会等是通用套路但“发许可证、搞培训、让大家自由发挥”策略从未成功。组织侧要明确授权让团队 Lead 和平台团队推动转型不能靠超级个体完成。找人帮忙难现在职位名称混乱无法通过头衔判断候选人成熟度。很多公司采用新面试方式先让候选人用 AI 解题测试其利用 AI 能力再让他们解释方案测试测试能力和工程判断力最后看其协作和分享意愿。能极致用 AI、有扎实工程功底、愿意分享和协作的人才是所需之人且不要把技能简单分为“初级”或“高级”。VP 工程部的职责与团队规模考量VP 工程部要向上交差可展示干预次数减少、复用率提升等指标比比较“有 Agent 和没 Agent 的编码生产力”更有说服力。有人抱怨 Agent 花钱多不应直接砍花费而应优化如选对模型、给开发者更好的 Context 和 Harness。团队规模方面全能型人才搭配互补技能还需考虑预备人员、盯生产和工单人员、新人培养等组织里很难让每个团队变成一两个人。暗工厂与组织护城河暗工厂可能保留一点微光意味着要根据风险水平为不同类型变更选择不同自动化程度可在审计方面投入更多。组织的护城河是抓住沉淀下来的业务上下文这将持续交付带向持续学习关键是在改变系统部分的同时保持可靠性。赢家不是单打独斗的超级玩家而是懂得在多个层面改进组织的人。