能力、权限与执行边界

智能体系统只有能够影响模型回答之外的事物时，才会产生实际作用：读取私有数据、运行计算、修改记录、发送消息、操作软件，或把任务委托给其他执行者。架构设计应从系统能够触及的外部结果及其边界出发，而不是从某个框架给接口取的名字出发。

Tool、Agent Skill、Action、插件和协议都是常见的实现形式，但都不是智能体架构中通用的基本组成。同一种能力可以通过带有明确输入输出结构的 API、图形界面、命令执行环境、工作流状态转换或另一个智能体来提供；Skill 可以说明如何使用这些能力，却不会因此授予任何访问权限。

核心论点

模型本身具备的能力、系统授予的权限和环境中实际发生的结果是三件不同的事。架构必须确定系统能够触及什么，强制约束谁可以在什么条件下做什么，并验证环境中究竟发生了哪些变化。

模型可能知道如何撰写邮件，却无权读取邮箱。应用可能提供发送接口，但当前任务没有调用权限。一个已经获准的请求，也可能在部分修改环境之后超时。把这些情况都笼统地称作一次“Tool 调用”，会掩盖系统可靠性和安全性所依赖的关键区别。

从外部结果出发，而不是从接口名称出发

选择框架之前，应先梳理系统可以如何观察或改变环境。下面的分类可以帮助发现能力边界：

能力类别	架构需要回答的问题	示例
观察	哪些事实可以进入当前任务，来自什么来源，时效性如何？	读取记录、查看页面、接收事件
计算	可以在怎样的资源限制和隔离条件下执行哪些转换？	运行代码、解析文档、计算路线
通信	可以用谁的身份向哪些对象传递什么信息？	起草或发送消息、发布回复
暂存	哪些可能的变更可以先行准备，而不立即生效？	生成差异、预留库存、准备付款
提交	哪些外部状态可以被真正改变？	更新数据库、部署软件、转移资金
委托	可以把哪些目标、权限、数据和限制交给其他执行者？	启动工作流、请求另一个智能体、分派人工任务

这不是一套需要强制套用的分类体系，而是一种识别后果的设计工具，因为接口名称可能掩盖真实影响。“使用浏览器”可能包括读取公开网页、向表单泄露私有数据和提交订单。“调用助手”可能把任务委托给权限比调用方更大的服务。系统必须识别整条调用链能够产生的结果，而不能只看第一层接口。

风险通常取决于受影响的资源、作用范围、是否可逆、数据去向和结果不确定性，而不是接口是否被称作 Tool。读取一个公开网页和导出完整的客户数据库都属于读取，但显然不应置于相同的控制边界之内。

区分能力、权限与实际结果

对于每条可能产生重要后果的路径，都要分别回答三个问题：

能力：系统在技术上能够请求或执行什么操作？
权限：哪个责任主体可以代表谁，在什么策略和时间限制下，对哪些资源执行该操作？
实际结果：系统提出、接受并尝试了什么操作，最终从环境中观察到什么结果？

这种区分可以避免几类常见的概念错误。模型会做某件事，不等于系统允许它去做；能够发现接口，不等于拥有调用权限；认证只能确认身份，不能单独决定某项操作是否获准；模型声称任务成功，也不能证明外部结果确实发生。

Saltzer 和 Schroeder 将主体（principal）定义为获得授权并承担责任的实体，并把完整调解和最小权限列为信息保护的基本原则（Saltzer and Schroeder, 1975）。当模型参与选择操作时，这些原则仍然成立：每一次对受保护资源的访问，都必须在模型无法绕过的边界上接受检查。

明确权限传递链

智能体很少只以自身名义行动。它可能代表用户、组织、服务账号或上级智能体执行任务。系统应明确记录这条关系链：

发起请求的参与者
  -> 承担责任的主体
  -> 委托的目标与范围
  -> 运行时身份与凭据
  -> 策略决策
  -> 执行组件
  -> 受影响的资源与目标位置

授权判断至少应把当前请求与主体、操作、资源、租户、数据分级、限制条件、相关状态和有效期绑定起来。必要时还应考虑数据去向、金额、频率、运行环境或审批凭据。长期有效且范围宽泛的凭据很难实现这些约束；范围明确、有效期较短的委托可以降低错误决策或系统受到操纵时的影响。

NIST 在 2026 年发布的软件与 AI 智能体身份概念文件中，把身份标识、身份认证、授权、委托、日志记录和数据流跟踪作为不同的问题。文件还专门提出动态授权、最小权限、权限证明、操作意图表达，以及“代表他人执行”时的委托关系等架构问题（NIST NCCoE, 2026）。它仍是一份征求意见的概念文件，不是已经定稿的标准，但其中对问题边界的划分值得采用。

不要把凭据或不受限制的密钥放进模型可以看到的上下文。模型可以提出操作请求；确定性的执行边界负责取得凭据、评估策略并调用执行组件。访问发生时必须重新检查策略，不能因为此前的提示词允许过、或某项集成已经安装，就推定当前操作已经获得授权。

让操作意图受控地转化为外部结果

模型输出只是一项尚不可信的操作提议。对于可能产生重要后果的任务，可以采用如下流程：

解释意图：根据目标和当前状态形成范围明确的操作提议。
验证：检查输入结构、类型、策略、权限、预算和前置条件。
暂存：在需要时生成预览或待处理变更，暂不让结果生效。
授权：取得与具体操作绑定的策略决定或审批。
执行：由受控组件执行已经接受的操作。
观察：获取环境最终状态的证据。
核对：比较预期与实际结果，并据此更新权威的任务状态。

并非每项操作都需要经历全部七个阶段。纯计算通常可以在验证后立即执行；付款或部署则可能需要暂存、职责分离和执行后的结果确认。是否合并阶段，应根据后果和不确定性判断，不能仅仅因为某个软件库把整个过程包装成了一次方法调用。

有意义的审批针对的是具体结果，而不是抽象的集成能力。“允许访问邮箱吗？”范围过于宽泛；“是否在 17:00 前把这封邮件及附件发送给这些收件人？”才是可以审查的对象。《人工监督与干预》负责说明人员应在何处介入；本章负责提供使这一决定有意义的信息和强制执行边界。

围绕后果设计接口约定

无论采用哪种调用机制，接口约定都不应只描述输入格式，还应包括：

用途与不适用范围
输入、输出与数据分级
观察、计算、暂存、提交或委托的结果
责任主体、所需权限与策略决策点
资源、租户、目标位置与数量限制
前置条件与可接受的状态版本
延迟、取消与超时语义
结果与错误类别
重试、幂等与重复生效语义
可逆性、补偿方式与验证方法
所有者、版本、来源与依赖

当领域中存在稳定约定时，应优先提供符合领域含义的操作，而不是让模型拼接脆弱的命令字符串。例如，refund_order 接口可以约束订单归属、金额、原因和审批；不受限制的 shell 则把重建这些控制条件的责任留给模型和提示词。开放环境有时确实需要通用接口，但它们应运行在隔离环境中，并且只能获得任务所需的数据、网络访问、凭据和运行时长。

智能体与环境之间的接口设计会影响系统行为，并非只影响开发便利性。SWE-agent 的研究显示，针对语言模型交互特点设计接口，能在其软件工程任务中显著改善表现（Yang et al., 2024）。这项证据局限于特定领域，但足以说明接口形态属于系统设计的一部分，不能假设更强的模型会自动弥补设计不良的执行边界。

保留完整的结果语义

执行边界至少应区分：

有证据确认的成功；
输入、权限或策略被拒绝；
尚未产生任何外部影响时发生的失败；
部分操作已经生效；
超时或中断，外部结果未知；
前置状态已经过期或发生并发修改；
返回内容格式错误、不可信或不符合业务含义；以及
委托已被接受，但下游结果仍在等待中。

不要立即把这些状态压缩成自由文本或简单的“成功/失败”。控制回路可能需要操作标识、尝试次数、接受的状态版本、受影响的资源标识、结果证据、是否可重试和核对方法。写入操作超时后，通常应先回读或核对，再决定是否重试。

τ-bench 除了评估对话过程，还会检查最终数据库状态与策略遵循情况，说明看似合理的交互记录不足以证明任务成功（Yao et al., 2024）。“生产工程”部分将深入讨论分布式投递、幂等、补偿和恢复；架构边界必须保留足够的信息，才能支持这些机制。

只开放当前确实可用的能力

系统连接的全部集成，并不等于每次模型调用都应看见或执行的能力集合。当前可用的能力应由以下因素共同确定：

任务目的和控制回路的当前状态；
发起请求的主体、委托关系与租户；
策略、数据分级与结果类别；
运行环境与依赖服务的健康状况；
所需审批或职责分离；
模型是否胜任以及接口是否兼容；
上下文预算与备选能力之间的重叠程度。

《上下文组装与管理》负责决定哪些已经符合条件的能力说明进入某次模型调用；本章负责此前的资格判断、权限判断与强制执行。对模型隐藏接口可以降低误选概率，但不属于授权控制。即使请求来自受到攻击的提示词、过期上下文、嵌套组件或直接 API 调用，执行组件仍必须拒绝不符合条件的操作。

外部注册表、插件、服务器或智能体提供的元数据只能视为声明。启用之前，应验证所有者、版本、完整性、本地风险分级和下游影响。组合也不能悄然扩大权限：被委托的服务、脚本、工作流或子智能体只能获得明确授予的权限子集，而且仍受上级任务的限制并承担可追溯责任。

将具体实现放回正确的位置

建立通用架构之后，常见的行业术语就可以放到各自对应的位置，而不必把它们视为普遍适用的基本组成：

实现术语	它可能表示什么	它不能证明什么
Tool	由模型选择调用的接口，通常具有名称和输入结构	不等于已经授权、安全，也不一定完整说明下游影响
Agent Skill / Skill	可复用说明、参考资料、资源文件或脚本的具名封装	加载后不会自动成为可执行能力，也不会自动获得权限
Action	某个框架中的操作对象、命令、状态转换或界面概念	不是普遍适用的生命周期阶段，也不能证明结果已经生效
协议	关于发现、传输、调用或互操作的规则	不等于应用策略或端到端的责任机制
插件或扩展	产品特有的打包与集成单元	不一定构成稳定的安全边界
计算机操作、代码执行、API、工作流任务、远程智能体	实现观察、计算、修改或委托的不同方式	不具有统一的风险等级或权限模型

例如，MCP 规定了带有输入结构、可被发现并由模型选择的 Tools，也建议对敏感操作保留人工控制（MCP Tools, 2025）。Agent Skills 规范则定义了以 SKILL.md 为核心、可以附带脚本、参考资料和资源文件的内容封装（Agent Skills Specification）。这些都是有用的具体格式，但应当用前文的能力、权限与结果模型来评估，而不能反过来由这些格式定义通用架构。

讨论特定规范或 API 时，应保留其正式英文名称；讨论一般架构时，应直接使用真正想表达的概念，例如能力、接口、任务知识、操作提议、已经生效的结果或委托。

常见失效模式

把接口清单当作架构

架构图列出了 Tools、插件和 Skills，却没有说明责任主体、受影响资源、策略和外部结果。应先识别能够触及的后果与信任边界，再把各种集成映射到其中。

把模型会做什么当作它有权做什么

因为模型能生成 SQL、shell 命令或浏览器操作，系统就给予它宽泛的生产环境访问权限。应将知识与访问权限分开，并在模型之外独立约束执行组件。

把发现能力当作获得权限

刚安装的集成或注册表返回的接口立即变为可调用项。系统既要按相关性筛选，也要在调用时以及下游受保护边界上再次强制检查权限。

把认证当作授权

系统确认了智能体或用户的身份，便允许其执行服务提供的任何操作。授权还必须评估具体操作、资源、范围、当前状态和委托目的。

只靠文字说明控制风险

自然语言说明要求“不得发送敏感数据”，但代码并不检查数据分级或目标位置。应把要求转化为策略、数据流、输入输出校验和执行控制。

隐藏下游影响

一个标称只读的接口在下游触发写入、消息、计费或另一项自主服务。系统应识别并记录完整的影响链。

用布尔值或模型自述表示成功

部分生效与结果未知，都被模型叙述成简单的成功或失败。应保留结构化结果，并在控制回路继续之前验证环境状态。

组合导致权限扩大

脚本、工作流、Skill 或子智能体携带了范围更大的凭据。系统应传递收窄后的委托权限，核算嵌套的成本与影响，并拒绝上级任务本身无权授予的权限。

本手册建议

选择具体实现形式之前，先建立能力与权限清单：

字段	需要回答的问题
用途	哪项目标需要这项能力，哪些情况不适用？
结果	它可以观察、计算、披露、暂存、改变或委托什么？
主体	谁承担责任，操作代表谁执行？
权限	允许哪些资源、操作、目标位置、数量和有效期？
强制执行	哪个非模型组件检查请求，所有路径是否都经过检查？
约定	输入、前置条件、结果、版本和失败语义是什么？
验证	哪些证据可以确认实际外部结果？
恢复	操作能否重试、撤销、补偿、取消或核对？
组合	哪些下游组件会收到数据或委托权限？
归属	谁负责审查接口、策略、依赖和实现的变更？

只有这些问题得到明确回答之后，团队才应决定把能力实现成 Tool、应用命令、浏览器操作、工作流步骤、脚本、服务 API，还是对另一个智能体的委托。

检查清单

参考文献及其用法

Saltzer and Schroeder, “The Protection of Information in Computer Systems” — 用于说明主体、权限、受保护对象、完整调解、职责分离与最小权限等基础概念。原文中的 capability 特指不可伪造的授权凭证，与本章较宽泛的“系统能力”含义不同；原文也未讨论现代 AI 智能体。
NIST NCCoE, “Accelerating the Adoption of Software and AI Agent Identity and Authorization” — 2026 年发布的概念文件，本章引用它对身份标识、认证、授权、委托、审计和数据流问题的明确区分。该文件提出的是待研究问题与项目设想，不是已经定稿的要求或标准。
NIST SP 800-207, “Zero Trust Architecture” — NIST 零信任出版物，用于支持按资源做出访问决策、动态评估策略，以及不因网络位置或所有权而默认信任。本章借用了其中的一般原则，并不声称 SP 800-207 专门针对智能体系统。
Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering” — 原始研究论文，说明有意识地设计智能体与环境之间的接口可能影响任务表现；其实验结果限于软件工程基准。
Yao et al., “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains” — 原始研究论文，用于支持检查环境状态与策略遵循情况，而不是接受看似合理的对话或模型自行报告的成功。
Model Context Protocol, “Tools” — 当前协议规范，仅用作由模型选择调用的接口以及人工控制建议的具体实现示例。
Agent Skills Specification — 当前开放规范，仅用于说明以 SKILL.md 为核心的具名封装形式和渐进式加载方式，不把它视为普遍适用的智能体架构层。
OWASP LLM06:2025, “Excessive Agency” — OWASP 社区风险条目，用于支持减少不必要的功能、权限和自主执行，并对重要操作进行验证与审批。