切换深色模式
从模型到系统：Agent 的责任边界
对应 CS329Z · 2026-09-23 · Foundations & Landscape。日期为校方课表日期，可能调整。核对官方课表。
资料状态
核对日期：2026-09-19。对应课程尚未开课；本文是基于公开课纲与文中原始资料的原创预习技术解读，不是课堂实录、讲义翻译或官方作业答案。本文于 2026-09-20 深度修订。示例为原创教学设计；离线实验与真实模型实验的边界分别说明，不以推演冒充模型实测。
一份比较报告很容易生成，难的是解释它为什么值得相信。本系列从一个具体任务开始：团队在比较延时任务方案 A、B，要求服务重启后已接收任务不静默丢失，同时避免业务被重复执行。资料中既有旧版本说明，也有只对特定配置成立的承诺。助手需要交付带条件的建议；本阶段没有发送报告或修改生产配置的权限。
本讲要解决的核心问题是：哪些责任可以交给模型，哪些必须由系统承担？只有划清这条边界，后面的工具、记忆和评测才不是零散功能。
从一段错误答案反推系统需求
假设助手读到“方案 A 支持数据库恢复”，便回答“A 保证重启不丢且不重复”。这里至少跨越了三道未经证明的推断：支持某项功能等于当前已经启用；调度状态可恢复等于业务副作用可恢复；不丢任务等于不重复执行。
把问题还原为事件顺序，就能看到差别：
text
接收任务 → 保存调度状态 → 执行业务 → 记录完成
↑ 在这里崩溃业务已经发生，完成标记却未保存。恢复后重试可以避免丢失，也可能重复扣款或重复发消息。因此“持久化”与“业务幂等”是两项证据需求。模型只看到一个关键词就完成判断，根因是系统没有定义必须证明什么。
我们先建立三个待回答问题：接收成功的承诺点在哪里；重启后怎样识别未完成任务；重复执行怎样被业务端吸收。它们构成后续检索的目标，而不是让模型随意搜索“哪个好”。
最小系统应围绕产物组织
BAIR 的复合 AI 系统文章提供了模型与其他组件协同设计的视角。本文的原创实现边界是：模型负责提出查询和候选结论，程序维护任务状态，外部证据支撑结论，验收器决定能否交付。
| 产物 | 必要字段 | 解决的故障 |
|---|---|---|
| 任务契约 | 目标、版本、约束、允许动作 | 目标在多轮中漂移 |
| 证据记录 | 来源、版本、条件、原文位置 | 有链接却无法核对 |
| 主张记录 | 结论、支持证据、缺口 | 从相关文本跳到无依据结论 |
| 执行记录 | 动作、观察、任务版本 | 不知道错误发生在哪一步 |
模块可以合并成一个进程，数据也可以先保存在内存。关键是责任可以分别检查，不必一开始就部署四个服务。
把“完成”定义成状态，而非模型语气
设任务状态为 S=(目标, 约束, 证据, 缺口, 预算)。一次动作只允许根据工具返回的观察更新状态：模型说“我查到了”不是证据写入条件，工具确实返回可定位资料才是。
教学运行逻辑可以写成：
text
循环：
若交付条件已满足：输出带条件结论，结束
若预算耗尽：输出已知事实与缺口，结束
让模型根据当前缺口提出下一动作
校验动作范围，执行，保存观察
更新证据与缺口；不能仅凭模型自述标记完成“已知事实与缺口”也是合法交付，但必须标为部分完成。否则系统会为了总能输出成功报告而掩盖资料不足。
这里有两类不变量：没有来源的外部事实不能进入确定结论；任何执行动作不能超出任务权限。它们比“回答要准确”更适合变成检查代码。
从责任划分导出一个交付门
可以把每个必要问题表示成一个槽位，值为已支持、冲突或未知。第一版交付门不需要理解整篇文章，只需先阻止明显不完整的强结论：
text
若输出“满足全部要求”：
每个硬约束必须绑定至少一条有效主张
主张必须绑定当前版本的证据
存在未处理冲突或未知 → 拒绝强结论，转为部分交付这里的“绑定”只是结构门槛，不能证明支持关系真实，因此后面还需要语义核验。但它已经能阻止一种常见失败：模型回答了两个容易的问题，却完全跳过业务去重。
还要区分必要与充分条件。来源齐全是合理交付的必要条件之一，不是充分条件；所有字段都填满，也可能每个字段都写错。分层设计的作用，是让每层排除一类错误，而不是任何一层单独宣布全系统正确。
如果模型拒绝填写某个槽位，系统应保存原因。是资料缺失、权限不足还是问题本身不清楚，将决定下一步是检索、部分交付还是澄清。这是从数据结构推导控制流，而非事后用提示词修补。
为什么不立即采用完全自主的 Agent
先做固定基线：分别读取 A、B 当前版本的部署和恢复说明，再逐项比较。对于来源固定的内部知识库，这可能已经足够。
只有遇到“文档提到另一项配置，需要继续追查”时，动态选择动作才有明确价值。外层保持预算、权限和停止检查，内层开放查询选择。自主性是解决信息依赖的手段，不是系统成熟度的等级标签。
如果固定基线经常漏条件，先检查文档解析和主张核验，而不是假定增加规划能力就能修好。否则只是给错误的数据基础增加更多调用。
沿着一次失败做定位
准备三份原创资料：A 的默认内存模式、A 的数据库恢复模式、B 的持久化说明。故意删除 A 数据库模式中的业务去重段落。
预期结果不是简单推荐 B，而是：A 的调度恢复有条件依据，A 的业务去重仍未知；B 同样需要核实业务端语义。若助手声称 A 完全不可靠，说明它把缺证据当成反证；若声称 A 全面可靠，则把部分证据扩大了范围。
定位时按产物检查：任务契约是否保留“不重复”；检索是否找到对应段落；主张是否保留配置条件；验收器是否放过了缺口。这样一次失败可以指向具体改动，而不是笼统换模型。
本讲交付的是一套责任划分。下一讲需要解决：模型提出的“候选动作”怎样变成程序能够校验的接口？继续阅读模型接口。