砍掉自研 AI 智能体后，Runnit 转向单一智能架构

近期，AI 产品团队 Runnit 在一篇工程复盘文中披露，他们在过去几个月里陆续砍掉了自家产品中已经搭好的多个 AI 智能体，把底层架构切换成「单一智能、按需加载能力」的形态。这一变化并非源于产品方向调整，而是团队在更长上下文窗口的新一代大模型上反复测试后做出的工程取舍。

从专用智能体起步

Runnit 的最初架构建立在彼时主流大模型的基础上：当时的模型上下文窗口多在 64k 至 128k 之间，单次对话能容纳的信息量有限。要让输出质量达到「勉强可用」的水平，团队不得不把工作拆给多个专用智能体，由它们分别负责规划、调研、排期、写作等任务。

• 每个智能体都配有独立提示词与行为规则，只处理自己那一类问题。
• 上下文被切分后，单个智能体在可用窗口内更容易给出相对准确的回答。
• 团队一度认为，这是当时模型能力下最合理的架构。

新模型让拆分变得不再必要

随着上下文窗口更大的模型上线，Runnit 团队开始在新模型上做对照测试。结果显示，同一个对话窗口内，模型已经能在规划、写作、调研、推理之间自然切换，不再需要为每类任务另设一个独立的「专家」系统。

团队因此提出一个直接的问题：这些职责，真的还要由独立智能体来承担吗？答案是「不需要」。于是他们逐一删除了既有的多智能体，把产品核心替换为一个名为 Ru 的单一智能主体，根据任务需要动态加载能力。

单一智能带来的工程收益

架构收敛后，Runnit 列举了几项明显的工程收益：

• 整个系统对业务只有「一份理解」，不再需要在多个智能体之间同步状态。
• 只有一个对话流、一份记忆、一个组织知识的落地点，调试和迭代都更直接。
• 需要并行处理时，单一智能可以复制出多个实例各自加载所需指令，再把结果汇总，对外仍表现为并行协作。
• 不必再维护数十条分散的提示词，也不再担心不同智能体在持续迭代中逐渐「漂移」。

多智能体并未被全盘否定

Runnit 同时强调，砍掉自家智能体并不意味着专用架构整体过时。在需要隔离任务、使用不同模型、或区分权限的场景下，专用智能体仍然有价值。他们真正想提醒同行的，是行业里不少仍在沿用的架构决策，最初是为更早一代、更短上下文的模型设计的。

用他们自己的话说：如果今天重做 Runnit，开局要问的问题不再是「应该搭建哪些智能体」，而是「一个单一智能需要具备哪些能力」。有时候，技术进步带来的不一定是叠加新层，而是意识到某一层已经可以拿掉。