Agent 不止服务一个人:Org-Agent 用组织约束与任务依赖图服务整个组织

Org-Agent: Beyond Personal Assistants Towards Organizational Agents

Luyao Zhuang, Yujing Zhang, Zijin Hong, Yilin Xiao, Xiao Huang

cs.AI

2026-09-28

提出 Org-Agent:按组织约束拆任务、建依赖图、按拓扑序执行,在 MUSES-Bench 与 GroupMemBench 上验证跨用户决策与记忆两项能力。

这篇在解决什么

现在的 agent 框架默认服务一个人:一个用户、一个上下文窗口、一份属于这个用户的记忆。一旦 agent 进入组织、服务对象变成一群人,这些假设就撑不住了。A 提的请求可能要用 B 上周给的信息;有的文档只有特定权限的人能看;两个人对同一件事的要求可能互相矛盾。个人助理式的框架没有为这些情况建模,结果要么漏信息,要么越权,要么在冲突要求面前瞎选。

论文把组织场景需要的能力归成两条:一是跨用户的交互与决策,把多个人的要求拼成一个能执行、合规的决定;二是跨用户的记忆与知识使用,把散落在不同对话里的信息在正确的时机、以正确的权限用出来。

方法

Org-Agent 的设计立场是约束优先:先想清楚哪些信息或批准必须在动作之前拿到、哪些条件必须在执行过程中持续成立,再谈怎么做。约束分三类:

执行分三步:

依赖图在这里不是装饰。组织约束天然决定顺序:必须先向有权限的人确认,才能读那份文件;必须先裁决冲突,才能往下走。把约束显式编码进图的边,调度就有据可依,而不是靠模型现场发挥。

结果

论文在 MUSES-Bench 和 GroupMemBench 两套基准上做了实验,结论是 Org-Agent 在两项能力上都有效,消融实验支持依赖建模和工具使用各自的贡献。但摘要没有给出任何具体分数,也没有点名对照基线;全文这次没有取到,所以「比谁强、强多少」目前无法回答,这些结论的分量要等看到原文数字再校准。

为什么重要

权限、审计、信息溯源在企业里是合规硬需求,现有 agent 技术栈大多把它们留在部署层的外挂过滤里。Org-Agent 把这些约束放进推理与调度的内部,方向踩在 agent 从个人工具走向组织基础设施的路径上。就算不直接用这套框架,「约束决定执行顺序」这个思路对做企业内部 agent、多 agent 协作系统的人也有借鉴价值。也要说清楚:从摘要看,这是一个框架性工作,拆解、建图、拓扑排序、工具调用都是成熟件的组合,新意在组合方式和对组织约束的系统化定义。

局限与存疑

术语

原文与代码

相关论文

全部论文解读