编译｜宇琪 策划 | Tina 如果一名开发者怎么都用不好 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 整理，不代表平台观点，也不构成投资建议，未经许可禁止转载。

        今日好文推荐MCP 迎来最大更新：重回上古时代HTTPAltman 带着 GPT-6 进白宫？

        OpenAI 新模型押注“Agent 团队”，或成美国首批过审模型GPT-5.6 当老板：买假用户、被Chrome干崩3小时，烧掉3亿Token收入却为0DeepSeek V4 Flash 发布，基测超过 GLM-5.2会议推荐2026 年 AICon 人工智能开发与应用大会 · 深圳站将于 8 月 21 日—

        22 日举办，聚焦 AI 基础设施、大模型系统、智能体工程、数据智能、多模态技术与行业落地等关键方向，邀请来自腾讯、阿里、华为、百度、蚂蚁集团等 50 + 头部科技企业技术负责人、科研机构一线专家，系统性分享前沿洞察与实战干货，共同探讨 AI 技术从能力到系统、从实验到生产的真实路径。

        大会限时 9 折优惠，现在报名立减 580，更多详情可扫码或联系票务经理 13269078023 进行咨询。