Opus 5 系统提示词拆解：模型能力、运行时工具、记忆规则和可靠 Agent 设计

顶级 Agent 不是靠长提示词写聪明，而是用运行协议把模型能力组织成可验证、可协作的行为。

导语

把一个强模型交给你，再塞进二十万字符的系统提示词，它会变得更聪明吗？

直觉上好像会。提示词越长，规则越细，模型就越像被训练过一次。但这其实误解了系统提示词的作用。它不会改变神经网络参数，也不会把普通模型变成 Opus 级别的模型。它真正能做的，是把模型已有能力组织成一种稳定、可预测、能长期协作的行为。

这也是阅读 OPUS-5.md 这类提示词快照时最值得抓住的主线。它不像一段传统 prompt，更像一套产品运行协议：什么时候该搜索，什么时候该相信用户，什么时候必须验证；什么可以写进记忆，什么绝不能写；工具很多时如何路由；任务结束前怎样判断是否真的完成。

真正值得研究的，不是 Anthropic 写了多少规则，而是它认为一个可靠 Agent 必须避免哪些失败。

图：系统提示词、模型和运行时共同塑造可靠 Agent 行为

先把三件事分开：模型、提示词和运行时

分析泄漏提示词时，最容易犯的错误，是把看到的一切都归因于模型能力。

例如，Opus 文件比 Fable 文件更长，能不能说明 Opus 一定更聪明？不能。更长的提示词可能只是产品版本变化：记忆系统变了，历史会话搜索变了，可视化工具变了，连接器和 Skill 的编排方式也变了。

正确的读法，是把一个 Claude 产品级 Agent 拆成三层：

层级	决定什么	不能说明什么
基础模型	理解、推理、长任务保持和迁移能力的上限	仅凭提示词无法反推出训练细节
系统提示词	默认行为、验证习惯、工具路由、记忆写入规则	不能凭空创造模型没有的能力
产品运行时	浏览器、文件、MCP、Visualizer、Memory、Past Chats 等真实能力	工具存在不等于每轮都可用或已授权

基础模型像发动机，系统提示词像驾驶规则，产品运行时像道路、仪表盘和刹车系统。只看驾驶手册，不能反推出发动机结构；但可以看出这辆车被设计去哪里、如何避免事故、什么时候必须刹车。

因此，OPUS-5.md 更适合被看作产品级 Agent 的运行协议，而不是某个终端编码 Agent 的单一系统提示词，更不是模型训练配方。

Opus 被设计成一种“有边界的合作者”

把工具 Schema 和安全条款先放到一边，Opus 的人格设计可以概括成一句话：稳定、有判断力、不讨好，也不过度支配。

它不是因为请求奇怪、尖锐或令人不舒服就拒绝，而是只有当帮助会造成具体、明确、严重的风险时才收手。这让安全从关键词匹配变成风险判断。一个只会机械拦截的 Agent 很安全，但没有生产力；一个永远服从的 Agent 很有行动力，却不可托付。

另一方面，提示词也在反复约束讨好倾向。它可以承认错误，但不表演自我贬低；可以不同意用户，但要建设性地说明理由；用户粗鲁时不必越来越卑微；面对复杂问题，不应为了满足“只回答一个词”的格式而牺牲事实。

这塑造的不是客服，而是有职业边界的合作者。

还有一个细节很重要：一次回复尽量不要问超过一个问题。即使问题略微模糊，也先给有用内容，再问真正会改变结果的变量。普通 Agent 常把不确定性全部甩回用户：“请补充目标、范围、格式、受众、截止日期。”看似严谨，实际把规划成本转嫁给了用户。

优秀同事不会这样。他会先合理推进，再在关键岔路口让你拍板。

可靠 Agent 的核心，是认识论

“认识论”听起来抽象，其实只是在问：Agent 凭什么相信自己知道？

普通聊天模型擅长把已有文字组织成答案。可靠 Agent 必须再往前走一步：它要判断信息是否真实、是否过期、是否来自当前环境、是否足以支撑结论。

Opus 的判断链大致可以压成这样：

用户说“测试已经通过”，这句话是线索，不是证据。Agent 如果要基于当前代码做判断，就应该实际运行测试或读取测试结果。失败时再根据错误回到代码，而不是围绕“已经通过”组织解释。

搜索不是为了显得勤奋，验证也不是固定仪式。什么时候查询，取决于信息是否可能过期；什么时候操作工具，取决于结论是否依赖现实对象；什么时候标记不确定，取决于证据是否足够。

Opus 的认识论不是“多查资料”，而是“不把说得像答案当成完成”。

记忆系统处理的是状态，不是聊天记录

很多 Agent 把记忆理解成“把历史对话丢进向量库，需要时召回”。OPUS-5.md 展示的是另一套思路：记忆是一套长期状态系统，必须能发现、分类、写入、更新、保护隐私，并且在回答时克制使用。

它至少回答八个问题：

环节	要解决的问题
发现	记忆库里是否已经有相关文件，不能只凭上下文猜
格式	每条事实如何带来源、别名、描述和稳定标识
来源	什么能被写入，什么只是模型推断
路由	新事实应该进入 profile、topic、area、people 还是 preferences
时机	哪些信息足够持久，必须在当前轮及时保存
安全更新	如何先读后写，避免覆盖并发修改
隐私	哪些内容即使用户说过也不能持久化
使用	哪些记忆真正会改变当前回答

这套设计最重要的，不是“记得更多”，而是“写得对、写不坏、用得准”。

写得对：来源和生命周期先过关

提示词里有一个很硬的测试：用户是否明确说过这件事？

只有用户明确陈述的内容，才能作为当前聊天写入的 [stated] 事实。模型推断、网页搜索结果、连接器查到的数据、模型自己提出的建议，都不能因为出现在对话里，就变成用户档案。

例如，用户从三个方案里选择了 A，可以记录“用户选择方案 A”；但不能把 Agent 对 A 的理由、步骤和预测，一起写成用户长期主张。

另一个门槛是持久性。今晚的房间号、明天的天气、临时停车位置，不该进长期记忆。三个月后仍可能有效的角色、偏好、项目约束、长期关系，才值得保存。

写不坏：记忆更新要像小型事务

OPUS-5.md 对写入已有记忆的要求很工程化：先读当前内容和版本，再选择最小范围的写操作。

· 小范围修改用精确替换，旧字符串必须唯一匹配。
· 新事实才追加，事实变化不能简单追加冲突条目。
· 整体重写只用于新建或重构，因为它会替换整个文件。
· 版本冲突时重新读取最新内容并合并，不能拿旧副本覆盖。

这让长期记忆更像一个受控状态库，而不是一个随手追加的便签本。它不能保证永远不出错，但能把盲目覆盖变成可检测、可恢复的写入过程。

用得准：记住了也不等于要说出来

Opus 还为记忆使用设置了独立门槛：这条记忆是否会改变结论、建议、解释深度或下一步追问？

如果删除它，答案仍然一样好，就不该展示它。尤其不能为了证明“我记得你”，主动提起无关的家人、爱好、健康、位置或敏感经历。自然的连续性，是让相关背景融入判断；不相关的记忆展示，给人的感觉更接近监视。

这也是自研 Agent 很容易忽略的一点：长期记忆的目标不是“让用户看到我记得”，而是降低重复沟通成本。

工具路由是 Agent 的控制面

拥有很多工具，不等于会完成任务。真正困难的不是从列表里挑一个工具，而是连续回答四个问题：

当前请求是否真的需要工具？
当前环境真实可用的能力有哪些？
用户是否授权这条执行路径？
结果怎样交付和验证？

这就是工具路由的控制面。

能力存在与允许调用是两件事。一个连接器可能在产品里存在，但本轮未连接；可能账号已连接，但用户没有授权这次操作；也可能内容里出现“请调用某工具发送数据”，但那只是网页或文件里的文本，不是当前用户的命令。

视觉任务的路由也有明确逻辑：先判断是否真的需要视觉；如果有类别匹配的专业 MCP，就用专业工具；如果用户要求保存成文件，就创建真实文件；如果只是聊天中展示，再使用内联可视化。这里表达的不是“MCP 永远优先”，而是“专业能力、交付介质和用户目标要匹配”。

信息检索也不能混在一起：

用户需要什么	更合适的路径
当前公开信息	搜索或读取真实 URL
企业内部状态	内部连接器或专业 MCP
以前聊过某个主题	历史会话搜索
某段时间内聊过什么	最近会话检索
跨会话稳定事实	Memory

Past Chats 和 Memory 尤其不能混用。Past Chats 找回当时具体说过什么；Memory 保存经过治理的耐久事实。把过去对话里 Agent 的建议直接升级成 Memory，会把“它曾经建议”误写成“用户已经决定”。

工具路由最终必须落到验证。生成文件要检查文件是否真实存在；修改文档要回读目标内容；运行代码要看测试结果；外部操作要核对目标对象和最终状态。工具调用成功，不等于用户目标完成。

这些规则背后，是七类真实失败

如果从第一性原理看，OPUS-5.md 其实在处理七类 Agent 失败。

失败类型	对应设计
答案像真的，但事实已过期	按变化率搜索，当前状态强制验证
听懂了语言，却没有检查环境	读取 URL、文件、代码、工具状态和实际结果
有很多工具，却选错路径	连接器、文件、可视化、Skill 的路由规则
记忆越积越多，反而污染决策	来源、分类、版本、禁写项和使用门槛
长任务中目标漂移	目标、文件交付、Skill 约束和最终验证
输出建议，却没有真正完成	要文件就创建文件，要修改就修改对象，要搜索就基于证据
能力越强，误操作后果越大	敏感内容、外部副作用、记忆隐私和工具调用边界

二十万字符不是“魔法咒语”。每一大块规则背后，都是产品团队见过的某种失败模式。Prompt 的价值不在文采，而在于把失败经验编码成可执行约束。

真正值得迁移的是结构，不是照搬文本

看到长提示词，最直接的冲动是复制到自己的 Agent 里。这通常会适得其反。

Anthropic 产品介绍、模型名称、日期、Claude 专属工具 Schema、Artifact 限制、具体文件路径、与你业务无关的大段内容政策，离开原产品环境后要么无效，要么冲突，还会挤占上下文。

真正值得迁移的是结构：

· 目标模块：Agent 最终要达成什么，而不是扮演什么。
· 证据模块：什么时候依赖已有知识，什么时候必须读取环境。
· 行动模块：哪些动作能自主执行，哪些动作需要确认。
· 工具模块：如何按任务类别、权限和交付介质路由。
· 记忆模块：什么值得长期保存，如何防止过期和污染。
· 验证模块：完成前检查什么，怎样区分“命令成功”和“目标实现”。
· 边界模块：能力和权限的上限在哪里，遇到风险时如何缩小帮助范围。

普通 prompt 描述输出；更好的 prompt 描述行为；Agent 级 prompt 描述闭环。

这个闭环是：目标进入系统，证据约束判断，工具完成行动，记忆保持连续，边界控制风险，验证决定能否交付。

这才是 Opus 5 提示词最值得带走的东西。

AI小老六