从单Agent、工作流到多Agent协同，拆解可扩展、可治理的企业级架构

企业智能体项目最容易制造一种错觉：只要模型能调用工具、知识库能回答问题、前端能完成对话，系统就已经“搭好了”。但真正进入企业生产环境之后，问题会迅速从“能不能运行”变成“能不能长期稳定运行”。用户权限开始复杂，知识持续更新，工具数量增加，业务流程出现异常分支，模型升级带来行为漂移，多个部门又希望复用同一套能力。此时，最初那个简单的Agent往往会变成一个难以维护的“大Prompt应用”。

企业智能体架构设计的核心，不是堆叠流行组件，而是提前处理几个会随着规模放大的问题：职责边界、状态管理、工具治理、权限体系、数据分层、可观测性以及后续扩展。一个好架构的价值，通常不是在第一周体现，而是在系统运行半年以后依然能够定位问题、替换模型、增加Skill、接入新部门而不必全部推倒重来。

一、为什么单Agent架构在早期很好用

单Agent最大的优势是简单。一个模型负责理解用户、调用知识库、选择工具、组织结果，开发速度非常快。对于内部知识问答、简单数据查询、少量工具调用，单Agent往往是最合适的选择。

问题出现在能力持续增加之后。假设一个Agent同时接入知识库、CRM、ERP、邮件、文件系统、搜索、数据分析和审批工具，它的工具描述会越来越长，Prompt里的业务规则越来越多，上下文也越来越复杂。模型需要在大量能力中选择正确工具，并且记住当前任务已经执行到哪一步。

此时会出现典型的“角色过载”：同一个Agent既负责理解业务，又负责制定计划，还负责执行工具、检查结果、处理异常。任何一个环节出错，都可能影响整个任务，而且事后很难判断问题发生在哪一层。

因此，单Agent不是“落后的架构”，而是一个非常适合早期验证的起点。真正的判断标准应该是：当前系统的复杂度是否已经超过单Agent可以稳定承担的范围。

二、企业智能体为什么需要分层

企业软件架构最重要的经验之一，是把变化速度不同、责任不同的部分拆开。Agent系统同样如此。

应用层关注具体业务，例如客服、知识助手、运营分析和流程自动化。

智能体层负责理解任务、规划步骤、维护上下文、调用能力以及在必要时进行多Agent协同。

能力层负责RAG、结构化查询、文件处理、计算工具、工作流和第三方服务。

模型层负责通用大模型、Embedding、Reranker、小模型以及语音或视觉模型。

数据与治理层负责企业知识、业务数据、身份权限、日志审计和评估监控。

分层的意义是把“业务变化”和“底层能力变化”解耦。业务部门调整客服流程，不应该导致模型层重构；更换Embedding模型，也不应该要求上层所有Agent重新开发。

三、RAG和结构化数据必须分开设计

很多企业智能体把所有信息都放进向量数据库，这是一个常见架构错误。

制度、手册、案例、合同条款等非结构化知识适合RAG；订单、库存、客户状态、设备状态等实时数据则应该通过数据库或API查询。

两者的正确性要求也不同。RAG的关键是找到“相关且可信的依据”，而结构化查询强调“当前时点的数据必须准确”。

如果把实时业务数据转换成文本再写入向量库，很容易出现更新延迟和数据不一致。反过来，如果让大模型直接生成SQL访问生产数据库，又会带来权限和安全问题。

更合理的做法，是在Agent之下建立两个清晰能力域：知识检索域和业务数据域。Agent负责判断问题属于哪一类，再调用对应能力。

四、Skill层为什么必须独立

Skill可以理解为企业智能体能够安全调用的业务能力。

例如“查询客户信息”“创建售后工单”“读取库存”“提交审批”“生成报表”。每个Skill都有固定输入、固定输出、权限边界、超时规则和错误码。

真正重要的是，Skill层与大模型解耦。模型只负责决定“要不要调用”和“需要哪些业务参数”，实际系统认证、参数校验、接口调用和异常处理都在Skill服务内部完成。

这样做的好处是，未来即使更换模型，企业的业务能力仍然可以继续复用；同时也避免把数据库密码、API Key和内部系统细节暴露给模型。

企业Agent长期真正有价值的资产，往往不是Prompt，而是稳定、标准化、可复用的Skill库。

五、什么时候需要工作流，什么时候需要自主规划

固定工作流和Agent自主规划并不是对立关系。

标准审批、退款、合同流转等场景，规则明确、风险高，更适合固定工作流。开放式分析、研究、资料整理等任务，则需要模型进行动态规划。

企业级系统更适合把两者组合：模型负责理解用户目标和模糊信息，工作流负责控制关键业务步骤。涉及高风险动作时，由确定性规则或人工确认控制。

例如客户提出退款，模型可以识别意图、抽取订单号和原因，但“是否符合退款条件”“是否需要主管审批”“实际退款金额是多少”应由业务规则和系统数据决定。

这种架构的核心思想是：让模型处理模糊问题，让软件系统处理确定性边界。

六、为什么多Agent不是越多越好

多Agent很容易被包装成“更高级”的架构，但实际工程里，Agent数量越多，调试成本越高。

真正适合多Agent的场景，是任务存在清晰专业分工。例如一份行业研究报告可以拆成外部搜索、内部知识检索、结构化数据分析和报告整合。每个Agent职责明确，输入输出相对稳定。

如果只是为了把一个本来简单的任务拆成多个角色，多Agent反而会增加通信成本、Token成本和错误传播。

企业应该优先解决“职责边界”而不是追求“Agent数量”。如果一个单Agent已经开始出现工具过多、上下文过长、权限冲突和难以回放的问题，再考虑拆分会更合理。

七、状态管理是复杂任务的生命线

真正的企业任务经常跨越多轮对话，甚至持续几小时或几天。

例如采购比价需要发送询价、等待供应商回复、解析报价、比较条件、再生成建议。如果只依赖大模型上下文，任务一旦中断就很难恢复。

因此复杂Agent需要持久化状态。每个任务应该有Task ID，记录当前步骤、已完成步骤、输入、输出、等待条件、重试次数和异常原因。

状态管理的价值并不“智能”，但它决定了系统是否能够可靠恢复和重试。越接近生产环境，这类传统软件工程能力越重要。

八、企业智能体必须把权限做在后端

“请不要访问其他部门的数据”写在Prompt里，不是真正的权限控制。

用户身份应该由企业统一认证系统确定。知识检索时过滤无权限文档，结构化查询时限制数据范围，Skill调用时检查角色和操作权限。

对于高风险操作，还要引入二次确认、审批或多因素认证。

权限的原则是：模型可以提出请求，但最终是否允许执行，由后端安全机制决定。

九、可观测性为什么是架构的一部分

Agent系统的失败往往不是“服务器报错”，而是“结果质量不对”。

可能是知识召回错了，模型理解错了，工具参数错了，也可能是工作流状态丢了。

因此可观测性不能只监控CPU和接口状态，还要记录任务链路：用户问题、检索内容、模型输入输出、工具调用、业务结果和人工修改。

只有完整Trace，才能在系统出现质量问题时定位原因。

十、一个可长期演进的架构应该具备什么特征

第一，模型可替换。业务能力不与单一模型绑定。

第二，Skill可复用。不同Agent共享标准能力。

第三，知识与实时数据分离。不同数据类型走不同路径。

第四，状态可恢复。复杂任务能够中断、重试和继续。

第五，权限后端化。安全不依赖模型自觉。

第六，全链路可观测。失败能够被定位和复盘。

第七，平台能够小步扩展。新增一个业务场景不需要重新建设整套底座。

结语

企业智能体架构设计的目标从来不是“最复杂”，而是“在未来变化时仍然容易维护”。一个能跑起来的Demo可以在几天内完成，一个能够长期服务真实业务的系统，则需要更清晰的职责边界、更严格的权限、更稳定的状态管理和更完整的可观测能力。

当架构设计开始围绕业务稳定性、扩展性和运营成本，而不是围绕某个模型的新功能时，企业智能体才真正从实验项目进入软件工程阶段。

十一、并发与异步任务应该在架构阶段提前考虑

企业智能体在小范围试点时，常常只有几名用户同时使用，因此性能问题不明显。进入规模化之后，同一时刻可能有大量知识检索、模型推理和工具调用发生，任何一个环节都可能成为瓶颈。

同步任务适合用户需要立即获得结果的场景，例如知识查询和简单数据查询。耗时较长的任务，例如批量分析文件、生成复杂报告、等待外部系统返回，则更适合设计成异步任务。

异步任务需要任务队列、状态查询、超时和取消机制。用户提交任务之后，系统应该明确告诉用户当前状态，而不是让一个HTTP请求一直等待。

如果所有任务都采用同步模式，随着并发增加，模型队列、数据库连接和第三方API都会相互影响。架构设计时将实时交互和后台任务分开，通常能够显著提高系统稳定性。

十二、记忆体系不能等同于“把历史对话全部塞回模型”

企业智能体确实需要记忆，但记忆应该是经过设计的数据结构。

当前对话上下文用于保持短期连贯；任务记忆用于保存任务状态；用户记忆可以保存经过确认的偏好；项目记忆则保存相对稳定的业务事实。

如果把所有历史对话无限追加到上下文，不仅Token成本迅速增长，还会把已经过期的信息带入新任务。

长期记忆最好支持来源、更新时间、可信度和删除机制。某个业务事实发生变化后，旧记忆需要被更新，而不是继续与新信息同时存在。

十三、开发、测试和生产环境必须隔离

企业Agent会调用真实业务系统，因此环境管理非常重要。

开发环境可以使用模拟数据和测试接口；测试环境用于真实集成验证；生产环境则只允许经过审核的Agent版本和Skill版本访问。

不同环境的API密钥、数据库、知识索引和模型配置应该隔离。

如果开发人员为了方便直接在生产环境调试，很容易产生错误业务数据，甚至触发真实通知或操作。

智能体系统越具备执行能力，环境隔离越不能被视为传统软件的“可选规范”。

十四、架构评审时可以使用一份简单检查清单

这个Agent是否拥有清晰职责？知识和实时数据是否分开？工具是否通过标准Skill调用？复杂任务是否有持久化状态？高风险操作是否有确定性规则？权限是否由后端控制？失败是否能够通过Trace回放？模型、Prompt和Skill是否支持版本管理？系统是否允许未来替换模型？

如果这些问题大部分都有明确答案，架构通常已经具备生产化基础。

如果答案仍然是“先让大模型试试看”，说明系统仍然更接近实验原型。

真正好的企业智能体架构，不追求每个组件都最先进，而是让整个系统在复杂度增加时仍然保持可理解、可测试和可维护。