构建企业级智能体工作流之前，你需要理解的7个层次

原创

learnaitogether
learnaitogether

安全行者老霍

2026年6月4日 08:00
美国

在小说阅读器读本章

去阅读

作者：Alex Wang

发布时间：2026年5月21日

你可能已经在构建智能体工作流了，只是没有意识到。

一家公司从\"我们想构建智能体\"开始，但工作很快就延伸到工作流设计、数据访问、工具、权限、可靠性和评估。

一旦AI开始接触内部数据、业务系统、客户记录、审批流程或运营决策，它就成为了工作完成方式的一部分。

这就是事情变得更复杂的地方。

AI作为一种技术正在快速演进，但围绕它设计工作流依然充满挑战。

那么，让我们来看看企业在规模化构建智能体工作流时，需要考虑哪7个层次。

1. 在引入智能体之前，先找到真正的工作所在

第一个层次是工作流设计：决定AI实际上应该嵌入工作的哪个环节。

这听起来显而易见，但很多智能体项目正是在这里走错了方向。一个团队从\"我们需要一个AI智能体\"出发，而更好的起点其实是工作流本身。

今天的工作是什么？它在哪里变慢？在哪里需要判断？哪里是重复性的但仍然依赖上下文？自动化在哪里有帮助，在哪里会带来风险？

并非每个流程都需要一个完全自主的智能体。

有些工作流需要AI来分类、摘要、起草或推荐。

有些需要AI采取有限的行动。

有些应该以人为主导，AI辅助决策而不是替代决策。

客户支持工作流是一个简单的例子。

一个AI系统可以对问题进行分类、检索退款政策、查询订单状态、起草回复并建议下一步操作。但这并不意味着它应该自动批准每一笔退款。

一个更实际的工作流可能是这样的：

• AI对请求进行分类
• 检索引入相关政策
• 一个工具查询订单状态
• 智能体起草回复
• 一条规则判断是否需要审批
• 人工审批敏感案例
• 系统记录最终决策

这才更接近企业级智能体工作流应有的样子。

重点不是最大化自主性，而是恰当的自主性。

这个区别很重要，因为最自主的工作流并不总是最有价值的。在很多企业场景中，最好的智能体工作流是AI有明确职责、明确边界、以及明确停止点的那种。

也许少了一些魔法感。

但可部署性强多了。

2. 这不是一件聪明的事，而是许多平凡的事连接得很好

第二个层次是系统设计：以真正能支撑起来的方式，将模型与工作流的其余部分连接起来。

这是很多关于智能体的讨论变得过于以模型为中心的地方。

模型当然重要。但在企业工作流中，模型只是整个系统的一部分。真正的设计问题在于，模型如何与周围的工具、数据、规则、人员和系统连接起来。

一个严肃的智能体工作流通常包含几个普通但重要的部分：

• 用于推理或生成的模型
• 用于行动的工具
• 用于知识获取的检索
• 用于约束条件的业务规则
• 用于连续性的记忆或状态
• 用于敏感步骤的审批流程
• 用于持续改进的日志和监控

这些听起来没有\"自主AI员工\"那么令人兴奋。

但这才是真正价值所在。

一个更新CRM记录的销售智能体，需要账户上下文、历史对话、交易阶段、权限规则，以及起草消息和发送消息之间的明确区分。

一个协助处理发票的财务智能体，需要区分数据提取、异常标记、审批路由和触发付款。

一个商务出行智能体需要公司政策、优选供应商、预算限额、出行人员偏好、审批要求和费用报销上下文。

在所有这些案例中，\"智能体\"本身并不是产品。

工作流才是产品。

AI是其中的一个层次。

这也是为什么主要的企业AI平台越来越多地从工作流、数据、治理、测试和监督的角度来谈论智能体。市场正在远离\"只需添加一个更智能的聊天界面\"的想法，转向能够在业务流程内部运行的托管系统。

这个方向是有道理的。

企业AI不会因为坐在工作流旁边就变得有用。

它在被设计进工作流的时候，才变得有用。

3. 你的智能体只有你给它的工具那么好

第三个层次是工具设计：定义AI实际上能做什么。

这是\"智能体\"这个词可能会产生一些误导的地方。它让这个系统听起来拥有广泛的独立能力。而实际上，智能体是通过你给它的工具来行动的。

这些工具塑造了它真实的能力边界。

如果工具定义模糊、范围太宽或设计欠佳，智能体就不得不去猜。而当工作流涉及客户、资金、合规或内部系统时，猜测并不是一个好的运作模式。

一个好用的工具应该让正确的操作更容易，让错误的操作更难。

对于非技术团队来说，重要的问题不是API语法，而是工具的边界：

• 这个工具能做什么？
• 它能访问哪些数据？
• 它能采取什么行动？
• 它永远不应该暴露什么？
• 哪些决策超出了它的范围？
• 输入不明确时会发生什么？

例如，一个支持智能体可能不需要一个模糊的\"客户数据\"工具来返回所有可用信息。

它可能只需要订单状态、套餐类型和近期工单记录。

它可能不需要支付详情、私人备注，或对客户记录的宽泛搜索访问权限。

更好的设计不是\"给智能体更多访问权限\"。

而是给智能体完成工作所需的那个精确工具。

这是工具设计在智能体系统中变得如此重要的原因之一。

Anthropic在其关于智能体的文章中也提出了类似的观点：提升智能体性能并不总是要修改提示词。有时候，工具本身需要一个更清晰的名称、更窄的用途、更好的输入格式，或者更可预测的响应。

4. 垃圾上下文，自信答案

第四个层次是上下文设计：确保AI在使用正确的信息工作。

这在企业内部尤为重要，因为大多数企业价值并不存储在基础模型里。

它存在于内部文档、政策、客户记录、合同、工单、会议记录、产品规格，以及多年来积累的所有杂乱运营知识之中。

其中有些是有用的。

有些已经过时。

有些与六个月前另一个团队写的另一份文档相互矛盾。

很美妙。

这是很多公司低估问题严重性的地方。他们把模型连接到一个文档文件夹，然后期待企业智慧自动涌现。

并非如此。

使用错误政策文档的支持智能体没有任何帮助。引用过时条款的法律助手是有风险的。将上季度数字与本季度报告混在一起的财务智能体，可能用非常专业的语气输出充满自信的废话。

一个精致的错误答案仍然是错误的。

只是穿得更好看了。

对于企业智能体工作流而言，上下文设计意味着知道系统应该信任哪些信息、何时应该检索它、谁有权访问它，以及答案是否能追溯到正确的来源。

至少，团队需要考虑：

• 来源质量：哪些文档、数据库或系统是可信的
• 新鲜度：智能体使用的是否是最新版本
• 访问控制：用户和智能体是否被允许查看该信息
• 相关性：是否为当前任务检索了正确的上下文
• 可追溯性：输出是否能与来源关联起来

这就是为什么\"我们把文档连接到了AI助手\"和\"构建企业智能体工作流\"并不是一回事。

系统需要理解哪些知识对哪项任务重要。它还需要知道，当文档检索还不够用时，工作流应该使用结构化数据库查询、特定工具，还是人工核查。

上下文不是背景素材。

上下文是模型的运行环境。

如果这个环境一团糟，智能体不会仅仅因为界面看起来干净就神奇地变得可靠。

5. 真实的工作流没有演示那么配合

第五个层次是可靠性设计：规划工作流行为异常时该怎么办。

演示通常非常配合。

用户提出预期的问题，工具正常工作，数据可以获取，智能体返回一个干净的答案。所有人点头，也许有人说\"这将改变一切\"。

真实的工作流就没那么配合了。

工具会失败，数据会不完整，交接会丢失上下文，而简单的请求往往会触及比预期更多的系统。

这些不是什么奇特的AI问题。

这些是普通的运营问题，只是中间多了一个模型。

对于企业领导者来说，这个层次很重要，因为可靠性不只是一个技术问题，它是一个信任问题。

如果智能体悄悄失败、陷入循环、采取了错误的行动，或者假装某件事成功了但实际上没有，用户会很快停止信任它。

他们应该这样做。

一个可靠的智能体工作流需要对实际问题给出清晰的答案：

• 工具失败时会发生什么？
• 系统应该在什么时候重试？
• 什么时候应该停止？
• 什么时候应该通知用户？
• 什么时候任务应该转给人工？
• 部分完成的情况如何处理？
• 系统如何避免重复执行同一个失败的操作？

这不是智能体AI中闪光的部分。

但这是决定人们是否会不止用一次的部分。

自主性只有在工作流能够处理摩擦时才有价值。

否则，智能体就变成了一种更快地制造运营混乱的方式。

非常未来感。

非常不方便。

6. 不要给实习生管理员权限

第六个层次是权限与人工审批设计：决定AI被允许查看什么、决定什么、以及修改什么。

这是企业智能体工作流中最重要的层次之一。

这也是\"智能体即员工\"这个比喻可能变得危险的地方。一个人类实习生第一天不会获得完整的管理员访问权限。AI智能体也不应该。

问题不仅仅在于提示词注入或安全攻击，尽管这些都很重要。更大的日常问题是权限设计。

财务智能体可以汇总发票，但付款审批可能应该需要人工或基于规则的控制。

客户支持智能体可以起草退款回复，但发出退款可能取决于政策、客户级别、欺诈检查和审批阈值。

销售智能体可以建议下一步行动，但向数千条线索发送对外邮件，不应该是一个开放性的模型决策。

企业工作流需要明确的区分：

• 读访问权限不同于写访问权限
• 起草不同于发送
• 推荐不同于审批
• 检索数据不同于暴露数据
• 低风险自动化不同于高影响行动

这不只是\"安全规范\"。

这是工作流设计。

最安全的智能体系统不是那个安全提示词最长的。而是AI在明确权限内运作、在风险较高的地方设有审批关卡的那种。

好的智能体工作流不给AI无限的自由。

它给AI在精心设计的边界内的有用自由。

这个区别很重要。

尤其是当这个\"实习生\"现在可以调用API的时候。

7. 感觉良好不是一种评估策略

第七个层次是评估：知道工作流是否真的在正常运转。

不是\"我们测试了一下，感觉好像更好了\"。

而是真正的评估。

智能体工作流比简单的聊天机器人更难评估，因为最终答案只是结果的一部分。你还需要理解系统走过的路径。

一个好的最终答案可能仍然来自错误的来源。

一个任务可能成功一次，但在边缘案例上失败。

一个工具可能被正确调用，但时机不对。

一个系统可能是准确的，但太慢或太贵，无法规模化使用。

对于领导者来说，关键是评估整个工作流，而不只是最终响应。

这意味着要关注以下信号：

• 智能体是否使用了正确的来源
• 它是否选择了正确的工具
• 行动是否保持在权限边界内
• 在需要时是否发生了人工审批
• 结果对该用例而言是否足够准确
• 延迟和成本是否合理
• 失败是否可以被追踪和改进

这是智能体工作流成为运营基础设施的地方。

这也解释了为什么Salesforce Agentforce等平台越来越强调的不只是构建智能体，还有在业务工作流中对其进行测试、监督和持续优化。这种定位反映了一个更广泛的转变：企业智能体需要生命周期管理，而不仅仅是上线当天的兴奋感。

原因很简单。

如果你看不到智能体做了什么，你就无法改进它。

你只能猜。

而猜测并不能很好地规模化，即使猜测配上了更好看的界面。

真正的转变

企业AI采用的下一个阶段，不是关于企业是否能添加智能体。

他们可以。

更有用的问题是，这些智能体是否能够安全、清晰、可衡量地参与真实工作。

这才是真正的差距所在。

工作流从未被重新设计。工具太模糊。数据层一团糟。权限太宽泛。失败路径被忽视。评估过程太浅。人工交接被当作事后补充。

这就是为什么企业智能体工作流需要这七个层次。

不是因为每家公司明天就需要七个新团队。

而是因为领导者需要理解，在模型周围需要存在什么，智能体AI才能在运营中真正发挥作用。

做好这件事的公司，不会把智能体当作聊天框里的神奇员工。

他们会把智能体当作一个新的工作流层次。

这意味着设计AI适合在哪里、它可以访问什么、它可以做什么、它在哪里停止、人类在什么时候介入，以及系统如何随着时间推移持续改进。

这才是真正的转变。

不是从人到AI的转变。

而是从孤立的AI工具，到真正能够参与工作的智能体工作流的转变。

https://www.linkedin.com/pulse/7-layers-understand-before-building-enterprise-agentic-alex-wang-nmhbc/

（完）