企业架构中的 Agentic AI

当企业 AI 项目不再停留在孤立的提示交互，而开始像经过设计的系统那样运作时，它们才真正具备战略意义。到了 Agentic AI 这一步，这种变化会更加明显：一旦模型能够规划、调用工具、生成产物并与业务流程交互，架构问题就会完全改变。

很多团队仍然把 Agentic AI 当成“更高级的聊天机器人体验”来评估。但在现实中，它更像一个分布式应用层：同时触及身份、权限、流程逻辑、知识检索、可观测性以及人工监督。

为什么 Agentic AI 在架构上完全不同

传统生成式 AI 试点通常聚焦于交互质量：提示设计、模型选择以及输出是否有用。

而 Agentic 系统引入了另一层责任，因为它们可以：

• 进行多步推理，而不只是一次性回答
• 调用工具、API 和内部服务
• 更新记录、触发动作或生成下游产物
• 在循环中运行，让一个输出成为下一步的输入

从这个时刻开始，真正重要的不再只是模型本身，而是架构。编排质量、权限边界、上下文控制与恢复逻辑都会成为产品的一部分。

为什么企业 operating model 也必须变化

当 AI 开始在真实工作流中行动时，核心挑战已经不再是“模型能不能做出令人惊艳的事情？”

真正的问题变成了：“这项能力能否在企业环境中安全、可重复、可衡量地运行？”

这意味着必须设计好：

• 面向角色的身份体系以及对工具和知识的访问控制
• 面向不同任务与供应商的模型路由与回退机制
• 检索质量、上下文完整性与来源可追踪性
• 评估、审计能力与上线后的持续监控
• 在高影响或低置信度场景中的 human-in-the-loop 控制

如果缺少这样的 operating model，Agentic AI 往往只能停留在 demo 层面，而无法成为可靠的业务能力。

真正的战略问题是什么

错误的问题是：“我们应该选择哪个 agent framework？”

更重要的问题是：“在允许 AI 系统于业务流程中进行推理和行动之前，必须具备哪些架构与治理条件？”

这正是企业架构需要把 use case 雄心与交付纪律重新连接起来的地方。风险、所有权、韧性以及可衡量价值，必须从一开始就进入设计讨论，而不是等到第一个试点已经制造了兴奋之后。

一个务实的方向

我更倾向的做法，是从 use case 的经济性和 workflow 的边界出发，再围绕这些边界设计支撑平台。

这通常意味着：

• 从狭窄但高价值的工作流开始，而不是一上来就追求广泛自治
• 分离推理、工具执行与策略 enforcement 的责任
• 把可观测性与评估当作一等的平台能力
• 为模糊、失败和异常设计明确的升级路径
• 将 agentic 行为视为一种架构能力，而不是单纯的界面功能

目标不是为了新奇而新奇。目标是在可控风险下获得可重复的业务价值。

当做到这一点时，Agentic AI 才会从实验室演示，真正进入企业架构。