作者 / 来源中智凯灵 / AiDD在 AI Coding 快速普及、个人效率显著提升却难以转化为组织效能的背景下快手内部 AI Coding 工具的渗透率已从去年的七八成攀升至高位部分团队近 4 周代码生成率超过 90%有好几周甚至是 100%。然而从续写补全到 Coding Agent产品形态在演进ABAB 串行执行、上下文不对等、协作摩擦等结构性问题却始终存在。本文整理自快手 AI Coding 专家周鸿轩在 AiDD 大会的分享《AI Coding 产品演进从续写补全到人机对等协作》。▼【演讲摘要】渗透率与代码生成率都很高团队最近 4 周生成率超过 90%有好几周是 100%感觉整个 IDE 和 Agent 产品都是 Agent 去写的。但从管理视角看大部分团队还没有得到匹配个人提效的提升——以前两周交付 20 个需求现在能交付 40、50 个吗可能并不能达到。从 24 年的代码补全到 25 年的 Coding Agent再到最近的 Agent Harness 和 Agent Teams产品形态在演进。但 ABAB 串行执行模式让人很难受——对着输入框打两三分钟字Agent 执行 10 分钟期间只能刷手机、喝咖啡回来发现不对再聊两三分钟碎片化时间被填满但真正高效的事做不了。解法是 Spec 驱动的长程 Agent Loop。把状态外置——specs、工作进度、执行历史都放到对话之外配合 Harness 环境约束、机器资源、权限和项目约束让 Agent 能长期自主执行。模型能力上来之后很多过去复杂的工程方案Fast Apply、向量化索引都被内化简化了。本地与云端的二元划分正在被打破统一抽象成执行节点——容器、云端、本地都可以装上 Agent runtime 和 daemon 进程就能转换。这样任何节点失败或迁移都可以平滑过渡也为 Agent Swarm 蜂群等大规模并行提供可能。再往前是人机对等协作。Agent 藏在人后面、上下文不对等是协作摩擦的根源。通过 CLI 化让 Agent 和人看到一样的任务列表共享上下文把 Agent 拉到和人一样的工作平面——这是目前比较好的前提未来还有更多事情可以做。从最早大家觉得 AI 只能做辅助开发到现在的自主研发再到刚才上一讲特别核心的一个内容——关于组织提效。每个人都感觉自己的生产力提升了每个人都感觉自己变得很强了。但从管理视角来看大部分团队还没有得到匹配个人提效的提升。这点也会从我的视角来分享一下。【演讲实录】先做一下简单的自我介绍。加入快手后我主要一直负责的都是基建和效能相关的事情——大前端方向的基建、云开发、云研发像 Cloud IDE、CloudDev 之类的。24 年公司内部立项做了 AI Coding当时最重要的产品就是代码补全tab 的功能。到后面从 25 年开始做 Agent 功能到现在也继续在做类似的事情。所以大概是从 24 年开始主要在做 AI Coding 这个方向。大家用过的所有 AI Coding 产品我们在内部都做过——插件、IDE、CLI 等等。今天的分享主要从产品和技术角度聚焦 25 年、26 年的演进情况。在分享之前先跟大家介绍两块内容。快手内部 AI Coding 工具的使用情况——渗透率大概多少工程师在用。渗透率还是挺高的从去年大概七八十的状态到今年随着大家对 Agent 模式接受越来越广泛使用率已经很高了。这些使用 AI Coding 的工程师AI 代码生成率也很高。接下来稍微有点夸张我们团队最近 4 周生成率超过 90%有好几周是 100%感觉整个 IDE 和 Agent 产品都是 Agent 去写的。然后是这条时间线。最早 24 年前后大家认为它还是纯粹的代码补全工具关心 AI 能不能帮我补得更准、写得更快看 tab 的采纳率到底有多高。到去年一整年Agent 的落地非常迅速大家关注 Agent 能不能帮我们更加自主地完成任务。当时有个产品叫 Devin号称第一个 AI 程序员能自主交付。到今年很多需求 Agent 已经能自己做了。实践的团队里甚至会有工程师觉得他是不是要被 AI 替代了。我们团队也有很资深的工程师之前会撸很多代码现在基本完全靠 AI 来生成交付。在个人效率提升之后承接上一讲上一讲特别关注在组织上是不是真的提效了。每个人都说我 AI 用得很好2~3 倍提升。但大家可以看看自己团队的交付效率——以前两周交付 20 个需求现在两周能交付 40、50 个吗可能并不能达到。▍AI Coding 的三阶段演进从续写到 Agent最早我们就是做补全。大家应该都知道我在写代码它弹出一个幽灵字符tab 一下就采纳了。这边有两个数字5% 和 20%——这是我们最开始做的时候的生成率。从投入到去年年中大概一年多的时间不断迭代花了很多精力不光是工程上还有算法团队专门做自己的模型在快手内部收集各种语料做微调。实际上它能做到的上限也比较有限即使只看单独写代码的场景做到最好也没有超过 20%。但在 24 年下半年的时候上线了一个很简单的功能——把 ChatGPT 这类东西集成到侧边栏我就可以问它代码问完之后通过简单复制和修改把代码放回编辑器。这个功能上了之后贡献度非常高没有怎么迭代也非常原始。大家可以对比一下补全我们投入了 90% 的人力问答我们投入了 10% 的人力把它集成进来在没有多投入的情况下就能达到类似的贡献度。这一定程度上说明通过表达一个需求让模型去生成大段代码本身产品和技术的上限会比较高。只是说当时那就是一个纯粹的问答但现在 Agent 这种模式也是类似的——我表达一个需求它帮我生成大段产物。所以也比较自然现在 Agent 的交互实际上和问答有点类似。但从产品上看Agent 的交互和问答很类似。大家可以回想现在桌面客户端或网页端的 Agent所有 Agent 界面基本都在模拟 23 年、24 年那种 AI 对话产品本质上还是一种对话模式。但在这个从对话模式到 Coding Agent 的演进上有不少技术问题其中有三个比较重要。第一个是关于怎么理解项目。大家如果在 24 年用过对话产品会有这种体感我要问一个问题的时候比如想做一个登录模块直接问的话当时这种问答产品肯定没有办法理解这个项目。所以最初的方案就是去关联一些目录、关联一些文件让它能看到这些内容不然回答出来是和项目无关的。但这种方式太手动了。中间状态大概在 24 年底、25 年初的时候大家去做代码仓库索引——对代码进行分片、向量化召回的时候再做重排序有点像文档的向量化 RAG 方式。在问答里嵌入一下当时觉得还挺好用确实能理解项目了比纯问答要好得多。但大家现在去看国外的产品——Claude Code、Codex国内的产品不管什么 Qoder、Trae甚至 Cursor会发现现在很少有人用向量化索引做代码仓库索引了尤其是在 Coding Agent 场景。原因有几个。第一是效果上在模型能力到一定程度的情况下用一个比较黑盒的向量化索引在一个比较小型的数据集上——我认为代码仓库还是小型数据集比互联网内容少很多——效果没有明显提升甚至可能还会差一点。第二是维护成本不低要投入人力和硬件资源。直接用 grep三四百行代码就解决了在本地就可以解决。从成本角度来说不太划算。到目前为止最主流的是通过 grep、read、listfile、glob 这类比较原生的工具。第二个技术问题是行动。你需要让 Agent 行动。如果用过对话产品在 24 年遇到最大的问题是当它生成一段代码不管在侧边栏、网页还是 APP 上我需要把它放回去。生成的代码越多越难放回去。还有语法不匹配需要手动改很多东西。中间有个解决方案最早被大规模应用是在 Cursor 上叫 Fast Apply。背后有专门训练过的模型去做一段看起来相似代码的语法匹配和语义应用放回原来的文件。但这个方案目前基本上被淘汰了。现在回归到一个非常朴实的方案——生成一段 diff 字符串去匹配search 一个字符串做替换。有替换前的、替换后的。这个方案准确度现在比较高不需要背后的服务资源也是几百行、1000 行之内就可以解决的事情。从这里也可以看到一个小点在模型能力不够强的时候需要非常复杂的工程方案去解决问题。但既然用了大模型又没有额外增加特别高的成本很多东西都被它简化了。很多方案在特定时间完成了历史任务。像 Fast Apply在 25 年初即使是 Claude 的 search replace 准确率都没有那么高可能也就 90%用其他模型可能低到 60%~70%非常浪费时间——每次生成不对可能要生成两次才能够对越大的文件出的问题越大。但现在已经好了非常多因为模型把很多能力内化了。再往后Action 不只是改文件还包括跑命令、操作浏览器。Agent 才从回答问题进入到执行任务。最后一个大家肯定会很熟悉就是ReAct 模式。这个模式当然不是去年才出来的。最早那篇论文在早几年就有了它也不是最先运用在 Coding Agent 上。在这之前像 24 年做 AI Coding 的时候还有一类产品特别流行叫 AI Web Search。当时有个国外产品叫 Perplexity在 24 年还挺火的。它通过给 AI 挂一些搜索工具——主要是 search 和 crawler 这种爬网页的工具能够通过行动观察的反馈循环不断根据问题搜到更好的内容总结出更好的答案。当时我们试过给它挂很多工具大概 24 年年中比较好的模型是 GPT-4o后来才是 Claude 3.5 出来。如果用 4o 去驱动完整的 ReAct 循环工具挂多了会有各类问题当时没有现在的 tool use 能力这么强。所以刚才第一部分主要跟大家快速回顾了从 24 年代码补全到去年一直在做 Coding Agent 的这段历程。下面可以带大家进入一下我们的演进路线。▍从 ABAB 到长程 Agent LoopHarness 与状态外置我们先回到一个很典型的场景。不管你现在刚接触 Coding Agent还是已经走得很远一定会经历一个阶段对着输入框打了两三分钟的字让它去执行它执行了 10 分钟。这 10 分钟里不知道大家是怎么度过的——去趟洗手间喝杯咖啡在家刷手机、玩消消乐、刷小红书知乎工作时看看消息。不管做什么10 分钟之后回来看代码到底怎么样发现有点不对再花两三分钟跟它聊再 10 分钟之后走开再回来。我也喝不了那么多咖啡。一个下午四个小时也许只花了两个小时在输入和查看但剩下两个小时并不能高效利用只能找碎片化的事情去干。我发现做了一段时间之后有点沉溺于那种好像能用碎片化时间填充起来的感觉好像效率提升了。但有些碎片化的事情本身不应该做或者通过组织流程可以优化掉却不断因为这个状态陷入和真正高效相悖的情况。这个 ABAB 的交错执行模式很让人难受。工程师都喜欢说能进入心流状态——给我 4 小时我一定把东西交付给你别来打扰我。或者修 bug 的时候说我批量去修你别一个 bug 来找我。但这种碎片化很难利用。所以大家自然会有第一个诉求能不能不要这么碎片化先把一个事情交给他至少别 10 分钟就来弄我一个小时也能给我喘口气的时间。每个人都有这样的诉求。第一层是说我把事情跟他说完了甚至用了 specs、SDD 的方式但他做不完三项事情只做两项做完就说自己做完了还得让我回来去弄。还有他做一些大面上的工作没问题但有一些看起来简单的事情他写出来的代码没法通过编译写一个弹框点击之后因为语法问题报错弹不出来。但这些问题你大概率不会手动去修——你跟他说一声把编译错误栈贴给他、截图贴给他他就修好了。说明他是能修好的。在更多层面上他写代码的时候是否对其他模块做破坏等等不同层面有各种问题。目前比较推荐通过 SDD 的方式去做。虽然是 Spec 驱动但实际上不光是左边需要有比较好的 specs右边也需要能够在各个层级有自驱验证。下面有一些环境约束。可以把环境约束理解成对系统的一种约束现在我们叫 Harness。如果我们要去掌控 Agent我理解不是人去掌控——人掌控又变回了每 10 分钟操作一下。比较推荐的方式还是用软件工程的方法给 Agent 构建合理的工程约束在环境上也进行约束。环境约束包括机器资源——不知道大家有没有关注前几个月 Anthropic 发了一篇文章说资源和内存、CPU 对 Agent 执行有没有影响他们发现在不同配置的机器上用同一个 Agent 执行任务成功率是不太一样的。还有权限、项目约束——以前架构师要把项目建好让大家不会写出偏差保证底线。现在 Agent 进来也得有一套约束让它避免写出偏差。还有一个很特殊的就是 Agent 的约束。现在有很多开放能力像 Skills、AGENTS.md、Hooks。这些属于给 Agent 的约束——可以在其生命周期的某一个环节注入上下文作为控制帮助 Agent 在执行时符合我们的意图。不知道大家有没有疑问好的 Specs 怎么生成这个是个比较复杂的问题而且不同的人都在用不同的方式做。我感觉有可能这不一定是最关键的问题。就像我们不会在 5 年前或 3 年前持续争论到底该用哪个 lint 工具——虽然有 lint 工具之争但可能不是关键问题。关键在于Spec 需要做到什么程度第一不能花太多时间。如果仍然花很多时间去精雕细琢 spec差不多就等同于花同样多时间去精雕细琢代码了。如果是一天的需求花了一天来做 spec虽然有一定帮助但对效率的杠杆会低很多。现在业界为什么主流喜欢用 brainstorm或者有些工具会问你澄清问题澄清问题让我印象最深的是去年 ChatGPT 推出 Deep Research 工具。因为是长周期做的事情所以在前面通过澄清能够快速定位关键决策点。通过 AI 和人的交互把关键决策点快速定位下来。AI 知道很多东西最好的方式是能直接问出我想的那几个方案问出一些我没想到的东西甚至问出一些我不知道我不知道的东西——对于我不知道的东西我可能都不会去问它。第二个是做完 spec 之后有一个很重要的功能人和 AI 能对齐。如果能保证人和 AI 对齐只需要保证后面的执行和 spec 对齐就行了。第三个是spec 很重要的一点是后面有自驱验证从这里也需要能够推导或保证出验证的方式。第二个问题是当我们已经能让它比较完整地解决复杂任务了自然而然就会让它去解决更复杂任务。大家不知道现在执行过最长的 Agent 自主运行——不管通过什么方式人工不要介入让它自己跑最后出结果——是多长时间像 OpenAI、Anthropic 在博客里发过文章有说 12 小时、24 小时的。如果你试过 6 小时以上的会发现常见的方案不太适合。平时说上下文特别长怎么办截断、压缩、精简不同的 section 做不同的精简。这些策略在一个有限上下文情况下如果要去运行 12 小时不做特殊处理很容易出问题。SDD/Specs 为什么大家用起来觉得还不错因为它天然做了一件事——把状态放到外面了。如果你试过不把 specs 放在外面就放在对话里别让它生成文件让它在对话里留着去执行6 小时之后肯定就已经花掉了。所以本质上它在做一件事把所谓的状态外置了。但现在还有一些工具没有把更多状态外置。像工作执行的进度——现在慢慢有更多产品去做类似事情Claude Code 和 Codex 都上了新的模式有一个 goal 模式做长任务。年初 Cursor 也上了实验性的 grind 功能目标是长任务过程中保持记忆和持续工作中断之后能够恢复。比较重要的是它们都会把状态外置——工作进度、任务列表。不光是一个 Agent 的执行如果要让多个 Agent 协作关注 Agent Teams 或 multi agent 项目会经常看到把任务清单、任务进度、执行状态首先外置不会放到会话里便于 handoff。还有执行历史。像是 AutoResearch 项目有一个很推荐的实践每一次执行完、每一次迭代完之后都做一个 Git commit。这就是一种通过 git history 把执行历史外化。AutoResearch 也是长期自己迭代的可能运行 12 小时甚至以上通过这种方式把执行历史外置不关联在对话里。这里还有一个很有意思的事情。在 25 年的时候有一版应该是 Claude 3.7 还是 4.0特别喜欢写文档在它之前是不喜欢写文档的。那个时间点正好和业界流行 SDD 时间差不多。大家都说使用数据最后会反哺到模型训练里。但当时在我们公司SDD 还不太流行所以所有人都在吐槽都在想办法让它别写文档我就让它生成代码。但大概过了三个月情况变了大家都喜欢写文档了没有人说我就喜欢直接出代码。所以我一直觉得用户、产品工程和模型之间有一个微妙的相互搀扶着前进的关系。现在看到的一些矛盾很可能在未来不一定是一个矛盾只是一个暂时态。大家如果做过类似把状态信息外置尤其是做过 spec、SDD很可能会遇到一个典型问题——叫做重建同步对齐。所有产品目前不管代码是谁写的要上线还得把代码产出出来代码肯定是唯一的信息源。但在 spec 的时候估计不会有人能做到百分百——做了一版 spec 开始实现所有实现都和 spec 一比一对等不会有任何变更。在我的工作中从来没有人做到过连 demo 项目都没有出来之后还要微调几版。微调的时候你是去改 specs 还是去改代码你直接跟他说去改代码还是改 specs如果直接去改了代码日积月累会出现一个非常重要的问题——你的 specs 和代码对上又对不上。对上又对不上到底是一个正资产还是一个负资产尤其是经过几次架构重构的时候大家也不去整理旧文档。旧架构还在那一进来的人比以前更懵了——以前我看不懂看看代码现在文档看完之后方案出了一半告诉我这东西是错的。现在有一些产品会做一些像 Dreaming 的功能在空闲或晚上的时间去运行一些任务。把工程架构对齐、把资产对齐的事情也是其中一个。OpenAI 在 2 月份最新发的关于长期执行的工程任务那篇有一块提到他们会持续去改进和同步整个 Agent 迭代的工程环境让它保持一致性避免各类问题。这个问题不光是在长时间执行里你迭代一个项目 6 个月也有类似问题。还有一个事情大家都做到了之后就会遇到一个问题我长期执行了本地电脑一关是不是会出现一些问题这个时候我们会选择一种云端运行的智能体。大家觉得这种智能体到底该是云端运行的好一些还是本地运行的好一些像云端运行的智能体在去年大概六七月份的时候最开始有个叫 Augment Code 提出了 Remote Agent后来 Cursor 也做了 Cloud Agent还有其他公司做。他们就是把 Agent 的 loop 放到云端容器里去执行。到底是云端好一点还是本地好一点目前看起来我的感觉是可以跳出一下这个视角。我举个例子今年年初的时候我买了一个 Mac mini。我在家里连上键盘的时候这 Mac mini 不就是我的本地电脑吗它就是个本地电脑。但现在比如我在上海要去远程操作它它应该是个云端还是个本地它应该是个云端。所以它到底是云端还是本地实际上和工作状态很有关系机器物理上没有发生任何变化。如果需要因为工作场景去大规模改架构或服务链路本身设计会比较复杂。所以现在有一种比较常见的设计不区分了换个视角就说它就是一个执行节点。这些执行节点可以是容器、可以是云端、可以是本地。在上面安装各种 Agent runtime——Claude Code、Codex 等等。可能运行一个 daemon 进程和服务端的控制面通信。只要启动这个东西就可以把任何节点转换成一个执行节点。为什么没有叫云端本地呢因为之前从客户端角度出发本机装了客户端来直接操作本机的 Agent所以把它叫做本地。这时候从界面上看不再操作本地了叫它云端。但客户端不和执行节点直接发生关系它和控制面发生关系——我可以通过任何 UI 或 GUI 接入到系统里。不太在意所谓的执行节点是本地还是云端只是选择一个执行节点。这个执行节点也可以扩展例如需要做大规模 Agent Swarm 蜂群之类的东西可能会临时启动上百个容器去执行不需要真的持续管理这些临时节点。像这种方式就不太执着于本地还是云端了。在有些产品里也可以大概理解成 managed agents所谓的手脑分离——把状态和数据都放到云端管理在机器上面做执行任务这样在任何机器上失败了或需要做任务迁移都可以迁移过去。▍人机对等协作共享上下文与协作网络到这里我们似乎把 ABAB、Agent Human 交替这个问题解决得差不多了。现在感觉上有了一套能够多线并行、多线叙事的状态——我可以一下发好几个任务让它长期执行。这里可以借用一下上一讲说的人人摩擦、人机摩擦。大家也可以从这个角度看——所谓人人摩擦现在大家会把 Agent 当做自己的工具所有沟通协调还是人去做的。人需要处理所有上下文只要业务想跑得更快人在里面本身就有带宽限制就有瓶颈。这件事可能有两块内容。第一块从上下文角度去看一个很重要的原因是目前这些 Agent 藏在人后面和人上下文不对等。有些事情它做不了是因为不知道——你告诉它的。但有些事情如果它和人有相同的信息输入就能做到一些事情了。第二块什么叫人机对等协作网络现在我们会把 Agent 认为是自己下属的执行者——原来我是一个执行者现在 Agent 是一些执行者我在上面好像是它的调度者。从组织层面说扁平化了但从另一个角度可以认为组织变深了多了一级。原来执行者到我结束了现在我下面还有一层执行者。这些执行者是不是和我在同一个工作平面上协作我对他们是有信息垄断的。大家可能不太好理解可以看一下有没有这种需求我们团队里有这种需求说想要别人把他的会话分享给我。为什么因为我发现他似乎有我不具备的技巧、技能他能让 Agent 做一个性能优化做得很好。我去问他说了半天也没听懂我就想看看他怎么做的。我想看他怎么做并不是想学他怎么做我实际上是希望我的 Agent 去学他怎么做因为我最后还得交给 Agent。在这样的情况下不如让他的 Agent 直接去和我的 Agent 交流一下把信息直接共享一下不需要我找他、他找他的 Agent、他给我、我再找我的 Agent——我们俩中间在做无谓交流。所以在刚才的产品上这里加入了一个比较特殊的点——有个 Agent 入口。现在很多产品都做 CLI 化CLI 是对 Agent 比较友好的。客户端这边 GUI 是人类的入口例如我可以在任务清单上通过 GUI 看到清单列表。但只要这个系统也提供一套 CLIAgent 同样也可以和我看到一样的任务列表。这样我对他就没有信息垄断了。我能在系统上发起一个任务他也能发起一个任务。我能拆三个任务给他他也能拆三个任务 我。为什么 我可能是一些权限原因或者我具备他不具备的组织信息或者我需要决策。我在整个工作协作中和他是一个比较对等的状态。在另一层面公司里面还有很多不太开放的生态——文档站、数据仓库、运维系统。这些之前一方面权限管控比较严本身不是很通畅另一方面这些系统从来都是为人设计的。大家在公司协作里一定会有文档系统不知道在座的各位有哪家的文档系统和 Agent 平台能打通得非常丝滑顺畅的我觉得如果能做到这个就已经完成了一个很大的跨越了至少在快手内部还有比较多的问题虽然有一定打通但达不到真正非常好的协作状态。刚才第二部分主要是从产品技术上说了一下从去年 Coding Agent 到目前大家都会遇到的问题。这边我快速带过一下。刚才说到把视角——上一讲那张图比我这张更好——从工程师研发团队的视角到整个研发体系里其实还有很多不同的环节。因为我们做 Coding Agent似乎只是解决了代码的问题。我从一个稍微微观一点的角度来说。光看我们团队大家可以看到代码生成率很高代码写得很快但需求产出不够快了。我们现在大概 50% 的需求是工程师自己来做的产品只负责一些审核甚至有时都没精力审核。我理解这既是精力问题也是一定的组织原因——就像作为工程师不知道大家喜不喜欢看别人的代码、CR 别人代码。那产品可能也不喜欢 CR 别人的 PRD。所以从需求这边有一些问题从测试这边——如果还是靠堆人力去黑盒测试的话我跟测试交流——我们团队也有测试——他们觉得有两个方面。第一方面是提测质量变低了Agent 快速产出大量代码提测质量很低接着狂修修完一个 bug 又引入一个 bug。第二是他们这边测试排不开了很多需求叫做免测、免测上线了工程师自测觉得没有太多问题就免测上线了。这两个都是在牺牲产品质量和系统稳定性的前提下去做的。好在暂时没有发生大问题有各种小 bug目前我们的用户在一定程度上还是接纳了我们。所以这个和上一讲其实讲的是类似的我们把中间环节去放大了其他环节还有很多问题。说明他肯定不能光是 Coding 提效。刚才说到 Agent Teams但我一直没有提业界那些 Agent Teams 方案为什么呢这些 Agent Teams 和 Multi Agent 方案都是很好的实践也是非常好的技术方案。但它们不完全解决我们刚才说的那个问题。我们可能没办法指望搞一个 Agent Teams——里面有能写 PRD 的、能写测试的——这东西一弄出来问题就完全解决了。它不完全是一个纯粹通过技术就能解决的问题用更多 Agent 去做也未必能直接解决。它不纯粹是个技术问题。所以它是一个很好的东西但不完全解决这个问题。这里有一个很重要的问题。我从去年做这类 AI 和 Agent 的产品觉得上下文本身就很关键算是很多事情的起点。现在有一个非常重要的问题是刚才工作中的上下文对不太齐。原因在于其他环节的 AI 化还比较少。但这个 AI 化比较少是不是说我们需要一个 PM 的 Agent、需要一个 QA 的 Agent有可能需要但也可能不一定。它可能很重要的一个点是假如我们需要产出一套需求这里面有什么工作和组织信息是我们需要整理出来的。这些信息如果按照刚才说的对等协作原则人和 Agent 应该是共享的。举一些例子。做 OnCall 的时候大家会不会觉得说我首先先要建一个 OnCall 的 AgentOnCall 完之后去定位问题还要 bugfix我需不需要建一个 bugfix 的 Agent我在团队里去尝试实践的时候比较推荐团队同学考虑说OnCall 的时候有哪些信息这些信息应该在整个流程里能够共享的。OnCall 的时候肯定有各种群消息——如果连群消息都拿不到的话可能都没有办法监控舆情。还有日志、trace、代码仓库、产品文档。有了这些之后理论上可以回答产品问题、回答用户咨询还可以定位问题的模块、修复问题。这时候到底是用一个 Agent 加上很多 Skill 去做各种事情还是需要用多个 Agent 去做多个事情还是需要 Agent 和人去协同做各种事情可能是不同的组织有不同的情况。例如我的组织里就一个研发那研发能补位的地方是这里其他是别的角色。需不需要多个 Agent可能是根据上下文情况去看的。如果一个 Agent 上下文无限它能做所有事情的话理论上 Agent 比较通才很可能用一个就把所有事情做了。但如果它的上下文需要很好管理通过多个 Agent 本身就是一种上下文管理的模式不光是一种协作模式也是一种上下文管理的模式。通过这种方式去做一些设计不同团队可能也不太一样。还有类似的例子比如修复问题。修复问题的时候也会发现首先要看一些重要的上下文——问题修复、修复报告等等其他的东西。还有一个例子如果我们想要去自动化——需求产出不够快了可能会希望它能自动做一些竞品调研。因为我们做的产品有一个很好的点——我们现在做的产品和 Codex、Claude Code、Trae 类似除了这些商业产品还有很多开源的竞品理论上可以从开源产品方案里调研出很多技术点。举个实践我们之前有一次大概 3 天开发了 10 个需求这 10 个需求要正常开发至少得将近大半个月。开发方式就是从竞品中调研一些功能尤其是产品力上面。产品力是通过很多细节体验去迭代叠加起来的可能不是光靠某一个功能。如果要让你的产品真的让用户觉得好用需要迭代很多细节功能。很多这种细节功能的调研实现如果需要投入人力其实还挺耗精力。是回到刚才的如果我们面向工作的上下文去尝试重新思考协作模式的话不一定说流程是最重要的——流程当然重要但不一定是最重要的。也不一定说到底有几个人组成是最重要的。因为 AI 现在能做到的一个很重要的事情是它能补充我能力之外的部分。像现在如果不会编码的设计师也可以通过设计技能和 AI 一起去交付产品。所以如果我们把这些上下文共享之后在不同团队里面因为每个团队人的能力分布和团队构成都不太一样在不同的事情上会有一些不同的实践。就像我的团队里如果有专职的 OnCall我肯定会把他利用起来在流程里面发挥作用。但如果你的团队里没有专职的 OnCall那设计出来的方案就不太一样因为我也确实有这么一个人能做一些事情。▍总结把 Agent 拉到人的工作平面最后的话我们回到这条时间线稍微再总结一下。当然这条时间线最开始已经讲过了。我这边还想表达一点大家可以看最下面——从辅助提效、个人提效到现在来讲大家可能都已经反应过来那种状态叫做 AI 好像帮个人做了很多很多事情。每个工程师至少现在感觉既危机又兴奋——有些人危机有些人兴奋。兴奋的会觉得一天能做以前 5 天的事情。但这个事情回到组织上——咱们团队一天能做完 5 天的事情吗大部分还是做不到的能做到两倍的提升已经是一个比较先进的状态了。所以理论上它应该是能帮助大家做更多提效的。在我这边我从产品技术角度给另一个视角的看法——这不是唯一的解决方案只是一个视角的参考。如果要构建一个产品或构建一套机制的话需要把 Agent 和人类以及多个人类和多个 Agent 一起纳入到一个系统里面让他们能够在这个系统里对等地去消费这些上下文对等地去生产这些上下文。在这样一个前提下面本身未来还有更多的事情可以做但可能这个是一个比较好的前提。相当于是把 Agent 的工作平面拉到和人一样的工作平面上。未来肯定还有更多问题需要我们去解决这么好的内容你不转一下吗转发本篇文章至朋友圈截图私信后台可免费领取AiDD上海站演讲PPT下载链接下一站北京我们继续聊。