开发者使用 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。
团队规模方面，全能型人才搭配互补技能，还需考虑预备人员、盯生产和工单人员、新人培养等，组织里很难让每个团队变成一两个人。
暗工厂与组织护城河
暗工厂可能保留一点微光，意味着要根据风险水平为不同类型变更选择不同自动化程度，可在审计方面投入更多。组织的护城河是抓住沉淀下来的业务上下文，这将持续交付带向持续学习，关键是在改变系统部分的同时保持可靠性。
赢家不是单打独斗的超级玩家，而是懂得在多个层面改进组织的人。
