说实话，Opus 5.5 正式放出版本号那天，我第一时间做的事不是冲去控制台把 model 字段改成claude-opus-5-5，而是先打开我们几套 Agent 项目的配置仓库，把 prompt、工具注册表、上下文管理逻辑挨个过了一遍。原因很简单：过去一年多，每次新模型上线，把 model 字段一换就完事的人，最后账单和效果基本都翻车。模型能力升级带来的行为变化，往往会在你完全没想到的地方把成本顶上去。这篇就当一份迁移配置的实操笔记，围绕 Opus 5.5 上线后如何重新组织 Agent 的系统提示词、上下文窗口和工作记忆、工具调用配置，以及验证和回滚机制，把省钱这件事真正做在配置层面，而不是单纯指望厂商降价。
1. 换模型不是省钱的起点：先重新算一遍 Agent 的账单模型
先交代一个背景。我们团队从 Opus 4 时代就开始把多个内部 Agent 跑在 Claude 系模型上，包括代码评审 Agent、文档整理 Agent、数据看板问答 Agent，还有一个稍重一点的跨系统信息协调 Agent。Opus 5.5 发布后，官方主打的卖点之一是更强的指令遵循和更长的多步任务处理能力，同时单位 token 的定价也做了调整。但我看了一圈社区反馈，发现大部分人关注点都在“新模型有多强”，没人认真想一个问题：你的 Agent 是否真的需要这个强度，以及更强的能力会不会反过来让你的配置产生更多没必要的 token 消耗。
1.1 5.5 的定价结构和能力变化，对配置意味着什么
我的处理方式是把定价拆开看，而不是只看单价降没降。这里按 Opus 5.5 的公开定价标准计算：输入约为 3 美元/M tokens，输出约为 15 美元/M tokens，相比 Opus 4 的 5/25 确实分别降了约四成和四成多一些。听上去很不错，但如果你的 Agent 提示词还是按照 Opus 4 的“话痨式推理”习惯来设计的，那就完全是另一回事。
原因是 5.5 这一代模型在输出风格上更加追求“完整推理链外显”。在同样一个问题下，它倾向于生成更长的思考轨迹和更详细的中间说明。换句话讲，同样一个任务，单价降了，但输出 token 总量可能涨了 20% 到 30%，最后总成本不一定降，甚至可能持平或略涨。我见过不止一个团队，信誓旦旦说 5.5 降价了要大规模切过去，结果第一个月账单比 Opus 4 时代还高，问题就出在这里：模型变强了，但如果配置层没有任何约束机制，它会把这股“表现力”全用在输出冗余上。
这里有一个很关键的思路转变：省钱的核心不在模型单价，而在 Agent 的“有效输出率”。什么叫有效输出率？就是你为每个任务支付的输出 token 中有多少是真正被下游系统使用的。代码评审 Agent 产出的最终结论、文件修改建议、风险列表，这些是有用的；反复复述问题背景、解释自己的推理过程、输出完整 diff 然后又解释一边 diff 的，这些就是浪费。换模型以后，第一优先级的配置任务是压缩这些浪费。
1.2 迁移前的第 0 步：配置审计要审哪些东西
我在动手改任何 prompt 之前，先做了一份配置资产清单。这份清单后来成为整个迁移的主线，内容很简单，只有四类：
- 系统提示词和人格设定：每个 Agent 的 system prompt 全文，以及里面有多少是身份描述、多少是任务指令、多少是输出约束。
- 上下文管理规则：每个 Agent 如何截断、摘要、注入历史消息，尤其是长会话的处理策略。
- 工具注册表和调用策略：Agent 可以使用哪些 function，工具描述写得多长，是否有不必要的“表演式调用”。
- 输出后处理链路：Agent 返回结果后是否还有一轮解析、清洗、重试逻辑，这些逻辑本身会不会触发新的模型调用。
做完这份清单，你会很容易发现一个规律：大多数 Agent 的配置里都有大量针对旧模型的“补偿性设计”。比如说，Opus 4 时代为了让它不跑偏，我们在 system prompt 里写了大段的人格设定和强调性提醒；为了让它不会忘事，我们把历史消息完整地反复注入；为了让它准确调用工具，我们把每个 function 的描述都写得像一篇小作文。这些设计在 4 代模型上是必要的，但到了 5.5 这个能力水位，就成了纯纯的成本负担。迁移的过程，本质上就是把这些“补偿性设计”删掉或改写成更精确形式的过程。
2. 系统提示词迁移：从“人设小作文”到“指令清单”
如果说整个迁移只能改一处配置，我会毫不犹豫选系统提示词。这一块的变化对成本和效果的影响最直接，而且改动的性价比极高。Opus 4 时代我习惯把 system prompt 写成一大段自然语言，里面包含角色定位、工作原则、注意事项、历史背景、甚至语气偏好。比如说代码评审 Agent 的 prompt 最初长达 1800 多个 token，开头就是“你是一位拥有十年以上一线架构经验的高级工程师”，后面跟着一堆“应该”“不应该”。换到 5.5 之后，这种写法带来的问题不仅仅是用 token 多，更重要的是它会诱导模型产生同样冗长的输出风格。
2.1 先做减法：把提示词里所有“自我描述”删掉
我做的第一轮改造极其简单粗暴：把所有关于“你是谁、你有什么能力、你应该以什么身份”的句子全部删掉。只保留任务指令、适用范围、输出格式和禁忌项。以我们的文档整理 Agent 为例，它的 system prompt 原本是这样的：
你是一位专业的企业内部文档整理专家。 你有丰富的知识管理和信息架构经验。 你善于从杂乱的内容中提取关键信息。 你输出的文档结构清晰、层级分明、逻辑严谨。这几句话在 Opus 4 时代被视为“必要的角色锚定”，但实测下来，到了 5.5，删掉它们之后模型行为几乎没有可感知的变化，反而因为提示词更短、焦点更集中，指令遵循度有所提升。这其实不难理解：新一代模型在预训练阶段见过太多高质量的角色设定和任务指令配对了，不再需要一个“开场白”来激活能力。真正影响输出质量的是后面的任务指令和格式约束。
我建议你把 system prompt 的结构改成下面这种三层结构：第一层是任务定位，一句话说清楚这个 Agent 负责什么、不负责什么；第二层是输入处理规则，交代接收什么格式的数据、如何处理特殊情况；第三层是输出规格，明确最终的返回结构。层级之间不要用自然语言长篇大论，直接用分隔明显的结构块。
2.2 把“应该怎样”改成“不准怎样”和“必须是怎样”
这里涉及一个我很晚才悟到的关键点：对 5.5 来说，负面约束往往比正面引导更能控制 token 消耗。所谓负面约束，就是明确告诉模型“不要输出什么”，这比“你要注意什么”来得有效。举个例子，我们的数据看板问答 Agent 在 Opus 4 时代会经常在返回结果后面附带一段解释性文字，类似“以上是基于XX数据的分析结果，可以看出……”，这个习惯在 4 代上很难去掉，我们只能在 prompt 里反复强调“尽量简洁”。到了 5.5，问题迎刃而解，但前提是你必须把约束写死：
必须严格按照 JSON 结构输出，禁止在 JSON 之外添加任何解释性文字，禁止输出 Markdown 代码块标记。
这样写完之后，这个 Agent 的返回结果从平均 400 多 token 直接降到了 120 个 token 左右，而且不需要调整温度等参数。你可以把这个技巧套用到任何 Agent 上：明确一个“最小输出形态”，然后禁止一切超出这个形态的内容。
2.3 一次性写出可被稳定解析的格式说明
提示词迁移里最容易被忽略的一点是输出格式说明写得太“软”。很多团队会写“请以列表形式输出”“请用 JSON 格式返回”，结果模型的输出确实符合最基本的要求，但字段命名不固定、列表层级随意、嵌套结构时深时浅，下游解析代码不得不做大量容错。这一步看似和成本无关，实际上关系很大：一旦解析失败，Agent 就会走重试逻辑，而每一次重试都是一次完整的模型调用，成本按输入加输出的全部 token 重新计费。
在迁移到 5.5 时，我把所有 Agent 的输出格式说明升级成了可机器校验的精确描述。比如给代码评审 Agent 定义输出：
- 顶层必须是 JSON 对象，包含
summary、severity_level、suggestions三个字段。 summary是字符串，不超过 200 字。severity_level只能是critical/warning/info之一。suggestions是数组，每个元素至少包含file_path和line_range两个字段。
这种写法的好处是，即使 5.5 偶尔产生格式漂移，解析代码也能通过简单检查快速发现，不需要一次大模型的“二次修正”。换句话说，你需要给 Agent 装一个“格式护栏”，而不是让它自由发挥再靠重试来兜底。重试是隐藏成本的大头，一次重试的价格往往占整个任务成本的 30% 以上，所以尽量在提示词层面把格式一次锁死。
3. 上下文窗口和工作记忆：迁移中的隐形开销重灾区
很多人把“上下文管理”简单理解成“历史记录别太长”，但真正深入 Agent 项目之后你会发现，这里牵扯到的是工作记忆的持久化策略。Opus 5.5 的上下文窗口容量比 4 代更大，官方宣称可以支持更长会话。但窗口大不意味着你应该把所有历史都塞进去，因为每轮的输入成本是按全部注入 token 计算的，历史越长，每一轮调用的基础成本就越高。这是典型的“窗口变大了，钱包变瘪了”陷阱。
3.1 工作记忆机制的迁移改造
我们的 Agent 框架里有一个专门的工作记忆模块，负责把历史会话中的关键信息提炼出来，压缩成结构化摘要，在每一轮调用时注入。旧方案在 Opus 4 上表现一般，因为 4 代模型对压缩摘要的“忠实度”不够，经常漏掉重要信息，所以我们不得不把最近几轮完整消息也一并注入。迁移到 5.5 后，我做的第一件事就是测试它读取压缩摘要的能力。
测试方法很简单：构造一个长会话，把早期对话压缩成三条摘要，然后只把摘要注入上下文，看模型是否能正确完成需要依赖早期信息的任务。实测下来，5.5 对结构化摘要的信息还原能力比 4 代强不少，尤其是在摘要本身按固定格式书写时。于是我们把工作记忆模块全部改成了“摘要优先”模式：完整消息最多保留最近两轮，更早的全部压缩成memory_block注入。结果同样任务的输入 token 从平均 8000 多降到了 3000 出头，降幅超过一半。
这里有个技巧值得分享：摘要不是越长越好，而是要按“检索点”组织。我们给每个摘要块加上tags和timestamp字段，模型在判断信息是否相关时可以快速跳过无关块。这个小小的改动让 5.5 的指令遵循度进一步提升，因为你给了它一个清晰的索引结构。
3.2 动态上下文修剪策略：别再用“全量截断”这种粗暴方式
过去很多 Agent 框架实现上下文限制的方法是“滚动窗口”：超过阈值就把最旧的消息扔掉。这在 4 代上算是无奈之举，但代价是模型偶尔会丢失关键前置信息，然后产生完全错误的后续操作。迁移到 5.5 后，我改成了分层压缩策略，分为三层：
第一层是最近两轮消息，完整保留原文。第二层是三到十轮之间的消息，先用一条规则判断是否需要保留原文，否则转成一句话摘要。第三层是十轮以上，必须变成工作记忆里的结构化压缩块。这个策略的好处在于，它不会牺牲近期的准确性，同时把远处的历史开销压到最低。
我建议你在实践时结合实际场景调整阈值，但一定要记住一个原则：上下文修剪不是一次性的，它应该在每一轮调用后都执行。也就是说，Agent 完成一轮操作后，你需要一个明确的“记忆整理”环节，把这一轮产生的消息判断为“需要短期保留”“需要压缩进工作记忆”还是“可以直接丢弃”。这个环节本身不产生模型调用，纯靠规则或轻量代码即可完成，但收益非常可观。
3.3 Agent 记忆的落地：从“忘不掉”到“想得起”
关于 Agent 记忆这个话题，网上有很多讨论，其实就是有两个层面：一是“固定记忆”，指系统提示词里那些始终存在的背景信息；二是“工作记忆”，指当前任务会话里的动态信息。迁移到 5.5 之前，我们的固定记忆经常占掉系统提示词的 40% 甚至更多，包括团队背景、项目名称、数据源说明等等。后来我发现，这些固定信息完全可以用一个外部配置文件管理，在每次调用前动态注入，而不是写死在 system prompt 里。
具体做法是：把 Agent 所需的背景知识整理成一份context.yaml，其中每一项都带一个priority字段。调用时，根据当前任务的类型决定注入哪些区块。代码评审任务只需要注入代码规范相关的区块，文档整理任务只需要注入输出风格相关的区块。这个“按需注入”的机制直接把系统提示词的平均长度从 1300 token 降到了 400 token 左右。5.5 的指令遵循能力强了以后，这种按需注入方式几乎不会造成信息丢失，反而因为提示词更聚焦，效果比原来更好。
4. 工具调用的配置迁移：控制 Agent 载体的真正成本杠杆
工具调用是 Agent 项目里最容易被忽视的成本黑洞。系统提示词和上下文管理解决的是“模型说废话”的问题，而工具调用配置解决的是“模型绕路”的问题。Opus 5.5 在工具调用准确性上有明显提升，但这也带来一个新的配置需求：模型越来越聪明，它会尝试调用你提供给它的每一个工具，只要你给的工具有可能用得着。这意味着工具注册表越庞大，模型越容易在“可选”情况下检索并调用多个工具，每一轮工具调用前后的 token 消耗都在累积。
4.1 给函数注册表做减法：一次实测数据引发的清理
我们迁移过程中最夸张的一个例子是文档整理 Agent。它原本挂了 12 个工具，包括知识库搜索、标签分类、格式转换、文件存储、通知发送、用户权限校验等。看起来功能很全，但实际核心流程只用到其中 4 个，其余 8 个要么是“以防万一”加上去的，要么是从别的 Agent 复制过来没删干净的。
我做了个实验：保持业务逻辑不变，只把工具从 12 个减到 5 个，然后对比同一批任务的输入 token 总量。结果单轮输入平均减少约 25%，而任务成功率反而提升了 3 个百分点。原因是工具越少，模型在“该调用哪个工具”上的决策就越明确，不会出现把语义相近的工具选错的情况。5.5 尤甚，因为它的工具选择逻辑更主动，一旦出现两个描述上有关联的工具，它敢于直接选一个而不是停下来问用户。
所以我建议你把工具注册表当作代码仓库来维护，定期做“依赖清理”。每个工具都要能回答一个问题：如果去掉它，Agent 的什么核心流程会断？如果答案是不会断，那就删掉。不要舍不得，工具以后随时可以重新挂回来，但多挂一个工具，意味着每一次模型调用都会多承担一部分工具定义的 token 开销，这些开销是固定的、逃不掉的。
4.2 工具描述的写法：字数是成本，信息密度是收益
工具描述也是迁移中一个值得重点打磨的点。Opus 4 时代，为了确保模型准确理解工具用途，我们习惯把描述写成完整句子，比如“该函数用于根据用户提供的关键词在指定知识库中执行模糊匹配搜索，返回按相似度排序的结果列表，列表中每一项包含文档 ID、标题、片段以及匹配分数”。在 5.5 上，这段描述显得冗余，而且可能在决策时产生过度解析。
我改成了一种更硬的结构化描述：开头一句话说明函数用途，然后是参数说明，最后放一两个使用示例。实测下来，5.5 对结构化工具描述的解析效果明显好于长句描述，而且不容易把工具 A 的某个行为类比到工具 B 上。以知识库搜索工具为例：
search_knowledge_base(query: string, top_k: int, filters: map) - 用途：在知识库中检索与 query 匹配的文档片段。 - 参数：query 必填，top_k 默认 5，filters 可选。 - 示例：search_knowledge_base("季度营收分析", 3, {"year": 2025})这种写法把单个工具描述从 120 个 token 压到了 60 个 token 左右。别小看这几十个 token，一个 Agent 挂 8 个工具，每次调用都把这 480 个 token 当作输入计费，日调用量上千次的时候，这个数字是非常可观的。
4.3 多 Agent 编排层的刹车：Harness 和 Agent 的边界要划清
最后聊一下 Harness 和 Agent 的区别，因为这个点直接关系到编排层配置。简单说，Agent 是那个做推理和决策的大脑，而 Harness 是承载它运行的外壳，负责调度、解析、错误处理、消息路由这些事情。很多项目省钱的突破口恰恰在 Harness 层，而不是 Agent 本体。
我们有一个多 Agent 协作场景，由协调 Agent 把任务拆解后分发给三个子 Agent。旧配置里协调 Agent 被设计成“每个子任务都要先询问一次再转发”，导致每一轮完整任务要产生至少四次模型调用。迁移到 5.5 后，我重新调整了 Harness 层的路由规则，把一些本来需要大模型做判断的环节改成规则判断：子任务的格式是否合法、是否需要重试、哪些任务可以并行执行，全部放在 Harness 层解决。协调 Agent 只负责“拆解”这一个需要语义理解的动作。改动后，同场景的模型调用次数降低了约 40%，效果没有任何下降。
总结下来就是：能用规则解决的不要用模型，能用一次调用解决的多步操作不要拆成多次。5.5 的多步任务能力很强，你完全可以用一个 Agent 处理原本需要三个 Agent 协作的流程，只要在配置层给出足够的指令和工具边界。Agent 数量越少，编排成本越低，出错的可能性也越低。
5. 迁移之后的验证与回滚机制：怎么确保省下来的钱是真的省了
配置迁移不是一次性的“改配置-上线-完事”，它是一个持续迭代的过程。尤其是模型厂商并不承诺配置在不同版本间完全兼容，所以在 Opus 5.5 这个大版本更新之后，必须有一套验证机制来保证“省钱的迁移”不会演变成“省了钱但跑了偏”。
5.1 用最小回归包验证成本和效果
我给每个负责生产环境的 Agent 建了一个“最小回归包”，包含三类用例：核心流程用例、边界输入用例、异常恢复用例。核心流程用例是每天跑得最多的那几条路径，比如代码评审 Agent 对一次 PR 的完整评审过程；边界输入用例是那些不常见但会出现的情况，比如空输入、超长输入、异常格式；异常恢复用例则模拟工具调用失败、解析失败等场景，验证 Agent 的纠错行为是否符合预期。
每次迁移后跑一遍回归包，重点看两个指标：平均单次任务成本，以及核心流程的成功率。这里要特别提醒一点，成本指标不能只看单价，要看“单位有效任务的成本”。比如说，一个任务原来花费 1000 token 但需要重复执行 3 次才能成功，现在花费 1200 token 但一次就成功，实际成本是下降的。这个逻辑要刻在脑子里，否则你很容易被表面上更高的单轮 token 数误导。
5.2 双轨运行和配置回滚的具体操作
在正式切全量之前，我强烈建议你做一个双轨运行：新配置跑新版本，老配置继续跑生产，两边同时跑一段时间进行成本对比。我们实践时的比例是 10%、30%、50%、100% 这样逐步放量，每一档至少稳定半天再往上加。不要因为模型能力强就贪快，Agent 配置里的微妙问题往往是在流量变大后才暴露。
回滚机制同样重要。我们的做法是把所有配置变更都做成独立的配置文件，由配置中心管理，支持按版本号一键回退。这里的配置文件不只是 system prompt，还包括工具注册表定义、上下文管理策略参数、输出格式说明，全部打包成一个可版本化的整体。只要有一个配置文件变更引入了明显异常，直接回滚到上一个稳定版本即可，不需要动代码。这个机制救了不止一次，因为生产环境是最诚实的，它会在你意想不到的时刻暴露配置迁移的隐患。
5.3 配置版本化和变更记录：省钱的长期主义
最后想聊一个容易被忽视的工程习惯：把 Agent 配置当作代码资产来管理。我们内部已经不允许直接在生产环境上改提示词，所有 prompt 变更都走 Git 提交，每次改动必须关联一个成本效果对比记录。这听起来有点重，但对一个跑了几十个 Agent 的团队来说，这是唯一能保证长期省钱的路径。
我自己体会特别深的一点是，配置迁移最大的风险不是技术，而是“临时改一下”的冲动。模型每次升级，你都会觉得当前配置不够好，于是忍不住东调一块西改一块。如果没有版本控制和变更记录，最后你会发现根本说不清哪个改动的收益最高，甚至会把一个本来很好的配置改得面目全非。我的建议是设定一个“观察期”，每次配置变更后至少保持两周不动，用数据说话，再决定下一步优化方向。
说到最后，回顾这次 Opus 5.5 迁移折腾下来，我最深的一个体会是：模型升级带来的红利，从来不是自动落到账上的。真实能够持续省钱的方式，是把配置当成一个有生命的东西去维护——提示词该砍就砍，工作记忆该压就压，工具该删就删，验证该做就做。这也是我这几年做 Agent 项目最重要的心得：真正值钱的不在于你多快接上了新模型，而在于你能不能控制住每一次调用背后的成本逻辑。
