理解模型能力很重要，但理解模型边界更重要。
因为很多 Agent 的失控，并不是因为模型完全不会，而是因为人把本不该交给模型自由发挥的问题，错误地交给了模型。
这两者差别极大。
“模型不会”通常是能力问题，可以通过更强模型、更多上下文、检索、工具或更好流程去改进；而“本来就不该让模型决定”则是边界问题。边界问题不是能力升级就能解决，因为即使模型更聪明，它也仍然不是制度、规则、权限系统、责任链和审计系统的替代品。
所以，本章真正要建立的认识是：Agent 设计里最危险的错误，往往不是模型不够强，而是把边界发包给模型。
一个成熟系统必须坚持一个非常硬的原则：
让模型在边界内做判断，不要让模型自己发明边界。
为什么这个原则这么重要？因为模型的工作方式决定了它天然更适合在既定边界内做启发式处理，而不适合自己生成、解释并执行那些带有制度后果的边界。
模型擅长的是归纳、候选生成、模式识别、信息压缩、语言重写和不完全信息下的启发式判断。它不擅长也不应该独自承担的，是权限划分、合法性认定、硬规则裁决、不可逆动作触发和最终责任归属。
这不是贬低模型，而是把模型放回它真正适合的位置。
最不适合完全交给模型自由发挥的，通常有五类问题。
第一类，是权限制度。
谁能做什么动作，什么动作必须审批，哪个工具谁可以调用，哪个上下文谁可以看到，这些都不应该由模型在运行时“觉得合理”后临时决定。权限之所以叫权限，就是因为它必须先于推理存在，并由身份、角色、调用者、环境和系统配置来定义。
如果一个 Agent 能不能删数据、发消息、转账、执行脚本、访问密钥，只靠 prompt 里一句“请谨慎”来约束，那这个系统本质上就没有真正的权限边界。真正的权限边界，必须落在 RBAC、tool contract、allowed callers、sandbox、审批节点和执行环境隔离这些机制上。
第二类，是核心业务规则。
风控红线、法务边界、医疗禁忌、审批制度、合规要求、拒贷条件、等级划分规则，这些都不适合只存在于 prompt 里。因为 prompt 本质上仍然是对模型的语言引导，而不是可执行、可验证、可追责的规则层。
这类规则的关键特征，是它们不是“建议”，而是“必须成立”。一旦规则被违反，损失不是回答质量下降，而可能是财务、法律、医疗或治理后果。因此，这些规则必须被外置为显式规则、校验器、策略引擎、审批系统或符号约束，而不能交给模型在生成时顺便记住。
第三类，是高风险动作触发条件。
删库、发钱、封禁、签署、下单、发送对外通知、提交工单、执行生产环境命令、升级监控告警，这类动作有一个共同点：一旦执行，代价往往不可逆，或者修复成本极高。对这类动作，系统真正需要的不是“模型大概判断没问题”，而是明确的触发门槛、显式的前置检查、必要时的人类确认，以及完整的日志与回放。
换句话说，高风险动作不能只依赖生成结果。生成结果最多是候选意图，真正的执行资格必须由额外机制确认。
第四类，是关键结构化结果的最终合法性。
很多团队一看到模型能稳定输出 JSON，就误以为结构问题已经解决了。实际上，结构化输出稳定，只意味着“看起来长得像”，并不意味着“结果在业务上合法”。模型当然可以输出候选字段、候选参数、候选 SQL、候选审批意见，但 schema 匹配、字段完整性、枚举合法性、约束一致性、业务规则正确性，都不应依赖模型自觉。
所以，结构化结果至少要过两道关：第一道是格式约束，第二道是语义与规则校验。前者可以靠 JSON Schema、CFG、受控语言或 constrained decoding；后者则要靠规则引擎、validator、符号求解器或后验检查。只做到第一道，不等于可以放任模型自由输出最终可执行结果。
第五类，是系统责任认定。
出了问题算谁的，是否满足合规要求，是否构成对用户权益的影响，是否需要上报、复核、申诉或停用，这些都不是模型在会话中“解释得通”就可以成立的问题。责任是一条制度链，不是一段生成文本。它必须由组织、监管、流程、记录和审计共同定义。
这也是为什么越是高风险行业，越明确地把“AI 可以辅助，但最终责任归人”写进制度、指南和伦理要求里。
从医学、法律到金融，公开材料已经越来越清楚地表达了同一个态度：模型可以帮助人更快地看资料、找候选方案、做第二意见、发现异常点，但不应被赋予最终诊断、最终裁判、最终责任认定或合规豁免的决定权。原因不只是“模型还不够强”，更因为这些结论天然属于制度性边界，而不是启发式边界。
这里必须特别指出一个常见误区：很多人把“有人在环”理解成“那就可以让模型自由发挥了，反正最后有人看一眼”。这仍然不够。
因为如果边界本身没有外置，人工复核很容易退化成事后背锅。真正有效的人在环，不是最后替系统承担责任，而是在系统结构里拥有清晰的触发条件、复核权限、阻断能力和接管位置。换句话说，人类监督如果没有被制度化，它和“事后甩锅”差别不大。
这一点在高风险监管框架里尤其明显。很多制度已经明确要求：高影响 AI 必须定义责任人、审批流程、上线前测试、持续监测、日志留存、申诉与停用机制。也就是说，在高风险场景里，边界从来就不是模型能力内部的问题，而是组织治理外部的问题。
除了制度边界，安全边界同样不能交给模型自由发挥。
近年来 prompt injection 和工具滥用研究已经反复证明，模型非常难稳定地区分“这是数据”还是“这是指令”。一旦 Agent 读取网页、邮件、检索结果、文档、文件或工具返回值，外部环境就可能借由自然语言把恶意意图伪装成看似正常的信息输入。如果系统没有外部的 source-sink 分析、审批、最小权限、沙箱和隔离，模型的“自由判断”就会成为越权调用和错误自动化的入口。
这也是为什么领先团队越来越少谈“把模型再训得更稳一点就好”，而越来越多谈结构化输出、严格工具使用、allowed callers、sandbox、monitoring、human approval、safe URL、fallback 和执行隔离。因为真正可依赖的边界，必须是系统不让它越界，而不是寄希望于模型每次都自觉。
从工程实现上看，把边界外置通常意味着三层结构。
第一层，是模型层。 模型负责归纳、解释、提出候选、澄清缺失信息、生成受控中间表示。
第二层，是规则与约束层。 这里负责 schema 检查、字段合法性、枚举值限制、权限核验、流程门槛、策略校验、工具 contract 和阻断逻辑。
第三层，是责任与治理层。 这里负责审批、签署、升级给人、留痕、监控、申诉和最终问责。
只有当这三层各司其职，Agent 才会真正可控。否则系统虽然“看起来自动化”，实际上是在把制度边界偷换成语言边界。
从这个角度重新看“模型边界”，就会发现一个更深的结论：模型最适合承担的，不是最终裁决，而是高质量候选生成。
它可以读很多材料，给出初步分类，列出风险点，生成候选结构，提出多种方案，提示可能遗漏的信息，帮助人或规则系统更快进入下一步。但最后要不要执行、算不算合法、能不能放行、由谁负责，都不应只由模型自己说了算。
所以，在真正成熟的 Agent 系统里，最稳定的结构几乎都会收敛为：
- 模型做不确定判断与候选生成
- 规则做硬约束与合法性校验
- 人做最终责任确认与例外裁决
一旦把这个结构理解透，第 15 章想解决的问题就很清楚了：不是“限制模型会不会削弱智能”，而是“不给模型边界，系统根本不配进入生产”。