标签 智能体系统 下的文章

过去几年，AI 更多是“工具”：

写文案、做图、生成代码、回答问题。

但进入 2026 年，一个明显变化正在发生：
AI 开始从“被使用的工具”，变成“主动运行的系统”。

这背后的关键不是模型升级，而是 AI 智能体（Agent）开始进入工作流程。

智能体和普通 AI 最大的区别在于三点：

  • 有明确目标
  • 能自动拆解任务
  • 能持续执行并根据结果调整行为

这意味着 AI 不再只回答问题，而是可以：

  • 自动跑流程
  • 自动查数据
  • 自动生成内容
  • 自动更新系统
  • 自动复盘结果

AI 开始“做事”，而不是“回答”。

内容创作不再是“人写完就结束”，而是变成完整流程：

选题 → 生成 → 发布 → 复盘 → 优化
都可以由智能体持续运行。

人类更多负责判断方向，而不是重复劳动。

生产排程、异常检测、库存预测正在被智能体接管。
系统可以全天候运行，持续优化。

经验正在被算法替代，决策周期大幅缩短。

审批、汇报、统计、监控等工作，开始被自动化代理接管。
管理的重心从“管人”，变成“管系统”。

2026 年开始，个人的能力上限被系统放大：

  • 一个创作者拥有内容智能体
  • 一个创业者拥有运营智能体
  • 一个开发者拥有测试与运维智能体

人与人的差距，开始取决于系统，而不是时间投入。

真正的变化在于三点：

  • 工作从操作型，转为决策型
  • 组织从层级型，转为系统型
  • 生产从人工驱动，转为自动优化

AI 元年并不意味着失业潮，而意味着生产关系重排。

从 2026 年开始，人和企业会明显分成两类：

  • 拥有智能体系统的一方，效率指数级提升
  • 仍停留在工具使用阶段的一方，逐渐被边缘化

关键不在于会不会用 AI，而在于：

是否把 AI 变成了自己的系统。

当智能体开始长期运行，
当流程开始自动完成，
当系统能自己优化，

AI 才真正改变了世界。

2026 年，不是技术爆发的一年，
而是规则悄然改变的一年。

从 Meta 离职、加入 Anthropic，这个决定在今天看来并不意外，但在当时却并非顺水推舟。

 

对 Claude Code 创建者 Boris Cherny 来说，这并不是一次普通的职业跳槽，而是一种价值判断：当大模型从“工具”逐步演化为具备自主生成与推理能力的系统，工程师究竟应该站在什么位置？是把它当作效率插件，还是把它视为一种需要被认真约束、引导和共同演化的新型技术力量？

 

近日，Boris Cherny 做客一档名为《The Peterman Pod》的访谈栏目，主持人 Ryan Peterman 与 Boris 围绕这一系列问题展开了长达一个半小时的深度对话。

 

访谈的前半部分，Boris 回溯了自己从 Meta 转向 Anthropic 的动机。他并未从公司前景或个人发展谈起，而是从第一次使用 ChatGPT 的震撼说起。在他看来，大语言模型并不只是“更聪明的软件”，而更像一种尚处在早期阶段的“新生命形态”——它的能力增长呈指数级，影响范围远超工程本身，最终会重塑社会运行方式。正因为如此，他选择加入一个将安全、对齐与长期风险置于核心位置的研究机构，而不是继续在以产品速度和规模为优先目标的大厂体系内工作。

 

这种价值取向，也直接塑造了 Anthropic 内部截然不同的工程文化。在鲍里斯的描述中，Anthropic 依然保留着创业公司式的“常识感”：工程决策不需要层层说服，安全不被视为拖慢产品的负担，而是与模型能力同步演进的前提条件。随着模型能力提升，风险不再只是内容失误或选举操纵，而是逐步逼近生物安全、社会系统性破坏等更高等级的问题。这并非科幻设想，而是工程师当下必须正视的现实边界。

 

在此背景下，Claude Code 的诞生与演进，成为这次访谈的另一条主线。Boris 坦言，Claude Code 在相当长时间里并不是一款“好用的产品”。它之所以最终跑出来，并非因为早期体验领先，而是因为团队在一开始就选择“为未来六个月后的模型能力而设计”，而不是围绕当下模型的短板打补丁。

 

随着 Sonnet 和 Opus 4 等模型上线，Claude Code 从辅助工具迅速跃迁为主力生产方式，在 Anthropic 内部，大量代码已经由模型生成，工程师的角色也随之发生变化。

 

但这并不意味着“氛围编码”可以无条件替代人类判断。Boris 反复强调，模型生成的代码与人写的代码必须接受同一套质量标准：不合格就不合并。不同任务对应不同协作方式——原型、临时代码可以交给模型快速推进，而核心逻辑仍需要工程师逐行审视。这不是“人被 AI 取代”，而是人类工程师与模型之间形成一种新的协同分工。

 

更重要的是，Claude Code 的使用场景正在溢出传统的软件工程边界。数据科学家、分析师、甚至销售团队，都在把它当作通用的工作执行工具，连接数据库、业务系统和数据源完成实际任务。这种扩散并非最初的产品设计目标，却揭示了一个趋势：当“写代码”本身变得门槛更低，软件能力正在被重新分配到更多角色手中。

 

贯穿整场对话的，是一个清晰却并不轻松的判断：软件工程正在经历一次结构性重写。工程师不再只是代码的直接生产者，而正在成为“智能体系统”的设计者、管理者和最后的责任人。Claude Code 只是一个具体案例，但它所揭示的，是一个更大的变化——当模型能力以指数级提升，工程文化、工作方式乃至风险边界，都必须随之重构。

 

以下为访谈实录，经由 InfoQ 翻译及整理：

 

Claude Code 创建者，职业生涯起步于 Facebook

 

Ryan：我想从你晋升为 Meta 高级工程师开始讲起你的故事。你晋升的那些项目背后有什么故事？当时你在哪里？

 

Boris：如果我没记错的话，这个项目叫做“群组聊天”，目的是为了让 Messenger 和 Facebook 之间的联系更加紧密。

 

我在 Meta 参与的最初几个项目都与 Messenger 和 Facebook 有关。第一个项目是扎克伯格提出的将 Messenger 聊天记录和 Facebook 群组同步的想法。当时有几个项目旨在拉近 Messenger 和 Facebook 之间的距离。

 

最初的动机是，我们感觉公共空间社交产品正在消失，而人们的注意力更多地转移到聊天和更随意的实时空间。我们尝试了几个产品版本，最终“聊天和群组”版本取得了成功。

 

我记得当时应该是第三个或第四个项目。那时我在 Facebook Groups 部门，主要负责 Messenger 的相关工作，但 Messenger 的组织架构和我们离得很远。这个想法是当时的 PM Steve 提出的。我听了之后觉得，好啊，太棒了！就这么办！我就开始着手开发。很快有了进展，于是我申请了更多工程师，有三位工程师加入了。

 

我们获得了一些数据科学和设计方面的支持。项目最初在网页端启动，后来也稍微拓展到了移动端。我们验证了在 Facebook 群组内进行聊天的想法，并证明了这类产品是可行的。当然，也有很多方面最终都失败了。

 

以现在的产品标准来看，当时的体验简直糟透了。那时候，大家都在用 Web 开发，各种各样的 bug 都完全可以接受。但现在，视觉效果和质量标准要高得多。产品不断发展壮大，而我们团队很小，所以每个人都得包揽所有工作。

 

我记得当时我们没有用户研究员，所以我会在午餐时间去食堂。我们会推出一个新功能，然后向食堂工作人员展示，问他们能不能找到打开聊天窗口的方法。有时候他们能找到，有时候找不到。

 

这是一项观察性用户研究。你可以观察人们在特定情况下如何完成任务，而无需过多提示，从而了解他们在哪些方面遇到困难，以及最终取得了哪些成果。我教会了团队如何进行这项研究，很快我们就会利用午餐时间去食堂，询问食堂工作人员（作为用户的代表）这种方法是否合理。

 

Ryan：有趣的是，你当时所处的早期 Facebook 文化允许工程师们在代码之外做很多事情。例如，你当时在做用户体验研究。我记得在你的经历中，你也做过一些设计工作，并且指导过其他人进行设计。我认为这在 Facebook 的企业文化中是一个非常有趣且独特的事情。对吗？

 

Boris：我觉得这一点非常重要。直到今天，在我所在的 Claude 团队中，我们仍然非常重视通才型人才。

 

我喜欢和通才共事。如果你是一位既会写代码又能做产品开发、设计，并且具备产品意识的工程师，那么你肯定想和用户交流。我非常喜欢和这样的工程师一起工作。现在我们所有职位都是这样招聘的：我们的产品经理会写代码，我们的数据科学家会写代码，我们的用户研究员也会写一点代码。

 

我非常喜欢这些通才。我的成长经历也是如此。从 18 岁创办第一家公司开始，我就得事事亲力亲为。在加入 Facebook 之前，我也一直在一些规模较小的公司工作，那里也一样，什么都得做。在大公司里，你可能会被安排在某个特定领域，但这其实只是个形式。工程技能的范围很广，除了编写代码，完成整个流程还有很多其他方面需要考虑。当时能在一家真正重视这种能力的公司工作，感觉真的很棒。

 

我觉得在那半年结束时，我得到了晋升，然后我觉得在那半年结束后，所有的工程师也都得到了晋升。

 

Ryan：在那些早期产品中，存在着你多次提到的“潜在需求”概念，这正是许多产品方向的推动力。你能解释一下“潜在需求”吗？

 

Boris：潜在需求是产品设计中最重要的原则。纵观 Facebook 的成功产品，每一款都蕴含着潜在需求的元素。

 

例如，Marketplace 的诞生源于一项观察：当时 Facebook 群组中 40% 的帖子都是关于买卖物品的。Facebook 群组最初并非为商业用途而设计，但人们却用它来做这件事。你设计的产品要具有一定的可扩展性和易用性（即使被“滥用”）。然后，你分析数据，看看用户是如何“滥用”的，并以此为基础开发新的产品功能。

 

先是出现了 Facebook 群组，然后是买卖群组。买卖群组之所以发展迅速，是因为人们本来就想在 Facebook 群组里进行商业活动。接下来是 Marketplace，它只是人们这种意图的自然延伸。Facebook Dating 的发展也与之类似。观察发现，大约 60% 的个人资料浏览量来自互不相识的异性用户。这种传统的互相“窥探”行为证明了这种方法的有效性。

 

产品设计的核心原则是：你永远无法强迫人们去做他们原本不会做的事情。但你可以找到他们的潜在意图，并引导他们更好地利用这种意图，从而更轻松地实现目标。

 

“跨部门工作简直是一场噩梦”

 

Ryan：在你的叙述中，你提到你曾跨部门工作，因为你负责弥合 Messenger 和 Groups 工程团队之间的鸿沟。你说存在一些明显的文化差异，这很困难。对于在文化差异很大的组织之间工作，你有什么建议吗？

 

Boris：我的天哪，说困难都太轻描淡写了。简直是一场噩梦。当时 Facebook 的目标是尽快推出优秀的产品。而 Messenger 则完全专注于可靠性和性能，他们只关心这些。这完全是截然相反的价值观。

 

这不仅仅是文化差异或工程师之间的问题。那个团队的工程师对我们抱有戒心，因为我们的工作可能会影响他们的绩效指标。他们的组织目标是稳扎稳打，在不影响核心指标的前提下稳步推进产品发布；而我们的组织目标是快速发布。

 

目标完全不同。他们关注的是服务级别协议规定的正常运行时间，而我们只关注日活跃用户数和用户参与度。这些文化价值观根深蒂固，不仅体现在人们的言谈中，更体现在组织架构、目标设定等各个环节。

 

那个项目最终能部分成功，克服了价值观差异，关键在于：如果你想让价值观截然不同的团队成功合作，就必须找到某种共同的目标、共同的兴趣或共同的信念。让他们能够一起验证某个假设，并且如果验证成功，对双方都有益处。

 

Facebook 的“聊天和群组”功能很酷，但很多功能在 Messenger 上实现时却不太理想，原因就在于此。

 

Ryan：既然你现在知道了这些，你会如何改变现状？

 

Boris：我可能会去找高层（比如扎克伯格），然后说，如果你真的对这件事很认真，我们应该把 Messenger 并入 Facebook 的组织架构下。我觉得这件事后来确实以某种形式发生了。Messenger 最初在公司里，后来搬了出去，然后又搬了进来，之后又搬了出去。公司这么大，这种情况难免发生。

 

但我认为，从根本上来说，这类事情要想成功，不能只靠普通经理去协调。可能需要更高层的介入，调整组织架构，让它们更具合作性。

 

Ryan：在你职业生涯的这个阶段，我看到你做了很多非常有趣的副业项目，我很好奇这些项目会产生怎样的蝴蝶效应。例如，在你加入 Meta 之前，你曾参与过 Undux 的开发，这是一个 React 的状态管理框架。我很好奇这段经历对你的职业生涯产生了怎样的影响？

 

Boris：对我来说，支线任务非常重要。我招聘工程师时，这绝对是我会考虑的因素之一。我想要那些有副业项目的人，比如周末可以做一些有趣的事情。甚至包括那些对制作康普茶充满热情的人。你需要的是那些对工作以外的事物充满好奇心和兴趣的人。这些人全面发展，我喜欢和他们一起工作。我的很多成长都来自于参与这些副业项目。

 

说实话，像 Undux 这样的工具，源于我觉得当时用 React 管理状态太复杂了。当时最先进的技术是 Flux，后来又出现了 Redux，但我完全搞不懂 Redux。我自认为只是个水平一般的产品开发工程师，不是那种技术高超的系统工程师。Redux 的概念，比如 reducer，更新一个小小的状态都需要非常复杂的流程，我理解不了。

 

所以我做了一个更简单的版本，效果不错。当时我在一家非营利组织做志愿者，他们开始使用这个版本，他们的工程师也很喜欢。加入 Facebook 后，我发现很多人在使用 Redux 时遇到困难，公司内部有一个 Redux 用户群，里面有很多问题，和我当初问的都一样。

 

当你作为工程师遇到问题时，有时可能只有你一个人遇到；但很多时候，其他人也会遇到同样的问题。培养一种“直觉”，能够预判其他人可能也遇到的类似问题，这非常重要。我遇到的这个问题显然是其他人也遇到的，我在用户支持帖子里也看到了。

 

我在公司内部推出了 Undux。它还不错；虽然算不上很棒的产品，但比 Redux 简单。在 Facebook 的时候，我不知道该如何推广它，所以我就发帖宣传了一下。结果有几个人开始用了。我记得通知团队的 Jeff Case 是这项功能的早期积极使用者，我们因此熬了好几个通宵，调试一些棘手的通知相关 bug。

 

为了推广这项功能，我写了个小脚本，抓取了提交问题的用户群体，并按团队进行了统计。我通过聊天工具联系了每个团队的技术负责人和经理，并为每个团队安排了一场技术讲座。在几周的时间里，我大概做了二三十场，甚至四五十场技术讲座。我记得当时骑着自行车在 Meta 园区里四处演讲，感觉特别棒，因为大家都很投入，也很兴奋有人关心这个问题并想解决它。

 

曾经，Undux 是 Facebook 最流行的状态管理框架之一。但很快它就被 Recoil 和其他更现代的方案取代了。如今，Relay 之类的框架又开始流行。

 

Ryan：这种副业项目会出现在你的绩效考核中吗？或者对你有什么帮助？

 

Boris：我觉得它应该写在我的绩效考核里了。按 Meta 的标准来说，这算是锦上添花。它本身并不能让你直接晋升到下一个级别。那段时间我还有很多其他的支线任务。

 

后来，我突然对 TypeScript 非常着迷。这是我之前在一家公司用过的。当时相关的资源不多，所以我开始写一本关于它的书，因为总得有人做这件事。这门语言太棒了，设计非常出色，包含了很多当时其他语言不具备的理念，像条件类型、字面量类型、映射类型之类的，简直太疯狂了。即使是最资深的 Haskell 程序员也会惊叹，但之前却没有人系统性地写过这些内容。

 

我当时完全沉迷其中，写了这本书，几乎耗尽了我整整一年的业余时间。我不推荐别人也这样做，但深入研究的过程真的很有趣。当时我还在旧金山创办了世界上最大的 TypeScript 聚会。能见到 Node.js 的创始人 Ryan Dahl 以及其他这些著名的 JavaScript 大咖，真是太棒了。这让我意识到，他们也只是普通人；每个人都能创造出很酷的东西。

 

Ryan：后来你在 Meta 工作期间，或者甚至在 Anthropic 工作期间，最终有没有大量使用 TypeScript 或达到那种技术深度？

 

Boris：是啊，说起来挺有意思的；我以前其实对编程语言本身一点兴趣都没有。大概十年前，我骑摩托车的时候出了一场很严重的车祸，双臂都骨折了，身上绑着两个吊带。

 

Ryan：我的天哪。你是怎么写出代码的？

 

Boris：那才是最难的部分。我整整一个月都不能写代码，而且我的手现在还有点疼。我写不了 JavaScript（按键多），所以我不得不学习其他按键次数更少的语言。我一开始学的是 CoffeeScript，因为它的括号比较少。这门语言现在应该已经没什么人用了。我也是通过 CoffeeScript 接触到 Haskell 和函数式编程的。你可以用更少的击键次数完成同样的事情，这正是我当时的动力。

 

在加入 Facebook 之前，我在一家对冲基金工作，我的同事 Rick 对 Scala 非常着迷。他带我入门，也让我接触到了函数式编程。如果让我推荐一本对我的工程师生涯影响最大的技术书籍，我会毫不犹豫地推荐《Scala 函数式编程》。你可能永远不会每天都用 Scala，但它教你思考编程问题的方式，与大多数人在学校或实践中接触的方式截然不同，这彻底改变了我的编码方式。

 

对我来说，Scala 和 Haskell、CoffeeScript 一样，是少数几种改变我思维的语言。第一步是 CoffeeScript，然后是 Scala，再然后是 TypeScript。这改变了我的思维方式，因为现在我编码时会用类型来思考。代码中最重要的就是类型签名，这比代码本身更重要。做好这一点能写出非常简洁、健壮的代码。

 

即使在 Facebook，我主要用 Flow 和 Hack，后来在 Instagram 用 Python，这种思维方式也很有帮助。在 Anthropic，我主要用 TypeScript 和 Python，所以这一点仍然非常重要。更重要的教训就是要学会用类型来思考。

 

Ryan：在你职业生涯的这个阶段，你提到你刚入职时级别偏低，只是个中级工程师，尽管你经验丰富。你说现在回想起来，当时级别低反而是件好事。我很好奇你当时是怎么想的。

 

Boris：在大公司里，对于项目影响和人员影响方面都有很多期望，具体标准因公司而异。很多事情要么关乎项目的影响，要么就是为了完成一堆任务，而这一切都非常耗时。刚开始的时候等级不够，反而给了我探索的空间，让我可以纯粹为了创造而创造，没有太多绩效压力。

 

Ryan：没错。我很好奇这是否也有助于积累势头。如果你以中级级别加入，然后表现出色，所有人都会说“Boris 太棒了”。这很不可思议。而如果你以更高预期级别加入，表现平平，情况就完全不同了。当你一加入就让所有人眼前一亮时，会产生一种奇妙的效果，你会给人留下非常深刻的第一印象。我认为这有助于建立良好的声誉，从而在未来获得更多的信任、更多的项目等等。

 

Boris：是的，我觉得完全正确。这对于任何公司来说都是很好的建议。很多时候，工程师跳槽的时候会非常积极地争取更高级别，比如“我想去另一家公司，我想升一级”之类的。这样做有很多弊端。

 

Ryan：接下来我想问一下是什么让你在 Meta 晋升为资深工程师（E6）。我很好奇你当时的职位，以及是什么推动你晋升到这个更高层级的领导岗位。

 

Boris：当时的情况是，Facebook 推出了群组聊天功能，并且有一个团队负责开发。在加入 Facebook 之前，我写过很多 JavaScript，但在 Facebook 内部，我之前从未真正写过 JavaScript，因为当时主要用 PHP。我真的很想写 JavaScript。

 

我们当时专门为 Facebook 群组开发了一个网页界面。很多人使用网页版而不是手机版，因为群组管理员在电脑上用键盘操作起来更方便。但当时这个网站真的很糟糕，它是一个静态网站，完全用 PHP 编写，只是在不同的地方零散地注入了一些 JavaScript 代码，结果导致了各种不一致的状态和问题，用户体验很差。

 

我当时想用 JavaScript 重写整个界面，但遭到了公司内部的强烈反对，主要原因是我们已有的基础设施还没准备好。幸运的是，与此同时，Comet 项目启动了，该项目旨在重写 facebook.com 的桌面版。

 

当时有很多核心成员在做这个项目，我真的很想参与。我主动联系他们，询问我能如何帮忙，并提议先在 Facebook 群组里进行测试和探索。我几乎是没问任何人就直接开始做了。

 

后来，我跟 Facebook 群组部门的领导们说：“嘿，Comet 项目马上就要全面推行了。这会是一项艰巨的工作。但我们可以提前做好准备，为所有其他团队树立一个迁移标准，并与其他团队建立联系。”我仍然遇到了阻力，比如他们说“你不能安排 20 个工程师来做这件事”。经过多次讨论和讨价还价，我们最终组建了大约 12 名工程师的团队，因为这是一个相当大的迁移项目，大约需要一年时间。

 

“群组”是 Facebook 所有产品中规模最大的一个，这有点出乎意料。这次迁移很成功。除了与这个基础架构团队建立联系和友谊之外，有趣的是，我们因此有机会影响 Comet 项目的发展方向。对于基础设施项目而言，产品团队通常无法左右项目方向，他们更像是客户。但在这个项目中，由于我们早期深度参与，我们创建了许多抽象概念，后来被其他基于 Comet 进行开发的团队所使用。

 

举一个具体的例子，比如“中继变更”。你需要发送 API 请求，并且需要某种状态一致性。之前存在一个 bug：假设有一个按钮，每次按下它都会发送一个 POST 请求。为了良好的用户体验，你希望在按下按钮后，按钮的状态立刻切换，这需要使用乐观更新。当网络请求返回时，你还需要更新本地缓存以确保一致性。但如果你连续快速点击按钮，响应可能会乱序到达，最终得到的状态可能与用户界面上显示的状态不同。

 

我写了一个系统来排队处理这些变更，这样虽然保证了一致性，但牺牲了一点即时性。在当时这是一个合理的权衡，这个方案最终被广泛采用。我就是在这个过程中认识了 Joseph 和 Relay 团队里负责数据存储的其他人。这段经历真的很有趣。每当我看到工程师深入钻研，努力弄明白复杂系统到底发生了什么时，我都很欣赏。产品工程师并不意味着你不能构建基础设施，基础设施工程师也不意味着你不能和用户交流。对技术栈的其他部分保持好奇心就好。

 

成功搞定大项目后，才有更多话语权

 

Ryan：当然。你抢先一步进行 Comet 迁移和大规模的 JavaScript 重写，正如你提到的，这实际上让你拥有了更大的影响力和话语权。你所说的机会，是指构建这些对所有使用新平台的人都至关重要的基础产品架构吗？

 

Boris：是的，这就是一个例子。另一个例子是，Comet 的质量比之前的版本高得多，因为它是一个单页 Web 应用，所以感觉更加流畅和完善。但我们当时还没有完全弄清楚“产品层面的质量”究竟意味着什么。我写了很多笔记试图定义它，也做了很多演讲，向其他团队的成员讲解我们对质量的理解，并就此展开讨论，共同塑造标准。

 

Ryan：您提到迁移到 Comet 需要大量人手。我很想知道，如果现在有了 Claude Code、Codex 等新的 AI 编码工具，情况会是怎样的。以您现在对 Claude Code 的了解，如果您负责评估这项工作，您认为现在需要多少工程师才能完成原本需要 12 名工程师花费一年才能完成的工作？

 

Boris：为了迁移 Facebook 群组，最初是 12 位工程师，但最后可能动用了 20 到 30 位工程师，持续了大约两年时间，最终变成了一个相当大的项目。现在来看，可能只需要 5 位工程师，耗时六个月左右就够了。

 

Ryan：也就是说，只需要四分之一的时间，以及不到一半的工程师？

 

Boris：是的，因为现在你可以让 AI 并行工作。你让它运行几个小时，它就能生成一个可用的 PR。你甚至可以给它装上 Puppeteer 之类的工具，让它能看到 UI 并进行视觉调整。大概就是这样。现在，从编码的角度来看，环境已经截然不同了，因为模型更新迭代太快了。如果你三个月或六个月后再问我这个问题，我的答案肯定会完全不同。六个月后，答案可能就变成了：这实际上只需要一个工程师就能完成。现在的变化实在太快了，很难做出准确的估算，也很难预测它们未来会如何演变。

 

Ryan：在你职业生涯的这个阶段，你曾提到过一件事，也许是半开玩笑地说，那时你学会了在向副总裁评审提案时，总是提出三个选项。因为 80%的情况下他们只会选择中间的那个。你这么做的想法是什么？

 

Boris：这话虽然有点讽刺，但或许当时在 Meta 公司那种特定环境下有点道理。那些远离一线具体工作的决策者，他们想知道你是否认真研究过各种方案和权衡利弊，是否真的做了充分的工作。但同时，他们也想以某种方式参与决策。提供一个“折中”选项，对他们来说比较容易理解和接受。我这么说确实带有讽刺意味，因为并非所有领导者都这样。很多领导者会亲自深入参与决策，他们或多或少信任自己的团队。管理风格有很多种。我记得当时我们有一位技术水平可能不那么深入细节的领导，而这种方法算是帮助她进行决策的一种沟通方式。

 

Ryan：在你职业生涯的这个阶段，你与高层管理人员的接触最为密切。你提到你曾向一位高级总监汇报工作，并且参与了很多重要的项目规划讨论。我很好奇，向这样一位资深人士汇报工作，对你后续的成长产生了哪些影响？

 

Boris：是的，我觉得这很大程度上取决于工程师个人和公司文化。比如，我现在在 Anthropic，我觉得在 Anthropic，你向哪个层级汇报并不重要。公司里一些最资深的员工也是向部门经理汇报的。很多部门经理本身就是前首席技术官或非常资深的人士，所以实际上这并不构成障碍。

 

我认为向高级别汇报带来的压力，在某种程度上是 Meta 公司特有的文化现象。我觉得这里存在两种情况。一是，在 Meta，你需要非常主动地找到自己的发展方向和上升路径。有些机会你可以自己发现，有些则需要你的经理或技术领导帮你识别和引荐。

 

Meta 的 PSC（绩效评估）流程出了名的严苛，你必须不断地强调和证明你的影响力。而“职责范围”是造成这种严苛体验的最大因素。如果你有足够大的职责范围，并且执行得当，就能产生显著的影响力。这就是秘诀。

 

我觉得在 Meta，另一个特点是大家都没有很花哨的头衔。即使是最资深的工程师，头衔也只是“软件工程师”，我非常喜欢这一点。贝尔实验室的技术人员也是如此，Anthropic 也是如此，但我们在这里更进一步：所有人的头衔都是“技术人员”。不管你是工程师、项目经理还是设计师，头衔都一样。我其实很喜欢这样，因为这样一来，你就可以跳出自己被默认设定的职责范围，去做那些你认为正确和必要的事情，而不用过分在意别人期望你做什么。我认为这种文化正是促成这种灵活性的原因。

 

Ryan：我看到了不设复杂头衔的很多好处。但我也能想到一种情况，也许这只适用于大公司：当你联系公司里的某个人，说“嘿，我想参与这个合作”，如果你的头衔是“总监”之类的，这就能让他们更容易理解你的层级、影响力和协作方式。如果你是设计师或其他职位，在 Anthropic 规模扩大了一些的现在，你感受到这一点了吗？也许因为大家现在都认识你，所以你没怎么感受到。

 

Boris：是的，这绝对是一个潜在的缺点。但我认为优点大于缺点。那就是你必须努力争取，用实力和贡献赢得尊重。我觉得这条原则无论在哪家公司都适用。仅仅因为你以前做过一件很棒的事，并不意味着你在新的环境里就理应自动获得权力和尊重。当然，每个人都应该得到基本尊重；但这不意味着你在一家新公司、一个新项目中就理应拥有决策权。即使是那些一开始就拥有“经理”头衔的人，也需要努力争取团队的信任。在某种程度上，拥有经理头衔反而可能让赢得这种信任变得更难。作为独立贡献者，无论如何你都必须用行动证明自己。我认为，正是因为没有那些预设的、等级森严的头衔，才使得这一切变得稍微容易一些，更注重实际贡献。

 

如何从技术人转型为高管

 

Ryan：在你职业生涯的这个阶段，你逐渐转型为技术主管或高级技术主管，我记得你讲过一些为数百名工程师制定工作计划的故事。你是怎么做到的？如果工作量如此庞大，而你又只有一个人，你是如何向领导层提出如此大规模的工作计划请求的？

 

Boris：是的，那段时间真是太疯狂了。我当时和蒂娜·萨奇曼共事很多，她现在在微软，但当时是我的经理。然后是我的上级伊芙。当时公司决定对 Facebook 群组投入更多资源。我刚加入的时候，群组部门大概只有 150 到 200 人，等我离开去 Instagram 的时候，好像已经有 600 到 800 人了。扎克伯格一直觉得 Facebook 应用的核心应该是社群，他希望我们加快速度，把这个想法变成现实。

 

作为高管，最重要的就是让合适的人负责决策，然后给他们提供资源。在 Meta，资源主要就是工程师。我们向扎克伯格推介了这个名为“社区即新组织”的内部项目。他为此投入了一大批人手，我们只需要弄清楚这些人具体要做什么。对他来说，如果事情很重要，就得投入大量人力。事后看来，我会采取不同的做法，大幅减少初期投入的人员，因为真正重要的是解决用户的问题，打造出色的产品，这必须自下而上地进行，需要随着新产品线找到市场契合点而逐步推进，不能一口气做完所有事情。

 

但当时，我们必须先把所有事情都规划好。有好几个星期，我都要写一份庞大的规划文档，内容大致是：“好，我们要安排 30 个工程师负责 A 项目。这里有三个技术方案，我们选方案二。下一个 B 项目，我们要安排 20 个工程师。这里有三个方案，我们选方案一。”就这样一遍又一遍地重复，才能确保这个庞大的项目计划不是完全异想天开。我们进行了一些基础的技术范围界定，大致估算了每个子项目需要的工程师人数。

 

其中有些事情很有意思。我记得我们曾经尝试合并 Facebook 群组和主页的数据模型。那真是一次非常棘手的迁移。要彻底实现这一点，需要很多年时间，可能还需要数百名工程师，因为必须跨数据模型、产品层、完整性系统和广告系统进行操作。当时，Yosef Carver 刚刚加入；我记得他之前在 Profile 或 Events 部门工作，这两个部门与 Groups 部门合作推进这项工作。他当时正在研究这个问题，但还在犹豫不决，无法就数据模型做出最终决定。

 

于是我召集了一群人，说：“好了，公司所有相关的技术主管都来了，我们今天花三个小时，像玩游戏一样，来讨论一下架构设计。”我把大家分成两队，好像是蓝队和绿队（记不清了）。我们给每个人布置了同一个问题：如何合并这些数据模型，并给出了具体的要求。每个人都有三个小时的时间在白板上设计方案。

 

最酷的是，一开始我们都觉得这个问题棘手，不知道该怎么做。但最后，我们两队得到的两个方案竟然有 80%的相似度！我们可以采取的行动变得非常明确，而那 20%的差异也清楚地揭示了风险所在。我们可以通过一些技术性操作来预先承担一部分风险，但我们也清楚地知道可以立即开始执行哪些部分。

 

Ryan：是啊，我觉得这个形式很有意思：就像一个技术设计竞赛，所有资深工程师都参与其中，分成几个小组，在不同房间里同步进行设计。我以前从没听说过这种形式。你当初在公司内部提出这个设计竞赛的想法时，大家是觉得很兴奋，还是觉得这有点异想天开？

 

Boris：是有点非常规。这种事，你只能硬着头皮去做，靠行动推动。我直接跟所有相关的人说：“嘿，我们要这么做了”，然后就把会议日期记在了每个人的日历上。感觉挺有意思的；作为工程师，你肯定也想参与这种创造性的解决问题的过程。但有时候你需要漫长的过程来达成共识，有时候你则需要快速行动来打破僵局。

 

在这种情况下，由于技术方向不明朗，采取行动至关重要。但同时，我自己也不知道确切的最佳路径，所以我们必须召集所有关键人员，通过这种高强度、高协作的方式快速达成共识。作为技术领导者，你总是需要在“推动共识”和“果断行动”这两件事之间寻求平衡。

 

Ryan：有了那次为数百名工程师规划项目的经历，你对那些需要快速进行项目范围界定的技术主管有什么建议吗？有什么对你来说行之有效的方法或原则？

 

Boris：我觉得我看到的最大问题是人们花费的时间太长，而且过于纠结细节。细节总是无穷无尽的。最好从宏观层面入手。大多数技术范围界定都可以在 30 分钟内完成一个非常粗略的版本。

 

如果你不了解所涉及的系统，现在你甚至可以让 AI 来帮忙。你只需要在代码库中运行一个查询，或者直接问 AI：“要实现 X 功能，会涉及代码库中的哪些系统和模块？”它实际上可以帮你快速梳理出依赖关系。这真是个不可思议的改变。我以前做这些事情的时候，绝对想不到人工智能现在能帮我做到这些。

 

但回到一般性原则，我过去的建议是：设定严格的时间限制。用于初步范围界定的会议最多花 30 分钟。如果需要深入研究代码，最多几个小时。一定要联系专家，并列出所有需要咨询的专家名单。和他们所有人交流。但不要只是泛泛地征求他们的意见。给他们一个具体的假设或初步设计方案，这样他们才能真正给你有建设性的反馈，你才能以此为依据进行迭代和完善。

 

Ryan：继续你的职业经历。你晋升到高级职位的关键，似乎和 Facebook 的“公共群组”项目有关。我很想了解这背后的故事，以及其中发生了什么有趣的事？

 

Boris：是的。“公共群组”项目源于我们想让 Facebook 群组更开放。我们当时想做一个看似简单、但实际非常复杂的改动：让用户无需加入，就能查看和评论公开群组的内容。

 

这听起来像改一行代码，但实现起来异常困难。因为它触及了核心的数据模型问题：在数据库里，一个发表评论但未“加入”的用户，到底算不算“群组成员”？这引发了我们内部激烈的技术讨论。

 

过去的“加入”需要管理员批准，是一种信任投票。现在对于公开群组，行为变成了“关注”。那么，“关注”和“加入”在数据层面应该是同一回事吗？当时公司里一位资深的元老级工程师鲍勃，强烈认为这必须是两件不同的事，并要求进行大规模的数据迁移来区分它们。

 

这还引发了连锁反应：如果任何人都能评论，垃圾信息怎么办？我通过一个简单的蒙特卡罗模拟，展示了潜在的垃圾信息风险，最终成功说服了公司的诚信团队介入，帮助调整评论排名算法来应对。

 

为了完成数据迁移等所有工作，我们组建了一个大团队。当时我和其他几位资深工程师同级，都需要我来协调指导，这让我一度感到有些“冒名顶替”。但最终，正是因为我推翻了之前鲍勃关于数据迁移的决定，才促成了我后来的晋升。

 

我经过审核发现，最初的“成员”字段其实完全可以同时表示“关注者”和“群组成员”，强制区分只会让后续所有开发变得复杂。我敦促负责的工程师撤销了那次迁移。这个正确的技术判断，反而让鲍勃更认可我作为技术领导的能力，因为我能基于事实对资深人士的决定提出异议。

 

Ryan：你和高级技术主管之间存在严重技术分歧，但结果反而加强了关系。对于如何处理这类分歧而不损害关系，你有什么建议？

 

要敢于挑战权威

 

Boris：我认为核心是赢得信任。在你拥有足够的技术信任之前，很难去挑战权威。一开始，可以更多地倾听、执行，表现出尊重和合作意愿。同时，你必须通过实际行动积累扎实的技术判断力。在赢得信任后，你基于事实和专业提出的异议，才更容易被接受。

 

Ryan：关于“冒名顶替综合症”，以及领导那些和你同样优秀的工程师，你有什么建议？

 

Boris：别想太多。其实没人真正知道自己在每个新层面上具体该做什么，大家都在摸索。这种感觉会随着时间慢慢消失。某种程度上，始终保持一点点“冒名顶替”感是健康的，那说明你还在努力突破舒适区。

 

Ryan：在你职业生涯的这个阶段，你更像技术主管，编码减少。你曾提到，在 Meta，有时其他职能（如产品经理）支持不足，你认为这是让工程师更多关注产品、甚至参与产品管理的机会。你如何决定何时该自己顶上，而不是反复要求更多支持？

 

Boris：关键在于理解利弊和背景。你需要从决策者的角度思考：他们关心什么？手头有哪些项目？做这件事的代价是什么？是否能帮他们成功？有些组织可能确实资源紧张，或认为你的项目优先级不够。有些组织则可能资源充沛。了解你所在的环境和决策者的处境，才能判断是应该自己主动补位，还是能够争取到资源。

 

Ryan：你将自己的成功很大程度上归功于“副业项目”。你对工程师如何寻找这样的机会有什么建议？

 

Boris：我的很多想法来源于日常工作中那些重复、繁琐的部分。工程师的超能力就是自动化。我养成了一个习惯：在代码审查中，如果我多次评论同一类问题，我就会写一条规则来自动化检查它。很快，我几乎自动化了所有代码审查。

 

这些“副业”往往就是去改进那些拖慢日常开发速度的基础设施或工具。这不仅能解放自己，也能惠及整个团队。一个核心原则是：如果你遇到了某个问题，很可能其他人也遇到了。为自己打造解决方案，往往就是为很多人打造解决方案。

 

为何从 Meta 转向 Anthropic

 

Ryan：你从 Meta 离职加入 Anthropic，当时是怎么做出这个决定的？

 

Boris：我第一次用到 ChatGPT，是它刚推出不久的时候。当时我在日本，一个小地方，几乎没有人能和我讨论技术。我每天刷 Hacker News，用到 ChatGPT 后的第一反应是：这东西太不可思议了。

 

现在回头看我们已经习以为常，但当时的大模型给我的感觉，更像是一种“新生命”。它不仅是一项技术，而是一种可以被培育、被引导的存在。我本人很喜欢科幻小说，尤其是硬科幻，所以当我意识到这类模型意味着什么时，心里只有一个想法：我一定要参与其中。

 

后来我去了解哪些实验室在做这件事，也和一些在不同研究机构工作的朋友聊过。第一次和 Anthropic 的创始团队吃饭时，我随口提到了一本科幻小说，结果发现桌上几乎所有人都读过，还能继续讨论别的作品。那一刻我意识到，这是一个真正认真思考“这些技术会把世界带向哪里”的地方。

 

人工智能正在改变社会，而且是从工程领域开始，逐步扩散到各个层面。我也很清楚，这项技术存在很多潜在风险，甚至可能走向非常危险的方向。对我来说，加入 Anthropic 几乎是顺理成章的选择——如果我能做点什么，那就是站在一个真正把“安全”和“长期影响”当回事的地方。

在 Meta，安全往往被当成一种负担，是和产品对立的事情。但在 Anthropic 完全不同。我们在安全和对齐研究上投入了大量算力和人力，甚至因为不确定模型是否足够安全而推迟发布。随着模型能力提升，风险也在快速上升，这已经不是科幻，而是现实问题。我很庆幸自己能参与其中。

 

Ryan：加入 Anthropic 之后，你感受到的工程文化和以前最大的不同是什么？

 

Boris：有两点特别明显。第一，公司虽然已经不小了，但仍然保留着创业公司的“常识感”。很多事情不需要复杂的流程去推动，大家天然会做正确的决定。这是大公司最容易丢失的东西。

 

第二，对我个人来说，最重要的是使命感。它让我每天都愿意来上班，甚至周末也愿意写代码，不是因为 deadline，而是因为我想这么做。我在 Facebook 群组项目里感受过类似的氛围，但在 Anthropic，这种感觉更强烈，也更一致。

 

Claude Code 为什么能跑出来

Ryan：你是 Claude Code 的核心推动者之一。当初市面上也有不少类似工具，Claude Code 真正不同的地方在哪里？

 

Boris：一开始，大家对“AI 编程”的理解非常狭窄，基本等同于自动补全。即便有一些智能体的概念，也更多是问答工具，而不是能真正参与编程。

 

坦白说，在很长一段时间里，Claude Code 本身也并不好用。即便在内部，我可能只用它写了不到 10% 的代码。关键在于，我的主管一直提醒我：不要按“现在的模型能力”来设计产品，而要按“六个月后的模型能力”来设计。

 

后来 Sonnet 和 Opus 4 发布后，一切发生了变化。短短几个月，我自己有一半以上的代码都交给 Claude Code 来写。现在在 Anthropic，很多团队 80% 到 90% 的代码都是用 Claude Code 生成的。公司规模虽然扩大了，但工程师的整体生产力反而显著提升。

 

Ryan：有人担心模型生成大量代码，但质量不稳定、问题隐蔽，你怎么看？

 

Boris：AI 编程和任何工具一样，是需要学习如何使用的。我们内部的原则很简单：不管代码是人写的还是模型生成的，标准完全一致。代码不好，就不合并。

 

不同场景需要不同方式。原型、临时代码，可以更“感觉驱动”；核心代码，就必须逐行推敲。大多数时候，我是和模型一起写代码：先制定计划，再让模型生成，再不断修改、清理。某些关键部分，我仍然坚持手写。

 

现在的模型编码能力当然还不完美，但已经是“史上最差的一代”了。一年前还只是自动补全，现在已经是完全不同的世界。

 

Ryan：除了写代码，你觉得 Claude Code 还能用在哪些地方？

 

Boris：我们公司里的数据科学家、分析师，甚至销售团队都在用它。有人用它写 SQL、跑分析、搭数据管道；销售团队把它接入 Salesforce，直接干活。这完全超出了我们最初的设计预期。

 

Ryan：你怎么看 Claude Code 和 Codex、OpenAI 之间的竞争？

 

Boris：说实话，我几乎不看其他产品。过度关注竞争对手，很容易让团队迷失方向。我们只专注一件事：解决我们自己、Anthropic 研究人员以及用户真正遇到的问题。

 

Ryan：你不是计算机科班出身，这对你有影响吗？

 

Boris：几乎没有。我学的是经济学，后来辍学创业。编程是一项高度实践性的技能，最重要的是动手做、做出产品。理论当然有价值，但对我个人来说，从来不是关键。

 

Ryan：你效率很高，有什么秘诀？

 

Boris：现在我的答案只有一个：学会用 Claude Code，而且是同时用多个。你不再是亲自写每一行代码，而是在做统筹、调度和判断。这就是工程的未来。

 

Ryan：你觉得工程师会不会越来越像管理者？

 

Boris：某种程度上是的。但我依然很享受安静地写代码。现在我每天早上都会启动几个 Claude Code 代理，让它们先跑起来，等我到电脑前再检查、合并或修改。

 

这听起来很疯狂，但它确实有效。甚至一些多年不写代码的管理者，现在也能重新参与进来。我们熟悉的“写代码”这件事，正在发生根本性的变化，而且正在变得对更多人开放。

 

参考链接：

https://www.youtube.com/watch?v=AmdLVWMdjOk

本系列介绍增强现代智能体系统可靠性的设计模式，以直观方式逐一介绍每个概念，拆解其目的，然后实现简单可行的版本，演示其如何融入现实世界的智能体系统。本系列一共 14 篇文章，这是第 14 篇。原文：Building the 14 Key Pillars of Agentic AI

优化智能体解决方案需要软件工程确保组件协调、并行运行并与系统高效交互。例如预测执行，会尝试处理可预测查询以降低时延，或者进行冗余执行，即对同一智能体重复执行多次以防单点故障。其他增强现代智能体系统可靠性的模式包括：

  • 并行工具：智能体同时执行独立 API 调用以隐藏 I/O 时延。
  • 层级智能体：管理者将任务拆分为由执行智能体处理的小步骤。
  • 竞争性智能体组合：多个智能体提出答案，系统选出最佳。
  • 冗余执行：即两个或多个智能体解决同一任务以检测错误并提高可靠性。
  • 并行检索和混合检索：多种检索策略协同运行以提升上下文质量。
  • 多跳检索：智能体通过迭代检索步骤收集更深入、更相关的信息。

还有很多其他模式。

本系列将实现最常用智能体模式背后的基础概念，以直观方式逐一介绍每个概念，拆解其目的，然后实现简单可行的版本，演示其如何融入现实世界的智能体系统。

所有理论和代码都在 GitHub 仓库里：🤖 Agentic Parallelism: A Practical Guide 🚀

代码库组织如下：

agentic-parallelism/
    ├── 01_parallel_tool_use.ipynb
    ├── 02_parallel_hypothesis.ipynb
    ...
    ├── 06_competitive_agent_ensembles.ipynb
    ├── 07_agent_assembly_line.ipynb
    ├── 08_decentralized_blackboard.ipynb
    ...
    ├── 13_parallel_context_preprocessing.ipynb
    └── 14_parallel_multi_hop_retrieval.ipynb

深度推理的多跳检索

许多复杂的用户查询并非单一问题，而是比较性的、多步骤的调研任务，需要从多个不同来源的文档中综合信息。

并行多跳

解决方案是 并行多跳检索（Parallel Multi-Hop Retrieval） 架构，这种模式将 RAG 系统提升为真正的调研代理，工作流模拟人类研究员如何处理复杂问题的过程：

  1. 分解（Decompose）：高级元代理首先分析复杂的用户查询，将其分解为几个更简单、独立的子问题。
  2. 分散（并行检索）：每个子问题都被派发给各自的专用检索代理。这些代理并行运行，每个代理执行标准 RAG 流程，为特定子问题寻找答案。
  3. 收集与综合：元代理收集所有子问题的答案，进行最终推理步骤，将它们综合为对原始复杂查询的单一、全面的答案。

我们将以一个无法通过单一检索回答的比较性问题为例，构建并比较简单 RAG 系统与多跳 RAG 系统，证明只有多跳系统才能成功收集必要的证据，以提供准确且富有洞察力的最终答案。

首先为初始分解步骤定义 Pydantic 模型，从而结构化元代理规划阶段输出的内容。

from langchain_core.pydantic_v1 import BaseModel, Field
from typing import List

class SubQuestions(BaseModel):
    """分解代理输出的Pydantic模型，包含一组独立的子问题"""
    questions: List[str] = Field(description="A list of 2-3 simple, self-contained questions that, when answered together, will fully address the original complex query.")

这个 SubQuestions 模型是元代理首次行动的合约，迫使 LLM 将复杂查询分解为一系列简单、可回答的问题，是并行"分而治之"策略的基础步骤。

然后构建高级多跳系统作为 LangGraph 图。第一个节点将是"分解器"，即元代理的规划角色。

from typing import TypedDict, List, Dict, Annotated
import operator

class MultiHopRAGState(TypedDict):
    original_question: str
    sub_questions: List[str]
    # 字典以问题作为键，存储每个子问题的答案
    sub_question_answers: Annotated[Dict[str, str], operator.update]
    final_answer: str

# 节点 1：分解器（元代理的第一步）
decomposer_prompt = ChatPromptTemplate.from_template(
    "You are a query decomposition expert. Your job is to break down a complex question into simple, independent sub-questions that can be answered by a retrieval system. "
    "Do not try to answer the questions yourself.\n\n"
    "Question: {question}"
)

decomposer_chain = decomposer_prompt | llm.with_structured_output(SubQuestions)

def decomposer_node(state: MultiHopRAGState):
    """获取原始复杂问题并将其分解为子问题列表"""
    print("--- [Meta-Agent] Decomposing complex question... ---")
    result = decomposer_chain.invoke({"question": state['original_question']})
    print(f"--- [Meta-Agent] Generated {len(result.questions)} sub-questions. ---")
    return {"sub_questions": result.questions}

decomposer_node 是研究代理的战略大脑，它不会尝试回答查询，其唯一且关键的任务是分析用户意图并将其分解为一组独立、可并行化的研究任务。

下一个节点将并行为每个子问题协调执行标准的 RAG 流程。

from concurrent.futures import ThreadPoolExecutor, as_completed

# 标准、自包含的RAG链，是并行检索代理的“引擎”
sub_question_rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | generator_prompt
    | llm
    | StrOutputParser()
)

def retrieval_agent_node(state: MultiHopRAGState):
    """节点 2：为每个子问题并行运行完整 RAG 进程"""
    print(f"--- [Retrieval Agents] Answering {len(state['sub_questions'])} sub-questions in parallel... ---")
    
    answers = {}
    # 用 ThreadPoolExecutor 对每个子问题并发运行‘sub_question_rag_chain’
    with ThreadPoolExecutor(max_workers=len(state['sub_questions'])) as executor:
        # 为每个待回答子问题构建一个 future
        future_to_question = {executor.submit(sub_question_rag_chain.invoke, q): q for q in state['sub_questions']}
        for future in as_completed(future_to_question):
            question = future_to_question[future]
            try:
                answer = future.result()
                answers[question] = answer
                print(f"  - Answer found for sub-question: '{question}'")
            except Exception as e:
                answers[question] = f"Error answering question: {e}"
    # 将结果收集到“sub_question_answers”字典中
    return {"sub_question_answers": answers}

retrieval_agent_node 是系统中的分散-聚合核心，接收 sub_questions 列表，并用 ThreadPoolExecutor 将每个条目分配到各自独立的 RAG 链。这是一种强大的并行形式，同时运行多个完整 RAG 流程。在所有并行代理找到答案后，该节点将所有发现汇总到 sub_question_answers 字典中。

最后，“合成器”节点作为元代理的最终步骤，将并行发现整合为一个连贯的答案。

# 节点 3：合成器（元代理的最后一步）
synthesizer_prompt = ChatPromptTemplate.from_template(
    "You are a synthesis expert. Your job is to combine the answers to several sub-questions into a single, cohesive, and comprehensive answer to the user's original complex question.\n\n"
    "Original Question: {original_question}\n\n"
    "Sub-Question Answers:\n{sub_question_answers}"
)

synthesizer_chain = synthesizer_prompt | llm | StrOutputParser()

def synthesizer_node(state: MultiHopRAGState):
    """获取子问题的答案，并合成最终的全面答案"""
    print("--- [Meta-Agent] Synthesizing final answer... ---")
    
    # 将收集的子问题答案格式化为最终提示
    sub_answers_str = "\n".join([f"- Q: {q}\n- A: {a}" for q, a in state['sub_question_answers'].items()])
    
    final_answer = synthesizer_chain.invoke({
        "original_question": state['original_question'],
        "sub_question_answers": sub_answers_str
    })
    return {"final_answer": final_answer}

synthesizer_node 是至关重要的最终推理步骤，它本身不执行任何检索，任务是接收 sub_question_answers 中的预处理事实，并将其构造为能直接回应用户原始复杂查询的连贯叙述。

最后按线性顺序组装图：分解 -> 并行检索 -> 综合。

from langgraph.graph import StateGraph, END

workflow = StateGraph(MultiHopRAGState)
workflow.add_node("decompose", decomposer_node)
workflow.add_node("retrieve_in_parallel", retrieval_agent_node)
workflow.add_node("synthesize", synthesizer_node)

workflow.set_entry_point("decompose")

workflow.add_edge("decompose", "retrieve_in_parallel")
workflow.add_edge("retrieve_in_parallel", "synthesize")
workflow.add_edge("synthesize", END)
multi_hop_rag_app = workflow.compile()

并行多跳检索

给两个系统一个复杂且需要比较的问题，这个问题无法通过单次检索调用正确回答，从而对比分析两种查询方式。

# 查询需要比较两个产品，信息在独立、不重叠的文档中
user_query = "Compare the QLeap-V4 and the Eco-AI-M2, focusing on their target use case and power consumption."

# --- 执行简单 RAG ---
print("="*60)
print("                  SIMPLE RAG SYSTEM OUTPUT")
print("="*60 + "\n")
print(f"Final Answer:\n{simple_answer}")

# --- 执行多跳 RAG ---
print("\n" + "="*60)
print("                 MULTI-HOP RAG SYSTEM OUTPUT")
print("="*60 + "\n")
print("--- Sub-Question Answers ---")
for i, (q, a) in enumerate(multi_hop_result['sub_question_answers'].items()):
    print(f"{i+1}. Q: {q}\n   A: {a}")
print("\n--- Final Synthesized Answer ---")
print(multi_hop_result['final_answer'])

# --- 最终分析 ---
print("\n" + "="*60)
print("                     ACCURACY & QUALITY ANALYSIS")
print("="*60 + "\n")
print("**Simple RAG Performance:**")
print("- Result: COMPLETE FAILURE.")
print("- Reason: The user's query contained terms for both products. Vector search found the documents that were, on average, most semantically similar to the entire query, retrieving only documents about the Eco-AI-M2. It completely failed to retrieve any information about the QLeap-V4. Without the necessary context for both products, a comparison was impossible.\n")
print("**Multi-Hop RAG Performance:**")
print("- Result: COMPLETE SUCCESS.")
print("- Reason: The system's intelligence was in the initial decomposition step. The Meta-Agent broke the complex comparative query into two simple, focused sub-questions: 1. Get info on Product A. and 2. Get info on Product B. The parallel Retrieval Agents had no trouble answering these simple questions, each retrieving the correct, focused context. The final Synthesizer agent then received a perfect, complete set of facts about both products, making the final comparison trivial.")

输出为……

#### 输出 ####
============================================================
                  SIMPLE RAG SYSTEM OUTPUT
============================================================

Final Answer:
Based on the provided context, the Eco-AI-M2 chip is designed for edge computing and mobile devices, with a primary feature of low power consumption at only 15W under full load. The context does not contain information about the QLeap-V4, so I cannot provide a comparison.

============================================================
                 MULTI-HOP RAG SYSTEM OUTPUT
============================================================
--- Sub-Question Answers ---
1. Q: What is the target use case and power consumption of the QLeap-V4?
   A: The QLeap-V4 processor is designed for maximum performance in data centers, with a primary use case of large-scale AI model training. It consumes 1200W of power under full load.
2. Q: What is the target use case and power consumption of the Eco-AI-M2?
   A: The Eco-AI-M2 chip is designed for edge computing and mobile devices like drones and smart cameras. Its key feature is low power consumption, drawing only 15W under full load.
--- Final Synthesized Answer ---
The QLeap-V4 and the Eco-AI-M2 are designed for very different purposes, primarily distinguished by their target use case and power consumption.
-   **QLeap-V4**: This is a high-performance processor intended for data centers. Its main use case is large-scale AI model training, and it has a high power consumption of 1200W.
-   **Eco-AI-M2**: This is a low-power chip designed for edge computing and mobile devices. Its focus is on energy efficiency, consuming only 15W, making it suitable for applications like drones and smart cameras.

最终分析得出明确结论，性能差异并非渐进式，而是一次能力上的飞跃。

  • 单次检索步骤无法解决比较查询歧义，仅检索了两个产品中的一个上下文，从根本上无法收集必要的证据。
  • 多跳系统之所以成功，是因为没有试图一次性回答复杂问题，而是识别了查询的比较性质，并将问题分解。
  • 通过并行、专注的 RAG 代理来解决每个简单的子问题，确保收集了所有必要证据，最后的综合步骤只是简单的将预先处理的事实结合起来。
Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com，一起交流成长。

本文由mdnice多平台发布