该系列的第 7 篇：工具描述的工程化------name、description、parameters 怎么写才少误用把单个工具 的 description 写清楚了，第 8 篇：工具粒度与 Token 预算的权衡把工具列表 按域裁剪了；但在真实对话里，模型仍会犯两类错误：一是明明没有的能力却口头答应 （幻觉），二是在工具已绑定 时过早调用写操作或高危工具 （越权式误用）。很多时候，问题不在工具 JSON 本身，而在系统提示里没有一张「总览地图」------模型不知道「全系统允许的能力包络」长什么样。
想象一下机场安检：每个登机口（工具）旁都有告示，但若入口没有「哪些东西绝对不能带」，乘客仍会在错误柜台排队。能力边界就是入口处的总告示牌。
本篇为系列第九篇 ：讨论如何在 system prompt 中写清 能做什么、不能做什么、推荐路径与优先级 ，并与权限、风控、两阶段确认 配合。文内用同一假设场景 下的 两段 system 文本对照 （极简 vs 带能力边界），说明「入口告示牌」如何降低 越权与幻觉式调用的概率（非绝对保证，随模型与工具描述而变）。
摘要 ：能力边界应覆盖四块：（1）权威数据源 （以工具结果为准，禁止编造业务事实）；（2）禁止项 （无确认不调删除/转账等）；（3）推荐决策顺序 （先只读定位再写）；（4）与工具表一致 （system 不写后端未实现的能力）。边界是提示层软约束 ，必须与执行层硬校验 （鉴权、幂等、dry-run）叠加。具体写法见 §4 的好坏对照。
关键词：System prompt；能力边界；越权；幻觉调用；工具误用；软约束与硬校验
1 为什么仅靠工具描述还不够？
工具级 description 解决的是工具 A 与工具 B 的区分 ；系统级边界解决的是：
- 跨工具的整体策略：例如「任何写操作前必须先完成只读核对」。
- 不存在的能力：例如「不能修改已锁定订单金额」------后端没这接口，就不应在 system 里暗示有。
- 用户话术下的社会工程：用户说「急用，先删再说」，模型仍需遵守禁止项。
🔍 实际例子 ：用户说「帮我查查订单是不是退款了」，模型应优先 get_order_by_id 或退款状态查询类只读工具，而不是直接 create_refund_request。
💡 理解要点 ：System 管「策略与包络」，Tool 管「局部语义与参数」 ；二者冲突时，应以后端真实能力为准修正 system，而不是反过来。
2 能力边界写哪四块最有效？
2.1 权威性与反幻觉
明确：业务事实只能来自工具返回；工具空结果时如实说「未查到」，禁止用常识填补具体单号、金额、状态。
💡 理解要点 ：这与系列第 3 篇：LLM-Friendly 的响应结构：扁平键、稳定字段与类型标注一致：---模型要先学会信数据 ，再学会说人话。
2.2 禁止项（Hard NO）
用可执行的否定句，避免含糊的「尽量」「最好不要」：
- 禁止在未收到明确二次确认 前调用
delete_*、transfer_*等。 - 禁止代用户承诺时效、赔偿、法务结论。
🔍 实际例子 ：把「尽量不要删除」改成「除非 human_approved=true 出现在上下文中，否则不得调用 delete_account」。
2.3 推荐路径（决策顺序）
给一条短流程，减少乱跳工具：
- 澄清缺失的关键 ID / 时间范围；
- 只读检索 / get by id；
- 仍不足再询问用户；
- 用户明确发起写操作再进入写工具。
2.4 与工具注册表对齐
System 中列出的能力名词应与 bind_tools 列表 、OpenAPI/MCP 实际暴露 一致。若写了「可导出报表」但工具未注册，模型会空转 或胡编。
3 与权限、风控的分工（软 vs 硬）
| 层级 | 负责 |
|---|---|
| System 提示 | 降低误调用概率 、统一话术与策略 |
| 工具层 Schema | 收窄参数空间（第 7 篇） |
| 执行前校验 | 鉴权、租户隔离、额度、黑白名单（硬） |
| 产品流程 | 二次确认、审批单、dry-run |
💡 理解要点 ：永远假设模型会违反提示------边界是成本最低的「第一道闸」，不是最后一道。
4 对照示例：极简 system 与带能力边界的 system
下面假设同一套 已绑定工具：get_order_by_id、search_orders、search_kb（偏只读）、request_refund（写）、delete_account（高危）。仅替换 system 正文，便于看出「边界写全」与「只写两句客气话」的差别。
4.1 较差的写法（笼统、缺包络）
只强调「用工具、别编造」，但没有禁止项 、没有先读后写 、没有未注册能力 的声明。在工具列表里若包含高危接口，模型更容易在用户催促下直接调用写操作或删除类工具。
text
你是电商售后助手。你可以在对话中调用工具来完成用户需求。
优先使用工具获取事实，不要编造订单状态。4.2 较好的写法（四块边界落地）
把 §2 的四块收成可执行的短条款 ：权威数据源、硬禁止、决策顺序、与工具表一致（并点名「没有改价/绕过风控」等后端未提供 的能力）。禁止项尽量用可判定条件（例如除非上下文出现明确的人审标记，否则不调某工具）。
text
你是电商售后助手。以下规则必须遵守：
1) 业务事实只能来自工具返回；工具未返回或为空时，明确说未查到，不要编造单号、金额或状态。
2) 禁止调用 delete_account，除非上下文中出现明确标记 human_approved_delete=true
（本对话不会出现该标记，因此永远不要调用 delete_account）。
3) 决策顺序：先澄清缺失的关键信息 → 只用只读工具（get_order_by_id、search_orders、search_kb）
定位问题 → 用户明确发起写操作后再使用 request_refund；不要因用户催促跳过只读核对。
4) 你没有修改订单金额、改价、绕过风控的能力；若用户提出此类请求，应拒绝并说明需要人工处理。
5) 工具列表以 API 绑定为准；不要承诺未注册的工具能力。4.3 同几句用户话下的典型差异（定性）
以下不是统计结论，而是我们在换模型 / 换工具描述 时仍可用的自检直觉：
- 用户说：「我账号不要了，你赶紧帮我删了。」在极简 system 下，模型更可能 直接调用
delete_account或口头答应删号；在带边界 system 下，规则 2 明确禁止在该上下文调用，更可能拒绝并引导人工流程。 - 用户说：「ORD-123456 急着退款，你直接给我退。」极简 下更可能 跳过只读核对就进入
request_refund；带边界 下规则 3 要求先只读定位，更可能 先get_order_by_id再视结果推进。
若两种写法差异不明显，优先回到系列第 7 篇工具描述的工程化------name、description、parameters 怎么写才少误用 检查：工具 description 是否在诱导误用；或换更强指令遵循的模型时观察是否变化。
4.4 仍须牢记
即使「好」的 system 写得清楚，也不能保证 零误调用------执行层 对 delete_account 等接口仍须 鉴权、白名单、二次确认 。永远假设模型会违反提示。
5 小结
- 在 system 里写清 权威性、禁止项、推荐顺序、与工具表一致 四块，可显著减少幻觉承诺 与高危误调用 的概率。
- 边界是软约束 ；执行层 鉴权 + 幂等 + 二次确认 才是硬约束。
- 迭代 system 时，用 §4 这类文本对照 + 自家业务的少量试跑 做自检，通常比凭感觉堆「更长免责声明」更有效。