Patrick Debois 认为，当 Agent 没有按预期完成任务时，问题不在开发者，而在公司没有为 Agent 准备好一套能工作的系统。真正的差异化，不在于技术，而在于组织如何围绕 Agent 重构协作方式。
真正的挑战不在技术，而在组织。
很多企业所谓的 AI 转型，仍然停留在给开发者购买工具、办几场培训、再让大家自行摸索。如果最后 Agent 效果不好，责任又落回到使用者身上。
但 Debois 提出了一个截然不同的视角：当 Agent 没有按你的预期完成任务时，不要再去修改它生成的代码，而要去改进整个系统。这是从确定性系统转向概率性系统时必须经历的变化。
调 Prompt → 改生成结果 → 继续调 Prompt → 陷入局部优化。开发者被困在「提示词管理员」的角色里，身份感模糊。
通过 Context、Harness、循环来构建「能造东西的东西」。一次系统改进，所有 Agent 产出质量同步提升。
Debois 用了一句精辟的总结：「别造那个东西了，去造那个能够造那个东西的东西。」这个抽象层级的跃迁，正是从单点调试走向系统工程的本质。
注：Debois 提出衡量 Agent 成熟度的两个核心指标。干预次数反映系统自动化水平，乘数效应反映组织共享能力。两者结合，才是真实的效率提升。
「如果你团队里还有人用那种 'YOLO'（先跑通再说）的野路子搞 vibe coding，你应该立刻制止。」Debois 强调，工程实践不仅对维护系统至关重要，对 Agent 自身持续变好也至关重要。
那组织该怎么办？
Debois 观察到，当团队开始深度采用 Agent 后，协作的动态关系发生了根本性变化。那些走得靠前的团队，已经开始出现新的仪式。
平台团队，是破局的关键。
Debois 直言：「别让每个团队都造一套 Harness。」如果每个团队都在自己的角落里发明同一套技能，那就是组织级的浪费。
平台团队需要从基础设施的提供者，成长为 Agent 时代的能力中心。这要求他们接管三类新资产：
但这里有一个组织难题：平台团队通常不碰开发层面的东西，开发者体验团队又不怎么碰基础设施。这种融合不会自动发生，必须有一个明确的 owner 来驱动。
Debois 的建议是：建立「铺装路」（Paved Road），而不是强制统一。集中维护的路径是「轻松路径」，用来吸引大家走上去。如果团队非要自己搞一套，也可以，但那算他们自己的预算。
他还强调了一个容易被忽视的点：让成本透明化。「如果你让花费可视化，人们自然就会去优化。这是平台团队的分内之事。」
注：平台团队的核心价值是创造乘数效应——一次对 Agent 系统的优化，能在整个组织范围内产生复利。
那该招什么样的人？
Debois 对当前的招聘现状很不满：「AI 产品工程师、forward deployed engineer、agentic 工程师……这些词其实没什么实质意义。」你没法通过头衔判断一个人的成熟度。
他提出了一个三维人才标准，并建议用三阶段面试来考察：
「能极致用 AI、有扎实工程功底、愿意分享和协作，将这三点组合，才是你要找的人。」Debois 特别提醒：别把这些技能混在一起贴上「初级」或「高级」的标签，它们是不同的技能维度——一个人可能 AI 利用能力是「高级」，但协作意愿是「初级」。
他还讲了一个有趣的细节：有的候选人在面试时用 AI 在耳朵里实时给答案，AirPods 里传来 AI 的建议。这恰恰说明面试方式需要升级——不是禁止 AI，而是设计能同时考察 AI 利用能力和工程判断力的流程。
Agent 时代的组织变革，不是「给开发者配上工具，然后让一千朵花绽放」。赢家不会是单打独斗的超级玩家，而是那些在多个层面上懂得如何改进组织的人。护城河不再是模型参数，而是沉淀在系统里的业务上下文和持续学习的能力。
① 停止让团队各自摸索，建立共享的 Context 和 Harness 体系。
② 把「人工干预次数」和「乘数效应」作为衡量 Agent 成熟度的核心指标。
③ 用三维度标准重新审视你的团队，识别能力短板并针对性地补位。
完整演讲内容可在视频平台查阅，搜索「Patrick Debois Agent 组织变革」。