Claude Opus 4.8 新能力：对话中途插入 System Message，Agent 开发终于少点别扭了

Anthropic 在发布 Claude Opus 4.8 的同时，悄悄补了一块 Agent 开发里很关键的拼图：mid-conversation system messages。

翻成大白话：

你可以在一轮对话进行到中途，再塞一条 system 级别的指令，临时改变 Agent 的角色、权限或工作模式。

这件事对普通聊天用户没啥感觉。

但如果你在做 Agent、自动化工作流、AI 编程助手、多阶段任务编排，那就很香了。因为过去很多“劝模型转向”的操作，真的挺别扭。

这个能力到底解决了什么问题？

以前 Claude 的 system prompt 只能放在最开头。

也就是说，你一开始怎么给 Agent 定性，它后面就会一直被这个设定强烈影响。

比如你在开头写了：

你是一个系统设计师。
你擅长做架构设计、模块拆分、接口文档。
你不能写代码，只输出设计文档。

前半段任务很顺：

让它分析需求 ✅
让它设计模块 ✅
让它写接口文档 ✅

可任务推进到后半段，你想让它开始写代码：

现在开始实现代码吧。

问题来了。

模型可能会继续坚持：

我会提供实现思路和伪代码，但不会直接编写代码。

你看，嘴上说“现在写代码”，可开头的系统指令还在那压着。

user message 的分量不够。它很难稳定覆盖最开始的 system prompt。

这就是 Agent 开发里常见的尴尬：任务阶段变了，模型还活在上一阶段。

mid-conversation system messages 是什么？

它允许你在对话中途插入一条新的 system 消息。

这条消息不是普通用户指令。

它是系统级指令，权重更高，可以对前面的系统设定做补充、修正，甚至覆盖某些旧约束。

继续刚才的例子。

开头你让 Agent 当系统设计师，不允许写代码。

到了实现阶段，你可以在对话中途加一条：

从现在开始，你的角色切换为开发工程师。
你可以编写、修改、解释代码。
之前“不写代码，只写文档”的限制不再适用于当前阶段。

这比单纯发一句“你现在可以写代码了”更稳。

因为它不是在请求模型改变，而是在系统层面告诉模型：当前规则变了。

为什么这对 Agent 很重要？

Agent 不是普通聊天。

它经常要跑很长的任务链：

读需求
拆任务
查资料
设计方案
写代码
跑测试
修 bug
写总结

每个阶段对模型的要求都不一样。

让一个 Agent 从头到尾只吃同一份系统提示词，很容易出问题。

场景一：角色切换

产品分析阶段，你希望它谨慎、多问问题。

开发阶段，你希望它直接动手写代码。

测试阶段，你又希望它像 QA 一样挑刺。

过去只能靠用户消息硬拽：

你现在是测试工程师，请开始检查问题。

有时有效，有时它还是带着前面的角色惯性。

现在可以这样做：

你现在进入测试阶段。
接下来以 QA 工程师身份工作。
重点寻找边界条件、异常输入、状态不一致、并发风险。
不要继续扩展功能。

这就适合多阶段 Agent。

场景二：临时改变权限

比如一个代码 Agent，默认只能读文件，不能改文件。

等用户明确确认后，再允许它写入。

中途系统消息可以这样写：

用户已确认进入修改阶段。
你现在可以编辑项目文件。
每次修改前说明目标，每次修改后汇报变更点。
禁止删除未提及的业务逻辑。

这比在普通用户消息里说“可以改了”更可靠。

权限控制是 Agent 的命门。别指望模型靠自觉。

场景三：插入安全边界

假设 Agent 正在处理生产数据库脚本。

你发现任务开始变危险了，可以临时加一条系统级刹车：

当前任务涉及生产数据库。
禁止生成 DROP、TRUNCATE、DELETE 无 WHERE 条件的 SQL。
所有写操作必须先给出回滚方案。
涉及数据迁移时，先输出 dry-run 方案。

这类指令放在 user message 里也能用。

但放在中途 system message 里，约束力更强。

它和旧方案有什么区别？

Claude 4.8 之前，Claude 的消息列表里不能随便放 system 类型消息。

系统提示词通常只能写在最外层的 system 字段里。

对话里一般只有两种角色：

user
assistant

所以 Claude Code 之前用过一种比较绕的写法：

<system-reminder>
请注意，你现在应该遵循新的约束……
</system-reminder>

这相当于在普通消息内容里模拟系统提醒。

能用，但不够优雅。

也不够硬。

现在有了真正的中途 system 消息，就不用再靠这种“贴小纸条”的方式提醒模型了。

API 请求长什么样？

下面是一个示意。

注意：具体模型名和 SDK 字段以 Anthropic 官方文档为准。这里重点看消息结构。

{
  "model": "claude-opus-4-8",
  "max_tokens": 2000,
  "system": "你是一个系统设计师。前期只做架构设计和文档，不直接编写代码。",
  "messages": [
    {
      "role": "user",
      "content": "请为一个任务管理系统设计后端架构。"
    },
    {
      "role": "assistant",
      "content": "可以。下面是模块拆分、数据模型和接口设计……"
    },
    {
      "role": "user",
      "content": "设计已经确认。现在进入实现阶段。"
    },
    {
      "role": "system",
      "content": "从现在开始，你的角色切换为后端开发工程师。你可以编写代码。之前“不直接编写代码”的限制不再适用于当前实现阶段。"
    },
    {
      "role": "assistant",
      "content": "明白。下面开始实现任务管理系统的后端代码……"
    }
  ]
}

关键点就一个：

中途的 system 消息用来声明阶段变化、角色变化、权限变化。

别把它当普通补充说明用。

它应该写得短、硬、明确。

推荐写法：别写散文，写规则

不推荐这样写：

现在我们可能需要稍微改变一下方向，你可以考虑开始写一些代码，如果合适的话，也许可以不用太受之前文档模式的限制。

太软了。

模型看了都想摸鱼。

推荐这样写：

当前阶段切换为代码实现阶段。
你的角色：后端开发工程师。
允许行为：编写代码、修改代码、解释代码。
不再适用的旧约束：只输出设计文档，不编写代码。
输出要求：直接给出可运行代码，并说明文件路径。

这种写法更适合 Agent。

因为它像配置，不像聊天。

一个好用的模板

你可以把中途系统消息写成这个结构：

当前阶段：{阶段名称}
角色切换：{新角色}
允许行为：{可以做什么}
禁止行为：{不能做什么}
覆盖旧规则：{哪些旧限制不再适用}
输出格式：{接下来怎么输出}

例如：

当前阶段：Bug 修复
角色切换：资深前端工程师
允许行为：阅读代码、定位问题、修改代码、补充测试
禁止行为：重构无关模块、改动公共 API、删除现有测试
覆盖旧规则：不再只做问题分析，可以直接给出补丁
输出格式：按“问题原因 / 修改方案 / 代码变更 / 验证方式”输出

这类提示词很适合放进工作流节点里。

比如：

plan 节点：规划任务
implement 节点：写代码
review 节点：审查变更
fix 节点：修复问题
report 节点：生成总结

每个节点切换时，塞一条中途 system 消息。

Agent 会稳定很多。

Prompt Caching 会不会被破坏？

这个能力很贴心的一点是：不会影响 Prompt Caching。

这对长上下文 Agent 很关键。

很多 Agent 的初始系统提示词非常长：

工具使用规范
项目背景
安全策略
输出格式
代码风格
业务约束

如果每次阶段变化都要重写整段系统提示词，缓存命中率就难看了。

现在可以保留开头那份稳定的系统提示词。

后面只追加一小段中途 system 消息。

好处很直接：

长系统提示词继续走缓存
阶段切换更轻
Agent 编排更干净
不用反复拼一大坨 Prompt

开发时少掉一堆字符串拼接地狱，谁用谁知道。

适合用在哪些项目？

AI 编程助手

比如你做一个类 Claude Code 的工具。

可以按阶段切换：

只读分析
生成方案
等待确认
修改文件
运行测试
修复失败
输出报告

每进入一个新阶段，用中途 system 消息更新权限和职责。

自动化办公 Agent

比如一个帮你处理合同的 Agent。

可以这样分阶段：

提取关键信息
标记风险条款
生成修改建议
输出邮件回复

到了风险审查阶段，就给它更严的系统指令：

当前阶段：合同风险审查。
角色：法务审查助手。
重点检查付款义务、违约责任、自动续约、数据使用、单方解除条款。
禁止给出最终法律结论，只输出需人工确认的风险点。

这比一句“帮我看看风险”靠谱多了。

多 Agent 协作

一个 Agent 负责规划，一个 Agent 负责执行，一个 Agent 负责审查。

如果你不想真的拆成多个模型调用，也可以用同一个对话，通过中途系统消息切换“人格”。

比如：

当前阶段：审查。
你现在扮演严格的代码 Reviewer。
不要继续实现新功能。
只检查当前补丁的问题。
重点关注安全、性能、边界条件、可维护性。

别小看这句话。

它能把“继续写代码的惯性”拉回来。

避坑清单 ⚠️

这里有几个限制，写代码前一定要看。

只支持 Claude Opus 4.8

目前这个能力只支持 Claude Opus 4.8。

别拿 Sonnet、Haiku 或旧版本硬试。

试半天报错，不是你代码写得丑，是模型不支持。

只在部分平台可用

当前可用范围：

Anthropic 自家 API
AWS 上的 Claude Platform

当前不支持：

Amazon Bedrock
Google Vertex AI
Microsoft Foundry

如果你的企业环境走 Bedrock 或 Vertex AI，暂时别把这个能力写进生产链路。

不然本地跑得好好的，上云直接翻车。

不能放在对话开头

开头的系统提示词，还是用顶层 system 字段。

中途 system 消息不是拿来替代初始系统提示词的。

错误示意：

{
  "messages": [
    {
      "role": "system",
      "content": "你是一个代码助手。"
    },
    {
      "role": "user",
      "content": "帮我写一个登录接口。"
    }
  ]
}

正确思路：

{
  "system": "你是一个代码助手。",
  "messages": [
    {
      "role": "user",
      "content": "帮我写一个登录接口。"
    }
  ]
}

不能连续放两条 system 消息

中途 system 消息不能一条接一条堆。

错误示意：

[
  {
    "role": "user",
    "content": "现在进入开发阶段。"
  },
  {
    "role": "system",
    "content": "你现在是开发工程师。"
  },
  {
    "role": "system",
    "content": "你还要遵守代码规范。"
  }
]

要合并成一条：

[
  {
    "role": "user",
    "content": "现在进入开发阶段。"
  },
  {
    "role": "system",
    "content": "你现在是开发工程师。允许编写代码。必须遵守项目代码规范。输出时说明文件路径和变更原因。"
  }
]

少一点碎片，多一点确定性。

必须跟在 user 消息后面

中途 system 消息需要跟在 user 消息后面。

推荐结构：

[
  {
    "role": "user",
    "content": "设计确认，进入实现阶段。"
  },
  {
    "role": "system",
    "content": "当前阶段切换为代码实现。你可以直接编写代码。"
  },
  {
    "role": "assistant",
    "content": "好的，下面开始实现……"
  }
]

别随手塞。

Agent 的消息编排要规矩，不然排查问题会很痛苦。

普通用户需要关心吗？

如果你只是打开 Claude 聊天、写文章、问问题，不用管。

这个能力主要给 API 开发者用。

尤其适合这些人：

做 AI Agent 的
做 AI 编程工具的
做自动化工作流的
做企业内部 AI 助手的
需要长上下文、多阶段任务控制的

普通聊天里，你直接说“换个角度回答”就够了。

API 里要稳定、可控、可复现，就得用更硬的机制。

实战建议：别滥用

中途 system 消息很强，但别每轮都塞。

推荐只在这些时刻用：

任务阶段发生变化
Agent 权限发生变化
角色职责发生变化
安全边界需要收紧
旧系统指令需要局部覆盖

不推荐用来写这些东西：

普通追问
临时补充资料
用户偏好
一次性的输出要求

这些放 user message 就行。

系统级指令用太多，后面你自己也会看懵：到底哪条规则还有效？哪条被覆盖了？谁说了算？

别把 Agent 做成 Prompt 版意大利面。🍝

可以直接拿走的 Agent 阶段切换示例

从规划切到执行

当前阶段：执行。
角色切换：工程实现助手。
允许行为：编写代码、修改文件、生成测试。
禁止行为：重新规划整体架构，除非发现原方案不可实现。
覆盖旧规则：不再只输出计划，可以直接给出实现内容。
输出格式：按文件路径分块展示代码，并解释关键改动。

从执行切到审查

当前阶段：代码审查。
角色切换：严格代码 Reviewer。
允许行为：指出缺陷、给出修改建议、标记风险等级。
禁止行为：继续添加新功能。
审查重点：安全漏洞、边界条件、并发问题、错误处理、可维护性。
输出格式：按“问题 / 影响 / 建议修改”输出。

从审查切到修复

当前阶段：问题修复。
角色切换：负责落地修改的开发工程师。
允许行为：根据审查意见修改代码、补充测试、解释验证方式。
禁止行为：引入无关重构、扩大修改范围。
输出格式：先列修复清单，再给出代码补丁，末尾说明如何验证。

结语

mid-conversation system messages 看起来只是 API 多了一个消息类型。

对 Agent 开发来说，它解决的是一个老问题：对话跑到一半，怎么让模型稳定进入新阶段。

以前靠普通消息劝。

现在可以用系统消息切。

做单轮问答，感知不强。

做长链路 Agent，这就是很实用的控制杆。

如果你正在做 AI 编程助手、自动化流程、企业内部 Agent，可以把它放进你的任务编排器里试试。尤其是“规划 → 执行 → 审查 → 修复”这种流程，效果会很明显。