

> 前面几篇讲的是"平台已经做到了什么"，本篇换个视角，看看**平台准备让外部开发者做什么**。建议先读完本系列其它篇目再阅读本篇。

---

## 面向更加开放的能力 —— 插件体系


前面几篇讲的是"平台已经做到了什么"。最后这一篇我们换个视角，看看**平台准备让外部开发者做什么**。

### 0. 背景：一个团队养不出整个生态

先回到出发点：数字员工系统是团队为了解决内部 AI Native 流程提效而做的。但"提效"这件事有一个天花板——**再强的平台团队，也穷举不完全公司每个部门、每条业务线的千奇百怪的场景**。财务的报销流程、招聘的简历筛选、运维的巡检、法务的合同审阅……这些场景各有各的系统、各有各的规则，靠一个中心团队去逐个实现，既做不过来，也做不地道。

顺着本系列的脉络看，平台其实一直在沿着"**把能力交给更多人**"的方向演进：多进程让员工规模化、模板派生让能力被复用、场景让协作被沉淀、SOP 让经验跨人流动。这条线的自然终点，就是**把"扩展平台本身"的能力也开放出去**——让每个懂业务的开发者都能为数字员工贡献能力，从而把平台从"一个提效工具"升级成"一个能自我生长的提效生态"。

这里还要顾及一个前提：平台**跑在云端容器里**，一旦引入"外部开发者提交的代码"，隔离与安全就是头等大事——第三方代码绝不能直接触达宿主进程、Token 和其他用户的数据。所以本篇你会反复看到"**沙箱**""受控 API""iframe 隔离"这类设计，它们不是可选项，而是"在云端容器里开放生态"的必要前提。

### 1. 为什么还要做插件体系

走到今天，平台已经具备了若干"开放点"：MCP 工具协议、Skills 软指令、Self-Evolution 自演化。这些能力解决了**单个员工自己进化**的问题，但当我们把视角放到 **"全公司开发者一起共建"** 时，仍然有几个无法绕开的痛点：

1. **能力扩展边界硬**：MCP 解决的是"工具接入"，Skills 解决的是"提示词复用"，但要在 *LLM 调用前后做一次拦截、给员工的工作区配一套自定义 Web 界面、在会话里展示一个动态表单* 这类需求，没有统一入口。
2. **缺少标准开发框架**：开发者今天要拓展能力，要么改核心代码、要么单独搭一个外部服务再用 MCP 接进来，门槛高、节奏慢。
3. **生命周期不可观测、不可介入**：skill 调用、工具调用、mcp 调用、每一次 LLM 请求与响应，对外都是黑盒，开发者无法在关键点 **"插一脚"**。
4. **会话 / 工作区 UI 闭环**：会话区固定是聊天气泡，工作区固定是文件树。但很多业务场景需要"长得不一样"的交互（如审批表单、可视化看板、定制 IDE）。

为此，下一阶段我们规划了一个完整的 **插件体系（Plugin System）**：

> **为有开发能力的用户，提供一个数字员工配置培养的灵活开放体系。其能力贯穿整个 Agent 运行时、会话区、工作区。**

### 2. 三大组成：引擎 / 框架 / SDK

整个插件体系将由三块构成，从平台到开发者逐层下沉：

![image.png](https://developer.qcloudimg.com/http-save/yehe-1084858/0fdd629eb18bb25f394f4f83f23662a6.png)

| 模块 | 角色 | 关键产出 |
|------|------|---------|
| **插件运行引擎** | 平台内置，负责加载、隔离、调度插件代码 | 沙箱、配额、生命周期分发 |
| **插件开发框架** | 标准化插件目录结构、清单、构建产物 | `plugin.json` 规范、scaffold CLI |
| **插件 SDK** | 暴露给开发者的 API 集合 | 钩子注册、平台能力调用、UI 组件 |

### 3. 能力一：贯穿全生命周期的钩子

这是插件体系最硬核的部分。我们计划在 Agent 运行的关键节点暴露 **Hook**，开发者通过 SDK 注册回调即可介入：

![image.png](https://developer.qcloudimg.com/http-save/yehe-1084858/b61726fe6f392996d3fa98ccbabda12e.png)

规划中的核心 Hook 一览：

| 阶段 | Hook | 典型应用 |
|------|------|---------|
| LLM 调用前 | `beforeLLM(payload)` | 注入额外上下文、敏感词过滤、Prompt 改写 |
| LLM 调用后 | `afterLLM(response)` | 内容审核、回复改写、自动翻译 |
| 工具调用前 | `beforeToolCall(tool, args)` | 参数校验、白名单、自动补默认值 |
| 工具调用后 | `afterToolCall(tool, result)` | 结果脱敏、缓存、二次加工 |
| Skill 调用前后 | `beforeSkill / afterSkill` | 技能链编排、技能权限校验 |
| MCP 调用前后 | `beforeMCP / afterMCP` | 出网域名校验、流量观测、配额计费 |
| 记忆写入前 | `beforeMemoryWrite` | 自定义脱敏、分类增强 |
| 会话开始 / 结束 | `onSessionStart / onSessionEnd` | 自定义会话头、结束总结回流 |

每个 Hook 都遵循统一的"放行 / 修改 / 拒绝"三态返回值，让插件可以做**温和增强**也可以做**硬性拦截**。

> 这套钩子机制将 **以 Server 侧的员工配置 + 运行时引擎侧的 AgentLoop 为锚点** 实现。AgentLoop 会在现有节点（LLM 调用、tool dispatch、memory consolidation）发出 emit 事件，插件运行引擎订阅这些事件并按员工绑定的插件列表分发。

### 4. 能力二：工作区自定义界面

数字员工的"工作区"目前是 CFS 共享存储里的一个目录树。下一阶段我们打算让插件**给每个员工的工作区配一套自定义 Web 界面**：

![image.png](https://developer.qcloudimg.com/http-save/yehe-1084858/74459ec978f0759299956e42e781336e.png)

设想中的典型用法：

- **数据分析员工**：工作区页面是一个看板（Dashboard），可以拖拽指标、保存视图，所有数据来自该员工自己的 workspace 文件。
- **审批助手员工**：工作区页面是一个工单列表，状态联动企业 IM。
- **代码助手员工**：工作区页面是一个迷你 IDE，做工件展示与差异查看。

技术上：插件 UI 跑在 **沙箱 iframe** 里，与宿主通过 SDK 提供的 `postMessage` 桥接通信，**不能直接访问宿主 DOM 与 token**，由 SDK 代为转发到 Server 侧 / 运行时引擎侧的受控 API。这样既保证了灵活性，也兜住了安全。

<image desc="工作区自定义插件示例：数字员工的看板式工作区" src="" />

### 5. 能力三：会话区自定义 UI

聊天气泡在很多业务场景下都是不够的。比如："请把这条工单审批掉" —— 与其让用户打字，不如直接出一个表单。

![image.png](https://developer.qcloudimg.com/http-save/yehe-1084858/af8ca7f6e27ea1e022ae95088ee9da2d.png)

规划要点：

- **Schema-driven UI**：员工回复中带上一段 `ui:` 描述，前端 SDK 渲染成对应组件（表单、按钮、列表、图表）。
- **双向事件**：用户在卡片里点"通过"/"驳回"，事件作为下一轮消息回流给 Agent。
- **多端一致**：平台 Web 与企业 IM 渠道统一渲染规范（不能渲染时降级为文本说明）。

实际上现有的"场景 announcement v2"（参见场景能力编排篇）已经为这一能力打了基础：消息体支持结构化字段，SSE 渠道事件已分类。下一阶段我们会把它正式化为 **`ui:` 协议** 并开放给插件。

<image desc="会话区自定义 UI 示例：审批表单卡片在 Web 与企业 IM 中的渲染" src="" />

### 6. 与现有架构的结合点

这套插件体系不是凭空再造一个系统，而是 **融入到现有的 Server 侧、运行时引擎侧、平台侧 三大子系统**：

![image.png](https://developer.qcloudimg.com/http-save/yehe-1084858/7512cd301cf5fadb748531bc0ffbea47.png)

| 子系统 | 新增职责 |
|--------|---------|
| **Server 侧** | 插件管理能力，包括上架审核（复用场景的 `pending_review` 流程）、`(user × plugin)` 权限矩阵、配额计费 |
| **运行时引擎侧** | 插件运行引擎、Hook 事件总线、沙箱执行（资源/出网/CPU 限制） |
| **平台侧** | iframe 沙箱、SDK Bridge、卡片 Schema 渲染器 |

值得一提的是 —— **这套体系会和现有的 MCP / Skills / Self-Evolution 形成互补，而不是替代**：

| 维度 | MCP（已具备） | Skills（已具备） | Self-Evolution（已具备） | **插件体系（规划中）** |
|------|---------------|------------------|--------------------------|------------------------|
| 主形态 | 协议工具 | Markdown 软指令 | 自动产出 Skill | **代码 + UI** |
| 介入点 | 工具调用 | system prompt | 后台学习 | **全生命周期 + UI** |
| 开发门槛 | 需要 MCP server | 写 markdown | 零（自动） | **完整 SDK 框架** |
| 运行位置 | 子进程 / 远端 | 进程内 | 进程内 | **沙箱 + iframe** |
| 谁能做 | 开发者 | 任何人 | 平台 + 模型 | **平台外开发者** |


### 7. 小结

如果说前面几篇描绘的是"数字员工平台的当下"，那这一篇描绘的就是它的"明天"。我们希望插件体系能让平台从一个 **"内置能力丰富的产品"** 演进为一个 **"任何开发者都能贡献能力的开放生态"** —— 让员工不只是越用越好，更让平台本身随生态一起进化。

前面几篇讲的是"平台已经做到了什么"，本篇换个视角，看看平台准备让外部开发者做什么。建议先读完本系列其它篇目再阅读本篇。

数字员工系列 · 插件体系能力篇

数字员工平台如何让Agent能力发挥到极致，如何让Agent协同工作尽量灵活，尽量提升准确性？本篇将通过插件的机制给到一种解决方案，为数字员工Agent能力扩展发挥无限可能。

技术专家

开发工具

后端

架构设计

插件体系赋能数字员工开放生态，通过贯穿Agent全生命周期的钩子机制、沙箱隔离的iframe自定义UI及Schema驱动会话卡片，实现安全可控的第三方能力扩展，与现有MCP/Skills/自演化能力互补，推动平台从提效工具向可生长生态演进。

数据分析

事件总线

容器

Agent

2026上云采购 | AI焕新·智启新局

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数字员工系列 · 插件体系能力篇-腾讯云开发者社区-腾讯云

数字员工系列 · 插件体系能力篇

数字员工系列 · 插件体系能力篇

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐