顶级 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 提示词最值得带走的东西。
推荐阅读
MCP 这次协议升级，真正改的是 Agent 基础设施的伸缩方式
Loop Engineering 与 Graph Engineering 的关系：单任务循环如何进入多节点协作图
[Agent Runtime 如何用 Session、Memory、User Profile 和 Skill 实现外部学习]
