别再修代码了，去修系统：DevOps 之父说，Agent 时代的组织变革比技术更难
摘要： 当 AI 编程工具效果不佳时，问题可能不在开发者，而在组织没有为 Agent 准备好可运行的系统。DevOps 一词的提出者 Patrick Debois 在近期分享中指出，软件工程正从确定性走向概率性系统，真正的挑战不是优化 Prompt，而是围绕 Agent 重构团队协作与组织架构。
如果一名开发者怎么都用不好 Agent，问题可能并不在开发者，而在公司根本没有为 Agent 准备好一套能工作的系统。
很多企业所谓的 AI 转型，仍然停留在给开发者购买 Cursor、Claude Code 等工具，办几场培训，再让大家自行摸索。如果最后 Agent 效果不好，责任又落回到使用者身上。
但 DevOps 一词的提出者 Patrick Debois 认为：“开发者需要完成一个重要的思维转变：当 Agent 没有按你的预期完成任务时，不要再去修改它生成的代码，而要去改进整个系统，而不是只改 Prompt。”
在 Debois 看来，这是软件工程从确定性系统转向非确定性、概率性系统和工作流时必须经历的变化。它不仅涉及技术，也会重塑开发者、团队和整个组织的工作方式。但这种变化不可能只靠某一个工程师，也无法仅停留在单个团队层面。它和 DevOps 一样，只有在规模化落地后，才能真正实现。
问题的核心不只是开发者会不会用 Agent，而是公司能否围绕 Agent，重新组织团队、平台和协作方式。
给开发者配上 Claude Code，组织就转型了？
Debois 用了一个类比来展开这个话题：2009 年，当他在各种场合推广持续交付时，很多人告诉他这个想法简直是疯了。当时行业普遍采用数月一次的大版本集中上线模式，大家默认发布越频繁风险越高，持续交付提出高频、增量、随时可发布的思路，在多数企业看来近乎天方夜谭。
而现在，他观察到一个相似的现象正在发生——当谈到 AI 驱动的自治软件生产模式（也就是所谓“暗工厂”，人类只输入需求规格，由 AI 自主完成编码、测试与上线）时，同样的阻力再次出现。
Debois 在各种场合反复听到同一句话：“这东西在我们这儿行不通。”但他认为，这句话真正在传达的信息不是技术不行，而是“我们还没准备好”。很多组织不是不想实现这种模式，而是现有的组织设置还无法支持它。
他指出，现在很多人都在讲怎么优化 Agent 循环、怎么搭建 Harness（即对 Agent 行为的约束框架），这些当然都很重要。但关键在于：最终我们都会达到那个技术水平，这些能力会变成某种标准商品，甚至被前沿实验室打包成服务提供出来。到那时，技术上就没有壁垒了。
真正的差异化，在于你的组织怎么围绕 Agent 重构协作方式。
康威定律的 Agent 版本：组织方式决定系统形态
Debois 说，他在 Tessl 及其他公司观察到，当人们开始采用这些 Agent 技术时，协作的动态关系会发生彻底改变。他援引康威定律——组织的沟通结构会直接反映在所构建的系统架构上——指出组织方式和工具之间存在一种相互塑造的关系。你怎么组织人，就会造出什么样的系统。
但他特别强调，今天要讨论的不是如何让 Agent 变得更好，而是这种变化如何反过来改变团队动态、平台架构和整个组织。团队协作与一个人对着 Claude Code 敲东西，完全是两码事。
从工程师到“提示词管理员”：身份摩擦是真实存在的
现在业界流行一种说法：开发者最终会变成一个指挥家、一个 Agent 的编排者。Debois 认为这个方向没错，这确实是正在发生的路径——我们越来越像 Agent 的管理者，要处理和 Agent 之间的关系。
但问题在于，很多开发者私下表达过一种矛盾心理：我们当初入行可不是为了干这个的。我们没想过要花大量时间去优化 Prompt、去写更好的需求规格。我们是工程师，我们搞的是技术。这种身份上的摩擦感，会让人不断追问：这真的是我想做的角色吗？
后来出现了一个概念叫“Context engineering”（上下文工程），算是给开发者一个台阶下。它说的是，这不仅仅是调 Prompt，你还要测试、评估、分发、优化 Prompt，所以确实有那么一点工程的味道在里面。但说实话，很多开发者仍然觉得只跟 Prompt 和规格文档打交道很空虚，感觉自己从工程师变成了“提示词管理员”。
这个身份转变的问题，不仅仅是个人感受层面的——它会直接影响到组织能否顺利过渡到 Agent 驱动的工作模式。
关键要点
- 思维转变是第一步：Agent 产出不符合预期时，不要只修代码或调 Prompt，要思考如何改进整个产出系统。
- 技术终将商品化：Agent 能力会变成标准化服务，组织的差异化优势在于协作方式的重新设计。
- 康威定律依然适用：你怎么组织团队，就会造出什么样的系统——Agent 时代也不例外。
- 身份摩擦是正常现象：开发者从写代码转向管理 Agent 的过程中，会产生角色认同的困惑，这需要组织层面的正视和疏导。
- “我们没准备好”是真问题：技术方案的落地阻力往往不来自技术本身，而来自现有的组织设置和协作方式。
开发者正在经历的转变，不是换一个写代码的工具，而是整个工作重心的迁移：从“修 Agent 生成的代码”升级为“修产出代码的那套系统”。这套系统里，工程实践、共享上下文、团队节奏和平台工具缺一不可。真正的生产力指标，也不再是代码量，而是“人工干预的次数”和“一次优化带来的乘数效应”。
给 Agent 造工具，反而点燃了“手艺感”
引入 Harness（给 Agent 设的护栏和工具链）、循环，并推动团队走向更高自治的过程中，一条新的路径被打开了：开发者需要为 Agent 造工具。这个变化出乎意料地重新点燃了一批人。那些之前觉得“这活儿不该我干”的开发者，一下子来了精神——他们发现，自己掌握的知识正好可以用来编程的方式让整个系统变得更好。
这里有个很有意思的反差：当我们一直在强调“抽象、抽象、再抽象”时，“手艺感”反而在另一个层面重新冒了出来，为更硬核的工程工作腾出了新空间。
不要修代码，修产出代码的系统
经常有人问我：怎么搞定那些持怀疑态度的人？我的回答永远是：这些人其实是你的宝贝。他们脑子里装着大量隐性知识和判断力，而你需要做的，就是把它们提炼出来，灌进 Agent 里。你可以直接告诉他们：“请把你所有的知识和挑剔都拿出来。”这种“挑剔”恰恰能让 Agent 和 Harness 变得更好。如果碰到那种心怀抵触、天天抱怨“这玩意儿生成的代码质量太差”的开发者，不妨把他们当作燃料，把那股愤怒和怀疑，转化为改进系统的动力。
所以，我给公司开发者的建议，是一个巨大的心态转变：不要再修 Agent 产出的代码了，去修那个产出代码的系统。
就像几年前有人说过的那句话：别造那个东西了，去造那个“能造出那个东西”的东西。我们现在正是处在这个抽象层级上——通过 Context（给 Agent 的上下文信息）、Harness、循环来构筑“能造东西的东西”。很多人还停留在“人类在环中”、自动补全、调 Prompt 的阶段，他们真正需要想清楚的，是怎么把自己拉升到系统思维上来。
我们真正要做的是，用好的工程实践来最小化人类的干预次数。刚开始接触 Agent 编程时，大家都觉得“vibe coding”（凭感觉随手写）很爽：丢一段 Prompt，出一个结果，别管好坏，继续往下跑。但现在已经越来越清楚的是，我们不只是通过 Prompt 给 Agent 下指令，我们实际上是在说：请带测试一起写、请更新文档、请遵守代码规范。原来我们对一名好工程师说过的话，现在全部原封不动地搬给 Agent。如果团队里还有人在用“YOLO”（先跑通再说）的野路子搞 vibe coding，你应该立刻制止。工程实践不仅对维护系统本身至关重要，对 Agent 自身的持续改进同样关键。
会议变了吗？变了：聊“系统”而不是聊“代码”
我在一些走得比较靠前的团队里，看到一种新的“仪式”正在形成：他们仍然开计划会和回顾会，但讨论的内容彻底变了。回顾会上不再说“代码出了什么问题”，而是说“系统出了什么问题？”
计划会上也出现了一个有趣的分裂。定义清晰、范围明确的任务，直接丢给 Agent 去处理——因为 Harness 越来越好，它能消化这类明确的任务。而那些边界模糊、需要协商的事情，依然留给人类。于是计划会上自然出现了一种分工：这些卡片直接走 Agent 流水线，那些卡片我们来谈。
开发者通常会经历一个学习周期：先学 Prompt，然后是更规范的 SPEC，接着是 Context、Harness、循环。整个行业也在这个周期里往上爬。团队 Lead 可以做的，是给这个进程设定节奏和约束。比如明确告诉团队成员：“别再调 Prompt 了，把 Context 做成可复用的。”“好，这一步做完了，我们跳到下一步。”团队 Lead 的价值，正在于设定这种节奏——如果只是丢下一句“自己摸索”，那是不灵的。
一个连带效应：上下游都会被卷入
还有一个容易被忽略的连带效应：一旦团队的生产率开始暴涨，下游就很容易掉队，比如搞 GTM（Go to Market，市场销售）的团队，甚至用户本身也会跟不上。所以你需要用自动化去帮助他们——你的框架不能停在编码这一步，必须延伸到他们那边。
同样的道理也适用于上游的需求输入。如果需求来得不够快，团队就会被卡住。这些环节，早晚都要被卷入这个新的工作流里。
两个真正值得看的生产力指标
现在市面上有一堆指标，比如 Token 花费之类。但我越来越确信，有两个指标才能真正衡量生产力。
第一个：人工干预次数。 数一数，要让 Agent 做对一件事，你还需要多少次人工介入？这个数字应该持续下行。你的 Harness 越好、Context 越充足、指南越清晰，这个数字就越低。
第二个：共享系统的乘数效应。 当你从单兵作战转向共享系统时，一次改进会惠及所有人——不是一个人变成十倍效率，而是对 Agent 系统的一次优化，能在所有人身上产生乘数效应。
你可以先在一个仓库、一个小团队内部启动，共享 Context，一起改进 Harness。但你真正想要做的，是把这种效应扩展到整个组织。这时候，我们得谈谈平台团队了。
别让每个团队都造一套 Harness
平台团队本身就是典型的共享型组织。他们现在可能在做基础设施、云服务、MCP（模型上下文协议，一种给 AI 工具统一提供上下文的协议标准）网关之类的事，还没太关注 Agent。但有一批新任务已经冒出来了，需要他们接手：
- 技能注册中心：不能让每个人都在自己的角落里重复发明同一套技能
- Context 评估系统：这段 Context 到底有没有用？能不能被量化？
- 针对编码 Agent 的护栏和身份管理：Agent 以谁的身份提交代码？权限边界在哪？
所以，平台团队需要有人拉一把，帮他们成长到这个新的中心角色上。