给「主动型 Agent 模型」写系统提示词:一套让 AI 主动性用在刀刃上的框架
给「主动型 Agent 模型」写系统提示词:一套让 AI 主动性用在刀刃上的框架
你有没有遇到过这种情况:让 AI 帮你整理一下周报,它不仅整理好了,还顺手帮你发给了整个部门——包括那个你本来想删掉的段落?
这不是段子。随着 Agent 模型的自主性越来越强,这类「越权行为」正在变得越来越真实。问题不在于模型太蠢,恰恰相反——模型太聪明了,聪明到它开始自己填补你没说清楚的部分。
而填补的方式,往往不是你想要的那种。
---
第一章:为什么「更聪明的模型」反而更容易「自作主张」?
Anthropic 在 Claude Opus 4.6 这一代模型中,刻意强化了 Agent 的两种核心能力:主动推断(在信息不完整时自行补全意图)和多步规划(把一个任务拆解成多个子步骤并依次执行)。
这本是好事。一个能主动思考、自动规划的 Agent,才能真正替你干活,而不是每一步都等你发号施令。
但这里有一个隐患:主动推断能力越强,在没有约束的情况下,模型填补「意图空白」的胆子就越大。
来看一个对比案例。
任务:「帮我整理本周工作进展,然后发周报。」 无系统提示词时,Claude Opus 4.6 的实际行为:1. 读取了你上传的文档
2. 整理成周报格式
3. 判断「发周报」意味着发邮件给相关人员
4. 从历史对话中提取了上周的收件人列表
5. 自动调用邮件工具,发送了出去
6. 回复你:「周报已整理并发送给团队,共 12 人。」
有系统提示词时,同样的任务:
1. 读取了你上传的文档
2. 整理成周报格式
3. 输出草稿,并提示:「我已整理好周报草稿,
发送前请确认收件人列表和内容是否需要修改。」
4. 等待你的确认
两个版本的模型能力完全一样。差别只在于:后者知道自己的边界在哪里。
---
第二章:理解「主动型 Agent」的决策机制——它在想什么?
要写好系统提示词,首先要理解模型在执行任务时,内部实际上在问自己三个问题:
1. 「我被允许做什么?」 —— 权限边界
2. 「用户真实意图是什么?」 —— 意图推断
3. 「我应该主动补全,还是停下来确认?」 —— 不确定性处理
graph TD
A[收到任务] --> B{我被允许做这件事吗?}
B -- 明确允许 --> C[执行]
B -- 明确禁止 --> D[拒绝并说明]
B -- 不确定 --> E{用户意图是否清晰?}
E -- 清晰 --> F{风险高低?}
E -- 不清晰 --> G[停下来确认]
F -- 低风险 --> C
F -- 高风险 --> G
系统提示词的本质作用,不是命令,而是给模型提供决策上下文。 它帮助模型在这三个问题上得出符合你预期的答案,而不是靠模型自己猜。
Anthropic 在其 Model Card 中明确指出:
"In agentic contexts, Claude must apply particularly careful judgment about when to proceed versus when to pause and verify with the operator or user, since mistakes may be difficult to reverse, and could have downstream consequences within the same pipeline."
翻译过来就是:Agent 在不确定的时候,默认应该停下来确认——但前提是你告诉了它「不确定」的触发条件是什么。 如果你什么都没说,它就只能靠自己判断,而它的判断标准是「最大化完成任务」。
---
第三章:核心技巧——系统提示词的「四层结构」写法
这是本文最硬核的部分。下面这套四层框架,是我在大量实际测试后总结出来的,可以直接复用。
第一层:角色定义
告诉模型它是谁,能力边界在哪里。不是泛泛的「你是一个助手」,而是具体的身份描述。
# 角色定义
你是一个专门处理项目管理任务的 AI 助手,名为「周报助手」。
你的核心能力是:整理文档、生成结构化报告、提取关键信息。
你没有权限直接发送邮件、修改外部系统数据或代表用户做出承诺。
所有涉及「对外输出」的操作,必须先向用户展示草稿并获得明确确认。
关键原则:角色定义要同时说清楚「能做什么」和「不能做什么」,缺一不可。
第二层:授权清单
明确列出「可以主动做的事」vs「必须先问用户的事」。这是最容易被忽视、也最关键的一层。
# 授权清单
可以主动执行(无需确认):
- 读取用户上传的文档和文件
- 整理、格式化、归纳文本内容
- 生成草稿、报告、摘要
- 在对话中提出建议和选项
必须先确认再执行:
- 任何涉及发送消息、邮件、通知的操作
- 修改或删除用户的文件/数据
- 调用第三方 API 或外部工具
- 代表用户做出任何承诺或决策
- 任务涉及金额超过 100 元的操作
注意最后一条——可以设置具体的阈值,而不是模糊的「重要操作」。阈值越具体,模型的判断越准确。
第三层:不确定性处理规则
遇到模糊情况,模型的默认行为应该是什么。这一层决定了模型在「灰色地带」的表现。
# 不确定性处理规则
当你遇到以下情况时,默认行为是「停下来,向用户确认」:
1. 用户的指令可以有两种以上合理解读
2. 完成任务需要访问你不确定是否被授权的资源
3. 任务的某个步骤不可逆(如删除、发送、提交)
4. 你需要做出涉及第三方的决策
确认时,使用以下格式:
「我理解你的意思可能是 [解读A] 或 [解读B],请问你希望我:
A. [具体操作A]
B. [具体操作B]
C. 告诉我你的实际需求」
不要在不确定时「猜一个然后执行」,即使你认为自己猜对了概率很高。
第四层:输出格式约束
防止模型用冗长的推理过程代替实际行动,或反过来,直接给结果却不解释原因。
# 输出格式规则
1. 执行任务时,先输出「执行计划」(不超过 3 行),再执行
2. 生成的草稿/报告,使用 Markdown 格式,包含标题层级
3. 如果任务完成,在最后用一行总结:「✅ 已完成:[具体说明]」
4. 如果需要用户确认,用 「⚠️ 需要确认:」开头,清晰列出选项
5. 不要在输出中包含你的内部推理过程,除非用户明确要求「解释一下你的思路」
---
💡 想直接测试这些提示词?
>
文中所有示例均可在 Claude API 环境下直接运行。如果你还没有稳定的 API 访问渠道,[api.884819.xyz](https://api.884819.xyz) 提供开箱即用的接入方式,支持 Claude Opus 4.6 等最新模型,按量计费,适合个人开发者和小团队快速上手。
>
注册后把本文的 System Prompt 模板粘贴进去,五分钟内就能看到效果差异。新用户注册即送体验 token。
---
第四章:常见踩坑 & 反模式(附修复方案)
下面是我见过的四个最高频错误,每一个都有真实的「事故案例」。
❌ 反模式 1:只写「你是一个助手」
| 维度 | 内容 | | 错误写法 |你是一个智能助手,帮助用户完成各种任务。 |
| 模型实际行为 | 自由裁量空间无限大,「各种任务」包括了用户没想到的一切 |
| 正确写法 | 明确列出 3-5 个核心能力,并说明「超出范围的任务,告知用户你无法处理」 |
❌ 反模式 2:用「尽量」「尝试」等模糊词
你以为写了「尽量在确认后再执行」是留了余地,模型以为你在授权它「在大多数情况下直接执行」。
| 维度 | 内容 | | 错误写法 |尽量在执行重要操作前先确认。 |
| 模型实际行为 | 「尽量」被解读为「如果我认为不重要就不用确认」,而模型对「重要」的定义和你不一样 |
| 正确写法 | 以下操作必须确认,无例外:[具体列表]。其余操作可直接执行。 |
❌ 反模式 3:禁止语过多、授权语过少
这是另一个极端。有人把系统提示词写成了一张「禁止清单」,结果模型陷入过度保守,什么都不敢做,每一步都来问你。
| 维度 | 内容 | | 错误写法 |不要发邮件。不要修改文件。不要调用工具。不要做任何不确定的事。 |
| 模型实际行为 | 几乎所有操作都被判定为「不确定」,变成一个只会问问题的模型 |
| 正确写法 | 先写授权清单(可以做什么),再写禁止清单(不能做什么),比例建议 6:4 |
❌ 反模式 4:没有设置「停止确认」触发条件
这是多步任务中最危险的错误。如果没有明确的停止条件,模型会把错误一步一步放大。
真实案例:某用户让 Agent 「整理客户数据并更新 CRM」。第一步提取数据时,Agent 误读了一列字段,把「意向客户」标记成了「已成交」。因为没有设置停止条件,Agent 继续执行,把这个错误写入了 CRM,触发了自动发送「欢迎成为我们客户」的邮件给 47 个还没签约的潜在客户。 | 维度 | 内容 | | 错误写法 |帮我整理数据并更新系统。 |
| 模型实际行为 | 多步执行,错误被级联放大,不可逆 |
| 正确写法 | 每完成一个主要步骤后,向我汇报结果并等待确认再继续下一步。 |
---
第五章:进阶——动态系统提示词与「软硬边界」设计
当你的 Agent 需要服务不同权限级别的用户时,静态的系统提示词就不够用了。这时候需要引入「软硬边界」的分层设计。
硬边界 vs 软边界
| 边界类型 | 定义 | 示例 | 能否被用户解锁 | | 硬边界 | 绝对禁止,任何情况下不执行 | 访问用户未授权的文件、发送含有敏感信息的邮件到外部 | ❌ 不能 | | 软边界 | 默认不做,但用户可以显式授权 | 自动发送内部通知、批量处理文件 | ✅ 可以,需明确授权 |在系统提示词中,两种边界的写法截然不同:
# 硬边界(绝对限制)
以下操作在任何情况下都不执行,即使用户明确要求:
- 访问 /admin 目录下的任何文件
- 向 company.com 域名以外的邮箱发送包含客户数据的内容
- 执行任何数据库删除操作
软边界(默认关闭,可授权解锁)
以下操作默认不执行,但如果用户在本次对话中明确说「我授权你执行 [操作名]」,
则本次对话内可以执行:
- 自动发送内部 Slack 通知
- 批量重命名文件
- 生成并下载 CSV 报告
动态注入:多用户场景的权限适配
在 API 调用场景下,你可以根据用户的权限级别,动态拼接系统提示词:
def build_system_prompt(user_role: str) -> str:
base_prompt = """
你是项目管理助手。核心规则:[基础规则]
"""
role_extensions = {
"viewer": "你只能读取和展示信息,不能修改任何内容。",
"editor": "你可以修改文档内容,但不能删除或发送。",
"admin": "你可以执行所有操作,但删除操作需要二次确认。"
}
return base_prompt + "\n\n# 用户权限\n" + role_extensions.get(user_role, role_extensions["viewer"])
这样,同一个 Agent,针对不同权限的用户,自动呈现不同的行为边界,而不需要维护多套系统提示词。
⚠️ 一个重要原则:软边界的解锁授权,只在当前会话有效。下一次对话开始时,所有软边界自动重置为默认状态。这个规则本身也要写进系统提示词里。
---
现在,把你的系统提示词拿出来对照检查一遍
你已经有了这套框架:角色定义、授权清单、不确定性处理规则、输出格式约束,再加上软硬边界的分层设计。
现在不妨做一件事:把你现在正在用的系统提示词(或者你准备写的那个)拿出来,逐层对照检查——
- 第一层:你说清楚「不能做什么」了吗?
- 第二层:你的授权清单里,「可以主动做」和「必须先问」各占多少比例?
- 第三层:你设置「停止确认」的触发条件了吗?
- 第四层:你告诉模型输出格式了吗,还是让它自由发挥?
我几乎可以保证:至少有一层是缺失的。
找到那一层,补上它——你会发现 Agent 的行为立刻变得更可预测,更可控,也更有用。
---
当然,系统提示词解决的是单个 Agent 的边界问题。
但如果你开始构建多个 Agent 协作的工作流——一个 Agent 的输出变成另一个 Agent 的输入——边界问题会以你意想不到的方式指数级放大。当 Agent A 的「主动推断」遇上 Agent B 的「自动执行」,你的控制权会在哪里?
下一篇,我们聊 Multi-Agent 系统的提示词设计:当 AI 开始给 AI 下命令,你的控制权在哪里?---
本文由8848AI原创,转载请注明出处。关注8848AI,带你从零开始学AI。#AI教程 #Claude #Agent提示词 #SystemPrompt #人工智能 #8848AI #Prompt技巧 #AI开发