在大语言模型（LLM）快速发展的今天，很多人都开始尝试构建属于自己的智能体（Agent）。
最近我在做一个 PDF 原格式翻译 Agent，它基于 LLM 的思考与推理能力，在 Multi-Agent 架构下结合各类工具（如 MCP Tool、Browser Use、Computer Use）进行协同工作，使 Agent 能够像一个专业的 PDF 助手一样理解任务、分析问题、并完成复杂操作。

然而，当我真正进入开发阶段后才发现——构建一个“好用”的 Agent 并不容易。
我遇到了许多典型问题，例如：

1. 为什么我反复调整提示词，效果还是不理想？
2. 为什么 Agent 的行为不稳定，一会儿遵守指令，一会儿又跑偏？
3. 为什么它经常出现“幻觉”，输出不符合预期？

这些问题的核心其实可以归结为一句话：
Agent 的输出不符合我们的预期。

本文结合我的实践经验，分享我在开发 PDF 翻译 Agent 过程中踩过的坑和总结的经验，或许能对你有所启发。

---

一、明确你的“预期”

要让 Agent 输出符合要求，首先要问自己两个问题：

1. 你的期望输出是什么？
2. 为了让它达到预期，你做了哪些设计？

1. 明确预期的重要性

很多人构建 Agent 时，会说“我希望它更智能”“它应该正确回答问题”，
这些都是典型的模糊预期。

模糊的目标无法指导优化。
你需要把这些模糊的愿望，转化为可量化、可验证的清晰预期。

当预期足够具体时，你才能判断：

• 是提示词指令不够明确？
• 是上下文设计存在歧义？
• 还是模型理解出了偏差？

否则你只能模糊地说一句“它不行”，却不知道问题出在哪。

2. 如何定义“清晰的预期”

（1）任务要求（Task）
任务是否具体？判断逻辑是否明确？

• 模糊示例：根据用户意向判断是否要精准翻译。
• 清晰示例：当用户输入中包含“精准”“准一点”等关键词时，采用精准翻译模式，否则使用普通翻译。

（2）输出格式（Format）
输出是 JSON、Markdown、自然语言还是函数调用？
如果是 JSON，要定义清楚 Schema。

（3）风格与语气（Style）
输出语气是专业、友好、简洁还是详细？

• 模糊示例：输出一段安抚用户的回复。
• 清晰示例：当翻译超过 3 个步骤仍未完成时，以礼貌、专业的语气回复：
  “非常抱歉给您带来了不便，正在为您进行更深入的翻译，请稍等片刻。”

---

二、合理使用 Few-Shot 示例

单任务场景：善用 Few-Shot
在单一目标任务中（例如参数抽取、模式判断），合理使用 Few-Shot 示例可以显著提高稳定性。
示例越贴近真实输入，模型表现越稳定。

灵活任务场景：慎用 Few-Shot
在复杂、多样的任务中，Few-Shot 反而可能限制模型的灵活性，让它“过拟合”到示例中。
一旦遇到没见过的情况，模型可能会机械模仿示例，从而输出错误结果。

核心思路： Few-Shot 不是越多越好，而是用得准、有代表性。

---

三、让上下文保持“苗条”

现在的大模型号称支持百万级 Token 上下文，但在实践中，当上下文长度超过约 1 万 Token 后，模型的记忆和稳定性都会明显下降。

从一些测试（例如 Needle In A Haystack）中可以看到：
Token 越多，模型对关键信息的准确率下降越快。
有时你写在系统提示词最前面的关键规则，模型甚至会“间歇性遗忘”。

我在开发 PDF 翻译 Agent 时也遇到过这种情况。
我曾在系统提示词中写入大量工具说明、调用流程、回复规范等内容，结果模型在执行时经常“忘记”调用指定工具，即使我明确规定了调用顺序，它仍然会遗漏。

这让我意识到：
过长的上下文不仅浪费 Token，还会削弱模型的稳定性与一致性。

要解决这个问题，可以：

• 精简提示词内容，只保留关键逻辑；
• 采用分层架构，把部分内容外置为知识模块；
• 使用子 Agent 处理特定任务，减轻主 Agent 的上下文负担。

---

结语

构建一个稳定、可靠的 LLM Agent，不只是“堆功能”或“写提示词”。
它更像是一场系统性工程：
既要有清晰的目标设计，也要理解模型的行为边界。

无论是提示词工程、Few-Shot 策略，还是上下文管理，本质上都是为了一个目的——
让 Agent 的思考更接近人类的逻辑，而不是随机的猜测。

希望我的一些实践经验，能给正在构建 Agent 的你带来参考。