LLM Agent 需要提示工程吗？上下文不足如何解决？

当你的 LLM Agent 总是“答非所问”，问题可能不在模型，而在提示

上周我帮一家跨境电商客户调试他们的自动客服 Agent。场景很简单：用户问“我的订单#12345到哪了？”，Agent 应该调用内部物流 API 返回轨迹。结果呢？Agent 要么胡乱编造地址，要么反问“您能提供更多上下文吗？”——典型的“上下文不足综合征”。

客户第一反应是换更大参数的模型。但我说：“别急着烧钱，先看看你的 Prompt。”

提示工程不是“锦上添花”，而是 LLM Agent 的“氧气面罩”。没有它，再强的模型也会窒息。

为什么 LLM Agent 比普通聊天机器人更依赖提示工程？

很多人以为：“既然叫 Agent，就该自己思考，不用我手把手教吧？”——这就像指望刚入职的新员工，不给岗位说明书、不培训流程，直接丢进战场还能打胜仗。

LLM Agent 的本质，是“有工具调用能力的语言模型”。它的“智能”来自两个部分：

1. 推理引擎：大模型本身（如 GPT-4、Claude 3）
2. 操作手册：你写的 Prompt + 工具描述 + 上下文管理策略

前者是肌肉，后者是神经。肌肉再发达，神经信号断了，人也是瘫痪的。

我在实际项目中发现，90% 的 Agent 失效案例，根源都在 Prompt 设计缺陷——比如没明确说明“何时该调用工具”、“如何解析用户模糊表达”、“遇到歧义时优先询问而非猜测”。

上下文不足？三招“外科手术式”解决方案

“上下文不足”听起来抽象，拆解开来无非三种情况：

下面我以“订单查询”为例，展示如何用 Prompt 手术刀精准切除上下文病灶。

实战：让 Agent 不再“失忆”的 Prompt 改造术

原始 Prompt（问题版本）：

你是一个电商客服助手，请回答用户关于订单的问题。

改造后 Prompt（带上下文管理）：

你是一个严谨的电商客服助手，必须遵守以下规则：

1. 当用户提及订单但未提供完整编号时，立即追问：“请问您的订单号后四位是多少？或告知下单手机号？”
2. 一旦获取订单号，立即将其作为“当前焦点订单”记录在对话开头，并在后续每轮回复前重复确认。
3. 若需调用物流查询工具，必须先输出：【工具调用准备】订单号=XXXXXX，再执行动作。
4. 禁止猜测或编造信息。不确定时主动询问。

这个改造的核心，在于把“隐性要求”变成“显性指令”，并植入“记忆机制”。就像给员工配了个便签本，随时记录关键信息。

配合 n8n 工作流，我们还可以在每次用户交互后，自动将“当前焦点订单”写入临时数据库，并在下一轮对话开始时，通过 Webhook 自动注入到 Prompt 最前端——相当于给 Agent 装上了“短期记忆芯片”。

终极心法：把 Prompt 当“法律条文”来写

提示工程的本质，是“用自然语言编写可执行的约束条件”。我常对团队说：“写 Prompt 不是写散文，是写合同——每一个字都要经得起推敲，每一个句号都可能引发蝴蝶效应。”

记住三个黄金法则：

• 明确优先级：用“必须/禁止/优先”替代“可以/建议”
• 预设故障路径：提前告诉 Agent “如果XXX发生，你就YYY”
• 量化模糊概念：不说“尽快回复”，而说“在3轮对话内完成信息收集”

当你能把业务逻辑翻译成这种“机器可执行的法律文本”，上下文不足？不存在的。

现在轮到你了

你遇到过最头疼的“Agent 上下文丢失”场景是什么？是在电商、客服、还是内部知识库场景？欢迎在评论区留下你的案例——我会挑三个最具代表性的，免费帮你做 Prompt 诊断和重构。