AI 智能体：Agent¶
本章所属 DDA 层：AI Agent
问题¶
为什么 AI 系统需要智能体（Agent）完成多步任务？因为真实业务问题不是一次问答，是一串有依赖的步骤。
药明诺华的药物情报查询很典型："查 c-Met 抑制剂的在研试验，汇总试验状态，对照现行 SOP 判断终止流程是否合规，生成报告。"这不是一次检索能解决的，要分步：先查化合物，再查试验，再取 SOP，再对照判断，再组织报告。每一步依赖上一步的结果，每一步都要在受控边界内执行。
数据工程师为什么要学 Agent？因为 Agent 是消费前面所有层的执行单元。Agent 消费 Ontology 理解业务世界，经语义层（Semantic Layer，SL）取数据，经知识基础设施（Knowledge Foundation，KF）与检索增强生成（Retrieval-Augmented Generation，RAG）获取知识，在受控语义边界内完成多步任务。数据工程师不一定要自己写 Agent 框架，但必须理解 Agent 如何消费数据层，才能把数据层设计成 Agent 友好的形态。
Agent 解决的问题是：让 AI 在受控语义边界内完成多步任务，而不是失控地自由发挥。
Agent 的可靠性上限，由它消费的语义传递链决定，不由模型本身决定。前面各层已经把 Ontology、语义接口、知识绑定、接地引用逐段加固；Agent 若绕过这条链直连裸库，等于在传递链末端重新引入不可靠——口径自造、操作不可追溯、错误无法回流。DDA 因此把 Agent 定位为消费方，不是中心。
传统方案¶
早期做法是让 Agent 直连数据库自己写 SQL、自己判断、自己执行。药明诺华的尝试是：接一个通用模型，给它数据库连接，让它自己查。问它"在研的 c-Met 抑制剂"，它自己拼 SQL，自己解释结果。
这种做法在演示里好看，在生产里失控。
为什么失效¶
失效机制是：直连裸库的 Agent 没有边界，错误无法控制也无法追责。
第一，失控。Agent 自己写 SQL，可能写出全表扫描跑垮平台，可能写出错误 JOIN 给出错误答案，可能写出越权查询访问不该看的数据。没有语义层护栏，这些都没有拦截。
第二，出错。Agent 不懂业务口径，自己拼的 SQL 口径与报表对不上。它把 preclinical 算进"在研"，但企业口径不算。错误答案来自口径漂移，不是模型笨。口径漂移是传递不可靠的症状，Agent 直连裸库时没有语义层这一道"协议层"来校验传下去的口径是否正确。
第三，无法追责。Agent 直连裸库时，它的每一步操作没有结构化记录。出了错，说不清是哪一步、依据什么、调用了什么。无法追责的 Agent 在受监管场景不可用。
第四，自造口径。Agent 没有统一语义来源，每次自己解释字段含义，同一个问题不同时候给不同口径的答案。
flowchart LR
AGT[AI Agent] --> SL[Semantic Layer]
AGT --> KF[Knowledge Foundation]
AGT --> RAG[RAG]
SL --> Ont[Ontology]
KF --> Ont
Ont --> DP[AI Ready Data Platform]
RAG --> KF
AGT -.不直连.-> DB[(裸库)]图：Agent 消费链路（DDA 层：AI Agent）
解读：Agent 经 SL 取数据、经 KF 取知识、经 RAG 取接地答案，三者都向下追溯到 Ontology 与 AI 就绪数据平台。裸库用虚线表示 Agent 不直连。这张图的核心是：Agent 是消费方，不是中心；数据层才是中心。Agent 的可靠性来自它消费的语义层，不来自它自己。
新的设计思想¶
DDA 方法重新看这一层：Agent 不是中心，数据才是。 Agent 是消费前面所有层的执行单元，它的可靠性由它消费的数据层决定，不由它自己决定。
设计思想有四点。
第一，Agent 消费 Ontology、SL、KF，不直连裸库。Agent 的每个数据动作都经语义接口，受 SL 护栏约束。
第二，每步可追溯。Agent 的每次调用、每次决策、每次工具使用都结构化记录，出错可回溯。
第三，受控语义边界。Agent 在 Ontology 与 SL 定义的语义边界内操作，不能自造口径、不能越权、不能绕过护栏。
第四，编排而非自由发挥。Agent 的多步任务用编排框架管理，有状态、有检查点、有中断恢复，不是放任它自由推理。
这里要区分 Agent 与工作流（Workflow）。工作流是预定义的执行路径，没有自主决策；Agent 有自主决策能力，能在边界内选择下一步。两者不是一回事，不能混用。药明诺华的合规检查适合工作流（步骤固定），药物情报综合分析适合 Agent（步骤依问题而定）。
架构设计¶
flowchart TB
Q[任务] --> ORC[编排层<br/>状态图/检查点]
ORC --> M1[模型: 规划]
M1 --> T1[工具: 经 SL 取数据]
T1 --> M2[模型: 推理]
M2 --> T2[工具: 经 RAG 取知识]
T2 --> M3[模型: 判断]
M3 --> T3[工具: 生成报告]
T3 --> R[结果]
ORC --> MEM[记忆: 工作/画像/情景/修正]
ORC --> OBS[可观测: 状态演化]图：Agent 编排架构（DDA 层：AI Agent）
解读：任务进入编排层，编排层管理模型规划、工具调用、模型推理、结果生成的循环。工具调用都经 SL 与 RAG，不直连裸库。记忆层与可观测层贯穿全程。这张图说明 Agent 不是"一个模型加几个工具"，而是带编排、记忆、可观测的执行系统，数据消费全部经语义层。
编排框架的演进可以看一条线索：从 ReAct 1（推理-行动交替）到有向无环图（Directed Acyclic Graph，DAG）再到状态图（StateGraph）。ReAct 简单但难控，DAG 可控但不灵活，状态图用显式状态管理兼顾可控与灵活，支持检查点与中断恢复。LangGraph 的 StateGraph 是这一思路的代表（仅为一种实现选择 2）。本书关心的是状态图这种编排形态的工程价值，不是某个框架。
垂直数据行业已经在用 Agent 做决策级任务。专利数据平台的 Agent 平台把研发情报任务分成五个阶段：提问、检索、解决、起草、验证。一个新颖性检索 Agent 先理解查询意图（提问），再跨专利族与文献检索（检索），判断是否破坏新颖性（解决），生成检索报告（起草），最后用审查员引用样本校验结果（验证）。企业征信平台的 AI 平台定位是从"回答企业是谁"升级到"判断能否放贷、放多少"。这类 Agent 的共同点是：站在已产品化的 API 与知识目录之上做决策，按 Ontology 规则推理、按 RAG 知识接地、按 SL 口径出数字——企业侧亦同，Agent 是数据产品的新消费者，只经语义接口与知识产品取数，在受控语义边界内完成多步任务，而非自由发挥。
工程实践¶
药物情报 Agent 的多步查询¶
以药明诺华的药物情报 Agent 为例，一个典型多步任务用时序图说明：
sequenceDiagram
participant U as 用户
participant A as Agent
participant SL as 语义层
participant RAG as RAG
participant KF as 知识基础设施
U->>A: c-Met 抑制剂在研试验合规吗
A->>SL: list_active_compounds(target=c-Met)
SL-->>A: NVP-001 等化合物
A->>SL: list_trials(compound=NVP-001)
SL-->>A: 试验列表含 terminated
A->>RAG: 检索试验终止 SOP
RAG->>KF: 取现行 SOP 与 CSR
KF-->>RAG: 绑定到试验实体
RAG-->>A: SOP 规程+引用
A->>A: 对照判断合规性
A-->>U: 报告+引用+合规判断图：药物情报 Agent 多步查询时序（DDA 层：AI Agent）
解读：Agent 依次经 SL 取化合物与试验数据，经 RAG 取现行 SOP，RAG 又向 KF 取绑定到试验实体的规程与 CSR。每一步都有结构化记录，每一步的工具调用都经语义层，不直连裸库。最终输出带引用与合规判断。这张图说明 Agent 的可靠性来自消费链：经 SL 保证数据口径，经 RAG 保证知识有依据，全程可追溯。
需要强调 Agent 从 RAG 继承的三项能力。第一，RAG 可能返回视觉证据（像素原生块，如 CSR 里的剂量-响应图表），Agent 把视觉证据与文本证据一并交给生成模型，能回答版式敏感的问题。第二，RAG 的接地与拒答会传递给 Agent：RAG 判断无足够依据时拒答，Agent 也要把这个"无依据"如实转达，而非自己编一个。第三，RAG 遵循引用优先（Citationware），Agent 输出的每条陈述继承 RAG 的引用坐标，引用完整性校验贯穿到 Agent 输出。Agent 不是引用链的起点，是引用链的终点消费者。
三层工具范式¶
Agent 调用的工具有三种范式：
- 函数工具：Agent 调用一个函数，如
list_active_compounds(target='c-Met')。最常见，适合确定性查询。 - 节点即工具：把一个处理节点封装为工具，如"证据聚合节点"，Agent 调用它完成复杂处理。
- ML 能力注册：把模型能力（如抽取、分类）注册为工具，Agent 按需调用。适合需要模型判断的子任务。
三种范式按任务复杂度选用。药明诺华的查询多用函数工具，证据聚合用节点即工具，文档抽取用 ML 能力注册。
工具的数量与组织是工程关键。专利数据平台把一百多个领域技能封装成可安装的 Agent 技能包，覆盖工程、知识产权、生命科学、材料等领域，每个技能是一份过程性知识定义加相关资源。这说明当 Agent 要服务一个完整业务领域时，工具不是几个零散函数，而是一套按领域组织的技能体系。药明诺华的药物情报 Agent 也应如此：化合物检索、试验状态查询、SOP 检索、合规判断、报告生成各自是技能，按研发流程组织，而非堆在一个提示词里。
四层记忆¶
Agent 需要记忆来处理多步任务与持续交互。四层记忆：
- 工作记忆：当前任务的上下文，任务结束即清。
- 画像记忆：用户偏好与权限，跨任务保留。
- 情景记忆：历史交互记录，支持召回相似场景。
- 修正记忆：用户纠正过的错误，避免重犯。
修正记忆是 Data Loop 在 Agent 层的体现：用户的纠错被记住，下次不犯。纠错来源不限于 Agent 自身的决策错误，也包括 RAG 检索与接地的失败（如召回了错误文档、接地对齐失败），这些经修正记忆沉淀后回流驱动 RAG 参数与 Ontology 修正。这与下一章的主题衔接。
Agent 可观测性¶
Agent 的可观测性聚焦状态演化。Agent 每一步改变了什么状态、为什么选这条路径、调用了什么工具，都要记录。状态层是可观测的关键：状态演化决定路由，看不清状态就调不动 Agent。
可观测性的四层信息模型（Trace/I/O/State/Metrics）在第一章数据可观测性已出现，这里复用于 Agent。Trace 记录调用链，I/O 记录工具输入输出，State 记录状态演化，Metrics 记录性能指标。其中 State 层对 Agent 最关键。
生产陷阱与诚实边界¶
Agent 上生产有几个常见陷阱，每个都有具体表现。
Agent 蔓延（Agent Sprawl）：一个任务造一个 Agent，Agent 数量失控，维护成本爆炸。应控制 Agent 数量，多用编排复用。
递归调用循环：Agent 调工具，工具又触发 Agent，形成死循环。编排层要设递归深度与超时限制。
工具爆炸：给 Agent 配太多工具，它选不准。应做渐进式上下文披露，按任务阶段暴露相关工具子集。
延迟边界：Agent 多步推理的延迟，受模型与工具调用累计影响。十毫秒级硬实时响应（HRT）对 Agent 不可达，这是诚实边界。需要硬实时的场景不适合 Agent，适合预计算或工作流。
最佳实践¶
Agent 消费语义层，不直连裸库：这是硬边界。Agent 可靠性的下限由它消费的语义层决定。
编排优先于自由推理：用状态图管理多步任务，有检查点、有中断恢复，不放任 Agent 自由发挥。
状态可观测是关键：State 层记录要细，它是调试与改进 Agent 的主要依据。
记忆分层管理：工作记忆清空、修正记忆持久，不同寿命的记忆分开管理。
诚实面对边界：Agent 不适合硬实时、不适合无约束自主。该用工作流的场景不要硬塞 Agent。
控制 Agent 数量：复用编排，避免 Agent 蔓延。一个 Agent 解决一类问题，不是一个问题一个 Agent。
延伸阅读¶
- Agent 编排演进：ReAct（推理-行动交替）论文；DAG 与状态图（StateGraph）编排资料；LangGraph 状态图相关开源文档。
- Agent OS 与治理：Agent OS 概念与五支柱（模型路由/成本治理/合规/可观测/生命周期）相关资料；基于能力、范围受限、时限受限的 Agent 权限治理资料。
- MCP 协议：模型上下文协议（Model Context Protocol）规范与 Agent 工具化资料。
- Agent 记忆：工作记忆/画像/情景/修正四层记忆系统相关研究。
- Agent 可观测性：Agent 状态演化观测与 OpenTelemetry/OpenInference 等可观测标准资料。
Checklist¶
- Agent 是否经 SL/KF/RAG 消费数据，不直连裸库？
- 是否澄清了 Agent 与工作流的区别，该用工作流的场景未硬塞 Agent？
- 多步任务是否用编排框架管理，有状态、检查点、中断恢复？
- Agent 每步操作是否结构化记录，可追溯？
- 是否有四层记忆，修正记忆是否持久化以避免重犯错误？
- 可观测性是否聚焦状态演化，State 层记录是否足够细？
- 是否设了递归深度与超时限制，防递归调用循环？
- 是否控制 Agent 数量，避免 Agent 蔓延？
自检（依据 WRITING_STYLE §9）：本章为何需要？因为真实业务问题是多步任务，需要受控执行单元。数据工程师为何关心？Agent 消费数据层，数据层设计决定 Agent 可靠性。解决什么问题？让 AI 在受控语义边界内完成多步任务。属哪一 DDA 层？AI Agent。改变什么架构？把直连裸库的失控 Agent，改为经语义层消费、带编排记忆可观测的受控执行单元，且明确 Agent 不是中心。