切换深色模式
Agent 框架：抽象应该接管什么
对应 CS329Z · 2026-10-07 · Frameworks & Orchestration。日期为校方课表日期，可能调整。核对官方课表。
资料状态
核对日期：2026-09-19。对应课程尚未开课；本文是基于公开课纲与文中原始资料的原创预习技术解读，不是课堂实录、讲义翻译或官方作业答案。本文于 2026-09-20 深度修订。示例为原创教学设计；离线实验与真实模型实验的边界分别说明，不以推演冒充模型实测。
研究助手现在能检索证据、产生候选结论，并以明确语义调用工具。原型可能只有一个循环，但加入“暂停等待确认、重启恢复、人工修改计划”后，运行状态迅速复杂起来。框架的价值，应该从这些具体责任出发判断。
本讲用一次迁移实验回答：采用框架后，代码减少了什么，又有哪些正确性责任仍属于我们？
手写循环真正缺少的是什么
假设当前状态为“证据已经读取，候选报告已生成，等待用户确认创建核查工单”。进程重启后，如果只重放聊天历史，模型可能再次搜索、再次生成略有不同的报告，甚至再次提交工单。
需要持久化的不是“对话文本”本身，而是已经确认的状态：任务版本、证据快照、候选产物摘要、待确认动作，以及最后确认的外部操作 ID。状态机可以显式表达这些阶段：
text
researching → reviewing → awaiting_confirmation → executing → delivered
↘ needs_more_evidence → researching迁移到框架前先写出每条转移的前提。否则把错误循环翻译成图结构，得到的只是更漂亮的错误流程。
框架能力应拆成四个问题
编排决定节点与分支如何运行；持久化决定哪些状态能恢复；可观测性决定如何检查执行；优化决定如何改进模型模块。它们互相配合，却不能互相替代。
DSPy 论文研究声明式模型模块及其优化。这里借它说明一个常见误解：能搜索更好的提示或示例，不意味着自动获得外部操作幂等；具备检查点，也不意味着知道某条结论是否得到证据支持。
选型时分别核实这四项，而不是只问“支持 Agent 吗”。对于研究助手，最先需要的是状态可解释和可恢复；自动优化可以晚一些加入。
检查点位于哪里，决定恢复会发生什么
考虑一个节点执行顺序：读取状态、调用远端工具、保存新状态。如果工具成功后保存失败，框架重跑节点时会再调一次工具。这通常是可预见的恢复行为，不是框架承诺“恰好一次”失效，因为它可能从未作出这种承诺。
应把上一讲的操作 ID 放入持久化状态，并在第一次调用前确定。恢复时使用同一个 ID 查询或重试。检查点保证“记得打算做什么”，工具服务的幂等保证“重复请求不重复产生业务效果”。
如果框架把整个节点作为重试单位，一个节点里同时发送邮件和创建工单就很难处理部分成功。把不同副作用拆成有独立操作记录的步骤，能使恢复依据更明确；代价是状态更多，需要管理跨步骤失败。
恢复节点不应重新解释已确认决策
模型调用具有不确定性。若第一次生成报告 R1 并获得确认，恢复时重新调用模型生成 R2，即使主题相同，也不能沿用 R1 的确认。这里的问题不是模型“漂移”，而是持久化边界没有保存被确认的具体产物。
对模型生成节点，可以保存输出产物以及版本；恢复时在输入依赖未变的条件下复用。如果依赖变化，需要明确使产物与确认失效。对外部读取节点，同样要决定复用旧快照还是读取最新状态，不能由框架默认重试语义替业务决定。
一个迁移检查表因此包含两种一致性：业务状态是否一致，决策所依据的数据是否一致。前者防止重复操作，后者防止“相同节点名”背后已经换了证据。
框架能帮助保存状态，却无法替我们回答哪个状态值得信任。把确认产物当成不可变对象，是在这条边界上作出的业务设计。
迁移时先守住接口，再改变实现
保留三个独立接口：模型返回统一决策；工具执行器返回统一观察；验收器判断统一交付契约。框架只负责驱动这些接口和保存状态。
text
旧实现：while 循环 → 决策接口 → 工具接口 → 验收接口
新实现：运行图 → 同样接口 → 同样接口 → 同样接口同一套任务可以在两种实现下运行。比较的不是内部节点数量或回答逐字一致，而是最终主张、证据关系、禁止动作和外部状态是否满足同一契约。
如果迁移时同时更换模型、提示和检索器，即使变好也难以归因。因此先用模拟模型和固定工具返回验证运行语义，再接回真实模型。
一次会暴露问题的迁移测试
在三个位置中断：工具调用前、工具成功后检查点前、等待人工确认时。前两种需要确认不重复业务；第三种需要确认恢复后仍等待相同内容的确认。
再修改待提交报告，检查旧确认是否失效。确认必须绑定产物版本，否则框架恢复得越准确，越可能准确地沿用已经失效的授权。
对只读步骤重复执行可以接受，但需要统计额外成本；对副作用则要求结果一致。不要将所有节点都设成“自动重试”，把不同风险压成一个配置。
什么时候保持简单更合理
单次只读任务、固定流程和明确退出条件，可以先用普通程序。需要跨进程恢复、人工介入或复杂并发时，框架的收益才容易体现。判断标准是减少了哪些可验证的维护责任，而不是少写多少行。
下一讲在已有运行骨架内讨论动作策略：何时固定步骤，何时规划，反思怎样改变事实依据。继续阅读规划与反思。