如何构建代理系统：生产AI代理缺失的架构

生产现实中的差距

智能体 AI 行业存在架构问题，但大多数人解决的方向错了。

每个人都在构建智能体。更聪明的提示词，更好的模型，然而许多项目从未进入生产阶段。智能体本身足够聪明，但架构却拖了后腿。

大多数实现方案要么过于死板（臃肿的脚手架，缺乏适应性），要么过于松散（不受约束的智能体）。在今年观察了企业客户运行的 17 亿次智能体工作流后，模式非常清晰：差距不在于智能，而在于架构。

真正有效的方案是：一个决定论骨架，在关键处引入智能。

我们处理过医疗、快消品、金融、物流和专业服务等多个行业企业的智能体工作流。DocuSign 通过这种架构提高了电子邮件的互动率，并将销售研究时间从几小时缩短到了几分钟。下面会详细介绍，这是一个非常棒的案例。

关于这个模式，有趣的一点是它在客户中表现出了自发的涌现性。我将其称为“智能体系统”（Agentic Systems）。

当前行业正陷入一种盲目竞争，试图让构建 AI 智能体变得超级简单，工具层出不穷，但绝大多数实现方案仍未做好生产准备。

它们优化的往往是构建时长或演示效果，但对于部署及部署所需的信心，核心差距仍然存在。

现状：行业为何止步不前

智能体 AI 领域的发展非常迅速。两年前，大家还在问“智能体真的存在吗？”。今天，每个人都在构建它们，各种供应商都在将自己的自动化工具重新包装为“智能代理”。

但以下方案通常会失败：

伪装成智能体的提示词链。 循环中的 LLM + 工具。调用 LLM，解析输出，链接下一次调用，点击 API，格式化响应。在文档中加上“智能体”字样并发布。这些本质上是在 LLM 中间穿插的脚本化 API 调用。如果你的用例只需要这些，那很好，但当你真正需要智能体能力时，它们会崩溃，而且如果你后续为了支持复杂性而不断扩展，复杂度会急剧上升。

重 DAG/图表，轻可维护性。 节点、边、状态机，视觉上令人印象深刻，概念上也稳妥。但随着规模扩展，生产环境似乎变成了在调试图表，而不是解决业务问题。正如一位社区成员所言：“[基于图的框架] 提供了对状态的灵活性，但一旦工作流扩展，调试的痛苦就超过了收益。”当每周都有破坏性更新时，你是在维护框架，而不是你的业务逻辑。

没有架构约束的自主智能体。 给它工具，设定目标，让它运行。这就是为什么我们看到“X% 的智能体 AI 部署被取消”之类的预测。没有架构的无边界智能体无法为企业部署关键工作流提供所需的信心。

模式似乎是每个人都在优化智能体的智力，但几乎没有人为系统架构进行设计。这是一个巨大的差距，阻碍了在实现快速构建的同时建立信心，且不会牺牲大规模环境下的可维护性。

未来的赢家不会是拥有最聪明智能体的公司，而是拥有能让智能体变得可靠、可部署且可治理的架构的公司。

而围绕智能体系统形成的这种有机模式，似乎解决了其中大部分问题。

什么是智能体系统？

从生产环境的实际需求出发，而不是看演示时有多酷，而是看当真实工作流和真金白银受到影响时你需要什么。

你需要至少具备以下特征的系统：可观测（追踪每个决策）、可治理（执行策略）、成本受控（大规模下可预测的支出）、可审计（满足监管要求）以及可维护（在扩展时不变成噩梦）。

智能体系统的架构方式是提供可组合的构建块，而不是受限的抽象，它们通过结合两个组件来实现这一点：

拥有结构的决定论骨架。 我们称之为 Flows（流程），它们定义了执行哪些步骤、顺序如何、以及具备什么护栏。Flows 是非常薄的代码层，几乎没有抽象，只有高度灵活的装饰器、状态管理和其他必要的原语，为你提供程序化控制。它们处理枯燥但关键的部分：条件分支、跨步骤的状态管理，以及你的业务所需的任何自定义逻辑。你编写的是常规代码，而不是框架配置。相同的输入，相同的执行路径，设计上可预测，事件驱动，且支持运行时修改。

部署在关键处的智能。 这是一个频谱：在低自主性侧，它可能只是一个即兴的 LLM 调用或单个智能体。在高自主性侧：是一个由多个协作智能体组成的 Crew（团队）。它们由 Flow 在特定步骤中有意调用。它们在 Flow 定义的范围内运行，完成后控制权总是返回给骨架。你获得了 AI 的适应性和推理能力，而不会引入导致部署失败的不可预测性。

在需要的地方提供结构，在关键的地方引入智能。

这种架构正是 DocuSign、KT、Konecta、美国国防部、百威英博等公司在生产环境中大规模交付业务成果所使用的架构。

构建智能体系统

架构很简单，但你需要知道界限在哪里。

如果一个步骤不需要智能、数据验证、格式化，也不需要使用已知参数调用 API，那它只需在 Flow 中作为普通代码存在。不要用智能体把事情复杂化，那些带我们走到今天的工程原则依然有效，KISS（保持简单直接）原则尤为重要。

如果你只需要单次补全，或者简单的函数调用，比如“总结这份文档”、“提取这些字段”或“分类此输入”，单次 LLM 调用就足够了，不需要智能体开销，也不需要复杂性。

如果你需要一个带有工具使用的智能任务，比如“研究这家公司并获取财务数据”或“跨多个来源验证这些凭据”，那么单个智能体可能就足够了，没有理由急于跳入完整的多智能体抽象中，它可以进行推理、使用工具并处理任务。

但当你进入更复杂的推理、协作或多步智能时，比如“在法律、财务和运营维度进行尽职调查”、“研究一个主题并撰写一份综合报告”，那么由多个智能体组成的 Crew 价值巨大：多个智能体协同工作，每个都有定义的角色，可能还会相互委派和验证工作，从自身执行中学习，可追溯、可观测，带有 PII 过滤器，包括采取行动、推理计划和在出错时进行自我修复的原生能力。

架构出错会导致什么

在有些地方本该用代码时却使用了智能体。 你无法正确调试它，成本失控，步骤的行为在某种程度上不可预测，并且每次更改都需要“测试智能体”而不是修改逻辑。

在一个智能体中塞入太多内容。 上下文窗口爆炸，太多的工具让它感到困惑，幻觉增加，这就是人们在单智能体与多智能体模式之间徘徊时碰到的天花板。

在没有架构的情况下构建复杂工作流。 当你拥有具有真实分支和状态管理的多步流程时，将智能体或 LLM 调用串联起来是不够的。你需要一个骨架。

不测试不同的模型。 在一个模型上有效的方案在另一个模型上会失败。你的架构应该让你能够更换模型而不必重写系统。

成功模式： 一个决定核心逻辑的决定论骨架（Flow），然后某些单独步骤利用不同级别的智能体，从即兴的 LLM 调用，到单个智能体，再到完整的 Crew。

DocuSign 是如何构建的

DocuSign 提高了电子邮件的打开率、回复率和转化率，同时将销售研究时间从几小时缩短到几分钟。以下是他们的构建方式。

DocuSign 是一家上市公司，年营收数十亿美元，其平台被 90% 的财富 500 强企业使用，他们面临一个根本问题：如何在不让每位销售代表都变成全职研究员的情况下，大规模地实现客户互动的个性化？

在我们上一次 CrewAI Signal 大会上，他们的首席 AI 架构师 Vamsi 和首席数据工程师 Dhruv 分享了他们如何将销售拓展系统构建为一个智能体系统。

考虑到他们的业务渗透率，规模是他们首要考虑的问题，销售代表不能花费数小时研究客户、阅读公司报告、查看最新新闻并定位产品，然后才能撰写一封电子邮件。

DocuSign 迅速采用了 CrewAI Flows，以下是 Vamsi 和 Dhruv 协助率先推出的架构部分：

该 Flow 实现了核心的决定论骨架，并委派给一组协作的专门智能体，这些智能体能够从 Salesforce 和 Snowflake 获取数据，并应用业务规则来决定资格和匹配度。

通过幻觉护栏（CrewAI 企业版的一项功能），他们能够在运行时对特定条件做出反应，并实施质量验证流程，确保最终结果达到高标准。

Flow 贯穿全程管理状态、分支和验证。 每个智能体都从前面的步骤获取上下文。研究员提供给撰写者。撰写者提供给验证者。但核心控制权总是返回给 Flow，当某些内容需要人工审查时，Flow 会适当地路由它，当智能体失败时，Crew 会优雅地处理它。

他们对此进行了严格的 AB 测试。 同一批客户，同一时期，一部分接收 Crew 生成的拓展信息，一部分接收代表生成的，智能体在参与指标上达到或超过了人类代表，同时大大缩短了周转时间。以前代表需要花费数小时的工作，系统只需几分钟，且电子邮件打开率提高了，回复率提高了，转化率也得到了改善。

成功的关键：

智能体是可复用的，工具也是（通过 CrewAI 企业平台中的内部智能体和工具存储库）。DocuSign 现在正在组织内的不同用例中使用相同的智能体架构，而不仅仅是销售拓展。这就是将结构（Flow）与智能（Crew）分离的力量。

Flow 强制执行不可协商的业务规则，智能体不决定是否执行这些步骤。它们提供在这些步骤内的智能。

来自 Vamsi 和 Dhruv 的关键洞察： 每个智能体都在 Flow 定义的清晰边界内运行，它们不是自由漫游的，而是在特定步骤中被调用的专用智能，完成特定的工作，然后归还控制权。

为什么这很重要

系统中的不同部分将以不同的速度演进

稳定部分（具有清晰规则的深入了解的流程）：可能永远不需要太多智能体功能。保持简单、快速和低成本。

实验部分（新用例、不确定的需求）：开始时赋予更多智能体能力以探索可行方案，随着模式的出现，将其固化为结构化的 Flow。

合规关键步骤（监管要求、审计追踪）：即使模型改进，结构也保持不变，你不会将合规性赌在模型的行为上。

成本敏感容量：当成本下降时增加智能体功能，当成本激增时调低。相同的架构，不同的设置。

从长远来看，获胜的团队不是那些追逐最新模型能力或最炫酷框架功能的团队。而是那些构建了能够维护、调试并快速演进系统的团队，同时确保在两年后，当半数团队人员更换且需求发生了没人预料到的变化时，系统依然稳健。

我们讨论的架构决策具有直接的业务影响。

可预测的成本。当你控制智能体存在的位置时，你就控制了支出。为高价值工作流调高智能，为常规工作流调低。像预算基础设施一样预算 AI。

更快的迭代。可维护的系统意味着在几周内而不是几个季度内发布新用例。DocuSign 从一个用例扩展到整个组织的多个用例，因为架构是可复用的。

降低风险。可观测、可治理的系统意味着你实际上可以在受监管行业进行部署。医疗保健、金融、法律，这些“通常有效”还不够的地方。

竞争壁垒。当你的系统随着每一次执行变得更聪明时，竞争对手就无法仅仅复制你的提示词来赶超。架构会随着时间推移复合你的优势。

这不仅仅是更好的工程，更是更好的业务。

这一切正在发生

我们谈论的不是某种未来的愿景，智能体系统现在就在生产中运行，财富 500 强医疗保健公司正在处理凭证工作流。金融服务公司每月进行数千次风险评估。物流运营不能容忍停机。这些不是演示，而是人们押注职业生涯的系统。

模式是什么？每次都是相同的架构。Flows 管理结构和合规性。Crews 在关键地方提供智能。记忆使系统在每次运行中变得更聪明。当某些地方出错时，工程师实际上可以调试它，因为架构不会妨碍他们。

如果你准备好构建在生产中真正有效的系统，架构就很直观。从可靠性开始。为可维护性设计。让智能留在关键的地方，在需要的地方使用结构。

企业处理智能体的方式主要有两种。

一些人将其视为工程项目——评估原语、比较开发者工具、通过追踪和指标衡量成功。

另一些人将其视为转型——通过生产中的用例、交付的业务成果、大规模运行的系统来衡量成功。

未来不属于拥有最聪明智能体的团队。它属于拥有最强大骨架的团队。