AI 智能体与智能体工作流：区别及适用场景

AI 智能体是一种由模型驱动的工作者，它可以选择行动、使用工具，并根据结果调整下一步操作。而智能体工作流则是围绕一个或多个此类工作者构建的更大规模、受控的流程：它定义了触发器、数据流、审批、重试和完成规则。当任务需要有限的判断力时使用智能体；当这种判断力必须在业务流程中可靠运行时，则使用智能体工作流。

这一区别之所以重要，是因为团队经常购买或构建“智能体”，而他们真正的问题其实是编排问题。一个能分类异常支持请求的有用助手，本身并不能提供安全的路由请求、保护客户数据、申请退款批准以及记录发生情况的方法。这些控制权属于工作流。

什么是 AI 智能体？

AI 智能体是利用 AI 模型通过一个或多个行动来实现目标的软件。在实践中，它接收上下文，决定下一步做什么，调用可用工具，观察结果，然后继续或停止。工具使用可能包括搜索知识库、读取工单、调用 API、起草回复或向人类询问缺失的信息。

这一定义是有边界的。仅生成文本的聊天界面不一定是智能体，固定的计划脚本也不是。模型需要具备一定的受控能力，根据证据选择行动或改变路径。OpenAI 的 构建智能体的实用指南 建议从能解决问题的最小工作流开始。

智能体应拥有的职责

• 解释杂乱但允许的输入，例如客户的自由文本请求。
• 选择检索查询或决定下一个调用的已批准工具。
• 总结证据、起草建议或分配置信度等级。
• 在证据缺失、指令冲突或行动超出其权限时进行升级。

智能体不应悄悄拥有身份验证、权限更改、支付释放、保留策略或不可逆的生产更改。它可以准备这些行动并展示相关证据。确定性控制或授权人员应决定是否允许该行动。

什么是智能体工作流？

智能体工作流是一个业务或技术流程，它将一个或多个智能体与确定性软件结合使用。它指定启动工作的时间、智能体可查看的输入、可使用的工具、检查点、状态存储、重试策略、人工审批以及最终的系统记录。即使某些步骤中没有智能体，整个工作流仍可能是智能体的，因为它将模型驱动的判断置于受治理的流程中。

可以将工作流视为运行环境。它限制了智能体能做什么，并使结果具有足够的可重复性以供检查。Google 的 智能体 AI 系统设计模式 同样将模型主导推理的模式与编排、评估和操作控制的模式分开。

工作流应拥有的职责

• 触发器、队列、截止日期、交接和幂等键。
• 工具白名单、凭据、策略检查和数据最小化。
• 资金流动、外部通信、访问更改和破坏性操作的人工审批关卡。
• 重试、回退、日志记录、质量检查和明确的终端状态。

这种划分并非为了官僚主义。模型输出随上下文变化，可能会以合理的方式出错。工作流创建了一个地方，可以在结果到达客户、数据库或外部系统之前验证结果。

AI 智能体与智能体工作流：对比表

何时 AI 智能体就足够了

当结果是咨询性的、容易逆转的，并且在产生它的同一界面中进行审查时，单独的智能体就足够了。例子包括返回源链接的研究助手、生成草稿的会议笔记助手，或建议故障排除路径的内部支持助手。在这些情况下，智能体节省了时间，但不会成为最终权威。

即使是这种情况，也要给智能体一个狭窄的工具集。支持助手可以搜索批准的文档并创建草稿工单，但不需要直接修改用户账户的权限。尽可能使用只读工具，只有在能够衡量建议的质量后，才暴露写工具。

何时需要智能体工作流

当工作跨越系统、对业务有实质性影响，或者必须在没有人监视聊天的情况下可预测地完成时，请构建智能体工作流。常见的信号包括面向客户的信息、生产写入、受监管的数据、截止日期、成本阈值或需要证明决策原因的需求。

考虑应付账款收件箱。智能体可以读取发票，提取字段，将其与采购订单进行比较，并解释差异。工作流检查发送者，验证字段，应用支出规则，在超过阈值时请求批准，并发布带有审计跟踪的已批准记录。单个自主智能体会使该过程更难审计。

实用的决策测试

在决定引入多少智能体行为之前，回答以下问题。右栏中的“是”通常意味着任务需要工作流控制，即使智能体执行其中的一部分。

最后一行是团队经常忽略的。固定的夜间导出、必填字段验证或已知的 API 转换并不会因为涉及 LLM 而变得更好。当规则稳定时，传统自动化更便宜且更容易解释。有关该边界的更多详情，请参阅 如何在 AI 智能体和 RPA 之间进行选择。

如何分六步设计智能体工作流

1. 定义决策，而非模糊的雄心

写下智能体可以做出的确切决策。“解决支持工单”太宽泛。“将传入的请求分类为计费、访问或技术支持，并起草下一个回复”是可测试的。同时定义允许的工具、所需的证据和停止条件。

2. 将判断与执行分离

让智能体返回结构化建议：类别、置信度、证据链接、提议的行动和升级原因。确定性服务应验证该形状，强制执行策略，并执行任何批准的写入。这种模式使得在不更改操作控制的情况下更容易更改模型。

3. 按行动设定权限，而非职位

赋予不同行动不同的要求。阅读公共知识库可能是自动的。发送外部电子邮件可能需要置信度阈值和模板。发放退款或更改权限应要求明确的批准者。相关问题是行动会影响什么，而不是智能体以前是否执行过类似的任务。

4. 将工具结果视为不受信任的输入

文档、网页和 API 字段可能包含与任务冲突的指令。将不受信任的内容与系统指令分开，根据模式验证工具参数，并将工具限制在最小范围。OWASP 的 提示注入指南 解释了为什么检索到的文本不能被视为权威。

5. 在设计成功路径之前设计故障

指定当工具超时、下游系统返回重复事件、所需字段缺失或智能体的置信度较低时会发生什么。重试网络请求可能没问题；在没有幂等键的情况下重试支付提交则不行。记录运行标识符和外部行动标识符，以便工作流可以安全恢复。

6. 评估完整路径，而不仅仅是模型响应

测试代表性案例、对抗性输入、工具中断和策略边缘情况。测量最终结果是否正确，智能体是否使用了允许的工具，是否在需要时进行了审批，以及工作流是否安全停止。SmaugBrain 的 AI 智能体评估指南 更详细地涵盖了测试集和回归验收。

示例：将支持智能体转变为智能体工作流

基本的支持智能体接收客户消息并起草答案。这可能很有用，但它留下了几个实际问题：客户经过身份验证了吗？答案基于当前文档吗？消息是否请求更改账户？消息实际上发送了吗？

受控的工作流可以按以下顺序处理相同的请求：

1. 接收工单并分配持久的工作 ID。
2. 获取策略允许的客户和产品上下文。
3. 要求智能体对请求进行分类并生成引用的草稿。
4. 验证输出模式并根据策略检查请求的行动。
5. 通过批准的模板发送低风险回复，或将高风险案例路由给人工。
6. 记录结果并保留后续审查所需的证据。

智能体仍然做受益于语言理解的部分。工作流使结果具有操作性。

常见的设计错误

不要给智能体一个广泛的工具集，因为它以后可能有用。每个工具都扩大了行动表面，并使评估更加困难。使用代码进行验证、路由、限制和政策执行；让模型解释证据或做出有限的建议。成功的模型响应也不能证明作业成功。确认下游系统接受了请求，并且重复事件没有产生额外效果。

不要在建立评估集之前引入自主权。以草稿模式运行，收集真实示例，并审查错误。只有当预期的错误成本、检测方法和回滚路径被理解时，才将狭窄的行动转换为自动执行。有关特定于审批的控制措施，请参阅 AI 智能体审批工作流。

SmaugBrain 的定位

SmaugBrain 在团队需要智能体在批准的工具上工作，同时保持工作可见和可控的地方最有用。实际的部署始于狭窄的任务、明确的权限和审查路径。将工作流逻辑保持在提示之外：在周围的系统中定义触发器、工具边界、记录和审批规则。在 SmaugBrain 了解更多。

常见问题

所有使用 LLM 的工作流都是智能体工作流吗？

不。将固定提示发送给 LLM 并存储输出的工作流可能是 AI 辅助自动化。当模型可以在定义的控件下做出有限选择、使用工具或影响下一步时，它就变成了智能体工作流。

智能体工作流可以使用多个 AI 智能体吗？

是的，但多个智能体并不自动更好。仅在职责、输入和交接明确时才拆分工作。一开始，具有有限工具集的单个智能体通常更容易评估和操作。

应该允许 AI 智能体自动发送客户电子邮件吗？

对于低风险、经过充分测试的消息类型，具有清晰的模板和监控，这是合适的。对于账户更改、敏感数据、法律承诺或升级，要求在发送之前进行审查或更强的策略检查。

智能体工作流会取代 RPA 吗？

不会。RPA 仍然是稳定、基于规则的任务的良好选择。智能体工作流可以为确定性步骤调用传统自动化，并仅在语言、文档或例外需要判断时使用智能体。

如何知道智能体是否应该拥有记忆？

仅存储改善定义的未来决策的信息，并且拥有所有者、保留规则和纠正路径。不要将记忆视为每段对话或工具结果的通用存档。

最安全的初始部署模式是什么？

在工作流中使用只读或生成草稿的智能体，该工作流记录输入、输出、工具调用和审查者决策。在启用狭窄、可逆的自动操作之前，从这些工作中建立评估集。

要点

AI 智能体在受限任务内贡献判断。智能体工作流通过定义其周围的控制流、权限、审批、重试和记录，使这种判断在生产中有用。从具有实际益处的最小模型驱动决策开始。保持执行控制显式，并在规则已经稳定的地方使用传统自动化。