批量任务上线前，先堵住系统提示词与重复上下文

01 · 调用量放大后，固定提示词也会成为成本主项

团队排查模型开支时，常先盯着回答长度，却忽略每次请求都携带的输入：系统规则、工具说明、历史消息、检索片段。单次看似不起眼，进入持续运行的批量任务后，重复内容便会反复占用预算。这里的“泄漏”不是数据外泄，而是没有增加任务价值、却持续产生计量消耗的上下文。

负责人首先要问的不是“提示词还能删多少字”，而是“哪些内容必须每次发送”。令牌也不等于汉字数；格式、代码和工具定义都会影响计量，应以实际用量为准。

02 · 把系统提示词拆成常驻规则与按需模块

过大的系统提示词往往是一份不断追加的团队手册：输出规范后面接业务背景，再接历史事故、罕见例外和多套示例。结果是，简单分类任务也要携带复杂分析流程。系统位置本身不会让这些内容免于计费。

• › 常驻规则：保留权限边界、安全要求、核心职责和必要的输出约束。
• › 任务模块：按路由加载对应流程，不让所有任务携带所有部门的说明。
• › 参考资料：将长篇事实与案例放入可检索资料，只提供本次需要的部分。

不要为缩短提示词而删除关键约束。每次精简都应回放代表性任务，检查格式合规、工具选择和异常处理；否则，省下的输入可能被重试与人工返工抵消。

03 · 重复上下文通常藏在历史、检索与工具结果里

检查实际发送的请求，而不只是提示词模板。同一份需求可能同时出现在用户消息、会话摘要和检索结果中；工具返回的整份文件，也可能在下一轮再次进入历史。单个组件看起来合理，拼装后的请求却充满重复。

• › 对检索片段去重，并保留必要的来源标识，避免把相邻重叠内容反复发送。
• › 为工具结果设置长度边界，优先传递相关字段，而不是整份日志。
• › 将长会话整理为当前目标、已确认事实和未决问题；摘要不能与完整历史无限叠加。
• › 让独立任务使用独立上下文，避免上一个任务的材料污染下一个任务。

摘要同样会消耗令牌，也可能遗漏信息。需要精确核对的数值、约束和原文，应保留可追溯记录，不能只依赖压缩后的描述。

04 · 缓存降低重复读取成本，不会消除冗余

当模型和接口支持提示缓存时，可将稳定内容置于可复用的前缀，把变化频繁的任务数据放在后部。时间戳、随机标识或动态字段若出现在前部，可能破坏后续内容的缓存复用；具体仍取决于缓存机制。

缓存命中不等于免费，也不意味着上下文变短。缓存写入、缓存读取和未缓存输入需要分别核算。频繁改动、很少复用的长提示词，未必能从缓存中获益。不要仅凭命中率判断优化成功，还要看任务总成本与完成质量。

05 · 上线门槛应看每个成功任务的总消耗

为每个任务记录提示词版本、调用次数、未缓存输入、缓存写入、缓存读取、输出用量及重试情况。将指标汇总到“成功完成一个任务”的成本，而不是只比较单次调用。先在小批量真实任务上验证，再逐步放量；发现质量下降或调用次数增加，就暂停推广。

对于持续高负载团队，Quanta 的按量中转适合集中管理多模型调用预算：一个余额覆盖多种模型，每次调用按实际令牌计量，缓存写入与读取分别计价。你可以开通一个 Quanta 账户，先用固定任务集建立成本基线，再评估提示词与上下文改造的收益。

负责人的长期动作，是给常驻规则、检索材料和历史保留策略指定维护人，并在版本发布时检查上下文预算。成本治理不靠一次大清理，而靠让每一段反复发送的内容，都有明确用途和保留理由。