从 Agent 到数字员工：技术栈全景与办公入口的工程实现（RAG+工作流引擎+MaaS）

从 Agent 到数字员工：技术栈全景与办公入口的工程实现（RAG+工作流引擎+MaaS）

拆解腾讯 WorkBuddy、阿里千问办公、字节 TraveWork 背后的统一入口架构与关键技术。

Agent 火了半年，三巨头最近同时按下“撤回键”——不是不做，而是从“赛马式铺产品”转向“集中火力做办公入口与数字员工”。作为开发者，我们更该关心的不是组织架构，而是这套“下一代工作系统”背后的技术栈：统一入口、工具调用、长程编排、记忆与权限。

图1：从 Agent 到数字员工的技术栈全景

半年前 OpenCloud 把 agent 开发门槛踩平，各家疯狂铺线：腾讯 Qcloud / WorkBuddy / QQ 龙虾 / 浏览器龙虾，阿里三条线，字节 ArcCloud / WhiteCloud / 飞书 AI，海外 OpenAI / Google / Anthropic 也烟囱林立。问题在于：agent 单次运行成本远超普通对话，算力账单厚、企业付费慢。方向清晰后，集中资源做“办公入口”成为共识。

办公入口的本质，是把散落的 SaaS（ERP / CRM / OA / HR / 文档）收进一个工作台。技术上，这意味着一个统一的对话/指令入口，背后是路由层（Router）+ 能力注册表（Capability Registry）。示意如下：

# 极简统一入口路由示意 class Workbench: def __init__(self): self.agents = {} # name -> agent 实例（数字员工） def route(self, intent: str): agent = self.router.classify(intent) # 意图识别分发 return agent.run(intent)

数字员工就是注册进这个 Workbench 的 agent 实例，由入口统一调度。

图2：技术四动作——统一入口·工具调用·长程编排·记忆与权限

数字员工要真正干活，必须能调用企业系统。核心是 Function Calling / Tool Use：把 ERP 查询、审批发起、文档读写封装成工具，由大模型决定何时调用。

{ "name": "create_approval", "description": "发起一张审批单", "parameters": { "type": "object", "properties": { "title": {"type": "string"}, "amount": {"type": "number"} }, "required": ["title"] } }

腾讯 WorkBuddy 靠微信 / 腾讯文档生态、阿里千问办公靠钉钉关系链、字节 TraveWork 靠飞书知识库——差异在连接的企业系统不同，机制一致。

单步工具调用不够，真实业务是多步的。需要 Workflow 引擎做长程编排：把“写周报→汇总各部门数据→发起审批→通知相关人”串成可执行图。DAG + 状态机是常见实现，这正是 TraveWork（飞书工作流）、千问办公（钉钉流程）的强项。

数字员工要“懂公司”，离不开企业知识库 RAG；要“安全”，离不开 RBAC 权限管控。RAG 把内部文档向量化按需检索；RBAC 决定某个数字员工能碰哪些数据。没有权限边界，数字员工就是风险敞口。

底层是 MaaS（Model as a Service）：模型能力、微调、推理成本。选型建议：先选定一个办公入口（钉钉 / 微信 / 飞书），再用其开放能力接 Function Calling 与 Workflow，最后用 RAG 补企业知识。别从零造轮子，押注工作系统而非单点工具。

图3：你用哪家 MaaS 做数字员工？

Agent 三阶段——产品→入口→能力，当前是入口战。PC 时代出 Windows，移动时代出微信，Agent 时代可能出“新的 Windows”：能力无处不在却无形。对开发者，机会在“把业务系统接入数字员工”的 Connector 层。你用哪家 MaaS 做数字员工？选型与踩坑评论区交流。