当 Agent 成为同事：企业融合通讯的四象限治理

副标题：从 P2P 分享、委托、A2A、P2A、A2P 五个场景，看人机协同的责任链怎么设计、怎么落地、怎么不出事 日期：2026-09-10 ｜ 性质：理论指导文章（以 OODER 平台已落地实现为工程证据） 读者：正在把 Agent 引入企业、并已经开始被"人和 Agent 怎么配合"困扰的架构师与产品负责人

摘要

企业引入 Agent 的真正瓶颈，从来不是"单个 Agent 有多聪明"，而是多个参与者（员工、Agent、外部系统）如何通讯与协同。

这篇文章不谈模型能力，只谈一个被严重低估的工程问题：当一个 Agent 开始和普通员工坐在"同一个聊天框"里工作时，这个聊天框到底应该怎么管？

我们把问题拆成五个必须回答的场景：

贯穿这五个场景的是一条主线：每一次通讯，本质上都是一次责任移交；每一次责任移交，都必须同时完成三件事——上下文传递、权限校验、问责记录。

文章最后用一个真实场景收尾：财务 Agent 处理报销付款。你会看到这五个场景如何在一条业务线上依次发生，以及哪些设计让这条线在生产里活了下来、哪些还差得远。

一、先讲清楚问题：Agent 进企业，第一个卡点是"通讯管理"

1.1 一个常见的失败模式

很多企业引入 Agent 的路径是这样的：先做一个"很聪明"的助手，接上大模型，让它能查数据、能写文档、能调接口。演示效果惊艳。然后——

• 员工 A 用 Agent 生成了一份对账结果，发给主管 B 复核。B 问："这些数字是哪来的？你让它剔除了哪些单？"A 答不上来，因为聊天记录里只有结果，没有过程。
• 财务要求"超过 5 万的付款必须人工确认"。Agent 确实弹了个确认框，但确认框上写着什么、谁点的、点了之后流程走了哪条分支，事后查不到。
• Agent 之间开始协作：一个负责识别票据、一个负责校验、一个负责生成凭证。出问题了要追责，结果发现 Agent 之间只传了一句话，没有上下文、没有单据引用、没有存证。

这三个坑，对应的正是可追溯性、责任归属、上下文完整性。它们都不是模型能力问题，而是通讯治理问题。

1.2 三重鸿沟

语义鸿沟：Agent A 说的"客户"和 Agent B 说的"客户"是同一个吗？上下文怎么传——全传（安全与性能风险）还是不传（责任悬空）？

信任鸿沟：这次操作是谁授权的？身份怎么确立？一个 Agent 能不能替另一个 Agent 承诺？越权怎么阻断？

时间鸿沟：Agent 毫秒级完成，人可能要三天后才看。这中间状态存在哪？怎么恢复？人回来时还能不能接上当时的上下文？

1.3 为什么"聊天框"是主战场

答案很朴素：员工不会为了用 Agent 去学一套新系统。他们已经在钉钉、企微、各种工作台里聊天了。Agent 要进入员工的工作流，最自然的形态就是"进到那个聊天框里"。

但这意味着聊天框要承担三倍的责任：

1. 交互界面——人看得懂、点得动；
2. 执行记录——不只是聊了什么，还包括 Agent 调了什么工具、花了多久、产出了什么；
3. 责任留痕——谁在什么时候、基于什么、把责任交给了谁。

一句话：聊天框不是 UI，它是人机协同的记录面（record surface）。 后面所有设计分歧，都可以用这句话来裁决。

二、理论骨架：协同四象限与 CAA 三元组

2.1 四象限

关键在于：这不是一个平面分类，而是一条责任梯度——

P2P（人全程持有） → P2A（人发起、机器执行） → A2P（机器产出、人裁决） → A2A（机器自闭环）

一个真实的业务过程会反复穿越全部四个象限。以报销为例：

1. 员工提交报销单 → P2A（委派 Agent 解析票据）
2. Agent 发现金额异常 → A2P（回来请求人工确认）
3. 经理审批 → P2P（责任在人之间流转）
4. 审批通过，自动记账 → A2A

2.2 CAA 三元组：一次移交 = 三件事

每一次象限跃迁都是一次责任移交。只有以下三者同时成立，移交才有效：

三者合称 CAA 三元组。它是本文的判断标准：后面每一个场景，我们都会用 CAA 去检视它的设计是否成立。

图 1：四象限不是分类法，而是责任梯度；CAA 是每一次跃迁的验收条件。

2.3 三条从工程里长出来的原则

原则一：责任在"行"上，不在"字段"上。

单据的办理权不落在流程状态字段上，而落在独立的权限行上（谁在办、以什么身份办、办到哪一步、回退锚点在哪）。于是"退回""撤回"不是改一个状态值，而是重建权限行——这就是为什么财务"冲正"、合同"收回"、单据"驳回重报"能统一落地。

原则二：HUMAN 是协同模型的一等参与者，不是引擎里的特殊节点。

"暂停下来等人"这件事，应该由业务层解释并驱动，而不是依赖某个流程引擎的私有能力。判断标准很朴素——一个系统只要能回答"这份单据当前停在哪个状态、由谁持有"，四象限模型就能投影上去。

原则三：凡是钱、合同、对外承诺，默认必须停在人工确认点。

自动通过只能在流程配置里被显式声明。任何"超时自动放行""强度参数调节"都不得越过这条边界。理由很朴素：让一个本该把关的人失去把关机会，比流程慢几小时严重得多。

三、五个场景：设计与落地

下面逐场景展开。每个场景给出：设计要点 → CAA 检验 → 实践中的坑。

3.1 P2P 分享：把"会话"变成可共享的工作现场

#### 业务问题 财务小张用 Agent 做完一笔对账，需要主管老李复核。把结果截图发过去？老李看不到过程、看不到 Agent 剔除了哪些单；把账号给老李？权责不清。

#### 设计：会话级分享 + 双角色

#### CAA 检验

• C：被分享人看到的是完整历史（含 Agent 推理、工具调用、产出物），不是一张截图——上下文充分；
• A：角色由服务端下发，操作菜单按 availableOperations 白名单渲染（无权限不渲染，而不是渲染了点不动）；
• A：参与者集合变更进 im_conversation_participant，并作为事件广播，接收方弹出协作邀请（可接受/稍后/拒绝）——移交这件事本身被记录。

#### 坑：分享不是"转发" 一个常见错误是把分享做成"把这条消息转发给某人"。这在 CAA 上是破产的——接收方拿到的是结论，丢掉的是依据。正确做法是分享会话引用：对方打开后看到的是同一个工作现场。

实践教训：只读态必须由服务端兜底。前端禁用输入框只是体验优化，绕过前端直接调接口仍然能写——所以服务端必须有独立的写权限断言。

3.2 委托：责任移交而不失联

#### 业务问题 老李休假前，把待办转给小王。关键要求是：小王办完之后，任何人翻记录都能看出"这件事本是老李的，小王是代办的"。

#### 设计：两层委托，语义完全不同

活动级委托的核心工程动作：不是改一个 assignee 字段，而是重建办理人权限行。这保证了：

• 原办理人的痕迹仍在（历史办理人行）；
• 退回归属可恢复（回退锚点）；
• 受托人的发言在聊天框里带「代 {owner}」角标——责任可见。

#### CAA 检验

• C：受托人获得该活动的完整上下文（单据 + 会话历史）；
• A：委托权限由服务端计算并下发（availableOperations 含 DELEGATE 才渲染按钮）；
• A：委托登记进委托表 + 事件广播 + 邀请通知，且受托人的每条消息都带"代谁"署名。

#### 坑：委托最容易"三处断链"（真实修复案例）

我们在实现委托时踩过一组非常典型的坑，值得作为反面教材：

1. 前端丢参：面板收集了用户选择的受托人，但派发请求时没把它塞进请求体——用户的选择根本没出浏览器；
2. 判定无视选择：后端方法签名里有 params 参数，但完全不读取——"谁被委托"这个用户决策没进入任何判定；
3. 执行取错源：路由目标取自设计器预置的配置，而非用户选择——委托退化成"按配置跳转"。

三个环节单独看都能跑（不报错），串起来就是"用户选了 A，实际委托给了 B"。这类 bug 的隐蔽性在于：每一环都在做事，只是没做对的那件。

由此沉淀出一条闭环鉴定法——对任一交互属性，按五环逐个追问，全部"是"才算闭环：

1. 定义 → 展示：配置是否被装配器发出？
2. 展示 → 行为：是否被渲染函数读取并影响交互？
3. 行为 → 接收：用户产生的数据是否进入请求体？
4. 接收 → 判定：接收端点是否读取并据此分支？
5. 判定 → 执行：结果是否被消费并产生可观测回流？

对应地，断链有四种典型形态，可以用来自查：

最后一条尤其值得警惕："委托给 Agent"在我们的实现里一度是个半环——面板能选、请求能发、标记能写，但没有任何真正的 Agent 派发调用。这在演示时看不出来，在生产里就是"点了委托，什么也没发生"。

图 2：闭环鉴定的六环与断链四形态；右下的 H2A 案例即本文 §3.2 的真实修复。

3.3 P2A 指令：员工怎么"选择 Agent"

#### 业务问题 出纳想让 Agent 处理报销付款。她需要选一个"懂报销付款"的 Agent，而不是一个通用聊天机器人。

#### 现实：不是 @agent，而是"选模式 + 选场景"

一个反直觉的发现：在企业里，"@某个人/Agent"这种提及式选择，并不是员工选 Agent 的主路径。 真正可用的是：

工作模式（workMode）：chat（知识问答）/ architect（设计构建）/ business（业务编排）
        ↓
场景（Scene）：每个模式下挂一批业务场景 —— 而"场景"就是 Agent

也就是说，"选场景"即"选 Agent"。业务编排模式下，出纳看到的是一串业务场景：开票回款对账、报销付款导出、银行流水转换、往来挂账、税负分析、凭证填列……选一个，等于把这个领域的 Agent（含它的提示词规则、工具集、业务口径）唤起来。

为什么这样更好？因为企业员工是按"业务"思考的，不是按"Agent 人格"思考的。她不知道也不关心背后是"识别 Agent"还是"校验 Agent"，她只知道"我要做报销付款导出"。

#### 执行者选择的四要素

一旦选定，系统要确定四件事，缺一不可：

#### CAA 检验

• C：场景切换时，上下文（会话历史、票据、台账引用）必须随身带过去；
• A：该员工是否有权使用这个场景（不是所有场景对所有人开放）；
• A："选了哪个 Agent、为什么"必须作为一次可审计操作被记录。

最后一条常被忽略。如果"选了谁"不留痕，责任链里就有一个沉默环节：事后只知道"Agent 干了这件事"，不知道"是谁让它干的"。

3.4 A2P 请求：Agent 回来找人签字（最成熟的一象限）

这是目前落地最完整的象限，也是企业场景里价值最高的一环。

#### 生命周期五环

① 定义   → 流程设计器配置 HUMAN 节点（模式/办理人/表单/路由/权限/时限）
② 展示   → 推送 human_confirm 事件 + 流程暂停事件 → 前端渲染确认卡/表单/审批面板
③ 行为   → 用户点击 → 三条通道：人工操作端点 / 确认端点 / 文件直传
④ 判定   → 端点校验 → 归一化动作 → 写上下文标记
⑤ 执行   → 路由引擎消费标记 → 恢复执行 → 流程步进事件回流（可观测）

每一环都必须有消费方。 "定义必须有展示消费者；行为必须有接收端点；端点必须有判定逻辑；判定结果必须有执行消费者；执行必须有可观测结果。"——任一环"只写不读"即为断链。

#### 五类确认卡 + 三专用面板

Agent 找人，不是只会问"是/否"。交互类型收敛为五种，覆盖绝大多数场景：

其中文件上传是独立通道（直传存储，不经委托处理器），这是为了避免"上传完成"与"确认提交"的竞态——这是真实踩过的坑。

#### 三条硬约束

1. 操作集服务端权威：操作栏上的按钮由服务端计算下发，客户端没有默认值。这条约束解决了"按钮能点、点了没反应"和"我明明批过了"两类致命体验问题。
2. 强制人工护栏：必须人工处理的请求渲染为置顶、无关闭按钮的横幅；处理完自动失效（绑定活动 ID，步骤非暂停即清除）。
3. 超时兜底双保险：前端强制 + 后端超时策略（自动接受或升级人工）。"该确认的人不在"不能让整条链卡死。

#### CAA 检验

• C：确认卡必须携带足够的决策信息——不只是"是否通过"，而是"这些数、这些单、按这个口径"；
• A：availableOperations 与 operationPermissions 由服务端计算，无权限不渲染；
• A：人的每一次决策（审批意见、委托理由、路由选择）一并进入会话记录——事后翻聊天记录就能还原责任链。

这是 A2P 最容易被低估的一点：人的决策要写回会话，而不是只写进流程库。 因为事后追溯时，人只会去翻聊天记录。

3.5 A2A 直接消息：为什么"能发消息"≠"能协同"

这是五个场景里最不成熟的一个，也是最有教育价值的一个——因为它最容易做出"看起来能用"的假象。

#### 现状：能发，能回，但什么都留不下

典型实现：Agent A 发一条组播消息，Agent B 收到后回一条回执，发起方把回执聚合成一条消息显示在聊天框里——

【A2A 聚合 · 对账Agent · TASK_RESPONSE】已收到任务，正在处理……（内容截断 300 字）

看起来很完整，实际上在 CAA 上是全面失守：

#### 正确的目标形态：委托 = 凭契约在远端起一个流程

A2A 不应该"发一句话"，而应该"凭一份可持久、可回放的单据，远程启动一个流程"。这份契约有四个要素：

#### 对聊天框的要求（用户特别关心的那一条）

"Agent 之间发了什么，聊天框必须能完整还原。" 具体要求：

1. 不留私有气泡：A2A 交互应作为时间线/列表中的标准条目出现（如"委托子流程 · 已由 X 节点接管 · 状态 Y"），而不是一句截断的聚合文本；
2. 可下钻：点开能看到完整请求/响应、上下文引用、执行步骤、耗时；
3. 可回放：凭契约文件在断线/重启后重放未完成的委托；
4. 可归属：条目上写明发起方、接收方、所属流程、操作人。

判断标准很简单：如果 Agent 之间的对话只能看到"一句话总结"，那它就不叫被记录，只叫被通知。

四、财务 Agent 实践：一条业务线上的四象限

理论讲完，看真实场景。财务是检验融合通讯最好的试金石——因为它同时具备：强合规（必须留痕）、强协同（多角色）、强外部依赖（单据来自别的系统）、零容错（钱不能错）。

4.1 场景概览

财务域有六个业务场景（对 Agent 而言，每个场景就是一个"领域 Agent"）：

4.2 完整走一遍：报销付款导出

图 3：一条业务线上的四象限穿越（P2A → 执行 → A2P 红线 → P2P），以及贯穿全线的"记录面"。

第 1 步 · P2A：出纳选场景、下指令

出纳进入业务编排模式，选「报销付款导出」场景，说："导入昨天的待支付报销单，生成付款模板。"

• 这一步完成了责任从人到机器的移交（CAA：上下文=会话历史+日期；权限=该员工可用此场景；记录="谁在何时选了哪个场景"入账）；
• Agent 通过费控接口拉取单据，本地按报销/借款/付款/申请分类，幂等落库留档。

第 2 步 · A2P：Agent 停下来找人确认

Agent 不会自作主张生成付款文件。它停下来，推一张确认卡：

• 文件上传型："请上传/确认本次导出的银行模板"（FILE_UPLOAD）；
• 或选择型："本次共 N 笔，其中 M 笔超出常规时限，如何处理？"（CHOICE，附后续动作选项）。

关键设计：确认卡上必须带决策所需的全部信息——不是"是否继续"，而是"这些单、这些金额、按这个口径"。

第 3 步 · A2P 判定与执行

出纳确认 → 动作归一化 → 路由引擎消费标记 → 恢复执行 → 生成 15 列银行批量付款模板 → 流程步进事件回流聊天框（可观测）。

这一步人的决策（选了什么、批了什么）写回会话记录，而不是只进流程库——因为三个月后审计来查，人只会翻聊天记录。

第 4 步 · A2P 再次出现：业务红线

如果某笔金额超过阈值，或触发了"对外承诺"性质，默认必须停在人工确认点。这是硬规则，不由模型"觉得可以"来决定。

第 5 步 · P2P：复核与委托

出纳把会话分享给复核会计（member，可看全部历史与过程）；或者，如果出纳要休假，把待办委托给同事——对方办理时，聊天框里每条消息都带「代 {出纳}」角标。

第 6 步 · A2A：这一环目前是缺失的

理想中的多 Agent 协作是：识别 Agent（读单据）→ 校验 Agent（对规则）→ 生成 Agent（出模板）分工并互相通信。

现实是：财务场景内部是单场景内的确定性工具链（解析 → 按业务口径筛选 → 映射 → 写台账/模板），加上 LLM 做审计，全部在同一进程内顺序执行。这有它的合理性——财务要的是确定性，不是 Agent 的自由度——但也意味着 A2A 的治理能力在财务域尚未被验证。

4.3 业务口径：为什么"剔除哪些单"必须可见

财务的场景里有一个细节，特别能说明"记录面"的价值——筛选口径：

• 只取"审批结果=通过"且"审批状态=已结束"的单；
• 剔除特定类别（如分公司开票不入表）；
• 剔除终止/审批中的单、剔除负值；
• 映射到台账的固定列；
• 写入台账副本时保留原格式与公式（更新统计区间）。

这些规则如果只在代码里，业务同事复核时就会问："为什么这笔没进来？"——Agent 必须能回答，且答案必须在聊天框里。

所以我们在财务场景里做了一件重要的事：把落库的真实台账数据注入审计上下文，强制 Agent 的"财务专家审计"基于具体数值展开，而不是基于它自己想象的数字。这是"上下文传递"（C）在 A2P 场景下的具体落地。

4.4 财务实践的三条结论

1. A2P（人工闸门）+ P2A（选场景即选 Agent）+ 外部系统取数，这三者构成了财务 Agent 的价值闭环，并且已经在生产里跑通；
2. P2P 分享与委托是"通用能力"的直接复用——没有为财务写任何专用分享/委托逻辑，这恰恰说明四象限模型的抽象是成功的；
3. A2A 在财务域尚未落地，也未必是当下最紧迫的——但它一旦落地，就必须满足"记录完整交互与执行信息"的要求，否则财务这种零容错场景根本不敢用。

五、一份可以直接拿去用的检查清单

5.1 闭环鉴定五问（对任一交互特性）

1. 定义是否被装配器发出？（定义→展示）
2. 是否被渲染函数读取并影响交互？（展示→行为）
3. 用户产生的数据是否进入请求体？（行为→接收）
4. 接收端点是否读取并据此分支？（接收→判定）
5. 判定结果是否被消费并产生可观测回流？（判定→执行）

5.2 上线前四问

1. 四个切片对得上吗——本地入口（单从哪发起）、流程定义（按哪套规则）、远端状态（现在停在谁的待办）、会话留痕（沟通过程可查）。随时能回答"这份单现在什么状态"。
2. 界面能点的，后台都有真实现吗——不存在"按钮能点、点了没下文"的假能力。
3. 用户看到的操作 = 他有权限的操作吗——操作条由服务端权限计算下发，无权限不渲染。
4. 服务重启丢单吗——委托、退回、跨实例委派在重启后都能从记录恢复。

5.3 四个雷区

5.4 部署前必须回答的六个业务问题

1. 跨部门单据，谁有权看、谁有权办？（权限落在"单"上，不落在"页面"上）
2. 超出授权额度的单，如何分级？（额度边界写进流程定义，不靠人自觉）
3. 该确认的人不在（休假/出差/离职）怎么办？（可转派、可委托、超时升级）
4. 单据跨系统、断网、重启后还能接着办吗？（持久契约 + 回放）
5. 出了事找谁？（操作人、动作、对象、载荷全记录）
6. Agent 的自动动作会越权吗？（自动放行边界只能由业务显式配置）

六、结语：四象限是一套纪律，不是一套分类法

回到开头那个问题：企业 Agent 建设中，怎么管理 Agent 与普通员工的融合通讯？

答案不在某个协议里，也不在某个框架里。答案是一套可以逐条检查的纪律：

每当你要为 Agent 加一个新能力，先问自己两个问题： 一、这落在哪一次象限跃迁上？ 二、它完成 CAA 三元组了吗——上下文传了、权限验了、问责记了？

如果两个答案都是肯定的，它就能在生产里活下来；如果不是，它就会成为责任链上下一个缺失的沉默环节——平时看不出来，出事时查不到。

最后一个提醒：不要被"A2A 很酷"带偏。 从我们的实践看，企业里最先产生价值、也最该做扎实的，是 A2P（Agent 回来找人） 和 P2A（人把活交给 Agent） 这一来一回。把人工闸门做严、把选择留痕做全、把执行过程记清楚，比让两个 Agent 互相发消息重要得多。

等这些做扎实了，A2A 才有意义——因为到那时，Agent 之间的每一次对话，才终于有一个说得清楚的责任归属。

七、实测证据：这些设计在真实系统里长什么样

下文截图全部取自 2026-09-10 的实测实例（OODER Studio ，web 端），不是示意图、不是设计稿。选它们的标准只有一条：每张截图对应前文一个"必须留下痕迹"的主张。

截图 1 ·

会话列表 = 记录面的入口。卡片上的「 2」协作徽标表示该会话已有第二个参与者（P2P 分享后），摘要行是"这件事进行到哪一步"的投影——分享不是把结果截图发出去，而是把整个工作现场纳入了对方可见范围。

截图 2 ·

人的决策写回会话（A2P 的问责记录）。这是一条role=system的决策留痕：动作、操作人、时间、活动 ID 一应俱全，重复提交也不会产生重复条目（按"父流程 + 活动 + 动作"幂等）。它回答的正是文章 §3.2 的那个问题——三个月后翻聊天记录，能不能还原"谁在何时批了什么、理由是什么"。

截图 3 ·

推理过程也要进记录面。会话里不只有结论：Agent 的思考过程以可折叠块呈现（默认收起、需要时展开），配合回复正文，构成"交互 + 执行 + 责任"三重记录中的执行侧证据。这也是 §1.1 那个失败模式（"这些数字哪来的？答不上来"）的对症解法。

截图 4 ·

"选场景 = 选 Agent"（P2A）。财务域有独立入口，每个场景就是一个领域 Agent（含它的提示词规则、工具集与业务口径）。员工不需要理解背后有几个 Agent，只需要点自己要做的那件事。

截图 5 ·

人工闸门（A2P 的红线）。Agent 干到关键处停下来推一张确认卡（此处为意图歧义消解：让用户明确选择下一步），确认前流程保持暂停。闸门的价值不在"弹了框"，而在"不点就不往下走"——所以超时也只能升级人工，不能替你签字。

本轮（2026-09-10）实测覆盖与结论

附录：核心概念速查

本文所述设计均以 OODER 平台已落地实现为工程证据；文中提到的"坑"与"断链"均为真实修复记录，而非假设场景。