代理还是工作流？企业人工智能中推理与执行的分离
使用智能体处理意图与信息检索，再用确定性工作流处理事务：RAG、LangGraph、MCP、审批流程及SQS如何共同构成更安全的架构。
来源: Agentic AI Architecture: A Practical Guide to RAG, LangGraph, MCP and AWS
智能代理 AI 是当前的热门话题。给大型语言模型配备一些工具、增加内存，将其接入企业系统，让它自行决定下一步该做什么，这样产生的实体就被称为 AI 代理。不过这其中存在一个问题：企业系统无法完全依赖概率决策来运行。当 AI 涉及供应商记录、财务流程、ERP 数据、审批或其他关键操作时，有些决策可以保持灵活性，而有些则不行。
一个基于 RAG、LangGraph、MCP、人工审批以及 Amazon Bedrock 构建的供应商管理项目让团队形成了一个核心理念：应由代理决定需要执行什么操作，而应用程序则负责控制操作的执行方式。设计中的其他所有内容都是基于这一分工确定的。
为何代理不应包办一切
想象一下供应商录入请求：创建该供应商，验证其详细信息，检查采购政策，然后将其发送到SAP系统。理论上，完全自主的智能体可以理解该请求，检索内部文档，验证数据，判断是否需要审批，连接至SAP系统，创建记录，并在失败时重新尝试。
从技术上讲这是可行的，但从架构角度而言并不理想。大型语言模型是基于概率运行的。相同的输入可能会经过略有不同的推理路径，而且模型、提示词和上下文都会不断变化。这种灵活性对于理解人的意图非常有用，但却不适合执行关键的业务交易。模型不应决定数据库事务是否提交，也不应自行设计重试策略、判断是否可以跳过授权流程或持有SAP系统凭证。这样一来，推理与执行就被分开了。
工作流与智能体
这两个术语经常被混用，但它们之间存在重要区别。AI工作流遵循的是预先定义好的路径：
Request
↓
Validate
↓
Retrieve Policies
↓
Evaluate
↓
Approval
↓
Create Supplier
↓
Publish Integration Event
该应用程序知晓所有的状态及状态转换。而人工智能代理在决定下一步行动时拥有更大的自由度：
User Request
↓
LLM
↓
Reason about intent
↓
Choose next capability
↙ ↓ ↘
Search Validate Request Approval
那种自由具有价值，但当智能体接触到事务处理基础设施时就会带来风险。理想的设计是将这两种模式结合起来。
上层为智能体推理，下层为确定性执行
从高层次来看，该架构如下所示：
USER
│
▼
FastAPI API
│
▼
LangGraph
Agent Workflow
│
┌───────────┼───────────┐
▼ ▼ ▼
RAG Reasoning Tools
│
▼
Amazon OpenSearch
│
▼
AWS Bedrock
│
▼
MCP Boundary
│
▼
Application API
│
▼
Domain / Use Cases
│
┌───────┴───────┐
▼ ▼
PostgreSQL AWS SQS
│
▼
SAP
有一个边界尤为突出：大语言模型位于应用层之上。它能够解析请求、进行推理、检索知识、推荐行动并调用工具，但并不掌控整个交易流程。
智能体发挥作用的位置
概率推理在某些特定场景中能发挥重要作用。
理解意图
人们不会编写结构完美的 API 调用。例如，用户可能会表示需要为巴西的业务接入 ACME 服务，并想知道相关操作是否符合规定。这样的句子包含了意图、背景信息以及模糊之处，而大语言模型很擅长将其转化为应用能够处理的格式：
{
"intent": "supplier_onboarding",
"supplier": "ACME",
"country": "BR",
"requires_policy_validation": true
}
之后，由确定性软件接管处理。
利用RAG获取企业知识
入驻流程取决于内部政策：所需文件、税收规则、各国特定要求、采购限制以及审批门槛。系统无需将这些文件直接放入提示词中或硬编码每条规则，而是可以从中检索这些信息：
Question
↓
Embedding
↓
Amazon OpenSearch
↓
Relevant Policy Chunks
↓
LLM Context
↓
Reasoning
这里还有第二个界限。检索功能仅提供上下文信息，不得参与业务决策。找到规定超过一定阈值的供应商需要获得批准的策略会很有帮助。而确保该批准流程仍属于常规应用逻辑则更为关键。
工作流的优势所在
一旦理解了请求内容，假设需要创建一个供应商。该流程可能包括以下步骤：
Validate Supplier
↓
Check Duplicate
↓
Check Authorization
↓
Persist Supplier
↓
Publish Integration Event
↓
Wait for SAP Result
大型语言模型不应自行即兴处理此类任务。工作流程必须明确规定执行保障措施：验证、授权、幂等性、重复数据防止、重试机制、审计日志、事务边界以及错误处理。这些都是软件工程需要考虑的问题，提示词工程与之无关。
为何选择 LangGraph
在任务协调方面，选择 LangGraph 是因为它提供了明确的状态转换机制，而非让智能体不断自行决定下一步该调用哪个工具的循环模式。从概念上来看，其结构如下图所示：
START
│
▼
Understand Intent
│
▼
Retrieve Policies
│
▼
Evaluate Request
│
├───────────────┐
│ │
▼ ▼
Approval Needed? No Approval
│ │
▼ │
Human Approval │
│ │
└───────┬───────┘
▼
Request Action
│
▼
END
在选定的节点内部，模型可自由进行推理，而图结构则限制了其结论对系统产生的影响范围。这样便形成了有界限的自主性：在明确界定的架构框架内享有自由。
“人在回路中”有多种含义
企业人工智能领域的讨论往往简化为“只需在流程中加入人工干预”。但实际上人们介入的原因各不相同，至少有两种类型的审批值得区分开来。
业务审批
无论是否涉及人工智能，业务流程本身都需要相应的批准环节：
Supplier
↓
Compliance Check
↓
Manager Approval
↓
Creation
AI工具审批
由于智能体想要执行敏感操作，因此需要再次进行审批：
Agent
↓
"Create supplier"
↓
Tool requires confirmation
↓
Human approves
↓
Application executes
这两个问题有所不同。一个属于领域范畴，另一个则涉及人工智能治理。将它们混为一谈会导致架构上的混乱。
MCP为何重要
要与企业系统协同工作的智能体需要相应的工具，但直接将基础设施暴露给大语言模型会带来不必要的风险。更好的方式是通过MCP工具来实现：
Agent
↓
MCP Tool
↓
Application API
↓
Use Case
↓
Domain
↓
Infrastructure
并且避免将代理与数据库连接：
Agent
↓
PostgreSQL
或直接发送至SAP：
Agent
↓
SAP
对于第一个架构，应用程序仍负责控制身份验证、授权、数据校验、业务规则、审计、事务处理以及重试机制。MCP成为了人工智能推理与企业功能之间的边界：智能体负责表达意图，而应用程序则负责执行操作。
SAP不应依赖大语言模型持续在线
外部系统可能会出现故障，SAP也可能停止运行，网络连接可能中断，下游服务可能会出现超时情况，大语言模型提供商同样可能下线。在智能体循环中同步处理所有操作会降低系统的弹性，这就是需要使用AWS SQS进行异步消息传递的原因。而不是采用这种方式：
Agent
↓
SAP
↓
Wait...
↓
Timeout
流程变为：
Agent
↓
Application
↓
Persist State
↓
AWS SQS
↓
Integration Worker
↓
SAP
业务交易不再需要等待 SAP 立即响应。有专门的工作人员负责处理重试、延迟策略、死信队列、可观测性以及幂等处理，而这些保障来自确定性软件而非某种模型。
混合架构
在明确了这些边界之后，再将该系统简单地视为 AI 智能体已不再合适。它实际上是一种混合架构：
┌─────────────────────────────┐
│ PROBABILISTIC LAYER │
│ │
│ LLM │
│ RAG │
│ Intent Understanding │
│ Reasoning │
│ Tool Selection │
└──────────────┬──────────────┘
│
Controlled Boundary
│
┌──────────────▼──────────────┐
│ DETERMINISTIC LAYER │
│ │
│ Application Use Cases │
│ Domain Rules │
│ Authorization │
│ Validation │
│ Transactions │
│ Idempotency │
│ Messaging │
│ Integrations │
└─────────────────────────────┘
这种区分对企业级代理型人工智能而言至关重要。
软件架构依然重要
在生成式人工智能领域，一个常见的错误是认为传统架构已不再重要。实际上它更加重要。一个能够动态推理并选择行动的系统，需要对其可执行的动作设置更严格的限制。领域驱动设计、命令查询响应模式、六边形架构、身份认证、授权机制、消息传递、可观测性、弹性以及幂等性这些概念依然适用。人工智能并不会消除它们中的任何一项，只是增加了一个必须与它们安全共存的概率性组件。
代理还是工作流？
答案是两者皆有。在不确定性和推理能创造价值的情况下使用代理，在可预测性和确定性至关重要的情况下则使用确定性的工作流。一个实用的心智模型是：
AI AGENT
│
│ decides WHAT
▼
┌─────────────────┐
│ Controlled Tool │
│ Boundary │
└────────┬────────┘
│
│ requests
▼
APPLICATION
│
│ decides HOW
▼
DOMAIN
│
▼
INFRASTRUCTURE
大型语言模型不应成为整个架构，而应作为其组成部分参与其中。
自主性的价值所在
重要的问题不在于模型能被赋予多大的自主权，而在于自主性能在何处创造价值。自主性适用于理解模糊的请求、在大量内部文档中搜索信息、结合上下文进行推理并提出下一步行动。但它并不适合用于绕过业务规则、管理交易或处理生产数据库的凭证。
目标在于实现受控的自主性，在企业系统中这意味着将概率性的人工智能推理与确定性工程方法相结合。接下来自然会产生的问题是：当智能体需要访问SAP系统或数据库时，这一边界究竟应如何设定？