企业做 AI Agent 之前先分清三种形态

先把话说清楚：Agent 不是一个东西

「我们也想做个 AI」这句话，落到具体项目上至少是三件完全不同的事。它们的工作量差着量级，需要你准备的东西也不一样。谈钱之前先分清是哪一种，比比价格更重要——因为拿一份客服 Agent 的报价去对照一份流程自动化 Agent 的需求，得出的结论一定是错的。

三种形态按「模型能碰到什么」来分：只碰对话、还能碰你的资料、能碰你的系统。

形态一：客服与咨询 Agent（只碰对话）

这是最轻的一种。它面向访客或老客户，支持多轮对话与上下文记忆，答不上来能转人工，聊到有意向时能把联系意向留下来。它不读你的内部资料，也不动任何业务数据，答案主要来自事先写好的话术与模型自身的通用知识。

适合什么：产品与服务比较标准、常见问题就那么几十个、主要目的是接住咨询不流失。

不适合什么：答案高度依赖你自己的资料（具体条款、具体规格、具体价格）。这种情况下只靠话术，模型迟早会编出一个听起来很合理但不存在的答案。

落地重点有三件：一是话术边界，写清楚哪些问题一律不答（报价承诺、法律意见、竞品比较）；二是转人工的触发条件，是关键词触发、连续答不上来触发，还是用户明确要求触发；三是会话记录能不能事后回查，这决定了你有没有办法发现它在乱说。

形态二：企业知识库问答 Agent（能碰你的资料）

也就是常说的 RAG。把制度、手册、合同模板、产品资料切分成段落入库，提问时先检索出相关段落，再把段落连同问题一起交给模型作答，并要求它只用检索到的内容。答案下方把引用的原文显示出来，让人能点开核对。

适合什么：资料多、更新频繁、答案必须能溯源。对内的员工手册问答、对外的产品与条款咨询都是典型场景。

这一类项目的成败往往不在模型，而在资料。我们做过的项目里，最常见的卡点是同一条规则在三份文档里有三种写法，谁也说不清哪份算数。这种情况下先要做的不是入库，是列一张冲突清单请业务方逐条裁定。这件事技术做不了，只能业务方拍板，而它通常比预想的花时间。

另一个容易被忽略的点是权限。如果知识库里既有公开资料也有薪酬制度，那检索这一层就必须按角色隔离，而不是在答案生成之后再过滤——过滤发生得越晚，泄漏的路径越多。

形态三：业务流程自动化 Agent（能碰你的系统）

最重的一种。模型被允许调用你系统里的接口：读一段消息生成订单草稿、按规则起草一张审批单、把附件里的数据抽出来填进表单。这一类的价值最直接，风险也最集中。

有一条我们不建议让步的设计：模型不直接写库。让模型负责把草稿准备好，人负责看一眼按确认，真正落库的动作由人的确认触发。理由不是不信任模型，而是错误的传播方式变了——人工录入的错误是一条一条发生的，模型的错误是成批发生的。一旦某类解析出现系统性偏差，自动写库会在你发现之前把它复制几百遍。

所以这一类项目的界面工作量常常超出预期：复核界面要让「改」比「录」更快，否则用户宁愿回去手工录。字段要按确定程度区分显示，不确定的宁可留空标红也不要猜一个填上——一个空字段用户会去补，一个填得很像的错字段用户会直接放过。

怎么对号入座

问自己三个问题就够了。

第一，答案从哪来？如果只能来自你自己的文件，那至少是形态二，别按形态一的预算规划。

第二，模型答完之后有没有动作？如果只是显示给人看，就到形态二为止；如果要生成单据、触发流程、改变数据，那是形态三，必须把复核环节一起算进工作量。

第三，答错了谁承担代价？如果代价是用户多问一句，形态一足够；如果代价是发错货、批错款，那就必须在流程里留人工节点，而不是靠调模型来兜。

一个常见的顺序建议

大多数企业不必一步到位。先把形态二做扎实——资料整理这件事无论如何都要做，而且它的产出（一份口径统一、可检索的知识库）即使将来换掉整套实现也仍然有效。等到资料这条底子打好、用真实问题跑过一轮、知道模型在哪些地方会答偏之后，再考虑要不要让它去碰系统。

反过来的顺序——资料还乱着就先做流程自动化——我们见过，通常的结局是复核环节的人工量比原来的手工量还大。

最后

不存在一个不会答错的模型，这一点在选型阶段就该接受。可选的不是「要不要容忍错误」，而是「把错误挡在哪一层」：挡在引用可核对上、挡在转人工上、挡在人工确认上。三道拦不住的，就不该交给 Agent 做。