分类目录归档：架构和远方

聊下 AI Agent 的 上下文工程（Context Engineering)

发表回复

2025 年确实成了 AI Agent 元年。不只是 Manus 这种通用型 Agent，还有设计领域的 Lovart、编程领域的 Claude Code 和 Cursor 等垂直产品。经常会有人问：这些 Agent 到底是如何工作的？为什么有的 Agent 看着很智能，有的却在掉链子？

大模型大家都可以用，但为啥结果差异比较大呢？

这是由于在大模型能力一致的前提下，决定 Agent 成败的，我们给它提供了多少有用的信息。这就是今天要聊的核心话题——从提示词工程到上下文工程的演进。

1. Agent 的三个核心动作

要理解上下文工程，我们得先从 AI Agent 的基本工作原理说起。简单来说，Agent 就像一个能自主完成任务的助手，它的工作流程可以概括为三个核心动作：感知、计划、行动。

1.1 感知

感知是 Agent 的第一步，也是最容易被忽视的一步。就像开车需要看清路况，Agent 需要准确理解当前的情况。

这里有个关键点：感知包含两个层面。

状态感知是对客观环境的理解。比如你让 Agent 帮你改代码，它需要知道：

  • 项目用的是什么语言和框架
  • 现有的代码结构是怎样的
  • 有哪些依赖和限制

意图感知则是理解你真正想要什么。当你说”优化这段代码”时，Agent 需要判断：

  • 是要提升性能还是改善可读性？
  • 有没有特定的性能指标要求？
  • 是否需要保持向后兼容？

很多 Agent 失败的案例，根源就在于感知出了问题。比如用户说”这个太慢了”，如果 Agent 只是机械地理解为”需要优化”，而没有深入了解具体慢在哪里、期望达到什么速度，那后续的优化很可能南辕北辙。

1.2 计划

有了准确的感知，Agent 需要制定行动计划。这就像做菜，你得先想好步骤：先切菜还是先热油，什么时候放调料。

计划能力很大程度上取决于底层的大语言模型。不同模型有不同的”性格”：

  • Claude 喜欢深思熟虑，会考虑多种可能性
  • GPT-4 比较均衡，执行标准任务很稳定
  • Gemini 更大胆，有时会提出创新方案

从技术架构上来说：

  • Gemini 侧重多模态融合和大规模上下文处理
  • Claude 专注于精确推理和复杂任务执行

但光有好模型还不够。Agent 的计划质量很大程度上取决于它掌握的信息是否充分。如果缺少关键信息，再聪明的模型也会做出糟糕的计划。

1.3 行动

最后是行动模块，让 Agent 真正能够”做事”。目前主流的实现方式是函数调用（Function Calling）——预先定义一系列工具函数，比如搜索网页、读写文件、发送邮件等，然后让模型根据需要调用这些函数。

这里面临的挑战是工具选择。当可用工具很多时，Agent 可能会困惑。就像给你一个装满各种工具的工具箱，如果不清楚每个工具的用途，很容易选错。

2. Agent 的四大支撑系统

除了核心的感知-计划-行动循环，现代 Agent 还需要四个重要的支撑系统：

2.1 记忆系统

记忆让 Agent 能够积累经验。就像人类一样，Agent 需要不同类型的记忆：

  • 工作记忆：处理当前任务的临时信息
  • 情景记忆：之前的对话和任务记录
  • 语义记忆：领域知识和最佳实践

但这里有个反直觉的发现：好的记忆系统不仅要会记住，更要会遗忘。

为什么？因为不是所有信息都值得保留。过时的信息、错误的尝试、无关的细节，如果都保存下来，反而会干扰 Agent 的判断。这就像你的电脑，定期清理缓存才能保持流畅运行。

2.2 工具系统

工具让 Agent 能够与外部世界交互。早期的 Agent 只能回答问题，现在的 Agent 可以：

  • 搜索信息
  • 操作文件
  • 调用 API
  • 甚至控制其他软件

Anthropic 推出的 MCP（Model Context Protocol）协议，试图为工具调用建立统一标准。这就像 USB 接口的标准化，让不同的工具都能方便地接入 Agent 系统。

2.3 安全系统

给 Agent 执行能力就像给孩子一把剪刀，必须要有安全措施。Manus 刚上线时就出现过安全问题，有人通过特殊的提示词，让 Agent 打包了执行环境的所有代码。

现代 Agent 通常采用多层防护：

  • 沙箱隔离：所有操作都在受控环境中执行
  • 权限管理：根据用户和场景动态分配权限
  • 审计日志：记录所有操作便于追溯

2.4 评估系统

如何判断一个 Agent 的表现？这比想象中复杂。不像传统软件有明确的对错，Agent 的输出往往有多种可能的”正确答案”。

评估需要考虑多个维度：

  • 任务完成度
  • 效率和成本
  • 用户满意度
  • 安全合规性

3. 从提示词工程到上下文工程

理解了 Agent 的工作原理，我们再来看看工程实践的演进。

3.1 提示词工程的局限

去年大家还在研究怎么写提示词。什么”你是一个专业的XX”、”请一步一步思考”，各种模板层出不穷。但很快我们发现，光靠精心设计的提示词，很难让 Agent 处理复杂任务。

原因很简单：提示词只是静态的指令，而真实任务需要动态的信息。

就像你请人帮忙，光说”帮我订个机票”是不够的，还需要告诉对方：

  • 出发地和目的地
  • 时间和预算
  • 个人偏好
  • 可用的支付方式

3.2 上下文工程的兴起

上下文工程是一个更宏大的概念。也有人说又是套壳包装了一下。但是我觉得非包装，而是大家对于如何和大模型交互有了更全面的认知。用 Shopify CEO Tobi Lütke 的话说，上下文工程是「提供所有必要上下文，让任务对 LLM 来说变得可解的艺术」。

上下文不只是提示词，而是 Agent 在生成回复前能看到的所有信息：

  1. 指令上下文：系统提示词、任务说明、行为规范
  2. 对话上下文：当前和历史对话记录，包含用户意图，如输出的结构
  3. 知识上下文：相关文档、数据库信息、搜索结果
  4. 工具上下文：可用函数的描述和使用方法
  5. 状态上下文：环境变量、用户偏好、系统状态

更重要的是，上下文工程是一个动态系统，不是静态模板：

  • 它根据任务类型选择相关信息
  • 它随着对话进展更新内容
  • 它平衡信息的全面性和简洁性

从终局的逻辑来看，上下文工程的结果还是给到大模型的提示词。

Google DeepMind 的一位工程师写了一篇博客，地址：www.philschmid.de/context-eng… 其中有一张图，如下：

image.png

讲了七个部分：

  • 指令 / 系统提示词：定义模型在对话过程中行为的初始指令集，可以/应该包含示例、规则等。
  • 用户提示词：来自用户的即时任务或问题。
  • 状态 / 历史记录（短期记忆）：当前对话，包括导致此刻的用户和模型响应。
  • 长期记忆：持久的知识库，从许多先前的对话中收集而来，包含已学习的用户偏好、过去项目的摘要，或被告知要记住以供将来使用的事实。
  • 检索信息（RAG）：外部的最新知识，从文档、数据库或API中获取的相关信息，用于回答特定问题。
  • 可用工具：它可以调用的所有函数或内置工具的定义（例如：check_inventory（检查库存）、send_email（发送邮件））。
  • 结构化输出：关于模型响应格式的定义，例如JSON对象。

这七个部分都包含在上面的 5 个上下文中。

4. 上下文工程的核心挑战

Karpathy 把 LLM 比作新型操作系统，上下文窗口就像 RAM。这个比喻很精确——就像内存管理是操作系统的核心功能，上下文管理是 Agent 工程的核心挑战。

主要挑战包括：

1. 容量限制 即使 Claude 已支持 20 万 token，Gemini 甚至支持 200 万 token，但这些容量在复杂任务面前仍然捉襟见肘。一个长时间运行的 Agent，轻易就能产生海量的交互记录。

2. 注意力分散 研究发现，当上下文过长时，模型会出现”迷失在中间”现象——对开头和结尾的内容记忆较好，但中间部分容易遗漏。这就像看一本太厚的书，中间章节的内容总是记不清。

3. 性能退化 过长的上下文不仅增加成本和延迟，还会降低模型的推理能力。Drew Breunig 总结了几种典型问题：

  • 上下文污染：错误信息影响后续判断
  • 上下文干扰：无关信息分散注意力
  • 上下文冲突：不同部分信息相互矛盾

5. 上下文工程的四种核心策略

面对这些挑战，有四种核心策略：

5.1 有选择的保存

这是把重要信息保存到上下文窗口之外，需要时再取用。

便签本模式：Agent 在执行任务时记笔记，保存中间结果和重要发现。Anthropic 的研究系统会在开始时制定计划并保存，避免因上下文截断而丢失。

长期记忆：跨会话保存的信息，包括用户偏好、领域知识、成功案例等。ChatGPT、Cursor 都实现了这种机制。

关键是要有选择地保存。不是什么都值得记住，需要识别真正有价值的信息。

5.2 选择对的信息

保存了信息，还需要在合适的时候取出来用。

记忆检索：当积累了大量记忆后，如何找到相关的部分？简单的关键词匹配往往不够，需要语义理解。ChatGPT 会根据当前对话内容，自动检索相关的历史记忆。

工具筛选：当可用工具很多时，全部列出会让模型困惑。研究表明，通过语义匹配只提供相关工具，可以将准确率提升 3 倍。

知识召回：这就是 RAG（检索增强生成）的核心。但实现好的 RAG 系统很有挑战。Windsurf 的工程师分享说，他们结合了多种技术：向量检索、关键词搜索、AST 解析、知识图谱，最后还要重排序。

5.3 压缩提炼

当信息太多时，需要压缩和精炼。

轨迹总结：Claude Code 的”自动压缩”功能就是典型例子。当上下文使用超过 95% 时，它会总结整个对话历史，保留关键信息的同时大幅减少 token 使用。

定点压缩：在特定环节进行信息精炼。比如搜索工具返回大量结果后立即总结，或者在不同 Agent 交接时压缩传递的信息。

智能裁剪：根据相关性和时效性，自动删除不必要的信息。可以基于时间（删除过早的对话）、频率（删除很少用到的信息）或相关性（删除与当前任务无关的内容）。

5.4 分而治之

把不同类型的信息分开管理，避免相互干扰。

多智能体架构：让不同的 Agent 处理不同的子任务，每个都有自己的上下文空间。Anthropic 的研究显示，多个专门的 Agent 往往比一个通用 Agent 表现更好。

环境隔离：HuggingFace 的做法很有启发——让 Agent 生成代码，在沙箱中执行，只把必要结果返回。这样可以把大量中间数据隔离在执行环境中。

状态分离：通过精心设计的状态结构，把不同类型的信息存在不同字段，只在需要时才暴露给模型。

6 小结

上下文工程正在成为 AI 工程师的核心技能。随着 Agent 能力的提升，如何管理和优化上下文将变得更加重要。

几个值得关注的发展方向：

  1. 自适应上下文：Agent 自己学习什么信息重要，自动调整上下文策略
  2. 分布式上下文：跨多个 Agent 和系统共享和同步上下文
  3. 个性化上下文：根据用户特点和偏好定制上下文管理策略
  4. 实时优化：在运行时动态调整上下文，而不是预先设定

当前不再是简单地“调教”模型说出正确的话，而是构建一个完整的信息系统，让 Agent 真正理解任务、掌握必要信息、做出正确决策。这种转变，预示着 AI Agent 正在从实验室的玩具，变成真正能够解决实际问题的工具。

如 Cognition 所说：”上下文工程实际上是构建 AI Agent 的工程师的头号工作。”。

以上。

终局思维 – 做时间的朋友

发表回复

上周，运营同学小 X 兴冲冲地找我：”老板，我这有个推广方案，算下来获客成本只要 30 块一个，要不要试试？”

她打开 PPT，里面密密麻麻的数据分析，转化漏斗画得很专业。看得出来，她花了不少心思。

“如果按照这个方案，”她继续说道，”投入 10 万，预计能带来 3000 多个新用户。相比其他渠道，这个 ROI 算是很不错了。”

我问了她一个问题：”假设这个方案真的有效，获客成本确实是 30 块。那么，你觉得我们会花 100 万、1000 万来做这个推广吗？”

小 X 愣住了。

“如果答案是不会，”我接着说，”那我们为什么要开始呢？”

这个对话，让我想起了一个词——终局思维，也就是今天我们要聊的。

我们都在用战术的勤奋，掩盖战略的懒惰

这些年，我见过太多类似的场景：

产品经理在复盘报告里写道：”本季度 DAU 增长 15%，用户留存提升 3 个百分点，各项指标都在往好的方向发展。”听起来很棒，但如果你问他：”按照这个增速，我们什么时候能实现盈利？”他可能就答不上来了。

技术负责人说：”我们这个月修复了 200 个bug，系统稳定性提升到 99.98%。”但如果你问：”这个系统三年后还在用吗？”大家都会沉默。

市场部说：”这次活动很成功，获得了 10 万次曝光。”但如果你问：”这 10 万次曝光最终能转化成多少有效用户？”数据就开始模糊了。

为什么会这样？因为我们都习惯了低头赶路，在自己熟悉的地方做事，却忘了抬头看路。

什么是终局思维

简单来说，终局思维就是从终点出发，倒推现在应该做什么。

这有点像下棋。新手下棋，只看眼前一两步。高手下棋，会在脑海中推演整盘棋的走向。当你知道最终要达到什么局面时，每一步棋都会有的放矢。

但在现实中，我们往往是反过来的：

  • 因为竞争对手在做，所以我们也要做
  • 因为这个功能用户有需求，所以我们要开发
  • 因为这个渠道便宜，所以我们要投放

这就像蒙着眼睛开车，也许能往前走，但很可能走错方向，或者原地打转。

一个价值千万的教训

2015 年，我在一家 P2P 公司做技术负责人。那时候正是 P2P 最火的时候，资本疯狂涌入，所有人都在抢市场份额。

我们的策略很简单：烧钱补贴，快速扩张。

运营团队每天都在汇报好消息：

  • “今天新增用户 5000！”
  • “这个月资金流水过亿了！”
  • “我们在这个城市的市场份额已经第二了！”

技术团队也跟着疯狂加班，不断开发新功能，支撑业务增长。最忙的时候，我们一周上线一个新的 APP。

直到有一天，CFO 在高管会上问了一个问题：”按照现在的烧钱速度，我们的钱还能烧多久？”

“大概 6 个月。”

“那 6 个月后呢？”

会议室里一片寂静。

后来的故事你们可能猜到了。寒冬来临，公司资金链断裂，不得不大规模裁员。那些曾经引以为豪的用户数据，在失去补贴后迅速归零。

这件事给我的教训是：如果一件事的终局不成立，那么过程中的所有努力都是徒劳。

终局思维的四个层次

经过这些年的实践和思考，我发现终局思维可以应用在不同的层次上：

1. 个人发展的终局思维

去年，团队里一个小伙伴找我聊职业规划。他很纠结：”我是继续做技术，还是转产品经理？”

我问他：”你想过5年后、10年后的自己是什么样子吗？”

“没想那么远，就是觉得产品经理好像更有前途。”

“那我们换个角度，”我说，”你觉得什么样的人生是成功的？”

他想了很久：”能够创造价值，被人需要，同时收入也不错。”

“那你觉得，是深耕技术更容易达到这个状态，还是转产品？”

这个问题让他陷入了沉思。一周后，他告诉我，他决定继续做技术，但会更多地从产品视角来思考技术问题。

现在，他已经是公司的技术架构师，不仅技术过硬，产品思维也很强。更重要的是，他找到了自己的方向。

2. 团队管理的终局思维

作为管理者，我经常问自己一个问题：三年后，我希望这个团队是什么样子？

基于这个思考，我做了几个看起来「不划算」的决定：

  • 投入 20% 的时间做技术分享和技术建设。： 很多人觉得这是浪费时间，直接写代码不是更高效吗？但我知道，一个学习型的团队才能持续成长。
  • 鼓励大家参与开源项目。： 短期看，这会占用工作时间。但长期看，这能提升团队的技术视野和影响力。
  • 坚持代码评审和文档规范。： 刚开始大家都觉得麻烦，但一年后，新人上手时间从一个月缩短到一周。

这些投入，在当下看都是成本，但从终局看都是投资。

3. 产品决策的终局思维

以某个曾经很火的工具类产品为例，最初是个简单好用的手机清理工具。但为了增长，不断添加功能：

  • 新闻资讯（因为能带来广告收入）
  • 小游戏中心（因为游戏分发赚钱）
  • 电商导购（因为电商返佣高）
  • 甚至还加了交友功能

结果原本的核心用户觉得产品变得臃肿，纷纷卸载。新功能带来的用户又留不住，因为有更专业的产品。最后，什么都想做，什么都做不好。

在产品决策时，终局思维体现在三个层面：

  • 第一，用户价值的终局。： 你要持续问自己：我们究竟在为用户解决什么问题？这个问题在未来是否依然存在？比如，Notion的终局是”第二大脑”。所以他们的每个功能都围绕着”如何更好地组织和连接信息”。即使用户要求加入视频会议功能，他们也拒绝了，因为这偏离了核心价值。
  • 第二，商业模式的终局。：产品最终靠什么赚钱？这个赚钱方式是否可持续？LinkedIn早期尝试过广告模式，但很快意识到，对专业人士来说，付费获得更好的求职和社交机会更合理。所以他们坚定地走付费会员路线，即使增长速度比免费模式慢，但用户质量和收入质量都更高。
  • 第三，竞争格局的终局。： 这个市场最终会是什么格局？赢家通吃还是百花齐放？视频会议市场，Zoom 意识到最终会是几家巨头共存（因为企业客户需要备选方案），所以专注于”最好用”而不是”功能最全”。而社交网络市场趋向赢家通吃，所以Facebook会不惜代价消灭或收购潜在对手。

产品决策的终局思维，不是让你预测未来，而是让你在每个决策点上问自己：这个选择是让我们离终局更近，还是更远？如果一个功能、一个项目、一个策略无法回答这个问题，那它可能就不该存在。

4. 技术架构的终局思维

技术选型是最需要终局思维的地方。

2021 年，我们要重构整个技术架构。团队里有很多声音：

  • “用最新的技术栈，保持技术领先！”
  • “用最稳定的方案，降低风险！”
  • “用最流行的框架，方便招人！”

我把大家召集起来，画了一张图：三年后，我们的技术架构应该是什么样子？

经过讨论，我们达成了共识：

  • 能支撑 10 倍的业务增长
  • 能快速响应业务变化
  • 能让团队规模化成长
  • 能控制运维成本

基于这个终局，我们选择了微服务架构，虽然初期投入大，但为后续的发展奠定了基础。现在回头看，这个决策帮我们节省了至少一年的时间。

如何培养终局思维

说了这么多，你可能会问：道理我都懂，但怎么才能真正做到呢？

1. 经常问「然后呢」

这是我养成的一个习惯。每当要做决策时，我都会连问三个「然后呢」：

  • 我们要做这个功能 → 然后呢？→ 用户会使用 → 然后呢？→ 提升用户活跃度 → 然后呢？→ 增加用户付费意愿…

通过不断追问，你会发现很多决策其实经不起推敲。

这里和我们常用的「5W」方法一样。

2. 学会算长期账

很多时候，我们被短期利益蒙蔽了双眼。

比如，为了完成这个月的 KPI，疯狂做活动拉新。但如果这些用户留存率很低，那么下个月你需要更多的活动来维持数据。这就像吸毒，越陷越深。

正确的做法是算长期账：这个用户的生命周期价值是多少？获客成本是多少？留存率如何？只有这些数据支撑，决策才不会跑偏。

3. 建立自己的原则

终局思维不是要你预测未来，而是要你建立原则。

比如几个原则：

  • 不做无法规模化的事情
  • 不做违背用户长期利益的事情
  • 不做团队无法持续的事情

有了原则，很多选择就变得简单了。

4. 定期复盘和调整

终局不是一成不变的。随着认知提升、环境变化，我们对终局的理解也会改变。

我的做法是，每个季度做一次深度思考：

  • 我们的终局假设还成立吗？
  • 有什么新的信息需要考虑？
  • 当前的路径是否需要调整？

记住，终局思维不是固执，而是在变化中保持方向感。

技术架构上三个常见的误区

在实践终局思维的过程中，特别是在技术决策中，也有不少坑。这里分享几个常见的误区：

误区1：过度设计的陷阱

很多技术团队在设计系统时，容易陷入”一步到位”的幻想。

典型的场景是这样的：某电商公司要做一个订单系统，技术负责人想：”既然亚马逊能做到每秒处理几十万订单，我们也要按这个标准设计。”

于是团队设计了一个”宏伟”的架构：

  • 完整的微服务拆分，订单、支付、库存、物流各自独立
  • 分库分表设计，预设了 1024 个分片
  • 引入了消息队列、分布式缓存、服务网格
  • 部署了完整的容器化方案

结果呢？系统上线一年，日订单量还不到 1000 单。那些精心设计的高并发方案，反而成了负担：

  • 运维成本极高，需要维护几十个服务
  • 开发效率极低，一个简单功能要改好几个系统
  • 故障率反而上升，因为链路太长太复杂

教训：终局思维不是让你现在就建造航母，而是让你的小船能够逐步升级成航母。

Netflix 的架构演进就是很好的例子。他们从单体应用开始，随着业务增长逐步拆分，而不是一开始就搞微服务。这种演进式的架构，才是真正的终局思维。

误区2：技术选型的赌徒心态

另一个常见误区是，把赌注全压在某个”未来技术”上。

如当年，GraphQL 刚火起来，某团队在新项目中全面使用。理由很简单：这是未来的趋势，早用早受益。

为了这个决定，他们：

  • 花了两个月培训团队
  • 重写了所有的 API 接口
  • 改造了前端的数据层
  • 甚至自己造了一些轮子

一年后回头看，GraphQL 确实有它的优势，但对当前的业务场景来说，REST API 完全够用。投入的成本，远远大于收益。

教训：技术的终局不是最新，而是最合适。

选择技术时，应该考虑：

  • 团队的学习成本
  • 社区的成熟度
  • 实际的业务需求
  • 长期的维护成本

不要因为某个技术”可能”是未来，就all in。技术债务，也是债务。

误区3：忽视路径依赖的理想主义

第三个误区是，只看到理想的终局，却忽视了现实的约束。

某个传统企业决定数字化转型，CTO 提出了一个激进的方案：”三年内，全面云原生化。”目标很美好：

  • 所有应用容器化
  • 全面使用云服务
  • 采用 DevOps 文化
  • 建立数据中台

但现实是：

  • 核心系统是20年前的COBOL代码
  • 运维团队平均年龄45岁，没人懂 Kubernetes
  • 很多业务逻辑藏在存储过程里
  • 合规要求数据不能出企业内网

强推的结果可想而知：

  • 老系统改造困难重重，进度一拖再拖
  • 团队抵触情绪严重，骨干员工纷纷离职
  • 新老系统并存，维护成本翻倍
  • 业务部门怨声载道，因为系统经常出问题

忽视现实约束的终局思维，不是思维，是幻想。

更深层的认知

这些误区背后，反映了一个更深层的问题：很多人把终局思维理解成了”终局决定论”。

真正的终局思维是什么？

  1. 它是指南针，不是 GPS

    • GPS 告诉你具体怎么走
    • 指南针只告诉你方向
    • 具体路径要根据地形（现实情况）调整

  2. 它强调的是进化，不是设计

    • 生物不是被设计出来的，是进化出来的
    • 好的架构也是如此，需要不断适应环境

  3. 它追求的是反脆弱，不是完美

    • 完美的系统往往很脆弱
    • 能够从失败中学习、进化的系统才是强大的

举个例子，Linux 的成功不是因为 Linus 一开始就设计好了一切，而是因为它的架构允许持续演进。相比之下，很多”设计完美”的操作系统都消失在历史长河中了。

在技术世界里，活下来的不是最强的，而是最能适应变化的。终局思维的真谛，是让你既有方向感，又保持灵活性。

做时间的朋友

终局思维的本质：不是追求当下的最优解，而是追求长期的最优解。

在这个快节奏的时代，大家都在追求快：

  • 快速成功
  • 快速变现
  • 快速增长

但真正有价值的东西，都需要时间来沉淀：

  • 深厚的技术功底，需要时间
  • 优秀的团队文化，需要时间
  • 忠诚的用户群体，需要时间
  • 持续的竞争优势，需要时间

所以，与其做时间的敌人，不如做时间的朋友。

其实，终局思维不是什么高深的理论，它只是提醒我们：

在奔跑之前，先想想要去哪里。

人生很长，不必着急。但人生也很短，不能迷路。

当我们学会站在终点看起点，很多困扰我们的问题都会迎刃而解。因为我们会发现，那些让我们焦虑的事情，在时间的长河里，不过是一朵小小的浪花。如当年韩寒在《三重门》中说的：「都只是棺木上的一缕尘埃」。

而那些真正重要的事情——我们的成长、我们的价值、我们的影响力——会像复利一样，随着时间的推移越来越有分量。

最后，问一句：

如果今天的选择，要用十年后的自己来买单，你还会这样选吗？

想清楚这个问题，你就拥有了终局思维。

愿我们都能成为时间的朋友，在正确的道路上，从容前行。

关于 AI Agent： 从 Manus 聊起

发表回复

最近几天 Manus 的新闻不停的出现在我的信息流中，从 Manus 官方账号清空了微博、小红书上的所有内容，到裁员争议，据说将核心技术人员迁往了新加坡。一个从北京、武汉出发的纯正中国公司，最终选择了离开。

还记得今年火热的 3 月，Manus 发布当天就引爆了社交网络。邀请码一码难求，甚至在二手平台被炒出天价。创始人肖弘（人称red）带领的这支年轻团队，用一个产品点燃了整个行业对 AI Agent 的热情。

2025 年是 AI Agent 元年。AI Agent 的发展速度惊人。不只是 Manus 这种通用型 Agent，还有各种垂直领域的，如 设计领域的 lovart，编程领域的 Claude Code Cursor 等等。

那什么是 AI Agent，它由什么组成？今天我们聊一聊。

1. 从专家系统说起

要说 AI Agent 的历史，得从上世纪 60 年代说起。那时候，计算机科学家们就在琢磨一个事：能不能让机器像人一样，自己去感知环境、做出决策、然后采取行动？

最早的尝试是专家系统。比如 1970 年代斯坦福大学开发的 MYCIN，这是一个诊断血液感染疾病的系统。它的工作方式很简单：问医生一堆问题，然后根据预设的规则给出诊断建议。虽然现在看来很原始，但在当时，这已经算是「智能」了。

到了 80 年代，出现了更复杂的系统，比如 R1/XCON，帮助 DEC 公司配置计算机系统。这些系统有个共同特点：它们都是基于规则的。你得事先把所有可能的情况都想到，然后写成 if-then 规则。问题是，现实世界太复杂了，你不可能把所有情况都考虑进去。

90 年代，研究者们开始尝试新的路子。他们发现，与其让人去编写所有规则，不如让机器自己去学习。于是有了基于机器学习的 Agent，比如强化学习 Agent。这些 Agent 可以通过试错来学习如何完成任务。

但真正的转折点出现在 2010 年代深度学习兴起之后。特别是 2017 年 Transformer 架构的出现，彻底改变了游戏规则。有了 GPT、BERT 这些大语言模型，AI Agent 突然变得「聪明」了很多。它们不再需要人类事先编写规则，而是可以理解自然语言，根据上下文做出合理的判断。

2. 现代 AI Agent 的样子

要理解现代的 AI Agent，我们得先搞清楚它到底是什么。

简单来说，AI Agent 就是一个能够自主感知环境、制定计划、采取行动来完成特定目标的系统。听起来很抽象？我举个例子：

假设你要让 AI 帮你订一张从北京到上海的机票。一个简单的聊天机器人可能只会回答：”请您登录航空公司网站自行预订。”但一个真正的 AI Agent 会这样做：

  1. 理解你的需求（什么时间、预算多少、有什么偏好）
  2. 搜索多个航空公司的航班信息
  3. 比较价格和时间
  4. 根据你的偏好筛选
  5. 甚至可能帮你完成预订（如果有相应的接口）

这就是 AI Agent 和普通 AI 应用的区别：它不是被动地回答问题，而是主动地解决问题。

3. 核心技术和架构

现在咱们来看看 AI Agent 是怎么实现的。核心架构可以分成四个部分：

3.1 感知模块

这是 Agent 的「眼睛」和「耳朵」。它需要理解用户的输入，同时还要感知环境的状态。比如，当你让 AI Agent 帮你写代码时，它需要理解：

  • 你想要实现什么功能
  • 使用什么编程语言
  • 有什么特殊要求
  • 当前的代码结构是什么样的

但这里有个关键点：感知模块需要区分两种不同的信息——状态上下文和意图上下文。

状态上下文是环境的客观信息。比如：

  • 当前项目使用的是 Python 3.9
  • 代码库里已经有了用户认证模块
  • 数据库是 MySQL
  • 使用的是的 FastAPI 框架

这些信息是确定的、可验证的事实。Agent 需要准确地获取和理解这些信息，因为任何误判都可能导致后续行动的失败。

意图上下文则是用户想要达成的目标，这往往更加模糊和主观。比如用户说「帮我优化一下这段代码」，Agent 需要理解：

  • 「优化」是指性能优化还是可读性优化？
  • 用户的性能预期是什么？
  • 有没有特定的约束条件？

区分这两种上下文至关重要。很多 AI Agent 的失败，就是因为混淆了状态和意图。比如，用户说「这个函数太慢了」，Agent 需要识别出：

  • 状态：函数执行时间是 500ms
  • 意图：用户希望降低到 100ms 以内

现代的 AI Agent 通过多种方式来增强感知能力：

多模态感知：不只是文字，还包括图像、语音、甚至视频。Cursor 支持图片上传，代码索引，文档等。

主动询问：当信息不充分时，优秀的 Agent 会主动提问。「你提到要优化性能，具体是想优化响应时间还是内存占用？」这种澄清式的对话，能大大提高后续行动的准确性。

历史记录：通过分析用户的历史行为，Agent 可以更好地理解当前的意图。如果用户之前多次要求「简洁的代码」，那么在新的任务中，Agent 就会倾向于生成更简洁的解决方案。

环境探测：高级的 Agent 还会主动探测环境。比如，在开始写代码前，它可能会先检查项目的配置文件、依赖列表、测试用例等，构建一个完整的环境画像。

感知的准确性直接决定了 Agent 的表现。一个看不清路的司机，再好的驾驶技术也没用。同样，一个不能准确理解用户意图和环境状态的 Agent，后续的规划和执行必然会出问题。

3.2 推理模块

这是 Agent 的「大脑」，也就是大语言模型。现在主流的做法是使用 GPT-4、Claude、Gemini 这样的大模型。但光有大模型还不够，还需要深入理解不同模型的特性，才能让它们更好地工作。

模型的性格差异

就像人有不同的性格，AI 模型也有各自的「个性」。这不是玄学，而是训练方式和优化目标的差异造成的。

以 Cursor 编辑器的实践为例，他们把模型分为两大类：

思考型模型（Thinking Models）：

  • Claude 3 Opus：喜欢先理解全局，会主动推断你的意图
  • Gemini 2.0 Flash：自信果断，经常会做出超出预期的大改动
  • o1：专门为复杂推理设计，会花时间深入分析问题

这类模型就像经验丰富的专家，你给它一个大方向，它会自己规划路径。适合探索性任务、大规模重构、或者当你自己也不太确定最终方案时使用。

执行型模型（Non-thinking Models）：

  • Claude 3.5 Sonnet：等待明确指令，不会过度推断
  • GPT-4 Turbo：行为可预测，适合精确控制
  • 文心一言 4.0：在中文任务上表现稳定

这类模型像是可靠的助手，严格按照你的要求执行。适合明确的任务、需要精确控制的场景、或者当你已经知道要做什么时使用。

选择模型的艺术

选择合适的模型，就像选择合适的工具。你不会用大锤子去拧螺丝，也不会用螺丝刀去砸钉子。

根据任务类型选择：

  • 代码生成：Claude 3.5 Sonnet 和 GPT-4 都很优秀
  • 代码理解和重构：Gemini 2.0 Flash 的长上下文能力突出
  • 复杂 Bug 调试：o1 的深度推理能力更适合
  • 中文文档处理：通义千问、豆包有本土优势

根据交互风格选择：

  • 如果你喜欢给出详细指令：选择执行型模型
  • 如果你偏好给出大方向：选择思考型模型
  • 如果你需要创造性方案：选择更”活跃”的模型
  • 如果你需要稳定输出：选择更”保守”的模型

提示词工程的进化

早期的 AI Agent 严重依赖精心设计的提示词。但随着模型能力的提升，这种情况正在改变。

从复杂到简单： 过去我们可能需要这样的提示词：

你是一个专业的Python开发者。请严格遵循PEP8规范。
在编写代码时，请考虑以下几点：
1. 代码的可读性
2. 性能优化
3. 错误处理
...（还有20条）

现在，一句简单的”帮我优化这段代码”就能得到不错的结果。

动态提示词策略： 现代 AI Agent 会根据上下文动态调整提示词：

  • 初次对话：使用更详细的背景说明
  • 后续对话：只提供增量信息
  • 错误修正：加入具体的约束条件
  • 创造性任务：减少限制，鼓励探索

混合模型策略

越来越多的 AI Agent 开始采用混合模型策略，在一个任务流程中使用多个模型：

  1. 理解阶段：使用 Claude 3 Opus 深入分析需求
  2. 规划阶段：使用 o1 制定详细的执行计划
  3. 执行阶段：使用 GPT-4 Turbo 快速生成代码
  4. 优化阶段：使用专门的代码模型进行微调

这种方式能够充分发挥每个模型的优势，同时控制成本。

3.3 记忆模块

人做事情需要记住前面发生了什么，AI Agent 也一样。记忆分成几种：

  • 短期记忆：当前对话的上下文
  • 长期记忆：之前的对话历史、学到的知识
  • 工作记忆：执行任务过程中的中间状态

但实现一个好的记忆系统，比想象中要复杂得多。

3.3.1 记忆的层次结构

就像人脑有不同类型的记忆，AI Agent 的记忆系统也需要分层设计：

感知记忆（Sensory Memory）：

  • 保存时间：几秒到几分钟
  • 内容：用户刚刚的输入、系统刚刚的输出
  • 用途：处理连续对话中的指代关系

工作记忆（Working Memory）：

  • 保存时间：整个任务周期
  • 内容：当前任务的状态、中间结果、待办事项
  • 用途：复杂任务的分步执行

情景记忆（Episodic Memory）：

  • 保存时间：数天到数月
  • 内容：完整的对话历史、任务执行记录
  • 用途：理解用户偏好、避免重复错误

语义记忆（Semantic Memory）：

  • 保存时间：永久
  • 内容：领域知识、最佳实践、学到的模式
  • 用途：积累经验、提升能力

3.3.2 实现方案-RAG（检索增强生成）

这是目前最成熟的方案。基本思路是：当 AI Agent 需要回答问题时，先去知识库里检索相关信息，然后把这些信息作为上下文提供给大模型。

比如你问：”我们公司的年假政策是什么？”Agent 会先去检索公司的政策文档，找到相关内容，然后基于这些内容生成回答。

RAG 的进化史

第一代 RAG（2020-2022）：

  • 简单的向量检索
  • 使用 BERT 或 Sentence-BERT 做编码
  • 召回 Top-K 相关文档
  • 效果一般，经常找不到真正相关的内容

第二代 RAG（2023-2024）：

  • 引入混合检索（向量+关键词）
  • 使用更强的编码模型（如 BGE、E5）
  • 加入重排序（Reranking）步骤
  • 开始考虑文档结构和语义分块

第三代 RAG（2024-现在）：

  • 多级索引结构（摘要→章节→段落）
  • 查询改写和扩展
  • 动态上下文窗口调整
  • 引入知识图谱增强检索

实践中的 RAG 优化技巧

  1. 智能分块：不要机械地按字数切分，而是按语义单元切分

    • 代码：按函数/类切分
    • 文档：按章节/段落切分
    • 对话：按话轮切分

  2. 多路召回：同时使用多种检索策略

    • 向量相似度检索
    • BM25 关键词检索
    • 实体链接检索
    • 基于图的检索

  3. 上下文工程：检索到的内容需要精心组织

  4. 增量索引：新知识的实时更新

    • 使用流式处理架构
    • 支持热更新索引
    • 版本控制和回滚机制

3.3.3 实现方案-超长上下文

最新的趋势是直接增加模型的上下文长度。比如 Claude 3 已经支持 200K token 的上下文，Gemini 1.5 Pro 甚至支持 200 万 token。

长上下文的真实挑战

虽然模型号称支持超长上下文，但实际使用中会遇到很多问题：

  1. 「迷失在中间」现象：模型对上下文开头和结尾的内容记忆较好，但中间部分容易遗忘

  2. 注意力稀释：上下文越长，模型对每个部分的注意力就越分散

  3. 推理退化：在超长上下文中，模型的推理能力会显著下降

混合方案：长上下文 + 选择性注意

3.3.4 主动遗忘

这是一个反直觉但很重要的概念：不是记住越多越好，而是要学会遗忘。

为什么需要遗忘？

  1. 降噪：不是所有信息都值得记住
  2. 隐私：某些敏感信息需要及时删除
  3. 效率：保持记忆系统的高效运转
  4. 相关性：过时的信息可能产生负面影响

遗忘策略

  1. 基于时间的遗忘：

    • 会话结束后 24 小时删除临时信息
    • 30 天后归档低频访问的记忆
    • 90 天后删除无用的错误记录

  2. 基于重要性的遗忘：

    • 使用 LRU（最近最少使用）策略
    • 基于访问频率的动态评分
    • 保留高价值的”关键时刻”

  3. 基于相关性的遗忘：

    • 当新信息与旧信息冲突时，更新而非累加
    • 合并相似的记忆，避免冗余
    • 定期整理和压缩记忆库

3.4 行动模块

这是 Agent 的「手脚」，让它能够真正做事情。

行动模块的核心是 Function Calling（函数调用），这是目前最主流的方式。

简单来说，就是预先定义好一系列函数，比如搜索网页、查询数据库、发送邮件等，然后告诉大模型这些函数的作用和参数。

当用户提出需求时，模型会判断需要调用哪个函数，提取相应的参数，执行函数并获取结果。这个过程已经从最初的单次调用，进化到现在可以进行多步骤调用、并行执行、错误重试等复杂操作。

Anthropic 推出的 MCP（Model Context Protocol）协议，试图建立行动模块的统一标准。

MCP 采用服务器-客户端架构，工具提供方作为服务器，AI 应用作为客户端，通过标准化的协议进行通信。这种设计的好处是解耦和复用：AI 应用不需要知道工具的具体实现细节，一个 MCP 服务器可以同时服务多个 AI 应用。更重要的是，MCP 提供了统一的安全管理和权限控制机制，让行动模块的集成变得更加简单和安全。

安全性是行动模块最关键的考虑因素。

在 Manus 刚上线的时候就爆出一个问题，有人用提示词，让 AI Agent 打包了当前执行的环境的所有代码。

给 AI 执行能力就像给孩子一把剪刀，必须设置严格的安全边界。现代 Agent 通常采用多层防护：首先是沙箱环境，所有代码执行都在隔离的容器中进行，限制内存、CPU、网络访问；其次是权限管理，基于用户角色和具体场景动态分配权限；最后是审计日志，记录所有行动的执行情况，便于追溯和分析。这些措施确保 Agent 在帮助用户的同时，不会造成安全风险。

复杂任务往往需要多个行动的协调配合，这就需要工作流引擎来编排。比如”帮我分析竞品并生成报告”这个任务，可能需要先搜索竞品信息，然后提取关键数据，接着进行对比分析，最后生成可视化报告。工作流引擎负责管理这些步骤的执行顺序、处理步骤间的数据传递、应对执行失败等情况。高级的引擎还支持条件分支、循环执行、并行处理等复杂逻辑，让 Agent 能够处理更加复杂的任务。

行动模块的未来发展方向是更强的自主性。目前的 Agent 主要执行预定义的动作，但未来可能会具备动作发现和学习能力，能够自动发现新的 API、学习新的操作模式、甚至创造性地组合已有动作来完成新任务。另一个重要方向是与物理世界的交互，通过机器人或 IoT 设备执行物理动作。随着这些能力的提升，AI Agent 将真正从「会说」进化到「会做」，成为人类在数字世界和物理世界中的得力助手。

4. 当前的局限性

AI 有其局限性，了解这些局限性，对于合理使用和未来改进都很重要。

4.1 幻觉问题

这是所有基于大模型的 AI Agent 都面临的核心挑战。

Agent 可能会编造不存在的 API、虚构执行结果、或者对自己的能力过度自信。比如，当你要求 Agent 查询某个数据库时，它可能会返回看起来合理但实际上完全虚构的数据。

这种幻觉在连续多步骤的任务中会被放大，一个小错误可能导致整个任务链的崩溃。

更危险的是，这些幻觉往往很难被发现，因为它们在表面上看起来完全合理。虽然通过 RAG、工具调用验证等方法可以部分缓解，但彻底解决仍然是个开放性难题。

4.2 可靠性不足

AI Agent 的表现稳定性仍然是个大问题。

同样的任务，在不同时间执行可能得到不同的结果。

这种不确定性来源于多个方面：模型本身的随机性、上下文理解的偏差、外部环境的变化等。

在一些对可靠性要求高的场景，比如金融交易、医疗诊断、工业控制等，目前的 AI Agent 还远远达不到要求。

即使加入了重试机制、结果验证等保障措施，也只能提高而非保证可靠性。这导致在关键业务场景中，AI Agent 更多是作为辅助而非主导。

4.3 成本与效率

运行一个功能完善的 AI Agent 系统成本不菲。

首先是模型调用成本，特别是使用 GPT-4、Claude 等顶级模型时，每次交互都要花费不少钱。复杂任务可能需要多次模型调用，成本会快速累加。

其次是延迟问题，每次函数调用、每次推理都需要时间，一个看似简单的任务可能需要等待数十秒甚至几分钟。对于需要实时响应的场景，当前的 AI Agent 往往力不从心。

虽然可以通过模型蒸馏、缓存优化等手段降低成本，但在性能和成本之间找到平衡点仍然很困难。

4.4 安全与隐私挑战

AI Agent 需要访问大量数据和系统才能发挥作用，这带来了严重的安全隐私问题。

首先是数据泄露风险，Agent 可能无意中将敏感信息包含在给大模型的请求中，而这些数据可能被用于模型训练。

其次是提示注入攻击，恶意用户可能通过精心构造的输入操控 Agent 执行非预期的操作。

还有权限滥用问题，一个被赋予过多权限的 Agent 可能造成严重损害。

虽然业界正在开发各种防护措施，如差分隐私、安全沙箱、细粒度权限控制等，但攻防对抗仍在继续。

4.5 理解与推理的局限

虽然大模型展现出了惊人的能力，但 AI Agent 在深层理解和复杂推理方面仍有明显不足。它们往往只能处理相对直接的任务，面对需要长链条推理、创造性思维或深层次理解的问题时就会暴露短板。

比如，Agent 可能很擅长执行”帮我订一张机票”这样的任务，但如果要求”帮我规划一个考虑预算、时间、个人兴趣的完整旅行方案”，效果就会大打折扣。

此外，Agent 缺乏真正的常识推理能力，可能会提出一些违背基本常识的方案。即使是最新的 o1 模型，虽然推理能力有所提升，但距离人类水平的推理能力还有很大差距。

5. 写在最后

AI Agent 的发展才刚刚开始。虽然现在的技术还不完美，但进步的速度是惊人的。两年前，我们还在惊叹 ChatGPT 能够进行对话；现在，AI Agent 已经能够帮我们写代码、分析数据、制定计划了。

对于技术人员来说，现在是最好的时代。我们有机会参与到这场变革中，创造出真正有用的 AI Agent。但同时，我们也要保持清醒：AI Agent 是工具，不是魔法。它能够提高效率，但不能替代人类的创造力和判断力。

未来的世界，可能每个人都会有自己的 AI Agent 团队。就像现在每个人都有智能手机一样自然。

而现在，正是这个未来的开端。

以上。