第4章 全书地图：平台参考架构与阅读路径¶
前三章分别讨论了 Agent 的边界、平台化的原因和 AI 原生业务系统。读到这里，概念已经不少：Runtime、Tool Registry、RAG、语义层、评测、网关、安全、组织分工。如果没有一张共同地图，后续章节很容易变成组件堆叠，团队也很难判断一个问题究竟应该在哪一层解决。
企业项目里这种混乱非常常见。业务负责人说“我们需要一个经营分析 Agent”，数据团队听成 NL2SQL，平台团队听成 Runtime 和工具调用，安全团队听成权限和审计，前端团队听成聊天工作台。每个人都在讨论 Agent，但关注的是不同层的问题。
本章把前面的概念判断收束成一张可使用的工程地图。企业级 Agent 平台可以先分成四层：业务任务、Agent 能力、智能与数据、基础设施与治理；在此基础上，再用八个能力簇理解平台骨架。DataAgent 被选为全书主线，是因为它能同时暴露模型、数据、知识、工具、评测、安全和前端问题。
图4-1：企业级 Agent 平台四层参考架构。来源：本书自绘。Alt text：自上而下四层，业务任务层、Agent 能力层、数据与知识层、治理与基础设施层，每层标注核心职责，箭头表示上层任务依赖下层能力、下层为上层提供约束与支撑。
这张地图不是产品蓝图，也不是组件采购清单，而是一种问题定位方法：先判断问题发生在哪一层，再判断缺的是哪一类能力和前置条件。
4.1 四层参考架构：先把问题放到正确位置¶
企业级 Agent 平台不宜一开始就按几十个组件理解。总论阶段更适合先看四层：
表4-1：四层参考架构各层的核心问题与对应章节。来源：本书整理。
| 层级 | 核心问题 | 主要对应章节 |
|---|---|---|
| 业务任务层 | 用 Agent 完成什么业务任务 | Part VI, Part XI |
| Agent 能力层 | Agent 如何规划、调用工具、执行长任务 | Part V |
| 智能与数据层 | Agent 使用什么模型、数据和知识 | Part II, III, IV |
| 基础设施与治理层 | 系统如何部署、观测、评估、安全运行 | Part VII, VIII, IX, X |
业务任务层：企业到底想完成什么¶
这一层包括 DataAgent、报价 Agent、工单 Agent、经营分析工作台等具体场景。它回答“企业希望系统完成什么任务”，也是价值、验收标准和业务责任的来源。
Agent 能力层：任务如何被推进¶
这一层包括 Runtime、工具调用、Planner、Memory、HITL、多 Agent 协作和协议等能力。它负责把“一个目标”变成可管理的执行过程，包括创建、暂停、恢复、审批和失败处理。
智能与数据层：系统凭什么理解和判断¶
这里包括模型推理、结构化输出、湖仓、OLAP、语义层、RAG、知识工程、元数据、血缘和指标口径。它决定 Agent 拿到的上下文是否正确、可解释、可治理。
基础设施与治理层：系统如何长期运行¶
这里包括部署、网关、多租户、Trace、Eval、成本、限流、降级、安全、合规和组织机制。它决定系统能否从试点走向长期生产。
四层之间存在明显依赖：业务任务不能绕过运行能力直接调用模型，Agent 能力必须从数据与知识层获得可信上下文，底层数据和工具又必须接受权限、审计和成本约束。
很多“模型问题”其实是语义层、工具契约、权限或评测问题；很多“业务太复杂”其实是 Runtime、Trace 和恢复机制没准备好。四层架构的价值，就是防止问题被放错层。
4.2 八个能力簇：执行骨架、智能放大器与反馈系统¶
在四层架构中，有八个能力簇会贯穿后续章节：Runtime、Registry、Planner、Memory、RAG / Knowledge、Observability、Eval 和 Policy。
它们分别解决不同问题：Runtime 管理任务的创建、推进、暂停、恢复和终止；Registry 管理工具、Agent、能力和版本；Planner 决定下一步做什么；Memory 保持会话、任务和长期上下文；RAG / Knowledge 让企业文档和知识进入决策；Observability 统一记录 Trace、日志、指标和回放；Eval 判断版本是否真的变好；Policy 承担权限、脱敏、审批和安全边界。
把八个能力簇进一步归为三组，会更容易理解：
- 执行骨架：Runtime + Registry + Policy。 让 Agent 能被统一运行、调用和约束。
- 智能放大器：Planner + Memory + RAG / Knowledge。 让 Agent 获得上下文并能够动态推进任务。
- 反馈系统：Observability + Eval。 让系统知道发生了什么、版本是否变好，并避免长期黑箱化。
图4-2：企业级 Agent 平台八个能力簇。来源：本书自绘。Alt text：八个能力簇分为执行骨架（Runtime、Registry、Policy）、智能放大器（Planner、Memory、RAG/Knowledge）和反馈系统（Observability、Eval）三组，连线表示各簇之间的调用与反馈关系。
没有 Runtime，系统往往只能演示；没有 Registry，工具规模扩大后会失控；没有 Policy，高风险动作无法约束；没有 Planner 和 Memory，长任务很难稳定推进；没有企业知识，系统无法理解组织语境；没有 Observability，事故无法解释；没有 Eval，模型和流程升级只能凭感觉判断。
八个能力簇不是“全部都要第一天建设完成”的清单，而是一组诊断坐标：当前项目缺的是执行骨架、智能放大器，还是反馈系统。
4.3 DataAgent 为什么贯穿全书¶
本书并不只讲 DataAgent，但选择它作为主线，是因为一个看似简单的经营问题就能穿过平台的大多数层级。例如：“上周华东区毛利率异常的原因是什么？”
表4-2：DataAgent 为何在每一架构层都绕不过去。来源：本书整理。
| 层级 | DataAgent 为什么绕不过去 |
|---|---|
| 模型层 | 需要理解问题、规划路径、生成 SQL、解释结果 |
| 数据层 | 需要语义层、指标口径、湖仓、OLAP 和数据质量 |
| 知识层 | 需要元数据、历史分析、业务术语、制度和案例 |
| Agent 层 | 需要 Runtime、工具调用、Planner、状态管理和人工介入 |
| 治理层 | 需要权限控制、trace、评估、成本和审计 |
| 前端层 | 需要图表、表格、引用、报告和任务工作台 |
一次完整 DataAgent 请求至少会经历：确认身份和范围、加载指标口径与历史上下文、规划查询路径、执行 SQL/API/Python 等工具、区分事实与推断、记录 Trace/成本/风险证据、生成图表和可交付结论。
图4-3：DataAgent 端到端任务链路。来源：本书自绘。Alt text：一条从用户提问出发的横向链路，依次经过意图理解、语义层编译、SQL 生成与执行、结果解释与可视化，每个环节标出所依赖的平台能力簇，末端汇出带证据的业务结论。
如果把 DataAgent 简化成“自然语言转 SQL”，会同时忽略语义层、权限、运行状态、评测、人工确认和结果交付。DataAgent 的意义不在于它最热门，而在于它能让平台的全栈缺口显影。 读完后续任何一个 Part，都可以回到 DataAgent 问：这项能力怎样让一次经营分析更可信、更可控、更容易复盘？
4.4 全书为什么按这个顺序展开¶
本书没有从聊天界面或 Prompt 开始，而是按照企业平台的依赖关系组织章节。
表4-3：全书各部分在依赖链中的位置及如此排序的原因。来源：本书整理。
| 书中部分 | 为什么放在这里 |
|---|---|
| Part II 模型与推理层 | 建立模型能力与结构化输出基础 |
| Part III 数据基础设施层 | 建立可访问、可信、可治理的数据底座 |
| Part IV 向量、检索与知识工程 | 让 Agent 能连接企业非结构化知识 |
| Part V Agent 基础能力 | 建立任务执行、工具调用和协作机制 |
| Part VI DataAgent 主线深潜 | 用一个综合场景拉通全栈能力 |
| Part VII-X 生产化与治理 | 补齐观测、评估、成本、部署、安全和组织机制 |
| Part XI 案例集 | 把平台能力迁移到更多业务 Agent |
先讲模型与推理，是因为 Agent 最终依赖结构化、稳定、可控制的模型能力；随后讲数据和知识，是因为企业 Agent 的差异往往来自能否连接正确数据和口径；再进入 Runtime、工具、Planner、Memory 和 HITL，建立执行能力；然后用 DataAgent 验证前面各层；最后补齐观测、评测、成本、部署、前端、安全、合规和组织治理。
章节顺序表达的是工程依赖，不是固定项目排期。 读者可以跳读，但不能忽略上下游条件。例如没有稳定语义层，NL2SQL 很难进入生产；没有 Trace 和 Eval，高风险自动化很难被持续验证；没有 Registry 和 HITL，工具调用就无法承担正式业务责任。
不同角色可以采用不同阅读路径¶
- 平台负责人 / CTO：先读 Part I，再重点看 Runtime、Trace、Eval、成本、安全和组织治理。
- 架构师：先读四层架构和八个能力簇，再深入模型、RAG、Runtime、Tool Registry、评测和部署。
- 数据智能工程师：优先看数据基础设施、语义层、知识工程、DataAgent、NL2SQL 和 Eval。
- AI 应用开发者：重点看 Runtime、工具、Planner、HITL、任务工作台和结果交付，但不能跳过 Trace。
- 安全与合规负责人：重点看权限、审批、Trace、Eval、Guardrails 和法规控制。
读者不必顺序读完所有章节，但应保留四个共同背景：证据、权限、评测和恢复。 只看模型和 Prompt，会低估工具副作用和运行责任；只看业务案例，会看不到平台约束。
4.5 一年建设路线：先跑通一条生产链，再证明可复用¶
如果一家企业希望在一年内从首个 Agent 试点走向多业务线平台化，更稳妥的路线不是一次建设“大而全平台”，而是围绕真实场景逐步沉淀公共资产。
表4-4：一年建设路线各季度的技术、治理与组织重点。来源：本书整理。
| 阶段 | 技术重点 | 治理重点 | 组织重点 |
|---|---|---|---|
| 第一季度 | Runtime、模型入口、工具注册、基础 trace、首个试点 | 工具风险等级、最小审批准则 | 明确平台团队边界和业务试点负责人 |
| 第二季度 | 评估、成本归集、审批接入、基础管理界面 | 评测样本模板、上线准入标准 | 建立场景共创和复盘机制 |
| 第三季度 | 语义层、RAG、更多工具接入、第二业务线复制 | 统一数据口径、权限和 trace 规范 | 推动业务团队按模板接入 |
| 第四季度 | 灰度、降级、SLO、供应商接入、平台目录 | 事故复盘、版本治理、合规检查 | 建立平台运营节奏和年度路线 |
这张表的重点不是季度数字，而是建设顺序：先站稳任务执行链，再补评测和准入，再解决跨业务数据与知识复用，最后进入灰度、SLO、供应商、目录和长期运营。
每个阶段都应沉淀能被下一条业务线复用的公共资产：统一任务状态、工具风险等级、评测模板、准入清单、语义层规范、权限规范、平台目录和复盘机制。
平台化是否成立，不看第一个场景做得多漂亮，而看第二个场景能否明显少做重复工作。 如果第二个业务仍然要重新接模型、重新写工具协议、重新发明 Trace 和评测，所谓平台资产还没有真正成立。
建设路线也应同时推进技术、治理和组织。只做技术，平台可能“能用但没人敢用”；只做治理，平台会变成流程负担；只做组织倡议，则缺少真正可运行的底座。
4.6 把现有项目映射到地图：从“有功能”转向“缺什么能力”¶
多数团队不会从零开始，而是已经有知识问答、指标问答、审批草稿、客服质检或接了少量工具的聊天机器人。最有效的做法不是给这些项目重新命名，而是把它们映射到四层架构和八个能力簇。
先写清用户任务，再标出项目已有的模型、数据、知识、工具、运行状态、评测、安全和前端能力。缺口通常会很快显现：
- 有些项目只有 Prompt 和前端，没有 Runtime；
- 有些项目有 RAG，却没有文档版本、权限过滤和引用证据；
- 有些项目已经调用工具，却没有 Registry、Trace 和审批事件；
- 有些项目做了离线评测，却没有把线上失败样本回流。
映射之后，团队可以形成三类结论：
- 阶段结论：当前适合原型、受控试点、有限生产，还是正式进入平台目录。
- 缺口结论：缺的是语义层、Registry、Runtime、Eval、HITL、Trace、安全策略还是任务工作台。
- 责任结论：哪些由业务补样本，哪些由数据补口径，哪些由平台补能力，哪些由安全和合规定义门禁。
地图的作用不是给项目打分，而是把一次“能演示”与“能运营”之间的差距写清楚。 一个知识助手会回答制度问题，不代表已经具备文档版本、权限、引用和失败回流；一个 DataAgent 会生成 SQL，也不代表它已经具备指标口径、字段权限和查询资源隔离。
4.7 地图也可以成为团队协作和评审契约¶
企业 Agent 项目经常涉及业务、产品、平台、数据、安全和法务团队。各团队使用不同语言：业务讲交付，产品讲体验，数据讲口径，平台讲运行时，安全讲策略。四层架构和八个能力簇可以把这些语言转成一组共同问题：
- 任务入口和验收结果是什么？
- 数据和知识依据从哪里来？
- 工具由谁调用、是否产生副作用？
- 任务如何暂停、恢复和转人工？
- 结果如何被评测、审计和追责？
一次 Agent 立项评审中，业务方应带来真实任务、失败样例和采纳标准；数据方提供口径、权限和质量状态；平台方说明可复用底座与当前限制；安全与合规方明确风险等级和审计要求。评审结束后，应能把项目放在地图的明确坐标上，并写清下一阶段要补什么。
地图还可以用于团队共读。Part I 先统一“Agent 是什么、平台负责什么、AI 原生改变什么”；后续每读完一个 Part，再把在建项目放回地图检查：哪些能力已经进入平台，哪些仍然是应用私有实现，哪些缺少证据和 owner。
一张真正有用的架构地图，最终应该能够改变项目评审和建设顺序，而不是只出现在汇报 PPT 里。
本章小结¶
第四章给出全书的共同坐标：先用四层架构定位问题，再用八个能力簇判断缺的是执行骨架、智能放大器还是反馈系统。DataAgent 被选为主线，是因为它能够同时暴露模型、数据、知识、工具、前端、评测和安全问题。
全书按平台依赖关系展开，而不是按技术热度排列。建设平台时同样应遵循依赖：先跑通一条真实任务链，沉淀 Runtime、Registry、Trace、Policy 和基本 Eval，再逐步扩展语义层、知识、更多业务线和长期治理。
读完这张地图后，面对任何 Agent 项目，都应先问三个问题：它位于哪一层、缺哪些前置能力、谁负责补齐这些缺口。 后续章节会从模型与推理开始逐层进入工程细节，但所有技术主题最终都要回到同一目标：让企业任务能够被可信、可控、可复用地执行。
参考文献¶
Bass, L., Clements, P., & Kazman, R. (2021). Software Architecture in Practice. Addison-Wesley.
NIST. (2023). AI RMF 1.0.
OpenTelemetry. (n.d.). Documentation.
Model Context Protocol. (n.d.). Specification and documentation.