当 Agent 做到一定复杂度，问题往往不在模型能力本身，而在上下文怎么给、工具怎么给、流程怎么控。同一套模型，有的团队能把它用成「能稳定交付的执行系统」，有的团队只能得到「偶尔灵光一现的聊天机器人」，差距就在架构。

早期提示词工程里，上下文基本是静态的：一次性把提示词写好，然后让 LLM 自己发挥。随着架构的演化，，上下文变成动态的，它会「收」和「放」：

收（Contract）：渐进式披露。屏蔽无关信息，减少 Token 消耗，聚焦注意力。（解决“准确性”）
放（Expand）：动态注入。根据交互状态，主动引入外部话题、记忆片段或世界观设定。（解决“丰富性”与“持续性”）

这是一种系统架构策略：用有限 Token 去管理无限信息，用非确定性模型去执行标准化流程。

1. 三个典型瓶颈：Context、工具、SOP

复杂 Agent 基本都会遇到三个主要的问题：

1. 上下文爆炸（Context Explosion）
   文档、代码、历史对话、用户画像、任务状态……你不可能全塞进 Prompt。硬塞进去也会出现“Lost in the Middle”，关键信息被淹没。

2. 工具过载（Tool Overload）
   工具越多，定义越长，Token 越贵；更严重的问题是：工具选项越多，模型选择正确工具的概率越低，尤其是多个工具功能相近时。

3. 执行不可控
   当我们希望它按 SOP 做事（先检查、再验证、最后提交），它却容易跳步、漏步，或者为了“把话说圆”而瞎编执行结果。

「渐进式披露 + 动态上下文管理」就是对这三件事的统一解法：不要一次把世界交给模型，而是让模型在每一步只看到它此刻需要看到的东西。

2. 渐进式披露

渐进式披露不是少给信息，是分阶段给信息

有人把渐进式披露理解成省 Token。省 Token 是结果，不是核心。

核心是：把一次性的大上下文，拆成多轮的决策—反馈—再决策。每一步只给与当前决策相关的最小信息面，减少噪音，让模型的注意力更集中，也让系统更可控。

一个直观的工程化表述：

• 不是构建一个「全量 Context」
• 而是维护一个「可增长的 Context」，并且增长受控

你会看到两个动作交替出现：

• Contract（收缩）：隐藏、裁剪、摘要、替换为索引
• Expand（扩张）：按需加载片段、工具子集、记忆、世界观、流程状态

3. 数据层

传统做法，使用 RAG 很容易走向粗暴：检索到的内容直接拼进 Prompt，能拼多少拼多少（可以配置）。结果通常是两种：

• Token 变贵，延迟变长
• 模型注意力被稀释，反而更不准

渐进式披露在数据层的落地方式，是把「获取信息」做成连续的动作序列，而不是一次性拉满。

参考 AI Conding 很贴近工程实际的步骤：

• 初始 Prompt 只有任务描述
• AI 发现信息不足，发起 ls 或 grep 请求
• 系统只返回 ls 的结果（文件名列表），而不是文件内容
• AI 选中目标，发起 read_file
• 系统这时才披露文件内容

这里关键点不是 ls/grep/read_file 这些名字，而是信息披露粒度：

• 先给目录/索引（低成本，低噪音）
• 再给片段（命中后才扩大）
• 最后给全文（只在确认需要时才给）

3.1 披露层级建议：L0 到 L3

可以把上下文分成几层，这里定义的层级不是标准答案，但思路是这么个思路：

• L0：任务和约束
  用户需求、输出格式、禁止事项、成功标准。L0 必须稳定，尽量短，长期驻留。

• L1：证据索引
  文件列表、章节目录、数据库表名、日志摘要、搜索结果标题。只给“在哪里”。

• L2：证据片段
  命中的段落、代码片段、表结构、关键日志区间。只给“相关部分”。

• L3：证据全量
  全文档、完整文件、长对话历史。尽量少用，只在确实需要通读时开放。

系统要做的事是：让模型先用 L1 做定位，再用 L2 做判断，最后才允许 L3 进场。这样不仅省 Token，还可以减少模型在噪音里自我发挥的空间。

3.2 动态注入

动态注入常见误区：用户问 A，你检索 A；用户又问 B，你把 A+B 都塞进去；几轮后上下文就乱了，且不可控了。

比较常用的做法是引入「上下文预算」和「淘汰策略」：

• 每轮允许注入的 Token 上限（硬预算）
• 驻留区（长期有效，例如用户身份、偏好、当前任务）
• 工作区（当前步骤的证据片段）
• 冷存区（旧证据移出，保留索引或摘要）

淘汰的对象通常是“旧证据全文”，不是“任务状态”。任务状态丢了，模型就会重复问、重复做；证据全文丢了，大不了重新检索。

4. 工具层

工具越多越强这件事，在 Agent 里是反的：工具越多，模型越容易犹豫、选错，甚至编造「我已经调用了某某 工具」。

渐进式披露在工具层的做法是：分层路由，按需可见。

参考一个很实用的层级披露思路：

• Root 层只披露 5 个大类工具：代码类、文档类、部署类、数据库类、通知类
• 模型先选大类，例如“我要查数据”-> 数据库类
• 下一轮 Prompt 才披露数据库相关的具体工具，例如 sql_query, get_table_schema

我们可以把它当成「工具菜单」：

• 第一屏：只显示一级菜单
• 点进去：才显示二级菜单
• 系统控制可见性，而不是让模型在 100 个工具里裸选

4.1 工具披露带来的三个工程收益

1. Token 控制更直接
   大量工具的 schema 描述会花费大量的 Token。层级分发能把「工具定义成本」分摊到多轮，而且只在需要时支付。

2. 工具选择准确率提升
   选项少，模型更容易做对；更重要的是，减少「近义工具」同时出现。

3. 安全策略更好落地
   不该给的能力，默认不可见。你不需要在 Prompt 里反复警告“不要调用某某工具”，直接让它看不见。

4.2 「工具可见性」本质是一种权限系统

很多团队权限做在网关、做在后端鉴权，但 Agent 的权限还应该做在“可见性”上：

• 看不见：降低误用概率
• 看得见但不可用：模型会反复尝试，浪费回合
• 可用但有条件：需要把条件变成流程状态的一部分（下一节讲 SOP）

5. SOP 层

SOP 层就是当前很火热的 Skills，且不仅仅是 Skills，它是把流程写进披露逻辑，而不是写在提示词里

企业场景里，最怕的是「看似完成、实际没做」，而这在大模型的输出中很常见。让模型「请遵循 SO」”意义不大，它会漏步骤，而且它很擅长把漏掉的步骤用语言补上。

渐进式披露在 SOP 上的落地方式，是在我们的系统里做“流程锁”：上一步没通过，下一步的工具就不出现。

参考一段很清晰的流程控制（关键点直接引用）：

1. 阶段一（Lint）：系统只披露 Lint 工具和当前 Diff，隐藏 Commit 工具
2. 阶段二（Test）：Lint 返回 Success 后，系统才披露 Test 工具
3. 阶段三（Commit）：只有测试通过，系统才披露 git_commit

这套逻辑解决的是“话术不可信”的问题：模型可以说“我已经测试通过”，但系统的状态机不会因为它一句话就放行。放行只能来自可验证的工具回执。

5.1 SOP 控制要点

把「检查点」设计成机器可判定

SOP 最容易失败的地方是检查点含糊，比如“确保无问题”“确认完成”。Agent 体系里要改成：

• 有工具回执的：以回执为准
• 没有工具回执的：以人工确认或外部系统状态为准
• 不能验证的：不要当作放行条件

能自动化判定，就不要让模型自评。

6. 为什么要引入 Agent Skill

这里本质是一种是工程分层，当然也是概念包装。

很多人会问：这些用代码控制不就行了，为什么还要提 Agent Skill？

把 Skill 当成一个架构抽象，会更容易把系统做稳：它解决的是解耦、复用、状态感知。

这里把关键逻辑说透：

6.1 Skill 是「上下文的容器」，用完即走

没有 Skill 时，你往往会得到一个越来越大的系统提示词：把所有话题、所有工具、所有规则都塞进去。结果就是注意力迷失、指令冲突、Token 爆炸。

有 Skill 后，你把「某一类任务需要的提示词 + 可用工具 + 知识入口」封装到一起：

• 需要时加载
• 不需要时卸载
• 上下文保持干净

这和「渐进式披露」是同一件事：Skill 是披露的载体。

6.2 Skill 是「动态注入」的边界

动态注入真正难的是边界：注入多少、注入什么、何时撤回。

Skill 让边界清晰：

• 注入不是“往 Prompt 拼字符串”
• 注入是“激活某个 Skill”，让它把需要的最小信息面带进来

系统因此更容易做预算、做审计、做回放。

6.3 Skill 让路由变成可维护的系统，而不是靠直觉写 prompt

复杂 Agent 一定会路由：用户一句话可能触发“查资料 / 写代码 / 安抚情绪 / 改流程 / 发通知”。

Skill 体系下，路由的输出是“激活哪些 Skill”，而不是“写一段更长的提示词”。这会直接改善维护体验：

• 你能统计每个 Skill 的触发率、成功率、平均 Token
• 你能对某个 Skill 单独迭代，而不牵一发动全身
• 你能为不同用户、不同权限加载不同 Skill 组合

7. 动态上下文管理

动态上下文管理要管理「状态 + 证据 + 权限」。

把上下文当成一段文本来拼接，迟早失控。更合理的视角是：上下文是系统状态在模型侧的投影。

建议把上下文拆成四类对象，每一类有不同的生命周期：

1. 任务状态
   当前处于哪个阶段、已完成哪些检查点、下一步允许做什么。它要短、稳定、结构化，尽量每轮都带。

2. 证据
   检索片段、工具输出、外部信息。它要可引用、可追溯、可淘汰。

3. 偏好与长期记忆
   能影响输出风格或长期策略的东西。它不该频繁变化，变化要可控，最好有写入门槛。

4. 能力与权限
   工具可见性、工具可用性、流程放行条件。它是约束，不是参考建议。

8. 可执行的架构清单

按“先做什么更值”排：

1. 先做工具可见性控制
   工具分层，默认只给 Root 类目；按分支披露具体工具。

2. 把 SOP 变成状态机放行
   上一步成功回执出现，下一步工具才可见。失败就停在当前阶段，不要让模型口头放行。

3. 把上下文分区：驻留区 / 工作区 / 冷存区
   驻留区短且稳定；工作区有预算；冷存区只保留索引/摘要。

4. 先索引后片段的披露策略
   任何大文本资源都先给目录、标题、命中位置，再给片段，不要一上来就全文。

5. Skill 化你的上下文与工具组合
   让“动态注入”从拼 Prompt 变成“加载/卸载 Skill”。一开始不需要 100 个 Skill，把高频的 5–10 个先做稳。

6. 把观测补齐
   记录每轮：披露了哪些证据、开放了哪些工具、触发了哪些 Skill、用了多少 Token、是否命中检查点。没有这些数据，后面很难迭代。

9. 小结

一个成熟的 Agent 系统，外观上像在聊天，内部其实在跑一套受控的执行架构：

• 信息不是一次塞满，而是按步骤披露
• 工具不是全量开放，而是按层级开放
• 流程不是靠自觉，而是靠状态机约束
• 记忆不是越多越好，而是可写入、可淘汰、可追溯

把这四件事做好，Agent 会越来越像一个靠谱的执行系统：该问的问清楚，该查的查到证据，该做的按流程做完，做不到就停下来，不会硬编。

这就是「渐进式披露 + 动态上下文管理」的价值：不是让 Agent 说得更像，而是让它做得更稳。

以上。

这个思路很巧妙。他们注意到人类记忆和视觉感知都有个共同特点：距离越远，信息越模糊。一小时前的事记得清楚，一年前的事几乎忘光；10 厘米的东西看得清楚，20 米外的东西就模糊了。

DeepSeek 把这个生物学现象转化成了工程实现：近期对话用高分辨率保存，一周前的对话降到中等分辨率，久远的记忆压缩到最小。信息随时间自然衰减，就像人类遗忘一样。

这让我想到 Agent 记忆系统设计的本质问题。

1. 为什么 Agent 需要记忆

上下文窗口和记忆是两码事。

上下文窗口只是让模型一次看到更多对话，像是扩大了工作台。但记忆不同，它让 Agent 能保存、更新和选择性回忆信息。没有记忆，Agent 就像得了失忆症，每次对话都从零开始。

现在大家都在追求更大的上下文窗口，从 8K 到 32K，再到 128K、1M。但这种暴力扩张有个问题：计算成本呈二次方增长。处理 100K tokens 的成本是 10K tokens 的百倍。而且，把所有信息一股脑塞给模型，反而可能让它迷失在细节中。

记忆系统的价值在于选择性保留。

不是所有信息都值得记住，也不是所有信息都需要同样的精度。

2. Agent 记忆的层次结构

AI Agent 的记忆系统可以分成几个层次：

短期记忆（工作记忆）
这是 Agent 的记事本，保存当前对话和正在处理的任务。典型容量在几千到几万 tokens。没有它，Agent 会在对话中途失去思路，问你刚才说了什么。

长期记忆
这是跨会话的持久化存储。用户下次回来，Agent 还记得之前的交互。长期记忆又可以细分：

• 事实记忆：保存确定的信息，比如用户姓名、偏好、角色定义。这些信息需要随情况更新，保持”当前真实状况”。
• 情景记忆：记录具体经历，什么时候发生了什么，结果如何。这给 Agent 一种时间连续感，能回顾过去的决策。
• 语义记忆：组织概念和关系的知识网络。让 Agent 理解”数据库慢”和”查询延迟高”是相关问题。

3. 遗忘机制是有用的

人类会遗忘，不是大脑容量不够，而是遗忘让我们更高效。

想象一下，如果你记得生活中的每个细节：每顿饭的味道、每次呼吸的感觉、路过的每个行人的脸。这些信息会淹没真正重要的记忆。遗忘是一种过滤机制，帮我们保留有价值的信息。

Agent 也需要这种机制。随着交互增加，历史数据会无限增长。如果不加选择地保存所有内容，会面临几个问题：

1. 存储成本：每个用户的历史数据都完整保存，存储需求会爆炸式增长。
2. 检索效率：在海量历史中找到相关信息越来越慢。
3. 注意力分散：太多无关信息会干扰 Agent 的决策。
4. 隐私风险：永久保存所有对话增加了数据泄露的风险。

4. 用分辨率模拟时间衰减

DeepSeek 的做法是：把历史对话渲染成图像，然后用不同的分辨率来编码。

近期对话用高分辨率（Gundam 模式，800+ tokens），保留完整细节。

一周前的对话用中等分辨率（Base 模式，256 tokens），保留主要内容。

久远的历史用低分辨率（Tiny 模式，64 tokens），只留个大概印象。

这样做的好处是：

1. 不需要丢弃历史信息，所有对话都保留着
2. 但远期信息自然”淡化”，占用的 token 越来越少
3. 模拟了人类记忆的衰减曲线

具体实现上，他们会：

1. 把超过一定长度的历史对话渲染成图像
2. 第一次压缩，让 token 减少 10 倍
3. 上下文再次超长时，进一步降低分辨率，再压缩 10 倍
4. 随着时间推移，图像越来越小，内容越来越模糊，模型也就逐渐”读不清”了

这种方式不是简单的截断或删除，而是让信息随时间衰减——就像人类记忆一样。

5. 理论上无限的上下文

如果这个思路走通了，就能实现”理论上无限的 context window”。

这里的无限不是真的无限，而是通过分层压缩，让历史信息的存储成本趋近于常数。

我们不需要保持所有信息的高保真度，只需要让信息按重要性和时效性衰减。

最近的对话，全保留。
一周前的，压缩一次。
一个月前的，再压缩一次。
半年前的，只留个印象。

这样，计算资源始终聚焦在最重要的”近期”信息上，而久远的历史虽然还在，但只占用很少的 token。

从成本角度看，这比无脑扩大上下文窗口要合理得多。

6. 记忆管理的工程实践

在实际的 Agent 系统里，记忆管理通常分几个层次：

会话级记忆——当前对话的上下文，存在内存里，对话结束就清空。这部分可以直接用模型的上下文窗口。

用户级记忆——持久化存储，用向量数据库或 KV 存储。每次对话时，根据当前问题检索相关的历史记忆，注入到 prompt 里。

全局知识库——所有用户共享的知识，比如产品文档、技术规范、FAQ。这部分通常用 RAG（检索增强生成）来处理。

关键是如何在这些层次之间做好信息流转和优先级管理。

比如，用户刚说过的话，优先级最高，直接放在 prompt 前面。一周前的对话，需要检索后才注入。一个月前的，可能只保留摘要。

这种分层策略，和 DeepSeek 的分辨率衰减思路是一致的——让资源消耗和信息重要性成正比。

7. 遗忘不是丢失

这里需要明确的是，遗忘不等于删除。

人类的遗忘，是提取变难了，不是信息消失了。在特定的提示下，很多”遗忘”的记忆还能被唤起。

Agent 的记忆也应该这样设计。

低分辨率的历史对话，在大部分场景下不会被激活，但如果用户明确提到某个时间点的事情，系统可以重新加载那段历史的高分辨率版本。

这需要一个索引机制，能根据时间、主题、关键词快速定位到历史片段。

像 Manus 所使用的文件系统就是这样一种索引机制。

遗忘是常态，召回是特例。这样才能在效率和完整性之间找到平衡。

8. 什么值得记住

并不是所有对话都需要长期保存。

大量的对话是重复的、临时的、没有上下文依赖的。比如简单的问候、重复的确认、无关紧要的闲聊。

这些内容可以在会话结束后直接丢弃，不需要进入长期记忆。

真正值得记住的，是那些包含决策、偏好、关键信息的交互。

比如：

• 用户明确表达的需求和偏好
• 重要的决策节点和原因
• 反复出现的问题和解决方案
• 用户的角色、职责、技术栈等基础信息

这需要在记忆写入时做判断和过滤。可以用一个小模型或规则引擎，评估每轮对话的重要性，决定是否持久化。 Gemini Code 就是这么干的。

不是所有东西都值得记住，筛选本身就是一种优化。

9. 记忆的更新和冲突

长期记忆不是只写不改的日志，它需要能更新。

用户的偏好会变，角色会变，之前的信息可能过时或错误。

比如用户之前说喜欢中古风的家具，后来又说喜欢北欧风，这个信息需要更新，而不是简单地追加一条新记录。

如果只追加不更新，记忆会越来越冗余，甚至出现矛盾。

一个好的记忆系统，需要能识别冲突，做合并和覆盖。

这可以通过实体识别和关系抽取来实现。把对话内容结构化成三元组（主体-关系-客体），然后在写入时检查是否和已有记忆冲突。

如果冲突，可以根据时间戳、置信度等因素决定是更新还是保留多个版本。

记忆管理的复杂度，不亚于写一个小型数据库。

10. 压缩不只是技术问题

回到 DeepSeek 的光学压缩思路，它的价值不只是技术实现，更重要的是提供了一个思维框架。

我们习惯于把上下文长度当作硬指标——越长越好。但这个论文提醒我们，长度和质量不是一回事。

有时候，适度的遗忘反而能提升系统的整体表现。

有如下的好处：

1. 减少了无关信息的干扰
2. 降低了计算成本
3. 让模型专注于最相关的内容

这和人类的认知机制是一致的。我们不会带着所有历史记忆去做每一个决策，而是根据当前情境激活最相关的那部分。

Agent 应该学会做同样的事。

11. 成本和效果的平衡

从成本角度看，无限扩展上下文是不可持续的。

假设一个 Agent 系统，每天处理 1000 次对话，每次对话平均 10 轮，每轮 500 tokens。

如果所有历史对话都全量保留，一个月下来，单个用户的上下文就会达到 1500k tokens。

如果有 1000 个活跃用户，每次推理都带上完整上下文，token 消耗会是天文数字。

但如果用分层记忆 + 遗忘机制：

• 最近 3 天的对话，全保留
• 一周到一个月的，压缩 50%
• 一个月以上的，压缩 90%

token 消耗可能降低到原来的 10%-20%，而对实际效果的影响很小。

因为大部分场景下，用户关心的就是最近的对话。

12. 记忆应该是系统能力

很多团队把记忆功能当作一个独立的我来开发——加个数据库，存一下历史，检索一下注入。

但这样做的效果往往不好。

因为记忆不是一个功能模块，而是整个 Agent 系统的底层能力。

它需要和 prompt 设计、工具调用、推理链路、错误处理深度集成。

比如：

• Prompt 需要为记忆预留位置和格式
• 工具调用的结果需要写回记忆
• 推理过程中需要动态检索记忆
• 错误发生时需要回溯历史上下文

记忆管理做得好，Agent 的整体表现会有质的提升。做得不好，就只是一个会话机器人。

13. 一些建议

以下是一些可以尝试落地的建议：

1. 不要把所有历史都塞进 prompt

很多团队的做法是，每次调用都把所有历史对话拼接到 prompt 里。这在对话轮数少的时候没问题，但规模上去后会成为瓶颈。

改成检索式注入——根据当前问题，从历史记忆里检索最相关的几条，而不是全量加载。（这里就会考量检索的能力了）

2. 区分会话记忆和持久记忆

当前对话的上下文，存在内存里就行，不需要持久化。

只有那些需要跨会话保留的信息，才写入数据库。

这样可以大幅减少存储和检索的开销。

3. 给记忆加上过期时间

就像缓存一样，记忆也可以有 TTL（Time To Live）。

一般性的对话，可以设置 7 天或 30 天过期。重要的信息，可以标记为永久保留。

定期清理过期记忆，防止数据无限膨胀。

4. 用好向量数据库

向量检索是目前最适合做语义记忆的技术。

把历史对话做 embedding，存到向量数据库里，每次根据当前问题做相似度检索。

但要注意，向量检索的召回率不是 100%，需要结合关键词索引和时间过滤。

5. 记忆要能解释

用户问”你为什么这么回答”，Agent 应该能说清楚是基于哪段历史记忆做的判断。

这需要在记忆检索时保留溯源信息——这条记忆来自什么时间、什么对话、可信度如何。

可解释性不仅是用户体验问题，也是调试和优化的基础。

14. 最后

上下文记忆和遗忘，本质上是资源分配问题。

我们只有有限的 token 预算，有限的计算资源，有限的响应时间，需要在这些约束下做出最优决策。

无限扩展上下文听起来很美好,但实际上不可行。

真正的解决方案，是学习人类的记忆机制——让重要的信息留下来，让次要的信息自然衰减。

DeepSeek 的光学压缩思路提供了一个很好的启发：遗忘不是缺陷，而是一种优化策略。

如果能把这个思路落地到 Agent 系统里，不仅能降低成本，还能提升整体的智能水平。

因为真正的智能，不是记住所有东西，而是知道什么值得记住，什么可以忘记。

从而也就无法看到一句话就完成所有的事情，需要有专业的人在旁边盯着。

甚至出现了一个新的名词：大模型善后工程师

并且那种自动多的 AI Agent ，面对的大多数是对于幻觉，有一定容错的场景，如自动化报告生成，陪伴语聊。

那些无法容错的场景， AI Agent 就必须要人工审核或者带审计的工作流来完成。

为什么在准确性要求比较高的 AI Agent 都变成了工作流？

看一下我们常见的 AI Agent 逻辑：

收到用户输入 → 判断意图 → 调用对应的模块 → 整理输出 → 返回结果

这跟我们想象中的 Agent 差距很大。理想中的 Agent 应该像一个真正的助手，能理解复杂的需求，自主规划执行路径，遇到问题能灵活调整策略。但现实是，大部分产品都在用固定的流程来约束 AI 的行为。

为什么会这样？核心原因是大模型本身的特性决定的。

大模型的能力边界在哪里

大模型确实很强大，但它有明确的能力边界。

第一个边界是可靠性。大模型的输出本质上是概率分布，每次生成都有不确定性。同样的输入，可能得到不同的输出。这种不确定性在聊天场景下可以接受，但在准确率要求比较高的生产环境中就是个大问题。比如一个财务报表分析的 Agent，我们是无法接受它今天说利润率是 15%，明天又说是 18%。

第二个边界是准确性。大模型的训练数据是有截止时间的，而且它没有实时获取信息的能力。更重要的是，它会产生幻觉——看起来很有道理，但实际上是错的。一个合同审核的 AI Agent，引用了一条根本不存在的法律条款，差点出事。

第三个边界是执行能力。大模型本质上是一个文本生成器，它不能直接操作系统、调用 API、访问数据库。所有这些能力都需要额外的工程实现。而一旦涉及到外部系统的调用，就必须有明确的权限控制和错误处理，这又把我们拉回到工作流的思路上。

第四个边界是成本。完全放开让大模型自主决策，意味着大量的 token 消耗。一个复杂任务可能需要多次推理、多次调用，成本会急剧上升。在我们做 AI Agent 之初，成本问题就是一个要着重考虑的问题。我最近用得比较多的编程 Agent，就因为成本问题，把之前的收费逻辑做了颠覆式的变化，作为一个用户，最直观的感受就是费用暴增。

使用工作流是一种现实

面对这些边界，工作流成了一个自然的选择。

工作流解决了可控性问题。通过预设的流程，我们能确保 AI 的行为在可控范围内。每一步该做什么、不该做什么，都有明确的定义。这对企业应用来说至关重要。没有哪个企业敢把关键业务交给一个完全不可控的系统。

工作流解决了准确性问题。在工作流的每个节点，我们可以加入验证和校准机制。比如在数据查询环节，直接调用数据库而不是让大模型猜测；在关键决策点，加入人工审核环节。这样既利用了大模型的能力，又避免了它的短板。

工作流还解决了成本问题。通过流程优化，我们可以精确控制大模型的调用次数和方式。简单的任务用小模型或规则引擎处理，复杂的任务才调用大模型。这种分层处理大大降低了运营成本。

更重要的是，工作流让产品可以迭代优化。每个环节的表现都可以监控和改进，哪里出问题就改哪里，而不是面对一个黑盒束手无策。

如何设计一个好的工作流 Agent

既然工作流是当前的现实，那怎么设计一个好的工作流 Agent？

1. 任务拆解。把复杂的任务拆解成多个简单、明确的子任务。每个子任务都有清晰的输入输出定义。比如一个智能客服 Agent，可以拆解为：意图识别、信息提取、知识检索、答案生成、对话管理等模块。
2. 模块化设计。每个模块独立开发和优化，通过标准接口连接。这样的好处是可以灵活替换和升级。今天用规则引擎的地方，明天可以换成机器学习模型；现在用 GPT-4 的地方，以后可以换成更合适的专用模型。
3. 状态管理。工作流需要维护整个对话或任务的上下文状态。这不仅包括用户的历史输入，还包括中间结果、系统状态等。良好的状态管理是实现复杂交互的基础。
4. 异常处理。每个环节都可能出错，需要有完善的异常处理机制。比如大模型返回了不合预期的结果怎么办？外部 API 调用失败怎么办？这些都需要提前考虑。
5. 人机协同。在关键环节保留人工介入的接口。这不是技术不行，而是业务需要。很多场景下，人工审核是合规要求，也是质量保证。总得有人背锅不是，毕竟 AI 背不了锅。

工作流的局限性

工作流虽然解决了很多问题，但也有明显的局限性。

第一是灵活性不足。预设的流程很难应对所有情况，遇到流程外的需求就无能为力。这也是为什么很多 Agent 给人感觉很”笨”的原因——它只会按照固定的套路来。

第二是开发成本高。设计一个完善的工作流需要深入理解业务逻辑，每个流程都需要大量的开发和测试。而且业务变化时，工作流也需要相应调整，维护成本不低。

第三是用户体验的割裂感。用户能明显感觉到自己在跟一个程序打交道，而不是一个智能助手。特别是当工作流设计不够自然时，这种割裂感会更强。

预想可能的发展

尽管当前工作流是主流，但技术还在快速发展。

模型能力在提升。新一代的大模型在准确性、稳定性上都有改进。特别是针对特定领域的专用模型，表现越来越好。比最新上的 Qwen3-Max 就针对工作流，工具调用有了特别的优化。这为减少工作流的约束提供了可能。

工具调用能力在增强。Function Calling、Tool Use、MCP，以及最新的 SKILLS 等技术让大模型能更好地与外部系统交互。虽然本质上还是工作流，但流程可以更动态、更智能。

多模态融合带来新可能。不只是文本，图像、语音、视频等多模态信息的处理能力都在提升。这让 Agent 能处理更复杂的任务，提供更自然的交互。

强化学习和自主学习是长期方向。让 Agent 从交互中学习，不断改进自己的策略。虽然现在还不成熟，但这是实现真正自主 Agent 的关键。

产品化的思考

做 AI Agent 产品，技术只是一部分，更重要的是产品思维。

首先要明确定位。你的 Agent 是要解决什么问题？为谁解决？解决到什么程度？不要试图做一个万能的 Agent，那样最后什么都做不好。现在很火的小鹏的机器人，其有 80 个控制点，相对于宇树的 20 个控制点，其灵活性肯定要高一些，但是其场景和定位是完全不一样的，成本也不一样。

其次是场景选择。选择那些容错率相对高、价值明确的场景。比如内容创作辅助就比财务决策更适合当前的技术水平。在合适的场景下，即使是工作流 Agent 也能创造很大价值。

然后是预期管理。不要过度承诺，要让用户清楚产品的能力边界。与其说这是一个智能助手，不如说这是一个智能工具。合理的预期能减少用户的失望，提高满意度。

还要重视数据积累。每一次用户交互都是宝贵的数据。通过分析这些数据，我们能发现工作流的不足，找到优化的方向。数据驱动的迭代是产品成功的关键。

最后是成本控制。AI Agent 的运营成本不低，必须找到合理的商业模式。是订阅制还是按量付费？是 To B 还是 To C？这些都需要根据产品特性和市场情况来决定。

实践中的几个关键点

基于这段时间的观察和实践，有几个点特别重要。

第一，不要迷信技术。大模型很强大，但它不是银弹。很多问题用传统方法解决更高效、更可靠。关键是找到合适的技术组合。

第二，重视工程实现。一个好的想法到一个可用的产品，中间有大量的工程工作。提示词优化、结果解析、错误重试、性能优化，这些看似琐碎的工作往往决定产品的成败。

第三，持续迭代。AI Agent 产品很难一步到位，需要不断根据用户反馈来改进。建立快速迭代的机制，小步快跑，逐步逼近理想状态。

第四，关注安全和合规。AI 的不可控性带来了新的安全风险。数据隐私、内容安全、决策可解释性，这些都需要提前考虑。特别是在企业级应用中，合规往往是第一要求。

第五，建立评估体系。怎么衡量一个 Agent 的好坏？准确率、响应时间、用户满意度、成本效率，需要建立全面的评估指标。只有能量化，才能持续优化。

写在最后

做 AI Agent 产品这段时间，最大的感受是理想与现实的差距。我们都希望做出科幻电影里那样的 AI，但现实的技术约束让我们不得不妥协。

但这未必是坏事。工作流让 AI 变得可控、可靠、可用。在当前的技术条件下，一个设计良好的工作流 Agent，往往比一个不受约束的”智能” Agent 更有价值。

关键是要认清现实，在约束中寻找创新的空间。大模型的边界是客观存在的，但边界之内仍然有广阔的天地。工作流不是终点，而是通向更智能的 Agent 的必经之路。

技术在进步，产品在迭代，市场在成熟。今天的工作流 Agent，可能就是明天自主 Agent 的雏形。重要的不是等待完美的技术，而是用现有的技术创造价值，在实践中推动进步。

这个领域还很年轻，充满了可能性。无论是技术突破还是产品创新，都有大量的机会。保持理性的乐观，脚踏实地地推进，相信我们能做出真正有用的 AI Agent 产品。

毕竟，每一个伟大的产品，都是从不完美开始的。

以上。

我结合自己的思考，整理了我认为 5 个最有价值的技术要点，每一个都直接影响着智能体的性能和可用性。

1. 上下文爆炸是智能体最大的瓶颈

Manus 统计显示，一个典型的智能体任务需要约 50 次工具调用。Anthropic 也提到，生产环境中的智能体对话可能持续数百轮。每次工具调用都会返回结果，这些结果会不断累积在消息历史中。

问题在于，随着上下文长度增加，模型性能会明显下降。Anthropic 把这个现象称为”上下文腐烂”（context rot）。具体表现是模型开始重复输出、推理速度变慢、回答质量下降。大部分模型在 200k Token 左右就开始出现这些问题，远低于它们宣称的上限。

这就形成了一个矛盾：智能体需要大量上下文来保持工作状态的连续性，但上下文太长又会导致性能下降。这是所有开发智能体的团队都会遇到的核心挑战。

Lance 在分享中展示了他们 Open Deep Research 项目的数据。这个开源项目在 Deep Research Bench 测试中排名前十，但即使是这样优秀的实现，也需要在三个阶段中不断地卸载和压缩上下文才能保持高效运行。

Pete 则分享了 Manus 的经验。他们发现，如果不做任何优化，上下文会在几十轮对话后就达到模型的处理极限。更糟糕的是，用户往往在这时才开始进入任务的核心部分。

解决这个问题没有捷径，必须从架构设计开始就考虑上下文管理。这也是为什么”上下文工程”这个概念在今年 5 月开始迅速流行的原因。它不是可选的优化项，而是构建生产级智能体的必要条件。

2. 上下文工程的五大组成部分

Lance 和 Pete 在分享中系统地总结了上下文工程的五个核心组成部分，这些部分相互关联，形成了一个完整的技术体系。

上下文卸载 是把部分信息移出主消息历史，存储到外部系统中。最常见的是使用文件系统。当搜索工具返回大量结果时，不是把完整内容放在消息队列里，而是写入文件，只在上下文中保留文件路径。Claude Code、Manus、Open Deep Research 项目都大量使用这种方法。

上下文缩减 包括压缩和摘要两种策略。压缩是去掉可以从外部重建的信息，摘要是对信息进行不可逆的精简。Claude 3.5 Sonnet 已经内置了修剪旧工具调用的功能。Cognition 在智能体交接时也会触发摘要。

上下文检索 解决如何按需获取被卸载的信息。有两派做法：Cursor 使用索引加语义搜索，Claude Code 和 Manus 只用文件系统加 grep、glob 这样的简单工具。两种方法各有优劣，选择哪种取决于具体场景。

上下文隔离 通过多智能体架构实现关注点分离。每个子智能体有自己的上下文窗口，避免信息混杂。Manus 的 Wide Agents、LangChain 的 Deep Agents、Claude 的多智能体研究员都采用了这种设计。

上下文缓存 利用 KV 缓存等机制减少重复计算。Anthropic 等服务商提供的缓存功能对长上下文智能体至关重要，特别是在输入远长于输出的场景下。

这五个部分不是独立的，而是相互影响的系统。卸载和检索让缩减更高效，稳定的检索让隔离变得安全。但隔离会减慢上下文传递，降低缩减频率。更多的隔离和缩减又会影响缓存效率。

Pete 特别强调，这种相互依赖意味着你不能只优化某一个方面，必须从整体考虑。比如，如果你的检索机制不够稳定，就不能激进地进行上下文隔离，否则子智能体可能无法获取必要的信息。

3. 上下文管理和数据库系统的对比

在分享中我个人的感觉是上下文工程的设计和数据库系统设计有比较多的相似性。

上下文卸载和数据库索引有很多相似之处，但它们的设计目标和实现机制存在本质差异。

展开来讲：相似性是都是为了解决容量与性能的矛盾

数据库索引解决的是「如何在海量数据中快速定位」的问题，而上下文卸载解决的是「如何在有限窗口中访问无限信息」的问题。两者都是通过建立某种间接引用机制，让系统能够处理超出直接处理能力的数据量。

数据库有内存中的索引页、磁盘上的索引文件、以及实际的数据页。上下文工程也有类似的层次：活跃上下文（相当于内存中的热数据）、文件路径引用（相当于索引）、文件系统中的完整内容（相当于磁盘数据）。

数据库索引针对不同的查询模式有不同类型：B 树索引适合范围查询，哈希索引适合等值查询，全文索引适合文本搜索。上下文卸载也有类似的分类：代码文件用路径索引，搜索结果用语义向量索引，对话历史用时间戳索引。

数据库的 buffer pool 会缓存频繁访问的索引页和数据页。上下文工程中的 KV 缓存也会保留频繁引用的上下文片段。两者都使用 LRU 或类似算法决定淘汰策略。

关键差异：索引是查询优化，卸载是容量管理

数据库索引的主要目标是加速查询，即使没有索引，全表扫描也能得到结果，只是慢一些。而上下文卸载是为了突破硬性限制，没有卸载机制，超出窗口的信息就完全无法访问。这是「优化」与「必需」的区别。

数据库索引是冗余信息，删除索引不会丢失数据，只会影响查询性能。但上下文卸载中，如果文件系统中的内容丢失，而上下文中只有路径引用，信息就永久丢失了。这就是为什么 Pete 强调卸载必须配合可靠的检索机制。

数据库索引需要随数据更新而维护，这是 ACID 事务的一部分。而上下文卸载通常是单向的：信息从上下文移到外部存储，很少需要反向更新。即使文件内容被修改，上下文中的引用通常保持不变。

数据库可以选择性地为某些列建立索引，基于查询模式和数据分布做决策。而上下文卸载往往是强制的：当接近 Token 限制时，必须卸载某些内容，没有”不建索引”的选项。

就像数据库有内存、磁盘、缓存的层次结构，上下文工程也有类似的分层：活跃上下文（内存）、文件系统（磁盘）、KV 缓存（缓存层）。数据库的查询优化对应着上下文检索，事务隔离对应着智能体隔离，数据压缩对应着上下文压缩。

Pete 提到的”通过通信”和”通过共享内存”两种模式，实际上对应着数据库中的消息传递和共享存储两种架构。当子智能体需要完整历史记录时，使用共享上下文模式，这就像数据库中的共享存储架构。当任务相对独立时，使用通信模式，类似于分布式数据库的消息传递。

智能体间的状态同步问题，本质上就是分布式系统的一致性问题。

Manus 的解决方案也借鉴了数据库的设计思想。他们使用结构化的模式（schema）来定义智能体间的通信接口，确保数据的一致性。他们的分层行为空间设计（函数调用、沙盒工具、软件包与API）类似于数据库的存储引擎分层。

这种类比不仅仅是理论上的相似。在实践中，你可以直接应用数据库系统的很多优化技术。比如，使用 LRU 策略决定哪些上下文应该被压缩或摘要；使用预写日志（WAL）的思想，在摘要前先把完整上下文写入日志文件；使用索引来加速文件系统中的信息检索。

我们可以借鉴数据库领域几十年的研究成果和工程实践，而不是从零开始摸索。

3. 上下文工程的核心是做减法，而不是加法

Pete 在分享最后强调的这一点可能是最重要的：避免上下文过度工程（context over-engineering）。

他提到，Manus 上线六七个月以来，最大的性能提升不是来自增加更复杂的上下文管理机制，而是来自简化架构、移除不必要的功能、对模型给予更多信任。他们已经重构了 Manus 五次，每次都是在做减法。

比如，早期的 Manus 使用 todo.md 文件来管理任务列表，结果发现约三分之一的操作都在更新这个列表，浪费了大量 Token。后来他们改用更简单的结构化规划器，效果反而更好。

另一个例子是工具选择。他们没有使用复杂的语义搜索来动态加载工具，而是固定使用 10-20 个原子功能，其他所有功能都通过沙盒中的命令行工具或 Python 脚本来实现。这种分层的行为空间设计，让系统既灵活又简单。

Pete 还提到了一个评估架构的方法：在强弱模型之间切换测试。如果你的架构从弱模型切换到强模型后能获得明显提升，说明架构有较好的未来适应性。因为明年的弱模型可能就和今天的强模型一样好。

关于是否要训练专门的模型，Pete 的观点也很明确：初创公司应该尽可能长时间地依赖通用模型和上下文工程。训练专门模型不仅成本高，而且在产品快速迭代的阶段，很可能在优化错误的指标。MCP（Model Context Protocol）的推出就是个例子，它彻底改变了 Manus 的设计，如果之前投入大量资源训练专门模型，这些投入就浪费了。

他们现在也不使用开源模型，不是因为质量问题，而是成本问题。对于输入远长于输出的智能体应用，KV 缓存至关重要。大型云服务商有更好的分布式缓存基础设施，算下来使用他们的 API 反而更便宜。

这些经验告诉我们：上下文工程的目标是让模型的工作变得更简单，而不是更复杂。不要为了优化而优化，每个设计决策都要基于实际的性能数据和用户反馈。

4. 压缩与摘要的本质区别决定了使用策略

Pete 详细解释了压缩和摘要这两种看似相似实则截然不同的策略，这个区分对实际应用至关重要。

压缩是可逆的。在 Manus 中，每个工具调用都有完整格式和紧凑格式。比如写文件操作，完整格式包含路径和内容，紧凑格式只保留路径。因为文件已经存在于文件系统中，通过路径可以随时恢复完整信息。这种可逆性至关重要，因为你永远不知道哪个历史操作会在后续变得重要。

摘要是不可逆的。一旦执行摘要，原始信息就永久丢失了。因此必须非常谨慎。Manus 的做法是在摘要前将完整上下文转储为日志文件，作为最后的保险。而且摘要时要保留最新几次工具调用的完整信息，让模型知道当前的工作状态。

关于阈值的确定，Pete 分享了具体数据：大多数模型在 200k Token 左右开始出现性能下降，他们将 128k-200k 设定为”腐烂前”阈值。这不是随意设定的，而是通过大量评估得出的。他们测试了不同长度下模型的重复率、推理速度、输出质量等指标。

触发策略是渐进式的：

• 接近 128k 时，开始压缩最旧的 50% 工具调用
• 压缩后检查实际释放的空间
• 如果压缩效果不明显（因为即使紧凑格式也占用空间），才考虑摘要
• 摘要时使用完整版本而非压缩版本的数据
• 始终保留最新的几次完整工具调用

尽可能保留信息的完整性，只在必要时才接受信息损失。这就像数据压缩算法中的无损压缩和有损压缩，你总是先尝试无损方案。

不同类型的内容有不同的压缩潜力。搜索结果、API 响应这类内容压缩效果好，因为大部分信息可以通过查询重新获取。而用户的指令、模型的推理过程压缩空间有限，因为这些信息往往都是必要的。

5. 隔离策略的选择取决于任务特性而非直觉

多智能体隔离是个老话题，但 Pete 分享的经验推翻了很多常见做法。

首先是反模式的识别。很多团队喜欢按人类角色划分智能体：设计师智能体、程序员智能体、经理智能体等。Pete 明确指出这是个陷阱。这种划分源于人类组织的局限性（个人能力和注意力有限），而不是 AI 系统的最优设计。Manus 只有极少的几个功能性智能体：通用执行器、规划器、知识管理器。

关于隔离模式的选择，Pete 区分了两种场景：

通信模式适合结果导向的独立任务。主智能体发送明确指令，子智能体独立完成，返回结果。整个过程主智能体不关心细节，只要最终输出。比如”在代码库中搜索特定函数”、”将这段文本翻译成中文”。这种模式的优势是上下文干净、成本低、易于调试。

共享上下文模式适合需要完整历史信息的复杂任务。子智能体能看到所有历史对话和工具调用，但有自己的系统提示和工具集。比如深度研究任务，最终报告需要参考大量中间搜索和笔记。这种模式成本高（需要预填充大量上下文，无法复用 KV 缓存），但对某些任务是必要的。

判断使用哪种模式的关键是从结果推理过程的依赖性。如果最终输出强依赖于中间步骤的细节，就需要共享上下文。如果只需要最终结果，通信模式就足够了。

Pete 还提到了一个实用技巧：”智能体即工具”（agent as tool）。从主智能体视角，调用子智能体就像调用普通工具，有明确的输入输出接口。这简化了系统设计，也让调试更容易。Manus 的”高级搜索”功能就是这样实现的，表面上是个工具，实际是个完整的子智能体工作流。

他们解决通信问题的方法是强制使用结构化输出。主智能体调用子智能体前必须定义输出模式，子智能体通过专门的”提交结果”工具返回数据，系统用约束解码确保格式正确。这避免了自由格式通信带来的解析问题和信息丢失。

6. 一些额外的技术洞察

除了这五个核心经验，还有一些值得记录的技术细节。

信息的局部性。使用基于行的格式意味着每行都是独立的信息单元，读取第 100 行不需要解析前 99 行。这对于大文件的随机访问至关重要。

结构化不等于复杂格式。Pete 强调，他们优先使用基于行（line-based）的纯文本格式，而不是 JSON 或 XML。原因很简单：模型可以用 grep 搜索特定行，用 sed 修改特定内容，用 head/tail 读取部分数据。这些都是模型已经掌握的基础工具。

关于 Markdown 的使用要特别谨慎。虽然模型都接受过 Markdown 训练，但过度使用会带来副作用。某些模型会因此输出过多的项目符号和格式化标记，浪费 Token 还影响可读性。Manus 的经验是：在需要结构时用 Markdown，在存储数据时用纯文本。

关于模型切换的评估方法。Pete 提到，他们会在强弱模型间切换来评估架构的未来适应性。如果一个架构在弱模型上也能工作（虽然效果差一些），说明它不是过度依赖特定模型能力的脆弱设计。

关于工具数量的上限，他们的经验是不超过 30 个。这不是任意数字，而是基于大量测试。超过这个数量，模型开始频繁调用错误的工具，甚至调用不存在的工具。解决方案不是动态加载工具，而是设计分层的行为空间：少量原子工具 + 沙盒命令 + 代码执行。

关于评估体系，Manus 的三层评估值得借鉴：用户评分是北极星指标，自动化测试覆盖可验证的任务，真人评估处理主观性强的输出。学术基准测试只是参考，不能作为主要依据。

上下文工程不是一些零散的技巧，而是一个需要系统思考的工程领域。每个设计决策都会影响到其他部分，没有放之四海而皆准的最佳实践，只有基于具体场景的权衡取舍。

以上。

这篇文章我会尝试分享一下 AI Agent 的 4 个常用设计模式。

1. 什么是 Agent 设计模式

设计模式这个概念最早来自建筑行业，后来被软件工程借鉴过来。Christopher Alexander 在《建筑的永恒之道》里说，每个模式都是一个三元组：在特定的上下文中，解决特定的问题，采用特定的方案。

放到 AI Agent 领域，设计模式就是构建智能体系统的常见架构方法。每种模式都提供了一个组织系统组件、集成模型、编排单个或多个 Agent 来完成工作流的框架。

为什么需要设计模式？因为 Agent 系统的复杂性在于它需要自主决策、动态规划、处理不确定性。我们需要有特定场景下的特定解决方案，不过于复杂，也不过于简单，刚刚好。

选择设计模式前，需要考虑几个关键因素：任务复杂度、响应时间要求、成本预算、是否需要人工参与。想清楚这些，才能选对模式。

2. 单 Agent 模式

2.1 模式定义

单 Agent 模式是最基础的设计模式。整个系统只有一个 Agent，通过一个 AI 模型、一组预定义的工具、一个精心设计的系统提示词来完成任务。

这也是我们实际工作中常用的设计模式。

Agent 依赖模型的推理能力来理解用户请求、规划执行步骤、选择合适的工具。

这个模式的架构很简单：

用户输入 → Agent（模型+工具+提示词） → 输出结果

所有的决策和执行都在一个 Agent 内完成。

2.2 解决的问题

单 Agent 模式主要解决的是需要多步骤处理但逻辑相对清晰的任务。比如：

• 需要调用多个 API 获取信息然后综合
• 需要访问数据库查询后给出答案
• 需要执行一系列操作来完成用户请求

这些任务用传统的非 Agent 系统也能做，但整个逻辑非常固化，都是规则，而使用了 Agent 后，它能动态决策，自行做工具调用。

2.3 核心组件

AI 模型：这是 Agent 的大脑，负责理解、推理和决策。模型的能力直接决定了 Agent 的上限。选择模型时要平衡能力和成本，不是所有任务都需要用最强的模型。

工具集：Agent 能调用的外部功能，比如搜索引擎、数据库、API、计算器等。工具定义要清晰，包括什么时候用、怎么用、预期结果是什么。工具太多会增加选择难度，太少又限制能力。

系统提示词：定义 Agent 的角色、任务、行为规范。好的提示词能较大幅提升 Agent 的表现。要明确告诉 Agent 它是谁、要做什么、有哪些限制、如何处理异常情况。

记忆系统：虽然不是必需的，但记忆系统能让 Agent 保持上下文，避免重复操作。可以是简单的对话历史，也可以是复杂的向量数据库。

2.4 工作流程

1. 接收请求：Agent 接收用户的输入，可能是文本、语音或其他格式
2. 理解意图：通过模型分析用户想要什么，需要哪些信息
3. 制定计划：决定需要执行哪些步骤，调用哪些工具
4. 执行操作：按计划调用工具，获取必要信息
5. 综合结果：把各种信息整合成最终答案
6. 返回响应：将结果返回给用户

整个过程是线性的，但 Agent 可以根据中间结果调整计划。

2.5 应用场景

客服助手：处理常见的客户询问，比如查订单、改地址、退换货。Agent 可以访问订单系统、物流系统、用户数据库，一站式解决客户问题。

研究助手：帮助用户收集和总结信息。比如搜索特定主题的最新进展，整理成报告。Agent 可以调用搜索 API、访问学术数据库、生成摘要。

个人助理：管理日程、发邮件、设置提醒。Agent 可以访问日历、邮箱、任务管理工具，帮用户处理日常事务。

2.6 优势与局限

优势：

• 架构简单，容易实现和维护
• 成本可控，只需要调用一个模型
• 响应速度快，没有多 Agent 协调的开销
• 调试方便，所有逻辑在一个地方

局限：

• 处理复杂任务能力有限
• 工具太多时容易混乱
• 单点故障，Agent 出问题整个系统就挂了
• 难以并行处理多个子任务

2.7 实施建议

从简单开始：先实现核心功能，确保基本流程跑通，再逐步添加工具和能力。

工具要精不要多：与其给 Agent 20 个工具，不如精选 5-8 个最常用的。每个工具的使用场景要明确。

提示词要迭代优化：没有一次就完美的提示词。要根据实际使用情况不断调整，特别是边界情况的处理。

加入失败处理：工具调用可能失败，模型推理可能出错。要有明确的错误处理机制，比如重试、降级、转人工。

监控关键指标：响应时间、成功率、工具调用次数、token 消耗等。这些数据是优化的基础。

3. ReAct 模式

3.1 模式定义

ReAct（Reasoning and Acting）模式是一种让 Agent 交替进行推理和行动的设计模式。不同于简单的输入输出，ReAct 模式让 Agent 在一个循环中不断地思考、行动、观察，直到找到问题的答案。

这个模式的核心思想是把 Agent 的思维过程显式化。每一步都要说明在想什么、要做什么、观察到什么，形成一个完整的推理链条。这不仅提高了结果的可靠性，也让整个过程变得可解释。

3.2 解决的问题

ReAct 模式解决的是那些需要多步探索和动态调整策略的复杂问题：

• 答案不是显而易见的，需要逐步收集信息
• 初始计划可能不完善，需要根据中间结果调整
• 需要试错和迭代才能找到最优解
• 推理过程和结果同样重要，需要可解释性

传统的一次性推理经常不够用，需要 Agent 能够根据新信息不断调整自己的理解和策略。

3.2 核心机制

Thought（思考）：Agent 分析当前状况，推理下一步该做什么。这包括理解已有信息、识别缺失信息、评估可能的行动方案。思考过程要明确表达出来，比如「我需要知道 X 才能回答 Y」。

Action（行动）：基于思考结果，Agent 决定采取什么行动。通常是调用某个工具获取信息，也可能是进行计算或转换。行动要具体，包括使用什么工具、传入什么参数。

Observation（观察）：Agent 接收行动的结果，理解新获得的信息。观察不是简单的记录，而要分析这些信息对解决问题有什么帮助，是否需要调整策略。

这三个步骤形成一个循环，不断重复直到找到满意的答案或达到终止条件。

3.3 工作流程

用户输入问题
↓
初始思考：理解问题，确定需要什么信息
↓
循环开始：
  → 思考：基于当前信息，决定下一步
  → 行动：执行决定的操作
  → 观察：分析操作结果
  → 判断：是否已经可以回答问题？
     ├─ 否：继续循环
     └─ 是：退出循环
↓
综合所有信息，生成最终答案
↓
返回给用户

每个循环都在积累信息，逐步接近答案。关键是 Agent 要能判断什么时候信息足够了。

3.4 典型应用场景

复杂问题求解：比如数学应用题，需要分步骤求解。Agent 先理解问题，识别已知和未知，然后逐步计算中间结果，最后得出答案。每一步都要验证是否合理。

信息检索与验证：用户问一个需要多方印证的问题。Agent 从不同来源收集信息，交叉验证，排除矛盾，最终给出可靠的答案。比如”某个历史事件的真实经过”。

调试和故障排查：系统出问题了，Agent 需要逐步检查各个组件，收集日志，测试假设，最终定位问题原因。这个过程充满了试错和调整。

研究和分析：对某个主题进行深入研究。Agent 先了解背景，然后深入特定方面，发现新的线索后调整研究方向，最终形成完整的分析报告。

3.5 实现要点

推理链的质量：ReAct 模式的效果很大程度上取决于模型的推理能力。要选择推理能力强的模型，并通过提示词引导它进行结构化思考。

终止条件设计：必须有明确的终止条件，否则可能陷入无限循环。常见的终止条件包括：找到满意答案、达到最大迭代次数、遇到无法处理的错误、用户主动终止。可以参考我上一篇文章《AI Agent 核心策略：如何判断 Agent 应该停止》

上下文管理：随着循环次数增加，上下文会越来越长。需要策略性地管理上下文，比如总结之前的发现、删除无关信息、保留关键结论。

错误恢复：某一步出错不应该导致整个流程失败。要有恢复机制，比如重试、换一种方法、跳过这一步等。

3.6 优势与挑战

优势：

• 可解释性强，每一步推理都有记录
• 灵活性高，可以动态调整策略
• 准确性好，通过多步验证减少错误
• 适应性强，能处理预料之外的情况

挑战：

• 延迟较高，多次循环导致响应时间长
• 成本增加，每次循环都要调用模型
• 可能陷入循环，在某些问题上来回打转
• 对模型能力要求高，弱模型效果差

3.7 优化策略

设置合理的最大循环次数：根据任务类型和复杂度，设置合适的上限。简单任务 3-5 次，复杂任务 10-15 次。

缓存中间结果：相同的查询不要重复执行，工具调用的结果要缓存起来。

并行化某些操作：如果多个信息获取操作互不依赖，可以并行执行，减少总体时间。

使用更轻量的模型进行初步筛选：不是每个思考步骤都需要最强的模型，可以用小模型做初筛，大模型做关键决策。

提供思考模板：通过提示词工程，给 Agent 提供思考的框架，提高推理效率。

4. 多 Agent 协作模式

4.1 模式定义

多 Agent 协作模式是让多个专门化的 Agent 共同完成一个复杂任务。每个 Agent 负责自己擅长的领域，通过协调器（Coordinator）或预定义的工作流来协同工作。

这个模式的核心理念是”专业分工”。就像一个团队，每个成员都有自己的专长，通过协作可以完成单个人无法完成的任务。协调可以是中心化的（有一个协调器），也可以是去中心化的（Agent 之间直接通信）。

4.2 解决的问题

多 Agent 协作模式解决的是单个 Agent 难以处理的复杂问题：

• 任务涉及多个专业领域，单个 Agent 难以精通所有领域
• 需要并行处理多个子任务以提高效率
• 任务太复杂，单个提示词难以覆盖所有情况
• 需要不同视角的交叉验证来提高可靠性

当你发现单个 Agent 的提示词越写越长、工具越加越多、错误率开始上升时，就该考虑多 Agent 协作了。

4.3 架构类型

顺序协作：Agent 按照预定顺序依次工作，前一个的输出是后一个的输入。像流水线一样，每个 Agent 完成特定的加工步骤。适合步骤明确、顺序固定的任务。

并行协作：多个 Agent 同时工作，各自处理任务的不同方面，最后汇总结果。像团队分工一样，每个人负责一部分，最后整合。适合可以分解的独立子任务。

层级协作：Agent 组织成树状结构，上层 Agent 负责任务分解和结果汇总，下层 Agent 负责具体执行。像公司组织架构，有管理层和执行层。适合需要多级分解的复杂任务。

网状协作：Agent 之间可以自由通信，没有固定的上下级关系。像专家会诊，大家平等讨论，共同决策。适合需要充分讨论和创意的任务。

4.4 核心组件

专业 Agent：每个 Agent 专注于特定领域或功能。比如数据分析 Agent、文案撰写 Agent、代码生成 Agent 等。专业化让每个 Agent 的提示词更精简、更有效。

协调器 Agent：负责任务分解、Agent 调度、结果汇总。协调器需要理解整体任务，知道每个 Agent 的能力，能做出合理的分配决策。

通信机制：Agent 之间如何传递信息。可以是直接传递（点对点），也可以通过共享内存（如消息队列、数据库）。通信协议要明确，包括数据格式、错误处理等。一般是 json 格式。

上下文管理：如何在 Agent 之间共享和传递上下文。不是所有信息都需要传给所有 Agent，要有选择地传递相关信息，避免信息过载。

4.5 典型场景

内容创作流水线：

• 研究 Agent：收集资料、查证事实
• 写作 Agent：撰写初稿
• 编辑 Agent：优化文笔、检查逻辑
• 审核 Agent：确保符合规范、没有敏感内容

每个 Agent 专注自己的环节，整体产出高质量内容。

客户服务系统：

• 分类 Agent：理解客户问题类型
• 查询 Agent：从数据库获取相关信息
• 解决方案 Agent：生成解决方案
• 回复 Agent：组织友好的回复话术

根据问题类型，协调器可能跳过某些 Agent 或调整流程。

代码开发助手：

• 需求分析 Agent：理解用户需求
• 架构设计 Agent：设计系统架构
• 代码生成 Agent：编写具体代码
• 测试 Agent：生成测试用例并执行
• 文档 Agent：生成代码文档

可以迭代工作，测试发现问题后返回给代码生成 Agent 修改。

数据分析系统：

• 数据收集 Agent：从各个源获取数据
• 清洗 Agent：处理缺失值、异常值
• 分析 Agent：统计分析、模式识别
• 可视化 Agent：生成图表
• 报告 Agent：撰写分析报告

可以并行处理多个数据源，提高效率。

4.6 协调策略

中心化协调：所有决策都由协调器做出。优点是逻辑清晰、易于控制；缺点是协调器可能成为瓶颈。

分布式协调：Agent 之间直接协商。优点是灵活、无单点故障；缺点是可能出现冲突、难以调试。

混合协调：结合两者优点，重要决策由协调器做，细节由 Agent 之间协商。

动态协调：根据任务特点动态选择协调策略。简单任务用顺序协作，复杂任务用层级协作。

4.7 实施要点

明确分工：每个 Agent 的职责要清晰，避免重叠和空白。写清楚每个 Agent 负责什么、不负责什么。

接口标准化：Agent 之间的接口要标准化，包括输入输出格式、错误码、超时处理等。

错误隔离：一个 Agent 出错不应该导致整个系统崩溃。要有错误隔离和恢复机制。

性能优化：识别瓶颈 Agent，考虑并行化、缓存、负载均衡等优化手段。

版本管理：不同 Agent 可能有不同的更新频率，要有版本管理机制，确保兼容性。

4.8 优势与挑战

优势：

• 可扩展性好，可以随时添加新的专业 Agent
• 复用性高，Agent 可以在不同任务中复用
• 维护性好，每个 Agent 独立维护，互不影响
• 可靠性高，通过冗余和交叉验证提高准确性

挑战：

• 协调开销大，Agent 之间的通信和协调需要额外成本
• 调试困难，问题可能出现在任何一个 Agent 或它们的交互中
• 延迟增加，多个 Agent 串行或协调都会增加总体时间
• 成本上升，每个 Agent 都需要模型调用，成本成倍增加

5. 人机协同模式

5.1 模式定义

人机协同模式是在 Agent 工作流程中嵌入人工干预点的设计模式。Agent 在关键决策点暂停执行，等待人类审核、提供额外信息或做出决策，然后继续执行。这不是简单的人工兜底，而是人类智慧和 AI 能力的有机结合。

这个模式承认了一个现实：当前的 AI 还不能完全自主地处理所有情况，特别是涉及主观判断、伦理决策、高风险操作的场景。通过合理的人机协同，可以发挥各自优势。

在 AI 编程中通用有一个手动模式和一个自动模式。

5.2 解决的问题

人机协同模式解决的是纯 AI 方案风险太高或能力不足的问题：

• 高风险决策需要人工确认，比如大额交易、医疗诊断
• 主观判断 AI 难以把握，比如创意评审、品牌调性
• 异常情况超出 AI 训练范围，需要人类经验
• 法律或合规要求必须有人参与决策
• AI 不确定性太高，需要人工验证

这个模式的关键是找到人机协同的最佳平衡点，既不能过度依赖人工（那就失去了自动化的意义），也不能完全放手给 AI（可能造成严重后果）。

5.3 协同机制

审核点（Checkpoint）：在工作流的特定位置设置审核点，Agent 必须等待人工审核才能继续。审核点的位置很关键，太多会影响效率，太少可能错过关键决策。

升级机制（Escalation）：当 Agent 遇到超出能力范围的情况时，自动升级到人工处理。需要定义清楚什么情况下升级，比如置信度低于阈值、遇到预定义的异常情况等。

协作模式（Collaboration）：人类和 Agent 共同完成任务，各自负责擅长的部分。比如 Agent 做数据分析，人类做战略决策；Agent 生成初稿，人类做最终润色。

反馈循环（Feedback Loop）：人类的决策和修正会反馈给 Agent，用于改进后续的行为。这是一个持续学习的过程。

5.4 干预类型

批准型干预：Agent 完成工作后，需要人工批准才能生效。比如 Agent 起草了一份合同，法务人员审核批准后才发送。这种干预主要是把关和确认。

选择型干预：Agent 提供多个选项，由人类选择。比如 Agent 生成了三个营销方案，市场总监选择最合适的。这种干预利用人类的判断力。

修正型干预：人类可以修改 Agent 的输出。比如 Agent 写了一篇文章，编辑可以直接修改其中的内容。这种干预是精细调整。

补充型干预：人类提供 Agent 缺少的信息。比如 Agent 在处理客户投诉时，遇到特殊情况，客服人员提供额外的背景信息。这种干预是信息补充。

接管型干预：在某些情况下，人类完全接管任务。比如 Agent 判断问题太复杂，直接转给人工处理。这种干预是兜底机制。

5.5 设计原则

最小干预原则：只在必要的地方设置人工干预，尽量让 Agent 自主完成任务。过多的干预会降低效率，失去自动化的意义。

透明度原则：人类要能理解 Agent 的决策依据。Agent 应该提供决策的理由、使用的数据、考虑的因素等，让人类能做出明智的判断。

可控性原则：人类要能随时介入、修改或停止 Agent 的行为。要有紧急停止按钮、回滚机制等。

责任明确原则：明确人和 AI 各自的责任边界。特别是出现问题时，要清楚责任在谁。

用户体验原则：人机交互界面要友好，信息呈现要清晰，操作要简便。不能因为加入人工环节就让流程变得复杂。

5.6 实施要点

界面设计：人机交互界面是关键。要展示必要信息，但不能信息过载。要提供便捷的操作方式，减少人工负担。可以用可视化、摘要、高亮等技术。

通知机制：需要人工介入时，要有及时的通知机制。可以是应用内通知、邮件、短信等。要考虑优先级和紧急程度。

超时处理：人工可能不能及时响应，要有超时机制。可以是自动采用保守方案、转给其他人、暂停任务等。

权限管理：不同的人可能有不同的干预权限。要有完善的权限体系，确保只有合适的人才能做关键决策。

审计追踪：所有的人工干预都要有记录。谁在什么时间做了什么决定，依据是什么。这对于问题追溯和合规审计都很重要。

5.7 优势与挑战

优势：

• 安全性高，关键决策有人把关
• 灵活性好，能处理 AI 无法处理的特殊情况
• 可信度高，用户更信任有人参与的系统
• 持续改进，人工反馈帮助系统不断优化

挑战：

• 效率降低，人工环节会增加处理时间
• 成本增加，需要人力投入
• 一致性难保证，不同人可能有不同判断
• 扩展性受限，人工环节可能成为瓶颈

6. 选择建议

选择合适的设计模式需要综合考虑多个因素。这里提供一个决策框架：

6.1 从简单到复杂的演进路径

第一阶段：单 Agent 模式

• 任务相对简单，领域单一
• 团队刚开始尝试 Agent
• 需要快速验证概念
• 成本敏感

第二阶段：ReAct 模式

• 任务需要多步推理
• 结果需要可解释性
• 有一定的复杂度但还能单 Agent 处理

第三阶段：多 Agent 协作

• 任务跨越多个领域
• 需要专业分工
• 单 Agent 已经力不从心

始终考虑：人机协同

• 涉及高风险决策
• 需要主观判断
• 法规要求人工参与

6.2 关键决策因素

任务复杂度：

• 低：单 Agent
• 中：ReAct 或简单的多 Agent
• 高：复杂的多 Agent

响应时间要求：

• 实时（秒级）：单 Agent
• 近实时（分钟级）：ReAct 或并行多 Agent
• 非实时（小时级）：任何模式都可以

成本预算：

• 紧张：单 Agent
• 适中：ReAct 或简单多 Agent
• 充足：复杂多 Agent

可靠性要求：

• 一般：单 Agent 或 ReAct
• 高：多 Agent 协作（通过冗余提高可靠性）
• 关键：人机协同

团队能力：

• 初级：从单 Agent 开始
• 中级：可以尝试 ReAct 和简单多 Agent
• 高级：可以驾驭任何模式

7. 总结

AI Agent 的设计模式不是银弹，每种模式都有自己的适用场景和权衡。单 Agent 模式简单直接，适合入门和简单任务。ReAct 模式增加了推理能力，适合需要探索的问题。多 Agent 协作通过分工提高能力，适合复杂的领域任务。层级规划通过递归分解处理高复杂度问题。人机协同则是当前 AI 能力限制下的必要补充。

选择模式时，要从实际需求出发，考虑任务特性、资源限制、团队能力等因素。不要过度设计，也不要畏手畏脚。从简单开始，逐步演进，在实践中找到最适合的方案。

技术最终是为业务服务的。不管用什么模式，最终目的是解决实际问题，创造价值。

以上。