当 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 说得更像，而是让它做得更稳。

以上。

最近 DeepSeek 的 OCR 论文里有个有趣的想法：用光学压缩来模拟人类的记忆遗忘机制。

这个思路很巧妙。他们注意到人类记忆和视觉感知都有个共同特点：距离越远，信息越模糊。一小时前的事记得清楚，一年前的事几乎忘光；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 ，面对的大多数是对于幻觉，有一定容错的场景，如自动化报告生成，陪伴语聊。

那些无法容错的场景， 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 产品。

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

以上。