聊下 AI 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 都变成了工作流?

看一下我们常见的 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 产品。

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

以上。

AI Agent不够聪明,但 SaaS 公司可能是解药

最近经常会和 AI Agent 聊天,使用 AI 编程,并且也会和正在用 AI Agent 的朋友聊天,发现大家 AI Agent 的期待值和实际体验之间,存在着相当大的落差。

换句话说,大家觉得 Agent 不怎么聪明。

1. AI Agent 到底哪里不聪明

可能是以下的方面:

  1. 业务理解能力差。很多 AI Agent 看起来能对答如流,但一涉及到具体业务场景就开始答非所问。先不说原因,原因后面再细讲。
  2. 执行能力有限。在大家的预期中 AI Agent 应该能自主规划和执行任务,但实际上大部分所谓的 AI Agent 还停留在”问一句答一句”的阶段。我们想像中的一句话需求,如”帮我分析这份财报并生成投资建议”,大部分 AI Agent 是搞不定的,类似于 Manus 这种勉强可以的,但其结论是否能参考也是存疑的。
  3. 可控性差。我们一方面希望 Agent 有自主能力,能像人一样灵活处理问题;另一方面又希望它的行为可预测、可控制。这本身就是个悖论。结果就是,要么 Agent 太死板,只能按预设流程走;要么太「聪明」,经常做出一些让人意外的操作。
  4. 定制成本高。这本来不是聪明的问题,但这是聪明的代价,每个企业的业务都有自己的特殊性,要让 Agent 真正理解并适应这些特殊性,需要大量的定制化工作。但问题是,很多企业并没有这个技术能力或者预算来做深度定制。

2. 为什么会出现这些问题

我觉得主要是三方面的原因:

  1. 过高的预期。过去一年,AI Agent 的概念被炒得太热了。各种厂商都在宣传 Agent 能够”完全替代人工”、”自主完成复杂任务”。但实际上,现在的技术水平离这个目标还有很大距离。有的老板,听了厂商的宣传后,真的以为买个 Agent 产品就能替代掉几个员工。结果上线后发现,不仅没法替代人,反而需要专人来”照顾”这个 Agent,教它怎么工作,纠正它的错误。
  2. 模糊的产品定位。现在市面上的 Agent 产品,很多都想做成”万能助手”。但越是想什么都做,越是什么都做不好。反而是那些专注于特定场景的 Agent,比如专门做客服的、专门做数据分析的,效果会好很多。
  3. 技术栈的割裂。做好一个 Agent,需要模型能力、工程能力、业务理解能力的深度结合。但往往懂模型的不懂业务,懂业务的不懂模型,懂工程的可能两个都不太懂。这种割裂导致做出来的产品总是差那么一些。

3. 当前谁最有优势?

答案是:SaaS 公司。

在 AI Agent 落地上,SaaS 公司有着天然的优势。

SaaS 公司最大的优势是接近客户和数据。他们天天跟客户打交道,知道客户的真实需求是什么,痛点在哪里,实际的业务流程是怎样的。更重要的是,他们手里有大量的业务数据和场景数据,这些数据对于训练和优化 Agent 来说是无价之宝。

举个例子,一家做 CRM 的 SaaS 公司,如果要做销售 Agent,它有几个天然优势:

第一,它知道销售的真实工作流程是什么样的。不是理论上的流程,而是实际操作中的流程,包括各种例外情况和潜规则。

第二,它有大量的销售数据。什么样的话术转化率高,什么时间打电话效果好,不同行业的客户有什么特点,这些数据都在它的系统里。

第三,它有现成的客户界面。不需要重新教育客户怎么使用 Agent,可以直接嵌入到现有的产品里。

第四,它有持续优化的能力。客户每天都在使用它的产品,产生新的数据,这些数据可以用来持续优化 Agent 的表现。

相比之下,纯做 AI 的公司,虽然模型能力很强,但在落地时往往会遇到各种水土不服的问题。

4. 垂直场景的突破

在个人粗浅的认知中,Agent 的突破口在于垂直场景,而不是通用场景。在于需要 Konw-How 的场景。

为什么?因为垂直场景有几个优势:

第一,需求明确,专注。不需要 Agent 什么都会,只需要它把一件事做好就行。

第二,数据充足。垂直场景往往有大量的历史数据可以用来训练和优化。

第三,容错率高。因为场景固定,出现意外情况的概率较低,即使出现了也比较容易处理。

第四,ROI 清晰。在垂直场景下,Agent 的价值很容易量化。

比如法律文书撰写、行业分析、代码生成这些场景,都是合适的 Agent 应用场景。这些场景有明确的输入输出,有清晰的质量标准,有大量的历史数据,非常适合 Agent 来处理。

5. 可预测与可掌控的矛盾

在 ToB 场景下,企业客户最怕的就是不确定性。如果一个 Agent 今天的回答和明天的回答不一样,或者在关键时刻做出了意料之外的决策,那对企业来说不可接受的。

但是,客户又希望 Agent 有自适应能力,能够灵活处理各种情况。

当前的解决方案基本上是两个极端:

  1. 完全用 Workflow 来定义 Agent 的行为。每一步做什么都规定得清清楚楚,Agent 只是一个执行者。这样做的好处是完全可控,坏处是太死板,失去了 Agent 的灵活性。
  2. 完全放开,让 Agent 自己去学习和适应。这样做的好处是灵活,能处理各种意外情况,坏处是不可控,你永远不知道它下一步会做什么。

比较理想的方案应该是两者的结合:在关键决策点上用 Workflow 来控制,在具体执行上给 Agent 一定的自主权。但这说起来容易,做起来很难。需要对业务有深入的理解,知道哪些地方需要控制,哪些地方可以放开。

6. 模型能力 vs 工程能力

要解决这些矛盾和问题需要模型和工程两方面的提升,并且现阶段工程能力可能比模型能力更重要。

为什么?

因为现在的大模型能力其实已经不错了,GPT-5、Claude、DeepSeek 这些模型的理解和生成能力都很强。真正的瓶颈在于如何把这些能力转化成实际的业务价值。

这就需要大量的工程工作:

  • 如何设计合理的 Prompt,让模型理解业务需求
  • 如何构建知识库,让模型能够获取必要的信息
  • 如何设计工作流,让模型的输出能够被系统消费
  • 如何做异常处理,保证系统的稳定性
  • 如何做监控和优化,持续提升系统表现

这些工作属于比较累和碎的活儿,不如训练模型那么「高大上」,但却是 Agent 能否落地的关键。

7. 安全问题

AI Agent 的安全问题不仅仅是数据泄露,更大的问题在于,Agent 可能会做出一些不当的决策或者操作。

比如,一个有权限访问企业数据库的 Agent,如果被恶意引导,可能会删除重要数据或者泄露敏感信息。一个负责采购的 Agent,如果判断失误,可能会下错订单,造成巨大损失。如此种种……

现在的解决方案主要是加各种限制和审核机制,但这又回到了前面的矛盾:限制越多,Agent 就越不「智能」。

8. 可能的未来

基于目前的情况,我觉得接下来的一段时间 Agent 的发展会有几个趋势:

第一,从通用到垂直。越来越多的 Agent 会专注于特定的场景和行业。

第二,从替代到增强。Agent 的定位会从「替代人工」转变为「增强人工」。

第三,从单点到系统。不再是一个个孤立的 Agent,而是多个 Agent 协同工作的系统。

第四,从产品到服务。Agent 不再是一个买来就用的产品,而是需要持续优化的服务。

这些趋势意味着什么?

意味着 Agent 市场会越来越理性,泡沫会逐渐消失,真正有价值的应用会脱颖而出。

9. 最后

回到标题:AI Agent不够聪明

确实不够聪明,至少没有我们期望的那么聪明。

但这不意味着 Agent 没有价值。就像早期的计算机,虽然功能有限,但在特定场景下已经能创造巨大价值。关键是找到合适的场景,用合适的方式,解决真实的问题。

AI Agent 的发展还处于早期阶段,现在下结论还为时过早。但有一点是确定的:那些能够深入理解客户需求,扎实做好工程实施,持续优化产品体验的公司,最终会在这个市场上站稳脚跟。

至于 AI Agent 什么时候能真正「聪明」起来?我觉得还需要时间。可能是一年,可能是三年,也可能是五年。但在这个过程中,我们需要做的不是等待,而是不断探索、试错、优化,一步步接近那个目标。

毕竟,罗马不是一下子建成的,AI Agent 也不是。

以上。