智能体入门课
authority_and_interop进阶85 分钟

8B

授权、协作与责任:Agent 能做,不等于 Agent 可以做

参考:来源 G · 趋势 2/4 · MCP、A2A 与 Agent 行动责任

学完你能做到

  • 区分 API、MCP、A2A、工作流引擎和 Agent Loop
  • 把自然语言意图转成可检查的委托契约
  • 设计授权证明、责任链、补偿动作和跨组织信任边界

Agent 能连接工具以后,最危险的误解是:“既然它会做,就让它做。”

真实系统必须把三个问题分开:它会不会做、它有没有权做、做错以后谁负责。协议解决连接问题,授权解决边界问题,审计和补偿解决责任问题。三者不能互相替代。

组织 / 系统 AAgent A工具 / 数据MCP 组织 / 系统 BAgent B工具 / 数据MCP A2A发现 · 委托 · 返回 身份、权限、证据和责任仍需系统自己设计
MCP 主要连接 Agent 与能力;A2A 主要连接 Agent 与 Agent。两者都不会自动替你完成授权、验证和责任设计。
部件核心问题不负责什么
API程序如何调用另一个服务不替你决定什么时候调用
MCPAI 应用如何标准化发现和使用工具、资源不自动保证工具可信、权限正确
A2A不同 Agent 如何发现、委托、沟通结果不自动建立跨组织信任和责任
工作流引擎固定步骤由谁按顺序执行不擅长开放路径判断
Agent Loop根据观察结果下一步做什么不应绕过授权和确定性检查

把一句自然语言变成委托契约

“黑色外套有货且不超过 100 美元就帮我买”不应只保存在聊天记录里
{
  "goal": "购买指定款黑色外套",
  "constraints": {
    "maxPrice": 100,
    "currency": "USD",
    "validUntil": "2026-09-01"
  },
  "allowedActions": ["search", "reserve", "purchase"],
  "forbiddenSubstitutions": ["differentColor", "differentProduct"],
  "approval": { "purchaseRequiresConfirmation": true },
  "requestedBy": "user-id",
  "requestId": "unique-id"
}
用户意图目标与边界 委托契约结构化授权 Agent 提议具体动作参数 代码验证权限 · 金额 · 时效 执行与审计结果 · 责任 · 恢复 任何一步不满足条件 → 拒绝、请求确认或升级给人
模型提出动作,确定性系统验证授权;同一个模型不能同时充当请求者、批准者和执行者。

跨组织协作:能通信不等于能信任

  • 身份:这个 Agent 属于谁,代表谁发出请求?
  • 能力声明:它说自己会做什么,是否经过验证?
  • 最小权限:只给当前委托需要的资源和时限。
  • 输入验证:对方传来的内容仍是不可信外部输入。
  • 结果验证:不能因为来自另一个 Agent 就直接当成事实。
  • 责任与追踪:每次委托都要有请求编号、来源、结果和确认记录。

行动以后还要设计“怎么后悔”

失败场景恢复或补偿动作
重复下单幂等请求编号,确保同一授权只执行一次
部分步骤成功记录每步状态,对已成功步骤执行反向补偿
邮件发错发送前预览和确认;发送后只能追加澄清,不能假装可撤销
写入数据错误版本化、备份或事务回滚
跨 Agent 超时标记未知状态,先查询真实结果再决定是否重试

案例推演:能发送邮件,不代表可以替用户承诺价格

销售 Agent 能读取客户邮件、查库存并起草回复。若它直接承诺折扣,就跨过了能力边界、授权边界和责任边界。

本节追问:能力、权限、授权和责任为何必须分别建模? 先不要急着看结论。沿着下面四步,逐项区分输入、决策、证据和失败信号。

每一步都要回答:看到了什么?为何这样决定?怎样证明? 1 能力盘点 说明 Agent 技术上能读、写、发送哪些… 观察 → 决策 → 留证据 2 权限最小化 令牌只开放当前角色所需读写范围 观察 → 决策 → 留证据 3 用户授权 区分阅读、代拟、发送和商业承诺 观察 → 决策 → 留证据 4 责任收口 高风险承诺由有责任的人批准 观察 → 决策 → 留证据 完整案例链:不是记住名词,而是能够用证据作出下一步决定
四步案例推演。手机上可左右滑动查看;每个箭头都代表一次需要证据支撑的状态转换。
阶段本步要做的决定什么算证据最常见的失败
能力盘点说明 Agent 技术上能读、写、发送哪些对象工具能力与数据范围清单完整能调用接口就视为允许调用
权限最小化令牌只开放当前角色所需读写范围权限可撤销、可过期、可审计使用管理员永久密钥
用户授权区分阅读、代拟、发送和商业承诺每类动作有明确同意方式与额度一次“帮我回复”覆盖未来所有客户
责任收口高风险承诺由有责任的人批准日志记录建议者、批准者与执行者出错后只说“是 AI 做的”

阅读方式:先遮住后两列自己回答,再用“证据”和“失败”两列检查理解。

常见误解

仅靠系统提示词写“未经允许不要发送”

实际上

可观察症状:提示词可能被误解或注入,工具权限仍然存在。

更可靠的修复:在工具与业务层强制权限、审批和金额边界。

案例工作坊 · 建议真正动手完成

25 分钟
  1. 为销售 Agent 制作能力—权限—授权—责任四栏表。
  2. 设计 5%、15%、30% 折扣对应的确认层级。
  3. 写一条能让用户撤销自动发送权的设置。
查看参考答案

能力回答“做得到吗”,权限回答“系统准许吗”,授权回答“用户本次同意吗”,责任回答“谁承担结果”。四者不能由同一句提示词代替。

迁移检查:换一个场景还会不会

阻止 Agent 承诺超额折扣的最可靠位置是?

协议与授权不能混为一谈

Agent A 通过 A2A 把付款任务交给 Agent B。为什么 Agent B 仍不能直接付款?