最近，腾讯把 WorkBuddy 和企业微信打通了。大厂们对办公 Agent 的期待，显然不止于处理个人邮件和文档，还希望它深入企业业务流程，发挥更大的作用。毕竟，个人提效不等于组织提效。一种新的协作方式是：Agent 负责理解意图、规划步骤；业务应用提供上下文、执行任务；人负责必要的审查和接管。那么，如何把企业应用的业务能力，甚至操作界面接入 WorkBuddy？本篇就来探讨与演示其中的一种集成方式 — MCP Apps。其中的核心逻辑是：让员工手头的 AI 工具，在组织授权和管理下接入企业系统，参与业务协作、承担实际任务。以客户拜访为例，销售需要查询 CRM 商机、了解未结的售后工单、翻阅每周的会议纪要，再整理下一步行动。过去，这些信息分散在不同的系统和文件中，你经常需要切换系统与页面、复制内容，甚至重复录入。查询我目前跟进的商机，翻阅下这周的会议纪要，制定我本周的跟进计划。WorkBuddy 就可以调用相关业务工具，汇总资料、整理计划，供你核对。帮我准备明天的客户拜访材料，并把跟进计划录入到 CRM。经过你的确认，Agent 再通过 CRM 接口写入跟进计划。在这里，值得集成的环节，往往是那些需要跨系统收集材料、结合上下文判断，再继续执行的工作（相比传统模式有明显的效率提升）。WorkBuddy 负责组织任务执行，企业系统负责保存事实、执行业务规则与专业操作，两者按各自擅长的方式配合。那么，接入 WorkBuddy，与自建共享 Agent 服务有什么区别？自建共享的 Agent 系统，更适合围绕组织的统一业务流程持续运行。例如，持续接收销售线索，按统一规则分配给员工，并在跟进超期时触发提醒。这类任务需要统一流程、管理状态、调度和运行环境，即使某位员工离线、换岗，也不影响任务继续。企业也可以按需设计 UI、编排流程，同时承担全部的开发和运维工作。接入 WorkBuddy，则更贴近员工手头的具体日常任务。例如，销售可以把 CRM 客户资料、自己电脑上的方案和企业微信中的会议纪要交给 Agent，结合当前任务整理材料、给出建议。复用已有的对话和任务入口后，开发重点可以放在业务能力、权限和操作界面的适配上。两种方式也可以结合。例如，共享 Agent 统一完成市场调研和商机生成，员工在 WorkBuddy 中推进具体客户的跟进。专业 Agent 还可以封装成服务，通过 API 与 MCP 接入 WorkBuddy。WorkBuddy 新推出的“项目”功能也支持共享上下文和团队协作，项目配置等内容会保存在云端。因此，桌面 Agent 能访问本地环境，但不等于所有数据都一定留在本机。
把企业应用接入 WorkBuddy 这样的桌面智能体，需要两端配合：智能体支持相应的调用协议；企业应用提供可用的接口或操作入口。根据企业系统已有的接口和工具，通常可以考虑几种接入方式：- 把操作方法写进 Skill，让 Agent 按说明调用 CLI 工具或脚本，访问业务系统、执行操作。
- 将应用 API 封装成 MCP 工具，供 Agent 调用；需要交互界面时，再配合 MCP Apps。其他 Agent 也可以封装成工具，通过 MCP 接入。
- 旧系统暂时没有可用接口时，可以通过浏览器自动化访问页面、完成操作。例如，在 WorkBuddy 中使用 Agent Browser 技能。
对于已有 API 的企业系统，可以优先考虑 MCP。若系统提供标准 OpenAPI 描述，还可以借助开源工具直接生成 MCP 封装，再按需求调整。比如，将查询客户、读取商机、登记跟进等能力，封装成用途明确、参数清晰的工具，供 WorkBuddy 等支持 MCP 的 Agent 调用。WorkBuddy 已经支持通过连接器调用 MCP 工具。接入后，员工可以在同一个任务中使用企业应用的业务能力，减少在多个应用之间切换。比如，筛选数据、比较方案、填写跟进表单时，如果每一步都靠自然语言交互，往往需要多轮沟通，操作也不够方便。这时，你可以为 MCP 工具配套开发 MCP Apps 界面，把表单等 UI 带进 WorkBuddy。员工可以在可视面板中查看数据与完成操作，推进当前任务。前两篇我们详细介绍过 MCP Apps，这里我们直接进入正题。MCP 让 Agent 调用工具，MCP Apps 则为这些工具配上交互界面。例如，可以为客户查询工具关联一个 UI 组件，用来展示返回的客户信息、商机和工单，并提供可填写、可提交的跟进表单。通常把这类围绕具体任务构建的交互组件称为 Widget。负责加载组件、承接交互的应用称为宿主（Host），在这里就是 WorkBuddy。Widget 可以复用企业应用已有的部分前端代码，也可以单独开发。除了展示 界面，还要处理交互和状态变化，比如，筛选条件改变、或者提交完成后，界面上要给出相应反馈。实际接入还涉及登录认证、授权和跨域访问等细节问题，这里先不展开。- 你向 WorkBuddy 发起任务，例如：“帮我登记xx客户的跟进计划。”
- WorkBuddy 规划步骤，识别 CRM 工具描述中关联的 UI 资源，并通过连接器调用相应的 MCP 工具。
- 读取 UI 资源，在沙箱（ifram额）中加载 Widget，再把客户基本信息等工具结果交给界面渲染。
- 员工填写并确认。Widget 通过宿主的通信桥接（AppBridge）调用 MCP 工具，提交数据，并根据返回结果更新界面。
- 交互完成后，Workbuddy 可以结束任务或者推进后续步骤。
这样，员工可以在提交前核对信息、修改输入；在提交后查看结果。交互界面显示在 WorkBuddy 中，业务规则、数据校验和写入仍由企业应用负责。你可以在 WorkBuddy 的侧边栏看到 MCP Apps 的类似交互界面:交互的过程和你直接在 CRM 系统中操作保持一致，但现在变化是：现在，员工依然可以沿用熟悉的系统操作方式。但现在的变化是：相关数据和界面会随着任务执行而变化，无需在多个应用之间反复切换。我们以“登记客户跟进计划”为例，演示如何用 MCP Apps 将企业应用的 UI 接入 WorkBuddy。先明确工具的输入、输出与职责。查询工具接收客户标识，返回客户信息、商机和未结事项等，并关联登记表单；销售填写后，再由另一个工具负责提交。- crmcustomerworkspace ：查询并关联工作台 UI
- crmcreatefollowup：创建客户跟进计划
- crmlistfollowups：查询跟进计划列表
const uri = 'ui://crm-demo/customer-workspace.html';
registerAppTool(server, 'crm_customer_workspace', {
inputSchema: { customerId },
_meta: { ui: { resourceUri: uri } }
}, async args => ({
content: [{ type: 'text', text: '客户工作台' }],
structuredContent: await workspace(args.customerId)
}));
structuredContent 返回结构化的业务数据，由宿主传给 UI 渲染。_meta.ui.resourceUri 则声明与工具关联的 UI 资源，告诉支持 MCP Apps 的宿主（WorkBuddy）：调用这个工具时，可以加载对应的 UI 组件。把客户摘要和跟进表单组织成一个 Widget：上半部分用于核对业务背景，下半部分用于登记跟进计划。大致骨架如下：<h3 id="customer-name"></h3>
<form id="followup-form">
<input name="title"placeholder="跟进事项">
<input name="owner"placeholder="负责人">
<input name="dueDate"type="date">
<button>保存跟进计划草稿</button>
</form>
将 HTML、样式和交互脚本打包后，需要在 MCP Server 中注册资源，让 WorkBuddy 可以根据前面声明的 uri 读取界面：registerAppResource(server, '客户 UI', uri, {
mimeType: RESOURCE_MIME_TYPE
}, async () => ({
contents: [{
uri, mimeType: RESOURCE_MIME_TYPE,
text: html
}]
}));
这里的 html 就是构建后的完整 HTML 内容；
RESOURCE_MIME_TYPE 的值为 text/html;profile=mcp-app，用于标识 MCP Apps 界面资源。注意 uri 必须与前面的工具注册中一致。销售填写并提交后，要由 WorkBuddy 转发工具调用，把跟进计划写入 CRM。这使用 MCP SDK 的 callServerTool 来完成：import { App } from'@modelcontextprotocol/ext-apps';
const app = new App({ name: 'CRM', version: '1.0.0' }, {});
app.ontoolresult = result => consume(result);
await app.connect();
form.onsubmit = async event => {
event.preventDefault();
// 从当前表单组装 argumentsValue，过程省略
consume(await app.callServerTool({
name: 'crm_create_followup',
arguments: argumentsValue
}));
};
这里的 form 就是上面的表单；提交时，从 UI 表单组装 argumentsValue。callServerTool 会把保存动作交给 WorkBuddy 转发工具调用请求（MCP Apps 必须通过宿主应用转发请求），获得返回后再更新前端界面。在工具和 UI 资源准备好后，就可以启动 MCP Server，通过 Streamable HTTP 提供远程服务。在WorkBuddy 中添加对应的 MCP 连接器，填写服务地址，例如 https://crm.example.com/mcp（可能需要完成认证）。工作台加载后，你可以查看客户信息和历史跟进，填写并提交新计划，再核对 CRM 返回的保存结果。整个过程都在 WorkBuddy 中完成。结合企业微信等工作入口和 WorkBuddy 的项目协作，这种方法可以把分散在多个系统中的数据和操作串在一项任务中：员工提出目标、核对信息并完成交互，企业应用负责具体的业务处理。桌面 Agent 可以把个人资料、协同办公和企业应用连接起来，减少系统切换和重复操作。这可以从一项高频任务、一组业务工具和一个交互组件开始：Agent 规划步骤、准备材料；员工核对确认；企业应用执行业务操作。上文以 CRM 为例，演示了如何用 MCP Apps 把业务能力和 UI 接入 Agent 工作流。这种方式当然也可以延伸到更多场景。比如：报销凭证核对、采购报价比较、运维排障的证据追踪、合同条款确认、经营指标下钻，以及招聘材料整理等。当办公 Agent 真正接入企业应用时，未来还需要完善几类问题：- 应用（比如已有 SaaS）的开放，以及对商业模式的影响
随着这些能力逐步完善，办公 Agent 有望成为未来企业日常业务的重要入口。