Agent系统的Tool描述比System Prompt更能决定模型行为？本文通过实战案例揭示了一个反直觉的发现：在多层Prompt架构的Agent系统中，Tool Description才是真正的决策核心。从模糊描述引发的调用失效，到长流程中的Prompt稀释效应，作者系统性地拆解了Agent场景下Prompt工程的六大关键层级与运行时管理策略。

我有一个 agent，挂了 8 个 tool，其中一个统计 tool 模型就是不调。反复测，触发条件都对，它就是绕开。最后定位到是 tool description 里有一句 “when needed for advanced analysis”。把 when needed 删掉，改成”使用场景：获取 X、Y、Z 三类数据”，模型立刻开始用。

这种事在单次 prompt 里基本不会遇到。在 agent 里很常见。

Agent 里的 prompt 不止一份

普通用 LLM 的时候，prompt 大概就一两个地方：system prompt 加 user input。写好了基本不动。

agent 里 prompt 是分层的，而且每一层都在影响模型决策。我自己梳理大概有这几层：

1. System prompt —— 定 agent 的角色、整体目标、不能做的事
2. Tool descriptions —— 每个 tool 的描述本身就是 prompt
3. User input —— 用户原始请求
4. Memory / 检索内容 —— 从向量库或者历史对话里拉进来的上下文
5. Tool results —— 每一步 tool 返回的内容，直接进 context
6. Reasoning trace —— 模型自己的中间思考(如果用 ReAct 类范式)

这六层在 agent 跑的过程里都会进 context window，一起影响下一步决策。

运行时是怎么变化的

普通 chat 里 prompt 写完就锁死了。agent 跑起来不是这样——每一步，context 里的东西都在长。

跑到第 5 步，模型看到的 context 已经包含：原始 system prompt + 用户问题 + 之前 4 步的 tool 调用 + 4 步的 tool 返回 + 它自己几段中间 reasoning。

跑到第 20 步，这个 context 就很臃肿了。最初的 system prompt 在最前面，可能已经被几千 token 的中间结果隔开。模型注意力在 context 里的分布不是均匀的——开头和结尾权重高，中间会被压低。

实际后果是：system prompt 在长 agent 跑里会被稀释。你最初写的”不要做 X”约束，跑到第 15 步可能就被中间堆积的内容淹没了。

应对方式有几种：

• 在每一步执行前重新注入关键约束(成本高但有效)
• 把硬约束写进 tool 本身的实现里(更彻底，但不灵活)
• 主动裁剪中间的 tool 输出，只保留摘要(我现在的默认做法)

Tool description 比 system prompt 更关键

这是我做了几个 agent 之后反过来才认的事。

早期我花很多时间打磨 system prompt，觉得这是控制 agent 行为的主要杠杆。后来发现不对。

模型在决定”调哪个 tool、传什么参数”的时候，主要看 tool 自己的 description。system prompt 影响整体语气和大方向，但具体到每一步，tool description 才是决策依据。

写 tool description 有几条经验：

• 不要用模糊词。”when appropriate”、”if needed”、”for complex queries” 这种，模型很难判断什么时候符合。直接写”使用场景：1) X;2) Y;3) Z”。
• 参数要给例子。schema 里的 type 不够，要在 description 里给实际格式。比如 query 参数，写”例：2024 年 Q3 销售数据，按区域分组”比 type： string 有用得多。
• 返回值要说明。模型决定要不要调这个 tool 的时候，也在估算”调了之后能拿到什么”。返回值描述清楚，调用决策更准。
• Few-shot 例子直接塞 description 里。比单独留 example 字段效果好，因为前者一定会被读到，后者不一定。

Reasoning prompt 的坑

如果用 ReAct 这类范式，模型在每一步 tool 调用前会产出一段 reasoning。这段 reasoning 本身也是 prompt 的一部分——它会进入下一步的 context。

这里有个隐蔽问题：模型很容易写出”自我安慰式 reasoning”。

让它 reflect 一下当前进度，它经常写”目前进展顺利，下一步继续 X”。其实可能根本没顺利。这段假积极的 reasoning 一旦进了 context，后面几步模型都被它带着走，以为前面一切正常。

对策是把 reflection prompt 强制具体化：不要问”进展如何”，问”刚才这一步的输出符合预期吗?哪里不符合?”。具体问题逼模型给具体回答。

一个不太显然的点

agent 里的 prompt 不是写一次就完事的东西。它是要随着 context 持续维护的一套动态内容。

写 prompt 在 agent 场景下，从”写一份文档”变成了”管理一整套动态拼装的内容”。最初的 system prompt 只占其中一小部分，真正影响每一步行为的，是 context 里那些不断变化的东西。

我现在调 agent，大概 80% 的时间花在 tool description 和 context 裁剪上，system prompt 反而是最先稳定下来的那部分。

跑通一个能干活的 agent 不难。让它在 20 步之后还守住最初的约束、还能做出靠谱判断，差别基本都在 prompt 的运行时管理上。