别被名词骗了：别再纠结应该单 Agent 还是多 Agent？底层全是多Session？

国庆节身体放假，学习脚步不停歇。

在讨论Agent工程开发时，你一定经常听到这类讨论：“这个任务单 Agent 搞不定，得换 Multi-Agent（多智能体）架构！”

听起来很高级，仿佛后台住着好几个各有神通的 AI 机器人。但如果扒开所谓的 Multi-Agent / Sub-Agent 架构的底裤，你会发现——根本没有什么“多智能体”，底层其实全都是“多 Session（会话）管理”。

理解了这个本质，你在做 AI 工程选型时就不会被繁复的名词忽悠。

1. 最根本的物理事实：LLM 是无状态的

要搞懂这一点，首先得承认一个大模型最底层的物理事实：

大模型本身就是一个无状态的数学函数。输入一段 Prompt（系统提示词 + 对话历史 + 工具参数），它给你吐出一个响应（回复）。

它没有运行时的动态内存，也没有独立运行的“灵魂进程”。每一次你发起 API 请求，对模型来说都是一次全新的“单次计算”。

既然底层模型只是一个无状态的入口，那所谓的Agent 实体在物理上根本不存在。

• 你以为的单 Agent：一个 messages 数组（一个 会话Session）装下所有对话，一直在里面追加聊天内容。
• 你以为的多 Agent：代码层在后台帮你开了多个独立的 messages 数组（多个 Session），把 Session A 的输出，用 Python 字符串拼接后，丢给 Session B 当输入。

2. 所谓 Multi-Agent，到底在隔离什么？

既然物理底层全是多 Session，那为什么大家还要提 Multi-Agent 这个概念？

因为这并不是一种算法突破，而是一套针对 LLM 无状态特性提炼出的“工程资源隔离模式”。

当你在一个 Session（单 Agent）里硬扛复杂任务时，模型会很快崩溃。把任务拆成多个 Session 协同执行，真正解决的是以下 3 个致命问题：

   
      
      
      
      
      
    
          
复杂任务 ──► 主控代码 (路由/状态机)
      
                   │
      
                   ├──► 干净 Session A (架构师) ── Prompt 专一 | 上下文极简 | 0 工具
      
                   │
      
                   └──► 干净 Session B (单元测试员工) ── Prompt 专一 | 上下文极简 | 只给 2 个特定 Tool
    
  

① 上下文隔离（Context Isolation）

LLM 虽然有 200k 甚至 1M 的上下文窗口，但东西填得越多，模型的注意力越涣散。

• 单 Session 坏处：改代码、跑报错、查文档全部塞在一个会话里，第 10 轮时模型就忘了最开始要干啥。
• 多 Session 优势：子任务干完只向主 Session 汇报一句“重构完毕，最终修改了文件 X”，让主 Session 的上下文永远保持干净。

② 系统提示词隔离（System Prompt Isolation）

• 一个既要当“规划师”、又要当“写码员”、还要当“测试员”的通用 Prompt，往往哪样都干不好。
• 拆成多个 Session 后，每个 Session 拥有极其狭窄且精准的人设（比如 Session B 只负责读 pytest 日志），思考专注度大幅提升。

③ 工具集隔离（Tool Selection Isolation）

• 如果你一口气把 50 个 API 工具暴露给同一个 Session，模型选错 API 或填错参数的概率会呈指数级飙升。
• 拆成多个 Session 后，每个 Session 只暴露 2~3 个专属 API。限制了它的选择，也就规避了它的犯错率。

3. 一句话透视本质

多Agent 只是一个工程设计名词，它的本质公式是： 独立的 Session + 专职 Prompt + 收敛窄范围的 Tools} + 代码层调度

底层并没有什么多 Agent，全部都是通过代码调度多个独立 Session，以及对 Context、Prompt 和 Tools 进行资源切片与隔离。

概念名词一点都不重要。做 AI 工程架构时，不要纠结“我用的是单 Agent 还是多 Agent”，你只需要问自己一件事：“我的任务，需要怎样拆成不同的干净 Session，才能让 LLM 不犯糊涂？”

此篇文章已被阅读4 次