如果一名开发者怎么都用不好 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 自身持续变好也至关重要。

我在一些走得比较靠前的团队里开始看到一种新的仪式，他们仍然做计划会和回顾会，但讨论的内容彻底变了。回顾会上不再说“代码出了什么问题”，而是说“系统出了什么问题？”

在计划会上我也看到了一个有趣的分裂。那些定义得非常清晰、范围足够明确的任务，直接就能丢给 Agent 去做，因为 Harness 越来越好，它们能消化这种明确的任务。而那些边界模糊、需要商量的事情，依然留给人类。所以计划会上出现了一种自然分工：这些卡片直接走 Agent 流水线，那些卡片我们来聊。

开发者通常会经历一个学习周期：先学 Prompt，然后是更好的 SPEC，接着是 Context、Harness、循环，整个行业也在这个周期里爬。但团队 Lead 可以做的，是给这个进程设定节奏和约束，比如告诉他们：“别再调 Prompt 了，把 Context 做成可复用的。”“好，这一步做完了，我们跳到下一步。”团队 Lead 的价值就在于设定这种节奏，如果你只是丢下一句“自己去摸索”，那是不灵的。

还有一个连带效应：一旦你们团队的生产率开始暴涨，下游的人，比如搞 GTM（Go to Market） 的会跟不上，甚至用户也会跟不上。所以你需要用自动化来帮助他们，你的框架不能停在编码这一步，必须延伸到他们那边去。同样的道理也适用于上游的需求输入，如果需求来得不够快，团队就会被卡住，这些环节也需要被卷入这个新的工作流里。

现在市面上有一堆指标，什么 Token 花费之类的。但我开始越来越相信两个真正能衡量生产力的指标。第一个：你数一下，要让 Agent 做对一件事，你还需要多少次人工干预？这个数字应该是持续往下降的。你的 Harness 越好，Context 越好，指南越清晰，这个数字就越低。第二个指标，是当你从单兵作战转向共享系统时，有一个乘数效应。你在一个地方修好了某个东西，所有人都跟着受益。这不是说一个人变成十倍效率，而是一次对 Agent 系统的优化能在所有人身上产生乘数效应，

你可以在一个仓库里、一个小团队内部先启动，共享 Context，一起改进 Harness。但你真正想要做的，是把这种效应扩展到整个组织。这时候，我们就不得不谈到平台团队了。

别让每个团队都造一套 Harness 

平台团队是典型的共享型组织，现在他们可能在搞基础设施、云服务、MCP 网关之类的东西，没太关注 Agent 这块。但有一堆新东西正在冒出来，需要他们接手，比如技能注册中心（不能让每个人都在自己的角落里发明同一套技能）、Context 的评估系统（这段 Context 到底有没有用？能不能量化？）、专门针对 coding agent 的护栏和身份管理（Agent 以谁的身份提交代码？权限边界在哪？）。所以平台团队需要有人拉一把，帮他们成长到这个新的中心角色上。

这事很难，你必须有一个明确的 owner 来驱动。但这该是谁？平台团队？开发者体验团队？前者通常不碰那些开发层面的东西，后者又不怎么碰基础设施，所以需要某种融合，但这个融合不会自动发生。你需要确保有一个负责人来推动这个中心化的工作，否则你的团队就只是在自己的一亩三分地里折腾，不会有“Paved Road（铺装路）”出现。

为什么我们每个团队都要各自发明一套认证系统的对接方式？这是共享组件，应该放进注册中心。为什么要各搭各的 Harness？如果我们都用同一个 linter、同一套安全扫描工具，那这就是可复用的组件。我认为这会像当年云基础设施的铺装路一样，逐步集中到平台注册中心里。

但问题是，如果谁都能往这个中心仓库里随便丢东西，就会迅速野蛮生长（becomes a sprawl）。比如一个 skill 放上去了，谁在维护？另一个人又 fork 了一个类似的 skill，那我该选哪个？所以必须有人明确拥有某个领域，他要确保这个东西是可测试的，是模块化的，别人能在这个基础上扩展 Context 或者 Harness 里的安全扫描部分。你得用集中化的方式来做，而不是在组织内部随便传。

建立共识很难。这不像 tabs 和 spaces 之争那么有名，但有时候感觉差不多。如果你让两个开发团队就工作方式达成共识，那需要大量的沟通和调停工作。所以最后你很可能不是只有一条铺装路，而是三条四条，他们可以从中选。如果他们非要自己搞一套，也可以，但那是他们自己的预算。集中维护的才是“轻松路径”，用来吸引大家走上去。

如果大家盲目地使用这些共享能力，你必须让他们看到成本。只要你把花费可视化出来，他们自然就会想去优化。这是平台团队的分内之事，让花费透明化：花了多少？帮到了什么程度？如果我能减少 Agent 的迭代次数，那就是优化。但如果我看不到这个指标、只看到最终结果，那我就没法下手，可视化是一切优化的前提。

所以我的核心主张是：我们要从单打独斗的开发者，走到团队层面的共享 Context 和共享组件，最终走到整个组织内部的“多人游戏系统”。乘数效应会在那里爆发，因为你有一个飞轮，改进可以向多个方向同时辐射。

超级个体救不了 Agent 时代的组织 

再往上一层，VP 工程部怎么思考这件事？我差不多能预测你们组织里会发生的故事：黑客松或者午餐分享会、分享成功案例、建一个共享 Slack 频道、搞一个 champions program。这些都是通用的转型套路。当年 Agile 转型这么干过，DevOps 也这么干过，没什么新鲜的。

另一方面我们也知道，“发许可证、搞培训、让大家自由发挥、让一千朵花绽放”这个策略从来就没成功过。一千朵花的结果通常是一千根杂草，百花齐放但没有一朵能结果。所以我主张，在组织侧要明确授权，让团队 Lead 和平台团队去做这件事。它不是靠某个超级个体就能完成的，必须有人被正式授权去推动。

找人帮忙也是头疼事。现在的职位名称一塌糊涂，AI 产品工程师、forward deployed engineer、agentic 工程师、AI 工程师……这些词其实没什么实质意义。你没法通过头衔判断一个人的成熟度，因为整个行业都不成熟。不过你发招聘需求的时候，这些词确实能带来一些信号，吸引有意图的人来投，但它本身并不代表对方就一定具备相应技能。我还听过一些更离谱的故事，有的候选人在面试时用 AI 在耳朵里实时给答案，面试官问一个问题，AirPods 里就传来 AI 的建议。

所以我听到越来越多公司采用这样一种面试方式。第一步，给一个练习，让他们用 AI 放手去解题，使劲用。如果 AI 能帮他们搞定，那恰恰说明他们擅长利用 AI。第二关，请他们查自己的方案，解释“你为什么要选这个方案？你怎么验证它是对的？”，这时候你在测试的是测试能力和工程判断力。前半段考 AI 利用能力，后半段考工程功底。第三，还要看他们怎么协作，愿不愿意分享，是开放型还是单干型。有的人技术很强但什么都要自己捏在手里，这种人在 Agent 时代反而会成为瓶颈。

能极致用 AI、有扎实工程功底、愿意分享和协作，将这三点组合，才是你要找的人。不是学过 ML 或 AI 的，也不是什么解码专家，而是一种混合体。你很可能找不到三点全满的人，那也没关系，比如某个候选人在某方面特别强，但在另一方面需要指导。同时，别把这些技能混在一起贴上“初级”或“高级”的标签，它们是不同的技能维度，一个人可能 AI 利用能力是“高级”，但协作意愿是“初级”。

VP 工程部还得向上交差。我们买了这么多许可证，能证明投入产出吗？交付变快了？可能有承诺但很难证明。质量变好了？同样很难说。 但回到我之前说的那两个指标，你可以展示干预次数减少了多少，改进了多少，还有复用率提升了多少。这比去比较“有 Agent 和没 Agent 的编码生产力”要容易得多，也更有说服力。

所以，当有人抱怨 Agent 太能花钱，说要限制额度的时候。你的本能反应不应该是“我们把所有花费都砍掉”，而应该是“我们怎么优化花费”。最简单的做法是选对模型，不是所有任务都需要最强的模型，有些任务用便宜的模型就够了。教育开发者什么场景用什么模型，更进一步，给他们更好的 Context 和 Harness，这会让 Agent 少走弯路，成本降得更狠。

还有一个关于团队规模的话题。一个全能型人才把所有活干了，那是终极梦想。但你仔细算一下：这个人通常得搭配互补技能，比如产品经理或设计。然后你还要考虑预备人员（backup），万一有个人休假了呢？这就又回到三个人了。再然后可能还要有人盯生产和工单，如果你真的极度高效，可能是同一拨人兼职做。但你一旦修 bug，做特性的速度就会下来。最后还有新人，你要给他们铺路，让他们知道“好”是什么样的。所以我依然认为，在组织里我们不可能真的让每个团队变成一两个人。

最后，暗工厂可能不是全暗，而是保留了一点微光（dim factory），这意味着你得决定对什么功能承担多少风险，不是所有功能都适合完全自治。你可以在审计方面投入更多，比如溯源，谁改的代码？是人还是 Agent？加验证器检查代码是否真的有用，当自动流程失败时投资于情景感知能力。从完全微观管理（每行代码都要人看过），到完全自主审批（假设 Agent 产出都是对的），这是一整个光谱。你要做的，是根据风险水平为不同类型的变更选择不同的自动化程度。

而我认为你的护城河，是抓住沉淀下来的知识，那些你现在注入到 skill 里、Context 里、甚至 Harness 约束里的业务上下文。对我来说，这实际上把持续交付带向了持续学习。试问自己：我们能多快地把一个新东西换进系统、再把一个旧的东西换出来？这是你的反应能力。如果你能持续改进这种能力，问题的关键就不再是“我要让整个系统更可靠”，而是“我能不能在改变系统越来越多部分的同时，保持它的可靠性？”

如果只带走一句话，那应该是：赢家不会是那个单打独斗的超级玩家，而是那些在多个层面上懂得如何改进组织的人。

演讲原视频链接：https://www.youtube.com/watch?v=b6dKwe00GpQ

本文来自微信公众号“InfoQ”，作者：Tina；编译：宇琪