总体架构

当前定位

OrgReOrg / Harness 是组织级 Agentic Knowledge Infrastructure。

它以企业微信、飞书和 Web 工作台作为统一交互入口，但不局限于聊天数据。真实业务信息分散在 GitHub、财务系统、CRM、项目管理系统、文档系统、BI 等部门系统中，需要通过 Agentic Search、主动信息收集、Connector / MCP、权限视图和 Loop Engineering 持续转化为可检索、可调用、可授权、可审计的私域智能能力。

分层架构

flowchart TD
    U["用户入口<br/>Web 任务工作台 / 企业微信 / 飞书 / CLI / IDE"] --> A["Agent Harness API"]
    A --> F["Frontend Interaction Layer<br/>自然语言、文件空间、表单、审批、业务控件"]
    A --> W["Workflow Plane<br/>任务编排、状态机、人工确认"]
    W --> P["Policy Plane<br/>权限、审批、脱敏、审计"]
    W --> R["Runtime Adapter<br/>Claude Code / Codex / OpenAI Agents"]
    W --> C["Context & Search Plane<br/>BM25 / Vector / Rerank / Evidence"]
    W --> B["Agent Bus<br/>事件、命令、查询、产物"]
    B --> R
    B --> T
    R --> T["Tool Plane<br/>MCP Servers / Function Tools / Internal APIs"]
    C --> T
    T --> S["部门业务系统<br/>GitHub / 财务 / CRM / 项目管理 / 文档 / BI"]
    W --> E["Eval Plane<br/>评测、回归、质量门禁"]
    P --> L["Audit Log<br/>工具调用、输入输出、审批记录"]

各层职责

Agent Harness API

统一对外入口，负责接收任务、识别任务类型、创建运行上下文，并返回任务状态。

它不直接包含复杂业务逻辑，而是把任务交给 workflow。

在当前目标企业中，协同入口优先按企业微信设计，同时兼容飞书和 Web 工作台。它们承担消息入口、审批通知、通讯录身份、群聊上下文和内部应用入口，但不是完整数据源。真正的业务事实仍需要通过部门系统 Connector 获取。

Frontend Interaction Layer

前端交互层负责把普通员工的工作意图转成后端可执行的任务上下文。

它包括：

• 自然语言对话。
• 文件空间。
• 业务表单。
• 审批和确认按钮。
• 任务状态。
• 结果预览和版本管理。
• 企业微信通知和跳转。

这层的目标是让员工不需要理解底层 SDK、模型、网络环境和 agent 配置。

Workflow Plane

负责任务编排，包括：

• 多步骤流程。
• 状态机。
• 人工确认。
• 失败重试。
• 任务暂停与恢复。
• 子任务拆分。

这层是企业 agent 的业务核心。

Context & Search Plane

Context & Search Plane 负责把组织知识和业务对象转成 Agent 可检索、可引用、可裁剪的上下文。

它包括：

• 文档解析和索引。
• BM25 全文检索。
• 向量检索。
• RRF 融合和 Rerank 重排序。
• 证据引用。
• 知识缺口识别。
• 按权限生成上下文视图。

这层不应只做一次性 RAG。更合适的方式是通过 MCP Search Server 支持 Agent 多轮搜索、深度阅读、交叉验证和缺口上报。

Agent Bus

Agent Bus 负责 Agent-to-Agent 通信。

它支持：

• 事件发布。
• 命令请求。
• 信息查询。
• 结构化产物传递。
• trace 和审计。

第一阶段可以先用单体后端中的逻辑 bus 实现，不急于引入复杂分布式基础设施。后续可根据复杂度评估 Zenoh、NATS、Kafka、Redis Streams 等方案。

Runtime Adapter

封装不同底层 agent runtime，例如 Claude Agent SDK、Codex SDK、OpenAI Agents SDK。

目标是让上层 workflow 不直接绑定某个供应商。

Tool Plane

封装企业能力，推荐优先做成 MCP server 或统一 tool gateway。

这层应该有清晰的数据契约、权限边界、错误码和审计日志。

第一批重点不是泛泛接入聊天记录，而是接入部门业务系统：GitHub、财务系统、CRM、项目管理系统、文档系统、BI 和审计系统。

Policy Plane

负责治理和安全：

• RBAC / ABAC。
• 数据脱敏。
• 工具 allowlist / denylist。
• 高风险动作审批。
• 预算限制。
• 外发内容检查。

Eval Plane

负责持续验证 agent 质量：

• golden cases。
• 回归测试。
• 安全红队测试。
• 任务成功率统计。
• 成本和延迟观测。

设计原则

• 底层 runtime 可替换。
• 企业工具能力可复用。
• 业务流程显式编排。
• 高风险动作必须可审计。
• 关键任务必须可评测。
• 不把核心逻辑藏在 prompt 里。
• 面向普通员工设计入口，而不是只面向工程师设计接口。
• 支持人与 Agent、Agent 与 Agent 两类交互。
• 企业微信和飞书是交互入口，不是完整数据源。
• 业务系统 Connector 必须返回可引用证据和权限元数据。