Prompt越长越好吗？何时该停手

提示词写着写着，几乎都会走向同一个结局：越来越长。

一次执行漏了字段，就补一条"务必完整"；工具调用错了，就加一段流程约束；输出不稳定，再附上一轮自检。过几天让模型帮忙优化，它往往又还你一份更长、更工整、也更难维护的 Prompt。

这套操作不难理解。Agent 的失败通常是具体的，但人对失败的修复很容易变成泛化的文字堆积。最后，系统指令像一个不断打补丁的老项目：规则散落、优先级模糊、例外彼此缠绕。模型未必更懂，维护者已经先看不懂了。

Prompt 没有一个放之四海而皆准的最佳长度。真正需要判断的，是新增或删去的那段内容，是否改变了模型在关键决策点拿到的信息，是否减少了可观测的失败。

一、先分清：变长的到底是什么

讨论"Prompt 太长"时，最容易混淆的一点，是把一次模型调用中看到的所有内容，都叫作 Prompt。

但在一个带工具、多步骤执行的 Agent 中，实际输入通常由几层内容叠加而成：

其中，系统指令负责长期稳定的行为边界；用户请求描述当前任务；Skill 更像可被按需加载的领域操作手册；工具说明定义模型能做什么；历史消息和工具返回，则常常才是上下文膨胀的大头。

这几个部分的优化方式完全不同。

例如，把系统指令从 500 字扩展到 800 字，并补上"结论必须引用日志证据"的验收条件，最终效果变好，并不能推导出"多写 300 字有用"。有效的是那条新约束，而非长度本身。

反过来也一样。删掉一段文字后准确率下降，也未必说明短 Prompt 不行。你可能刚好删掉了一个时间范围、权限边界，或者某个很少出现但必须处理的例外分支。

所以，长度只是一个表象指标。更值得盯住的是三件事：

• 模型是否缺少完成任务所必需的条件；
• 多份指令之间是否存在重复、冲突或优先级竞争；
• 当前调用是否塞进了大量本不该参与决策的资料。

还有一个现实问题：上下文窗口能容纳，不代表模型能稳定执行其中每一条规则。

窗口大小解决的是"装不装得下"，不是"能不能用好"。尤其在长链路 Agent 中，规则、工具结果、历史对话不断累积后，模型对局部关键信息的关注会被稀释。这也是近来被频繁讨论的 context rot：输入越来越多，任务质量反而开始衰减。

二、Prompt 改动只有三种值得做

面对一次 Agent 失败，直接扩写通常是最省事、也最不可靠的动作。更稳妥的路径，是先定位失败类型，再决定该补、该删，还是该拆出去按需加载。

补：缺少必要条件时，增加可执行约束

最值得补的内容，通常不是"认真""全面""仔细"这类泛化要求，而是模型完成任务时确实缺失的条件。

以日志分析 Agent 为例。假设它能给出一个看起来合理的根因，但结论经常没有证据支撑。

一段低质量修补可能是：

请全面分析日志，认真检查所有可能原因，确保结论准确。
​

它增加了字数，几乎没有增加执行信息。

更有价值的改写是：

输出根因前，必须列出至少两条直接支持该结论的日志证据。
每条证据应包含：时间戳、服务名、关键日志片段。
若证据不足，输出"无法确认"，并说明缺少哪些日志。
​

这段指令依然不长，但它补齐了验收标准、失败出口和结果结构。模型知道何时可以下结论，也知道证据不足时不能硬猜。

示意如下：

失败现象	应补的信息	不建议的补法
漏掉必填字段	字段清单、格式规则	"回答更完整"
根因无证据	证据数量、证据格式、拒答条件	"仔细分析日志"
工具调用错误	调用前置条件、参数约束	"正确使用工具"
越权执行	权限范围、审批条件、禁止动作	"注意安全"
结果不可验收	验收项、输出 Schema、失败处理	"保证高质量"

一些代码审计相关研究也给出过类似线索：当输入上下文变长时，模型通过率可能下降；在关键决策处补充一份明确、有限的检查清单，效果又可能回升。

这并不意味着"清单越多越好"。清单真正有用的前提，是它对应任务中高频、关键、可验证的遗漏点。把几十项低频规则全部复制到每一轮调用里，往往只是在制造新的噪声。

删：重复和冲突比"冗长"更危险

一个成熟 Agent 的 Prompt 里，最常见的坏味道不是单纯长，而是同一条规则在多个层级重复出现。

例如：

• 系统指令要求"输出中文"；
• Skill 又要求"默认使用中文"；
• 用户模板再写一遍"请用中文回答"；
• 某个工具描述里还有"返回中文摘要"。

这类重复不一定立刻造成错误，但会抬高维护成本。未来某个场景需要支持英文时，你得同时修改四处；漏改一处，模型会收到相互拉扯的指令。

更麻烦的是冲突。比如系统指令要求"信息不足时必须追问"，某个旧 Skill 却要求"不得向用户追问，应自行完成任务"。模型如何选，取决于层级、表述位置、当前上下文，以及模型自身的指令遵循特性。生产环境里，这类行为通常很难稳定复现。

删减时，要删的是表达冗余、过时规则和跨层复制，不是业务边界本身。

下面这类逻辑，压缩时尤其容易被误伤：

当变更影响生产环境时：
- 若已获得变更单审批，可以执行；
- 若未获得审批，只生成变更方案，不得执行。
​

如果被"精简"为"生产变更需要审批后执行"，看起来意思差不多，实际却丢掉了未审批时的替代行为。Agent 可能直接停住，也可能擅自走到不该走的路径。

Anthropic 在面向新一代模型的上下文工程实践中提到，Claude Code 曾删除大量系统 Prompt 内容，内部编码评测没有观察到可测损失。这个案例值得关注，但不能机械解读成"删掉 80% 规则就行"。

它更有价值的启示是：模型能力、工具能力和工作流演进后，旧规则需要重新验收。曾经为了弥补模型缺陷加上的硬约束，可能已经过时；但权限限制、业务事实、审计要求和交付标准，永远不能靠"模型更聪明了"来替代。

拆：专用资料应当可达，而非永远常驻

第三类改动是按需加载。它通常比反复压缩 Prompt 更有工程价值。

假设你有数十份故障处理手册，覆盖数据库、网络、消息队列、Kubernetes、业务中台等不同领域。把它们全部塞进系统提示词，模型当然"看得到"；但每一次调用都要处理一堆与当前问题无关的内容，成本和干扰都会上升。

更合理的组织方式，是保留一个足够清晰的入口：

故障处理资料目录：
- 数据库连接池耗尽：database/connection-pool.md
- Kafka 消费延迟：messaging/kafka-lag.md
- Pod 频繁重启：kubernetes/crashloop.md

根据告警类型和日志特征选择资料。
无法确定归类时，先读取 incident/triage.md。
​

当任务确认与 Kafka 消费延迟相关，再读取对应手册。

这里的关键不是"把内容拆得越碎越好"。资料层级多了，模型就多了一次选错入口的机会。相关 progressive disclosure 研究也观察到，在一些多资料场景下，一层清晰披露往往更稳定；继续加第二层、第三层路由，不一定带来收益，甚至可能拉低准确率。

因此，资料拆分要满足两个条件：

1. 模型能基于当前任务可靠地找到入口；
2. 真正决定行为的关键条款，必须在执行前被加载。

把生产权限限制塞进一个极少被读取的文档，主文件是短了，系统却失去了安全边界。这是典型的为了"上下文整洁"牺牲业务正确性，工程上并不划算。

三、系统指令、Skill 和工具说明该怎么分工

一个容易维护的 Agent，不靠一份超长总提示词维持秩序，而是让不同层级承担不同职责。

内容类型	更适合放置的位置	原因
身份边界、禁止行为、通用输出原则	系统指令	每轮都必须生效
当前任务目标、临时约束	用户请求	随任务变化
特定领域流程、排障手册、业务规则	Skill / 按需资料	只有相关任务需要
参数定义、调用前后条件、返回字段	工具说明	与工具能力强绑定
实时数据、检索结果、执行日志	工具返回	必须保持新鲜度

一个实用判断标准是：这条内容在什么时候必须生效？

如果模型在选择工具前就必须知道某条约束，它需要在那个决策点可见。比如"涉及删除操作必须先生成计划，不得直接执行"，就不能只放在一个可能不会加载的运维 Skill 里。

如果只有数据库迁移任务才需要知道某个表结构规范，就没必要让客服问答、文档总结、日常搜索也背着它。

工具说明尤其值得单独治理。很多团队的工具 Schema 会慢慢变成另一份巨型 Prompt：字段很多、示例很多、历史兼容逻辑很多。模型面对十几个相近工具时，调用正确率往往开始下降。

可优先处理这些问题：

• 合并功能高度重叠的工具；
• 给工具命名提供明确的业务语义；
• 把长篇背景介绍移到按需 Skill；
• 限制工具返回体积，避免把原始大对象整段回填；
• 为关键工具写清调用前置条件与失败后的恢复路径。

需要注意，缓存命中和上下文精简是两件事。缓存可以降低重复输入的处理成本，但无关内容仍可能存在于当前上下文中，继续影响模型决策。成本、延迟、输入 token 和任务质量，应分别观测，别只看其中一个。

四、别让模型"扩写 Prompt"，让它定位缺陷

让 LLM 帮忙改 Prompt 是合理的，但需求不能写成"帮我优化得更详细"。

"更详细"没有验收标准，模型最擅长的回应就是补充一堆看似周全的通用规则。文本更丰满，系统未必更可靠。

可以换成这种约束更强的修改任务：

请审查以下 Agent 指令，识别四类问题：
1. 缺失的必要条件；
2. 会导致不同解释的歧义；
3. 与其他规则冲突的要求；
4. 不改变行为的重复表述。

对每项建议：
- 指出对应的原始位置；
- 说明它解决的具体失败风险；
- 给出最小修改方案；
- 说明可能引入的行为变化；
- 给出可验证该修改是否有效的测试用例。

无法从现有信息确认的业务规则，标记为"待确认"，不得自行补充。
​

这套要求的重点在于"最小修改"和"可验证"。

Prompt 优化不是文案润色。它接近于修改生产规则：每多加一条约束，都可能修复一个失败，也可能压制原本正常的路径。没有回归测试的优化，很容易从修复一个 case，演变成制造三个新的边界问题。

五、用结果决定长度，而不是凭感觉删改

Prompt 的质量，最终需要落在可测结果上。

先区分你要解决的是质量问题还是成本问题：

• 模型漏条件、引用错资料、调用错工具、违反权限边界，属于质量问题；
• 输入 token 过多、响应变慢、维护困难、多人修改冲突，属于成本问题。

两者会互相影响，但不能混为一谈。

短 Prompt 可能省下了输入成本，却导致模型多走两轮纠错，端到端成本反而更高。增加几十个 token 的明确验收条件，可能减少一次高风险工具调用，整体收益很大。

一个最小的验证闭环可以这样建立：

测试集不一定要从一开始就很大，但至少要覆盖：

• 正常成功样本；
• 过去失败过的样本；
• 边界条件和冲突条件；
• 工具调用失败或资料缺失的样本。

如果 Agent 具有随机性，单次跑通意义有限。对于高风险任务，应重复运行，并记录 pass rate、关键规则遵循率、工具调用次数、总 token、端到端延迟和人工返工率。

模型说"我已经全面检查"，回答写得更长、更自信，都不能作为通过依据。最终还是要看验收结果。

六、Prompt 的终点是可维护的决策系统

提示词工程走到 Agent 阶段，核心工作已经不是写一句更聪明的咒语。

它更像在维护一个由规则、资料、工具、状态和反馈构成的决策系统。系统指令承担稳定边界，Skill 承载领域流程，工具提供外部行动能力，评测集负责把"感觉变好了"变成可验证的结论。

因此，下次准备往 Prompt 里再塞一段话前，可以先问三个问题：

1. 它针对的是哪个已观察到的失败？
2. 它应该在什么决策阶段被模型看到？
3. 用什么结果证明它确实有效？

答不出来，先别加。

Prompt 变长有时是必要成本：权限边界、验收条件、关键例外，本来就不能靠猜。Prompt 变短有时也是必要维护：过期规则、跨层重复和无关资料，只会让系统越来越别扭。

长度值得监控，但不该成为优化目标。能稳定解决问题、成本可控、后续还能改得动，才是一份 Prompt 应该停下来的位置。