AI Agent 的未来：聊天框之外的多 Agent 协作

Fri, 31 Jul 2026 12:00:00 +0800

探索 Agent，就必须看到当前 Agent"长"什么样，考虑 AI Agent 的 UI 展示是否限制了什么。

当前 Agent 的通用做法

用户输入一个 Prompt，做好了 Harness 的 Agent 加载 Skill、Prompt、Memory、Tool-config 给 AI LLM，然后由 LLM 处理：ReAct、Plan and Execute、Loop Engineering、申请权限、Tool-Calling。

对于这种黑箱操作，各家方案不同：

普遍采用的 Skills：让 Agent 反问用户，总结生成更详细的 Prompt，以便 LLM 生成更个性化、贴近用户想象的结果
Hermes 的 MOA：多 Agent 协同——两个参考模型，一个负责发散，一个负责"准确"，一个统筹模型，负责在用户 Agent 端保存的"记忆"、Skills、Prompt、tool-config、上下文……范围内做比对、择优。最后主 Agent 负责编排与干活
Codex 的方案：同样提供 MOA 模式。Ultra 模式下，主模型负责任务拆解与编排，sub-Agent 负责干活、测试、审计，并且是并行计算。这得益于 OpenAI 对模型端到端的控制
KIMI 的 Agent 集群：同样在模型接收侧调度主 Agent 进行分析、推理与调度，子 Agent 的数据互相隔离，即刻进入 GPU 集群计算，即刻返回主 Agent 循环反馈、读写 KV……

Codex、KIMI 都是在模型侧实现了上下文极大的利用率，天生就比 Hermes MOA 的资源利用率高。

从这个角度看，MOA 也应该做到：主模型分析后，拆解任务给多个 Agent 调度；子 Agent 只吃自己那部分 Skills、Tool-config、记忆，只做自己那部分工作、只交付自己的工作内容，循环与主 Agent 交互，实现最终结果。

聊天框/瀑布流 Agent 是否框死了 Agent 的上限？

输入框是必要的，但是仅仅提供输入框交互是不够的。

人的要求是很多又模糊的。AI 在做设计时，单个聊天框的瀑布式输入输出容易造成上下文臃肿，所以 Codex / KIMI 的 MOA 是对的：在端侧设计多个子 Agent、并行计算，减少一个聊天框内的上下文在单个 Agent 内部的循环，减少幻觉、遗忘、减少 KV Miss，提高输出效率。

但是 MOA 在展示能力上仍然有优化空间：非常依赖主 Agent 的调度与设计。

主 Agent 的设计除了要看模型，还要看 Agent Harness。在 Agent Harness 方面，控制子 Agent 的能力也很重要：主 Agent 与子 Agent 的调度、安排之间应该加一道可操作控件。也就是说在瀑布式聊天之外，加一道 Agent 展示与协调窗口，用以实时控制子 Agent 的表现。

问题是 Codex / KIMI 在做的事情是不断提升 LLM 能力与 Agent 调度表现：Codex 实现了端侧 6 个 Agent 协同并行计算，KIMI 则最多可以做到 4000 个 Agent。这样就很挑战在用户侧实现 Agent 工作可视化的操作。

而 Claude Code 除了有自己的 Agent 设计，额外采取的做法是在 Agent 运行时，可以随时追加用户观察 + 及时反馈，也就是 Mid-Stream Interrupt 流式中途注入架构，配套三大核心模块：会话状态机、异步消息队列、带断点的 KV 缓存快照。这是 Claude Code 为用户侧与模型侧共同设计打造的产品设计。

企业视角：绑定 LLM 的 SaaS 之痛

Codex、KIMI、Claude Code 的 Agent 设计与模型、客户端深度绑定、多侧协同，发挥自身最大价值。

对于企业而言，这些软件的目标应该是成长为一种新的 SaaS，成为企业与个人的长久需求。但与 SaaS 不同的是，这些软件绑定自家 LLM，对企业而言最大的痛点就是数据外泄、模型 API 成本与收益问题，这几乎无法避免。

当然，企业自己追求部署最先进 AI 永远没有必要：

企业的业务并不是随着 AI 版本更新的
硬件成本很难做到与时俱进——模型更新速度一年两次大版本，企业过分追求 AI 是本末倒置
AI 人力成本没必要：企业需要的是专职员工，为了使用独立大模型就成立一个模型部署与优化部门，实在没必要；懂 AI 的数据管理部门可能更重要

该如何做数据保护、数据脱敏、断网使用、摆脱单个模型依赖——未来无论是哪一家模型胜出，都不影响自身业务价值，这才最重要。

知识属于全人类

同时，这样的一个 Agent 要绑定普罗大众，就必须要做最通用、使用成本最低、效益最高、能够满足模型爆发、还能匹配模型能力的设计。

生物的本能是传播基因，那么这样的 Agent 也应该能够"传播基因"，并且是像变色龙一样地传播——适配不同环境，如币圈的去中心化。我将之称为：知识属于全人类。

LLM 是黑箱，Agent 不应该是。所以多 Agent 的操作流程，第一个特征就应该打破聊天式交互逻辑——在 LLM 动辄百万文本输入输出、代码脚本等用户无法耐心阅读的情况下，呈现出更直观的 Agent 运行状态。

有一个值得关注的问题是：在未来，LLM API 会不会开放多 Agent 给 API 用户？也就是说多 Agent 的操作对用户仍然不可见，这可能也会成为趋势。看起来是开放的——KIMI 的 K2.6 等版本已经向 API Key 使用者开放了多 Agent 能力。

Agent 的知识破圈价值

如果想做知识平权，Agent 还应该担任起知识破圈的能力。

众所周知，语言的边界就是知识/思想/经验的边界。用户的语言如果被知识、经验束缚，就不可能得到想象中的结果。LLM 对于人而言，始终都还是知识 + 经验 + LLM 才能发挥最大作用，但往往 LLM 的上限被压制了。

所以，Agent 最大的价值就是打破这种语言束缚，提供更多可能。

当然，多可能并不意味着就好，多可能还可能意味着噪音，这不符合效率直觉：如果 LLM 引入的噪声太多，不如直接请人来做。

所以，Agent 的价值还要框定在：比人做得好、做得快、做得准确、做得毫无保留、符合人性直觉。

看起来，这既要符合人的经验要求，又要反人性：反人性中懒惰、疲倦、模糊、隐瞒、上下文管理问题、信息差问题……还得服从性拉满，而不是潦草敷衍。这涉及到 loop engineering：多轮催促 AI LLM 输出更多的知识，类似于老板把一个人当做几个人用的同时，还要让他们去读研、读博、评院士——并且除了多付出 token 资源，无需操心理解偏移、遗忘上下文等问题。

Agent 的显著职责

Agent 的显著职责是帮助人类解放双手，和部分脑子。人类需要可靠的 AI 帮助自己做：

需要大量投入、学习、知识，才能做的专项工作：比如写代码、做财务报表、医疗诊断/影像分析、设计师
一旦熟悉就有固定流程的工作：比如数据分析、财务报表、人事工作、教师
信息差、黑箱、不能用显性知识描述的经验性工作：涉及业务人员认知的内容；需要审核，但不特指容易产生技术性瑕疵的工作内容，比如财务分析师、市场分析师、咨询师——往往涉及信息差、解读角度的技巧性、经验性、挑战性内容

这些能力，最好由专职工作人员在使用 Agent 做过一次专项工作、由用户"签收"之后，迅速沉淀为 Agent 的个人知识、经验，形成 Agent 随用户自主进化的内容。该内容是可以闭环的：

与 LLM 交互的过程交给 Harness 框架把控
但 Agent 的工作过程应该可视化，尤其是多 Agent：除了受到主 Agent 调配，还能够配合用户调度
所做的工作结果是完全可视化的、可解读的、可形成固定资产的
Bad Case 是可以调优的

这样，Agent 的一切都是可解释的、可评测的，不需要用户的事前 + 事后管理，而是高度契合事中管理的需要。

最有价值的三个方向

这里面的内容，最具有价值的是：

数据脱敏 engineering：让企业敢用、数据不出界
经验沉淀 engineering：解决幻觉、上下文压缩、任务拆解逻辑、工具调用、用户选择
Agent 过程可视化与可独立交互化的框架设计：
- 如何打断主 Agent？ 显然，打断主 Agent 会打断所有 Agent 的流程，即使它们指向的是不同的模型。所以根据现状——所有 MOA 都只具有一个 Agent 通道——就应该在主 Agent 上下功夫
- 如何打断某个子 Agent？ 看起来，应该设计一个"用户 : 主 Agent : 多个子 Agent"的结构：用户与主 Agent 交互，主 Agent 控制子 Agent。这样更符合用户一直与 Agent 交互的逻辑，但不污染主 Agent 与子 Agent 的交互通道
- 而且应该有灵活的 Agent 调度功能：当主 Agent 决定调用多个子 Agent 时，就有相应的窗口开启，允许用户查看、交互。当然，第一层永远是主 Agent——也就是说主 Agent 有 Claude Code 的 Mid-Stream Interrupt 流式中途注入架构的设计，且比它更清晰：控制主 Agent 还是子 Agent，可能更具可解释性，在事中控制的价值上更具有发言权，降低 Bad Case 发生，更符合事中控制直觉

You Speak It, And We Do It!

5W2H 与主-多 Agent 设计灵感

任何一个任务都可以用 5W2H 拆解：

What：做什么，事项、目标、内容、产出物
Why：为什么做，目的、价值、动机、必要性
Who：谁来做/面向谁，负责人、参与人、服务对象
When：何时，起止时间、阶段时间、排期
Where：在哪里，执行场地、环境、线上/线下渠道
How：怎么做，流程、方法、工具、操作步骤
How much：成本、数量、预算、标准

语言是知识/思想的边界。由此给出的设计灵感：多 LLM Agent + 工作窗口。

你与一个主 LLM Agent 交流，此主 LLM Agent 负责设计世界观，具体的实现交给其他子 LLM Agent。

WHY：现阶段主 LLM Agent 与多 LLM Agent 的矛盾之处在于——单个模型上下文过长，既要做规划、又要做任务、又要做 debug……loop engineering 做的就是解决这个问题，但仍然是压榨同一个模型/LLM Agent 的同一个 temperature。

主-多 LLM Agent 要做的是满足用户的"创世者思维"：针对用户的问题提出主要矛盾，由子 LLM Agent 负责根据局部矛盾行事。这么做的价值是开阔思维与思路，保证主 LLM Agent 思路的一致性——即使用户随时修改主旨、意见，主 LLM Agent 仍然能够顾全大局，及时发现问题与方案，螺旋上升。

解决的是主体矛盾与局部矛盾的问题：所谓"众人拾柴火焰高"，而不是"左右脑互搏"“左脚踩右脚”。

矛盾点：是否存在过度设计？显然，这需要主 Agent 与子 Agent 在 loop communication 中实现更佳方案，实时输出、与用户交互。用户-主 Agent-子 Agent 的多窗口设计，保证用户的幻想哲学得到主 Agent 的把控与落地，子 Agent 实现。

多 Agent 做得好不好，需要经过测量——窗口可视化、可修改就实现了实时监测。如此设计是为了应对用户随意修改主体/局部的议题：实时更新主旨、修改局部/保护局部设置。

结尾：可视化的 WHY

Agent 的思路与工作的可视化，设计思路还在于：

企业追求投入产出比。AI 的提升能力如果不可以被描述、测量、直观感受，数据如果不可以被保护，企业会认为这是 Bad 设计——除非盈利显著到接受这种黑箱。

MOA on WitMinder