权限视图与 MVC 模型¶
核心问题¶
组织级 Agent 不能把“所有已接入数据”直接塞进上下文。
同一个问题，对不同用户、部门、角色和项目，应该看到不同上下文。OrgReOrg 需要把统一知识与业务数据转成权限化上下文视图，让 Agent 在正确边界内搜索、阅读、行动和回答。
MVC 抽象¶
```text Model 统一知识对象、业务对象、工具结果、索引、元数据和审计记录
View 面向用户、部门、项目、角色和任务生成的上下文视图
Controller 权限判断、上下文裁剪、工具调用边界、审批、审计和策略执行 ```
这个 MVC 不是传统 Web 框架概念，而是组织知识上下文的工程抽象。
Model：统一知识与业务数据¶
Model 层保存或引用组织数据：
- 文档、制度、会议纪要、决策记录。
- GitHub Issue、PR、Commit、CI、技术文档。
- 财务预算、报销、合同、发票。
- CRM 客户、商机、沟通、回款。
- 项目管理任务、里程碑、负责人。
- BI 指标、看板、口径和查询结果。
- 审计日志、工具调用、授权记录。
Model 层不等于把所有数据复制到一个数据库。更现实的做法是：
- 对文档和知识页建立搜索索引。
- 对业务系统保留 connector 查询能力。
- 对关键对象保存元数据、权限标签和引用路径。
- 对敏感数据按需缓存、脱敏或只保留摘要。
View：权限化上下文视图¶
View 是 Agent 实际可见的上下文集合。
常见视图包括：
- 用户视图：某个员工当前能访问的任务、文档、系统对象。
- 部门视图：部门内共享的制度、项目和业务数据。
- 项目视图：项目成员可见的 issue、文档、客户、预算和风险。
- 角色视图：HR、财务、研发、销售、管理层等角色的权限边界。
- 任务视图：某次 workflow 被授权访问的临时上下文。
View 层需要支持动态裁剪：
- 删除无关上下文。
- 脱敏敏感字段。
- 限制时间范围。
- 限制对象范围。
- 限制工具动作。
- 只暴露证据摘要而非原文。
Controller：权限、裁剪和边界¶
Controller 层负责：
- 判断用户是否有源系统权限。
- 判断 Agent 当前任务是否需要这些数据。
- 决定哪些字段进入上下文。
- 决定哪些工具可以调用。
- 对写入、高风险或外发动作发起审批。
- 写入审计日志。
- 在权限不足时生成授权请求。
Controller 必须在代码和策略层执行，不应只写在 prompt 中。
上下文裁剪策略¶
组织上下文裁剪可以按四类规则组合：
| 规则 | 示例 |
|---|---|
| 身份规则 | 只有项目成员能看项目客户沟通 |
| 对象规则 | 只能看当前任务关联的合同和发票 |
| 字段规则 | 普通员工可见预算状态，不可见银行账户 |
| 动作规则 | 可读取 PR，不可合并；可创建报销草稿，不可提交付款 |
裁剪结果应保留“为什么可见”的元数据，方便审计和调试。
与 Custom Roles / Connector Permissions 的关系¶
Anthropic Enterprise 和连接器方向体现了一个重要趋势：组织需要把角色、项目、连接器动作和源系统权限组合起来管理。公开资料中已经可以看到项目共享权限、连接器工具权限、企业级 RBAC 和审计日志等思路。
OrgReOrg 的工程启发是：
- 角色不是只控制 UI 菜单，也控制 Agent 可见上下文。
- Connector 权限不是只控制能不能连接，也控制具体工具动作。
- 源系统权限仍是底线，Agent 层只能缩小可见范围。
- 审计日志必须覆盖“看了什么”和“做了什么”。
权限不足时的体验¶
当用户问题需要不可见数据时，Agent 不应编造答案，也不应泄露细节。
推荐响应：
text
当前视图缺少完成该任务所需的财务预算明细。
我可以向财务负责人发起只读授权请求，范围限定为项目 A、2026 Q2、预算执行状态。
授权后将继续检索并给出带证据引用的回答。
这种体验把权限不足转化为可审计的主动收集流程。
最小实现¶
第一阶段可以先实现：
- 用户、部门、项目、角色四类权限标签。
- 文档搜索结果按标签过滤。
- MCP 工具调用前统一 policy check。
- 工具返回结果按字段脱敏。
- 每次 Agentic Search 和工具调用写入审计日志。
- 权限不足时生成授权请求任务。
这足以支撑最小可用 Agentic Search 原型，并为后续 Connector 权限和审计打基础。
实施顺序¶
当前 MVP 不把完整 MVC 权限模型作为前置条件。
更务实的顺序是：
- 先跑通企业微信入口、Agentic Search、主动询问和知识外挂。
- 保留最小只读、审计和高风险人工确认边界。
- 用真实任务产生的
knowledge_gap、knowledge_card、工具调用和审计记录反推 Model。 - 再设计用户、部门、项目、角色、任务五类 View。
- 最后实现 Controller 层的权限判断、上下文裁剪、审批和审计。
这样可以避免先做一套抽象权限系统，后面发现它不匹配真实主动收集流程。