过去一年，很多人谈 AI Agent，最常讨论的是 Prompt。

怎么写提示词？
怎么让模型听话？
怎么让它一步步思考？
怎么让它输出更稳定？

这些问题当然重要，但如果真正把 AI Agent 放进工程场景里，就会发现一个很现实的问题：Prompt 不是决定 Agent 成败的唯一因素，甚至不是最核心的因素。

很多 Agent 失败，并不是因为提示词写得不够好，而是因为它拿到的信息不够完整。

它不知道项目结构。
不知道业务边界。
不知道哪些文件能改。
不知道哪些逻辑不能碰。
不知道什么结果算完成。
不知道怎么验证自己做对了。

在这种情况下，Prompt 写得再漂亮，也只是让它更自信地犯错。

所以我越来越认为，AI Agent 真正的核心不是 Prompt Engineering，而是 Context Engineering，也就是上下文工程。

一、为什么 Prompt 解决不了所有问题

Prompt 的本质是指令。

它告诉模型应该做什么、怎么回答、以什么格式输出。

但指令本身不能替代事实。

比如你让 Agent：

“帮我优化这个系统的性能。”

这句话看起来很明确，但对 Agent 来说，其实非常模糊。

它不知道：

系统哪里慢。
慢的是前端渲染，还是接口响应。
是数据库查询慢，还是缓存没命中。
是首屏慢，还是交互卡顿。
有没有监控数据。
有没有性能指标。
优化后怎么证明有效。

如果没有这些上下文，Agent 只能猜。

它可能会建议加缓存、加懒加载、加索引、加分页、加防抖。每个建议听起来都合理，但不一定解决真实问题。

这就是很多 AI 建议看起来“都对”，落地却没用的原因。

它没有错在表达，而是错在缺少上下文。

二、上下文决定 Agent 的能力上限

一个 Agent 能做多复杂的事，取决于它能理解多少上下文。

上下文不只是当前问题的描述，还包括：

业务目标。
代码结构。
历史决策。
数据模型。
接口约束。
权限边界。
部署环境。
错误日志。
测试结果。
用户反馈。
团队规范。

这些信息共同决定了 Agent 的判断质量。

如果只给它一句话，它只能做语言推理。

如果给它完整上下文，它才有可能做工程推理。

这也是为什么同一个模型，在不同使用方式下表现差距巨大。

有的人觉得 AI 只能写点 demo。
有的人已经能让 Agent 处理多文件重构、自动修复测试、生成 PR。

差距不完全来自模型，而是来自上下文组织能力。

模型像大脑，上下文像记忆和环境。

没有上下文的大脑，只能靠猜。

三、上下文不是越多越好

很多人理解上下文工程时，会走向另一个极端：把所有东西都塞给模型。

项目文档、代码文件、日志、需求、聊天记录，全都丢进去。

这也不对。

上下文不是越多越好，而是越相关越好。

无效上下文太多，会带来几个问题：

第一，模型注意力被稀释。

真正重要的信息淹没在大量无关内容里，模型反而抓不住重点。

第二，成本上升。

大上下文意味着更多 token 消耗，速度更慢，成本更高。

第三，结论变得不稳定。

信息越杂，模型越容易抓到错误线索，给出看似合理但方向偏掉的方案。

所以好的上下文工程，不是堆材料，而是筛材料。

核心问题是：

当前任务需要哪些信息？
哪些信息会影响决策？
哪些信息只是噪音？
哪些信息需要在执行前确认？

这就像开发者自己排查问题时，不会把整个公司所有文档都翻一遍，而是先定位相关模块，再逐步缩小范围。

Agent 也应该这样使用。

四、Agent 最容易失败的四类上下文缺口

在实际使用中，我观察到 Agent 最容易因为四类上下文缺口而失败。

第一类是目标缺口。

用户只说“优化一下”“重构一下”“改好一点”，但没有说明完成标准。

没有完成标准，Agent 就不知道什么叫成功。

第二类是边界缺口。

用户没有说明哪些文件可以改，哪些逻辑不能动，哪些兼容必须保留。

于是 Agent 可能为了完成任务，顺手重构了不该动的模块。

第三类是约束缺口。

项目可能有自己的技术栈、代码风格、接口规范、权限规则，但 Agent 不知道。

于是它会按照通用经验生成代码，看起来不错，却不符合项目实际。

第四类是验证缺口。

Agent 做完后，没有测试、没有构建、没有人工检查，也没有可量化结果。

这种情况下，任务只是“看起来完成了”，并不代表真的完成。

这四类缺口，是大多数 Agent 失控的根源。

五、一个稳定 Agent 任务应该怎么描述

好的 Agent 任务，不应该只描述“要做什么”，还应该描述“为什么做、怎么判断做完、不能做什么”。

一个差的任务是：

“帮我重构登录模块。”

一个更好的任务是：

“请先阅读登录相关代码，梳理当前登录流程，包括账号密码登录、Token 保存、登录过期处理和路由拦截。不要直接修改代码。先输出当前流程、存在的问题、建议的最小修改方案，以及可能影响的文件。等我确认后再执行。”

这两种写法的区别非常大。

第一种让 Agent 直接进入执行。

第二种让 Agent 先建立上下文。

对于复杂任务，我更推荐分阶段：

先探索。
再计划。
再执行。
再验证。

不要一上来就让 Agent 改代码。

复杂问题直接执行，往往是灾难的开始。

六、上下文工程的第一步：让 Agent 先读懂现状

很多人使用 Agent 时太着急。

上来就说：

“帮我实现这个功能。”

但 Agent 连当前系统是什么样都不知道。

更合理的方式是先让它读懂现状。

例如：

“先不要修改代码。请你阅读用户模块相关文件，整理当前用户状态管理方式、接口调用方式、缓存策略，以及可能影响该需求的代码位置。”

这一步非常重要。

它能让 Agent 从“猜测式回答”变成“基于证据回答”。

如果 Agent 输出的现状理解是错的，说明它还没准备好执行。

这时候应该继续补上下文，而不是让它继续改。

很多时候，提前多花 5 分钟让 Agent 读懂现状，可以省掉后面几个小时的返工。

七、上下文工程的第二步：明确边界

Agent 很容易“过度发挥”。

你让它修一个 bug，它可能顺手重构半个模块。
你让它补一个字段，它可能改了整个数据结构。
你让它优化性能，它可能引入一套缓存系统。

这些行为不是因为 Agent 故意乱来，而是因为边界不清。

所以在任务开始前，必须明确：

哪些文件可以改。
哪些文件不要改。
是否允许重构。
是否必须保持兼容。
是否可以新增依赖。
是否需要保留原有 API。
是否需要考虑历史数据。

边界越清楚，Agent 越稳定。

比如：

“只允许修改用户设置页和对应的状态管理文件，不要改动登录流程，不要新增第三方依赖，不要重构目录结构。”

这类约束看起来啰嗦，但非常有效。

工程稳定性很多时候就来自这些边界。

八、上下文工程的第三步：提供项目规则

每个项目都有自己的规则。

比如：

接口统一放在 api 目录。
组件必须使用 TypeScript。
错误提示必须走 toast。
状态管理必须用 Zustand。
样式不能写内联。
请求必须带认证头。
敏感字段不能进入日志。
所有新增逻辑必须有空状态和错误状态。

这些规则如果只存在开发者脑子里，Agent 不可能知道。

所以成熟的 Agent 工作流，应该把规则显式化。

可以写成项目约定：

代码风格。
目录结构。
命名规范。
异常处理方式。
测试要求。
安全要求。
不允许做的事情。

这样 Agent 每次执行任务时，都能基于同一套规则工作。

这比每次都在 Prompt 里重复说明更稳定。

团队使用 Agent 时，项目规则尤其重要。

否则不同人、不同 Agent、不同模型生成的代码风格会越来越不一致。

九、上下文工程的第四步：把验证变成上下文

很多人忽略了一点：测试结果也是上下文。

Agent 修改代码后，如果只是让它停在那里，它不知道自己是否真的成功。

如果你把构建错误、测试失败、日志输出反馈给它，它就能继续修正。

这就是反馈闭环。

一个稳定的 Agent 工作流应该是：

执行修改。
运行检查。
读取错误。
定位原因。
再次修复。
再次验证。

没有验证的 Agent，只是代码生成器。

有验证的 Agent，才开始接近工程助手。

验证方式可以包括：

单元测试。
类型检查。
Lint。
构建。
接口测试。
页面截图。
日志分析。
人工验收清单。

不同任务需要不同验证方式。

关键是，不能让 Agent 只负责“写”，不负责“证明写对了”。

十、Agent 的幻觉，本质上常常是上下文不足

很多人说 AI 会幻觉。

这是真的。

但在工程场景里，很多所谓幻觉，其实是上下文不足导致的合理猜测。

比如 Agent 编造一个不存在的函数。

可能是因为它没有读取完整工具库。

比如 Agent 使用错误的接口字段。

可能是因为你没有给它接口文档。

比如 Agent 给出不符合项目风格的代码。

可能是因为它没有看到项目规则。

当然，模型本身确实会出错，但减少幻觉的第一步，不是换一个更贵的模型，而是补齐关键上下文。

好的上下文不能消灭所有幻觉，但可以显著降低幻觉出现的概率。

十一、不要让 Agent 一次处理过大的任务

任务越大，上下文越复杂，失败概率越高。

例如：

“帮我重构整个后台系统。”

这种任务几乎不可控。

更好的方式是拆分：

先梳理后台系统模块。
再选择一个最小模块。
先重构状态管理。
再重构接口层。
再调整页面组件。
最后补测试和文档。

Agent 适合处理边界清晰的小任务，也可以连续处理多个小任务。

但不适合在缺少阶段控制的情况下，一口气吞掉整个系统。

任务拆得越清楚，结果越可控。

这和人类工程管理是一样的。

复杂项目从来不是靠一句话完成，而是靠分阶段交付。

十二、上下文工程不是 AI 技巧，而是工程能力

很多人把 AI 使用能力理解成 Prompt 技巧。

但我认为，真正高级的 AI 使用能力，其实是工程能力。

你要理解系统。
你要拆解问题。
你要定义边界。
你要设计验证。
你要判断风险。
你要知道什么时候该让 Agent 停下来。

这些能力不是 AI 出现后才需要的。

它们本来就是优秀工程师需要具备的能力。

AI Agent 只是把这些能力放大了。

一个工程能力强的人，用 Agent 会更强。

一个工程判断弱的人，用 Agent 可能只是更快生成更多问题。

所以未来开发者的差距，不会因为 AI 消失，反而可能更明显。

十三、我理解的 Agent 最佳工作流

如果让我总结一个相对稳定的 Agent 工作流，我会这样设计：

第一步，明确目标。

告诉 Agent 要解决什么问题，以及什么结果算完成。

第二步，读取上下文。

让 Agent 先阅读相关代码、文档、日志，不要急着改。

第三步，输出方案。

要求它说明修改范围、风险点、验证方式。

第四步，人工确认。

开发者确认方向和边界。

第五步，执行修改。

让 Agent 按方案实施，不做额外扩展。

第六步，运行验证。

把测试、构建、日志结果反馈给 Agent。

第七步，总结沉淀。

让 Agent 输出变更说明和后续注意事项。

这个流程不复杂，但非常有效。

它的核心不是让 Agent 更聪明，而是让 Agent 工作得更有边界、更有反馈、更可验证。

十四、总结

AI Agent 的价值正在被越来越多人看到。

但如果只停留在 Prompt 层面，很容易高估它的稳定性，也容易低估工程落地的复杂度。

真正能让 Agent 稳定工作的，不是某一句神奇提示词，而是一整套上下文工程。

你要给它目标。
给它相关信息。
给它项目规则。
给它执行边界。
给它验证反馈。
也要在关键判断上保留人的控制权。

Prompt 决定 Agent 如何开始。

上下文决定 Agent 能走多远。

验证决定 Agent 是否真的完成。

所以，与其不断寻找万能 Prompt，不如先建立自己的上下文工程方法。

当 Agent 能在正确的上下文中工作，它就不再只是一个会聊天的模型，而会变成一个真正可用的工程协作者。