从 Agent 授权到职责的数字孪生

企业想做一个采购 Agent，让它从提出采购建议进一步走到自主下单。到了这一步，应该给它什么权限？

“允许创建采购单”并不能回答这个问题。起草待审批的单据与向供应商发出正式订单，意味着不同的业务承诺。我们可能只希望它在指定品类和预算额度内下单，超出范围再交给人决定，但这些边界无法仅靠增删查改表达。

当授权停留在工具开关和数据读写层面时，把 Agent 放在沙箱或草稿区，后续工作仍需人接手；开放工具，又需要额外规则和人工确认约束它。我们想交出去的是一份有边界的工作，系统要求配置的却是一组操作权限。

Agent 授权的困难，让组织分工与系统权限之间原本就存在的断层变得明显。

组织中的分工，目前主要体现在部门职责、岗位说明书和授权制度中。要理解业务权责与系统权限之间的关系，应该回到这类文档。

一 拆解职能说明，重看权、责、限的本质

先看一段典型的采购岗位说明：

负责指定品类的采购，组织供应商询价与评估，在授权额度内确定采购方案，跟踪订单交付，及时上报交付异常，保障采购信息准确、进展可追踪；超出额度的事项报采购负责人审批。

这段话已经包含了对象、职责、权力及其边界：

其中，“责”说明持续承担什么工作、对什么结果负责；“权”说明可以作出什么决定、实施什么行动；“限”说明这些权力在什么对象范围和条件下成立。职责把工作义务与结果责任组织在一起，谁来承担则由具体的分工安排确定。

这段说明已经区分了开展询价与决定方案。如果再沿着组织分工往外看，还会遇到另外两类工作：谁制定采购制度与授权额度，谁检查采购是否遵守这些规定。它们与当前岗位的工作相连，共同构成采购活动的权责安排。

把这些已有的业务权责按性质展开，就可以归纳为治理权、支配权、执行权和监督权：

沿着一笔合同延期来看，这四种权力就容易理解了。

供应商反馈无法按时交货。负责跟进的人核实情况、登记事实、分析影响，属于具体工作的执行。是否接受新的交付安排，由具备相应支配权的主体决定。这个决定需要遵循现有的变更程序；谁可以修改程序、调整审批额度，则是治理层面的问题。后续检查这次变更是否依规处理、证据是否完整，又涉及监督。

这里的区别来自业务行为的意义。修改规则、决定例外、记录事实，都可能通过一个“编辑”按钮完成；从按钮名称或数据库更新动作，看不出它们之间的权力差异。

“新增”也一样。新增一条履约记录，是记录业务事实；制定并发布一项新规则，则会改变后续工作的约束。新增对象实例与定义适用规则，不能因为都产生一条新记录就归为同一种权力。

四权由此帮助我们把宽泛的“管理”拆成可以分别授权的内容。具体落地时，仍应说清合同变更决定权、履约跟进执行权等实际业务权限。一个主体可以兼有多种权力，需要分离的事项也可以由不同主体承担。

责任则与这些权力相互对应：跟进人员对信息及时、记录准确和异常上报负责，决定者对其决定承担相应责任，监督者对约定的监督工作负责。谁承担整体履约结果责任，还需要组织明确。不能仅凭谁最后点击了按钮，就把全部责任归给谁。

二 从职责文本到系统配置，断层在哪里

岗位说明中包含了权责结构，并不意味着这些结构已经足够明确。上面的示例写了“指定品类”和“授权额度”，但具体覆盖哪些对象、额度如何适用，仍需其他安排补充。现实中的说明往往更笼统，一句“负责采购管理”就可能涵盖多种工作。

首先是对象范围。同样是采购，生产物料和设备可能由不同团队负责；即使都采购生产物料，也可能按品类或项目继续划分。这些边界未必写在岗位说明里，可能依靠日常分配和组织惯例维持。

其次是同一对象上的分工。同一份合同，采购跟进交付、技术负责验收，双方都可以被写成“负责合同履行”，却不一定写清各自能决定什么、出了异常由谁接手。职责名称相同，并不代表工作和权力相同。

文档里没有展开的边界，配置时却必须作出选择：生产物料和设备采购可能使用不同表单，也可能在同一流程中按品类走向不同的审批分支；同一份合同上的交付跟进与技术验收，则可能分属不同任务、操作权限和消息接收规则。

这也是为什么实施工作通常需要通过访谈、流程走查和具体案例来理解分工，仅靠研读部门职责和岗位说明书，很难直接完成配置。这些文件表达了职责的大体安排，却往往没有写到系统所需的颗粒度：哪类事项走哪个分支、谁能修改哪些内容、异常交给谁处理，都需要在调研中补齐。

但这些补齐工作，本质上已经是在定义业务模型：哪些对象需要区分，谁对它们负责，哪些行为需要什么授权，以及这些关系如何进入系统。这正是《业务建模，本质是定义业务如何被表征》讨论的工作。

业务模型的定义，在这里被降级成了系统实施中的配置工作。 它的交付标准往往变成“这套系统能跑起来”，而对象、分工和规则的定义则隐含在表单与流程中，缺少独立的确认、维护和复用。于是，组织对自身运行方式的理解，最终散落在各个系统及实施人员的经验里。

业务权责由此进入系统：角色与增删改查权限表达其中一部分，表单、数据范围、消息通知和审核审批又各自承载了其他部分：

同一项“负责华东区域服务合同履约”的分工，需要在角色、合同范围、消息接收和审批路径中多次表达。各处分别维护，就可能出现有任务无权限、能操作却收不到异常通知，或者审批仍然流向原负责人的情况。

RBAC 的原子是权限，业务分工的原子是职责。

三 对什么对象负什么责，就需要相应的权

要把业务权责落到系统里，需要先说清：一个主体对哪些对象、哪些结果负责，为此可以作出什么决定、实施什么行动，再确定系统应当提供哪些权限。同样是维修工单，负责调度、实际维修和监督质量的人，虽然都需要访问工单，承担的责任和可采取的行动却不同。

这里，派单决定的是“由谁处理这张工单”，属于支配；维修人员点击“开始维修”、填写处理记录，则是在执行。两者在数据库里都可能只是修改字段，但对应的业务权力不同。监督需要读取和消息接收能力，以便及时发现问题；这些能力应当随监督职责配置，而不能只看谁参与了处理流程。

治理权的落点更容易被忽略。谁决定工单有哪些状态、什么条件允许关闭、哪类异常必须升级，实际上就在定义业务运行规则。这些规则可能分散在配置、校验逻辑和代码中，没有一个名为“治理权”的系统权限。业务上由谁确认规则、技术上由谁修改实现，也需要分别明确。

支配权通常对应系统里的管理权限，管理看板和对象的新增、删除等操作，常被一起放进“管理员”角色。但具体操作仍需按业务含义拆开：取消一项维修安排，是处置业务事项；删除一条重复工单，是维护系统记录；创建工单，也可能来自不同的履责需要。

四 权限如何随职责关系产生和变化

以创建维修工单为例，设备使用者发现异常后报修，与工程师巡检发现问题后报修，都需要创建维修工单。前者来自设备使用中的异常反馈职责，需要准确描述现象；后者来自巡检的问题发现与处置职责，需要记录检查发现和专业判断。操作相同，权限的职责依据、需要提供的信息和后续义务却可以不同。同一个业务操作，可以由不同职责赋予权限。

维修完成后的使用确认，也可以沿着职责关系找到相应的人。这里的“验收”是确认设备是否恢复可用的业务动作，背后承接的是设备使用职责，不必固定由原报修人完成。如果已经交接班，接班人承接了这台设备的使用职责及相应权限，就可以依据维修记录和实际使用情况作出确认。

新增权限很多时候还隐含着对系统数据一致性的责任。 创建记录时，需要判断对象是否已经存在、是否应当新建、应关联哪台设备，以及是否与已有工单冲突。允许把数据写进去，只解决了操作入口；谁负责维护这些记录与真实业务的一致性，还需要有明确的职责承接。

传统企业的职责安排往往覆盖了“谁负责维修”，却没有同样明确地安排“谁维护维修业务在系统中的准确表达”。这部分工作容易落在录入人员、实施人员或 IT 身上，成为附带工作。于是，新增、编辑和删除权限虽然已经分配，数据一致性的责任却仍然空缺。

《设计 Agent 之前，先弄清任务从哪里来》讨论了职责如何形成具体任务。权限也需要沿着同一条关系落实：对哪些对象负什么责，为此拥有哪些权力，最终对应哪些操作、数据范围和消息。人和 Agent 都需要这套对应关系。

五 职责数字孪生是值得期待的未来

理想情况下，组织在部门职责、岗位说明书和授权制度中表达的分工，应当与系统中的权限、消息和流程形成可追溯的对应。职责的数字孪生，就是让“谁对哪些对象承担什么职责，依据什么行使哪些权力”，在系统中拥有可检查、可更新的表达。

这至少需要通过两项检验。首先是双向可追溯：从一项职责能找到对应的操作权限、数据范围、消息和审批；从一项配置，也能回到它支持的职责及授权依据。前者用于发现履责所需的支持是否缺失，后者用于检查是否存在失去业务依据的权限或配置。

其次是变更后仍然一致：发生交接、调岗或职责范围调整时，相关权限、消息接收和审批人能否依规则同步更新，并保留历史记录。前面的交接班例子，就是一个具体检验：接班人能否取得使用确认权限，交班人原有权限是否按有效期和保留规则正确处理。

理想情况距离现有企业的实际运行仍然很远。

对管理层而言，制度中写的分工与系统实际允许的行为可能已经偏离，却很难从组织架构图或权限表中看出来。实施文档、配置记录和相关人员的经验承担着连接两者的工作，但缺少持续核对的共同结构。

人员和分工每变一次，就要逐项排查多个系统的配置；条件与例外不断累积，便形成了《系统实施为什么变成了配置地狱》所讨论的维护困境。

但把这些配置统一映射到职责，也远不只是整理权限。沿着对象和工作去核对现有岗位、部门分工，会发现原有组织安排本身就有重叠与空缺：几个岗位都写着“负责合同管理”，却没有区分各自负责的部分；每个人都完成了自己的步骤，却无人承接异常处理；有人承担结果责任，却没有相应决定权限。部分重叠是必要协作，部分空缺可能由非正式安排补上，仍需要结合实际业务辨认。

因此，这个 gap 同时存在于组织分工、职责文本和系统实现之间。把它显式化，有助于发现问题，也意味着需要业务管理者参与确认和协调，无法仅靠实施或 IT 团队改配置完成。

实际落地时，未必适合立即按这套理想结构全面改造。可以先把它作为分析思路，在一类对象或一项职责上，核对现有分工与权限、消息、审批之间的对应，优先处理已经影响工作的错位。更大范围的职责澄清和系统联动，则随组织条件与实际收益逐步推进。

这也呼应了《企业 AI 落地为什么必须从业务开始：业务 → 组织 → 系统 → Agent》中的判断：可以从局部切入，但不能跳过这个局部里的业务定义、组织分工和系统承载。放到权责问题上，就是先说清一项工作涉及哪些对象、由谁负责、谁能决定什么，再检查系统权限是否与之相符。无需等待全企业完成重构，也不能指望新增一套权限配置，就替组织回答这些问题。

Agent 今天没有职位说明书，但未来需要能被执行的职位说明书。 对采购 Agent 而言，这意味着明确它对哪些对象承担什么职责、可以决定什么、何时交给谁处理。多个 Agent 协同时，也需要依据同一套关系分配工作、传递信息、交接职责，并确认结果由谁负责。让人和 Agent 的职责、权力与系统权限形成可追溯、可随分工更新的对应，正是 Agent 权限设计与多 Agent 协同所需要的基础设施。