Brand 5.0 Lab by Keye博客

Brand 5.0 Lab：企业 AI 转型中的 Agent Architecture 设计及运营模式

科爷 Kevin Zheng企业 AI 转型2 次阅读约 6 分钟
导出
01.png

根据 Brand 5.0 Lab 对 AWS、OpenAI、Anthropic、Azure、NIST、微软 Work Trend Index、Deloitte、BCG 等行业案例的研究，企业的 AI 转型以及应用，需要建立两套相互咬合的系统：

  1. Agent Architecture — 技术、信息、执行与控制结构

  2. Agent 运营模式 — 所有权、监督、能力编制、问责与决策权

02.png

AI Transformation 不是买一套软件

传统企业软件（SaaS / ERP / CRM / 数据平台）主要把人的工作结构化、可追踪、可协同——软件支持人完成流程；Agentic 系统带来的变化则是革命性的：软件开始在流程内部参与推理、决策与执行。

当然，我们需要认识到，”Digital = 只支持人 / AI = Agent 替人干活”这种说法过度简化了，更准确的定义是：稳定的自动化执行、LLM 增强关键步骤、目标驱动的 agentic 执行并存；人仍然对结果和风险边界负责。按照 Brand 5.0 Lab 的观点，企业 AI 转型中最重要的不是”Agent 数量”，而是 Agent 如何安全地进入端到端业务。

Agent Architecture

1. 业务、工作流层

从业务结果与端到端工作流出发，而不是从模型或工具目录出发：哪些节点使用现有方式即可，哪些需要 AI 辅助执行，哪些可直接交给 Agent。

这是正确的切入方法，AWS、OpenAI、Anthropic、Azure 以及独立研究都支持这种工作流优先的设计思路；它首先应该回答”该做什么”。

2. Agent、编排层

Agent 循环与编排是必要的：指令、工具、任务交接、路由、可选的监督者/评审者机制。

但多 Agent 是可选的一种模式，不是一定要用的模式。OpenAI、Anthropic、Azure 的实践经验都指向同一个方向：多数情况，其实可以使用单 Agent + 工具完成；专家协作、并行、监督者是业务复杂度上升后才应该考虑的选项。把专家/路由/评审等照搬，只不过是抬高 token 成本，却不能提供效率和改善效果。

3. Enterprise Context、基础层

这个层包含了知识、文件、CRM/ERP/CMS、API、MCP、专有数据、记忆等，可以分为四类：

  • 知识 / 数据 — 企业信息资产与检索对象

  • 系统 / 工具（SoR） — Agent 据以行动的业务系统

  • 集成 / 访问 — API、MCP、网关等连接机制（协议 ≠ 知识）

  • 记忆 / 状态 / 上下文组装 — 任务级状态、记忆与运行时上下文的组装逻辑

03.png

4. 模型访问层

即 Model / Intelligence Access：受治理的模型目录、路由、按任务/风险/成本选择模型的能力。

需要强调的是：企业 Agent 架构与模型无关。从性能和成本的角度考虑，多模型或路由模式，对于企业可能更有益。

模型 ≠ 执行框架 ≠ Agent 框架 ≠ 编排；

API 兼容 ≠ Agent 栈可移植。

5. 运行环境

Agent 需要一个可以执行动作的环境。

它包括：会话运行时容器；代码/浏览器等工具沙箱；工作流/持久执行引擎；部署拓扑（云/VPC/自托管）。

6. 治理与控制

身份、权限、策略、审批、注册与可发现性、评估、可观测性、追踪、审计、安全、数据与生命周期控制等，这些都需要贯穿业务到执行。

BCG 的 Enterprise AI Control Plane、Bain 的治理讨论、微软 Agent 产品线中的治理能力，以及 NIST / OWASP / 欧盟 AI Act 对监督、日志与风险控制的要求，都说明；Agent 本地仍要落实执行与合规。

04.png

Agent 运营模式

微软 Work Trend Index、Deloitte 对运营模式的讨论，以及咨询行业的共识，都认为企业 AI 转型中，必须在组织与运营设计中充分讨论。

Agent 运营模式包括：

  • 领域所有权与 Agent 所有权

  • 人工监督与升级机制

  • FDE / 类 FDE 嵌入式构建能力

  • AI 转型团队 / CoE

  • IT 与 Security（映射到平台与控制平面，而不是”第 7 个人层”）

  • 决策权、资金、学习节奏、问责

这个部分相对比较容易理解，就不多展开了。

两套系统如何咬合

Architecture 规定 Agent 能碰什么、在哪运行、如何被看见与约束；运营模式规定谁拥有结果、谁批准越权、谁为失败负责、能力如何编制。

没有运营模式的 Agent Architecture，容易变成只能演示、不能有效运营的演示版本；没有明确架构接口的运营模式，就很难把责任落到具体 Agent 与权限对象（人）上。

实施路径：协同演进，不是二选一

”永远先平台”或”永远先堆 Agent、架构最后才出现”，都是错误的。

在 Brand 5.0 Lab 的研究中，正确的路径是分阶段协同演进：

05.png

  1. 诊断（Diagnose）

  2. 选灯塔流程（Lighthouse Workflow）

  3. 最小必要的数据/安全/治理/运行时基础，与原型↔评估↔生产同步生长

  4. 沉淀（Codify）：可复用的 Agents / Skills / Patterns / golden paths

  5. 企业 Agent Architecture 与运营模式从复用中逐渐成形

当然，灯塔流程优先，并不等于禁止平台投入；这里反对的是用宽泛平台采购替代对真实工作流的改造，也反对在没有任何生产反馈前就动手调整企业架构。