别再修代码了，去修系统：DevOps 之父说，Agent 时代的组织变革比技术更难

如果一名开发者怎么都用不好 Agent，问题可能并不在开发者，而在公司根本没有为 Agent 准备好一套能工作的系统。 很多企业所谓的 AI 转型，仍然停留在给开发者购买 Cursor、Claude Code 等工具，办几场培训，再让大家自行摸索。如果最后 Agent 效果不好，责任又落回到使用者身上。 但DevOps 一词的提出者 Patrick Debois 认为：“开发者需要完成一个重要的思维转变：当 Agent 没有按你的预期完成任务时，不要再去修改它生成的代码，而要去改进整个系统，而不是只改 Prompt。” 在 Debois 看来，这是软件工程从确定性系统转向非确定性、概率性系统和工作流时必须经历的变化。它不仅涉及技术，也会重塑开发者、团队和整个组织的工作方式。但这种变化不可能只靠某一个工程师，也无法仅停留在单个团队层面。它和 DevOps 一样，只有在规模化落地后，才能真正实现。 问题的核心不只是开发者会不会用 Agent，而是公司能否围绕 Agent，重新组织团队、平台和协作方式。 核心观点如下： 不要再修 Agent 产出的代码了，去修那个产出代码的系统。如果你团队里还有人用那种“YOLO（先跑通再说）”的野路子搞 vibe coding，你应该立刻制止。工程实践不仅对你维护系统至关重要，对 Agent 自身持续变好也至关重要。暗工厂可能不是全暗，而是保留了一点微光（dim factory），这意味着你得决定对什么功能承担多少风险，不是所有功能都适合完全自治。能极致用 AI、有扎实工程功底、愿意分享和协作，将这三点组合，才是你要找的人。你的护城河，是抓住沉淀下来的知识，那些你现在注入到 skill 里、Context 里、甚至 Harness 约束里的业务上下文。 给开发者配上 Claude Code，组织就转型了？ 2009 年的时候，一大堆人告诉我持续交付这个想法简直是疯了。 译者注：2009 年，行业普遍采用数月一次的大版本集中上线模式，大家默认发布次数越多风险越高，加之开发与运维壁垒森严、容器与云等自动化基础设施尚未成熟，缺少标准化pipeline工具，同时传统测试、变更审批机制追求上线前尽可能扫清缺陷，而持续交付提出高频、增量、随时可发布的思路，颠覆了大众对软件上线风险、流程管控的固有认知，因此在多数企业看来近乎天方夜谭、十分疯狂。 而现在，暗工厂又遇到了完全一样的阻力。 译者注：暗工厂指 AI 驱动的自治软件生产模式，人类只输入SPEC，由 AI 自主完成编码、测试与上线，无需人工逐行审查代码，区别于仍需要大量工程师参与流程的传统软件工厂。 我在各种场合反复听到同一句话：“这东西在我们这儿行不通。”但这句话真正在传达的信息不是技术不行，而是“我们还没准备好”。他们不是不想实现这个东西，而是现在整个组织的设置还没法支持这种模式。 现在很多人都在讲怎么用循环优化 Agent，怎么搭 Harness，这些都很棒。但我想说的是，最终我们都会达到那个技术水平，终有一天它们会变成某种标准商品，甚至被某个前沿实验室打包成服务提供出来。到了那一天，技术上就没壁垒了。真正的差异化，在于你的组织怎么围绕这个东西重构协作方式。 所以我假设我们都在往暗工厂的方向走。我在 Tessl 以及别的公司里观察到的是，当人开始采用这些技术时，协作的动态关系会彻底改变。你们如果熟悉康威定律，就知道组织方式和工具之间存在一种相互塑造的关系——你怎么组织人，就会造出什么样的系统。但我今天不想讲怎么让你的 Agent 变得更好，我要讲的是这如何改变你的团队动态、你的平台以及你的整个组织。 我猜在座大部分人都在某个团队里工作，而不是单打独斗，团队协作和一个人对着 Claude Code 敲东西是完全不同的两码事。 现在大家都喜欢讲一个说法：开发者最终会变成一个指挥家、一个 Agent 的编排者。我觉得这个说法没毛病，这确实是我们正在走的路径。我们越来越像 Agent 的管理者，要处理和 Agent 之间的关系。 但问题是，我听到很多开发者私下说：我们当初入行可不是为了干这个的，我们没想过要花大量时间去优化 Prompt、去写更好的SPEC。我们是工程师，我们搞的是技术，这让我们有一种身份上的摩擦感，会不断问自己：这真的是我想做的角色吗？ 后来出现了一个概念叫“Context engineering”，算是给了开发者一个台阶下。它说的是，这不仅仅是调 Prompt，你还要测试、评估、分发、优化 Prompt，所以确实有那么一点工程的味道在里面了。但说实话，很多开发者仍然觉得只跟 Prompt 和SPEC打交道很空虚，感觉自己从工程师变成了“提示词管理员”。 但我在实践中观察到一个很有意思的转折点。当我们开始引入 Harness、循环，甚至让整个组织走向更高程度的自治时，一条全新的技术路径打开了。突然间，开发者需要帮 Agent 造工具，这一下子就重新点燃了一批人。那些之前觉得“这不是我该干的”的开发者，瞬间就来劲了。他们说，没错，我们能干这个！我们掌握这种知识！我们可以用编程的方式帮这个系统变得更好。所以这很有意思，当我们一直在讲“抽象、抽象、再抽象”的时候，“手艺”感反而在另一个位置重新冒了出来，为更硬核的工程工作找到了新的空间。 不要修代码，修产出代码的系统 经常有人问我：怎么搞定那些持怀疑态度的人？我的回答永远是：这些人其实是你的宝贝。因为他们脑子里有大量的隐性知识和判断力，你需要把这些东西灌进 Agent 里。你可以告诉他们：“请把你所有的知识和挑剔都拿出来”，这能让 Agent 和 Harness 变得更好。如果你碰到那种比较抗拒的，天天抱怨说“这玩意儿生成的代码质量太差了”，你可以把他们当作燃料，把这股愤怒和怀疑，变成改进系统的动力。 现在让我给公司的开发者们提一条建议，我会提出一个巨大的心态转变：不要再修 Agent 产出的代码了，去修那个产出代码的系统。就像几年前有人说过一句话：别造那个东西了，去造那个能够造那个东西的东西。我们现在就在这个抽象层级上，通过 Context、Harness、循环来造“能造东西的东西”。很多还停留在“Human in the Loop”、自动补全、调 Prompt 这个阶段的人，需要思考怎么把自己拔高到系统思维上来。 我们真正要做的，是用好的工程实践来最小化人类的干预次数。刚开始的时候，大家都觉得“vibe coding”很爽，丢个 Prompt，出一个结果，管它呢继续往下跑。但现在越来越清楚的是，我们不只是通过 Prompt 给 Agent 下指令，我们其实在说：请带测试一起写、请更新文档、请遵守代码规范。原来我们对好工程师说的那些话，现在全部原样搬给 Agent。如果你团队里还有人用那种“YOLO（先跑通再说）”的野路子搞 vibe coding，你应该立刻制止。工程实践不仅对你维护系统至关重要，对 Agent 自身持续变好也至关重要。 我在一些走得比较靠前的团队里开始看到一种新的仪式，他们仍然做计划会和回顾会，但讨论的内容彻底变了。回顾会上不再说“代码出了什么问题”，而是说“系统出了什么问题？” 在计划会上我也看到了一个有趣的分裂。那些定义得非常清晰、