跳转至

权限视图与 MVC 模型

核心问题

组织级 Agent 不能把“所有已接入数据”直接塞进上下文。

同一个问题，对不同用户、部门、角色和项目，应该看到不同上下文。OrgReOrg 需要把统一知识与业务数据转成权限化上下文视图，让 Agent 在正确边界内搜索、阅读、行动和回答。

MVC 抽象

Model
  统一知识对象、业务对象、工具结果、索引、元数据和审计记录

View
  面向用户、部门、项目、角色和任务生成的上下文视图

Controller
  权限判断、上下文裁剪、工具调用边界、审批、审计和策略执行

这个 MVC 不是传统 Web 框架概念，而是组织知识上下文的工程抽象。

Model：统一知识与业务数据

Model 层保存或引用组织数据：

  • 文档、制度、会议纪要、决策记录。
  • GitHub Issue、PR、Commit、CI、技术文档。
  • 财务预算、报销、合同、发票。
  • CRM 客户、商机、沟通、回款。
  • 项目管理任务、里程碑、负责人。
  • BI 指标、看板、口径和查询结果。
  • 审计日志、工具调用、授权记录。

Model 层不等于把所有数据复制到一个数据库。更现实的做法是：

  • 对文档和知识页建立搜索索引。
  • 对业务系统保留 connector 查询能力。
  • 对关键对象保存元数据、权限标签和引用路径。
  • 对敏感数据按需缓存、脱敏或只保留摘要。

View：权限化上下文视图

View 是 Agent 实际可见的上下文集合。

常见视图包括：

  • 用户视图：某个员工当前能访问的任务、文档、系统对象。
  • 部门视图：部门内共享的制度、项目和业务数据。
  • 项目视图：项目成员可见的 issue、文档、客户、预算和风险。
  • 角色视图：HR、财务、研发、销售、管理层等角色的权限边界。
  • 任务视图：某次 workflow 被授权访问的临时上下文。

当前 MVP 已把最小 View 先放进 workspaces/variai/registry/workspace-topology.json 的 permission_views：

  • employee-self：员工个人视图，只能访问本人 personal context 和组织目录提示。
  • finance-department-owner：财务部门 owner 视图，只能访问财务部门 context 和组织目录提示。
  • project-maintainer：当前 OrgReOrg 项目维护者视图，只能访问项目 context 和组织目录提示。

这不是最终权限系统，而是把 MVC 的 View 从概念推进到可测试 contract。详见 Workspace Scope Eval。

View 层需要支持动态裁剪：

  • 删除无关上下文。
  • 脱敏敏感字段。
  • 限制时间范围。
  • 限制对象范围。
  • 限制工具动作。
  • 只暴露证据摘要而非原文。

Controller：权限、裁剪和边界

Controller 层负责：

  • 判断用户是否有源系统权限。
  • 判断 Agent 当前任务是否需要这些数据。
  • 决定哪些字段进入上下文。
  • 决定哪些工具可以调用。
  • 对写入、高风险或外发动作发起审批。
  • 写入审计日志。
  • 在权限不足时生成授权请求。

Controller 必须在代码和策略层执行，不应只写在 prompt 中。

上下文裁剪策略

组织上下文裁剪可以按四类规则组合：

规则 示例
身份规则 只有项目成员能看项目客户沟通
对象规则 只能看当前任务关联的合同和发票
字段规则 普通员工可见预算状态，不可见银行账户
动作规则 可读取 PR，不可合并；可创建报销草稿，不可提交付款

裁剪结果应保留“为什么可见”的元数据，方便审计和调试。

与 Custom Roles / Connector Permissions 的关系

Anthropic Enterprise 和连接器方向体现了一个重要趋势：组织需要把角色、项目、连接器动作和源系统权限组合起来管理。公开资料中已经可以看到项目共享权限、连接器工具权限、企业级 RBAC 和审计日志等思路。

OrgReOrg 的工程启发是：

  • 角色不是只控制 UI 菜单，也控制 Agent 可见上下文。
  • Connector 权限不是只控制能不能连接，也控制具体工具动作。
  • 源系统权限仍是底线，Agent 层只能缩小可见范围。
  • 审计日志必须覆盖“看了什么”和“做了什么”。

权限不足时的体验

当用户问题需要不可见数据时，Agent 不应编造答案，也不应泄露细节。

推荐响应：

当前视图缺少完成该任务所需的财务预算明细。
我可以向财务负责人发起只读授权请求，范围限定为项目 A、2026 Q2、预算执行状态。
授权后将继续检索并给出带证据引用的回答。

这种体验把权限不足转化为可审计的主动收集流程。

最小实现

第一阶段可以先实现：

  • 用户、部门、项目、角色四类权限标签。
  • 文档搜索结果按标签过滤。
  • MCP 工具调用前统一 policy check。
  • 工具返回结果按字段脱敏。
  • 每次 Agentic Search 和工具调用写入审计日志。
  • 权限不足时生成授权请求任务。

这足以支撑最小可用 Agentic Search 原型，并为后续 Connector 权限和审计打基础。

实施顺序

当前 MVP 不把完整 MVC 权限模型作为前置条件。

更务实的顺序是：

  1. 先跑通企业微信入口、Agentic Search、主动询问和知识外挂。
  2. 保留最小只读、审计和高风险人工确认边界。
  3. 用真实任务产生的 knowledge_gap、knowledge_card、工具调用和审计记录反推 Model。
  4. 再设计用户、部门、项目、角色、任务五类 View。
  5. 最后实现 Controller 层的权限判断、上下文裁剪、审批和审计。

这样可以避免先做一套抽象权限系统，后面发现它不匹配真实主动收集流程。

当前新增的 workspace_scope_eval 暴露了一个前置坑：SearchConnector Tool Gateway 必须支持 person:*、dept:*、project:* 这类 namespaced scopes；否则真实组织的个人/部门/项目私域无法进入同一套 Framework。