企业智能体工程体系v1.1｜多智能体协作实战：权限矩阵如何让企业 Agent 学会“拒绝”

当多个 AI Agent 组队进入企业流程，最危险的往往不是能力不足，而是权限泛滥。本文基于真实案例，设计了一套可落地的 Agent 组织架构和权限矩阵，并给出了完整可运行的 Python 代码——让 Agent 既会协作，也会说“不”。

---

一、背景：当 Agent 不再是“一个人”

在企业智能体工程的演进中，单 Agent 往往能完成某些具体任务，但真正的业务场景需要多角色协作——正如人类团队中有受理、复核、审批等岗位，Agent 也需要明确的分工、协调机制和权限边界。

本系列从第 0 期开始，围绕一个信用审批案例（CASE-CR-0042）逐步构建了一套完整的企业智能体治理体系。本文作为终章，聚焦在当多个 Agent 组成一个“职场”时，如何通过权限矩阵保证流程安全、可控。

二、案例回顾：三角色审批链

案例场景为：用户申请提额，系统需经过 受理（intake）→ 数据查询（credit）→ 财务裁决（limit） 三个环节。我们为此设计了三个专职 Agent：

角色	主职	禁止
support.intake	受理用户请求，初步澄清，转交	修改额度、篡改原始信用数据
data.credit	查询并生成信用报告快照	做出提额裁决
finance.limit	基于规则做出提额决策	直接修改原始信用数据

这种“只做契约内工作”的约束，是 Agent 组织设计的第一原则。

三、协调机制：推理不盲从，冲突显式化

多个 Agent 之间不是简单的链式传递，还需要协调：

• 上游输出可读，但下游不盲从：data.credit 可以读取 support.intake 的工单，但不会直接采信其结论。
• 核心动作受四轴约束：任何涉及资金的决策（如提额）必须过 P1 轴（合规与权限），并在决策记录中显式外化。
• 冲突进入人工队列：当 Agent 之间判断不一致时，不自动覆盖，而是标记并提交人工处理。

这保证了组织具有“会转发、会拒绝”的能力，而非机械的流水线。

四、PermissionMatrix：权限矩阵设计

传统的 RBAC 可以解决人类权限问题，但对于 Agent，我们需要更细粒度的资源域级权限矩阵。定义三个资源域：case（工单）、credit_data（信用数据）、limit（额度）。权限级别分为：Y（可读写）、R（只读）、N（无权限）。

矩阵如下：

角色 ↓ / 资源域 →	case	credit_data	limit
support.intake	Y	R	N
data.credit	R	Y	N
finance.limit	R	R	Y

• support.intake 可以读写工单，读取信用数据，但绝无可能触碰额度决策。
• data.credit 专注数据，无权裁决。
• finance.limit 拥有裁决权，但不能直接篡改原始数据，必须通过只读方式获取快照。

这种矩阵式设计，从代码层面彻底堵死了“越权操作”。

五、全链路组织流程

将权限矩阵融入审批流程，得到如下全链路（虚线表示被矩阵拒绝的动作）：

组织的真正能力体现在：不仅会按路径转发，更会在路径之外果断拒绝。

六、最小可运行代码实现

下面给出一个极简但完整可运行的 Python 实现，核心只有 矩阵 + 判定 + 交接 三部分。

from __future__ import annotations
from dataclasses import dataclass

# 权限矩阵：行=角色, 列=资源域
MATRIX: dict[str, dict[str, str]] = {
    "support.intake": {"case": "Y", "credit_data": "R", "limit": "N"},
    "data.credit":   {"case": "R", "credit_data": "Y", "limit": "N"},
    "finance.limit": {"case": "R", "credit_data": "R", "limit": "Y"},
}

@dataclass
class Action:
    role: str
    resource: str
    mode: str          # "read" 或 "write"
    case_id: str = "CASE-CR-0042"

def allow(a: Action) -> bool:
    perm = MATRIX.get(a.role, {}).get(a.resource, "N")
    if a.mode == "read":
        return perm in {"Y", "R"}
    if a.mode == "write":
        return perm == "Y"
    return False

def handoff(case_id: str, frm: str, to: str) -> str:
    return f"{case_id}: {frm} → {to}"

if __name__ == "__main__":
    # 模拟正常流程
    steps = [
        Action("support.intake", "case", "write"),       # ✓
        Action("data.credit", "credit_data", "read"),    # ✓
        Action("finance.limit", "limit", "write"),       # ✓
        Action("support.intake", "limit", "write"),      # ✗ DENY
        Action("data.credit", "limit", "write"),         # ✗ DENY
    ]
    for s in steps:
        print(f"{s.role} {s.resource} {s.mode} -> {'OK' if allow(s) else 'DENY'}")

    print(handoff("CASE-CR-0042", "support.intake", "data.credit"))
    print(handoff("CASE-CR-0042", "data.credit", "finance.limit"))

运行结果：

support.intake case write -> OK
data.credit credit_data read -> OK
finance.limit limit write -> OK
support.intake limit write -> DENY
data.credit limit write -> DENY
CASE-CR-0042: support.intake → data.credit
CASE-CR-0042: data.credit → finance.limit

越权操作被矩阵直接拦截，实现了代码级的“最小权限原则”。

七、组织漂移与持续治理

组织不是一成不变的，当企业引入新 Agent 或调整权限时，必须遵循既定的治理协议（这些协议在本系列前 8 期中已建立）：

• 新增 Agent：走第 8 期 Assurance 放行流程，分配角色并初始化权限行，全部默认为 N，逐步按需开放。
• 矩阵调权：变更需记录到审计日志，并与第 2 期的 P2（对账轴） 联动，确保权责一致。
• 路由规则变更：属于第 5 期的 P3 飞轮 范畴，需验证回流路径是否被破坏。
• 结构腐化：当组织层级混乱时，触发第 6 期的 P5 重写 协议。
• 生产阻断：紧急情况下，第 4 期的 P4 应急窗 允许临时关闭某些约束轴，但不能以“组织紧急”为由永久绕过 P1（合规轴）。

整个系列通过 P1~P5 五个治理协议，为 Agent 组织提供了从设计、运行到演进的完整保障。

八、全系列回顾

期号	对象/协议	核心贡献
0	Identity · 档案 · 架构	开场红线，明确各角色身份
1	SkillContract · P2	定义技能边界与对账机制
2	四轴 · P1	合规、对账、飞轮、应急四轴决策
3	DecisionBoard	实现推理透明与冲突外显
4	ToolSpec	标准化快照、提额提议等工具
5	Flywheel · P3	误路由自动回流纠正
6	重写 · P5	大规模组织重构规则
7	MemoryItem	记忆片段管理与拦截规则
8	Assurance · P4	Agent 上线前的安全放行
9	PermissionMatrix	全链路拒绝能力与权限矩阵

九、终卷思考题

1. 若新增一个「反欺诈 Agent」，它需要读取信用数据和工单，但禁止直接修改额度。该角色在矩阵中应新增一行，权限为 case: R, credit_data: R, limit: N——你会把哪个资源列先设为 N？
2. 组织内谁拥有一票否决的 Assurance 权力？是平台管理员、风险合规部门，还是业务方？答案往往是风险合规，但在代码中需要明确的委派逻辑。

十、延伸阅读与参考文献

• Four-Axis Decision Alignment for Multi-Agent Governance (arXiv:2604.19457)
• Adaptive Data Flywheel in Enterprise Agent Systems (arXiv:2510.27051)
• Strategy-Following Multi-Agent DRL with Organizational Constraints (arXiv:2607.18719)
• 系列修订说明：v1.1_修订提纲.md

---

版权声明：本文为「企业智能体工程卷」系列终章，由技术治理研究组原创，欢迎注明出处转载。文中案例及代码均为抽象模型，不涉及任何真实生产数据。

2026-08-12 | 发布