专栏 · Agent 工程手艺 › 第 192 期 · AGENT 工程 · 收录于 2026 年 8 月 23 日
编码 Agent 不会自己规模化,你的团队也不会——Patrick Debois(Tessl)
PD
Patrick Debois · AI Engineer
8,982观看
189赞
2.1%点赞率
9评论
62.7万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一harness、loop 这些 agent 调优技术终将变成大路货甚至 frontier lab 的标准服务，不会是你组织的差异化优势；「这在我们这儿行不通」的真实含义是「我们还没搭好架子」——差异化在团队、平台、组织怎么跟着变。 → 详细
- 二最大的心态转变是「别修 agent 写的代码，去改进系统」：retro 的主语从代码变成系统，团队负责人要定节奏施约束（「别再写 prompt 了，把 context 做成可复用的」），只盯两个指标——人工介入次数往下降、一次修复的受益人数往上升。 → 详细
- 三规模化必须有 owner 铺 paved road（共享的 context / harness / skill 注册中心 + 成本可视化），VP 层要把授权给团队负责人和平台而不是办 hackathon；黑灯工厂其实是「昏灯工厂」——按功能定风险，赢的不会是独行侠。 → 详细
01
「这在我们这儿行不通」= 「我们还没准备好」：黑灯工厂是前提，不是争论点
- Patrick Debois（Tessl，DevOps 一词的提出者）开场就把话说死：他讲的不是技术，是组织。2009 年大家说「持续交付（continuous delivery，代码一提交就能自动测试、随时可上线）太疯狂了」，今天大家对「黑灯工厂（dark factory，指软件开发大部分环节由 agent 自主跑、人几乎不碰）」说的是同一句话：「这在我们这儿行不通。」他听出的真正信号是：「不是技术做不到，也不是他们最终做不到，只是他们还没为此搭好架子。」 → 详细
- 大会上满场都在讲 loop、harness（给 agent 套的"工作台"：工具、检查、循环、护栏的整套脚手架）怎么调优，他承认这很好，但判断是：这些终将变成大路货，「说不定某个 frontier lab 直接把它做成服务提供给你」，到那时它就不再是你们组织的差异化优势。所以整场演讲的起点是一个假设：我们正在奔向黑灯工厂，组织内会出现某种形式的自主工作方式——问题只剩"你的团队、平台、组织怎么跟着变"。 → 详细
- 他引康威定律（Conway's Law：你们怎么组织自己，做出来的系统就长成什么样；工具和组织互相塑形）点明视角：不讲「你怎么把自己的 agent 用得更好」，讲「它会怎么改变团队动态、平台和组织」。并且明确区分两种玩法：「就你一个人配一个 Claude Code」和「一个团队围绕 coding agent 一起干活」，是不一样的。 → 详细
02
开发者的身份危机：「我们没报名来写 prompt」，直到「给 agent 造工具」重新点燃他们
- 流行叙事说开发者会变成 agent 的「指挥家 / 编排者」，他认可这是演化方向，但现场听到的反弹是：「我们当初可没报名干这个。我们不是来学怎么写更好的 prompt、写更好的 spec 的。我们是工程师，我们是搞技术的。」 这就是摩擦——这真是我们想要的角色吗？context engineering（上下文工程：把 prompt 当成要测试、评估、分发、优化的工程对象）算往前迈了第一步，但「整天跟一个 prompt、一份 spec 打交道」很多开发者仍觉得空落落。 → 详细
- 转机出现在引入 harness 和 loop、推更自主的工作方式之后：一条新的技术路径打开了——「突然之间，我们在用工具帮 agent，在给 agent 造工具」，那些原本觉得「这不适合我」的开发者重新被点燃：「对，这个我们能干。我们有这方面的知识。我们能用程序化的方式来帮它。」他觉得有趣的是身份认同这一层：一边在技术上喊「抽象、抽象、再抽象」，一边这门手艺又开辟出一块新地盘，让工程性的活有地方可去。 → 详细
- 对「团队里的怀疑派怎么办」他的答案是反直觉的：这些人恰恰最适合拉进来给 agent 做更好的 context 和 harness。跟他们说「把你所有的知识都拿出来，让 agent 的产出更好」——「几乎是借用他们那股火气、那股怀疑劲儿，去把东西做得更好」。 → 详细
03
最大的心态转变：别修 agent 写的代码，去改进系统
- 如果现在给一家公司的开发者只提一条建议，他选这条：「别再去修 agent 写出来的代码了，去改进系统。」 他引 Swyx 几年前的话「别造那个东西了，去造『造那个东西的东西』」——靠 context、harness、loop 往上走一层抽象。还紧紧扒在循环里（自动补全、手写 prompt）的人，需要把自己提升到系统思维这一层。目标是：把人工介入降到最少，但仍然保持好的工程实践。 → 详细 → 详细
- 早期叙事是「我在 prompt 里写代码，它给结果，就能一直往下走」；现在变成了「请配上测试、请更新文档」——我们对优秀工程师说的所有那些话，现在都在要求 agent 去做。对还在 yolo 式瞎搞的人要直说「不行，别这么干了」：工程实践依然重要，既为了你能维护系统，也为了 agent 在这上面越来越好。 → 详细
- 更先进的团队里，planning 和 retro（回顾会）这些仪式的主语变了：聊的不再是「我们的代码出了问题」，而是「我们的系统出了问题」——retro 变成「agent 一遍又一遍撞上这个问题，我们能不能把系统修一下？」。planning 那边也出现了一个清晰的分界：范围界定得足够清楚的事 agent 很容易接手，留给人的恰恰是那些范围还没划清楚的东西。 → 详细
04
团队负责人的新工作：定节奏、施约束，「别再写 prompt 了，把 context 做成可复用的」
- planning 分流成两类：「定义清楚、可以直接丢给 agent 的事」（harness 也在一直变好）和「需要团队讨论着定下来的事」。他强调开发者有一个固定的成长周期——先学 prompt，再到 spec、context、harness、loop，整个行业也在这么学——但团队负责人的职责是主动推进这个周期：「好了，别再写 prompt 了，把 context 做成可复用的。这个搞定了，再跳到下一步。」 → 详细
- 他的原话是：团队负责人的一部分工作「就是在团队里定节奏，几乎是施加一种约束、一种指令」。「如果你只说『你们自己去琢磨、自己搞点什么』，是行不通的。」 → 详细
- 产出变多的副作用：下游的 GTM（go-to-market，市场 / 销售 / 客户成功这些把产品推向市场的人）跟不上，连用户都跟不上；上游需求收集的输入也可能喂不够快。所以 harness 不能止步于写代码，要延伸到下游的人和上游的需求流，用自动化帮他们。 → 详细
05
他只信两个指标：人工介入次数往下降，一次修复的受益人数往上升
- 大家都在谈「token 花了多少」之类的指标，他说自己开始只相信两个。第一个：衡量「为了让 agent 把事做对，你还需要人工介入多少次（human touches）」——harness 越好、context 越好、指南越好，这个数就该一路往下降。 → 详细 → 详细
- 第二个：从单打独斗走向共享系统后出现的乘数——「你修一次，所有人都受益」。他特意区分：「这不是『一个人变成 10 倍工程师』那种乘数，而是一次针对 agent 的优化，会影响到所有人。」可以先在团队 repo 里共享 context、一起做 harness，但真正的目标是把它规模化推出去。 → 详细
06
规模化就撞进平台团队的领地：谁当 owner？没有 owner 就没有 paved road
- 共享系统天然是平台团队的活，但他们此刻可能没盯这块（忙着基础设施、云、MCP gateway）。而新东西正在冒出来，需要他们接手：skill 注册中心、针对 context 的 eval 系统、专门给 coding agent 用的 guardrail（护栏）、身份管理——他们「需要别人搭把手才能成长到那个角色」，而且这种中心化角色很难做。 → 详细
- 归属是尴尬的：平台团队不真正做开发，开发者体验（DevEx）团队又不负责基础设施——「所以是某种混合」。但无论如何必须有一个 owner 推动中心化的部分，否则你就没有 paved road（"铺好的路"，指组织预先铺好、省事又安全的默认路径）。他举例：「为什么我们每个人都在重新发明怎么做认证系统？这是个共享组件，放进注册中心。你们为什么各自都在造 harness？」 → 详细
- 同一套 linter（代码风格检查器）、同一套安全工具，都是可复用组件，会像云的 paved path 一样沉淀进平台的复用注册中心。但反面是蔓延（sprawl）：谁都能往 repo 里扔，「这个人有个 skill 在维护，那个人 fork 了个类似的——我该选哪个？」解法：这个领域有一个 owner，他负责可测试、模块化（别人能扩展 context / harness）、做过安全扫描——建起来的是「受保护、有人维护的东西，而不只是我在组织里随手分享的一个东西」。 → 详细
07
共识很难：最后不是一套标准，而是三四条 paved road 的目录 + 把成本可视化
- 让两个开发团队就工作方式达成共识「需要大量的沟通和斡旋」——「我不是说这跟 tab 还是空格之争一样，但有时候感觉确实差不多」。所以现实结局不是一套方案，而是一个有三四条 paved road 的目录让团队挑；想自己另搞一套可以，「但那得花自己的预算」。中心化的件有人维护，这才是最省事的采用路径。 → 详细
- 平台团队的另一项工作是让成本可见：他花了多少？带来了多少帮助？「如果我能减少 agent 要跑的迭代次数，这就是我能做的一项优化。但如果我不把它可视化，只看最终结果，那我们就不知道。」成本一旦可见，人就有动力去优化。 → 详细
- 整条论证线收束为三级跳：单人开发者 → 团队共享的 context 和组件 → 组织里的多人协作系统（multiplayer system），「倍增效应会在那里发生」，因为改进的飞轮会同时往多个方向转。 → 详细 → 详细
08
VP 层：hackathon / champions 计划那套通用转型剧本不管用，要把授权给到团队负责人和平台
- 工程 VP 问「我怎么让整个组织用起来」，他说这个故事他都能替你预测：hackathon、lunch and learn、分享成功案例、共享 Slack 频道、champions 计划——「这些全是通用的转型套路，换成 Agile 转型也是这么干，换成 DevOps 也一样，没区别」。而「把东西扔出去、做做培训、让一千朵花自己开」的策略根本行不通。他的主张：把授权（mandate）给到团队负责人和平台团队去做这件事，「这不是单个开发者的活」。 → 详细
- VP 还得为投入辩护：「买了 X 个 license」「交付更快了」「质量提升了」都很难证明。更好的办法是回到他的两个指标——展示减少了多少轮次、做了多少改进、复用了多少——比拿「有 agent vs 没 agent 的生产力对比」说事容易得多。 → 详细
- 面对「供应商收费疯了、要限制开支」，不该「把所有开支都卡死」，而是优化开支：选对模型、教大家选模型、给更好的 context 和 harness——这些同样会让成本降下来。 → 详细
09
招人：新头衔不说明任何东西，用「先考 AI → 再考工程品味 → 最后考协作」三段面试
- AI 产品工程师、forward deployed engineer（前线部署工程师，大会上另有整场演讲讲这个）、agentic engineer、AI engineer——「这些名字其实不说明任何东西」，因为「没人真的有多成熟」。招聘启事写上它只是一个信号，能吸引带着新意图的人来看，但不是对技能的验证。面试还有新状况：有人用 AI 在耳机里实时提词答题。 → 详细
- 他从大多数公司听到的三段式：第一步给一道题，让候选人放开手脚拼命用 AI 解——看他能把 AI 用到什么程度；第二步 walk-through：「请给我解释一下刚才发生了什么，为什么这是个好主意？」——考的是品味和工程功底；第三步考协作：你愿不愿意分享？你是开放的还是独行侠？ → 详细 → 详细
- 第三项恰好对应整场的主题——在组织内把东西做成可分享、可复用、工程级。要找的不是学过 ML 的人，也不是编码专家，是三项混合。找不到三项全能没关系，但「别把三项能力揉成一个笼统的『初级还是高级』的标签」，知道他哪块强、哪块需要带。 → 详细
10
「一个人包揽一切」是终极梦想，但算下来团队还是回到三个人以上
- 关于团队该小还是该大：有一个人能包揽一切当然很美，但现实账是这样算的——这种人通常要搭配一个互补角色（PM、设计）；有人休假得有人顶，又回到三个人；还得有人盯生产环境和进来的工单（效率高可以是同一批人，但只要还在修 bug，功能速度就会掉，取决于质量水平）；再加一个初级工程师上路，确保他还在学「好是什么样子」。结论：「在一个组织里我们仍然受这些限制，不可能做到每个团队只有一两个人。」 → 详细 → 详细
11
黑灯工厂其实是「昏灯工厂」：按功能定风险，从微观管理到自动审批是一条光谱
- 他修正了自己开场的词：dark factory「恐怕更准确地说是 dim factory（昏灯工厂）」。「你得看清楚，你愿意为哪些功能承担多大的风险」——不是所有功能都会全自主，但可以在审计上加大投入：谁改了代码、用验证器（verifier）检查这段代码是不是有用的、失败时要有态势感知（situational awareness，出了问题能立刻知道哪里、为什么）。 → 详细
- 从「事无巨细的微观管理」到「自动审批、默认一切正确」是一条完整光谱，你自己决定风险水平在哪。 经验仍然重要，所以他们也持续在教育上投入。 → 详细
12
从持续交付到持续学习：真正的指标是「改动越来越多的同时还能保持可靠」
- 你的工作模式本质是把知识沉淀下来：放进 skills、放进 context、放进 harness（你约束它的方式、你的业务上下文）。对他来说这把 continuous delivery 推进成了 continuous learning（持续学习）。 → 详细
- 「我们能多快把一个新东西换进来、换出去」就是你的响应模式。终极目标不是让整个系统更可靠，而是「我能不能在改动系统越来越多的同时，还保持它的可靠？」 → 详细
- 一句话收尾：「赢下这局的不会是独行侠，而是我们在各个层级上如何改进自己的组织。」 → 详细
13
闪电问答 / 收尾
本期为大会单人演讲，无闪电问答。收尾要点已并入上文「十二」：赢下这局的不会是独行侠。 → 详细
14
联系方式
- Patrick 正在做一个网站，整理他讲到的「agent 赋能模式（agent enablement patterns）」，并征集各组织的真实故事（愿意附链接）；幻灯片也可分享。演讲中未给出网址。 → 详细 → 详细