三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

上下文工程:Agent 的“工作台”收拾好没

上下文工程:Agent 的“工作台”收拾好没


两个人用同一个大模型做 Agent,一个稳一个傻。差别往往不在模型,而在“工作台上摆了什么”。上下文工程,就是 Agent 最重要的工程能力之一。

上篇讲了 Agent 的运行循环:Think → Act → Observe → Repeat。这个循环每一步都要依赖“当前能看到的信息”。

问题是:模型不是人,它没法像人一样自主“瞄一眼备忘录、翻一下聊天记录、想起三个月前的事”。它每一步能看到的,只有我们塞进上下文窗口里的内容。

上下文窗口,就是 Agent 的“工作台”。工作台收拾得好不好,直接决定 Agent 干活得稳不稳。

一、上下文窗口 = 计算机的 RAM

你可以把 LLM 的上下文窗口理解成计算机的运行内存(RAM)。Agent 每一步能“看到”的,只有装进 RAM 里的东西。

窗口越大,能装的东西越多;但窗口不是无限的,而且越大的窗口越贵、越慢、越缺少重点。所以工程上要做的是:在有限空间里,装最该装的东西。

二、上下文里通常放什么

一个 Agent 的上下文里,通常有这几类信息:

  1. 系统指令
    :告诉模型“你是谁、你的风格、你的边界”。比如“你是一个严谨的助手,不要编造数据”。
  2. 用户需求
    :用户这次到底想要什么。
  3. 工具列表与说明
    :告诉模型它能调用哪些工具、每个工具要什么参数、返回什么。
  4. 历史对话
    :之前聊了什么、走到了哪一步。
  5. 工具返回结果
    :上一次调用工具拿到了什么数据。
  6. 中间推理
    :模型自己思考的轨迹(Chain-of-Thought)。
  7. 约束与格式要求
    :比如输出 JSON、不要暴露敏感字段。

本质上,上下文工程就是:给模型一个能正确决策的工作台。

三、上下文工程在做什么

上下文工程不是简单地把所有信息堆进去,而是做四件事:

1. 选择:这一步该让模型看什么?

  • 不能全给。给多了会分散注意力,给少了会漏关键信息。

2. 组织:按什么顺序和结构排布?

  • 通常系统指令放最前面,工具说明紧随其后,用户当前需求放在显眼位置,历史结果按时间顺序排。

3. 压缩/裁剪:太长时怎么办?

  • 对历史对话做摘要,丢弃过时的中间结果,只保留对当前任务有用的部分。

4. 更新:每轮循环后刷新

  • 工具返回了新结果,要及时写回上下文;任务阶段变了,要调整提示。

我的观点是:上下文工程被严重低估。很多人一上来就追求“更强的模型”,但 80% 的 Agent 表现问题,靠更好的上下文组织就能解决。

四、常见坑:上下文污染、过载、遗忘

上下文污染:上一轮工具返回了错误数据,模型没识别出来,继续把它当事实推理,越走越偏。

信息过载:把十页文档、全部聊天记录、工具说明全塞进去,模型反而找不到重点,要记住LLM的核心能力是依赖注意力机制。

遗忘关键约束:系统指令说“不要暴露手机号”,但上下文太长,模型后面就把它忘了。

这些坑,做大数据的人都熟。数据不是越多越好,数据开发最关键的一步就是要做数据清洗。

这里有个小知识点你可以立马就能用,在使用你的AI助手时,如果有新的任务要开发,或者一个对话持续使用很久了,可以新开一个对话,既能节省token,又能提升他工作的准确性。大家如果用过一些起步阶段的agent可能感触更深,一个任务跑久了,后面就开始胡说了,甚至跑到一半任务跑丢了,一些成熟的agent倒不明显,不过多少还是有些影响的。

五、给普通人的建议

如果你是 Agent 的使用者或搭建者,记住三点:

  • 先写好系统指令
    :它决定了模型的“行为底线”。
  • 每次只放必要信息
    :和收拾桌子一样,东西越少越不容易乱。
  • 及时更新状态
    :每轮循环后,把新结果和新目标写清楚。

参考

  • 李博杰《深入理解 AI Agent》第 2 章 上下文


本文首发于微信公众号 BigDataLab,转载请注明出处。
更多 AI / 大模型实战干货,欢迎微信搜索关注「BigDataLab」,或 点此回看原文。

← 返回列表