南威软件 WellWork 智能体操作系统

🎯 平台定位

平台定位为组织的智能体操作系统：向下管理模型与工具，向上承载数字公务员与数字员工，用统一的安全与权限规则约束智能体行为。

🏗️ 架构分层

🔌 接入与集成能力

📊 数据与智能

📊 规格参数横向对比

政企在“让 AI 干活”这件事上通常有三条路：买通用对话工具、买单点智能体应用、自研 Agent 框架。三者的差别不在模型强弱，而在能否被组织真正管住。

判断是否需要这一层的分界线不是预算，而是“要不要让智能体写回业务系统”。只读问答用通用工具就够；一旦涉及提交、审批、回写，权限与审计就成了硬约束。

🎯 应用场景

☁️ 部署模式

🛡️ 安全与合规

🔧 运维与保障

⚙️ 工作原理与运行机制

把智能体叫成“操作系统”，容易被理解成营销说法。它实际回答的是一个工程问题：当一家单位里有几十个智能体、要访问十几个业务系统、还要保证不同岗位只看得到自己能看的数据时，谁来做调度、鉴权与记忆。WellWork 处理的就是这一层。

首要工作：给智能体划边界

智能体不是“越能干越好”，而是“在授权范围内可靠地干”。平台把岗位职责翻译成可执行的权限集合：能查哪些库、能调哪些接口、能写回哪些字段。超出范围的请求在调度层被拦下，而不是指望模型自觉。这一层是政企场景能否落地的前提——没有边界的智能体，业务部门不敢用。

第二件事：跨系统调用需要“翻译层”

同一件事往往横跨多个系统：查人员在一个系统、查审批在另一个、回写结果在第三个。WellWork 把这些系统能力封装成统一工具，智能体只描述“要做什么”，由平台负责选路、鉴权与结果归一化。系统增减时只需维护工具层，智能体本身不用改。

第三件事：组织记忆与技能资产

通用模型记不住“本单位的办事口径”。平台把历史交互结论沉淀为组织级记忆，把成熟做法固化为技能，新上岗的数字员工加载对应技能即可工作。这解决的是政企最实际的痛点：经验随人走，人走了经验就没了。

🏗️ 架构分层与数据流向

从架构上看，WellWork 是四层结构，自下而上依次是资源、技能与记忆、运行、治理。理解分层比记功能清单更有用，因为每一层的边界决定了系统能扩展到什么程度。

资源层：模型、知识与系统工具

这一层不生产内容，只负责“有什么可用”。模型可按场景选配，知识来自本单位文档与业务库，系统工具则是各业务系统开放接口的封装。资源层的关键指标是覆盖率——能接入多少系统、能覆盖多少业务动作。

技能与记忆层：把经验变成可加载的组件

技能描述“这类任务怎么做”，记忆记录“上次是怎么处理的”。两者结合，智能体不必每次从零理解背景。技能可跨部门复用，也可按单位定制，这是平台从“工具”变成“基础设施”的分水岭。

运行层：按角色装配智能体

数字公务员、数字民警、数字员工不是三套程序，而是同一运行层加载不同技能与权限的组合。新增岗位类型时，配置技能与权限即可，不需要重新开发一个智能体。

治理层：审计与效果评估

记录每次调用的输入、依据与动作，支持事后追溯；同时统计任务完成率与人工干预比例，用于判断哪些岗位可以扩大自动化范围、哪些还需要人工兜底。

🚀 实施与上线路径

这类平台不适合“一次性全量上线”。按岗位分批推进，既能控制风险，也能让业务部门看到具体收益后主动提出扩展需求。

阶段一：选点与基线测量

选两到三个“重复度高、规则清晰、有明确产出物”的岗位试点，先测出当前单件事务的平均耗时与人工投入，作为后续对比的基线。没有基线的试点，最后只能用“感觉好用”来汇报。

阶段二：知识与工具准备

梳理该岗位依赖的制度、模板与数据口径，完成业务系统接口封装。这一步通常占项目一半以上工作量，也是最容易被低估的部分。

阶段三：权限与审计配置

按最小必要原则划定数据范围与可执行动作，设置关键动作的人工确认节点。审计规则要与本单位内控要求对齐，而不是照搬产品默认值。

阶段四：试运行与扩面

试运行四到六周，重点观察误操作率与人工干预比例。干预比例稳定下降后再扩到同类岗位，同时把成熟技能纳入技能中心供其他部门复用。

🔧 运维保养与日常维护

智能体系统的运维与传统软件不同：代码不变，效果也会衰减——因为制度在变、数据在变、模型在迭代。维护节奏要围绕“效果”而不是“可用性”。

每日：异常调用与人工接管

查看调用失败、越权拦截与人工接管记录。接管率突然上升，通常指向知识过期或接口变更，而不是模型退化。

每周：技能与知识更新

由业务部门确认本周制度与流程变更，同步更新对应技能与知识条目。更新责任应落到业务侧，信息中心只负责发布与回滚。

每月：效果复核与权限校准

按岗位复盘任务完成率、平均处理时长与差错率；同时检查权限是否随岗位调整而失效——人员轮岗后权限未回收，是政企系统最常见的安全隐患。

版本与回滚

技能与知识更新应保留版本，出现效果下降时可回退到上一版。没有回滚能力的智能体平台，业务部门不敢把关键流程交出去。

❓ 常见问题

🏬 典型场景深描

平台的价值在不同岗位上呈现方式不同。以下四类场景覆盖了政企当前落地最集中的方向。

政务窗口：数字公务员承接前置环节

群众到窗口前先由数字公务员问清事项、核对材料、提示缺件，窗口人员只处理疑难与确认。衡量口径是“因材料不全被退回的比例”，而不是“回答了多少问题”。

企业职能岗位：数字员工处理重复事务

制度问答、材料起草、数据汇总、跨系统查数这类工作占用了大量人力却不产生决策价值。数字员工承接后，人转向审核与判断，岗位编制不必随业务量线性增长。

基层执法：按规范生成与核对

执法文书格式固定、要素明确，适合由智能体起草初稿，干警核对后签发。这类场景的关键不是写得快，而是“引用条款准确”，因此知识库的时效性比模型能力更重要。

跨部门流程：把串行变并行

一件事涉及多个部门时，智能体可同时发起多项前置核查，把串行等待变成并行准备。这类场景对工具层要求较高，也是平台与单点应用差距最明显的地方。

👥 不同角色的使用反馈

同一套平台，三类角色的关注点差异很大。把这些关注点提前对齐，能显著减少上线后的返工。

业务部门：关心“能不能真的少干活”

业务部门不看架构，只看一件事：原本三个人做的事，现在两个人能不能扛住。试点阶段应直接给出“单件事务耗时”的前后对比，而不是功能演示。

信息中心：关心“接得进、管得住”

信息中心关注接口改造量、权限模型是否可维护、出问题能否快速定位。工具层的封装质量直接决定这两点，选型时应要求提供接口接入清单与鉴权方案。

审计与合规：关心“出了事能说清”

审计部门关心每一次智能体动作是否有依据、有授权、有留痕，能否还原“谁在什么权限下做了什么判断”。这一诉求必须在架构层满足，事后补日志是补不出来的。

📜 信息来源与免责声明