AI 与工程 on WitMinder

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 设计——除非盈利显著到接受这种黑箱。

LLM 推理全链路：从提问文本到输出 Token

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

LLM 用户提问的完整流程：文本 → Embedding → 模型计算 → 输出。这篇文章拆开每一步，并补充工程与硬件层面的细节。

极简流程

1用户提问文本
2→ Tokenizer → token ids
3→ 查表得到 FP16/BF16 高维 Token Embedding 向量 + 位置编码
4→ CPU → GPU 显存 → 送入 SM 计算单元循环多层 Decoder
5→ 输出隐藏特征向量 → LM Head 映射为词表概率 logits
6→ 采样选出 token，循环自回归生成
7→ token 序列解码 → 可读文字输出

一、你的提问会被转换成什么向量（Embedding）

这里有两套完全不同的向量，不要混淆：输入 Token Embedding（LLM 原生）、检索 Embedding（RAG 配套）。

1. LLM 原生输入向量（推理必走，每轮对话都有）

1）先分词（Tokenizer）

你的句子切为 token id（数字，如你=123，好=456）。

2）Token Embedding 层（模型第一层权重矩阵）

矩阵尺寸：[词表大小 V, 隐藏维度 d_model]
举例常见模型：
- LLaMA2 / Qwen：d_model=4096 / 8192，向量是 FP16/BF16（极少 FP32）
- 小参数量开源模型：d_model=768 / 1024 / 2048
每个 token id 查表取出一行，得到 d_model 维浮点数向量
向量含义：语言语义；位置信息会叠加位置编码（RoPE/ALiBi）

重点：这不是检索向量，是 Transformer 底层特征向量，维度极高（4k+），不用于向量库检索。

2. RAG 检索用 Embedding（只有知识库场景才会生成）

如果带文档检索，你的提问会单独丢给专用 Embedding 模型（bge、e5、all-MiniLM）：

维度低：384 / 768 维
存储格式：FP16 / INT8 / INT4 量化压缩
用途：去向量库做相似度匹配召回文档，不进大 LLM 主 Transformer 计算

3. 存储精度

线上推理几乎全部：

Token Embedding：BF16 / FP16（显存减半，速度翻倍）
只有训练、高精度微调才用 FP32

二、向量如何进入模型计算区域（GPU/显存流转全过程）

阶段 1：CPU 预处理

用户文字 → token ids（CPU 内存）
查表取出 embedding 向量、叠加位置编码（CPU 或 GPU）
组装输入张量：[batch_size, seq_len, d_model]
- 比如单条提问长度 2048 token，d_model=4096 → 张量 shape [1, 2048, 4096]

阶段 2：数据搬运进 GPU 计算区

CPU 内存张量通过 PCIe 拷贝到 GPU 显存（Global Memory）
推理框架（vLLM / TensorRT / Transformers）做内存优化：
- 连续内存排布、padding 合并、KV 缓存预分配
计算调度：
- 显存向量分批送入 SM 流多处理器（计算核心）
- 向量数据先缓存到 L2 Cache → 片上共享内存/寄存器（高速计算区）

核心：真正矩阵乘法（Attention、FFN）全部在 GPU 寄存器/片上缓存完成，显存只做存储交换。

阶段 3：Transformer 多层循环计算（核心区域）

输入向量逐层穿过 N 层 Decoder：

多头 Self-Attention：输入向量 × Q/K/V 权重矩阵 → 注意力分数 → 加权融合特征向量
FFN 前馈网络：特征升维映射、激活、降维回原维度
LayerNorm、残差连接：每层输出依然是同维度 [seq_len, d_model] 向量，逐层更新语义特征

关键缓存：KV Cache（生成必备）

每轮提问的 key/value 向量会存入显存 KV 缓存，后续生成新 token 不用重复计算历史输入，大幅提速。

三、模型如何输出文字（向量 → 可读文本）

步骤 1：最后一层输出隐藏向量

Decoder 最后一层输出依旧是 [seq_len, d_model] 高维特征向量。

步骤 2：LM Head 线性投影（关键输出层）

权重矩阵 [d_model, V 词表大小]，做矩阵乘法：高维语义向量 → 长度等于词表 V 的 logits 向量（几万维）。例：Qwen 词表 151936，logits 维度=151936。

步骤 3：采样生成单个 token

logits 做 Softmax，转为每个 token 的概率分布
根据采样策略（greedy / top-p / top-k）选出概率最高的 token id
把这个 token id 追加到输入序列，重新走一轮前向计算（自回归生成）

步骤 4：循环直到终止

不断生成新 token，直到产出终止符 </s>，停止迭代。

步骤 5：解码输出文本

收集所有生成的 token id，送入 Tokenizer 反向解码，转回自然语言，返回给用户。

四、完整九步链路（含工程与硬件细节）

1. 用户提问文本输入

用户原始自然语言（中文/英文混合），包含空格、标点、特殊符号。额外前置操作：

预处理清洗：剔除不可见控制字符、统一换行/空格格式、截断超长文本（不超过模型上下文窗口上限，如 8k / 32k tokens）
拼接完整 Prompt：系统提示词 + 历史对话上下文 + 当前用户 Query

2. Tokenizer 分词编码 → 得到 Token IDs

使用模型配套 BPE / SentencePiece 分词器处理完整 Prompt：

按训练时的词表规则切分为最小子词单元（token），中文会单字/词语混合拆分
映射每个 token 为唯一整数 Token ID
补充特殊标记：句首 <bos>、句尾 <eos>、填充 <pad>，生成一维 ID 数组
输出 CPU 内存上的 [batch, seq_len] 整型张量（batch=1 单轮对话）

3. 查表获取 Token Embedding + 叠加位置编码

两者均为模型内置权重矩阵，常驻 CPU，推理时拷贝至 GPU 显存：

Embedding 查表：权重矩阵 shape [词表总量, 隐藏层维度]（例如 152k × 4096）；根据所有 Token ID 索引矩阵对应行，取出每个 token 的 FP16/BF16 高维向量，得到张量 [1, seq_len, hidden_dim]
位置编码融合：LLM 无法感知文字顺序，预计算正弦余弦/可学习位置向量，shape 与 Embedding 完全一致；向量逐元素相加融合，携带时序位置信息
此时得到完整输入特征张量，仍存在 CPU 内存

4. CPU 张量拷贝至 GPU 全局显存

执行 CUDA 内存拷贝（cudaMemcpy），将融合后的 Embedding 张量从主机内存搬运至显卡全局显存
配套分配显存空间：提前预分配 KV Cache 缓存区（Decoder 推理核心，存储每一层历史注意力 key/value 向量，大幅减少重复计算）
同步 CPU/GPU 指令流，等待拷贝完成后才启动计算

5. 调度张量送入 GPU SM，循环执行多层 Decoder

一张 NVIDIA GPU 由数十个 SM 并行组成，调度器分片分发张量至所有 SM 协同计算：

单块 SM 内部硬件：CUDA Core（通用浮点运算）、Tensor Core（AI 矩阵乘法专用加速单元，LLM 核心算力）、片上高速 Shared Memory
逐层循环执行 N 层 Decoder（如 32 层、40 层），每层固定流程：
- 多头自注意力：读取 KV Cache，计算 Query-Key 相似度，Softmax 归一化权重，加权融合 Value 向量
- FFN 前馈网络：高维向量升维、激活函数、降维
- 残差连接 + 层归一化 LN
中间计算数据优先存放 SM 片上 Shared Memory（读写速度远高于全局显存），仅中间结果写回显存更新 KV Cache
全部层计算完成，输出序列末尾的隐藏特征向量（自回归仅取最后一个 token 特征用于预测下一词）

6. LM Head 线性层映射，输出词表概率 Logits

LM Head 是一个线性权重矩阵，存储在 GPU 显存：

输入：单层 Decoder 输出的末尾隐藏向量 [1, hidden_dim]
矩阵乘法映射至词表维度，输出 [1, vocab_size] 的原始得分 Logits
可选预处理：对 Logits 做温度缩放、Top-P / Top-K 截断，屏蔽 <pad> 等无效 token 得分

7. 采样算法选出单个新 Token ID（自回归核心循环）

对 Logits 概率分布采样，两种主流方案：

贪心采样：直接取分数最高的 token
随机采样（TopP / TopK）：筛选高分 token 后随机选取，回答更有创造性

输出单个整数 Token ID。

8. 循环推理（关键：迭代生成整段回复）

将刚生成的 Token ID 追加到原始输入序列尾部
仅对新增的 1 个 token 重复步骤 3~7（复用历史 KV Cache，不用重新计算整段上下文，大幅提速）
循环迭代，直到采样出 <eos> 终止标记，停止生成

9. Token ID 序列解码 → 可读自然文字

收集全部生成的 Token ID 序列，送入 Tokenizer 反向解码逻辑
根据词表映射 ID 还原子词，拼接合并为完整句子
自动清理分词产生的特殊分隔符、空白冗余字符，输出人类可读回答

五、容易被混淆的区分

LLM 内部 Token Embedding：维度极高（4096+）、FP16/BF16，只给 Transformer 计算，不存向量库
RAG 检索 Embedding：低维（384/768），专门相似度计算，不进大模型主干
内存占用举例（2048 上下文，d_model=4096，FP16）：单条输入向量 1 × 2048 × 4096 × 2B = 16,777,216 B = 16MB，换成 FP32 直接翻倍 32MB

关键工程点

KV Cache：Decoder 自回归推理性能的核心——没有它每一轮都要重算全部上下文，速度暴跌几十倍
硬件分层差异：全局显存（低速，存全部权重/KV 缓存）→ SM 共享内存（高速，临时计算），向量读写存在明显的层级速度差距
精度细节：BF16 多用于模型权重存储，FP16 多用于中间计算，两者算力、数值范围有区分
Batch 逻辑：多用户并发时会批量拼接多个 Prompt 送入 GPU，单轮对话 batch=1
计算与 IO 阻塞：CPU-GPU 数据拷贝会占用耗时，大维度向量（如 4096 维）传输开销不可忽略