个人 Agent 走进生活，数字员工如何走进公司？

个人 Agent 是当前 AI 最热闹的方向。创业公司有 Instinct，大厂有 Meta 的 Muse，模型厂有 OpenAI 的 dots、Anthropic 的 Claude Duet。 这些产品正在尝试一种持续合作的体验：用户授权它们访问相关应用和信息，它们规划任务、主动跟进，并在用户离开后继续工作。

好的个人 Agent ，得“眼里有活”，主动做事。

企业办公场景也出现了相似变化。Anthropic 今年 6 月发布的 Claude Tag，让 Claude 进入 Slack 的团队频道。同事在讨论中 @Claude，就可以交办工作；它使用企业配置的工具推进任务、返回结果，其他成员也可以像同事间协作一样，继续补充和调整工作内容。它还能够保留相关记忆，并按设置主动跟进。

好的数字员工得“扛得起事”，找得到活、交得出活。

这两类产品面向的对象不同，却呈现出一个共同方向：Agent 与使用者的关系，开始跨越一次问答，延续到多次任务和日常协作中。

其中，Claude Tag 带出的一个问题尤其值得关注：数字员工为什么需要进入工作流、参与团队讨论？对于 Data Agent，又有什么借鉴和启发？

Context，是数字员工的工作现场

“按刚才讨论的方向，明天把分析给我。”

在人与人的办公协作中，这句话往往足以推进工作。因为分析师参加过会议，知道问题的来由，也听到了讨论中的补充与分歧。同一句话交给没有经历前面过程的 Agent，就可能缺少关键背景。

以渠道经营分析为例。假设企业刚把一部分经销客户转到直营，负责人随后询问：“最近经销渠道销售为什么下降？”

不了解调整背景的 Data Agent，可以准确找出哪些客户在经销渠道买得少了，却可能把渠道迁移解释成客户流失。参加过讨论的分析师，则有机会想到把这些客户在不同渠道的购买连起来看。

这里的差别，来自双方掌握的工作背景。销售下降是数据事实，客户是否流失，还需要进一步判断。

现实中的任务交接，依赖大量共同经历。项目启动会说明目的，经营会确定重点，群里的讨论补充变化。团队内部协作时，成员之间自然会省略已经共同知道的部分。

人与 Agent 协作时，这种省略却未必成立。用户可能认为某项变化“它应该知道”，Agent 也可能认为现有信息已经足够。

这正是我们之前提到“知道与不知道”四个象限中最危险的一种状态：不知道自己不知道。

如果 Agent 已经意识到客户迁移可能影响比较，只是不清楚迁移范围，它还可以继续查证。更困难的是，它根本没想到存在这件事，自然也就不会主动寻找相关材料。

Agent 进入企业工作流的价值，由此变得更具体：让影响任务的信息有机会到达 Agent。

这些影响任务的信息，构成了企业上下文的一部分。

“Context 是 Agent 的工作现场”，对 Data Agent 来说，上下文既包括数据定义、指标口径和计算规则，也包括任务目标、分析方法、近期业务变化，以及团队已经形成的决定。

Data Agent 既需要理解数据，也需要理解业务。

Anthropic 的数据团队公开介绍过这一问题。他们在 Slack 中部署分析 Agent，配置了企业语义层、分析 Skills 和评测，同时接入内部知识索引，查找会议纪要、故障记录、项目说明等背景知识。

不同场景下的数字员工，对于企业上下文信息的组织方式和消费方式会有不同，比如项目经理更关心项目目标、负责人、任务状态等信息，而数据分析师更关心项目的业务目标、考核方式、过程指标、决策依据等。同一批企业信息，需要围绕不同岗位和任务重新组织，才能成为它们各自可用的工作现场。

Agent 如何进入工作现场

企业上下文既然如此重要，那么 Agent 如何获得？

一种自然的想法是给 Agent 发工牌，让它拥有跟人类员工一样的身份，从而企业开放给它相应的权限，比如可以进同事群、进项目群，可以旁听讨论过程，可以查看文档和报表等。

10 月 29 日，腾讯发布面向个人用户的 Buddy One，连接 WorkBuddy、腾讯文档、腾讯会议、腾讯网盘和 IMA，支持关联账号后的跨应用知识检索。

同样的事情，在企业侧也一样在发生，Workbuddy 不仅实现 C 端各个腾讯系产品的打通，还跟企业微信做了打通，减少了在聊天记录、微盘、文档之间来回复制资料的麻烦；通过连接器和开放生态，还可以接入更多外部服务。这让企业办公超级入口的轮廓逐渐显现，也为更多企业上下文的连接创造了条件。

员工接触到的企业上下文信息纷繁复杂，归结起来大致有三类：

第一类是业务知识，帮助员工理解业务怎么运转。比如，客户、商品、门店、渠道之间是什么关系，“新客”和“销售收入”如何定义，分析销售下降通常要检查哪些因素。这里有企业共同遵循的规则和口径，也有长期积累的方法与经验。

第二类是业务事实，帮助员工了解发生了什么、当前是什么情况。比如，上个月销售下降了多少，哪些门店正在缺货，哪些客户从经销转到了直营。这些信息持续变化，时间、来源和适用范围都会影响判断。

第三类是工作背景，帮助员工理解这次为什么做、究竟要解决什么问题。同样分析销售下降，是为了调整促销，还是决定渠道投入？会上讨论过哪些原因，排除了哪些方案，最终需要分析支持什么决定？这些背景往往散落在会议、聊天和方案修改中，却直接影响工作方向。

三类信息，在真实工作中总是联系在一起的。分析师接到“解释经销渠道销售下降”的任务，需要知道销售怎么算，需要查到实际变化，也需要了解企业刚刚作出的渠道调整。

因此，工程上需要建立一套能够把它们联系起来的上下文体系。本体组织业务对象及其关系，数据语义层提供统一的定义与计算依据，知识库保留解释、背景和证据，Skill 承载经过验证的工作方法。Agent 执行任务时，需要把这些信息接起来，才能交出有依据的分析，支持业务决策。

这就是为什么我说，Context 首先是信息学，其次是工程学。先分清信息的含义、关系和用途，再决定怎样表达、获取和使用它们。

当企业开始使用多个 Agent，共同的业务定义、对象关系和知识，就不适合由每个 Agent 各自重复建设。更可行的方向，是建立能够被不同 Agent 在权限范围内调用的企业上下文基础设施。

过去 5 年，我们一直持续投入在企业数据语义层，比如持续增加对企业数据源的连接、探查、发现和理解能力，目前拥有几乎全部主流数据库的连接能力、常用湖仓平台的 ETL 代码的解析能力、主流 DW / BI 工具元数据的解读能力等，并通过这些能力，自助按需构建数据语义。

但企业上下文的构建仅在数据语义层是不够的，我们近期会升级语义层能力，新增本体的表达能力，推出本体语义层，让数据定义与更多业务对象和关系联系起来，作为构建统一、开放的企业上下文的一项基础能力。

正是因为能够依托这些能力，我们讲 Data Agent 像数据分析师一样“30 分钟上岗”，才有了实现的基础。

不妨设想这样的画面：Data Agent 的第一步是拿到“工牌”，明确它服务哪个部门、承担什么分析职责，并获得相应的数据、文档和协作空间的访问权限。随后，它开始探查数据、阅读报表和历史 SQL，梳理指标口径，识别客户、商品、渠道等业务对象及其关系，借助已有的企业语义，逐步补充岗位所需的本体语义层。与此同时，它阅读业务材料和项目讨论，整理相关知识，标出相互矛盾或尚待确认的地方，请分析师核对，再把确认后的认识更新到知识库。

有了这些准备，它就可以从具体任务开始干活。比如分析经销渠道销售下降时，先确认指标口径，再结合客户与渠道的关系、近期调整的背景，调用相应的分析 Skill，区分渠道迁移与真实流失的影响。

这才是 Agent 进入工作现场，在企业干活的正确打开方式。

数字员工上岗，FDE 也要跟着到岗

不过，上述过程能够顺利开展，有一个前提：企业的环境已经具备让 Agent 工作的条件。现实中，这些条件往往需要 FDE 与客户一起建设。

比如，企业使用的是内部开发的数据系统，接口和数据格式都有自己的约定，现成的连接器无法直接使用；历史报表保存在特有格式中，或者依赖经过深度定制的 ETL 程序，需要开发新的解析器才能读懂；私域环境里的网络、身份认证和数据访问方式，也可能需要专门适配。

Agent 可以发现连接失败、识别材料无法读取，但要把它们变成稳定可用的访问能力，还需要 FDE 理解客户架构，与客户一起完成开发、部署、联调和验收。

即使数据已经接通，企业语义的建模也不宜全部交给 Agent 作主。Agent 可以根据表结构、历史 SQL 和报表生成候选模型，但业务对象如何划分，跨系统的客户身份怎样统一，关系应该表达到什么粒度，哪些定义可以在部门之间共享，都需要专业判断。尤其是要把一份报表中的局部理解，建设成多个 Agent 都会使用的企业语义时，建模选择的影响已经超出了一次任务。

指标口径也是如此。Agent 在接到任务时，应当能够主动澄清、选择适用的口径；而建设企业共用的指标定义，则需要 FDE 与客户的数据团队、业务团队一起，核对计算逻辑、数据来源和使用范围，确认以后，再落实到可执行、可维护的语义模型中。

FDE 要为 Agent 上岗兜底，首先就体现在这些地方：把企业私域环境接通，把专业建模做好，把客户确认的业务含义落实为可靠的工程能力。

冷启动时，FDE 负责处理标准产品尚未覆盖的连接与解析需求，指导语义建模，并与客户共同完成 Skills、知识库和典型任务的初始化。陪跑时，通过真实任务检查：连接是否稳定，模型能否支持实际分析，业务定义与计算结果是否一致。持续运行以后，还要跟进源系统、数据结构和业务模型的变化，维护相应的连接器、解析器、语义及知识，避免环境已经变化，Agent 仍沿用旧的工作依据。

因此，FDE 的价值，是把标准化产品带进非标准的企业环境，让 Agent 的通用能力在这里真正发挥作用。能够由 Agent 自动探查、学习和适应的，交给 Agent；需要工程建设、专家判断和客户共同确认的，由 FDE 承接，并尽可能沉淀为后续可以复用的产品能力。

在这样的交付方式下，客户与厂商形成的是一项持续的能力与服务合作。企业采购厂商的本体语义平台及配套的工具与连接能力，由 FDE 与客户共同完成环境适配、上下文初始化和后续维护；Agent 则作为厂商派驻到客户现场的数字员工，承担约定的分析职责。厂商负责它的岗前能力准备、在岗适配和持续支持。

相应地，商业模式也可以用岗位和交付来理解：平台与 FDE 服务提供工作基础，Agent 的持续可用能力对应“岗位工资”，按任务完成量和约定质量标准计量的使用部分对应“绩效工资”。

这样的分工继续发展，也可能改变企业配置人才和能力的方式。过去，需要一项长期能力，企业通常先考虑设置岗位、招聘员工；未来，对于目标明确、交付可以检验的任务，企业有机会直接获得由 Agent 和 FDE 共同提供的能力。

在一些已经验证、边界清楚的任务中，人的位置也可能逐渐从 Human in the loop 走向 Human on the loop。

未来的企业，会越来越围绕目标来设置和优化组织资源，企业未来越来越需要的是对业务结果负责的人。未来组织能力强不强，将越来越体现在：能否定义值得解决的问题，找到合适的数字员工，并判断它们交付的结果是否真正推动了业务。