跳转至

员工入口与网页端 UI

核心判断

AI 平权不能要求每位员工自己安装 Codex、Claude Code、配置 API、购买海外订阅、处理网络环境,再学习如何把这些能力接到自己的工作里。

真正的 AI 平权入口应该是:

员工通过熟悉的网页端、企业微信和业务系统入口使用智能体能力;复杂的模型、agent runtime、工具接入、权限、安全和网络问题由后端 harness 统一封装。

这意味着产品必须提供面向普通员工的前端 UI,而不是只提供给技术人员的 CLI 或 SDK。

双输入入口

当前 P0 入口层收敛为两条确定主线:

  1. 企业微信 ChatOps:承接消息输入、群聊任务捕获、人工确认、通知、审批提醒和结果推送。
  2. 共享文件空间 / 云盘入口:承接员工每天按项目、部门、个人或任务上传的 Word、PPT、Excel、压缩包、代码包、链接清单和业务专用格式文件。

两条入口都不直接写搜索索引。正确链路是:

企微消息 / 文件空间上传
  -> Evidence source snapshot、hash、权限、PII/field mask、来源状态
  -> parser_hint 分流解析
  -> Ontology 对象、关系、规则、Markdown、Skill 或 workflow
  -> Runtime Projection 按任务和权限生成最小上下文包

主动补充信息时也遵循同一规则:用户可以直接回复消息、提供外部资料线索,或把文件上传到共享文件空间;系统只把这些补充材料先登记成 Evidence,再决定是否进入知识投影。

目标用户

第一批重点切入三类部门:

  • 研发部门:更容易接受 agent 工作流,也能最快验证代码、测试、PR、知识库和研发流程自动化。
  • 市场营销部门:内容、投放、线索、竞品、活动、素材和复盘任务密集,适合通过 agent 降低执行成本。
  • 职能管理服务部门:HR、行政、财务、后勤、法务、采购等流程多、文档多、审批多,是组织降本增效的关键场景。

这些部门的共同点是:

  • 信息和文档密度高。
  • 跨系统协作多。
  • 重复性流程多。
  • 质量和合规要求高。
  • 很多员工并不擅长配置和使用底层 AI 工具。

产品形态

flowchart TD
    U["员工"] --> UI["网页端 UI / 企业微信入口"]
    UI --> API["Harness Backend API"]
    API --> W["Workflow Plane"]
    W --> R["Runtime Adapter"]
    R --> L["Claude / Codex / OpenAI Agents / 其他 Runtime"]
    W --> T["Tool Plane"]
    T --> B["企业系统与知识库"]
    W --> P["Policy & Audit"]

前端负责承接人的意图和业务上下文,后端负责调度 agent runtime、工具、权限和 workflow。

UI 必备能力

自然语言交互

员工可以直接描述任务,例如:

  • “帮我整理这个需求的研发拆解。”
  • “根据这些素材写一版公众号初稿。”
  • “帮我检查这个报销单还缺什么。”
  • “把这份会议纪要转成待办并发给相关人确认。”

自然语言不是唯一交互方式,而是低门槛入口。

文件空间

界面中需要有文件空间,用于上传、查看、引用和生成文件。

但这里不应该直接暴露服务器文件系统,而应该设计为受权限控制的工作台文件空间:

  • 每个任务有自己的 workspace。
  • 文件可以来自上传、企业微信、知识库、业务系统或 agent 生成物。
  • 文件有权限、来源、版本和审计记录。
  • agent 只能访问当前任务授权范围内的文件。
  • 原始文件必须先形成 Evidence;Office、压缩包、代码包和专用业务格式通过 parser_hint 分流到不同解析器。
  • 还不能解析的文件也要先保存 raw snapshot、hash、权限和解析状态,避免原始证据丢失。

业务功能控件

仅靠聊天窗口不够。常见业务动作需要结构化控件:

  • 任务类型选择。
  • 部门和场景模板。
  • 文件引用。
  • 审批按钮。
  • 表单补充。
  • 结果对比。
  • 版本回退。
  • 发送到企业微信。
  • 创建工单、PR、活动计划或报销预审。

任务状态

员工需要看到任务运行状态:

  • 等待输入。
  • Agent 正在分析。
  • 正在调用工具。
  • 等待人工确认。
  • 已完成。
  • 失败并需要补充信息。

这能降低黑箱感,也方便组织复盘。

前端不是“聊天壳”

网页端 UI 不应该只是一个聊天壳。它应该是一个任务工作台:

任务工作台
  - 对话区:自然语言输入和解释
  - 文件区:上传、引用、生成、版本
  - 业务区:表单、审批、状态、结果
  - 证据区:引用来源、工具调用、审计摘要
  - 协作区:转交、评论、企业微信通知

企业微信入口

企业微信优先承接:

  • 员工身份和组织架构。
  • 轻量任务发起。
  • 通知和审批提醒。
  • 群聊中的任务捕获。
  • Agent 结果推送。
  • 人工确认和异常处理。

复杂任务则跳转到网页端工作台继续处理。

企业微信不是唯一输入源。聊天里出现的附件、外部链接和“请去云盘看这个文件”类指令,需要和文件空间 Evidence 入库合流,不能只作为一条普通聊天摘要处理。

后端职责

后端 harness 负责:

  • 用户身份和权限。
  • 任务类型识别。
  • workflow 调度。
  • runtime adapter 调用。
  • tool plane 调用。
  • 文件空间管理。
  • 审批和审计。
  • 评测和运行指标记录。

员工不需要知道底层到底调用 Claude、Codex 还是其他 agent runtime。

设计原则

  • 普通员工优先,不以工程师体验作为唯一标准。
  • 自然语言和结构化交互并重。
  • 文件、工具、审批和结果必须有明确边界。
  • 高风险动作必须显式确认。
  • 每个任务都能沉淀为 workflow、模板和评测样例。