企业官网建设流程全解析

Agent 与 AI 数字员工怎么分：五个技术要件、四个岗位要件与一套选型判据

技术评审里有一类反复出现的分歧：需求方说要"上一个 Agent"，供应商说要"配一个 AI 数字员工"。两句话听着差不多，报价却能拉开一个量级。真正的问题不在谁在抬价，而在这件事被按什么单位立项、按什么单位验收。

结论不复杂：Agent 是一种能力单元，AI 数字员工是把这种能力单元包装成岗位的产品形态。二者不是两个平行的品类，而是同一套底层能力的两层封装。底下那层只负责把活干完；上面那层额外挂上身份、权限和管理归属，回答"这能力归谁管、能碰哪些数据、出问题谁兜"。

下面按评审顺序展开：先拆两个概念的构成要件（Agent 五条、数字员工四条），再给能当场验证的识别判据与决策判据，然后把四类落地区域的边界与前提逐类对齐，最后给成本构成、误判排查和一份可勾选清单。判断尽量落在"能否验证"上，不写无法复核的效果承诺。

一、Agent 的五个技术要件

给定一个系统，判断它够不够叫 Agent，看五条能否同时成立。

推理能力。它得在没有预先写死分支的前提下做判断。检验办法是换个说法、换组数据再问一遍，看它还答不答得上来。只能匹配固定关键词、再走对应分支的，属于规则脚本。

工具调用。它得能真正触动外部系统。检验办法是看它读不读数据库、发不发邮件、调不调接口、写不写回单据；如果只会产出一段文字等人来复制，那它是对话助手。

记忆与上下文。它得跨轮次、跨会话记住前情。检验办法是昨天讲过的前提，今天还要不要再讲一遍。每次从零开始的，是无状态问答。

任务规划。给一个目标，它得自己拆成若干步并排序。检验办法是让它整理本季度投诉、再按类归档，看它会不会先反问按哪几类分。只会一步一动的，是单点功能。

反馈闭环。执行失败之后，它得能自行重试或换策略。检验办法是接口报错时它把异常抛回来，还是先试备用路径。缺这一环的，是脆弱脚本。

五条之间是有依赖的，不是并列清单。推理和工具调用管"能不能干活"，记忆管"能不能连着干活"，规划和闭环管"长任务里会不会半路断掉"。所以后两条分量最重，下面单独一节说因果。

市面不少自称 Agent 的产品实际只有两三条，最常见的是"推理加工具调用"这一组，跨会话记忆没有，任务规划也没有。这类东西准确的归类是"带工具调用的对话助手"，它对应的验收口径与交付周期，也该按对话助手算。

二、数字员工的四个岗位要件

数字员工是上面那层封装。拆开就是：若干个 Agent，加上工作流、权限体系与身份。它是否完整，看四条。

职责映射。要能说清它挂在谁的岗、向谁汇报、交付什么。检验办法是能不能在组织架构里指出它的位置。指不出来的，说明它到现在还是工具，只换了称呼。

任务流稳定。要有触发条件、交付物和完成标准。检验办法是它偶尔用一下，还是每天固定有几件事必须走完。只是偶尔用的，本来犯不上做岗位封装。

权限与数据边界。要能说清它看得到哪些数据、改得动哪些记录、批得了多大额度。检验办法是它的权限按岗位配，还是所有人共用一把超级钥匙。后者等同于把越权风险预埋进系统。

兜底与考核口径。要能说清谁为结果负责、怎样算达标。检验办法是有没有写明复核人和复核频次。缺失的话，它就是一件没人认领的工具。

四条里最容易被省掉的，恰好是第三条和第四条。去掉权限体系，它退化成一个权限过大的脚本；去掉兜底口径，它退化成一个无人打理的摆设。这两条的缺失有个共同点：演示阶段看不出来，只在上线之后以事故或"没人管"的形式冒出来。

三、和 RPA 类数字员工的分界

"数字员工"这个说法，RPA 厂商卖了很多年，市场上数量最多的一类正出自这条线。所以看完要件，很自然会追问：早几年买的那种，按这套标准如何归类？

分界落在执行依据上：RPA 类数字员工跑的是预先录制的固定脚本，输入一旦出了规则范围就停住等人接手；以 Agent 打底的数字员工，遇到脚本没覆盖的变体能自己判断下一步。前者的典型动作是"照着流程表一个个点按钮"，界面改版、字段挪位就得重录；后者在输入形态变化时，能自行选路。

两条路线谈不上谁取代谁。流程固定、不许自由发挥的场景，固定脚本更稳；输入形态多变、规则写不全的场景，才需要底下垫 Agent。

四、形象是可选项

有个偏差必须在技术层面说破：数字员工不等于带虚拟形象的数字人。

形象属于可选的对外外壳，与要件成立与否无关。大量 To B 场景里的数字员工没有任何虚拟形象，它在系统里就是一个带职责、带权限、带责任人的岗位角色，这已经完整。尺子始终是"它对应组织里的哪个岗位"，而不是"它长不长一张人脸"。把形象误当要件，只会抬高预算，能力一点不涨。

五、三条识别判据，加一张五维对照

想少记一点，就记这三条。用途是识别：拿它一晃，就知道供应商卖的是哪一边。

▸看立项单位：按任务立项归 Agent，按岗位立项归数字员工。 ▸看交付物：交一条能跑的功能归 Agent，交一个能挂进组织架构的角色归数字员工。 ▸看考核对象：考任务成功率归 Agent，考岗位 KPI 归数字员工。

再配一张五维表，横向是维度，纵向是两类：

六、「2×4」是上下两层，不是相乘的格子

“该从哪个场景切进去”，我们内部用一套叫「2×4 产业AI模型」的东西来梳理。先把身份讲明：这套框架是我们自用的场景梳理工具，不属于行业标准，也不为任何产品站台。它分两步用：第一步挑场景，挑完之后，再回头用上一节那三条判据决定封装到哪一层。

它有两条主线和四类场景，但这两个数字是上下叠着的，并非相乘。

▸上层是价值层，两条主线，回答"为什么做"：面向企业内部的是业务提效，落在降本、提质、控风险上；面向市场的是内容获客，落在拉新、转化、增长上。 ▸下层是场景层，四类场景，回答"从哪儿下手"：办公协同、知识运营、业务流程归在业务提效这条线下面；营销获客归在内容获客这条线下面。

顺手答一个疑问：营销获客既在主线上出现，又在场景里出现，算重复吗？不算。四类场景中只有它直接对外，所以它天生身兼两职，既是价值的去向，也是落地的入口；另外三类都在企业内部运转，价值上一律归到业务提效。用这套模型时别拿它当格子去对号，主线回答钱从哪省、从哪来，场景回答第一步从哪迈。

七、四类落地区域：能接什么，封装到哪一层

四类按落地难度排，不按重要性排。企业真正要回答的不是"哪类重要"，而是"我这里现在能上哪类"。顺序是：办公协同 → 知识运营 → 业务流程 → 营销获客。每一类下面都说清四件事：能接的活、和数字员工差在哪、落地前提、接不住的。

① 办公协同：见效最快的一类

这一类动的是人的日常动作，会议、邮件、日程、文档都算在内。能接的活大致有：会一散就出纪要与待办、邮件按主题分批、跨部门日程自动撮合、文档初稿起个框、周报数字自动汇集。

落到形态上，Agent 侧就是一批各管一段的小工具，用哪件取哪件；数字员工侧对应"行政助理数字员工"，它把这些小工具收拢成一个整体，完整接过行政岗的流程，自带审批权限、有固定对接的人。要落地，前提有四条：会议与文档有没有统一模板；谁能看哪些日程、谁的会优先；日历、邮箱、文档系统是否开放读写；谁复核、谁签字。接不住的也有两类：跨部门抢资源这种要博弈的事，以及评价标准本就不统一的工作。

② 知识运营：会积累，也最需要人盯着

这一类动的是知识的全生命周期。能接的活大致有：把散落资料按主题归位并标清版本、把高频提问整理成成对的问答、把政策文件按适用对象拆开解读、按模板搭出标书初稿并标出缺哪块、把离职或调岗留下的材料重新指认责任人。

差别在责任层：Agent 能做到的是"答得出来"；数字员工这层管的是"谁有资格问、答错谁改、隔多久复核一遍"。前者是能力，后者是岗位约束。落地前提四条：手上多少份资料、其中多少版本互相打架、谁来判哪版有效；权限分层能不能落到具体的人；资料更新有没有触发机制；谁对回答准不准负责。接不住的，是本身没有唯一答案的争议内容，以及要承担法律责任的表述。

这里补一句和知识库类项目的接口：这个区域底下的能力，很多基于检索增强生成技术，但那只是 Agent 的能力组件之一。相较之下，Agent 额外交出任务规划、工具调用与反馈闭环三件能力，可以主动去做归档、拆解和生成，而不停留在被动答疑。所以选了知识运营，下一步要问的不是"用不用检索增强生成"，而是这个区域究竟要不要往岗位级封装走。

③ 业务流程：牵动系统对接，难度上台阶

这一类动的是系统里的单据流转。能接的活大致有：报销单据按规则先过一遍并圈出不合规的点、合同关键条款拿来比对并提示风险、订单异常自动分流、工单按规则派下去并催办、审批流开工前的预检。

差别仍在责任层：Agent 干的是单点判断；数字员工这层管的是"这一步谁能做、额度多少、谁来批、留痕给谁看"。同一张单据，前者判得出合规与否，后者决定它放不放行。落地前提四条：哪些系统已经把接口开出来、接口稳不稳、有没有测试环境可用；业务规则是写下过的还是靠人拍脑袋；额度上限与越权升级路径定没定；出错之后谁改单。接不住的，是需要人拍板的例外审批，以及要承担法律与合规最终判定的环节。

④ 营销获客：最贴近钱，变量也最多

这一类动的是对外的增长链路。能接的活大致有：按"热点加场景加常见误解"起选题初稿、按平台改出不同版本、把咨询留言整理成需求线索、按规则给线索打标签并派单、跟进提醒与话术准备。

差别同样在责任层：Agent 是生产内容的工具；数字员工这层管的是账号归谁、能不能发、线索算谁的、对外怎么说。内容做得好不好属于能力问题；以谁的名义发、线索记在谁头上，属于岗位问题。落地前提四条：有没有内容资产（老文章、案例、话术库）；线索合格的标准写没写下来；跟进规则谁定的；最终话术谁负责。碰不了的是这几类：要临场拿捏的客户谈判、品牌调性的一致性把关、舆情处理，以及平台规则说变就变。头一类得有人对语境和关系负责；中间两类判断标准常常写不清楚，也不敢整个交给机器；末一类则需要有人盯着平台动向随时调策略。这些都不是固定脚本能接住的。

八、为什么五要件缺一不可：长链路的可靠性是乘出来的

补一段因果，说明第一节那五条为何不是"锦上添花"。

一个任务被拆成的步数越多，每一步各自的出错概率会累积，整条链路的成功率掉得越快。三步各有九成把握，乘起来只剩七成出头。任务规划与反馈闭环排在最后，不是功能清单里的两个可选件，而是替长链路兜底的两个机制。规划决定步数能不能少、路径能不能短；闭环决定某一步错了能不能就地纠回来。少了规划，步骤会乱作一团；少了闭环，一个环节错到底。

这条因果同时解释了一个反复出现的现象：链路越长，越需要在关键节点留一个人来验收。后面四类区域里"接不住的"那一段，几乎都落在同一点上，需要人兜底的判断和担责，不是模型能力不够，是长链路的可靠性结构决定的。把它当成设计约束、而不是缺陷来修，选型时的预期才摆得正。

九、六条决策判据：什么时候该升级到岗位封装

先把两组判据的关系说清。第五节那三条是识别，用来判断供应商卖的是哪一类；这一节这六条是决策，用来判断自己该买哪一个。分组不同、用途不同，不会重叠。

还有一句要先摆平：这两者之间没有一刀切的分界，从"工具"到"岗位"是一段连续过渡。现实中大量存在介于其间的形态，例如已经带了一部分权限的 Agent，或者只管一个环节的数字员工。碰到这种情况，别去纠结它"算不算数字员工"，还是回到那句：立项按什么单位、验收按什么标准。以任务为单位验收，功能堆得再多也还是 Agent；以岗位 KPI 为单位验收，哪怕只承担了一部分职责，也已经是数字员工的雏形。

按经验给一条参考线（属经验值，不是统计结论）：后三条里若中了两条以上，就该往岗位封装那边想一想；一条都没中，先上 Agent。六条全不占，说明这事还没到要用工具的地步，先把流程理顺。

顺带提醒一句，别把它读成"包得越重越稳"：岗位封装那层的维护开销是长期背着的（成本那一节会拆开）。一件 Agent 就能收尾的事，不必提早包成岗位。包得越厚，往后要养的权限、责任人和复核机制就越多。

换个场景：拿五要件去市场上一照，发现目标产品只有两三条达标，这单还签不签？采购方多半卡在这里。答案是不必一票否决，但要重新定价：只有两三条的，本来就不该按完整 Agent 的价位和预期去谈，而应按"带工具调用的对话助手"那一档来谈，验收线、交付周期、责任边界统统降一级。五要件既是筛供应商的网眼，也是给产品标价的刻度。

十、四类误判：症状、机制、对策、验收

按四拍整理，可以直接拿去当项目复盘的对号清单。

误判一，把"能演示"当成"能上线"。症状是演示行云流水，接上真实数据第一周就错得离谱。机制不难理解：演示时的样本是挑干净了的；真实环境里则是脏数据、并发、权限冲突一样不少，还夹着一堆没人交代过的历史特例。对策是在立项阶段就把验收数据集锁定，专门挑真实数据里最脏的那一批来跑，覆盖新数据、缺字段、格式不一致、越权访问四种情形。验收看的是在真实环境里把同一批任务连着跑，成功率能不能稳定达标，失败项有没有逐条留下处置记录。

误判二，按"买了几个 Agent"立项，而不是按岗位任务立项。症状是采购十个，三个月后没人在用。机制是按工具数量下单，没有对到任何人的日常工作上，工具只解决"能不能做"，不解决"谁负责"。对策是先把岗位上要做的事列成清单（谁、每天干哪几件、每件的输入与输出各是什么），再倒过来推需要哪些能力。验收看的是每个 Agent 是否都落在某个岗位的真实任务上，且使用人写得明明白白。

误判三，只买工具，不定义职责。症状是数字员工跑满三个月，答错了也没人过问，知识一点点过期。机制是没有责任人就没人维护，知识型能力会随时间慢慢失效：接口会变，规则会改，只要没人跟进更新，它就开始输出过期答案。对策是上线前先定两件事：归口责任人是谁、复核频次多少（比如每月抽样复核一次）。验收标准是有可查的更新记录与复核日志，复核人名姓具在。

误判四，把数字员工当成裁员工具。症状是一提数字员工团队就抵触，不给真实数据、不提改进意见。机制在于，人一旦感觉要被取代，第一反应就是防守，而防守的外在表现恰恰是不配合。这里有一处绕不开的张力：管理层看到公开案例里的提效倍数、想优化人效，属于理性预期；员工担心饭碗，同样是理性防御。双方的反应都合理，单靠"这是给大家配能力"一句解释，是压不住的。对策是把张力摊开谈，用机制解决三件事：把过渡期先讲明，多长时间内不会因为上了这套东西而裁人；再讲清省出来的时间怎么安排，是转做别的事还是计入绩效；优先把能力补在空缺岗和长期人手吃紧的环节，不动在岗的人头。起步阶段依旧从最枯燥、最没人愿意做的活切入（整理纪要、核对单据、归档文档）。验收标准是员工主动使用，并主动提改进点。

十一、封装成本：三档构成，和最容易漏算的部分

采购口径分三档，构成项与周期各有不同。下面只写构成和周期区间，不涉及金额。

最容易漏算的是隐性成本，三项：

▸文档定版与授权到人的人力：把同一份资料的新旧版本理清、把访问权限落到具体的人，这块花掉的时间常常超过写代码。 ▸兜底与复核的工时：它不会因为上线就消失，而是长期挂在那里，只是性质从"亲手做"变成了"抽查"。 ▸更新与回归的成本：知识会过期、接口会改版、规则会调整，每动一次都得重新验一遍。

按经验，这三项加起来的量级常常落在总预算的四成到六成之间（经验值，不是统计口径），远不止"顺手带一下"的份量。一份预算里若只列了软件、服务器和开发人力，基本可以判定漏项，至少得把数据治理、复核抽查、更新回归这三块补进去。

支出这头讲完，收益那头也得用同一把尺子，否则账对不上。"替代人力"和"增强人力"是两套算法，不能混着用。省掉某个环节的人力，算的是减少了多少支出；让同一批人产出更多，算的是多了多少产出。前者的折算基准是省下来的工时，后者的基准是新增的产出量。两套混在一起算，结果必然失真。

所以这一节的名义要把后半截补上：先想清楚按什么单位花钱，再想清楚按什么单位算收益。这两件事在立项阶段就写在同一页上，验收时账才平得了。

十二、落地兜底：六个非技术动作

治理方向定下来之后，卡点多在技术之外。下面六件事都不涉及业务代码，却决定前面那些工程判断会不会重新失效。

▸发起人：应该是业务侧的责任人，而不是 IT 或供应商。业务侧不点头的项目，最后常常沦为"技术部门在自娱自用"。 ▸先切哪一块：沿难度轴从最有感的开始，办公协同通常门槛最低。 ▸入口放哪：塞进已在用的工具里（企业微信、钉钉、邮箱），别再开一个新入口。入口每多一个，使用意愿就往下掉一截。 ▸责任人落进职责：把数字员工的归口人写进岗位职责，而不是只写在项目文档里。只有进了职责，才会有人长期管。 ▸先留基线：上线之前，把眼下的处理时长、错误率、业务量记下来。缺了基线，事后根本说不清到底有没有改善。 ▸兜底路径要写明：哪些情况必须转人工、转给哪个人，提前写清楚。路径模糊，一线宁可不用。

十三、选型自查清单（可直接勾选）

下面十二条，能逐条答"是"了再往下推。按四组归好，方便对着查。

▸ 概念与立项

1. 这两者的差别，你能一句话讲清吗（一边给能力，一边给岗位封装）？
2. 本轮是按任务立，还是按岗位立？
3. 验收用的数据集定了吗，里面有没有最脏的那批？

▸ 数据与权限

4. 责任人是否具名到人？
5. 权限边界划了吗（能看什么、能批多大额度）？
6. 数据在哪、齐不齐、谁在管？

▸ 系统与验收

7. 系统接口是否齐备、是否稳定、有没有可用的测试环境？
8. 复核人是谁、隔多久复核？
9. 出错后的升级路径写下来了吗？

▸ 组织与预算

10. 上线前的基线记了吗？
11. 隐性成本（文档定版、复核抽查、更新回归）有没有列进预算？
12. 团队的顾虑怎么处理，是不是把它定位成"给人加能力"？

若十二条里有三条以上答不上来，这事八成就还没到立项的时机。先把问题问透，比系统上完再推倒重来划算得多。

十四、把两类封装的边界收成一句话

▸ 只解决单个任务、想快些见效、要能灵活塞进现有系统 → 选Agent。 ▸ 要接着一个岗位的完整职能、要统一身份与权限、要对外给标准化服务 → 选AI 数字员工。

顺手补一个关系式：数字员工 ＝ 若干 Agent + 岗位权限体系 + 工作流编排 +（可选的）身份形象。

回到开篇那两家供应商。它们报价相差的那个量级，差的不在能力上，而在封装层，也就是三件事：

▸治理：权限给到谁、操作怎么留痕、出错由谁复核。 ▸编排：把若干 Agent 串成一条链路，以及链路中途出错时怎么补。 ▸形象：属于装饰性外壳，不必为它掏大头。

这三件事问明白，价差落在哪儿、值不值得，心里自然有数。当面还可以拿三个问题去问供应商：按什么单位验收、交付物究竟是什么、最终考核谁。

四类区域里那些"接不住的"，最后几乎都指向同一个地方：需要由人兜底的判断与担责。这不是模型不行，是结构使然。所以对数字员工可以下一个更锐的定义：它并不"顶掉一个岗位"，而是把岗位上能规则化的那部分剥出来做封装，剩下的判断和担责仍旧留给人。因此它交付的从来不是"一个员工"，而是一张岗位任务拆分表：哪部分归它、哪部分归人、界线画在哪里。

若你正卡在选型或立项的起步阶段，先别忙着比产品，把三件最小的事做掉：

1. 把岗位上最高频的任务列成清单，挑三件最重复、最没人爱干的；
2. 找到该事项的业务负责人，确认他肯为结果担责；
3. 把这几件事当前的处理时长与出错率记下来，留作基线。

这三件做完，再来讨论选 Agent 还是数字员工，基本不会跑偏。无论叫哪个名字，第一步都不是挑工具，而是先诊断，再落地：岗位任务先拆开，数据与权限先理顺，然后才决定用哪一层来封装。

唐欢（弯弯）｜企业AI落地顾问

让企业把 AI 真正用到业务里

弯弯的产业AI实战