跨国深谈← 返回←DevOps 之父谈智能体开发：谁来管、怎么管、别踩什么坑

DevOps 之父谈智能体开发：谁来管、怎么管、别踩什么坑

关联

人物 Patrick Dubois · Tamuz Dubnov · Daniel Jones · Simon Maple

公司 Autonomy AI · Resync

概念 智能体 · 智能体编码 · PR · CI-CD · 可观测性 · 护栏 · token · 测试 · DORA报告 · PUMP · 平台团队

这一集是 AI Native DevCon 2026 上的一场圆桌，聊的是企业怎么把智能体开发真正铺开。三个嘉宾：Patrick Dubois，因发起 DevOps 运动被业界称为 DevOps 之父，现在关注智能体时代的组织模式演进；Tamuz Dubnov，Autonomy AI 联合创始人兼 CTO，他们做了一个让非技术人员也能在代码库上提 PR 的平台；Daniel Jones，Resync 产品负责人，做 AI 原生转型咨询和智能体编码培训。最反直觉的一点：当智能体写代码时，公司突然开始认真优化软件开发流程了——而同样这些流程，人类在写代码时从来没人在乎 。

谁来负责：不是建个新部门就完了

组织里谁来管智能体开发的落地？Daniel 看到的趋势是，它会落在开发者体验团队或平台团队的职责范围内——这些团队本来就在通过提供更高层抽象来降低开发者认知负荷，管理智能体的上下文自然契合 。

但 Patrick 指出一个现实问题：现在平台团队的人往往还只盯着基础设施，本身不是 AI 编码的老手，可他们手里握着模型、网关和预算，形成了一个能力真空 。他的判断是，大公司里大概率会出现云平台团队、AI 平台团队、数据平台团队并存的局面，而不是一个平台小组包揽一切 。

真正的瓶颈：基础不行的会被智能体拖慢

Daniel 说得很直白：暴露出来的瓶颈，本质上都是软件开发基本功不行——CI/CD 好不好、有没有测试、有没有人真正遵守的编码标准 。DORA 报告的结论是：开发成熟度低的团队，引入智能体编码反而会变慢；成熟度高的才会加速。问题是没人知道那个转折点在哪 。

另一个瓶颈是产品侧。开发速度上去了，产品经理措手不及——待办事项里没有足够的储备，而补这些东西需要深度思考和客户对话，没法简单加速 。

Patrick 提了一个新代理指标：别看代码行数了，看智能体完成一个任务需要多少轮（turns）。你可以通过换模型、给工具、优化上下文来压低这个数字 。

让非技术人员也提 PR：不是给个工具就完事

Tamuz 的核心做法是：把不需要工程师的活卸载给产品经理和设计师，让他们直接在代码库里做可视化的迭代，生成可以合并的 PR 。但这背后有两个真问题要解。

技术端的自负：他们平台的智能体因为能跟踪 2700 个组件并做智能排序，生成的 PR 质量经常比开发者自己写的好，但开发者看到非技术人员提的 PR 第一反应是抵触 。Tamuz 的做法是对技术端温和一些，同时让团队负责人先看代码质量——当代码本身没问题，“不是开发者写的”就不该成为拒绝理由 。

非技术端的恐惧：PM 们有冒充者综合征，怕被技术审查问住。Tamuz 的解法是改变交付物的定义——你不需要写 Jira 工单，不需要做断开的 HTML 原型，你直接在代码库里做原型，智能体已经知道代码库的约束，你只需要给产品意图 。

PUMP 流程：因为代码太快，PR 工作流必须重构

代码移动速度太快，传统的”开 PR → 等人工审查 → QA → 产品审查 → 合并”根本跟不上——等审查完，代码已经冲突了 。Daniel 甚至说企业里的 PR 工作流是个极其愚蠢的主意，应该回到基于主干的开发 。

Tamuz 提了他们内部的 PUMP 框架——计划、合并、打磨。核心思路：PR 一开就尽快合并，不需要通过 QA 和产品审查，所有新功能通过功能开关控制。

合并之后，产品经理和设计师再在代码库里直接打磨 UI/UX，修正开发者从用户视角做出的糟糕决策 。一个功能通常要三到四个 PR：开发者一个、产品经理改功能一个、设计师调 UI 一个、QA 补边界情况可能再来一个 。

用智能体审查智能体：按风险分级

Tamuz 的团队已经在朝跳过人工审查的方向走，但按风险分级。高风险的（涉及敏感代码区域）必须有人看；低风险的，他们让智能体模拟团队里每个开发者的评论风格来做 PR 审查，然后另一个智能体去解决这些评论，再做日志回溯看有没有异常 。这个流程做得出奇地好，但他承认团队里有开发者坚决反对，觉得开发者必须对代码有所有权 。

Patrick 把这和 DevOps 当年的脉络对比：当年也是靠测试流水线作为安全网，才让初级开发者敢推主分支。区别在于，数据 schema 变更大家还是不敢自动化——风险感知决定边界 。

CI 必须改造：让智能体能查日志

Tamuz 强调，CI 流程要做几个关键改造。第一，可观测性平台必须对智能体可查询——不只是写代码时能查，发布后回溯时也能查 。

他们内部的具体做法：每个 PR 自动被智能体打风险标签；发布前另一个智能体按风险排序，逐个检查日志——这个变更的意图是什么、日志是否显示它达到了预期、有没有遗漏的边界情况 。高风险的 PR 经常能捞出漏掉的东西，哪怕团队已经有 QA 和测试 。

Daniel 补了一个思路：别指望一个智能体一次搞定所有事。他做了个叫 Assembly Line 的小工具，主智能体做完变更后，启动多个专用智能体分别检查死代码、测试覆盖率、安全性等——每个智能体只有一个确定性定义的提示词，像流水线上的工位 。Tamuz 说他们叫同样的思路”引导”（nudging）——不让 LLM 一步做三件事，而是让它一步走一个方向，质量更好 。

别踩的坑：三个 concrete 的反面模式

给不感兴趣的开发者派 AI 任务，token 会爆炸。 Tamuz 发现，开发者对任务不感兴趣时，会把所有验证工作都甩给智能体——“你帮我测”。结果是智能体跑七轮 QA，token 消耗飙升，PR 质量还差 。

给非技术人员直接发编码工具。 给 PM 发名字里带”Code”的工具，他们不会配环境，要么什么都不做，要么提交垃圾 PR。

Tamuz 亲耳听到一个 CTO 当着 VP 产品的面说”你昨天提的那个 PR 就是垃圾” 。工具要为用户角色优化，不是一个工具打天下。

CTO 说”随便用自己喜欢的工具”。 Daniel 说 2025 年很多 CTO 采取放任态度，这会导致组织内做法不一致，无法沉淀经验。

研究表明，明确要求使用统一工具是智能体编码采用成功的关键指标 。但反过来，把 token 预算限得太低（比如每月 100 欧元）也不好——开发者会纠结”这件事值不值得花 token”，增加了认知负荷 。

测试的新含义：上下文提示

Tamuz 提了一个很实操的观点：测试不只是验证，还要给未来的智能体提供上下文提示。测试失败时的断言信息、注释、错误响应，都得写得足够丰富，让拿到这个错误的智能体知道该怎么修 。懒开发者只写”assert true failed”，人对着这种信息都不知道怎么办，智能体更不知道 。

Patrick 总结了一个更底层的模式：对 AI 好的实践，对人也好——好的文档、好的测试、好的可观测性，这些不是新东西，但智能体让它们的回报率暴增 。他给开发者的核心建议是”不要重复自己”——别反复告诉智能体该做什么，写下来、给它工具、让它自己查 。

【背景】Patrick Dubois 是比利时人，因 2009 年发起 DevOps Days 活动被广泛称为”DevOps 之父”。转写稿中主持人将其误称为”Patrick Devoir”，正文已纠正。TESL 是本集播客的赞助商/主办方，非知名公司。Resync 是一家 AI 原生转型咨询公司，其联合创始人撰写了 O’Reilly 出版的《云原生转型》一书。Autonomy AI 的产品让非技术人员通过平台在真实代码库上生成 PR。DORA 报告是 Google 发布的软件交付效能年度研究报告。BMAD 和 SpecKit 是 AI 辅助需求/规格工具。vibe coding 指用自然语言让 AI 生成代码、不手写的开发方式。MCP 是让 AI 智能体连接外部工具的协议标准。

本集带走

• 先补基本功，再上智能体：CI/CD、测试、编码标准——这些不行，智能体编码会让你更慢，不是更快。
• 按风险分级管理 PR：高风险必须人看，低风险可以让智能体模拟团队审查风格自动审，但不要一刀切。
• PUMP 流程应对速度：PR 开了就尽快合并（功能开关保护），合并后让产品和设计师在代码库里直接打磨，一个功能分多个 PR。
• CI 改造重点：让智能体能查日志：可观测性平台要对智能体可查询，发布前用智能体按风险排序回溯每个 PR 的日志。
• 多智能体流水线优于一个全能智能体：每个检查维度（死代码、覆盖率、安全）启动一个专用智能体，提示词确定性定义，不让 LLM 一步做太多事。
• 别给非技术人员发编码工具：工具要为角色优化，PM 需要的是能表达产品意图的平台，不是 IDE。
• 测试要写给智能体看：失败信息要包含足够上下文，让拿到错误的智能体知道怎么修，不只是写给人看。
• 别让不感兴趣的开发者用 AI：他们会把所有验证甩给智能体，token 消耗飙升且 PR 质量差——把任务分给感兴趣的人。

我喜欢行业中每一个新的混乱时期，因为那是学习正在发生的地方。
And I love every new chaotic period in the industry because that’s where the learning is happening.
—— Patrick Dubois · [00:30]

而我们看到的是，组织在尝试采用一种颠覆性技术时正在重复同样的错误，就是直接把技术扔进去，不改变任何关于他们工作方式的事情，然后对他们没有变得更快感到惊讶。
And what we see is that organizations are repeating the same kind of mistakes when trying to adopt a disruptive technology of just plopping the technology in, not changing anything about how they work and being surprised that they’re not going faster.
—— Daniel Jones · [03:55]

只是你不是把它应用在代码上，你是把它应用在制造代码的机器上。
It’s just you’re not applying it to the code, you’re applying it to the machine that makes the code.
—— Daniel Jones · [27:31]

就像企业内部基于拉取请求的工作流是一个极其愚蠢的想法。
Like pull request-based workflows inside enterprises are a damn silly idea.
—— Daniel Jones · [37:04]

一旦 PR 被打开，我们启动不同的智能体，这些智能体模拟我们团队中的不同人，并表现得像那些人一样评论，并且做得出奇地好。
Once a PR is open, we launch different agents that model different people from our team and comment as if they were those people, and does a surprisingly good job.
—— Tamuz Dubnov · [40:22]