导读：本文是“数据拾光者”专栏的第一百零四篇文章，这个系列将介绍在AI领域中的一些学习和思考，以及实战中的经验教训总结。本篇主要是学习大模型Agent以及上下文工程技术。
欢迎转载，转载请注明出处以及链接，更多关于自然语言处理、推荐系统优质内容请关注如下频道。
知乎专栏：数据拾光者
公众号：数据拾光者

如果你用过 ChatGPT、文心一言这类大模型，可能会有这样的体验：问它“今天北京的天气如何”，它能准确回答。但如果让它 “帮我订一张周末去上海的高铁票，再推荐几家附近的酒店”，它就会束手无策：因为它既不能调用购票软件，也无法实时查询酒店信息，更没法把 “周末出行” 这个需求串联起来。

这背后的核心差异，就是 “普通大模型” 和 “大模型 Agent” 的区别。前者像一个 “超级问答机器”，后者则更像一个 “能自主办事的助手”。而让 Agent 真正 “懂事”、“能办事” 的关键，就是我们今天要聊的 ——上下文工程。

这篇文章会用最通俗的语言，带你搞懂大模型 Agent 是什么、它怎么工作，以及上下文工程如何成为它的 “记忆中枢” 和 “决策依据”。

01 大模型 Agent 到底是什么？

我们先从一个生活场景切入：假设你让同事 “帮你处理一个客户需求”，同事会做什么？

1. 先问清楚客户的需求细节（比如 “客户想要修改合同哪部分？截止时间是什么时候？”）；

2. 回忆之前和这个客户的合作记录（比如 “上次客户强调过付款周期不能超过 30 天”）；

3. 规划处理步骤（比如 “先联系法务确认修改可行性，再写邮件和客户沟通，最后更新合同版本”）；

4. 遇到问题时调整方案（比如 “法务说修改条款有风险，那就和客户协商折中方案”）；

5. 最后把结果反馈给你（比如 “合同修改好了，客户已确认，文件发你邮箱”）。

这个能 “主动沟通、回忆信息、规划步骤、解决问题、反馈结果” 的同事，其实就是一个 “人类 Agent”。而大模型 Agent，就是让大模型具备类似人类的 “自主办事能力”—— 它不再局限于 “你问一句，它答一句”，而是能理解复杂需求、调用工具、记忆上下文、调整策略，最终完成一个完整的任务。

Agent 的核心价值：解决 “大模型做不了的事”

普通大模型的局限很明显：

• 无法实时获取信息（比如查最新天气、股票行情）；

• 不能调用外部工具（比如发邮件、订车票、算数据）；

• 记不住长流程的需求（比如聊了 10 轮后，忘了最初的目标）；

• 不会主动规划步骤（比如你说 “帮我做个旅行计划”，它只会列一堆景点，不会问你 “预算多少？喜欢自然风光还是人文？”）。

而 Agent 就是为解决这些问题而生的。它的应用场景，早已渗透到我们的工作和生活中：

简单说，普通大模型是 “知识问答工具”，Agent 是 “任务执行助手”—— 前者帮你 “解惑”，后者帮你 “做事”。

02 Agent 的 “核心动作”：感知、计划、行动和评估，缺一不可

要让 Agent 完成一个任务，就像让一个人完成工作一样，需要三个关键步骤：先搞清楚 “发生了什么”（感知），再想 “该怎么做”（计划），最后动手 “去做”（行动）。这三个动作循环往复，直到任务完成。

我们用 “帮你订一张周五晚上从北京到上海的高铁票” 这个任务，拆解 Agent 的三大动作：

2.1 感知：搞清楚 “需求和环境”

感知的核心是 “收集信息”—— 包括用户的需求、当前的环境、历史的记录。就像你同事先问你 “订几点的？要靠窗还是过道？”，Agent 的感知也是同理：

• 用户需求感知

  ：先确认模糊需求中的细节。比如你说 “订周五去上海的高铁”，Agent 会追问：“周五具体哪个时间段？需要一等座还是二等座？是否有偏好的车次？”

• 环境信息感知

  ：获取实时外部信息。比如 Agent 会调用 12306 接口，查询周五北京到上海的余票情况（比如 “18:00 的 G101 还有 3 张二等座，20:00 的 G103 余票充足”）。

• 历史信息感知

  ：回忆过往的记录。比如 Agent 发现你上次订高铁选了靠窗座位，会优先推荐：“根据你上次的偏好，为你推荐靠窗的座位，是否需要调整？”

没有感知，Agent 就会 “瞎做事”—— 比如你明明想订周五晚上的票，它却订了周五早上的，这就是感知不到需求细节的后果。

2.2 计划：想清楚 “步骤和备选方案”

计划的核心是 “拆解任务”—— 把一个复杂需求，拆成多个可执行的小步骤，同时准备备选方案（防止一步错、步步错）。

比如订高铁票的计划步骤：

1. 确认用户最终需求（比如 “周五 18:00 左右、二等座、靠窗”）；

2. 调用 12306 接口查询对应车次的余票；

3. 若有余票，生成订单并发送给用户确认；

4. 若没有余票，推荐相近时间段的车次（比如 “18:00 的 G101 已无票，是否考虑 17:30 的 G100 或 18:30 的 G102？”）；

5. 用户确认后，完成支付流程；

6. 支付成功后，发送订单信息到用户手机。

这个计划里，每一步都有明确的目标，同时还考虑了 “没余票” 的备选方案 —— 这就是 Agent 比普通大模型强的地方：它不会因为一步受阻就停滞，而是会主动调整。

2.3 行动：动手 “执行步骤并反馈”

行动的核心是 “落地执行”—— 根据计划好的步骤，调用工具、完成操作，同时实时反馈进度。

比如订高铁票的行动环节：

• 调用工具：Agent 调用 12306 的 API 接口，查询余票、生成订单；

• 执行操作：用户确认后，Agent 触发支付链接，完成订单提交；

• 反馈进度：每一步都告诉用户 “现在在做什么”—— 比如 “正在查询 18:00 的 G101 余票… 已查询到 3 张余票，正在生成订单… 订单已生成，请点击链接支付… 支付成功，订单号为 XXX，已发送短信到你手机”。

行动不是 “一次性操作”，而是 “边执行边反馈”—— 如果支付时出现问题（比如银行卡余额不足），Agent 会及时提醒：“检测到支付失败，可能是余额不足，是否需要更换支付方式？”

2.4 评估：检查做得好不好

除了感知、计划、行动，Agent 还有第四个核心动作：评估—— 也就是 “检查做得好不好”。比如订完票后，Agent 会评估：“用户是否收到订单短信？订单信息是否正确？用户是否有后续需求（比如推荐上海的酒店）？”

如果评估发现问题（比如用户没收到短信），Agent 会主动补救：“检测到你未收到订单短信，是否需要重新发送？或我直接读给你听？”

这四个动作（感知→计划→行动→评估）循环起来，就构成了 Agent 的 “自主办事能力”—— 就像一个靠谱的同事，能把事情从头到尾做好，还会主动解决过程中的问题。

03 Agent的支撑系统：没有这些支撑，Agent 就是 “空壳”

如果说 “感知、计划、行动，评估” 是 Agent 的 “手脚”，那支撑系统就是 Agent 的 “五脏六腑”—— 没有这些系统，Agent 就没法正常工作。就像一个人需要大脑（记忆）、工具（手的延伸）、安全意识（保护自己），Agent 也需要四大支撑系统：

3.1 记忆系统：Agent 的 “大脑记忆库”

普通大模型的 “记忆” 是临时的 —— 比如你和 ChatGPT 聊了 10 轮后，再问 “我们之前聊的第一个话题是什么”，它可能记不清了（因为上下文窗口有限）。但 Agent 的记忆系统是 “持久且有序的”，能记住长期的信息。

记忆系统分为两类：

• 短期记忆（上下文记忆）

  ：记住当前任务的临时信息。比如订高铁票时，记住 “用户要订周五 18:00 的二等座”—— 这个信息只在本次任务中有用，任务完成后可以暂时存档。

• 长期记忆（知识库记忆）

  ：记住长期有用的信息。比如用户的身份证号、常用联系人、偏好座位、常用支付方式 —— 这些信息可以长期保存，下次用户再订车票时，不用重复询问。

举个例子：如果你第一次用 Agent 订车票，需要输入身份证号；第二次再用，Agent 会从长期记忆中调出你的身份证号，问你 “是否使用上次的身份证号（11010XXXXXXX）订车票？”—— 这就是长期记忆的作用。

3.2 工具系统：Agent 的 “手脚延伸”

Agent 自己不能 “直接做事”—— 比如它没法自己打开 12306 网站，也没法自己发邮件。工具系统就是 Agent 的 “外接手脚”，让它能调用外部工具完成操作。

常见的工具类型有：

• 信息查询工具

  ：比如调用天气 API 查天气、调用股票 API 查行情、调用地图 API 查路线；

• 操作执行工具

  ：比如调用邮件 API 发邮件、调用日历 API 添加日程、调用支付 API 完成支付；

• 专业处理工具

  ：比如调用 Excel 工具处理数据、调用代码编译工具测试代码、调用设计工具生成图片。

比如你让 Agent“帮我把上周的销售数据做成图表，发给老板”，Agent 的工具系统会：

1. 调用 Excel 工具，读取销售数据并生成柱状图；

2. 调用邮件工具，把图表作为附件，发送到老板的邮箱；

3. 调用日历工具，给你添加一个 “确认老板是否收到邮件” 的提醒。

没有工具系统，Agent 就是 “光说不练的嘴炮”—— 只能告诉你 “应该怎么做”，却没法真正动手。

3.3 安全系统：Agent 的 “防护盾”

Agent 能调用工具、处理敏感信息（比如你的身份证号、支付密码），如果没有安全系统，很容易出现 “信息泄露” 或 “恶意操作”。安全系统的核心是 “防风险”，主要包括：

• 权限控制

  ：比如 Agent 只能调用你授权的工具 —— 你没授权它访问你的银行卡余额，它就不能调用支付工具查余额；

• 敏感信息保护

  ：比如你的身份证号、手机号，Agent 会加密存储，不会明文显示或传给第三方；

• 操作审核

  ：比如 Agent 要进行支付操作时，必须先让你确认 “是否同意支付 XXX 元”，防止误操作或恶意操作；

• 风险识别

  ：比如 Agent 发现你要订的车次 “票价异常高”（比平时贵 3 倍），会提醒你 “当前车次票价可能存在异常，是否确认继续预订？”

举个例子：如果你用 Agent 处理工作邮件，安全系统会确保 Agent 只发送你指定的内容，不会把你电脑里的私人文件不小心附带上 —— 这就是安全系统的作用。

3.4 评估系统：Agent 的 “自我检查仪”

评估系统是 Agent 的 “自我纠错机制”—— 它会不断检查 “做得对不对、好不好”，如果发现问题，及时调整。

评估系统主要做两件事：

• 过程评估

  ：检查每一步行动是否符合计划。比如 Agent 订高铁票时，发现 “调用 12306 接口失败”，会评估 “是网络问题还是接口问题”，然后调整方案（比如 “接口暂时不可用，是否改用其他购票平台？”）；

• 结果评估

  ：检查最终结果是否满足用户需求。比如订完票后，评估 “用户是否收到订单信息？订单时间、车次是否和用户需求一致？” 如果发现 “车次订错了”，会主动补救（比如 “抱歉，刚才订错了车次，已为你取消订单并重新预订，耽误你的时间了”）。

没有评估系统，Agent 就会 “一条路走到黑”—— 比如订错了车次却不知道，直到用户发现才补救，体验会非常差。

04 Agent的核心引擎：从提示词工程到上下文工程

聊完了 Agent 的动作和支撑系统，我们来聚焦最关键的部分 ——上下文工程。它是 Agent “记忆系统” 的核心，也是连接 “感知、计划、行动、评估” 的桥梁。

在讲上下文工程之前，我们先搞懂：它和我们常说的 “提示词工程” 有什么区别？

4.1 提示词工程：Agent 的 “临时便签”

提示词工程（Prompt Engineering）是我们和大模型交互的基础 —— 比如你说 “写一篇关于春天的短文，300 字左右”，这句话就是提示词。它的本质是 “给大模型一个明确的指令，让它生成想要的结果”。

但提示词工程有个很大的问题：它只能处理 “单次、独立” 的任务，没法应对 “长期、复杂” 的任务。

举个例子：如果你用提示词工程让大模型 “帮你写一个产品推广方案”，你需要一次性把所有需求说清楚：
“产品是一款智能手表，目标用户是 20-30 岁的年轻人，卖点是续航长（7 天）、能测心率，预算 5000 元，推广渠道要包括小红书和抖音，方案要包含活动流程和预算分配。”

如果你的需求没说全（比如忘了说 “推广时间是下周”），就需要重新发一个提示词：“补充一下，推广时间是下周，方案里要加上时间节点。”

这就像你给同事写了一张 “临时便签”，如果便签没写全，就得再写一张 —— 同事没法把多张便签的信息自动串联起来。

提示词工程的核心问题：

1. 上下文断裂

   ：每一次提示词都是 “新的开始”，大模型记不住上一次的信息（除非你把所有历史对话都复制到新提示词里，很麻烦）；

2. 信息过载

   ：如果任务复杂（比如写 10 页的方案），提示词会非常长，大模型可能抓不住重点；

3. 缺乏灵活性

   ：如果任务过程中需求变了（比如你突然想把预算从 5000 元改成 8000 元），需要重新写提示词，大模型没法 “实时调整”。

正是因为这些问题，我们才需要 “上下文工程”—— 它能让 Agent 像人一样，“记住所有相关信息，并且灵活调用”。

4.2 上下文工程：Agent 的 “智能笔记本”

如果说提示词工程是 “临时便签”，那上下文工程就是 “智能笔记本”—— 它会把所有和任务相关的信息（用户需求、历史对话、工具反馈、计划步骤）都整理、存储起来，并且在需要的时候自动调取。

举个例子：还是 “写产品推广方案” 的任务，用上下文工程的 Agent 会这样做：

1. 你第一次说 “帮我写一个智能手表的推广方案”，Agent 会记录 “任务：智能手表推广方案”，然后追问细节（“目标用户、卖点、预算、渠道有哪些？”）；

2. 你回答 “目标用户 20-30 岁年轻人，卖点续航 7 天、测心率，预算 5000 元，渠道小红书 + 抖音”，Agent 会把这些信息补充到 “笔记本” 里；

3. Agent 生成第一版方案后，你说 “预算改成 8000 元，加一个微博渠道”，Agent 会在 “笔记本” 里更新 “预算：8000 元，渠道：小红书 + 抖音 + 微博”，然后基于更新后的信息调整方案；

4. 最后你说 “方案里加一个时间节点，下周开始”，Agent 会再次更新 “笔记本”，并补充时间规划。

整个过程中，你不需要重复说 “产品是智能手表”“目标用户是年轻人”—— 因为这些信息都存在 Agent 的 “智能笔记本” 里，它会自动调用。

上下文工程的核心优点：

1. 信息持久化

   ：所有相关信息都被保存，不会 “聊完就忘”；

2. 信息关联化

   ：自动把 “用户需求、历史对话、工具反馈” 关联起来（比如把 “预算 8000 元” 和 “渠道增加微博” 关联到 “智能手表推广方案” 这个任务上）；

3. 灵活调整

   ：需求变化时，只需要补充新信息，Agent 会自动更新上下文，不用重新开始；

4. 降低认知负担

   ：用户不用一次性说清所有需求，可以逐步补充，体验更自然。

简单说，提示词工程是 “你喂它什么，它吃什么”，上下文工程是 “它记着你喂过的所有东西，还能自己整理”。

4.3 上下文工程的核心策略：怎么让 “笔记本” 更高效？

上下文工程不是 “把所有信息都堆进去”—— 如果信息太多、太乱，Agent 反而会 “找不到重点”。就像你的笔记本如果记满了无关内容，找东西会很麻烦。

高效的上下文工程，需要四个核心策略：

策略 1：有选择的保存 —— 只记 “有用的信息”

不是所有信息都需要保存，比如你和 Agent 闲聊 “今天天气真好”，这句话和 “订高铁票” 任务无关，就不需要保存到上下文里。

选择保存的标准：

• 和任务目标相关

  ：比如订高铁票时，“周五 18:00、二等座、靠窗” 这些信息必须保存；

• 有长期复用价值

  ：比如用户的身份证号、偏好座位，下次订车票还能用，需要长期保存；

• 能影响后续决策

  ：比如 “18:00 的车次没余票” 这个工具反馈，会影响后续推荐其他车次，需要保存。

反例：如果 Agent 把你说的 “今天中午吃了汉堡” 也保存到订车票的上下文里，反而会干扰它的决策 —— 这就是 “无选择保存” 的弊端。

策略 2：选择对的信息 —— 用 “结构化” 代替 “杂乱文字”

如果上下文里的信息是杂乱的文字（比如 “用户说周五晚上想走，要二等座，最好靠窗，对了，上次他选的是靠窗”），Agent 需要花时间提炼重点。而 “结构化信息” 能让 Agent 一眼看到关键内容。

比如用表格保存订车票的上下文信息：

结构化的信息，能让 Agent 快速定位到 “用户要什么、当前情况如何”，避免在杂乱文字里 “找重点”。

策略 3：压缩提炼 —— 把 “长信息” 变 “短信息”

如果上下文里有很长的内容（比如用户发了一段 500 字的需求描述），Agent 处理起来会很慢。这时候需要 “压缩提炼”—— 把长信息浓缩成关键要点。

比如用户说：“我想周五晚上从北京去上海，因为周末要去上海参加一个朋友的婚礼，所以最好是下班后出发，大概 18 点到 20 点之间的车次都可以，座位的话，我平时喜欢靠窗，因为可以看风景，不过如果没靠窗的话，过道也可以接受，对了，我是二等座的预算，一等座太贵了。”

压缩提炼后的信息：

• 时间：周五 18:00-20:00（因参加婚礼，需下班后出发）；

• 座位类型：二等座（预算限制）；

• 座位偏好：优先靠窗，其次过道。

这样一来，上下文信息从 500 字变成了 3 句话，Agent 处理效率会大大提高。

策略 4：分而治之 —— 把 “大任务” 拆成 “小上下文”

如果一个任务很复杂（比如 “帮我策划一场为期 3 天的上海旅行，包括交通、住宿、景点、餐饮”），把所有信息都放在一个上下文里，会非常混乱。这时候需要 “分而治之”—— 给每个子任务建一个独立的上下文。

比如把旅行策划拆成 4 个子任务，每个子任务有自己的上下文：

1. 交通上下文

   ：记录 “北京到上海的交通方式（高铁 / 飞机）、上海市内交通（地铁 / 打车）”；

2. 住宿上下文

   ：记录 “住宿区域（靠近景点 / 市中心）、预算（每晚 500 元以内）、用户偏好（安静、含早餐）”；

3. 景点上下文

   ：记录 “用户感兴趣的景点（外滩、迪士尼、豫园）、游玩时间安排（第一天迪士尼，第二天外滩 + 豫园）”；

4. 餐饮上下文

   ：记录 “用户口味（不吃辣）、想尝试的美食（上海本帮菜、生煎包）、推荐餐厅（XX 餐厅、XX 生煎）”。

每个子任务的上下文独立管理，Agent 处理时不会互相干扰 —— 比如调整住宿时，不用考虑景点的安排，专注处理住宿相关的信息即可。

4.4 上下文工程的 “三大挑战”

虽然上下文工程很强大，但它也有自己的 “痛点”—— 这些挑战也是目前 Agent 发展的关键瓶颈：

挑战 1：上下文窗口的 “容量限制”

大模型的 “上下文窗口” 是有限的 —— 比如 GPT-4 的上下文窗口是 128k tokens（大概相当于 10 万字），虽然看起来很多，但如果处理长任务（比如写一本 200 页的书、整理一年的聊天记录），很快就会 “装满”。

比如你让 Agent 整理 “过去一年的客户沟通记录”，这些记录有 50 万字，远超 GPT-4 的上下文窗口容量 ——Agent 根本装不下这么多信息，自然没法整理。

目前的解决办法：

• 上下文压缩

  ：把不重要的信息压缩，腾出空间；

• 上下文分页

  ：把长信息分成多页，Agent 处理完一页再处理下一页；

• 外部知识库

  ：把超出窗口的信息存到外部数据库（比如 MySQL），Agent 需要时再调取。

挑战 2：注意力分散的 “噪声干扰”

如果上下文里有很多 “无关信息”（比如和任务无关的闲聊、重复的内容），Agent 的 “注意力” 会被分散，可能会忽略关键信息。

比如订高铁票的上下文里，混进了 “用户今天吃了汉堡、昨天看了电影、上周去了北京” 这些无关信息，Agent 可能会误把 “上周去了北京” 当成 “这次要去北京”，导致订错目的地。

目前的解决办法：

• 信息过滤

  ：自动删除和任务无关的信息；

• 注意力权重

  ：给关键信息（比如用户需求、工具反馈）更高的 “注意力权重”，让 Agent 优先关注这些信息。

挑战 3：长上下文的 “性能退化”

大模型处理 “短上下文” 时，准确率很高，但处理 “长上下文” 时，性能会逐渐下降 —— 比如上下文窗口快满时，Agent 可能会忘记前面的信息，或者理解出现偏差。

比如你和 Agent 聊了 100 轮后，再问 “我们最初说的旅行时间是哪天？”，Agent 可能会回答 “记不清了”—— 这就是长上下文导致的性能退化。

目前的解决办法：

• 关键信息置顶

  ：把最重要的信息（比如任务目标、核心需求）放在上下文的最前面，让 Agent 优先读取；

• 上下文总结

  ：每隔一段时间，自动总结上下文的关键信息，用总结代替原始信息，减少冗余。

05 值得尝试的 “开源项目”：亲手体验上下文工程

如果你想亲手试试上下文工程，或者基于开源项目搭建自己的 Agent，这三个项目非常适合新手 —— 它们不仅免费，而且文档详细，容易上手：

1. LangChain：最流行的 Agent 开发框架

一句话介绍：LangChain 是目前最火的 Agent 开发框架，它提供了一套完整的工具，帮助你快速搭建具备上下文管理能力的 Agent。

上下文工程相关功能：

• Memory 模块

  ：专门用于管理上下文，支持短期记忆（ConversationBufferMemory）、长期记忆（VectorStoreMemory）、压缩记忆（ConversationSummaryMemory）等；

• Chain 模块

  ：支持把多个任务串联起来，每个任务的上下文自动传递（比如先处理用户需求，再调用工具，最后生成结果，上下文无缝衔接）；

• 工具集成

  ：可以轻松集成 OpenAI、Anthropic 等大模型，以及 12306、天气 API 等外部工具。

适合人群：有一定 Python 基础，想搭建自定义 Agent 的开发者。

上手链接：LangChain 官方文档

2. AutoGPT：最容易上手的 “自主 Agent”

一句话介绍：AutoGPT 是一个开源的自主 Agent 工具，你只需要输入目标（比如 “帮我写一篇关于 AI 的短文”），它会自动规划步骤、调用工具、管理上下文，直到完成任务。

上下文工程相关功能：

• 自动上下文管理

  ：不需要手动处理上下文，AutoGPT 会自动记录用户需求、工具反馈、计划步骤；

• 上下文回溯

  ：如果任务卡住，AutoGPT 会回溯之前的上下文，调整方案（比如 “之前调用天气 API 失败，这次换一个 API 试试”）；

• 结果总结

  ：任务完成后，AutoGPT 会生成上下文总结，告诉你它做了哪些步骤、用了哪些信息。

适合人群：没有编程基础，想体验自主 Agent 的新手（可以直接下载 exe 文件运行）。

上手链接：AutoGPT GitHub 仓库

3. LlamaIndex：专注于 “上下文检索” 的工具

一句话介绍：LlamaIndex（也叫 GPT Index）的核心是 “让 Agent 能高效检索上下文信息”，特别适合处理长文档（比如 PDF、Word）的上下文管理。

上下文工程相关功能：

• 文档解析与索引

  ：可以把长文档（比如 1000 页的 PDF）解析成结构化数据，建立索引，Agent 需要时能快速检索到相关内容；

• 上下文融合

  ：把检索到的文档信息和用户需求融合成新的上下文，让 Agent 基于文档内容回答问题（比如 “根据这份 PDF 里的内容，总结产品的核心卖点”）；

• 多模态上下文

  ：支持图片、音频等多模态信息的上下文管理（比如让 Agent 基于图片内容生成描述）。

适合人群：需要处理长文档、多模态信息的开发者（比如做文档问答 Agent）。

上手链接：LlamaIndex 官方文档

06 总结：Agent 的未来，藏在上下文工程里

从普通大模型到 Agent，是 AI 从 “理解语言” 到 “理解任务” 的关键一步。而上下文工程，就是让 Agent “真正理解任务” 的核心 —— 它解决了 “记不住、理不清、用不上” 的问题，让 Agent 从 “机械执行” 变成 “灵活办事”。

回顾这篇文章的核心：

• Agent 是什么

  ：能自主感知、计划、行动、评估的 “办事助手”，区别于 “问答机器”；

• Agent 的核心动作

  ：感知（收集信息）、计划（拆解任务）、行动（执行步骤）、评估（检查结果）；

• Agent 的支撑系统

  ：记忆（大脑）、工具（手脚）、安全（防护盾）、评估（自我检查）；

• 上下文工程

  ：从 “临时便签”（提示词）进化到 “智能笔记本”（上下文），核心策略是 “选对、存对、压缩、拆分”，挑战是容量、注意力、性能。

未来，随着上下文工程的发展，Agent 会变得更 “聪明”：它能记住你的长期偏好（比如 “你喜欢喝美式咖啡，不加糖”），能处理更复杂的任务（比如 “帮你规划整个职业生涯”），甚至能和其他 Agent 协作（比如 “订票 Agent 和酒店 Agent 协作，完成你的旅行安排”）。

如果你是普通用户，未来会遇到更多 “懂你” 的 Agent，帮你节省时间；如果你是开发者，上下文工程和 Agent 开发会是未来的重要方向 —— 现在开始尝试，就能抓住下一波 AI 应用的机会。

最后，用一句话总结：大模型决定了 Agent 的 “智商上限”，而上下文工程决定了 Agent 的 “办事能力下限” —— 没有好的上下文工程，再聪明的大模型，也成不了靠谱的 Agent。

最新最全的文章请关注我的微信公众号或者知乎专栏：数据拾光者。

码字不易，欢迎小伙伴们关注和分享。