让数字员工和团队一起工作：我们对企业级 Agent的实践与思考
过去一年，智能体（Agent）从「能回答问题」走到了「能完成任务」。但在企业里真正落地时，我们越来越清楚地看到：企业并不缺一个能干活的 AI，缺的是一个能被放心交付工作的 AI。
本文结合近期两篇值得关注的观点——一位企业智能体研究者对落地场景的分析，以及 DeepSeek Harness 团队发布的《Super-agent 设计探索》——梳理我们在「事半 AI 数字员工」上的设计取舍、已经做到的部分，以及仍在解决的问题。
一、企业要的不是「能不能干活」
有业内研究者将企业中的智能体需求分为三类：
- 个人办公：目前基本满足，但需要安全备份，且重要资料不能上传到云端；
- 团队协同：目前还不成熟；
- 替代原有 ERP、CRM 等系统：还远远不够，除少数大厂与 Palantir 一类技术路线外，大多存在很高的不确定性。
他进一步指出，企业追求的是五件事：不能泄密、可追溯、可审计、出了问题有人负责、每一步都是白盒。此外，让 AI 将企业老系统中的数据逐一对齐、语义对上、关系理清，也是一件极难的事。
这一判断与我们的观察高度一致。我们的定位因此很明确：
不替代企业现有系统，而是在其之上提供一层「可审批、可追溯」的执行层。
数字员工负责执行——外呼、加微信、跟进、整理名单、排查问题；企业的人负责决策与验收。每一项工作都要能回答：谁做的、依据什么、谁批准的、结果如何。
二、把 AI 做成「员工」，而不是「会话」
DeepSeek Harness 团队在文章中指出一个关键问题：主流智能体仍以「单次会话」为基本单位，不同会话彼此独立。一个人通常只能同时跟进 3 到 5 个活跃会话——单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
他们的结论是：会话应当是系统的实现细节，而不应是用户的认知负担。
我们在产品层面得出了相同的结论，并选择了一个更贴近企业组织的表达方式：数字员工是企业的正式成员。
- 数字员工在「员工」中与真人成员并列，有姓名、岗位、所属部门和上级；
- 企业从官方岗位模板中「招聘」数字员工，按月计薪；
- 每位数字员工有自己的专属项目、工作记忆和微信账号；
- 老板不需要管理会话，只需要像对待同事一样，在群里点名、交代、验收。
目前事半 AI 内部运行着一支由数字员工组成的团队：
| 员工 | 岗位 | 职责 |
|---|---|---|
| 老周 | 项目经理 | 主持会议，跟进客户项目的交付与进度 |
| 花花 | 客户经理 | 微信接待、报价咨询、意向线索承接；群内查询数据、调整配置 |
| 阿修 | 研发管家 | 派发并处理研发工单，监控系统运行与话术配置 |
| 大永 | 销售主管 | 名单、外呼获客与转化盯盘，制定拨打计划 |
| 八角 | 线索专员 | 按条件采集名单并验货 |
一次简单的「自我介绍」会议：负责人发起议题，主持人开场，员工依次说明职能，不在群里的同事由花花代为介绍，最后由主持人收尾。
三、一次真实的会议：讨论 → 拍板 → 纪要 → 分头执行
单个智能体完成单个任务已不稀奇。真正困难的是多个智能体围绕同一件事协作，并且在人类随时插话纠偏时保持方向一致。
下面是事半 AI 数字员工群的一次真实会议。负责人在群里提出：将一个新手引导项目改造为面向商贸批发企业老板的获客场景。
这次会议中有几个值得注意的细节：
- 负责人用自然语言发起讨论，「大家一起看看」即可被识别为开会，无需特定指令；
- 主持人点明议题，默认由项目经理老周主持，控制发言顺序；
- 负责人随时插话纠偏，讨论随即转向新方向，员工按纠偏调整观点，每次只表达一个观点；
- 员工之间互相 @、交换意见，有分歧当场说开；例如销售主管认为负载很轻可以照常开拨，研发管家则承诺「线路没问题就不推迟，有状况立刻群里告知」；
- 主持人归纳共识，排期与分工逐步收拢；
- 方案成形后先请负责人拍板，再输出会议纪要——结论加分工，每一项写明由谁负责；
- 负责人确认后，各自执行。
会议结束后，系统还会继续承担几件事：
- 承诺到点提醒：会上说「明早 9:15 前给准信」，到点未完成会自动提醒；
- 同事之间转交：会上 @ 某位同事的事项，会转交到对方的待办中；
- 跨天不遗忘：纪要与未完成事项写入每位员工的工作记忆，下次开会主持人会先过一遍上次没做完的事。
这正是那位研究者所说的「团队协同目前还不成熟」的部分。我们的体会是：协同的难点不在于让多个 AI 说话，而在于让它们说得少、说得准，并且始终围绕人的决策推进。
四、与 Super-agent 架构的对照
DeepSeek Harness 团队将「持续在线、事件驱动」的智能体称为 Super-agent，并提出四个基础特征：连续、高效、主动、持久。以下是我们的实践与之对照。
1. 事件驱动与两级过滤：主动，但保持安静
文章指出，真实的群聊与业务平台呈现「高噪音、低触发率」的特征，应当先用确定性规则过滤（Fast Path），再交给模型做语义判断（Slow Path）。
我们在数字员工群中采用了几乎相同的结构：
- 程序层：是否被 @、是否被直接叫名字（包括语音消息）、是否在跟进窗口内、是否处于夜间静默时段、是否已由真人接管——这些都由代码直接判断；
- 语义层：通过程序层的消息交给模型判断是否需要回应；模型判断无需回应时输出静默标记，不发送任何内容；
- 群内少说话：纯客套不回应，被明确要求闭嘴后保持静默直至再次被点名。
主动与安静并不矛盾。项目经理老周会按项目的真实进度主动跟进；销售主管大永每小时巡检一次，发现异常自动暂停相关项目——主动的前提是有明确的触发条件，而不是什么都想插一句。
2. 后台先做，确认后交付
文章借用了「投机执行」的概念：在不确定结果是否会被采用时，先在后台尝试，有价值就交付，没有价值就丢弃。
这在我们的系统中是一个反复出现的模式：
- 老周的跟进计划先以「待审批」形式生成，负责人采纳后才执行；
- 阿修处理工单时先在后台修改话术并用客户原声试跑，负责人同意后才应用到线上；
- 花花采集线索时先出采集计划，与负责人确认后才执行，采集完成后自动导入并开始拨打；
- 八角出名单时先给方案，客户确认后采集，验货不合格则停止该批次并重新采集。
**后台尽可能多做，对外每一步都要有人确认。**这是我们在「主动」与「可控」之间找到的平衡点。
3. 计算、状态与执行环境分离
文章建议将智能体的推理放在云端无状态容器中，会话状态存入数据库，执行环境留在原地，通过端侧轻量进程按需访问。
在我们的系统中：
- 后端服务与语音智能体均为无状态容器，会话、记忆与任务状态存于数据库与缓存，容器可随时重启或替换；
- 个人微信账号支持通过企业本地节点登录，账号所在的网络环境留在企业侧；
- 研发管家阿修的执行进程运行在研发人员自己的机器上，由系统服务托管，异常退出后自动恢复。
4. Watchdog：独立于主系统的巡检
文章强调，长期运行的系统需要一个独立的外部控制回路，既监控基础设施，也监控任务本身的进展。
我们设有一名专职巡检的数字员工——检修师 SH，负责巡检各数字员工、微信账号、通话线路与研发执行进程的运行状态，发现异常通过客户经理向负责人报告。
五、企业关心的五件事，我们如何回答
回到第一部分提出的五项要求。
1. 不能泄密
- 不以客户名义擅自发言：系统不会在客户不知情的情况下，用客户的企业微信或个人微信账号发送消息；
- 密钥不外露：工具配置中的密钥在读取时一律脱敏显示，保存时沿用原值；
- 审批消息不带原文：研发审批消息只包含编号与用途，不包含命令或代码原文；
- 数据按企业隔离：群、项目、渠道账号均归属于具体企业，数字员工只能访问其所属企业与项目的数据。
2. 可追溯
- 关键操作写入审计记录，包括操作人、对象、变更前后的值；
- 通过数字员工修改话术会保留版本，可以找回修改前的内容；
- 加微信失败、推送失败均有记录与原因说明。
3. 可审计：操作分级审批
研发管家阿修的权限按风险分级：
- 低风险操作（只读查询、查看日志、起草方案）：同一工单内审批一次后放行，并每 10 分钟汇总同步一次，避免频繁打扰；
- 高风险操作（写数据库、重启服务、部署、执行脚本）：每一次都需要负责人审批。
4. 出了问题有人负责
每位数字员工都有上级，在工作日定时向上级或群内提交日报。自动化处置——例如巡检发现故障自动暂停项目、微信账号连续失败触发熔断——都要求在网页上可以查看、有人知道如何处理、有明确的处理状态。
5. 每一步都是白盒
这是我们目前做得最不充分的一项，也是下一阶段的重点，详见下文。
六、尚未解决的问题
坦率地说，以下几个问题我们还没有完全解决：
**1. 统一的任务对象。**目前会上的承诺、同事间的转交、研发工单、项目经理的跟进事项分别存放在不同位置。我们计划为每一项交给数字员工的工作建立统一的任务编号，记录来源、负责人、状态、关联对象与审批记录，并在网页上提供「进行中的任务」看板。这既对应 Super-agent 文章中的 Thread 订阅机制，也是实现「可追溯、有人负责、白盒」的基础。
**2. 跨渠道的连续性。**老板在群里、私聊和网页中提到的同一件事，目前主要依靠工作记忆关联。有了统一任务编号后，任一渠道的后续消息都可以直接归入对应任务，交由负责的员工处理。
**3. 决策过程的可解释性。**客户最常问的是「为什么」：为什么判定为这个意向、为什么没有拨打、为什么项目暂停了。这些信息目前多数只存在于系统日志中，我们计划将其呈现在每一通电话、每一个会话与每一个项目的详情中。
**4. 外部输入的安全边界。**数字员工直接面对客户消息，必须防范提示词注入。我们的原则是：接待客户的会话不具备管理权限，有副作用的操作必须经过负责人审批；凭据由系统代为使用，不进入模型上下文。我们正在将这些原则从权限校验进一步落实为会话层面的隔离。
**5. 与老系统的数据对齐。**对接企业 CRM 与多维表格时，字段映射错误往往是静默发生的。我们计划在配置推送时提供「试推送预览」，并让推送失败在网页上可见、可重推；在导入数据时由模型给出字段映射建议与置信度，低置信度的映射交由人工确认。
七、从招聘到上岗：一位数字员工的完整开通
数字员工的入职不是填一个配置表，而是一套完整的岗位授权流程——从选择岗位模板、配备技能，到接入通信渠道、分配业务，逐步完成。
1. 选择岗位与招聘
企业从官方岗位模板中选择需要的角色。每个岗位模板定义了员工的基础职责描述与话术框架，同一岗位可以招聘多名，分别负责不同项目。
招聘时需要确认三件事：员工名称（企业内部如何称呼）、初始分配的项目（也可暂不分配，之后再安排）、以及月薪确认。招聘完成后，系统自动为该员工创建专属项目，并加载岗位模板中预置的话术与工作流配置。
2. 开通技能
每位数字员工可以同时具备多项技能。技能决定了员工通过什么渠道与客户沟通，目前已支持的渠道包括：
电话渠道
- 外呼：主动拨打电话，用于获客、回访、通知等场景；需要配置外呼线路与并发数量。
- 呼入：接听来电，用于客服热线、预约确认等场景；需要分配呼入号码。
即时通讯渠道
- 个人微信：通过个人微信账号添加客户、私聊跟进、群内接待。
- 企业微信：通过企业微信账号开展客户沟通与服务。
- 微信公众号：在公众号中接待咨询，适用于客服与产品答疑场景。
- 微信群：在客户群中接待、跟进、协作。
- 飞书 / 钉钉：对接企业内部 IM，适用于内部协同与跨系统通知。
技能组合取决于岗位需要。一位电话销售员工可能只有「外呼」技能；一位客户经理可能同时具备「外呼」与「个人微信」，外呼结束后自动发起微信跟进；一位公众号客服则只需接入公众号渠道。首页员工卡片会以技能标签的形式展示每位员工已开通的能力，尚未配置完成的技能以醒目标记提示。
3. 配置通信渠道
技能确定后，进入具体渠道的配置。不同渠道的配置内容各有侧重：
电话渠道：为具备外呼或呼入技能的员工配置通话参数——外呼线路（可多条）、单线路并发上限、呼叫间隔、响铃时长与最大通话时长。这些参数按员工独立配置，同一项目中不同员工可以使用不同线路、不同并发策略。员工卡片右上角会显示该员工绑定的外呼线路名称与并发数、呼入号码等关键信息。
个人微信 / 企业微信：需要绑定账号。系统提供开通向导：
- 选号或扫码：从企业渠道账号池中选用空闲账号，或在向导中直接扫码登录新账号；绑定后员工专属项目自动同步使用该账号；
- 接入业务：可选择将该员工的账号接入企业其他业务项目的对应环节，由该员工负责客户沟通；
- 验证接待：添加该微信为好友并发送消息，确认员工能够正常接待与回复。
个人微信账号的安全防护同步生效：每个账号每天最多添加 30 位好友，两次添加之间间隔 1 至 3 分钟；账号掉线即停止一切添加操作，连续失败则自动熔断 6 小时。
公众号 / 微信群 / 飞书 / 钉钉：通过平台对接相应的消息通道。公众号需完成授权接入；微信群在关联项目后自动生效；飞书与钉钉通过企业应用配置接入。接入后，数字员工即可在对应渠道中接收消息、回复咨询、执行工具调用，与电话和私聊渠道共享同一套话术与工具体系。
4. 分配业务与上岗
配置完成后，员工即可在分配的项目中开始工作。对于尚未完成全部配置的员工，首页员工卡片、员工列表与体验页面均会显示「继续配置」入口；业务项目中尚未指定账号的环节，也支持就地选号或扫码完成绑定，无需回到员工管理页面。
整套流程的设计目标是：企业不需要理解底层的线路、账号、并发等技术概念，只需要像招聘真人一样——选岗位、起名字、开通技能、配好工具、安排上岗。
结语
DeepSeek Harness 团队在文章结尾写道：随着大模型执行单个任务越来越少需要人工干预，限制生产力提升的瓶颈正在转向人的注意力。
我们同意这一判断，并想补充一点：在企业中，比注意力更稀缺的是信任。
让数字员工持续在线、主动推进、并行处理，解决的是注意力问题；让每一步可追溯、可审计、有人负责、过程透明，解决的是信任问题。只有两者同时成立，企业才会真正把工作交给 AI。
这也是事半 AI 数字员工接下来的方向：不追求替代企业的系统与人，而是成为一支可以被放心交付工作的团队。
参考：
- DeepSeek Harness 团队，《Super-agent 设计探索：迈向更自主的 Agent 系统》
- 文中群聊截图来自事半 AI 数字员工群的真实对话，涉及客户的信息已做模糊处理。