企业级 Agent 不一定要多 Agent

前段时间我复盘了一个真实的 AI 接待系统，发现一个容易被忽略的点：

很多企业场景里，好用的 Agent 架构不一定是多个 Agent 互相协作，而是一个 Agent 被一套稳定流程约束住。

系统要先告诉 Agent：

• 现在处在哪个业务阶段。
• 当前阶段要完成什么。
• 可以调用哪些工具。
• 什么情况下进入下一步。
• 什么情况下必须停下来转人工。

这类架构我一般叫它 SOP Agent。

它的重点是让 AI 在正确边界里工作。

SOP Agent 是什么

SOP Agent 是把大模型放进业务流程里的 Agent 架构。

在这种架构里，LLM 更像理解和表达层：它负责读懂用户的话，生成自然回复，判断可能的下一步。能不能跳转阶段、能不能触达用户、能不能调用高风险工具，由状态机、规则系统和业务仲裁决定。

这和“给模型一段长 prompt，让它自己按流程执行”不是一回事。真实业务里，状态会跨会话存在，用户会反复回来，工具也有风险等级。这些东西不能长期交给上下文窗口。

为什么不是所有业务都需要多 Agent

现在很多人一提 Agent，就会想到 Deep Research 那种结构：主 Agent 拆任务，多个子 Agent 分头搜索，最后汇总成报告。

这种模式当然有价值。开放式研究、陌生行业调研、复杂资料搜集，都适合多 Agent 并行。因为一开始不知道要查多少资料，也不知道会遇到哪些信息缺口。

但企业里有很多任务不是这种形态。

客户接待、售前咨询、订单处理、售后回访、投诉分流，它们的难点不是“信息覆盖不够”，而是流程不能乱。

客户刚进来，系统要识别需求；客户表达兴趣，系统要确认关键信息；客户问到具体问题，系统可能要查知识库或订单系统；客户已经接近成交，系统要处理顾虑；客户出现不满，系统要切到安抚和人工介入。

这些事情如果全交给一个自由发挥的 Agent，它可能会提前推进流程、重复问用户已经回答过的问题、在错误阶段调用错误工具，或者在用户已经不满时继续按销售逻辑往下走。

这类业务要的不是更自由的 Agent，而是更稳定的流程控制。

流程型业务先看状态

很多 Agent 文章会强调规划能力：给一个复杂任务，Agent 先拆步骤，再调用工具，再根据结果调整。

这对研究任务很重要。但流程型业务里，更大的问题是系统知不知道客户现在走到了哪一步。

一个客户不会只聊一轮。他可能今天问几句，明天回来继续聊，三天后才下单，一周后又回来问售后。中间每一步都有状态：他提供了哪些信息，关注点是什么，是否确认方案，是否付款，是否表示过犹豫，是否需要回访，是否进入人工处理。

如果这些状态只靠上下文窗口保存，系统迟早会乱。上下文会变长，会被压缩，会被截断，也可能因为模型切换或服务重启丢失。

更稳的方式是把状态外置。

系统从数据库加载当前会话状态，告诉 Agent 当前处于哪个 SOP、走到哪一步、已经确认哪些事实、还有哪些问题没解决、当前允许调用哪些工具。Agent 只在这个上下文里完成当前回复。

这里的原则很简单：不要让 LLM 记流程，让系统记流程。

单 Agent 加 SOP 路由

流程型业务里，我通常不会一开始就拆成接待 Agent、销售 Agent、订单 Agent、售后 Agent、投诉 Agent。

用户对话是连续的，不会按系统角色切开。用户可能在售前阶段突然问订单，也可能在售后阶段追问方案细节，还可能一句话里同时包含新需求、异议和情绪。

如果每个角色都是独立 Agent，就要处理上下文传递、角色切换、口吻一致性和责任归因。复杂度会先涨起来。

更简单的方式是只保留一个主 Agent，用 SOP 路由控制它当前的工作模式。

系统把业务拆成多个阶段。每个阶段有自己的目标、完成条件、可用工具和跳转规则。同一个 Agent 在不同阶段看到的系统提示不同，能调用的工具不同，需要完成的目标也不同。

它仍然是一个 Agent，但行为被当前 SOP 约束住。

意图识别不要全交给大模型

用户每发一句话，系统都要判断：这句话意味着什么？要不要切阶段？要不要调用工具？要不要转人工？

很多系统会直接把这件事交给 LLM。我不建议全交给模型。

真实业务里有大量确定性事件，不需要模型判断。比如“查一下订单”“我想退款”“转人工”“不要再发了”，这些应该由规则直接命中。规则快、便宜、稳定，也不会因为模型状态波动而误判。

但也有很多表达离开上下文就没意义。比如“那这个呢”“还有别的吗”“我再想想”“你帮我看看”。这时候需要 LLM Classifier 结合当前阶段、历史对话和用户状态判断。

比较稳的结构是三层：

1. Hard Rules 处理确定性事件。
2. LLM Classifier 处理语义模糊的表达。
3. State Arbiter 做系统仲裁。

最后一步很关键。模型可以建议进入下一阶段，也可以建议转人工，但系统不能照单全收。还要检查置信度、前置条件、当前阶段是否允许跳转、是否有风险标签、是否缺少关键事实。

模型负责理解，系统负责决定。

工具要按阶段暴露

Agent 能调用工具，不代表它应该看到所有工具。

如果把所有工具都暴露给模型，模型就要在一个很大的工具列表里选择。它可能在不该查订单时查订单，在应该转人工时继续查知识库，或者在售后场景里调用售前工具。

更稳的做法是按 SOP 暴露工具白名单。

当前处于哪个业务阶段，就只给哪些工具。信息收集阶段可以记录事实；订单阶段可以查订单；知识解释阶段可以查知识库；售后或投诉阶段可以创建工单或转人工。当前阶段不该用的工具，不要出现在模型上下文里。

工具还要有风险等级：

• 读取信息风险较低。
• 写入状态风险更高。
• 用户可见动作风险更高。
• 付款、退款、投诉、敏感承诺，应该进入审批或转人工流程。

企业级 Agent 的重点不是让 AI 无限制行动，而是让 AI 在授权范围内行动。

消息系统也很重要

很多 demo 只处理一种情况：用户发一句，AI 回一句。

真实接待不是这样。用户可能连续发多条消息。如果系统每条都单独处理，Agent 可能还没理解完整问题就开始回复。入口需要消息合并，把短时间内连续发来的消息合并成一个完整输入。

AI 的回复也不一定适合一次性发出去。太长会像机器，太短又没信息量。出口需要投递队列，负责拆分、延迟、重试、去重和失败处理。

主动回访也一样。不能让模型自己决定什么时候打扰用户。应该由规则系统先判断是否在允许时间段、是否超过冷却期、当天是否已经触达、用户是否表达过不想被联系。规则判断可以触达，再让 Agent 生成话术。

规则决定该不该发，模型决定怎么说。

难点在可追踪和可恢复

做一个能跑的 Agent demo 不难。难的是让它在真实业务里连续跑几周、几个月，还能解释为什么做出某个决策。

生产系统里，每次处理用户消息都应该记录：

• 当时的会话状态。
• 意图识别结果。
• 模型看到的工具。
• 实际调用的工具。
• 工具返回结果。
• 状态是否推进。
• 质量检查是否通过。
• 最后发给用户的内容。

否则出了问题查不清楚。

用户投诉“AI 乱承诺了”，你要能查到是哪一轮、哪个 SOP、哪个提示词版本、哪个模型、哪个工具结果导致的。业务人员改了 SOP 后转化率下降，你要能回放历史对话，看是哪个步骤的完成条件写错了。

企业级 Agent 不能只靠感觉调 prompt。它需要 trace、eval、版本管理、灰度发布和回滚。

多 Agent 放在哪里

我不是反对多 Agent。多 Agent 很有用，但要放在合适位置。

开放式研究、代码修复、复杂数据分析、长文档审查，可以考虑多 Agent 分工。后台任务也适合，比如分析历史对话、找客户流失点、整理知识库、生成 SOP 优化建议、复盘复杂投诉、生成运营周报。

但实时接待主链路不应该优先拆成多个 Agent。

主链路要稳，后台分析可以复杂。这是两个不同问题。

结论

开放式任务路径不可预测，需要并行探索，多 Agent 是好选择。

流程型业务路径相对稳定，但用户表达复杂、周期长、状态多、工具多、风险高，更适合：

单 Agent 做理解和生成，SOP 做流程控制，工具白名单做权限边界，数据库做长期状态，规则系统做触达和风控，评测系统做持续迭代。

这个架构不炫，但更容易落地。