为部分完成而设计：当你的智能体完成 70% 后停止

每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。

对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。

介于开始与完成之间的四种失败模式​

在为部分完成进行设计之前，有必要准确分类任务中途中断的根源。共有四种不同成因，每种都需要不同的设计应对。

持续时间溢出是最可量化的。当前前沿模型在四分钟以内完成任务的可靠性接近完美；而对于超过四小时的任务，成功率会跌破 10%。这并非偶然——这是一条可预测的退化曲线。智能体在长序列过程中会因上下文漂移、累积的不确定性以及工具调用错误的叠加而逐渐失去连贯性。任何可能耗时数小时的工作流，都需要从一开始就设计为可中断的。

执行中途发现的授权缺口更为隐蔽。智能体以合理的权限范围开始任务，随后遭遇一个需要它并不具备的凭证的步骤——对某个系统的写操作而它只有读权限、超过审批阈值的金融交易、隐藏在额外认证层后的 API 端点。任务初始化时的静态权限授予无法预见完整的执行树。智能体就此卡住，往往悄无声息。

上下文耗尽会导致智能体在触碰硬性限制之前就已退化。每个前沿模型在输入长度增长时都会退化——通常早在声明上下文窗口的 30–50% 时便开始。智能体不会在接近限制时崩溃；它们开始做出更差的决策，遗忘早期上下文，最终产生前后矛盾的输出。65% 的企业 AI 生产故障被归因于上下文漂移，而非触达硬性限制。

不确定性与置信度崩溃发生在智能体到达一个决策点时——正确行动真的不明朗，而猜错的代价又很高。若缺乏对这类情况的显式处理，智能体要么猜测（产生难以追溯的错误），要么以晦涩的报错信息停止，让运维人员无从下手。

检查点优先设计原则​

优雅应对上述任何情况的前提，是状态外部化。将所有任务状态保存在上下文窗口中的智能体没有任何恢复空间。一旦失败，它对自己已做之事的所有认知都会消失。

检查点架构将任务的每个步骤视为离散的、可持久化的事件。执行某个步骤前，写入意图；完成后，写入结果。持久化的状态构成恢复、回滚和审计的基础——与智能体的下一次运行是否还记得任何内容无关。

实现方式的选择至关重要。对于小型检查点（350 KB 以下），将序列化状态直接写入 DynamoDB 并附上线程 ID 和时间戳就足够了。对于包含工具输出、文档或中间产物的大型检查点，模式会转变：将有效载荷写入 S3，在 DynamoDB 中存储引用指针。检查点器只是一个指针存储，实际状态存在于对象存储中。

关键的区分在于工作流状态与会话状态。工作流状态是持久的——任务完成了什么、产生了哪些产物、在执行序列中处于哪个位置。会话状态是短暂的——当前对话上下文、进行中的工具调用、智能体的工作内存。许多团队混淆了这两者，最终在每次服务器重启后都要重建工作流进度，因为他们把所有东西都存在了会话里。

工作流状态应能在进程重启、智能体模型升级以及智能体之间的交接中存活。会话状态按定义不需要。在任务设计中内置检查点，意味着在写第一行智能体代码之前就决定好什么属于哪个类别。

人机协作恢复的三种模式​

一旦拥有持久化的任务状态，问题就变成了人类如何与部分完成的工作交互。生产系统中呈现出三种模式，选择哪种取决于任务对延迟的容忍度、错误成本以及实际需要干预的频率。

同步审批门在预定义的节点暂停执行，并在继续之前要求人工确认。智能体执行到该节点，序列化其状态，并向用户呈现包含完整上下文的审查界面：已做了什么、下一步打算做什么、用户拒绝时会发生什么。当下一步不可逆或代价高昂时——提交采购订单、发送对外通信、执行数据库写操作——这是正确的模式。代价是延迟；人工审批周期会为任务执行时间增加数分钟乃至数小时。对于错误步骤的下游代价超过等待代价的工作流，这是正确的权衡。

异步审计队列让智能体完全自主运行，同时将每个决策及其足够的上下文记录到日志，以供事后审查。智能体不会阻塞等待人工输入，但一个决策队列会不断积累，供运维人员审查、标记或用于系统调优。当任务延迟受到严格约束且单个错误可以恢复时，这种模式是合适的——例如处理工单的客服智能体、生成草稿的内容生成流水线。风险在于，当一个糟糕的决策浮现在队列中时，影响可能已经扩散。

多层监督对不同类别的操作分配不同的监督级别。低风险、边界明确的步骤自主运行；超过成本阈值、触及敏感系统或置信度跌破基线的步骤同步上报。智能体本身根据初始化时收到的策略做出上报决策。这是大多数生产部署最终收敛到的模式——它将人类的注意力分配到最需要的决策上。

三种模式的底层要求是相同的：智能体必须能够清晰地表达其状态，以便人类能够做出有意义的决策。一个呈现"任务在第 7 步失败"的中断不是审批门——那是报错。真正的中断应呈现：已完成什么、存在哪些中间产物、下一步的提议是什么、以及如果人类做出不同选择时各分支的结果。