选 Agent 还是数字员工？一张封装判据表，从技术要件到岗位边界逐项对齐
选型会上最常见的僵局，是双方在同一个词上各说各话。甲方说要"上 Agent"，乙方说要"配 AI 数字员工"，报价差一个量级，会开完了才发现，两边说的压根不是同一件事。
这份东西当一组对照表用：逐项拿自己的需求去比，比完了，该买哪一类、该套多重的封装，答案会自己浮出来。
一句话先给核心：Agent 是能力本身，AI 数字员工是把它装进岗位外壳之后的产物。 前者交出结果，后者在结果之上再补身份、权限与管理归属。下面从技术要件起，逐层往下对。
一、先给识别判据：三条就够
拿这三条去比一比，供应商卖的是哪一类基本就清楚了。这三条的用途是识别，不牵涉"该不该买"。
| 判据 | 指向 Agent | 指向数字员工 |
|---|---|---|
| 立项单位 | 以任务立项 | 以岗位立项 |
| 交付物 | 一个能跑的功能 | 一个能挂进组织架构的角色 |
| 考核对象 | 任务成功率 | 岗位 KPI |
三条之外，还有一个更快的问法：你交的是零件，还是整机？ 这个问题得到的答案，通常比产品说明书诚实。
二、要件速查：五条对四条
两层的要件并排放在一起。左边五条解决"能不能干活"，右边四条解决"这层干活的能力挂在谁的岗上"。
| Agent 五要件（能力层） | 数字员工四要件（岗位层） |
|---|---|
| 推理：没写死分支也能做判断 | 职责映射：组织架构里指得出位置 |
| 工具调用：能读库、发信、调接口、写回单据 | 任务流稳定：有触发条件、交付物、完成标准 |
| 记忆与上下文：跨轮次跨会话留住前情 | 权限与数据边界：能看什么、能批多大 |
| 任务规划：把目标自己拆成多步并排序 | 兜底与考核口径：有复核人、有复核频次 |
| 反馈闭环：失败会重试或换策略 | --- |
一句提醒：Agent 那五条一条都不能少。 市面上不少产品只占两三条，最典型的是"推理加工具调用"，既没有跨会话记忆，也没有任务规划。它更准确的名称是"带工具调用的对话助手"，验收线与交付周期都该按对话助手那一档来算，而不是 Agent 那一档。
三、Agent 五要件：逐项给合格与不合格信号
排障和验收都能用的一组对照。任意一项停在不合格信号上，这个系统就不是完整的 Agent。
| 要件 | 合格信号 | 不合格信号 |
|---|---|---|
| 推理 | 换问法、换数据仍能给出合理回应 | 只认固定关键词，其余走分支 |
| 工具调用 | 能读库、发信、调接口、写回单据 | 只吐出一段文字等人复制 |
| 记忆与上下文 | 前情不必重讲 | 每轮对话都从零开始 |
| 任务规划 | 目标能自己拆成多步并排序 | 一次只肯走一步 |
| 反馈闭环 | 失败会自行重试或换路 | 报错即抛，没有备用路径 |
四、数字员工四要件：逐项给合格与不合格信号
同样的对照方式，换成岗位层的四条。这里最容易被"顺手省掉"的，是第三第四两条：它们的缺失不会在演示阶段显形，只会在上线之后以事故或"没人管"的形式露出来。
| 要件 | 合格信号 | 不合格信号 |
|---|---|---|
| 职责映射 | 组织架构里指得出它挂哪 | 指不出，还是件工具 |
| 任务流稳定 | 每天固定要走完几件事 | 想起来才用一下 |
| 权限与数据边界 | 权限随岗位走 | 所有人共用一把超级钥匙 |
| 兜底与考核口径 | 有写明的复核人与频次 | 没人对结果负责，知识慢慢烂掉 |
五、两个高频混淆点
混淆点一：数字员工这个叫法，RPA 厂商已经用了很多年。 要件摆完之后，难免会冒出一个问题：早几年采购回来的那批，该算到哪一边？分界在执行依据上：RPA 类跑的是预先录制的固定脚本，输入一旦出界就停下等人，界面改版、字段挪位就得重录；以 Agent 打底的数字员工，碰到脚本没覆盖的变体也能自行判断下一步。两者谈不上取代关系：流程固定、不许自由发挥的活，固定脚本反而更稳；输入形态多变、规则写不全的活，才需要底下垫 Agent。
| 对比项 | RPA 类数字员工 | 以 Agent 打底的数字员工 |
|---|---|---|
| 怎么跑 | 照着录好的脚本走 | 靠推理加工具调用 |
| 遇到规则外的输入 | 停住，等人接手 | 能在变体里自己拿主意 |
| 界面一改版 | 得重新录一遍 | 大多能跟得上 |
| 出错时 | 直接中断 | 可以重试或改走别的路 |
| 适合什么活 | 极其确定、重复极高 | 大体确定、允许变体 |
混淆点二：数字员工不等于带虚拟形象的数字人。 形象只是可选的对外门面，算不上核心要件。很多 To B 场景压根没有虚拟形象，它在系统里就是一个挂在岗位上的角色，带着职责、权限和责任人，仍然是完整的。判断的尺子始终是"它对应组织里的哪个岗位"，不是"它长不长一张脸"。 把形象当成要件，只会把预算推高，能力一点不涨。
六、五维对照表
要件之外，再从五个维度横着扫一遍，两类的差别会更直观。
| 维度 | Agent | AI 数字员工 |
|---|---|---|
| 定位 | 单点任务层面的能力 | 组织里的一个岗位角色 |
| 主要本领 | 把一件或一串任务做完 | 在任务之上管编排、管权限、管身份 |
| 适合的活 | 边界清楚、容错还行的确定任务 | 高频、跨环节、且要对外有一个统一身份 |
| 周期量级 | 一般几周 | 一般几个月，跨岗协同按季度算 |
| 改动成本 | 低，随时拆换 | 偏高，剥一次封装代价不小 |
七、从哪儿下手：两层坐标与四类落地区域
"先切哪一块"这件事，我们内部用一套叫「2×4 产业AI模型」的东西来理。先交代它的来路：这是内部自用的场景梳理框架，不是行业标准，也不给任何产品站台。 用法两步走：先挑场景，挑完了，再回头用第一节那三条判据决定套哪一层封装。
它由两条主线加四类场景组成，但这是上下两层，不是相乘的格子：
| 层 | 内容 | 回答什么 |
|---|---|---|
| 价值层（上） | 两条主线：业务提效 / 内容获客 | 为什么做。对内落到降本、提质、控风险；对外落到拉新、转化、增长 |
| 场景层（下） | 四类场景：办公协同 / 知识运营 / 业务流程 / 营销获客 | 从哪儿下手 |
归属上：办公协同、知识运营、业务流程 归在 业务提效 下面；营销获客 归在 内容获客 下面。顺手答个疑问：营销获客既出现在主线里，又出现在场景里，算不算重复？不算。四类里只有它是直接对外的，所以它天生兼着两个身份，既是价值去向，也是落地入口；另外三类都在企业内部跑，价值上统一归到业务提效。别拿这套模型当格子去对号，主线回答钱打哪儿省、打哪儿来，场景回答第一步往哪儿落。
这四类按落地难度排序，而非按重要性。企业真正该问的不是"哪一类更重要"，而是"我这里眼下能上哪一类"：
| 落地区域 | 能承接的 | 与数字员工的分工 | 落地前提 | 接不住的 |
|---|---|---|---|---|
| 办公协同 | 会一散就出纪要与待办、邮件按主题分批、日程自动撮合、文档起稿、周报汇总 | 前者是各管一段的散件；后者把这些收拢成一个整体，独立扛下行政岗全流程，自带审批权与固定对接方 | 会议与文档模板是否统一；谁能看哪些日程、谁的会优先；日历邮箱文档系统开不开读写；谁复核谁签字 | 跨部门争资源这类要博弈的事；评价标准本身不统一的工作 |
| 知识运营 | 资料按主题归位并标版本、高频提问做成问答对、政策按对象拆读、标书初稿带缺口、离职调岗材料重标责任人 | 前者管"答得出来"；后者管"谁有资格问、答错谁改、多久复核一轮" | 资料总量、多少版本互相冲突、谁来裁定有效版本；权限分层能否落到人；更新有没有触发机制；谁对准确率负责 | 本就没有唯一答案的争议内容；要承担法律责任的表述 |
| 业务流程 | 报销单按规则预审圈出不合规、合同条款比对提风险、订单异常分流、工单派发催办、审批流前置检查 | 前者做单点判断；后者管这一步的权限额度、谁批、留痕给谁。同一张单，前者判合规，后者定放行 | 哪些系统已开接口、稳不稳、有没有测试环境；业务规则写没写下来；额度上限与越权升级路径；出错谁改单 | 要人拍板的例外审批；法律与合规的最终判定 |
| 营销获客 | 按热点场景误区起选题、按平台改多版本、咨询留言归线索、线索打标派单、跟进提醒与话术备料 | 前者是内容生产工具；后者管账号归谁、能不能发、线索记谁头上、对外怎么说 | 有没有内容资产（老文、案例、话术库）；线索合格标准写没写；跟进规则谁定；最终话术谁负责 | 得当场拿捏的客户谈判；品牌调性的统一把关；舆情处置；平台规则随时改 |
其中知识运营这一块，补一句和知识库类项目的接口：底下的能力很多基于检索增强生成技术，但那只是 Agent 的一个能力组件。相较而言，Agent 还额外带着任务规划、工具调用与反馈闭环，能主动去做归档、拆解、生成，不止于被动答疑。 所以选了知识运营，接下来要问的不是"用不用检索增强生成"，而是这块要不要往岗位级封装走。
八、为什么五条一条都不能少：长链路的可靠度是乘出来的
补一段因果，说清第三节那五条为何不算"锦上添花"。
一个任务拆出的步骤越多，每步自带的出错概率就叠一次，链路整体的成功率跌得越快。三步各按九成把握算，乘完只剩七成多。任务规划与反馈闭环放在最后两条，并非功能清单上的两个可选项，而是给长链路兜底的两道机制。 规划管的是步数能不能压缩、路径能不能缩短；闭环管的是某一步失手后能不能当场补回来。没有规划，步骤乱成一盘散沙；没有闭环，一处失手就全线崩。
这条因果也说明另一个反复见到的现象：链路拉得越长，越要在某个节点安排一个人把关。 后面四类区域里"接不住的"那一栏，几乎都指向同一点，得由人兜的判断与担责。这不是模型不行，是长链路的可靠度结构决定的。把它当成设计约束、而不是当成缺陷去修，选型时的预期才摆得正。
九、决策判据双栏表：判断该不该升级为岗位封装
先把两组判据的分工讲清。 第一节那三条管识别 ，看供应商卖的是哪一类；本节这六条管决策，看自己该买哪一种。分组不同、用途不同，两者不重叠。
还有一句得先摆平：二者之间并不存在一条硬界线，从"工具"到"岗位"是连续过渡的一段。 现实里两头不靠的形态相当多，比如那些已经带了些许权限的 Agent，或者只管单个环节的数字员工。遇到这类，别去纠结"它算不算数字员工"，还是回到那句老问题：立项按哪个单位走、验收按哪把尺子量。 以任务来验收，功能再全也仍是 Agent；以岗位 KPI 来验收，哪怕只承担了一小块职责，也已经具备数字员工的雏形。
| 看什么 | 偏向 Agent | 偏向数字员工 |
|---|---|---|
| 任务频次 | 偶尔做一次 | 每天都要跑 |
| 使用范围 | 一个人用 | 多个岗位接力 |
| 容错程度 | 错了代价小，改一下就好 | 错了得有人担责 |
| 是否允许无人兜底 | 可以 | 必须有复核机制 |
| 是否要统一对外身份 | 不需要 | 要有固定身份去对接 |
| 是否跨系统流转 | 单系统内就行 | 需要串起多个系统 |
补一条经验参考（经验值，不做统计依据 ）：六条里后三条只要中两条，就够资格考虑岗位封装；一条不中，先用 Agent 打。 若六条全不沾边，说明这事离"上工具"还远，先把流程捋顺。
顺带提醒：别拿它当"包得越重越保险"来读。岗位封装这一层的维护账是长期挂着的（成本一节会展开）。一件 Agent 就够收尾的活，犯不着提前包成岗位。包得越厚，日后要养的权限、责任人和复核机制就越多。
再看一种情形：拿五要件去市场上照一遍，发现看中的产品只中了两三条，还签不签？ 这是采购方最容易卡住的地方。答案是不用一票否掉，但要重新定价 ：只中两三条的，本来就不该拿完整 Agent 的价和预期去谈，而该归到"带工具调用的对话助手"里去谈，验收线、交付周期、责任边界一并往下挪一档。五要件既是过滤供应商的筛子，也是给产品定价的坐标。
十、四类误判排查表
照"症状、机制、对策、验收"四拍编排，可直接留作复盘时的逐条核对表。
| 误判 | 症状 | 机制 | 对策 | 验收 |
|---|---|---|---|---|
| 把"能演示"当"能上线" | 演示顺滑，接上真实数据第一周就错得离谱 | 演示样本是挑干净的；真实环境里脏数据、并发、权限冲突一样不少，还夹着没人交代过的历史特例 | 立项阶段就锁定验收数据集，专门挑真实数据里最脏的那批来跑 | 在真实环境里把同一批任务连着跑，成功率达标且失败项逐条留痕 |
| 按"买了几个 Agent"立项 | 进了十个，三个月后没人在用 | 按工具数量下单，没对到任何人的日常工作上，工具只管"能不能做"，不管"谁负责" | 先把岗位上的事列成清单，再倒推需要哪些能力 | 每个 Agent 都落在某岗位的真实任务上，使用人写明 |
| 只买工具，不定义职责 | 跑满三个月，答错无人过问，知识一点点过期 | 没有责任人就没人维护。知识型能力会随时间失效，接口会变、规则会改，没人跟进就输出过期答案 | 动手前先敲定两件事：归口由谁负责、隔多久复核一轮 | 更新记录与复核日志查得到，复核人写真实姓名 |
| 把数字员工当裁员工具 | 一提就抵触，不给真实数据、不提改进意见 | 人一旦觉得要被取代，第一反应是防守，防守的外在表现就是不配合 | 把张力摊开谈，用机制解决三件事：过渡期讲明、省出的时间怎么用讲清、优先补空缺岗 | 员工主动使用，并主动提改进点 |
第四类那处张力不该绕开：一边是管理层看着公开案例里的提效倍数、想优化人效，属理性预期；另一边是员工怕丢饭碗，同样是理性防御。两边的反应都合理，单靠"这是给大家加能力"一句解释，压不住。 落到机制上分三步走：先把过渡期划出来，讲明多长一段时间内不会因为上了这套而减员；再把省下来的时间怎么处理交代清楚，是转岗还是算绩效；能力优先补到空缺岗、长期人手紧张的环节，在岗的人头不动。 起步时仍然挑最枯燥的活去切（整纪要、对单据、归资料）。
十一、封装成本对照与收益口径
按采购口径可分三档，三档的费用项与周期并不一样。这里只谈费用项与周期跨度，不列具体数额。
| 档位 | 成本构成 | 周期 | 验收物 |
|---|---|---|---|
| 任务级（单个 Agent） | 选场景、写提示与流程、接接口、跑测试 | 一到三周 | 可运行的任务流程一份、测试用例一组 |
| 岗位级（数字员工） | 拆岗位任务、编排多个 Agent、设计权限体系、备知识与数据、试运行 | 一到三个月 | 岗位任务清单、权限矩阵、试运行报告各一份 |
| 跨岗协同 | 打通流程、统一数据口径、划分多岗责任、管变更 | 三到六个月 | 端到端流程、责任矩阵 |
最容易漏算的还是隐性成本，三项：
▸ 资料定版与授权的人力：同一份东西往往有好几个版本要先分清，访问权限也得一个个落到人头。这块耗掉的时间常比写代码还多。
▸ 兜底与复核的工时：上线不代表它消失，它只是换个形态长期挂账，从"自己动手"转成"定期抽检"。
▸ 更新与回归的开销：知识会陈旧、接口会换版、规则会调整，动一次就要再验一轮。
按过往经验，这三项凑起来通常要吃掉总预算的四到六成（经验值，非统计结论），绝不是"随手带一下"的量级。一份预算如果只有软件、服务器、开发人力这几行，基本可判为漏项，至少还得补上数据治理、抽样复核、更新回归。
花多少讲完了，还得回到赚多少，两边用同一把尺，账才平。省人力与增人力是两本账，算法完全不同。 砍掉一个环节的人手，对应的是支出减少；让同样的人多出活，对应的是产出增加。前者的锚点是省下来的工时，后者的锚点是新增的产量。两本账混在一起，得到的数一定靠不住。所以这一节的名字得说全：钱按什么单位花、收益按什么单位算，两件事是配套的。
十二、落地兜底：六个动作，做没做成看这两栏
方向定下来以后，真正卡人的地方大多在技术之外。下面六件事都能做成工程侧的兜底，做成与没做成各有明显的样子，别一股脑推给"管理问题"：
| 动作 | 做成的样子 | 没做成的样子 |
|---|---|---|
| 发起人 | 业务侧责任人牵头 | IT 或供应商牵头，业务不认账 |
| 切入点 | 沿难度轴从最有感的切，通常先办公协同 | 一上来就挑最难的区域 |
| 入口 | 塞进员工已在用的工具（企业微信、钉钉、邮箱） | 另开一个新入口，用两次就忘 |
| 责任人 | 归口人写进岗位职责 | 只写在项目文档里，无人长期管 |
| 基线 | 上线前已记下耗时、错误率、业务量 | 事后说不清有没有变好 |
| 兜底 | 写清什么情况转人工、转给谁 | 路径模糊，一线宁可不用 |
十三、选型自查清单
十二条列在下面，能一条条答"是"了再往下走。分四组摆开，对着找。
▸ 概念与立项
- 一边给能力、一边给岗位封装，你能一句话说清吗？
- 这轮按任务立，还是按岗位立？
- 验收数据集定了吗，含不含最脏的那批？
▸ 数据与权限
- 责任人能点到具体的人名吗？
- 权限边界划清了没有（可看什么、可批多大）？
- 数据在谁手上、全不全、归谁管？
▸ 系统与验收
- 接口齐不齐、稳不稳、有没有测试环境？
- 复核人是谁、多久复核一轮？
- 出错后往上升级的路径写了吗？
▸ 组织与预算
- 动手前的基线记下来了吗？
- 隐性成本（定版人力、复核工时、更新回归）算进预算了吗？
- 团队顾虑怎么解，是不是按"给人加能力"来定位？
十二条里若有超过三条答不上，这件事大概还没到能立项的火候。先把问题问到底，比系统上线后推倒重做要省得多。
十四、把边界收成一句话
▸ 一件事、要快、要能塞进现有系统 → Agent 。 ▸ 一整个岗位、要统一身份权限、要对外给标准服务 → AI 数字员工。
补个等式便于记：数字员工 = 多个 Agent 叠加 + 岗位权限体系 + 工作流编排 + 身份形象（形象可选）。
绕回开头那组报价。两家差的这个量级，落在封装层上，拆开是三项：
▸ 治理：权限配给谁、动作留不留痕、出错由谁翻查。
▸ 编排：多个 Agent 接成一条流水线，中途断档了由谁来续上。
▸ 形象：纯装饰性的外壳，不值得为它花大头。
这三项问完，价差的来源、值不值得，心里就有底了。见面时还有三句可以直接问过去：按哪个单位验收、到底交什么、最后考核谁。
把四类区域里"接不住的"摞到一起，指向的是同一个点：得由人来兜的判断与担责。这是结构决定的，跟模型强弱无关。所以数字员工还能给一个更狠的说法：它不是"顶替某个岗位"，而是把该岗位上能写成规则的部分切出来封装，剩下要判断、要担责的仍归人。 它交出去的也从来不是"一名员工"，而是一张岗位任务拆分表：哪块给它、哪块给人、线划在哪。
如果你正处在选型或立项的起点，先别急着挑产品，把下面三件最小的事办掉：把岗位上的高频任务列出来，圈三件最重复、最没人乐意碰的；把该事项的业务负责人找出来，确认他愿意为结果负责；把眼下这几件事的处理时长和出错率记下来，当作基线。三件做完，再来谈选 Agent 还是数字员工，基本就不会走偏。名字叫什么其实不打紧，第一步都不是挑工具，而是先诊断，再落地：先把岗位任务拆细，再把数据与权限理清，最后才决定套哪一层封装。
唐欢（弯弯）｜企业AI落地顾问
让企业把 AI 真正用到业务里
弯弯的产业AI实战