Agent 都这么厉害了,「AI 员工」为什么今天还没有真正出现?

AITNT-国内领先的一站式人工智能新闻资讯网站
# 热门搜索 #
Agent 都这么厉害了,「AI 员工」为什么今天还没有真正出现?
5526点击    2025-08-23 11:37

AI 同事、AI 数字员工的呼声越来越高,但至今仍没看到很好的落地。这其中的难点和瓶颈到底在哪里?


AI 数字员工,真的是一个值得追求的目标吗?


过去两年,我经常听到身边的人在想办法让销售或者服务性岗位可以使用 AI 员工。很多人期待它能像真人一样坐在工位上,替代重复性工作,甚至完成复杂决策。可现实是:我们还没看到真正意义上的「AI 小李」或「AI 小张」。


到底瓶颈在哪里,或许可以从数字员工最早的源起说起。


01

早期的自动化工具并不是数字员工


其实,「数字员工」的概念最早在 RPA(机器人流程自动化)时代就有了。当时,人们希望通过流程自动化来模拟人类员工的部分操作。


后来,聊天脚本机器人、智能外呼系统也常被包装成「AI 员工」。但大多数人并不认同:这些系统只是自动化工具,并不具备真正的自主性


根本差距在于:


  • 自动化(Automation):依赖预设规则,照做即可。


  • 自主性(Autonomy):能理解环境、做出权衡、持续改进。


另外很多人对「AI 员工」的失望,来自于高昂的维护成本:不断更新文档、配置流程,比管理一个真实员工还要麻烦。


02

大模型带来了新可能,

但还有不少问题


这波 AI 的进化的确带来了质变,让人们一度以为「AI 员工」触手可及:


  • 理解力显著提升:从关键词匹配,升级到基于大模型的意图分析,回答更准确。


  • 多模态能力增强:不再局限于文字输入,还能处理语音、图片,交互体验大幅提升。


  • 回应更灵活:不再是冷冰冰的固定话术,而能针对场景灵活应答。


看上去,条件都成熟了。但现实却是——它依然没能成为一个真正的「员工」。在用新技术做了 1 年的客服场景之后,有总结出以下观点:


2.1 时效性和打断机制不足


大模型的推理速度远比不上人类。在对对话节奏要求极高的场景(如电话销售)中,延迟几秒钟就足以破坏体验。结果是:AI 依然只能停留在预约、意向筛选层面,难以负责真正成交。之前我在湾区的时候,有不少 echo assist 会找用户做测试,测试人们在 AI 回应延迟多少的情况下是舒适的。另外就是看什么时候应该等用户说完或者被用户打断,而不是只管自己输出,做出一种在认真倾听的感觉。这种效果即便在文字环境下也是有难度的,核心就是如何把握说话的时机。


在这方面,我们最早是用最简单的计时,在用户发完一个消息之后不是立即响应,如果在这个等待时间里又发了消息就重新计时。但这个方案很快就被否定了,因为我们有大量的群聊场景,一个人说完了不代表别人不会说话,这种机制会导致只要有人还在不停的说话,就会一直等下去。


后面,我们就改成了使用 redis 进行批处理,在处理前就先对无用消息(比如打招呼等不影响上下文意图的内容)进行剔除,然后等待用户说完,把整个一组上下文做统一处理。同时,因为答案生成是有时间的,在答案生成期间如果又出现了消息,就会对生成进行打断或者不发出已经生成的内容,而是重新处理。自此就有了非常好的「不打岔」的效果,也明显让回复更像是人,而不是一个查询机器。


2.2 场景定义的局限


今天大多数 AI 应用仍依赖人工预设场景与工作流。但人类在抽象流程时,总会遗漏情况或界限模糊。AI 无法处理边缘案例(corner case),而人类的价值恰恰在于能解决这些突发情况。


之前我们做了大量的实验,让甲方基于经验抽象场景,然后把实际发生的例子进行聚类分析,发现除非把这些分类的边界设置的很宽,否则就会击中率非常低。而这些无法击中预设分类或者工作流的,其实就是日常生活中感觉到人工智障的时候,因为可以说它完全会错了意。


Agent 都这么厉害了,「AI 员工」为什么今天还没有真正出现?


上图就是我们针对一个客户预先定义好的场景,将实际发生的事件进行匹配的效果,可以看到很多事件的界限是非常模糊的,甚至换一下场景也是成立的。所以这里我们的实践经验是交给基模自己来对历史事件进行场景抽象,然后让后续的事件和历史相似类型的事件进行匹配,明显会比人类进行预定义的效果要更好。


2.3 意图澄清能力不足


现实用户并不会像实验数据那样表达完整而精准。他们可能心口不一、表达不清晰,甚至需要反问来澄清。


我之前在吃饭的时候和朋友们经常玩「海龟汤」的游戏,就是有个人说一个结果,大家通过问问题来把整件事情还原,从而了解事情的全貌。目前很多通用 agent 已经在这么做了,在用户提出任务之后,会进行一次澄清,但这显然是不够的,这个过程往往需要根据每次用户的反应找到特征,然后继续尝试挖出完整的需求,才能做出更加符合用户预期的反应。


这里我觉得可以参考一下 ChatGPT 学习模式的设计,它的设计逻辑是:


1.先摸清你的底子,看看你对这块知识了解多少。


2.接着,它不会直接甩给你答案,而是像教练一样引导你,一步一步,通过提问、暗示,让你自己找到答案。


3.最后,它会检查你是不是真的明白了,让你复述、应用,甚至角色扮演。


这种通过 follow up 问题的方式,逐渐澄清一个用户的真实意图,在明确意图之后再进行回复,就会有根本性的提升。因为回复的内容从「供参考」变成了「具体答案」,这样才能有问题在被解决的感觉,而不是只是丢相关内容自己解决。


2.4 知识更新滞后


这是我认为最核心的阻碍。主要是因为模型本身是「无记忆」的。诺兰的成名电影《记忆碎片》生动的反映了这点。主人公有失忆症,只能有很短的记忆 ,却要完成为妻子复仇这种极其存续和复杂的任务。他会利用拍立得照片、写笔记、纹身等方式提醒自己,记住每个节点的状态,帮助自己推进。


这就很像现在的 LLM+RAG 的模式。但是依赖 RAG 和外部知识库,更新的动作都是由人类完成的,所以知识更新往往滞后、质量参差不齐,而且成本比管理人类员工还高。


另外,真正的员工会「越干越熟练」,但 AI 系统却缺乏成长性。第 100 次做和第一次做没有本质的区别,如果这真是个活人的话,我们可以说他不长记性。


这里我们做了很多的东西,篇幅有限,回头可以专门弄一个讲知识更新的内容


2.5 缺乏博弈能力


权限边界是个大问题,从大模型刚出来时就有很多人担心什么能给 AI 做、什么不能。我认为这背后最重要的原因是它没有博弈能力,无法衡量各种决定的结果,到底是不是对自己有利。


人对人的信任,是相信自己人会将利益的天平倾斜向自己,但这里就需要「自己人」深刻理解,什么才是对组织当下最有利的选择。而 Agent 目前的设计很明显做不到这一点,也就很难放心 AI 是会始终和购买它的人站在一起的。


03

局部替代,

不追求完全替代


对于接下来的 AI 员工的发展,首先可以肯定的是这个需求是极其的旺盛且高度未被满足,那么到底有没有必要做成一个非常完整「人」呢?


首先,追求完全替代的想法,是因为看到了需求背后巨大的市场空间,但是忽略了为了做好最后一公里,这里的成本是无法想象的。另外受到上面一些限制,就会让场景更加的不下沉,能够真正用的起来的场景会变得很少。


所以我的观点是局部替代,只找最合适的部分来替代,这里的核心难点是处理系统本身,就是如何让这个新的系统和人类进行协作形成新的平衡。我们已经适应了上时代以表格为中心作为协作模式的工作方式很多年,如何在新的时代开启和 Agent 协作,也就是 human in the loop,是我们接下来要攻克的核心课题。


Agent 都这么厉害了,「AI 员工」为什么今天还没有真正出现?


这张图是之前我在公司内部确定产品边界的时候画的,我认为「执行」这个环节从上个时代开始就已经做的很好了,但是有了 LLM 之后,其实就可以开始引入「总结」能力和「发现有效」,现在的基模对于总结和洞察往往比真人做的还要好,但这里的难点是要对有效进行定义,做出自己场景的 eval 系统或者模型。我认为能把这部分做好,能让「固定工作套路」这个小圈闭环,已经是个很大的突破了。


相对地,我不建议把「决策中枢」和前置规划过早交给 AI。更稳妥的路径是倒着走:先把可重复、可验证的固定工作做实,再从 episodic memory(事件记忆) 中抽象出可解释的优化建议,形成小范围的自我调整,随后逐步放权。反之,如果一上来就从「目标提出—定义—拆解」做完全替代,在缺少反馈数据的前提下只会引发复杂度爆炸,既难以落地,更无法「成长」。


因此,我的核心建议是:尽快进入真实场景,让 AI 先以「实习生」的角色上岗,在实战中被评估、被优化、被约束。至于「模型会吃掉应用」的担心,大可不必——模型是能力层,真正的护城河来自「可度量的闭环 + 贴身的业务边界」。模型会吃掉的是一切弥补模型短板的复杂的工程,比如流程编排器、历史日志拼接、盲目的文档塞入向量库、过度的 prompt 工程等等,都是会随着模型能力的提升而消失的。


当一个个可测量的小闭环跑通,AI 会从能干活的「实习生」成长为可信赖的「员工」。 届时,「AI 员工」将不是被宣布出来的,而是被迭代出来的。


文章来自于微信公众号“Founder Park”。


关键词: AI , AI员工 , 智能体 , 人工智能
AITNT-国内领先的一站式人工智能新闻资讯网站
AITNT资源拓展
根据文章内容,系统为您匹配了更有价值的资源信息。内容由AI生成,仅供参考
1
AI工作流

【开源免费】字节工作流产品扣子两大核心业务:Coze Studio(扣子开发平台)和 Coze Loop(扣子罗盘)全面开源,而且采用的是 Apache 2.0 许可证,支持商用!

项目地址:https://github.com/coze-dev/coze-studio


【开源免费】n8n是一个可以自定义工作流的AI项目,它提供了200个工作节点来帮助用户实现工作流的编排。

项目地址:https://github.com/n8n-io/n8n

在线使用:https://n8n.io/(付费


【开源免费】DB-GPT是一个AI原生数据应用开发框架,它提供开发多模型管理(SMMF)、Text2SQL效果优化、RAG框架以及优化、Multi-Agents框架协作、AWEL(智能体工作流编排)等多种技术能力,让围绕数据库构建大模型应用更简单、更方便。

项目地址:https://github.com/eosphoros-ai/DB-GPT?tab=readme-ov-file



【开源免费】VectorVein是一个不需要任何编程基础,任何人都能用的AI工作流编辑工具。你可以将复杂的工作分解成多个步骤,并通过VectorVein固定并让AI依次完成。VectorVein是字节coze的平替产品。

项目地址:https://github.com/AndersonBY/vector-vein?tab=readme-ov-file

在线使用:https://vectorvein.ai/付费

2
智能体

【开源免费】AutoGPT是一个允许用户创建和运行智能体的(AI Agents)项目。用户创建的智能体能够自动执行各种任务,从而让AI有步骤的去解决实际问题。

项目地址:https://github.com/Significant-Gravitas/AutoGPT


【开源免费】MetaGPT是一个“软件开发公司”的智能体项目,只需要输入一句话的老板需求,MetaGPT即可输出用户故事 / 竞品分析 / 需求 / 数据结构 / APIs / 文件等软件开发的相关内容。MetaGPT内置了各种AI角色,包括产品经理 / 架构师 / 项目经理 / 工程师,MetaGPT提供了一个精心调配的软件公司研发全过程的SOP。

项目地址:https://github.com/geekan/MetaGPT/blob/main/docs/README_CN.md

3
知识库

【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。

项目地址:https://github.com/labring/FastGPT

4
RAG

【开源免费】graphrag是微软推出的RAG项目,与传统的通过 RAG 方法使用向量相似性作为搜索技术不同,GraphRAG是使用知识图谱在推理复杂信息时大幅提高问答性能。

项目地址:https://github.com/microsoft/graphrag

【开源免费】Dify是最早一批实现RAG,Agent,模型管理等一站式AI开发的工具平台,并且项目方一直持续维护。其中在任务编排方面相对领先对手,可以帮助研发实现像字节扣子那样的功能。

项目地址:https://github.com/langgenius/dify


【开源免费】RAGFlow是和Dify类似的开源项目,该项目在大文件解析方面做的更出色,拓展编排方面相对弱一些。

项目地址:https://github.com/infiniflow/ragflow/tree/main


【开源免费】phidata是一个可以实现将数据转化成向量存储,并通过AI实现RAG功能的项目

项目地址:https://github.com/phidatahq/phidata


【开源免费】TaskingAI 是一个提供RAG,Agent,大模型管理等AI项目开发的工具平台,比LangChain更强大的中间件AI平台工具。

项目地址:https://github.com/TaskingAI/TaskingAI

5
prompt

【开源免费】LangGPT 是一个通过结构化和模板化的方法,编写高质量的AI提示词的开源项目。它可以让任何非专业的用户轻松创建高水平的提示词,进而高质量的帮助用户通过AI解决问题。

项目地址:https://github.com/langgptai/LangGPT/blob/main/README_zh.md

在线使用:https://kimi.moonshot.cn/kimiplus/conpg00t7lagbbsfqkq0