08. 智能体工程

八、Agent 工程¶

Agent 不是聊天能力的升级版，这一点得先说清楚。给模型加上“观察-思考-行动-评估”（Observe-Orient-Decide-Act, OODA）的闭环自主权之后，它才有能力针对路径不确定的业务问题自己迭代收敛，而不是每一步都等宿主代码告诉它下一步干什么。往系统架构的角度看，Agent 其实是一套分布式计算运行时系统（Distributed Agent Runtime System）：要有状态感知能力，要能自主规划，要能做动态分支决策，还要扛得住长周期故障恢复。

总判断：Agent 是运行时，不是更会聊天的模型¶

flowchart LR A["目标与约束"] --> B["状态对象"] B --> C["节点决策"] C --> D["工具执行 / Agent handoff / 人工确认"] D --> E["观察结果"] E --> F["checkpoint"] F --> G{"停止条件满足?"} G -- 否 --> B G -- 是 --> H["最终收口"]

大模型应用的本质演进是由“无状态的单轮同步计算（Stateless Inference）”向“有状态的多步受控决策循环（Stateful Multistep Loop）”升级。当系统的下一步走向（Next Step Action）不再由宿主应用的代码逻辑（If-Else）硬编码预设，而是依赖于模型在运行期基于环境反馈的实时观察结果动态决策时，系统便进入了 Agent 运行时的范畴。

确定性工作流与 Agent 运行时的分工边界：¶

确定性工作流（Deterministic Workflows）：执行分支清晰、失败模式已知且状态流转逻辑高度确定的场景（如发票合规审批、自动流水线测试）。应坚决避免引入概率性的 Agent 运行时，规避系统不可预测的行为偏移与测试回归困难。
Agent 运行时（Agent Runtime）：面对目标明确但物理路径不固定、信息源高度异构、需要动态编排多种微服务工具的探索性任务（如跨系统的复杂问题排查、动态资源调度），Agent 运行时才具备真正的工程合理性。

运行时最小闭环：目标、状态、工具、观察与停止条件¶

一个可投入生产运行的 Agent 实例，必须在架构层面显式化并固定以下五个核心状态维度，缺一不可： 1. 任务目标（Goal & Constraints）：界定任务成功的客观判定标准及资源预算约束。当用户意图发生缺失时，应评估风险等级：若涉及越权、资金副作用等硬性槽位缺失，必须中断执行并触发前置澄清机制；若为低风险查询，可前置执行只读检索缩小范围后再回溯追问。 2. 运行时共享状态（Shared Runtime State）：作为 Agent 的全局“物理内存”，承载当前槽位（Slots）、决策图快照、审批结果等强类型事实骨架。 3. 工具契约集（Tool Registry）：明确当前执行主体所被授予的工具调用范围与权限 ACL。 4. 观察反馈流（Observation Stream）：将工具执行的物理返回、异常报错标准化回灌至状态机中。 5. 硬性停止条件（Stop Criteria & Escalate）：规定最大执行步数（Max Steps Limit）、无限循环自检拦截（Loop Detection）及人工介入触发点。

复杂度升级谱系：先 workflow，后更重的 agent runtime¶

为防范系统性复杂度的过度膨胀，架构师应严格遵循分层控制策略，优先通过轻量级工作流（Workflow Patterns）来收敛概率节点的波动度：

1. 经典轻量级工作流模式（Workflow Patterns）¶

Sequential（顺序管道）：适用于输入输出固定、步骤线性的任务。模型仅承担单节点上的语义变换，不接管流转决策。
Routing（动态分流）：依靠规则引擎或轻量分类器，在入口处对高风险或格式化意图执行拦截分流，仅将边界模糊的请求导入概率推理链路。
Parallel（并行发散与收拢）：对于可拆分、互不依赖的子任务（如并行检索多源知识库），采用异步并发执行，避免强耦合的一致性冲突。
Evaluator-Optimizer（评估器-优化器闭环）：在无需工具执行的场景下，通过 Grader 模型对 Candidate 生成执行事实对齐校验、偏航修正与质量审查。
Orchestrator-Workers（编排器-执行器拓扑）：主编排节点负责将复杂目标拆分为并行的子任务，分发给特定 Worker 执行，Worker 自身为单一职责的确定性受控单元。

2. ReAct 运行时机制实现¶

当任务路径无法被静态工作流完全覆盖时，单 Agent 的 ReAct（Reason-Act）受控循环成为首要选择。在 Go 语言中，ReAct 循环的最小健壮运行时实现如下：

for step := 0; step < maxSteps; step++ {
    decision := llm.Decide(goal, state, tools)
    if decision.Stop {
        return finalize(state)
    }

    result := executeTool(decision.Tool, decision.Args)
    state = reduce(state, decision, result)

    if duplicated(state) || noProgress(state) {
        return failOrEscalate(state)
    }
}
return stepLimitExceeded(state)

reduce 函数：是维持状态连贯性的关键，负责将新观察的 Observation 过滤、结构化降噪后以原子操作回写至全局 state 中。
duplicated/noProgress 自检逻辑：运行时实时拦截状态哈希冲突，防止模型在同一路径上陷入死循环，保障系统安全止损。

3. Planning（多步规划）与 CoT（思维链）的物理界分¶

CoT（Chain of Thought）：是单步推理阶段的语义显化（“我为什么要这么判断”），其产物是自由文本，无法被宿主语言解析为确定性的状态流转对象。
Planning（任务分解）：是针对长周期多阶段任务的执行分解（“接下来我准备如何执行”）。其产物必须是具有强类型、包含依赖图（Directed Acyclic Graph, DAG）的步骤对象：
```
[
  {"step_id": 1, "task": "检索近三年 RAG+RL 论文", "success_criteria": "拿到至少 3 篇高相关论文"},
  {"step_id": 2, "task": "抽取每篇论文的方法与结论", "depends_on": [1]},
  {"step_id": 3, "task": "合成中文总结", "depends_on": [2]}
]
```
只有产出带有唯一步骤标识 step_id、前置依赖 depends_on 及客观校验成功阈值 success_criteria 的结构化计划，系统底座才有可能在步骤失败时执行精准局部重试、补偿或中断状态恢复。

4. 高阶搜索规划与协作模型¶

当决策解空间极大（如算法生成、高维系统演进规划）时，系统可切换至 ToT（Tree of Thoughts）、GoT（Graph of Thoughts）或 LATS（Language Agent Tree Search）等深度搜索范式。然而，引入此类范式的系统级算力开销将呈指数级级联飙升：

\[\text{搜索成本} \approx \text{分支宽度}^{\text{深度}} \times \text{每次扩展与评估成本}\]

鉴于其极端高昂的 Token 费用与 P99 Latency 损耗，在绝大部分企业级场景中，应坚决限制此类搜索范式在在线环境的默认启用。

状态与记忆：基于 LangGraph 原理的状态流转设计¶

Agent 的内存架构设计必须摆脱单一“对话历史”的粗犷设计，引入冷热分离、显式状态化及分布式快照的系统化方案。

1. 运行时状态管理三元组（借鉴 LangGraph 设计）¶

State（运行时状态）：多节点并发共享的状态对象（共享内存拓扑）。
Node（物理执行节点）：实现特定单一逻辑（如检索、反射、工具调用）的受控运行时单元，通过原子写方式修改 State。
Edge（条件路由转移）：基于 State 的最新值，通过确定性布尔函数判定下一步跳转至哪一个 Node，消除动态 Loop 中的状态不确定性。

2. 多级记忆架构模型与排序引擎¶

Agent 场景下的记忆分层，是第五章 Hot / Warm / Structured / Cold 四层模型在“多步循环执行”场景下的具体落地：Scratchpad 对应 Hot Memory，Rolling Summary 对应 Warm Memory，Episodic / Semantic Memory 对应 Cold Memory。Structured State 对应的是 Agent 的槽位与决策图快照，已在前文“运行时共享状态”一节展开，此处不再重复。命名不同是因为 Agent 场景强调的是“循环步”而非“对话轮”，但生命周期和一致性规则与第五章一致。

短期工作记忆（Scratchpad / Working Memory，≈ Hot Memory）：最近一次 OODA 循环中的原始 Observation、未格式化的中间文本，随单步循环收尾自动清理。
运行摘要（Rolling Summary，≈ Warm Memory）：对跨越多个循环周期但仍具备语义连贯价值的历史事实，通过滑动摘要管道进行增量合并，压扁为紧凑的高维语义片。
长期检索记忆（Episodic / Semantic Memory，≈ Cold Memory）：存储跨 Session 的稳定画像、同义词术语、历史优质案例。在灌回上下文前，为防范记忆污染（Memory Contamination），必须采用多因子记忆排序引擎进行动态评估：

\[\text{memory\_score} = \alpha \cdot \text{semantic\_similarity} + \beta \cdot \text{freshness} + \gamma \cdot \text{source\_trust} + \delta \cdot \text{role\_priority} - \epsilon \cdot \text{staleness\_penalty}\]

这里的 \(\alpha/\beta/\gamma/\delta/\epsilon\) 只是权重构成示意，说明排序要综合这五个因子，具体系数没有通用值，需要结合业务场景做离线调参和 A/B 验证。

freshness / staleness_penalty：防止系统检索出高相关但已失效的旧状态，通过时间轴执行线性位置折损。
source_trust：用于过滤从不可信输入管道写入的脏记忆，确保权威事实的优先级。

3. 分布式 Checkpoint 与 Durable Execution¶

长周期 Agent 执行链在实际生产环境下，极易因高并发导致的进程重启、节点故障或人工介入（Human-in-the-Loop Interrupt）而发生计算流中断。 - Durable Execution（持久化生存执行）：每个 Node 在原子化写入 State 后，必须同步将状态镜像序列化为持久化的 Checkpoint（存储至 Redis 或 PostgreSQL 中），并释放当前物理线程。 - Interrupt & Resume：当执行高风险物理动作前，系统读取 Checkpoint 冻结状态，向外部发出中断通知并持久化挂起（Pending）。人工审核确认后，系统重新加载 Checkpoint 反序列化恢复运行时上下文，沿图边缘推进，实现零网络状态丢失的冷断点续跑。

治理机制：自检、协调与循环防控¶

在企业多角色协作的复杂场景中，必须在运行时外架设确定性的治理网络。

1. 运行时反射（Reflection）与自检收缩¶

自检反射（Reflection）绝不应无脑常驻每个节点。作为一种昂贵的自适应补偿逻辑，自检仅建议布置在“高风险物理动作执行前”、“外部响应输出前”及“生成结构化计划校验后”等关键卡点。

2. 物理故障自愈状态机（Fault Recovery State Machine）¶

当 Agent 运行时遭遇非业务逻辑异常时，系统不应简单退化为“重新生成”，而应执行基于以下拓扑的自愈重路由策略： - 暂时性基础设施异常 \(\rightarrow\) 驱动本地 Backoff Retry，隔绝大模型感知。 - Schema 解析异常（类型错误） \(\rightarrow\) 向 LLM 投递标准 Error Trace，驱动模型执行 Self-Correction 自愈重试（最大次数阈值控制）。 - 权限及状态冲突限制 \(\rightarrow\) 标记任务不可恢复失败，触发 Compensating Transaction（补偿事务，如逆向回滚部分写动作），并转人工接管。 - 长周期进程挂起 \(\rightarrow\) 回滚至最近一次全局 Checkpoint 并拉起节点续跑。

3. 协作代理交互（A2A / Multi-Agent Collaboration）协议¶

多 Agent 系统（Multi-Agent System）的核心挑战在于防止自主体之间因交互失控陷入无限递归死锁。工程治理上必须强制引入以下三条防护规则： 1. 统一任务上下文染色（Propagation Tagging）：跨 Agent 的 Handoff 调用必须传递唯一的 trace_id 与递增的 hop_counter。一轮任务的全局 Hop 数达到物理阈值（如 \(> 10\)）时，系统底座强制执行硬断路（Circuit Breaker），回退转人工。 2. 强制状态机拓扑收敛：各 Agent 之间的通信必须基于固定的消息交换契约（Envelope-based Message），且必须具有单向流转的 Supervisor 终审判定角色，消灭对等体之间的对开递归。 3. 幂等去重与状态版本控制：Handoff 接收端必须实现完全的去重（De-duplication Ledger），防止不同 Specialist 发送的多路冲突事实覆盖全局 State。

4. 在线自我进化（Self-Improvement）的简化案例¶

自我进化不是让模型在运行时随手改自己的 system prompt，而是把“失败 → 复盘 → 沉淀”做成一条离线闭环，让下一次执行受益。以一次工具调用失败为例：

触发：Agent 调用 create_expense_claim 时漏填必填字段 cost_center，工具返回 SCHEMA_MISMATCH 错误信封。
当轮自愈：服务端把结构化错误回喂给模型，模型在同一轮内补齐字段重试成功——这是运行时的 Self-Correction，不涉及“进化”。
离线复盘：如果同类缺字段错误在近一周内出现超过阈值次数，评估管线会把这些失败轨迹抽出来，判断规律是“模型没有意识到 cost_center 是必填项”。
沉淀为 few-shot 或规则：人工或自动审核后，把一条示例（“报销单必须带 cost_center，缺失时先反问用户所属成本中心”）追加进该工具对应的 few-shot 库或工具的 description，作为下次调用前的上下文补充，而不是直接改模型权重。
生效与回归：下一次同类任务命中该 few-shot 后，缺字段率下降；变更本身要跑一次离线回归集，确认没有对其他工具调用造成负面干扰。

这条链路的边界很明确：模型可以“建议”要沉淀什么，但沉淀动作、审核和上线都由确定性的评估管线和人工把关完成，不能让模型在线上直接改写自己的 system prompt 或规则库。

失败模式、排查顺序与中台化演进¶

1. 工业级 Agent 运行时排障顺序¶

当 Agent 发生业务偏移或行为崩溃时，架构师应依据如下顺序执行定向排查： - 排查一（目标与停止条件）：检查 Goal 及最大步数约束是否泄漏，停止条件是否有效激活。 - 排查二（运行时状态保真度）：检测 State 状态机对象是否存在被历史遗存事实污染、槽位值类型覆盖等现象。 - 排查三（工具信封与观察流）：校验工具返回结果是否通过归一化适配层（Uniform Adapter）封装，Error 是否被分类映射（统一信封的字段设计见第七章）。 - 排查四（长周期快照）：分析 Checkpoint 镜像序列化时是否将过期垃圾数据一并回灌，导致恢复冷启动开销暴涨。

2. Agent 平台中台化（Platform Baselines）建设¶

当企业内的 AI 应用从单一智能体扩展至多团队、多场景微服务群时，必须沉淀一套统一的 Agent 运行时公共底座（Agent Platform Base），将如下能力彻底收为平台级中台基础设施： - 公共能力注册表（Capability Registry）：对所有 MCP Server、Skills 和 Tool Calling 契约执行统一注册与 ACL 管控。 - 多租户状态与 Checkpoint 服务：提供跨实例高可用的 Durable State 读写及版本化快照归集存储。 - 多因子记忆治理中台：提供统一的长期记忆去重、合并归档、TTL 遗忘管线与冷热排序计算集群。 - 风险合规与审计平台：跨应用追踪 OODA 循环中的每一次 LLM 决策与真实 Side Effect，提供可视化的物理回放测试床与安全性红蓝对抗（Red Teaming）基准。

中台化不是一步到位的目标，落地时先从能力注册表和统一信封做起——这两项成本最低，也最快能让排障顺序（目标/状态/信封/快照）跑起来；记忆治理中台和红蓝对抗平台可以等业务规模真正压过来再补。

单 Agent、多 Agent 与 Plan-and-Execute 的选择¶

先看一个“查制度并生成带引用答复”的任务：它要检索、核验和写作，但三步共享同一份上下文、权限和失败策略。此时一个 Agent 加明确停止条件就够了。只有职责边界真的出现，例如检索服务不能接触写入权限、审核必须独立留痕，才值得拆出 Specialist。

形态	适用任务	主要代价
单工具直接调用	路径固定、一步完成	表达力有限，但最可靠
单 Agent ReAct	工具较少、路径需动态判断	容易循环，需要停止条件
Plan-and-Execute	多步依赖、需要中途校验和恢复	增加规划时延和状态管理
多 Agent + 状态机/DAG	权限、上下文或团队职责明显隔离	Handoff 损失、成本和编排复杂度更高
确定性 Workflow	流程稳定、合规要求高	适应开放问题的能力较弱

Plan-and-Execute 的规划结果必须可执行、可验证：

[
  {
    "step_id": "s1",
    "task": "检索权限配置资料",
    "depends_on": [],
    "success_criteria": "至少获得两条有效证据"
  },
  {
    "step_id": "s2",
    "task": "生成带引用的回答",
    "depends_on": ["s1"],
    "success_criteria": "每个关键结论均有来源"
  }
]

Plan 的价值在于让多步任务可检查、可恢复。它并不等于正确：执行器仍需逐步检查前置条件、权限、产物质量和总预算。简单问答继续直接执行，避免为了“像多智能体”额外引入交接丢失与状态同步成本。

记忆的时效性与事实边界¶

用户偏好“中文、回答简短”可以长期保存；“该用户目前拥有管理员权限”则不能当作记忆事实。后者必须回权威系统查询，因为它随时可能变化。长期记忆记录稳定偏好、已确认事实和历史结果时，至少保存：

value
source
scope
created_at
verified_at
confidence
ttl / archive_policy

订单状态、权限和库存等强状态必须回权威结构化系统查询。向量记忆只能帮助召回历史线索。通过 TTL 或归档让过期内容退出在线召回，离线合并相似记忆时保留原始来源和审计路径，才能在记忆误导时定位并纠正它。