跬步 On Coding

AI Agent 工程化实践：从 Prompt 到 Context 的思维转变

Nov 30 2025

最近在新公司这边，大部分精力都耗在了 AI Agent 的落地应用上。大家都在谈 Agent，网上的 Demo 也是满天飞，但当你真正把这玩意儿往生产环境搬的时候，会发现完全是两码事。

简单的说，AI Agent 的核心逻辑其实并不复杂，本质上就是一个基于 ReAct（Reasoning and Acting）范式的工程结构，程序在一个死循环里不断地调用 LLM 的 API，让它根据当前的观测去决策下一步是思考还是行动。

起初我也觉得这就跟写个脚本差不多，但在实际调试过程中，我发现让 Agent “跑通”不难，但要让它“跑好”、“省钱”且“不犯蠢”，这里面全是工程细节。我也复盘了一下这段时间的踩坑经历，总结了一些在工程实践中的“巧思”。

遇到的瓶颈

在项目初期，我碰到的最大痛点就是 Token 的消耗 和 上下文窗口（Context Window）的限制。

Agent 运行起来后，为了保证它能记住之前的操作，我们往往会把历史对话一股脑地塞进 Prompt 里。但随着交互轮数的增加，上下文会迅速膨胀。这不仅烧钱（Token 费很贵），更要命的是，当无关信息太多时，LLM 的注意力会被稀释，导致它开始“幻觉”或者逻辑混乱，也就是我们常说的“变笨了”。

为了解决这个问题，我开始从工程角度去干预 Agent 的记忆机制，我发现单纯的 Prompt Engineering 已经不够用了，我们需要进阶到 Context Engineering（上下文工程）。

几个工程化的巧思

针对上下文过载和执行效率低的问题，我在工程实践中尝试了以下几个优化策略，效果还不错：

1. 动态整理与压缩上下文

这招主要是应对“记不住”的问题。当对话轮数逼近模型的 Context 上限时，如果直接截断最早的记录，Agent 可能会丢失关键的任务背景。

我的做法是，在检测到 Token 数快到阈值时，触发一个后台任务，让 LLM 自己对之前的多轮对话做一个动态整理（Summary）。

  • 输入：过去 N 轮的详细对话。
  • 输出：提取出“用户的核心诉求”、“已完成的关键步骤”和“当前获得的中间结果”。

用这段高密度的摘要替换掉那 N 轮冗长的对话。这样既大幅减少了 Token 量，又确保了历史关键信息得以保存，让 Agent 始终记得“我是谁，我在哪，我要干什么”。

2. Checkpoint 回溯与有效信息保留

Agent 在尝试调用工具时，并不总是成功的。有时候它参数传错了，有时候 API 报错了。在标准的 ReAct 循环里，这些报错信息（Error Logs）会被完整地记录在上下文里。

这就导致一个问题：如果 Agent 试错了好几次才成功，那上下文里会充斥着大量的垃圾报错信息。这些信息对于后续的决策不仅无用，反而可能误导模型。

这里我引入了一个类似游戏存档的 Checkpoint（检查点） 机制。

  • 在执行关键动作前，系统会自动保存当前的上下文快照。
  • 当检测到 Agent 陷入死循环或产生大量无效交互时，系统会强制回滚到上一个 Checkpoint。
  • 关键点：回溯不是简单的“读档重来”，我们会通过规则提取出刚才试错过程中产生的“有效信息”（比如“某个参数验证失败”的结论），将其注入到回溯后的上下文中。

这样既清洗了上下文中的噪音，又保留了试错的价值，避免 Agent 在同一个坑里跌倒两次。

3. Sub Agent 解决上下文隔离

在某些场景下，Agent 需要执行非常复杂的子任务，比如写一段 Python 代码并执行，或者进行复杂的数据清洗。

如果把这些子任务的所有中间步骤都塞进主线程的上下文（Main Context），瞬间就会把 Token 撑爆。我的解决思路是引入 Sub Agent（子智能体）：

  • 把复杂任务分发给一个独立的 Sub Agent。
  • Sub Agent 拥有独立的上下文空间，它可以在里面进行多轮的思考、调试、修正。
  • 当 Sub Agent 任务完成后，只提取“最终结果”返回给主 Agent。

通过这种方式，我们实现了上下文的物理隔离，主 Agent 的视野始终保持清爽，只关注宏观流程，而细节则由 Sub Agent 屏蔽。

4. 面向“人”设计工具，而非面向 API

这一点是我觉得思维层次提升最大的地方。

最初给 Agent 设计工具时，我习惯直接把后端的原子 API 扔给它，比如 login(), get_token(), get_user_info()。结果就是 Agent 完成一个简单的查用户信息，需要来回跑三趟。

后来我意识到，Agent 使用工具的逻辑应该更像“人”使用 app。工具的设计粒度应该更粗。我们将多个原子 API 组合封装成一个面向业务场景的高阶工具。这样一次调用就能搞定，减少了 Agent 的交互流程，容错率也大大提升。

总结：从 Prompt 到 Context

回顾这些优化点，我们可以发现，提升 Agent 能力的关键，不仅仅在于你 Prompt 写得有多花哨，更在于你如何管理它所能看到的“世界”。

让我们来总结下这里的思维层次：

  • 第一层（Prompt Engineering）：专注于怎么把 Prompt 词写好，试图用一段话把所有要求都告诉 AI。
  • 第二层（RAG / Memory）：开始给 AI 外挂数据库，解决知识库的问题。
  • 第三层（Context Engineering）：把上下文看作一种稀缺的计算资源，通过动态压缩、Checkpoint 回溯、Sub Agent 隔离等工程手段，动态地管理 AI 的注意力。
  • 第四层（Architecture Design）：从单点优化走向系统设计，构建一套具备自我纠错、状态管理、分层协作的智能体运行时环境。

以前做传统开发，我们优化的是 CPU 和内存；现在做 AI 开发，我们优化的其实是 Context Window 和 Token 效率。

在这个技术日新月异的时代，作为程序员，我们不仅要会写代码，更要学会如何设计系统来弥补模型的短板。这些关于 Context 的巧思，其实就是把复杂的非结构化问题，通过工程手段变得有序化的过程。

希望这些瞎絮叨的经验能对正在折腾 Agent 的你有那么一点点启发。2025 年了，保持学习，保持思考，依然是应对变化的唯一解法。