第 14 章 可观测性与运维

这一章讲智能体系统的运维三件事：运转得怎么样（14.1 链路追踪，主线是 OpenTelemetry 的语义约定，埋点字段不攥在任何一家厂商手里，主流工具与 Collector 收口一并讲；14.2 信号与告警，观测的事前一半），钱烧在哪里、烧得对不对（14.3 成本工程，逐次记录成本、乘数估算、模型路由、前缀缓存），节点重启或接口超时之后跑到一半的任务怎么收回（14.6 检查点与故障恢复，覆盖断点续跑、无状态扩展和替补模型）。规模决定了这些活躲不开：demo 跑十条案例一屏日志就够，生产一天十万次会话没人盯得过来，出了事第一件事是把出问题的那几次运行完整调出来，这正是链路追踪的职责，第 12 章的轨迹思路搬到运维，trace 与轨迹追同一套对象，生产版本多出跨进程跨服务，再加报警和留存。14.4 列十种生产失败模式的诊断清单，每条讲清症状、定位与防线；14.5 沿清单里挖得最深的第 8 条讲元认知与自我改进。贯穿全章的例子仍是快递客服。

14.1 AgentOps 与链路追踪

AgentOps 是行业给智能体运维起的名字，这一节讲它的地基，链路追踪：把每次运行记成结构化的 trace，出了事能按会话把现场完整调出来。快递客服上线两周后的一个下午，改址成功率从九成掉到六成，客诉跟着涌了进来，值班工程师想做的第一件事，是把那几次失败的运行原样调出来；可服务器翻了个遍，能找到的只有 print 留下的碎片，工具名记了、参数没记，轮次记了、token 又没记，这些输出还跟业务日志混在一处，想按会话捞齐根本没头绪。第 12 章 12.2 提过，轨迹记录应当做成基础设施；链路追踪在这里把这句话兑现。

AgentOps 一词的来历要往前捋一捋。DevOps 管的是确定性软件的交付，MLOps 在它基础上加了模型监控、再训练与数据治理这几块，等生成式应用兴起，又分化出 GenAIOps 这一支，再按关注点往下分，就是提示运维、RAG 运维与 AgentOps 三支。

这套演进是层层叠上来的，新一支并不替换老一支，底下那一层一点没少，CI、测试和数据治理，智能体照样全要。AgentOps 在它上面补的是智能体独有的四块，评测不再只看最终答案，还要看轨迹与工具选择；工具得有人注册、有人治理；智能体自身要有目录、管版本；记忆那一块，数据权限也得有人负责。

监控跟评测是什么关系？把评测搬到实时场景里跑，就是监控，两者大概率共用同一套指标。第 12 章那套指标接上生产环境，正是按这个判断做的。

链路追踪围着两个核心概念转。trace 对应 12.2 的轨迹，是整次任务的完整链路。span 是这条链路上有头有尾的一段操作，一次模型调用算一个，一次工具执行算一个，整个智能体运行也算一个。span 与 span 构成父子关系，一层层嵌套出来就是 12.2 那棵轨迹树的形态，只是这里的表示是结构化的。这套东西不是智能体圈子先搞出来的，做分布式观测的标准 OpenTelemetry（OTel）早就把它定成了跨语言规范，智能体系统的可观测性应当直接建在这套标准上，而不是自造一套格式。

要建在这套标准上，就得先认识语义约定（semantic conventions），它是一份大家事先讲定的字段名与取值口径。缺了它，A 团队把模型字段记成 model，B 团队记成 model_name，两边的数据就算汇进同一个后端也没法对上。

OpenTelemetry 为生成式 AI 准备了一整套属性，都收在 gen_ai 命名空间底下。截至 2026-08，这批约定仍标着开发中（Development），维护已经从主仓库搬到独立的 GenAI 语义约定仓库，mcp、openai 等命名空间也归这个仓库一并管着。

再往细看，span 的命名各有各的规则。模型推理的 span 按 chat {模型名} 命名，工具执行的 span 是 execute_tool {工具名}，智能体层另有 create_agent、invoke_agent、invoke_workflow、plan 这些约定。关键字段摘录如下。

字段	装什么
gen_ai.operation.name	操作属于哪种，chat、execute_tool、invoke_agent 这类取值
gen_ai.provider.name	记录提供方是谁，openai、gcp.vertex_ai 这样的标识
gen_ai.request.model / gen_ai.response.model	请求发出的模型与实际应答的版本，两者分开记
gen_ai.usage.input_tokens / gen_ai.usage.output_tokens	输入、输出各消耗的 token 数
gen_ai.conversation.id	会话标识，同一会话的多次请求靠它串成一条
gen_ai.prompt.name / gen_ai.prompt.version	用了哪个命名模板、模板的哪个版本
gen_ai.tool.name / gen_ai.tool.call.id	调用的工具名，加上本次调用的 ID
error.type	出错时记错误类别，取值保持在低基数

字段层有两条纪律得先定死。像输入输出原文、工具参数和工具结果这类内容字段，例如 gen_ai.input.messages、gen_ai.tool.call.arguments，在约定里属于 Opt-In 级，默认不落记录；真要记录，脱敏这一关先得过。快递客服的轨迹本身带着姓名、电话、地址，把原文直接送进观测系统，等于把数据又泄露了一遍。采样的逻辑也是同一条，token 计数这类字段，生产流量全量记没有问题；原文字段就按比例抽，或者干脆只留一个长度。第 13 章的最小权限原则，放到观测层同样管用。

字段定完，trace 这一层的采样也得拿主意，毕竟追踪本身带着延迟与存储的成本。通行的经验是按阶段分成三档。开发与测试期不留死角，100% 全量记。进了生产就换个策略，错误轨迹照旧 100% 记，成功轨迹只抽一个子集，通常 10% 到 25%，这个量已经够察觉推理漂移。撞上事故复盘、重大架构变更这类要紧期，就把采样临时调回 100%，这段时间内什么都能看到，过后再降下去。预算没烧在噪声上，要紧的时刻又能看全。

截至 2026-08，tracing 工具大致分成两派。一派是 LangSmith，出自 LangChain 团队，商业平台，以托管服务为主，调试、测试、监控和数据管理全配在一处，跟 LangChain 生态合得最紧，同时接受标准 OTLP 导入，自己插桩埋的点也能送进它的看板。

另一派是 Arize 的 Phoenix，走开源路线。pip install arize-phoenix 装完，一条 phoenix serve 就能把服务起起来，界面开在 6006 端口，追踪数据经 OTLP 协议进来。用 Docker 部署时，把 6006 与 4317 两个端口一并映射出来，数据就能全程留在自家机房。

Phoenix 的自动插桩靠 OpenInference，这是一套由 Arize 发起的插桩标准，建在 OTel 传输层之上，自带一组 openinference 属性名，LangChain、LlamaIndex 这些主流框架都在覆盖之内。官方的 gen_ai 约定现在跟它并行，前者还处于开发中，选型时照着自家框架的插桩覆盖情况对接就行。

数据出不了域，Phoenix 就自托管；想省下存储与界面那部分工程量，顺带还想要平台化的评测，就交给 LangSmith。两者并不冲突，埋点照 OTel 标准写，后端随时可以换。

埋点与后端之间，还常垫一层 OpenTelemetry Collector。应用只管把 OTLP 数据吐给它，剩下的事都在这一层集中办，采样策略下沉到这里，换框架、换语言不用重写一遍；原文字段的脱敏在收口处统一做，省得每个服务各守一道；一家后端不够用，往多家分发也是它的活。要换后端，改的只是 Collector 的导出配置，应用一行不动。

想看清这套机制的最好办法，是手动埋点。下面用第 2 章那条客服回路，不借助任何框架的自动插桩，自己把 span 埋一遍。先装 SDK，pip install opentelemetry-api opentelemetry-sdk。

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter
from opentelemetry.trace import SpanKind

provider = TracerProvider(
    resource=Resource.create({"service.name": "express-cs"})
)
provider.add_span_processor(BatchSpanProcessor(ConsoleSpanExporter()))
trace.set_tracer_provider(tracer_provider=provider)
tracer = trace.get_tracer("express-cs")

这条回路总共埋三个点。根 span 包住整次运行，模型调用与工具执行各占一个子 span。

def run_agent_traced(user_input: str, session_id: str,
                     max_turns: int = 8) -> str:
    with tracer.start_as_current_span("invoke_agent") as root:
        root.set_attribute("gen_ai.operation.name", "invoke_agent")
        root.set_attribute("gen_ai.agent.name", "express-cs")
        root.set_attribute("gen_ai.conversation.id", session_id)

        messages = [
            {"role": "system", "content": "你是快递平台的客服助手，用中文回答。"},
            {"role": "user", "content": user_input},
        ]
        for _ in range(max_turns):
            with tracer.start_as_current_span(
                    f"chat {MODEL}", kind=SpanKind.CLIENT) as span:
                span.set_attribute("gen_ai.request.model", MODEL)
                response = client.chat.completions.create(
                    model=MODEL, messages=messages, tools=tools
                )
                span.set_attribute("gen_ai.usage.input_tokens",
                                   response.usage.prompt_tokens)
                span.set_attribute("gen_ai.usage.output_tokens",
                                   response.usage.completion_tokens)

            message = response.choices[0].message
            messages.append(message)
            if not message.tool_calls:
                return message.content

            for tool_call in message.tool_calls:
                name = tool_call.function.name
                with tracer.start_as_current_span(
                        f"execute_tool {name}") as ts:
                    ts.set_attribute("gen_ai.tool.name", name)
                    ts.set_attribute("gen_ai.tool.call.id", tool_call.id)
                    args = json.loads(tool_call.function.arguments)
                    result = tool_map[name](**args)
                    # 示意只截断控体积；生产先过第 13 章脱敏，或只记长度
                    ts.set_attribute("gen_ai.tool.call.result",
                                     result[:200])
                messages.append(
                    {"role": "tool", "tool_call_id": tool_call.id,
                     "content": result}
                )
        return "已达单次任务的轮数上限，请稍后再试或转人工。"

把 span 树画出来，每段操作占一条。invoke_agent 的条从任务开始一直拉到结束，chat 与 execute_tool 的条按时间嵌套在里面，条的长短对应的就是这段操作的耗时。

任务跑完，控制台打出的就是图里这棵树。把导出器从 ConsoleSpanExporter 换成 OTLP，指向 Phoenix 的 4317 端口，同一份数据就进了一个带检索、带筛选的界面。排查事故的做法也跟着变了，以前翻日志，现在点开 trace 直接看树。

回头拿它跟 12.2 手写的 Trajectory 比一比，字段能一一对上，usage 对着 gen_ai.usage，消息历史对着内容字段。工程量没多出多少，得到的却是跨服务、可报警、能留存的运行记录。开头那场事故，要是当时就有这套东西，失败会话顺着 gen_ai.conversation.id 一捞一个准。

这套 trace 数据还有个顺手的好处，评测数据集可以直接从里面取材。第 12 章攒任务集靠人工构造加回流，链路追踪把生产里的真实会话完整记了下来，从里头挑出典型样本、打好标注、纳进版本管理，就是一条现成的来路，主流观测平台都带数据集导出。导出来送回第 12 章的评测，生产到评测的闭环就此接上。

14.2 信号与告警

这一节讲观测的事前一半，信号怎么设计、告警什么时候响；链路追踪只负责事后，等人翻出 trace 复盘时，损失多半已经发生。输出质量分三层盯。最直接的是规则过滤，用几条规则扫每一条响应，把显眼的问题抓出来，比如空响应、头一次尝试就拒绝帮忙、内部报错泄漏进答复，还有过度自信，断言下得过满，一点限定都不带。再往上一点是统计监控，看的是漂移，回答长度变了、拒绝率升了、同一个短语开始重复了，这些变化单看一条响应看不出来，放到统计上就藏不住。最上面一层是拿模型当评审，让它按一到五给输出打分，质量好坏从此有了一个能长期跟踪的数字。

评审盯的还可以再深一层，盯到推理过程本身。让第二个模型观察干活模型的思维链，计划里冒出绕开规则、应付检查的苗头，在答案成形之前就能抓到，比只看最终输出灵敏得多。这路数的来处是一项 OpenAI 的研究，拿一个模型监视另一个模型的推理，专抓计划使坏的痕迹。代价也有个名目，叫监控性税（monitorability tax），对坏念头罚得太狠，模型会学会把推理藏起来接着犯错，所以宁可少压一分性能，也要让推理保持啰嗦与坦诚，监控才有东西可看。

输出质量之外，推理这一侧也有数可看，而且都记在同一份 trace 里。任务一旦分级，简单问题交给便宜的小模型、难题交给贵的大模型，各档的错误率就得分开盯。本该由大模型接的难题错给小模型，质量往下走；本该走小模型的简单题错给大模型，烧掉的是钱和时间。这两种错都算判错，代价却两样，揉成一个总数看不清哪头在漏，得分头报。

分级之外还有一条省钱的路，难题不一定非换大模型，给小模型加上推理预算有时也能顶上去。测试时算力的研究结论是，小模型配上足够的思考预算，效果可以胜过参数量大十几倍的模型，两家厂商的推理力度参数就是这条路径的产品化。它的边界是过度思考，简单问题上加预算反而费钱还降准确率，所以预算要按任务难度给。

再有一个值得盯的数，叫回溯率，量的是推理走一步又推翻重来、反复改主意的比例。一步不回的推理未必算好，那多半是只管往前、不肯回头验证；回溯反常地多，多半是最初的判断不成立，推理在原地绕来绕去。分头报的判错率加上回溯率，再配上工具调用的成败率，推理这一侧就上了监控面板。

输出与推理之外，还能按组件再拆一层盯。带记忆图的系统，记忆本身就是一份活的数据结构，它的健康有六个数可看，节点增长率看膨胀不膨胀，边密度看连接是不是过密，簇均衡看内容有没有偏斜，关键查询的尾延迟看检索路径顺不顺，冲突率看新旧事实碰不碰头，时间一致性看时间戳对不对得上。走检索增强的系统，同样按管道阶段各配各的指标，重排环节盯分数方差，提示构建环节盯截断率，嵌入环节盯漂移。这么拆的意义在时差，检索或记忆坏了，输出质量的曲线要晚好几天才跟着走形，中间这几层才是先行信号。

工程上还有一处常被漏掉的测试对象，就是接缝。组件单独测都好，坏常坏在交接处，智能体之间传消息、状态更新和工作流变复杂的那几条缝，端到端的测试要专门冲着它们打。

指标与测试之外，用户的行为本身就是信号。会话中途走人，多半是没得到有帮助的回答；拿到答案马上换种问法再问，说明头一个回答没用；复制粘贴，说明这份回答值得留下；回访频率，透出的是用户信不信任这套系统、愿不愿意一直用下去。另有一种信号经常被人读反，提问、拿答案、紧接着连抛三个追问，这多半是困惑，不是满意。显式评分可能碍于面子给得偏高，行为却骗不了人，暴露的是真实的满意度。

显式反馈也别因为这点就省掉，收的设计有讲究，评分、点评这类出口挂在会话收尾，用户顺手就给；收来了跟隐式信号对着读。数据上了仪表盘，好不好用拿三个问题验，现在正在发生什么，实时流量、成功率、成本速率要一眼可见；该去哪里排查，告警要带可能原因和下一步；业务影响是什么，单次成功的成本、任务完成率要与业务实况对得上。三个问题有一个答不上，这块面板就还欠火候。

信号收了上来，还得有固定的消化节奏。可行的做法是每周抽 30 分钟开一场反馈分诊，负面反馈按五个桶归类，准确性、回答长度、语气、信息缺失和转人工请求。桶与桶之间按业务影响加权，准确性问题最伤用户信任，嫌回答太长多半只是偏好差异。分诊找的是模式，不是一条条去救。同一周里五个用户抱怨同一个毛病，那就是一次值得动手的修改。

人工分诊之外，另有自动适应一路可走。隐式信号不必等人来消化，可以直接拿去推动改进。工单重开率、人工修改次数和测试通过率这类指标，先过一层平滑处理，再写进提示或记忆。举一个例子，某类答复人工改动频繁，就把这些改动的共性凝成一条记忆，下次撞上同类任务，先把这条记忆调出来。

全自动回路得装上防噪的护栏，否则一次波动就改一次提示，系统会跟着噪声乱跳。护栏有三条。探索预算，留一小部分流量去试新行为，别把全部的预算都赌在当前最优上。趋势持续才适应，信号朝同一方向连续变上几次才动手，单次波动不作数。花费封顶，给适应动作自身的开销设一个上限，免得回路把预算烧干。这条路适合信号干净、量又大的场景；信号稀薄或噪声大的场景，人审分诊依然更稳。两条路各有各的用处，谁也不必替代谁。

反馈机制本身怎么选，有几对拉扯可以摆出来权衡。质量对规模，人审深但量上不去，自动评分量大但粗；延迟对深度，实时信号浅，复盘式分析深；成本对覆盖，全覆盖贵，抽样便宜；客观对细腻，行为指标硬，问卷访谈软。落到情形上，人力富余、质量优先，走人审分诊；算力富余走自动适应；工期紧，先上轻量的显式评分；监管严的行业，深度和留痕一样不能省，成本往后排。

改的对象除了提示与记忆，还有规则库。智能体的规矩不该只靠人手动添，团队可以定期复盘，把近期的运行日志翻一遍，用不上的规则删掉，常被绕过的规则重新措辞，没覆盖到的新情况补上；这一步现在能让智能体代起草，盯着会话日志找出哪条规则从没被引用、哪条老是被违反、哪些模式没人管，据此拟出增删清单，人来拍板。同样的逻辑放到代码库上就是技术债，实现成本降一个量级之后，按原价永远过不了优先级门槛的清理任务集体过关，让智能体在夜里、周末这类低优先窗口自主去啃，产出人审收尾的清理提交，代码库的渐进改善不再跟功能开发抢工时。

规模再往上走，人手就见底了。管一支舰队的人没法逐个翻每个智能体的日志，海量信息得先压成人能消化的摘要，这一步如今可以交给观察者智能体，专门盯着全舰队的日志与指标，解析过滤，把对运营和维护要紧的部分总结成一份扫一眼就够的简报，原始数据留着备查。用智能体运维智能体，这一类新工种已经在真实生产里出现。

告警设计背后有一条共同原则，盯模式，不盯绝对阈值。延迟一超 5 秒就报，长回答生成期里的正常变慢同样会误触；改成每秒 token 数跌破 20 才报，抓到的才是真实的性能问题。错误率一超 1% 就报，随机散布的错误多半只是噪声；改成错误按用户类型或问题主题聚集成片才报，那种聚集指向的才是系统性问题。每 token 成本比基线上浮 50% 就报，CPU 用量高可能只是流量变大，效率退化才真正值得警惕。

光有告警还不够，系统还得有一个明确的成功率目标。比如定下 95% 的会话达标率，这个目标叫服务水平目标（service level objective，SLO），剩下的 5% 就是错误预算（error budget），这套方法出自 Google 的 SRE 实践。预算一立，失败从事故变成了额度。预算快烧完时主动降级保核心，可选步骤跳过去、模型换便宜一档、重试少几次、只交付部分结果，都是候选动作；预算有余，就放心上新版、做实验。执行上有一条纪律，降不降级由持有预算的编排层说了算，不交给受预算约束的模型自己决定。

排障时还有个分层的小纪律，框架日志与应用日志分开收。SDK 或框架自己的日志混进应用日志，出了事先要分清是框架坏了还是自己的智能体坏了，两套日志各归各，答案一翻就有。聚合统计的背面也得提防，延迟全拿平均数看，尾部那几个慢请求就藏起来了；错误率揉成一个总数，关键路径上的失败会被大流量的正常请求稀释到看不见。该看分位数的时候看分位数，该按路径拆的时候按路径拆。

在 trace 树里，大家最常追问的两个数字是耗时与 token，前者用来定位慢在哪一段，后者决定钱烧在哪一轮。gen_ai.usage.input_tokens 与 output_tokens 这两个字段，正好是成本记录的来源。

14.3 成本工程

智能体系统里最大的不可控开销是模型费。传统软件不一样，服务器成本随流量线性涨，扩不扩容事先算得出来。智能体系统额外多出一层不确定的放大，一次任务要跑几轮、每轮吃进多少上下文、答复吐出多少 token，全都跟着任务难度与提示写法浮动，同一套系统换种写法，费用可能差出几倍。成本之所以失控，往往不是因为价格高，而是因为手头一直没有成本记录，钱花到哪了都说不清。这一节按成本记录、路由和缓存三步往下走，每一步都用快递客服的数字作底盘，个别通用的算例再单独注明。

成本记录的起点，是每次调用的返回值。OpenAI 兼容接口的 usage 里有两个数，prompt_tokens 与 completion_tokens，第 12 章 12.2 的 Trajectory 早就在累计它们了。

DeepSeek 这一族的返回里，usage 会附上两个额外的数，prompt_cache_hit_tokens 与 prompt_cache_miss_tokens，一个记缓存命中的 token 数，一个记未命中的，分开上报。

记录的粒度同样有讲究。每次调用的原始 token 记下之后，还要按会话、功能和租户三层聚合，否则回答不了“查单这类任务单均成本多少、哪个租户在超额用”。价格表要单独存放、自带版本号，厂商调价是家常便饭，历史用量按当期价格重算一遍，跨月对比才有意义。最小的成本记录长下面这样。

from dataclasses import dataclass

# 每百万 token 人民币价，下面是示意值，按各家官方定价页自行填入；未填命中价的按未命中价保守计入
PRICE_TABLE = {
    "kimi-k3": {"input_miss": 10.0, "input_hit": 1.0, "output": 50.0},  # 示意价
    "qwen-flash": {"input_miss": 0.05, "output": 0.5},  # 示意价
}

@dataclass
class CostLedger:
    model: str
    miss_tokens: int = 0
    hit_tokens: int = 0
    output_tokens: int = 0

    def record(self, usage) -> None:
        miss = getattr(usage, "prompt_cache_miss_tokens", None)
        hit = getattr(usage, "prompt_cache_hit_tokens", None)
        self.miss_tokens += miss if miss is not None else usage.prompt_tokens
        self.hit_tokens += hit if hit is not None else 0
        self.output_tokens += usage.completion_tokens

    @property
    def cost(self) -> float:
        p = PRICE_TABLE[self.model]
        hit_price = p.get("input_hit", p["input_miss"])
        return (self.miss_tokens * p["input_miss"]
                + self.hit_tokens * hit_price
                + self.output_tokens * p["output"]) / 1e6

代码里的两套单价都只是示意，量级分别照着 2026 年的高与低两档去取，真实数字需按各家官方定价页填入。命中价按未命中价的一折来算，这样一个十倍价差在真实定价里并不少见，下面的算例正是按这个价差算的。

成本不妨换一套价目来算。客服线原来用 deepseek-v4-flash，这里改用 kimi-k3，记录方法不随模型变。假设系统提示加工具描述构成 3000 token 的固定前缀，每一轮再新增 1000 token 的消息与工具结果，平均 4 轮收尾、每轮输出 300 token，全程走 K3，缓存一次也没命中，那么单次会话输入合计 22000 token、输出 1200 token。照示意价计算，成本等于 0.22 加 0.06，也就是 0.28 元。日均 10 万次会话，一天 2.8 万元，一个月累计 80 多万元。

三层聚合写成代码，就是拿同一份调用流水，按会话、功能、租户三个维度各归拢一遍。

"""示意代码：按会话、功能、租户三层聚合成本的最小实现，python3 可直接运行。"""

from collections import defaultdict

PRICE = {"input_miss": 10.0, "input_hit": 1.0, "output": 50.0}  # 每百万 token，示意价
CALLS = [   # 每次调用的流水（数据为示意）
    {"session": "s-1", "feature": "查单", "tenant": "华东租户",
     "miss": 1200, "hit": 800, "out": 300},
    {"session": "s-1", "feature": "查单", "tenant": "华东租户",
     "miss": 900, "hit": 1600, "out": 280},
    {"session": "s-2", "feature": "改址", "tenant": "华北租户",
     "miss": 2400, "hit": 500, "out": 420},
]

def call_cost(c: dict) -> float:
    """单次调用按未命中、命中、输出三行价目折算，单位元。"""
    return (c["miss"] * PRICE["input_miss"]
            + c["hit"] * PRICE["input_hit"]
            + c["out"] * PRICE["output"]) / 1e6

def aggregate(calls: list) -> dict:
    """同一份流水，按会话、功能、租户三层各归拢一遍。"""
    by = {"session": defaultdict(float), "feature": defaultdict(float),
          "tenant": defaultdict(float)}
    for c in calls:
        cost = call_cost(c)
        by["session"][c["session"]] += cost
        by["feature"][c["feature"]] += cost
        by["tenant"][c["tenant"]] += cost
    return by

if __name__ == "__main__":
    for level, totals in aggregate(CALLS).items():
        print(level, {k: round(v, 4) for k, v in totals.items()})

直接成本记完，还得估一个乘数，部署之前就要算出来。带条件分支的工作流里，一个用户请求会铺开成一串模型调用，其中每一步都只在条件成立时才执行；摊到长期来看，这一步贡献的调用数，等于触发概率乘上触发时产生的调用数。

拿图里这条示例工作流算一遍。护栏每个请求必跑、一趟要发两次调用，摊 2 次；检索八成触发、其中四分之一有上次的结论可以回放，摊 0.6 次；反思只在四分之一的难场景里跑、一跑就是两次调用，摊 0.5 次。路由与推理这两步，一个必跑、一个七成触发，照同样的乘法摊。五步加起来，一个请求平均大约 4.8 次调用，这就是系统的成本乘数。

乘数算的是调用量，还有个更狠的口径，按正确完成的任务计成本。一个失败率高的便宜模型，重试加返工摊下来，未必比一次做对的贵模型便宜，单看 token 单价会把贵贱算反。跟它配套的是质量平价阈值（quality parity threshold），流水线里每个节点各设一条质量下限，定多高看下游能不能补救回来，验证节点错一次比不验证还糟，下限就得钉死；查询分类错了后面还补救得回来，下限可以放宽。延迟同理要按层给预算，每层分到多少事先讲定，超了就查那一层，用户感知的是端到端完成时间，不是某一层跑得多快。

乘数之外还有一条省钱的办法，叫决策级记忆化。它跟稍后要讲的前缀缓存是两回事。前缀缓存打折的是命中的那部分价格，调用本身照样发生；记忆化省掉的则是重复的决策，同样的查询再来一遍，直接把上次结论回放出来，模型一次都不用调。

两者之间还有个中间档，语义缓存（semantic caching）。前缀缓存认逐字一致，记忆化认的是同一个查询，语义缓存认的是意思相近，把来的查询做成嵌入，到向量库里找过往的相似请求，够近就直接回放旧答案，模型照样不用调。装在路由层最划算，企业里的提问高度重复，同一份销售报告一天能被问上几十遍，时延与成本一起省。代价是判相近的阈值要拿捏，卡得太松答非所问，卡得太紧等于没装。

模型路由要做的事，是把贵模型用在最该用的地方。选型的时候有一个大家常提的取舍，精度、速度和成本这三项，一般只能照着优先级优化其中两项。

路由背后的量化底气，同样有现成的数字撑着。简单查询派给小模型、复杂查询留给大模型，大约用 15% 的成本就能换到大约 90% 的表现。这组数字看量级就好，别当成常数。小模型整体要比前沿模型便宜 20 到 30 倍。

放到客服里看，查单、查进度和常见问答这类请求占七成流量，交给 qwen-flash 这类轻量模型，单轮输入 4000 token、输出 300，按示意价约合 0.0004 元。改址、纠纷调解和赔付审批则走 K3，同样一轮约 0.06 元，两者差两个数量级。路由从最笨的实现起步，先用规则挡一层，消息里带“改地址”“投诉”这类关键词就进复杂队列；规则不够使了，再换一个小模型上来当分类器。

这里有两件事得守住。第一件，路由判错的代价比不路由更糟，复杂任务错给小模型，省下的钱以更低的质量还了回去，所以路由分支必须放进第 12 章的评测任务集。第二件，提示与模型是绑在一起的，“指令与模型不匹配”本身就是一种独立的失败模式，系统提示没法在不同模型之间通用；换了模型，就得按模型各维护一份指令版本，再重跑评测验收。

路由这个话题还有一处反直觉的地方。推理模型不是到哪儿都加分，放进多智能体系统，有时反而拖低性能。原因是这类模型容易越权，去抢超出自己范围的角色，比如编排智能体的活。编排要的是按协议把活交出去，不是把每一步都琢磨得更深。所以监督者配上最强的推理模型，未必是多智能体系统里正确的路由选择。

比谁贵谁便宜更容易漏掉的一项，是人的时间。真实的成本公式该是 API 花费加人力时间。来算一个假设的例子，人的时间按一小时一百元折算，便宜模型跑一单要磨半小时，光等待就值五十元；贵模型五分钟跑完，折合八块钱上下，就算它的 API 花费贵上几倍，总成本反倒可能更划算。哪个真贵不一定，但只盯 token 花费，成本一定算错，因为任务总得有人盯着等结果，人的时间也算在里头。

人工审批一上，这笔成本还要再算一遍，因为这回瓶颈换成了人。机器的吞吐按秒算，评审员的吞吐按小时算，一道人工确认挡在关键路径上，系统每秒能扛多少请求就不再由算力决定，而由当班的评审员数量决定。容量规划得照着人做，评审队列多长、单人每小时消化多少单，先量出来；不够就加人，就分级放行，低风险的批量走抽检，高风险的才逐条过，这套分法 15.2 谈审批运营时还会接上。人力这笔没算过，流量一涨，先崩的不是模型，是审批队列。

另一处经常算错的地方，出在价目表怎么读。模型单价不是一个数，输入独占一个价，输出那边普遍贵得多，贵在生成方式上，输入可以一口气并行算完，输出是自回归生成，一个 token 一个 token 串行往外吐，每吐一个都要对着整段前文再算一步；缓存命中又便宜得多。本节那张示意价表装的就是这个结构。要拿自家任务的输入、输出构成去乘这三行价目，才能比出两个模型到底谁便宜。只盯标称的输入单价，在输出占比大的任务上，很可能把两个模型的贵贱算反。

成本工程里最值得做的一件事，要数前缀缓存，它不用动架构。第 1 章 1.6 与第 7 章算过这笔开销，这里补上机制全貌。多轮对话中，每一轮都会把此前的内容一字不差地重发一遍，服务端看到这段前缀与上一个请求逐字吻合，就把算过的部分直接拿来复用，命中的部分照折扣价计费。

Kimi 的上下文缓存对所有请求自动生效，不用引用缓存 ID，但命中设了一道硬门槛，上一个请求的 prompt 必须超过 256 token，之后来的请求才谈得上命中前缀；不到 256 的请求不缓存，直接丢弃。DeepSeek 的磁盘缓存默认开启，缓存单元按请求边界与公共前缀切分，命中与未命中在 usage 里分列两行。

还是同一场 4 轮会话，接着算，结果画在图 14-4 里。

旧内容每轮原样重发，前缀一对上就按折扣价计，图里这场会话除第一轮外每轮都命中，输入侧从 0.22 元压到 0.09 元，单次会话总成本省到大约一半。照日均 10 万会话，一天能省 1.3 万元。当然这是理想化的假设，真实命中率到不了这个高度，但量级大致如此。

命中率多高才算真实合理，可以照提示的构成分档去估。请求以静态系统提示加复用指令为主时，复用比按 0.8 计；模板化的半动态提示，按 0.5 计；高度动态的提示，只剩 0.3。部署前把这几档比例代回算式，得到的才是贴近现实的缓存收益。

命中率不是凭空就有，要经营才出得来。要命中，前提是前缀逐字一致，提示怎么组装于是成了一条工程约束，系统提示与工具描述这类不变的内容永远排最前，用户消息、检索结果、带时间戳的动态字段依次往后放；前缀只要一动，就全废。第 7 章 7.4 那条性质在这里起了作用。投影函数是纯函数，每次调用模型前，把 events 这份事实流水里该给模型看的部分现算成请求，同样的 events 永远算得出同样的请求前缀，命中率的工程保障就在这里。

反过来也一样，提示里掺进当前时间、工具列表按返回顺序动态排序、A/B 实验改到系统提示第一行，都会让命中率持续走低。因此命中率自己就得进监控面板，用 cache_read token 占输入总量的比例去盯，一旦下滑，先查最近谁动了前缀。

这套缓存机制还带自部署的一面。自托管模型会冒出一层开销，这层是部署自带的物理特性：权重得先装进显存，第一个 token 才出得来，冷启动常常要几十秒。缩容到零能省下空闲期的 GPU 开支，代价是每个空闲期结束都得再经历一次冷启动。KV 缓存遇上新前缀就得重算，长上下文再叠上大批次，显存占用跟着上抬，尾延迟跟着走高。

API 侧经营前缀一致性的那条纪律，系统提示不动、动态字段后置，搬到自部署这一侧，直接决定 KV 缓存能复用多少。前缀缓存可把首 token 时间改善二到五倍，这个数同样是量级参考。等到真要为了合规做私有化、自建推理集群那天，这层功课躲不开，省下的是 API 花费，多付的是懂推理后端的工程师的时间。

自部署这边另有几件常规手段。量化把权重从十六位压到四位一档，显存占用降一个量级，一块原本装不下的卡就装下了；并发批处理把同机的请求攒成一批一起出，摊薄单次成本；负载有峰谷，就配自动扩缩容，闲时缩、忙时扩。一个底座服务多个场景的团队，还可以单卡挂多个 LoRA 适配器，底座装一次，各场景的增量各算各的。细节各家推理引擎都有现成文档，照自家引擎配就行。

成本记录给出事实，路由给出结构，缓存给出复用，三件事彼此牵连。成本算得清，才知道路由到底省了多少。命中率有记录，才知道缓存值多少钱。

要趁成本异常还没伤到预算就抓住它，办法是盯紧成本的走向。基线取上周同一小时做同时段对比，正常的使用波动就抹平了。异常长三种样子。尖峰表现为成本陡然翻倍，这类翻倍通常指着一个具体变化，提示词改了、流量激增、路由出错，几小时内要查清。渐进是每天 50% 的涨幅，单看一天金额不起眼，几周按复利涨下去就失控了，比尖峰更难察觉。还有一种最隐蔽，总量不动，单位产出的成本却持续变差。同一件事花的 token 越来越多，说明效率在退化，费用迟早会暴露。

三种形态各自对应一类真实事故。有人改了一次提示词，回答长度涨成三倍，成本跟着爬升。一个路由 bug 让每个查询都落到最贵的那档模型，先前配好的组合根本没生效。还有一种，是用户的问题慢慢向更贵、更复杂的话题偏移，流量结构自己变了样。前两类是系统出了错，第三类是用户变了；成本记录只要按功能、按租户拆开，三类都无处可藏。

成本记录还有一重防御性的用途，叫限额熔断。三道闸从细到粗，任务级管单次运行的 token 上限，正好接住 14.4 第 5 条的“不知道何时停”；会话级管单个用户当天的额度，租户级管整家客户一个月的预算，一碰线就降级或排队。机器资源那一侧的上限，13.2 的沙箱配额已经管上，两边配合起来，失控的智能体烧不穿钱，也吃不垮机器。成本工程做到这一步，钱才算真正管住了。

成本的口径本身也值得推敲。省时口径把收益算成省下的时间，可智能体带来的另一个东西它称不出来，产出量。有些任务按老成本根本排不上号，有了智能体才立项开工，这部分增量在省时口径上是零。只按省时算投产比，会系统性低估。至于省出来的时间去了哪，是干更多的活还是缩了编制，那是组织层的取舍，记录只负责把两头都摆出来。

成本记录之外还有一笔电费。同规模的智能体系统，能耗可以比它替代的传统系统高出一截，长时间大规模跑的系统不能视而不见。对策现成，边缘计算把算力挪近数据，蒸馏把大模型压小，调度避开电网的高碳时段。钱和电，最后都记在可持续性这一份清单上。

成本记录只回答钱花在了哪里，回答不了系统错在哪里；系统会怎么错，业界有现成的归纳，14.4 展开。

14.4 十种生产失败模式

调优走到后半段，最大的坎往往不是手里没方法，而是不知道先动哪里。AutoGen 框架在生产上支持了两年，攒出一套可以直接照用的排查次序。这套次序背后有一个观察，多智能体系统坏起来的方式既一致又可预测。

这套次序一开头是一个优先级框架。系统参数分两层来看，智能体系统层装着指令、工具、记忆、模型选择、编排模式、终止条件和人类委派，模型层则是权重、结构与训练数据。先动系统层，代价最小、收益最大。多数团队在系统层调优，等任务准确率做到 95% 以上，就进入一个值得停下来的平台期。

至于模型层的微调，要放到最后才考虑，只有三种情况值得动手，大幅压缩成本或时延、合规要求私有化和系统层已经调无可调。

三个条件里，“系统层调到头了”这一条最含糊。把它落到实操上，其实是两种具体场景。

先看第一种，残留的失败仍能分出类型。优化进入平台期后，剩下的失败分得出类，一类在分布外（训练数据没覆盖到）的领域知识上，比如不常见材料的化学性质、冷门的监管框架；另一类在反直觉的业务逻辑上，比如呼叫中心里提前挂断客户电话，有时反而是正确行为。这类失败意味着模型缺的是特定领域的推理模式，提示词与工具都补不进去，微调却补得进。另一种是效率场景，准确率已经达标，成本、延迟或隐私迟迟压不下来。

为什么这种场景该轮到微调？因为业务领域有边界。目标任务要求的只是领域内的推理，通用大模型身上却装着两个东西，一个是目标任务的推理能力，另一个是任务从头到尾用不上的广博世界知识。微调的用场，是让小模型把容量从用不到的世界知识里挪出来，专心留给推理。正因如此，在目标任务上调过的 7B，有时能跟 70B 的通用模型打平。

训练数据也有现成的来路，从调优过的系统里收集执行痕迹，就能做出来。学术界这边，2025 年的 Agent Lightning 展示过用强化学习在智能体内部自动收集执行痕迹来训模型，不过这条路目前仍局限在特定任务，而且还要定义显式的奖励函数。

这么一来，决策的工序就有了一个判据，先给残留失败分好类，能对上这两种场景再想微调；对不上，就待在系统层继续调。

下面就是十种生产失败模式。本节逐条过，每条给出症状、定位与防线，快递客服的完整例子留在第 10 条，前面九条不硬套场景。这份清单有两种用法，出了事按症状找对应，上线前拿来当检查表。这种先看症状再倒推原因的做法，就是 3.3 讲过的溯因推理。十条彼此并不独立，分量也各不相同，先分组读会更顺。第 9 条评测托住其余九条的定位与校准。第 1 到 5 条是系统层参数上的毛病。第 6 到 8 条是架构选择上的毛病，代价高一个档次，动它们之前必须先有评测数据打底；清单讲完还会回到这个分组。

1. 指令不够细。症状不难认，任务一复杂，行为就开始飘，同一个输入时好时坏。想定位，摊开轨迹看，模型的决策依据里找不到某条规则，多半是系统提示里没写。防线是把指令当成活文档持续维护，评测每失败一条就补一条针对性规则，好的智能体提示能长到好几页。
2. 小模型没人管。便宜模型一换上来，指令遵循肉眼可见地变差，协调类任务成片地垮，这就是它的症状。定位时看失败分布是否跟着模型切换走。防线分两步，先用最好的模型把基线与任务要求摸透，再走降成本的三条路，路由按难度把请求分流给小模型，蒸馏让小模型照着大模型的输出学，模型级联则让小模型先答、失败再升给大模型。
3. 指令与模型不匹配。换过模型，同类失败就成批冒出来，旧提示到了新模型上用着别扭，症状就是这个样子。想定位，拿换模型前后的轨迹对比分歧点。防线是按模型家族各自维护一份指令集、放进版本库，换模型一定重跑评测验收，用 A/B 过渡代替直接切换。14.3 的路由一节已经撞上过它。
4. 工具质量差。工具选错、参数填错，工具一报错整条回路跟着崩，是它的典型症状。定位时盯轨迹里工具调用段的错误类型分布。防线讲究宁少而精，经验上 10 个可靠工具胜过 50 个平庸工具，而且别忘工具列表本身也在消耗上下文。工具应当永远返回结构化错误而不是抛异常，限流、时效和失败模式要写进工具描述，瞬时错误要带退避重试。同一个错连着犯三回，原样重发大概率还是错，不如换个问法或换条路径再试。
5. 不知道何时停。任务失控、白白烧 token，或者半途而废、丢下明明能解的任务，这些是它的症状。定位看失败构成里 max_rounds 与 timeout 占多少。防线是让终止条件跟指令对齐。有个反例，终止条件等着模型说出 TASK_COMPLETE，指令里却从没告诉模型要说这个词。更稳的办法是提供一个显式的任务状态工具，让模型交出完成态与理由，各种限制阈值拿生产数据来校准。
6. 编排模式选错。症状是 token 烧得厉害，质量却不见起色。要定位，看复杂度对收益划不划算，第 9 章引过的那组实验正好当参照。简单推理任务上，直连模型拿 9.7 分，AI 编排的多智能体只有 9.3 分，两边的 token 花销平均差着 43 倍；工具密集任务上则倒过来，多智能体 9.2 分对直连 6.8 分。防线是从最简单、可能奏效的模式起步，评测证明有收益再加复杂度。另有一句话值得说在前头，很多团队或许根本用不上多智能体。
7. 没有记忆。无状态智能体每次从零起步，同类的问题隔几天换个用户再问一遍，它还得从头解一遍，症状就是这样。定位看轨迹里缺不缺本可复用的历史。防线是照第 8 章的记忆系统按需上。不过记忆自带检索时延与存储成本，值不值得上要拿评测来量，收益盖不过开销就别装，毕竟不是每个智能体都需要记忆。
8. 缺少元认知。长任务一旦跑偏就不回头，一路错到轮数上限，这是它的症状。定位看轨迹里计划与实际进展的偏离是否越拉越大。防线是带复盘的计划式编排，每走一步评估一次进度，不足就重新规划。微软 Magentic-One 靠 10.3 讲过的任务清单与进度清单实现自我监控，最高带来约 31% 的性能提升；基数没交代，当量级看就好。代价是复盘自身也是一次模型调用，值不值同样由评测说了算。
9. 没有评测。所有优化全凭感觉，讲不清这一版比上一版好在哪里，症状就是这个。定位最容易，问一句“上一次改动的效果数据在哪”，对方答不上来，那就是它。防线就是第 12 章讲的整套东西，最小可用的评测从十来条任务起步就够。
10. 不知道何时交给人工。症状可以走两个极端，对模型而言，查快递与发起赔付权重相等，高危动作就这么无人把关；反过来什么都推给人批，审批又形同虚设。定位看高危工具的错误率与审批通过率的分布。防线是按后果给动作分级，只读类自动执行，不可逆类强制审批。经验值是，审批通过率长期高于 95%，说明标准定得过紧。快递客服正是这么做的，查单直接放行，改址与赔付走审批，审批请求挂进第 8 章 8.1 的草稿区等人决定。

清单之外再补一个容易漏诊的症状，MCP 服务器断了连接，常常不报错。看起来的样子是模型忽然不用工具了，转而拿裸 HTTP 请求去兜底干活。监控里见到工具调用量骤降而流量正常，先查连接，别急着改提示词。

长会话也值得单独盯。轮数越往后，单轮输入越大，成本一路往上走，回答质量反而往下掉；定位看输入 token 随轮数的增长曲线；防线是第 7 章 7.3 的压实与摘要，把消化完的旧内容替下来。

九条都得靠第 9 条托住，没有评测，定位无从谈起，防线的校准更无处下手。第 1 到 5 条改的是配置，指令、工具描述、终止条件都在内，改一处按小时算。第 6 到 8 条动的是结构，牵涉编排模式、记忆和元认知回路，动手之前必须先有评测数据打底。

可编排模式与记忆明明写在系统层参数的清单里，怎么一到失败模式就贵起来了？原因在于同在系统层，改指令、补规则属于动配置，换编排、动记忆属于改架构。前面那句“先调系统层，代价最小”，只对动配置那一种成立。

清单的另一重价值，是让团队心里不慌。生产环境里智能体的失败大多有明确原因，是能逐条排除的工程问题；十条排完仍找不到原因，就该回头查评测设施本身。第 12 章提醒过，评测系统要和智能体一视同仁地对待，它自己也会出 bug。

排障靠假设，假设要经得起实验，这里面有几条判别纪律值得立住。每做一个实验，事先把两套预期都写下来，假设成立会看到什么、不成立会看到什么，实验跑完对着判，别事后找解释。连续三次都差一点，那不是快成了，多半是这条假设错了的反证；生产上这叫信心漂移，越试越舍不得放手，最烧时间。多个假设并存时，先挑证据最接近对半开的那个下手，一场实验下去分辨力最强。

清单里除了第 8 条，其余九条要改的东西都在运行过程外面，指令、工具、编排和评测；第 8 条不同，它缺的东西在运行过程里面，得让智能体学会盯着自己。

14.5 元认知与自我改进

清单第 8 条说缺元认知，长任务一旦跑偏就不回头，一路错到轮数上限，背后藏着一笔算术。单个 token 的准确率假设为 99%（这个数字只用于举例，真实的错误率要低得多），那么 100 个 token 连乘，只剩下约 37%，1000 个就仅剩约 0.004%。过程越长，误差复合得越厉害，中途不做检查，小错就会一路乘下去。

缺了元认知的智能体是什么样子，生产日志里常见的毛病有五种。第一种，检索回一页目录，就当权威答案给出来，推理链很干净，输出却是垃圾。第二种，同一条失败的查询原样重试三次，烧光轮次毫无进展。第三种，计划在分解时定下就再没看过，用户描述了相反的场景，还照标准路径走。第四种，没有数据的事不发出不确定信号，而是编一个听着合理的答案。第五种，两个查询各自都会做，遇到要组合的问题，就当一条扁平查询处理。这五种不是边缘情况，是能推理但不会思考的智能体的默认行为，靠提示修不动，得靠结构。

结构上能改的地方是置信度闸门，这个做法的背后有两项研究。Wang 等人 2025 年提出的 DMC 框架发现，从 token 似然导出的隐式置信度，比口头表达的置信度更能预测答案对错。token 似然就是把第 1 章采样那张概率表取对数得到的值，量的是模型对每个候选词的把握。MetaMedQA 基准 2025 年测得更直白，选择题里根本不放正确答案，模型照样自信作答。闸门本身是一组示例阈值。置信度低于 0.3 的，不呈现结果，显式标示不确定。0.3 到 0.6 之间的，先再收集几轮证据，收集次数超限就同样标示不确定。最近三个读数一步比一步低的，触发重查。

停滞检测再配一个。最近两步产出的词面重叠一旦越过 0.7，或者置信度连着几步原地不动，就判系统在做无用功，换条路再试。第 8 条防线里的复盘与重规划，落到代码层就是下面这几个开关。

def gate_on_confidence(steps: list) -> str:
    """置信度闸门。steps 是逐步的记录，每步带 confidence 与补证轮数。"""
    confs = [s["confidence"] for s in steps]
    last = confs[-1]

    if last < 0.3:                       # 不呈现结果，显式标示不确定
        return "uncertain"
    if last < 0.6:                       # 先补证据，补证超限同样标示
        if steps[-1]["evidence_rounds"] >= 3:
            return "uncertain"
        return "collect_more"
    if len(confs) >= 3 and confs[-3] > confs[-2] > confs[-1]:
        return "recheck"                 # 最近三个读数一步比一步低，触发重查
    return "present"                     # 过闸，正常呈现

def bigrams(text: str) -> set:
    """相邻两字组成的片段，不引分词依赖的粗粒度词面。"""
    return {text[i:i + 2] for i in range(len(text) - 1)}

def stalled(steps: list) -> bool:
    """停滞检测：最近两步产出几乎一样，或置信度连着三步不动。"""
    a, b = bigrams(steps[-2]["output"]), bigrams(steps[-1]["output"])
    if len(a & b) / len(a | b) > 0.7:
        return True
    confs = [s["confidence"] for s in steps[-3:]]
    return len(confs) == 3 and confs[0] == confs[1] == confs[2]

代码里的阈值都是示例数，真正的取值要用自家系统的生产数据来校准。闸门把关的是呈现这一关，低置信的结果不出给用户，逼系统要么补证据，要么明说拿不准。停滞检测防的是浪费，同一批结果刷三遍也刷不出新的，一旦检出无用功就换路子。

无用功查出来之后怎么收场，也需要事先设计。硬停算不上好答案，任务半途而废，用户只等来一句失败。更体面的收场是强制决策，摆出两个选项，一是给出当前最好的结果，说明它好在哪、还差什么；二是向用户讲明情况，请对方放宽约束。

现成的例子就在航班搜索里。同一组查询连续三次返回同一批结果，再刷一轮也不会有新结果；这时把当下最便宜的两个选项列给用户，告诉对方再等也等不到更低价，比没完没了地刷或者干脆报错都来得体面。停滞检测挡下的是浪费，强制决策兜住的是用户体验。

这些散件还能再往上收一层，收进一个完整的认知架构。有一类设计把智能体拆成几块专职模块，一块读懂问题，一块定策略，一块执行，一块评估，另有一个注意力角色决定下一个执行的是哪个模块；所有模块共用一份结构化的工作空间，各自读写，评估模块写下矛盾信号，其余模块都看得见。拆法有三个出处，心智社会理论主张智能来自多个专职部分的交互，全局工作空间理论提供了共享工作空间这个部件，双系统理论提供了快慢两条路径，简单问题走快路径直接作答，省下的推理就是省下的 token 和延迟。到 2026 年这条路线仍是探索性的，没成生产共识，先被工程化的正是散件，置信度闸门、停滞检测和知识边界感知，都是从它身上拆下来先用起来的。

修成什么样，得有数可量，四个指标值得长期盯。认知效率，实际步骤数对最优步骤数的比值，比值偏大说明快路径没调好。元认知校准，置信度放横轴、实际正确率放纵轴画散点，校准好的点聚在对角线附近，错得自信、对得犹豫都是偏出去了。适应速率，从检测到停滞到换路成功隔了几轮，越少越好。知识边界准确率，分两头数，简单问题错喊不确定是一头，自信地编答案是另一头。出处见本章参考资料。

元认知再往前一步，是智能体改自己。有个叫 SICA 的研究实现把这件事做到了完整，智能体维护一份自己历史版本的档案，每轮按成功率、耗时与算力开销挑出表现最好的版本，分析档案找改进点，然后直接修改自己的代码，改完跑基准，成绩记回档案，如此循环。隔了几代，它自己造出了更聪明的编辑工具和定位符号的检索器。这个实现里有两道保险值得记，全程在容器里与宿主机隔开跑，另有一个异步的监督模型盯着调用记录，认出死循环或停滞就叫停。监督者独立于执行者、随时可以熔断，这个做法对任何长跑智能体都通用。

进化式优化是同一条路上的另一支。一批模型出提案，一个确定性的评估器给提案打分，候选程序存进一个数据库，留优汰劣，一代代把代码进化下去。谷歌的 AlphaEvolve 用这个路数优化过数据中心调度、矩阵乘法算法和训练内核，官方公布的结果里有一项，数据中心调度平均收回全球算力的 0.7%。这条路的前提是评估器可验证，分数必须算得出来，不能让模型给模型打印象分，正好接回第 12 章的评测。开源实现里，OpenEvolve 把这套循环做成了现成的库。

当场改自己是最重的一档，同一批生产轨迹还有一条更稳的去处，喂回模型层。审批与驳回的记录、人改写过的参数和纠偏的往来，这些躺在日志里的东西，标出哪次行为可取、哪次不可取，就是现成的训练信号；攒够一批，按岗位分别做一轮微调，哪个岗位的行为偏了，就修哪个岗位背后的模型。新旧两版还能按冠军挑战者（champion-challenger）的方式同场对比，老版本当冠军守着流量，微调出的新版本当挑战者跑同一批请求，谁好用谁上，对齐于是成了持续要做的事，不是出厂时定一次就完。这条路的次序也得认下，同一批数据先喂提示、记忆与检索就已经有产出，14.2 的自动适应回路和第 8 章的记忆沉淀干的就是这件事；动权重一定排在最后，上一节开头的判据说的正是它。

这一节讲的自察与自改，针对的仍是行为出错的毛病；清单之外还有两类故障，都不属于行为出错。一类是执行断了，进程重启、节点缩容和下游接口超时，任务跑到一半，执行就没了。另一类是模型不可用，主力模型超时、限流和输出开始走形，回路连第一步都迈不出去。前一类的恢复机制是检查点，后一类交给替补模型。

14.6 检查点与故障恢复

这一节回答检查点在运维层的三个新问题，什么时候存、存到哪、怎么配合发布与扩容，外加替补模型怎么指定。先看为什么必须有它：某个周五晚上客服服务滚动更新，三十多个在途工单跟着 Pod 重启一起消失，其中几个改址任务已经推进到第六轮，地址查完了，修改正改到一半；重跑一遍，token 再烧一次，这还只是钱的问题，麻烦的是副作用，改址这类操作重放一遍等于再改一次，用户那边已经接过一回确认电话。想保住这类工作的进度，得靠检查点。

第 8 章 8.1 已经讲过检查点机制本身，这里不再重复。恢复一次执行要凑齐三类信息，完成了哪些步骤、各步骤产出了什么、共享状态长什么样。WorkflowCheckpoint 这个存档结构装的正是这三类，另带一份工作流结构哈希。恢复之前先比哈希，对不上就拒收，原因在于结构一变，把旧检查点往新结构上套，算出来的结果就不可信。

存的时机，看的是重做一次的代价。模型调用与外部请求之后必须存，这两个东西重跑，要么烧钱、要么有副作用。纯内存的计算，存得粗一点也无妨。实现上可以让执行引擎每完成一步，就自动落一份检查点。

存在哪里，沿用第 8 章的分层口径，测试用内存，单机用文件，分布式用数据库或对象存储。文件后端的好处第 8 章已经说过，单机环境与小团队从它起步最省事。

断点续跑能带来什么，用一个场景就看得明白。数据处理工作流里，校验步骤碰上限流失败了；从头重跑的话，昂贵的 API 拉取与模型调用就得全部再来一遍，而检查点能跨过已经完成的步骤，让这些昂贵操作不再跑第二回。

续跑要安全，前提是步骤尽量幂等，这是这里要补的一条运维纪律。纯读取的工具天生幂等。改址这类带副作用的工具，得设计成先查后改、用请求 ID 去重；重放时一旦发现已经改过，直接返回当前状态就行，用户不必再听一次确认电话。

检查点能管的不只是崩溃，还有“等人”的情形。第 8 章 8.1 提过改址审批那个例子，审批或许几分钟后就到，或许三天后才从邮件里来，这期间进程早已退出。从机制上看，这两种中断是同一件事，执行停了、状态还在；检查点的作用，是把“停下来”一律折算成可恢复的状态。

顺着运维走，还白得两个有用信号。一个叫检查点停留时长，一个任务在同一份检查点上停了几小时，多半是审批卡住，这时该催人，而不是改代码。另一个是同一位置的恢复次数，任务反复从同一断点恢复，说明那个步骤在按某种规律失败，翻一翻 14.4 的清单，通常对得上某一条。

检查点在部署层的回报，就是无状态扩展。检查点一旦进了共享存储，任意 worker 都能接着任意工作流跑。worker 从队列领活，见有检查点就续，没有就新开一份。某台机器停了，另一台取最新检查点跟上，没有哪个任务跟特定机器绑定。吞吐不够就加 worker，负载下来再缩回去，引擎自身无状态，状态都写在检查点里。

第 8 章 8.2 讲过，会话历史与检查点放进数据库、多副本共享，才能解决各容器各记各的毛病，指的正是这套架构。落到客服系统上，这套架构做成之后就是共享检查点库配一组无状态的推理 worker，扩缩容就只是加副本、减副本，在途任务一概不碰。

多个 worker 一起领活，还得防一个坑，两个 worker 同时接管了同一任务。worker 崩了不能立刻让别人接手，它也许只是网络抖了一下，其实还在跑。通行的做法是给任务发一份租约，租约到期还没续上，才允许别人恢复，时长取比最长一步略宽一些的值。任务卡住的状况也顺带管住了。任务卡在某步中间，进程没死，既不报错也不收尾；租约到期没人续，外面照样把它当死任务，放别人接手。嵌入式圈子管这种外部定时器叫看门狗，用的就是同一招。缺了这层保护，重启风暴里同一个改址任务可能并发跑两份，副作用直接翻倍，检查点等于白做。

失败分了五类，队列跟着分层，整幅拓扑见图。

worker 从队列领活的做法再往前走一步，就接到另一条基础设施路线，任务整个放在消息代理上跑，失败处理直接用消息中间件打磨了多年的那套机制。走这条路，头一件事是把故障分清类。瞬时类，网络抖一下自己就好。持续瞬时类，还是会自己好，只是抖得久些。永久类，消息本身有毛病，重试多少遍都白搭。毒消息不但自身失败，还会拖垮处理它的服务。过期或拒收的，真到能处理时早没了意义。五类搅成一团，能做的就只剩一律重试。

分类一旦清楚，分层的重试拓扑就配得出来了。瞬时错与持续瞬时错差在抖多久，分别走短间隔与长间隔两层队列；重试用尽、永久失败与毒消息这几类，搬进一个只读隔离区，即死信队列（dead-letter queue），留给人诊断后重放；过期消息按存活时间淘汰，别让迟到的结果一直占着位置。这套拓扑真正省事的地方在消息头，每条都带着完整的失败史，排查时日志都不用翻。

重试本身也有一笔概率成本。设每次尝试的失败概率是四成，试五次全败只剩约百分之一，失败率压得很低；换来的代价是预算按重试次数线性放大，最坏情况一次任务的模型开销是原来的好几倍。所以重试上限不是拍的，是拿预算换成功率换出来的，上限每加一，成本天花板就抬一档。

这条路线还带三条配套纪律。投递确认要开手动模式，处理完才确认，换来的是至少一次投递；代价是消息可能重复，于是幂等必须做在消费端，跟本节前面讲的续跑安全是同一个原则。预取数调小，worker 一次只领两三条，下游处理不过来时，积压自然顶回队列，背压也就形成了。发布端打开确认回执，防止代理重启时悄悄丢消息。三条的名字都出自 AMQP 一系的约定，RabbitMQ 是常见实现，具体名称怎么对应，照各家中间件的文档来。

代价也得摆出来讲。这条路换回来的是投递保证，消息不丢、失败能分类、超限有去处。要付的是三项：时延多一跳排队，运维多养一套中间件，开发多学一套投递语义。这笔代价付不付，看任务性质。任务丢了会出事、吞吐又大、本来就长在消息架构上的系统，值得付。多数团队的应用，API 循环加检查点已经够用，时延低、运维省事，从这个起点走；哪天真撞上消息绝不能丢的硬需求，再搬家也不迟。

这套对比同样适用于智能体之间、以及智能体对外部 API 的传输选型。让编排者在自己代码里直连 HTTP 调模型、调工具，超时会占住执行线程，重试各写各的，错误没人分类；把调用包进一个消息适配器，异步化、超时、重试和死信全由中间件的现成机制接手，外部服务退化成队列边上一个可替换的消费者。换来的还是那几样代价，至少一次语义要求消费端做幂等，选哪边仍看这笔代价。

用消息代理跑多智能体协作，还有一类故障要心里有数，对端沉默。消息迟到和压根没发，在传输层长得一模一样，TCP 管得了丢包，管不了对方不吭声。所以催办得做在应用层，等回复的智能体自带提醒策略，隔一阵发一次催促，催到上限还没动静就按超时升级处理。这本质上是把重传做进了业务逻辑，传输层的可靠性机制替不了它。

进程这一级的重启管理，另有一套现成的成熟模式，源头在 Actor 模型，Erlang 与 Akka 系统里名声在外。它的主张是把“让它崩溃”立成设计原则，不追求写出永不出错的智能体，而是把智能体排成层级监督树，一对一重启、能力按子树授予这些规矩都画在图里。这样换来的正是损失隔离，一个分支失守，别的分支照跑，敏感能力也不受连累。

重启还要带上频率上限。某个子智能体一秒内崩掉五次，就不要再起了，那是崩溃循环，只白白耗资源。监督树是有搭建成本的，跑不稳定工具的生产系统上它划算；一次性的小工具犯不上，那点执行时间抵不了搭建的工夫。

结构哈希还牵连到发布节奏上的一处讲究。灰度阶段新旧版本同在，新版本改了流程结构，旧检查点放到新结构上就是无效数据，硬要恢复，结果就不可信。稳妥的路子有两条可选，要么让在途任务留在旧版本镜像里跑完再下线，要么作废检查点、带上原始输入重新排队；取哪条，看任务的重放代价与时效要求。结构哈希的比对机制把这道选择题明明白白摆出来，总比悄悄算错要强。

落到代码上，为客服回路配一个文件检查点。这里只是示意实现，模型调用与工具沿用第 2 章的定义，存取逻辑本身却真实可用。

import json
import time
from pathlib import Path
from typing import Optional

CHECKPOINT = Path("checkpoints") / "express-cs.json"
SCHEMA = "express-cs/1"   # 回路结构版本，涵盖消息约定与工具清单

def save_checkpoint(messages: list, usage: dict, pending: str) -> None:
    CHECKPOINT.parent.mkdir(exist_ok=True)
    CHECKPOINT.write_text(json.dumps({
        "schema": SCHEMA,
        "messages": messages,
        "usage": usage,
        "pending": pending,
        "saved_at": time.time(),
    }, ensure_ascii=False), encoding="utf-8")

def load_checkpoint() -> Optional[dict]:
    if not CHECKPOINT.exists():
        return None
    data = json.loads(CHECKPOINT.read_text(encoding="utf-8"))
    if data["schema"] != SCHEMA:
        raise ValueError("回路结构已变更，拒绝恢复该检查点")
    return data

回路在每一轮收尾时调用一次 save_checkpoint，把此刻的消息历史、累计用量、待办动作都落盘。进程重启之后，load_checkpoint 把 messages 取回来，任务便从断点那一轮继续往下一轮走；用户这边的体感，只是停顿稍长了一点，而不是任务就这么消失。

检查点还能倒着用，这是它当调试工具的一面。排障不必从断点硬续，挑一个更早的检查点分叉出去，换一版提示词、换一个参数重放一遍，看同样的前情在不同处置下走出什么结局。几个平行结局摆在一起，哪一步引入的错一眼可辨。存档格式选 JSON 不选 Markdown，理由也在防改写上，Markdown 是写给模型读的，模型顺手就能续写改写，在模型带文件工具的系统里尤其如此；JSON 解析要么通过要么失败，没有模糊地带，存档被悄悄改坏的机会小得多。

再往前一步是可复现仿真。把模型响应、工具调用和随机数这些不确定性的来源全部收进一层虚拟化接口，模拟环境与真实环境各实现同一套接口，编排逻辑就能在纯模拟里跑，模型响应换成固定输出，工具调用换成预设结果，随机数钉死种子，同一份输入永远走出同一条轨迹。这样编排逻辑就能像普通代码一样写单元测试，回归一趟几秒钟，不用烧真金白银调模型。第 12 章的评测跑的是真模型，这一层测的是逻辑，两层分工。

代码里的 schema 字段，可以看作结构哈希的极简版。回路的结构由消息约定与工具清单定死，哪一项变了就换一个版本号，旧的检查点直接不认。多副本部署时，把这两个函数换成数据库读写，语义一点不变。图省事的话，也能直接用框架自带的能力，第 8 章提过，OpenAI Agents SDK 把会话做成了原语，会自动在运行前后存取增量。

检查点里不能只放消息。模型名、提示版本和工具清单的指纹都得一并写进去，不然两周后翻出一个旧任务来恢复，续跑用的是新模型、新提示，行为早已不是原来那套。第 12 章 12.2 说过，要精确复现就得连模型快照一起冻结；检查点正是同一原则在运维侧的做法。至少当期的模型与配置版本要存进去，恢复时按原版本续跑，或者明确记下这次恢复跨了版本。

检查点自己的生命周期也得管起来。每走一步存一份，库很快就会变大；常规做法是每个任务只留最近几份，任务收尾后归档一份或干脆清掉。工具返回的大段原文，按 12.2 的落盘约定放进对象存储，检查点里只存一个引用，检查点库就不会跟着变大。

执行断了这一类由检查点管住，模型不可用则是另一类，检查点用不上，得交给替补模型。替补模型要办三件事。头一件是提前指定，部署那一刻，第二选择是谁就得定下来。真等出了事才临时抓一个没验过的模型顶上，它的行为会变成什么样，没人能预料。

第二件，触发条件要写清楚。延迟飙高、撞上限流码、输出校验连续失败和预算触线，这些都属于切过去的信号。14.3 末尾限额熔断切过去的那位，正是这里预先指定的替补。

第三件也最容易被省掉，替补正式启用前，要拿整条流水线验上一遍。单测一次调用远远不够，主力能吐出合法 JSON、替补吐不出，系统照样停下来，这等于 14.4 第 3 条“指令与模型不匹配”换了个方向又冒出来。顺手还要做标签归一化，不同模型对同一个意思可能用不同的标签词，拿映射表把口径拉齐，否则换模型那天，下游统计会悄悄错位。

这一层也有人叫它回退模型，说法相当直白，替补不在事前定好，凌晨三点被警报叫醒的值班工程师，就得亲自顶上。

防线备好，还得知道它真的管用。传统运维对这个问题的回答是混沌工程（chaos engineering），不等生产事故来教，主动往系统里注入有界故障，杀掉一个节点、给下游加延迟和让某个工具超时，看稳态指标晃不晃、恢复机制起没起作用。智能体系统同样适用这套做法，前提有两条。稳态和假设要先写成机器可读的定义，什么算正常、预期挡住什么，注入前后拿它比对；爆炸半径要圈好，故障只注入到允许出故障的地方。第 15 章的影子与金丝雀验证的是变更，混沌验证的是韧性，两者不互相替代。

操作者一侧也有纪律要守，跟检查点直接配套。任务一跑偏，人的第一反应是停下来纠正，解释问题、让它改错、再补点上下文，我头一个反应也是这个。这条路的代价往往比表面更大。纠正这个过程本身在消耗上下文，还可能跟原有的误解叠在一起；解释、打补丁、补丁带出新问题、再解释，这个循环烧掉的时间与 token，也许比从头试两次还多。实在非要纠正，也设一道上限，两次不收敛就放手。

还有一条更划算的路数，资料里叫老虎机式恢复。做法是先把当前状态提交掉，然后放手让智能体自己跑一段固定的时长，二十到三十分钟，到点做一个二元决定，结果够好就收下，不够好就退回那个提交，换一份更好的提示词另开新会话重来。不去抢救，也不进纠正的循环，一次失败尝试的浪费到此打住。

这个时限不是随手拍的。二十到三十分钟这一段，长到足以在有界任务里做出有意义的进展，又短到一次失败的尝试赔得起。真盯着它耗两小时，花掉的时间已经超过从头试两回。这套路数的前提是频繁提交，放手之前必须先留下一个干净状态，不然就没有可回退的点，这套办法根本不成立。

任务长到以天计，靠的就不是一场会话从头跑到底，而是一连串短命会话接力。新会话开场什么都不知道，交接全靠落盘的工件，要紧的是三样。头一样是完成标准，做成什么样算完，写成一条条能核对的条目；第二样是进度记录，做完了什么、还剩什么，新会话照着它接活；第三样是环境重启脚本，开场先跑一遍，把服务、依赖、数据这些工作环境恢复回来。

接力要立一条硬纪律，自称完成与验收通过得分开。干活的会话顶多自认做完，验收要换一个会话或者人，对着完成标准逐条核。Anthropic 公开的长时程编码实验里出过一种失败，后到的会话打开工作目录，看见前几棒攒下一堆成果，就把整个项目宣布完工，实际离做完还差得远。

还有一类毛病，监控看不见。会话逼近上下文上限时，模型常常提前体面收尾，把手上的活告一段落，安静地结束，不报错，也不触发告警。这种悄悄收场单靠盯指标发现不了，进度记录正是对策，每一棒真正完成到哪条，记录里写得明白，验收时一对，停在半路的状态藏不住。

恢复链路上挂着的不只检查点，钩子这类确定性扩展件也在这条链上，它们的排障另有一套小步骤。这类挂在固定时点的检查坏起来多半不出声，配置错了它就是不跑，不给报错。排查沿着链走四步，头一步验装载，配置里认不认得出它；再验触发，做一次该触发它的动作，看它动没动；接着验执行，它跑起来了但成没成；最后验生效，成了但结果用上没有。四步各有各的验证办法，毛病十有八九卡在其中一步，单独验证比整体重跑省时间。第 21 章 21.4 装配钩子时，这套步骤用得上。

把检查点和第 12 章的轨迹并到一处看，会发现二者同源，分工却不同。底子都是那份只追加的消息流水。轨迹是从它派生出来、只读不写的一份，供取证、评测与回流使用；检查点则是可以恢复的执行状态，为断点续跑服务。第 7 章那条存储与呈现分离的原则，在这里又用了一次，一份底子，两份派生物，彼此不干扰。

本章小结

• 14.1 看得见：OpenTelemetry 的 gen_ai 语义约定把模型调用、工具执行、智能体运行汇成一棵 span 树，埋点字段不攥在厂商手里；LangSmith 商业、Phoenix 开源，中间垫一层 Collector 集中做采样、脱敏和分发；内容字段 Opt-In 加脱敏，采样按三档（开发全量、生产错误全量加成功 10%–25%、事故期临时回 100%）；trace 数据可直接导出成评测数据集。
• 14.2 盯在事前：输出质量三层盯（规则过滤、统计漂移和模型评审一到五打分），推理侧判错分方向报、加回溯率，记忆与检索按组件配先行指标；用户行为是隐式信号，每周 30 分钟分诊五桶归类；告警盯模式不盯绝对阈值；SLO 定成功率目标、差值即错误预算，预算紧了编排层降级保核心、松了放心上新（Google SRE 方法）；自动适应回路配三道护栏（探索预算、趋势持续才适应和花费封顶）。
• 14.3 算得清：每次调用记 token，按会话、功能和租户三层聚合；部署前把条件分支摊成期望调用数估成本乘数；按正确完成的任务计成本配质量平价阈值；模型路由让贵模型只接难题（约 15% 成本换约 90% 表现，量级参考），前缀缓存靠提示组装纪律守命中率（静态前缀永远排最前）；成本异常三形态（尖峰、渐进和单位产出恶化），限额熔断三道闸（任务、会话和租户）。
• 14.4 对得上号：十种生产失败模式各配症状、定位、防线，先看症状再倒推原因，正是 3.3 讲过的溯因推理；第 9 条评测托住其余九条；先动系统层配置（第 1 到 5 条），动架构（第 6 到 8 条）前必须有评测数据，微调放最后（三种情况才值得）。
• 14.5 元认知与自我改进：长任务误差复合（单 token 99%，100 token 只剩约 37%），置信度闸门三档分流（低于 0.3 不呈现、0.3 到 0.6 补证据和连降三步重查）加停滞检测（词面重叠超 0.7）；四个长期指标（认知效率、元认知校准、适应速率和知识边界准确率）；改自己最重一档，生产轨迹回流模型层更稳，动权重排最后。
• 14.6 续得上：检查点每步落存、进共享存储、worker 无状态扩展，租约防双接管；消息路线五类故障分流（瞬时、持续瞬时、永久、毒消息和过期），死信隔离、消费端幂等；结构哈希定发布期恢复边界；替补模型三件事（提前指定、触发条件写清、整条流水线验一遍加标签归一化）；混沌工程验证韧性；天数级长任务靠短命会话接力，完成标准、进度记录、环境重启脚本三样落盘工件交接，自称完成与验收分开，进度记录防临近上下文上限的悄悄收尾。
• 一条总原则：span 从第一天埋起，成本从第一轮记起，检查点在第一个长任务之前备好，运维是可靠性工程在设计期写下的另一半。

参考资料

• Snell 等《Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Model Parameters》（测试时算力与模型参数的权衡，UC Berkeley 2024）https://arxiv.org/abs/2408.03314 ，核实于 2026-10-07

• Anthropic《Effective Harnesses for Long-Running Agents》（2025-11，长时程任务的会话接力与三样交接工件，后到会话见成果即宣布完工的失败、对照完成标准逐条验收），https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ；《Harness Design for Long-Running Application Development》（2026-03，干活者与验收者分离，模型临近上下文上限提前收尾的现象），https://www.anthropic.com/engineering/harness-design-long-running-apps ，核实于 2026-10-07

• Beyer、Jones、Petoff、Murphy《Site Reliability Engineering: How Google Runs Production Systems》（O'Reilly 2016，全书官方免费在线）第 3 章（SLO 与错误预算：目标定下后，1 减 SLO 就是允许不可靠的额度，预算有余可以继续发布，烧完则暂停发布转入加固），https://sre.google/sre-book/embracing-risk/ ，核实于 2026-10-07

• OpenTelemetry GenAI 语义约定仓库（gen_ai、mcp、openai 命名空间，inference / execute_tool / agent span，Development 状态），https://github.com/open-telemetry/semantic-conventions-genai ，核实于 2026-08。

• OpenTelemetry GenAI 属性注册表，https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/ ，核实于 2026-08。

• Arize Phoenix 官方文档（开源、OTLP 接入、phoenix serve、6006 端口），https://arize.com/docs/phoenix ，核实于 2026-08。

• LangSmith 官方文档（OTel 追踪接入），https://docs.langchain.com/langsmith/trace-with-opentelemetry ，核实于 2026-08。

• OpenInference 仓库（基于 OTel 的插桩标准），https://github.com/Arize-ai/openinference ，核实于 2026-08。

• OpenTelemetry Collector 官方文档（接收、处理、导出遥测数据的厂商无关组件：应用快速卸载、重试与批处理、敏感数据过滤、送一家或多家后端），https://opentelemetry.io/docs/collector/ ，核实于 2026-09-17。

• Kimi 定价页（K3 输入未命中 20 元、缓存命中 2 元、输出 100 元，每百万 token），https://platform.kimi.com/docs/pricing/chat-k3 ，核实于 2026-08。

• Kimi Context Caching 指南（全自动、无需缓存 ID、无需管理 TTL，固定初始上下文放在 messages 最前面可提高命中率；命中要求上一请求 prompt 超 256 token，不足则不缓存直接丢弃），https://platform.kimi.com/docs/guide/use-context-caching-feature-of-kimi-api ，核实于 2026-08-28。

• DeepSeek 上下文缓存文档（默认开启、prompt_cache_hit_tokens 与 prompt_cache_miss_tokens），https://api-docs.deepseek.com/guides/kv_cache ，核实于 2026-08。

• DeepSeek 官方定价页，https://api-docs.deepseek.com/quick_start/pricing ，核实于 2026-08。

• 阿里云百炼模型定价页（qwen-flash 折算价，以官方页为准），https://help.aliyun.com/zh/model-studio/model-pricing ，核实于 2026-08。

• Heiko Hotz、Sokratis Kartakis《Multimodal, Real-Time AI Agent Systems》（O'Reilly）第 5 章（Ops 谱系、AgentOps 四类新挑战、精度速度成本三角）。见 txt-ref-zh/multimodal-realtime-agents/。

• Victor Dibia《Designing Multi-Agent Systems》（2025）第 11 章（两级优化框架、十种生产失败模式、路由 15% 成本换 90% 表现、小模型便宜 20 到 30 倍、推理模型在多智能体系统中可能降性能的越权告警、微调判据两种场景与 Agent Lightning 转引，Luo et al. 2025，arXiv 2508.03680）、第 6 章（WorkflowCheckpoint、结构哈希、检查点存储分层、无状态扩展）。见 txt-ref-zh/designing-multi-agent-systems/。

• 《AI Agent 开发实战》第 6 章（LangSmith 四大功能与环境变量接入、Phoenix 的 OTel 集成与 Docker 部署）。见 txt-ref/ai-agent开发实战/。

• Nicole Koenigstein《AI Agents: The Definitive Guide》（O'Reilly，2026）第 7 章（部署物理学：冷启动、缩容到零、KV 缓存、前缀缓存与显存压力；替补模型三件事与标签归一化；trace 采样三档：开发测试期 100%、生产错误 100% 加成功 10%–25%、事故期临时回 100%）、第 10 章（检查点时间旅行：从更早检查点分叉重放执行）、第 11 章（成本乘数：每请求期望调用数算法、决策级记忆化与前缀缓存的分野；重试的概率成本账算例：失败概率与重试次数的指数压缩、预算线性放大，源书示意数字未入正文）。译文见 txt-ref-zh/ai-agents-definitive-guide/。

• 《Building Reliable AI Systems》（Manning MEAP，2026）第 8 章（接缝测试：缺陷与故障发生在智能体交接信息、状态更新处，端到端测试要冲着接缝打）、第 9 章（语义缓存：重复问题直接回放旧答案、与批处理并列的高效模式）、第 10 章（告警三原则：每秒 token 数跌破 20、错误按用户或主题聚集、每 token 成本比基线涨 50%；输出质量三层监控：规则过滤、统计漂移、模型评审；隐式反馈信号与每周 30 分钟分诊五桶加权；仪表盘三问：正在发生什么、去哪里排查、业务影响是什么；显式反馈收集与隐式信号对读；成本异常三分法：基线取上周同一小时、尖峰 2 倍、渐进每天 50%、总量稳而每 token 恶化；三类成本事故形态）。译文见 txt-ref-zh/building-reliable-ai-systems/。

• Julian Soh、John Tidwell、Priyanshi Singh《Building and Distributing Agentic AI Solutions: A Comprehensive Guide to Productizing AI》第 2 章（缓存复用比三档：静态系统提示加复用指令 0.8、模板化提示 0.5、高度动态提示 0.3）。译文见 txt-ref-zh/building-distributing-agentic-ai/。

• Micheal Lanham《AI Agents in Action》第二版（Manning，2026）第 10 章（五种元认知失败模式、置信度闸门示例阈值 0.3 与 0.6、置信度连降三次触发重查、停滞检测词面重叠 0.7；转引 DMC 与 MetaMedQA 两项研究；认知架构图景：心智社会、全局工作空间、双系统三理论与共享认知工作空间；元认知度量四指标：认知效率、元认知校准、适应速率、知识边界准确率）。译文见 txt-ref-zh/ai-agents-in-action-2e/。

• Eric Broda、Davis Broda《Agentic Mesh: The GenAI-Powered Autonomous Agent Ecosystem》第 5 章（链长复合衰减算例：单 token 99% 准确率，100 token 约剩 37%、1000 token 约 0.004%，说明用假设数字）、第 13 章（舰队观察者智能体：把全舰队日志与指标压成人可消化的摘要）。译文见 txt-ref-zh/agentic-mesh/。

• Ali Arsanjani、Juan Pablo Bustos《Agentic Architectural Patterns for Building Multi-Agent Systems》（Packt，2026）第 3 章（自部署省钱机制族：量化、并发批处理摊薄、自动扩缩容）、第 5 章（带能力护栏的监督树：让它崩溃哲学、一对一重启、能力按子树授予、1 秒内崩溃 5 次不再重启；路由层语义缓存件：查询做嵌入到向量库找相似请求、重复查询绕过模型）。译文见 txt-ref-zh/agentic-architectural-patterns/。

• 《Claude Code: The Definitive Guide to Agentic Development》（独立出版，2026）第 10 章（老虎机式恢复：提交后自主跑 20–30 分钟、二元决定接受或重启、两次纠正不收敛即停、前提是频繁提交）、第 12 章（产出量口径：约 27% 的 AI 辅助任务没有 AI 帮忙根本不会被立项，源书口径未入正文；技术债当智能体待办：实现成本降一个量级后清理任务集体过优先级门槛、低优先窗口自主啃、人审收尾）。译文见 txt-ref-zh/claude-code-definitive/。

• Wang 等《A Framework for Quantifying Metacognitive Ability in LLMs》（DMC 框架，AAAI 2025），https://ojs.aaai.org/index.php/AAAI/article/view/34723 ，核实于 2026-08-31。

• Griot 等《Large Language Models lack essential metacognition for reliable medical reasoning》（MetaMedQA 基准，Nature Communications 2025），https://www.nature.com/articles/s41467-024-55628-6 ，核实于 2026-08-31。

• Jia Huang《Designing AI Agents》（Manning MEAP）第 4 章（检查点与进度文件选 JSON 的理由：模型不当地改写或覆盖 JSON 文件的可能性比 Markdown 低）、第 5 章（推理侧可观测指标：路由误判率的方向性——把难题判成简单代价更高，回溯率过低是只证不验、过高是初始假设太差；假设-实验循环判别纪律：双预测先行、三次差一点是反证、证据比最接近五五的假设先打；阈值系作者经验值，未入正文），见 txt/designing-ai-agents.txt（英文原文，第 4、5 章，行 5415-5502、6444-6455）。

• 《The Claude Code Operating Model》第 10 章（真实成本 = API 花费加人力时间：便宜模型跑半小时对贵模型五分钟的算例；输出价约为输入数倍、缓存读便宜一个量级的计费结构，倍数未入正文），见 txt/claude-code-operating-model.txt（英文原文，第 10 章，行 10578-12924）。

• Dhivya Nagasubramanian《Agentic AI for Engineers》（Springer/Apress 2026）第 8 章（审批吞吐容量：人工审批是人的吞吐，按评审员扩容与分层放行）、第 11 章（隐式反馈自动适应回路：信号经平滑直接进提示或记忆，探索预算、趋势持续才适应、花费封顶三道护栏，系数系作者示意，未入正文；反馈机制选型四组权衡：质量对规模、延迟对深度、成本对覆盖、客观对细腻）、第 4 章（重复检测与强制决策收场：同结果连出三次即摊牌，端出当前最优或请用户放松约束），见 txt/agentic-ai-for-engineers.txt（英文原文，第 4、11 章，行 4817-4851、6328-6335、12826-12921）。

• Tim O'Brien《Building Complex Multi-Agent Systems Using Pattern Prompting》（Packt 2026）第 8-9 章（消息代理路线的失败处理：瞬时/持续瞬时/永久/毒消息/过期拒收五类故障，短间隔与长间隔两层重试队列、只读死信隔离区与人工重放、消息头失败史；手动确认保至少一次投递、幂等放消费端、prefetch 背压、publisher confirms；通道适配器对直连 HTTP 的对比：直连在处理代码里调 API 则超时占线程、重试随手写、错误无分类，适配器把外部服务包成队列边的消费者；以 RabbitMQ 实现，重试秒数与次数系作者自选参数，未入正文），见 txt/pattern-prompting-mas.txt（英文原文，第 8-9 章，行 5311-5327、5332-5412、6365-6413、6450-6458、7219-7313、7317-7352）。

• Antonio Gulli《Agentic Design Patterns》（Springer，预印本）第 9 章（自我改进编码智能体 SICA：历史版本档案按成功率、耗时与算力加权择优、直接修改自身代码、全程容器隔离、异步监督 LLM 可叫停；AlphaEvolve 与开源实现 OpenEvolve 的进化式优化循环），中文译文见 参考资料/agentic-design-patterns/（xindoo 翻译项目）。

• Google DeepMind《AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms》（数据中心调度平均收回 0.7% 全球算力、Gemini 内核提速 23%、FlashAttention 指令优化最高 32.5%、4x4 复数矩阵乘法 48 次标量乘法的官方口径出处；正文仅引 0.7% 一项），https://deepmind.google/discover/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ ，核实于 2026-09-15。

• 《Agentic GraphRAG》（Anthony Alcaraz，O'Reilly 2026 中译）第 4 章（记忆图健康监控六指标：节点增长率、边密度、簇均衡、查询尾延迟、冲突率、时间一致性）、第 8 章（单次成功完成成本与质量平价阈值、按层延迟预算、multi-LoRA 单卡多适配器并入自部署机制族），见 txt-ref-zh/agentic-graphrag/。

• Indrajit Kar《Building Multimodal Generative AI and Agentic Applications》第 18 章（RAGOps 分阶段监控：重排器分数方差、提示截断率、嵌入漂移，按管道阶段而非只按输出质量分层），见 txt-ref-zh/building-multimodal-agentic/。

• Rem Collier、Viviana Mascardi、Alessandro Ricci 编《Agents and Multi-Agent Systems Development》（Springer 2026）Jadex V 章（框架日志与应用日志分开收，开发者默认只看自己的输出）、JaKtA 章（可复现仿真：调度、感知、行动、随机数等不确定性来源全部收进虚拟化接口，模拟与真实各实现同一套接口）、协议工具章（对端沉默与应用层催办：消息迟到与未发送在传输层不可区分，智能体自带提醒策略），见 txt/agents-mas-platforms.txt（英文原文，行 3540、5257、6564-6568）。

• David Jambor《Agentic Reliability Engineering》（O'Reilly Early Release 2026）第 2 章（聚合掩盖的反面注记：均值化延迟藏尾部、聚合错误率盖住关键路径）、第 3 章（混沌工程：主动注入有界故障、稳态与假设写成机器可读定义），见 txt/agentic-reliability-engineering.txt（英文原文）。

• 《Claude Code Architect》第 22 章（钩子四步排障链：装载、触发、执行、生效各步一验，钩子坏起来多半不出声），见 txt/claude-code-architect.txt（英文原文）。

• 《Patterns for Building AI Agents》（Sam Bhagwat、Michelle Gienow，O'Reilly 2025）第 16 章（从生产数据造数据集：链路追踪挑典型样本、打标注、版本化管理回流评测），见 txt-ref-zh/patterns-for-building-ai-agents/。

• 《Agentic AI for Healthcare》（Sairohith Thummarakoti 编，Routledge 2026）第 9 章（能耗视角与边缘计算、蒸馏、碳感知调度对策，源书同规模医疗智能体能耗倍数口径未入正文）、第 10 章（思维链监控与监控性税，转述 OpenAI 研究），见 txt/agentic-ai-healthcare.txt（英文原文）。

• Baker 等《Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation》（OpenAI，2025-03；用 GPT-4o 监视推理模型的思维链抓越轨、对坏念头重罚会催生隐瞒式作弊、监控性税的出处），https://arxiv.org/abs/2503.11926 ，核实于 2026-09-16。

• 《The Agentic Enterprise》（Babak Hodjat、Antoine Blondeau，O'Reilly 2026 Early Release）前言（持续对齐闭环：系统进生产后收集使用数据、人工审计者标注可否接受、再按智能体分别微调其背后的 LLM），见 txt-ref-zh/agentic-enterprise/。