这次要写的是技术架构主题，我先把工具路由、状态管理、可靠性这三块的最新公开资料查齐。
主稿已经找到，我取回阿里云开发者社区这篇原文，核对它的分层设计和步骤细节。
资料已齐：阿里云原文，加上 MLflow、LangGraph、AWS、Anthropic 的对照材料。下面是按你的模板整理好的版本。
想做出真正能在生产跑的高可靠 AI Agent，靠的不是换个更强的模型，而是三件工程活：把可靠性从提示词里搬到代码层、把工具从 “全塞给模型” 改成 “按需路由三五个”、把会话从内存里的 while 循环改成可持久化、可恢复、带幂等号的检查点。阿里云开发者社区 2026 年 11 月 13 日那篇实战指南把问题说得很直白：Agent 落地的三大断裂点是大模型输出不可控（幻觉、格式错误导致下游解析失败）、多工具协同缺统一调度（网络波动或参数不匹配就断链）、长任务上下文溢出（历史状态无法持久化，对话中途断掉），传统提示词工程已经压不住这些不确定性，必须上分层解耦的工程架构。
这套架构的骨架是四层：感知层提取实体与意图、过滤低置信度请求；决策层用 ReAct 的 “思考 — 行动 — 观察” 闭环，配一张动态工具路由表选执行路径；执行层把工具接口标准化，内置指数退避重试、超时熔断与幂等校验；记忆层用滑动窗口向量检索加 Redis 短期缓存，平衡上下文长度和信息连贯。所有校验、日志、权限都硬编码在代码层，不靠提示词隐式约束。
一、为什么 “高可靠” 不是模型问题
一个被反复验证的判断是：生产环境的可靠性绝大部分不在模型里，而在包住模型的那层编排代码里。MLflow 团队的工程实践给出的说法更极端 —— 生产级 harness 要承担 98% 的可靠性，校验逻辑、权限检查、重试处理都该活在编排代码中，把模型当成可靠性层是早期项目最常见的架构错误。
三类断裂点和对策可以这样对照：
| 断裂点 | 现场表现 | 代码层对策 |
|---|---|---|
| 输出不可控 | JSON 缺字段、类型错、编造参数 | 强类型校验（Pydantic / JSON Schema）+ 解析容错 + 重试一次带纠错提示 |
| 调用链断裂 | 某个 API 超时，整条任务悬空 | 超时、熔断、指数退避、降级到备用接口 |
| 上下文溢出 | 聊到第 20 轮忘了初始目标 | 状态外置到存储，上下文只装本轮需要的摘要 |
| 副作用重复 | 重试导致重复下单、重复扣款 | 幂等键 + 执行效果登记表 |
二、四层解耦：把模型的能力边界外移
| 层 | 职责 | 关键约束 |
|---|---|---|
| 感知层 | 实体与意图提取、低置信度拦截 | 置信度低于阈值直接转人工，不要赌模型能猜对 |
| 决策层 | ReAct 闭环 + 工具路由 | 必须有最大步数与终止条件，不能靠模型自己说 “做完了” |
| 执行层 | 工具调用、重试、熔断、幂等 | 所有工具走同一层封装，禁止业务代码直连外部 API |
| 记忆层 | 短期会话缓存 + 长期检索 | 上下文按需装配，不做整段历史无脑拼接 |
这套分层最实际的价值是责任边界清楚：模型只负责 “下一步做什么” 的判断，能不能做、做了会不会出事的判断全在代码层。Anthropic 在讲工作流模式时也强调同一点 —— 只在复杂度真能换来效果时才加复杂度，因为每一层都会带来延迟、成本和新错误源。
三、工具路由：核心是 “别让模型看到全部工具”
两个数字值得记住：一是 MLflow 明确说，如果一个 Agent 同时注册超过 8 个工具，那是设计问题，不是能力缺口；二是按职能拆分 sub-agent 隔离上下文，相比单一大 Agent，性能提升最高可达 90.2%—— 这个数字反映的是无关上下文对推理质量的侵蚀。
路由本身有三种常见形态，适用场景完全不同：
| 形态 | 怎么工作 | 适合什么 | 风险 |
|---|---|---|---|
| 静态规则路由 | 关键词 / 意图分类器直接映射到工具组 | 场景收敛、类别清晰（退款、查单、技术支持） | 边界样本容易误判 |
| 动态上下文路由 | 模型按当前上下文从路由表选路径 | 任务形态多变、工具多 | 路由本身也会幻觉，需要候选集白名单 |
| 分层路由（主管 — 专家） | 主管 Agent 派活给领域 Agent，各自只带自己的工具 | 跨域复杂任务 | 链路变长，延迟与成本上升，需要逐层追踪 |
Anthropic 把 routing 列为独立的工作流模式，逻辑是 “先分类、再交给专用下游”，好处是能针对某一类输入单独优化提示词，不至于为了照顾一类输入而拖累其他类；它还特别提到模型路由：简单常见问题丢给便宜的小模型，难而少见的问题交给能力更强的模型，以此同时优化成本和响应时间。
路由表该长什么样，别写成一句自然语言描述，要写成可校验的结构：
| 字段 | 示例 | 作用 |
|---|---|---|
| tool_id / 名称 | refund_check | 唯一标识，日志与追踪的主键 |
| 能力描述 | “查询订单是否可退，输入订单号” | 给模型看的语义，也是检索工具的依据 |
| 输入 Schema | {order_id: string, reason?: enum} | 强类型校验，挡住参数幻觉 |
| 副作用等级 | 只读 / 可重试写 / 不可逆写 | 决定是否需要人类确认 |
| 幂等性 | 支持幂等键 / 不支持 | 决定重试策略 |
| 超时与预算 | 3s、单任务最多调用 5 次 | 熔断与费用控制的输入 |
| 权限域 | 仅限本人订单 / 需二次授权 | 结构化的最小权限，不靠提示词 |
四、状态管理：会话不是聊天记录，是可恢复的检查点
这里最容易踩的坑，是把 “状态” 理解成 messages 数组。真正要持久化的是任务的可恢复现场。LangGraph 的做法可以当参照系：checkpointer 存线程内的图状态快照，用于会话连续性、人机协同、时间旅行和容错；store 存跨线程的应用数据，用于用户偏好、事实和共享知识。
它的三种持久化模式，本质是 “快” 和 “不丢” 的取舍：
| 模式 | 何时落盘 | 代价 |
|---|---|---|
| exit | 只在执行退出（成功 / 异常 / 人工中断）时持久化 | 性能最好，但进程崩溃时中间状态全丢 |
| async | 下一步执行时异步写 | 兼顾性能与耐久，进程在写盘前崩溃仍有小概率丢检查点 |
| sync | 运行全程写，结束时等待未完成的写 | 耐久性更高，慢存储会拖慢整体 |
想做到 “断点续跑”，光有检查点不够，还得管住副作用。一个被验证可行的结构是三张表：runs（任务级）、steps（步骤级检查点）、effects（外部副作用登记 + 幂等号）。恢复时先重载最新快照和事件日志，修复不完整的工具调用记录，再主动回查外部环境的真实状态（文件是否已写、订单是否已创建），基于真实状态重新规划，最后验收结果、杜绝重复副作用。
状态里到底该存什么，按 “丢了会出事” 来筛：
| 必存字段 | 为什么必须存 | 丢了会怎样 |
|---|---|---|
| 原始目标 + 验收标准 | 防止长任务目标漂移 | 越跑越偏，最后交付一个 “看起来完成” 的东西 |
| 已完成步骤与产出引用 | 避免重复执行 | 重复调用、重复扣费 |
| 工具调用与结果摘要 | 恢复时不必重放全部历史 | 恢复成本高，甚至无法恢复 |
| 待人类确认的决策点 | 人机协同的断点 | 中断后无人知道卡在哪 |
| 幂等键与副作用登记 | 保证重试安全 | 一次任务扣两次钱 |
| 预算消耗（步数 / Token / 金额） | 熔断依据 | 死循环烧钱 |
五、执行层：把不确定性限制在可控范围内
执行层的目标不是 “让调用成功”，而是 “失败也可控”。可用的策略组合：
| 故障类型 | 处理策略 | 保底手段 |
|---|---|---|
| 瞬时网络错误 | 指数退避重试 2—3 次 | 切备用接口 |
| 上游持续超时 | 熔断，本步标记失败 | 返回可读的降级结果 |
| 参数不合法 | Schema 校验拦截，回灌错误让模型修正一次 | 转人工，不无限自我纠正 |
| 写操作结果未知 | 先查真实状态，再决定是否重放 | 幂等键去重 |
| 步数或预算耗尽 | 强制终止并输出已完成部分 | 生成待续跑任务，交人工接管 |
配套的两个硬开关：最大步数和 Token 预算。阿里云那篇明确提醒要设合理上限，避免死循环或无限重试导致费用失控，并建议用缓存复用相同查询；同时要做安全隔离，禁止把未校验的用户输入直接拼进工具参数，必须用强类型 Schema 校验来挡注入。
工具本身的形态也决定可靠性。Anthropic 在高级工具用法里给了一个很实用的方向：让模型用代码编排工具（Programmatic Tool Calling），把循环、条件、数据转换和错误处理写成显式代码，而不是靠自然语言一轮轮调；同时强调适合这样做的工具是 “可并行、且可安全重试” 的那一类。
六、可观测与验收：看过程，不只看终态
只统计 “任务成功率” 会掩盖问题，因为它把 “模型绕了 30 步才勉强做对” 和 “3 步干净做完” 算成同一件事。生产上更该盯这五个指标：
| 指标 | 说明 | 异常信号 |
|---|---|---|
| 工具调用成功率 | 按工具、按参数类型细分 | 某工具长期高失败，多半是契约写得模糊 |
| 升级率（转人工比例） | 反映自治边界是否合适 | 过低说明在硬扛，过高说明能力不足 |
| 每步延迟 | 定位慢在模型还是工具 | 端到端延迟常被规划环节主导 |
| 单任务成本 | Token + 工具调用费用 | 突增往往是循环或重复调用 |
| 上下文利用率 | 有效信息 / 总 token | 偏低说明装配策略在浪费窗口 |
可观测性要有贯穿链路的 Trace ID，用 OpenTelemetry 之类把每次工具调用串起来，才能快速定位瓶颈和异常节点；更进一步是评估 “过程级约束是否满足”，而不只看终态完成 —— 多工具编排的研究里也把中间检查点用于可判定校验、把可观测性扩展到过程约束，列为控制错误级联的关键手段。
七、从 Demo 到生产的落地顺序
顺序错了会返工，这套顺序相对省事：
| 步骤 | 做什么 | 验收标准 |
|---|---|---|
| 1 | 先定自治等级（多数场景 L1/L2，模糊与高风险决策升级给人） | 写清哪些动作必须人工确认 |
| 2 | 写工具契约：Schema、异常码映射、副作用等级、幂等性 | 每个工具都能被单独单测，含非法输入用例 |
| 3 | 建路由表，按职能切分领域 Agent，单 Agent 工具数控制在 8 以内 | 路由误判有白名单兜底，不会调到越权工具 |
| 4 | 接持久化 checkpointer + 幂等键 + 副作用登记 | 杀掉进程后能从检查点续跑，不重复产生副作用 |
| 5 | 加预算与熔断：最大步数、Token 上限、超时、降级路径 | 注入故障能停在安全状态，不烧钱 |
| 6 | 埋点与回归：五指标看板 + 用例集（含负例与边界例） | 每次改动有对应用例回归，pass rate 门禁 |
八、六个会让项目出问题的不当做法
| 不当做法 | 后果 |
|---|---|
| 一个 Agent 挂 20 个工具 | 上下文被工具描述淹没，选择准确率下降 |
| 用提示词做权限控制 | 可被注入绕过，等于没有权限 |
| 状态存内存字典 | 进程一重启，任务全丢 |
| 只加重试不加幂等 | 重复下单、重复扣款，事故级别 |
| 没有最大步数 | 循环打转，账单失控 |
| 只看终态成功率 | 掩盖了绕路、超成本、越权调用 |
一句能落地的判断：高可靠 AI Agent 的护城河是 “模型判断 + 代码约束 + 可恢复状态” 这三件套的组合，模型强弱只是其中一项；先把第 4 步（持久化与幂等）和第 5 步（预算与熔断）做扎实，比换更贵的模型更能降低线上事故率。
【常见问题】
问题 1：构建高可靠的 AI Agent，最先该改的是模型还是编排层？
回答 1：先改编排层。生产环境的可靠性绝大部分由 harness 承担，校验、权限、重试都该放在模型外面的代码里，把模型当成可靠性层是最常见的架构错误。具体动作是：给工具写强类型 Schema、给主循环加最大步数与终止条件、把状态从内存搬到持久化存储。这三件事做完，再考虑换模型，收益顺序才正确。
问题 2：AI Agent 的工具路由为什么要限制工具数量，超过 8 个真的不行吗？
回答 2：8 这个数字是经验阈值，不是硬标准，但它指向一个真问题：工具描述会占满上下文，选择准确率随数量下降。更稳的做法是按职能拆分子 Agent（账单、排期、退款各管一摊），让每个 Agent 只看到自己那几个工具，靠上下文隔离提升推理质量。如果业务确实需要很多能力，用分层路由 —— 主管 Agent 先分类，再派给带专属工具的专家 Agent，而不是把所有工具塞给一个入口。
问题 3：AI Agent 的状态管理，存聊天记录够不够？
回答 3：不够。聊天记录只解决 “说了什么”，解决不了 “做到哪、能不能接着做”。状态管理至少要包含：原始目标与验收标准、已完成步骤与产出引用、工具调用与结果摘要、待人工确认的决策点、幂等键与副作用登记、预算消耗。其中幂等键和副作用登记最关键 —— 没有它们，重试就可能变成重复扣款，这是从 Demo 走向生产最容易出的事故。
问题 4：AI Agent 任务执行到一半崩溃，怎么做到高可靠地续跑？
回答 4：靠检查点加真实状态回查。先按线程标识重载最新状态快照与事件日志，修复不完整的工具调用记录，然后主动查询外部环境的真实状态（文件有没有写、订单有没有建），基于真实状态重新规划，最后验收并杜绝重复副作用。注意检查点模式的选择：只在退出时落盘最省性能但崩溃必丢中间态，异步写兼顾两者，同步写耐久更高但受存储速度拖累。
问题 5：高可靠 AI Agent 应该监控哪些指标，只看成功率行不行？
回答 5：不行。只看成功率会把 “绕三十步勉强做对” 和 “三步干净做完” 算成一样。至少要盯五个：工具调用成功率（按工具和参数类型细分）、升级率、每步延迟、单任务成本、上下文利用率。再加上贯穿全链路的 Trace ID，才能判断问题出在模型、工具还是路由。更成熟的做法是评估过程级约束是否满足，而不只看终态是否完成。
问题 6：中小团队落地高可靠 AI Agent，有没有低成本的最小可行架构？
回答 6：有，四件事就能撑起一个不错的基线。第一，单 Agent + 不超过 8 个工具，用规则路由先跑通一类场景；第二，每个工具一份强类型 Schema，输入输出都校验；第三，状态落一张表（任务、步骤、副作用三列即可），带幂等键；第四，加最大步数和 Token 预算两个硬开关。这套跑稳之后再引入子 Agent、向量记忆和分布式追踪，不要一上来就上多层多 Agent。
【参考资料】
[2026-11-14]（Checkpointers：线程、检查点与三种持久化模式）LangChain 文档（本次查阅日期）
[2026-11-13]（构建高可靠 AI Agent 落地架构：从工具路由到状态管理的实战指南）阿里云开发者社区
[2026-11-09]（Pluggable Agentic AI Framework: A seven-layer composable enterprise agentic AI reference architecture on Amazon Bedrock AgentCore）AWS Machine Learning Blog
[2026-09-18]（Server First Agent Server Architecture for Engineers）MLflow
[2026-09-02]（A guide to the anatomy of effective commerce agents）Anthropic（Claude）
[2026-06-09]（AI Agent Tool Use Best Practices for Practitioners）MLflow
[2026-01-13]（Build durable AI agents with LangGraph and Amazon DynamoDB）AWS Database Blog
[2025-11-24]（Introducing advanced tool use on the Claude Developer Platform）Anthropic
[2024-12-19]（Building Effective AI Agents）Anthropic
免责声明：本文依据 2026 年 11 月 14 日前可公开访问的技术文章、官方文档与工程博客整理，属于架构方法与实践经验梳理，不构成任何具体项目的技术选型结论、性能承诺或安全合规意见。文中引用的量化结论（如 harness 承担 98% 可靠性、子 Agent 隔离带来最高 90.2% 提升、单 Agent 工具数不超过 8 个）均为相应来源作者的实践观察或经验阈值，非严格基准测试结果，实际表现随模型、工具契约质量、业务分布差异很大。表格中的分层、路由与状态字段为通用设计建议，落地时需按自身合规要求（数据留存、审计、最小权限）调整；涉及金融支付、医疗、身份认证等高敏场景，请另行完成安全评审与压力测试。LangGraph 文档条目时间为本次查阅日期，非内容发布时间；各框架版本与 API 可能已更新，请以官方最新文档为准。