READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · Agent 循环的控制权与完成判据
先理解核心原理
先备概念：请求生命周期、异步取消、业务验收
模型输出是下一步建议，运行时才掌握执行和终态。停止只证明循环结束，成功还必须证明约定的业务条件成立；预算耗尽、取消和结果未知因此不能被同一个“完成”标签覆盖。
从 HTTP 请求看 Agent 循环
普通后端收到请求后执行确定程序，Agent 多了一步由模型提出下一动作。这个差异改变的是决策来源，没有改变服务端对权限、费用和副作用的责任。可以把循环看成反复执行“生成候选动作—网关检查—执行—更新事实”；最后的自然语言只是候选产物。
为什么轮次限制不够
一轮可以提出多次调用，单次调用内部还可能重试。只限制模型轮数，相当于限制事务数却不限制事务里的 SQL：负载仍可能失控。轮次、实际调用尝试、并发额度和绝对截止时间需要分别约束，费用按实际用量结算。OpenAI Runner 的最大轮次属于循环保护，应用仍需补业务预算。
完成状态是可检查的事实
“已经修好”无法证明测试通过；“用户取消”无法证明已提交的发布消失。把任务状态与每个操作状态分别记录，才能同时表达任务已停止、部分操作已成功、某个操作仍待核对。验证时让假模型提前宣布完成、持续调用工具，比只看一次真实模型成功更容易暴露控制漏洞。
回到问题：怎样回答？
Agent 的核心是模型提出下一步、运行时执行工具、把结果放回上下文，再继续决策。模型可以提出完成，但运行时必须独立控制工具权限、轮数、时间和费用，并用业务验收判断成功。达到预算是受限结束，工具失败是执行异常，都不能伪装成任务完成。我的做法是把终态做成明确枚举，记录停止原因和已验证的产物，让用户知道完成了什么、还差什么。
实现与取舍
循环的实际控制权
一次模型响应可能包含最终回答，也可能包含一个或多个工具调用。运行时负责分发调用、收集结果和决定是否继续。OpenAI Agents Runner 将工具结果追加后再次调用模型，并提供 max_turns 限制；这说明“让模型自己停”不是完整控制策略。一个模型轮次内的多次工具执行还需要独立计数，工具内部重试更不能藏在预算之外。模型输入应包含目标、允许动作和已有证据，授权身份、密钥与真实预算保存在服务端。
终态与预算怎样设计
我会区分 succeeded、failed、cancelled、waiting_approval 和 budget_exhausted。succeeded 需要满足验收，例如目标文件存在、内容格式合法、必要检查通过；模型说“完成了”只产生待验收候选。预算至少有模型轮数、工具调用数、总截止时间、费用上限。每次调用前预留可估计成本，调用后按实际用量结算；并发请求共享同一预算账本，避免各分支都以为仍有余额。超限后保存已完成产物及剩余任务，不能继续重试到无限循环。
取消与失败不能只改一个标志
取消首先阻止新动作，再向正在运行的可取消调用传播信号。对于已经发出的外部写操作，需要核验结果，不能因本地超时就宣称远端未执行。工具返回按可恢复错误、权限拒绝、永久业务错误分类；仅对确实可重试且幂等的操作重试。相同工具和规范化参数连续失败时，应升级为诊断或退出，而不是把同一错误喂给模型几十次。事件记录 run_id、turn、tool_call_id、耗时和停止原因，敏感内容脱敏。
如何验证控制边界
用固定响应序列模拟模型：持续要求同一工具、一次发多个调用、提前声称成功、执行期间取消。断言超限后不再调用工具，失败不会生成 succeeded，取消后没有新副作用，产物验收失败能够回到修复或明确失败。先验证这些确定性控制，再用真实模型评估任务完成率。面试中给出这样的反例，比背诵“规划—行动—反思”更能证明实现能力。
工程推演
- 场景
- 假设工程场景：研发 Agent 修复接口后不断重复运行同一失败测试，任务迟迟不结束。
- 设计决策
- 设置共享预算和重复动作检测，把失败日志转换为结构化诊断；成功必须通过指定接口验收。
- 验证目标
- 预期行为：重复失败触发受限结束，保留修改和错误证据；通过验收的运行才进入成功终态。
- 适用边界
- 这是设计示例，没有宣称真实团队提效指标；预算阈值需按具体任务分布校准。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层一个模型轮次产生五个工具调用，预算怎么记？
一轮并不等于一个动作，需要把抽象循环落到资源账本。
参考解答
模型轮次记 1，工具请求分别记 5 次候选；真正启动多少次就记多少次执行尝试，工具内部重试也单独计数。启动前原子预留共享额度，额度不足时按任务约定拒绝整批或执行允许的子集，不能让五个并发分支各自读取同一余额。未执行的调用也要返回明确拒绝原因，避免模型误认为已执行。
沿着这个回答继续深入
第 2 层只剩两次调用额度，五个候选里有一项关键验证，应该如何选？
共享计数解决超额，接下来要考虑额度不足时怎样保持验收意义。
参考解答
由运行时已配置的任务依赖和优先级决定，先保证关键验证的可用预算；允许模型建议排序，但它不能自行把验证降为可选。若关键步骤的完整成本已无法承担，保存当前产物并以预算不足结束，比执行两个无关步骤后宣称成功更诚实。
沿着这个回答继续深入
第 3 层关键验证预留了额度，但一个已启动工具迟迟不返回，预算能释放吗？
预留策略遇到结果未知，需要区分本地容量与外部事实。
参考解答
不能因本地等待超时就立即把潜在费用和副作用视为消失。分别结算可确认的资源、保留未知操作记录，并停止后续依赖。费用保留时间和对账方式由供应商行为决定；可取消的纯计算完成取消后释放容量，已经发出的写请求先查回执。
第 1 层用户取消时远端写操作已经成功，你如何收尾？
取消信号作用于执行过程，已发生的业务事实需要单独收尾。
参考解答
先禁止新动作，再核验已提交请求。远端已经成功就记录回执，告诉用户取消阻止了后续步骤，但该动作已生效；若业务支持撤销，按撤销权限发起独立操作，并记录它是否成功。不能删除原成功记录，也不能把补偿请求发出解释为已恢复原状。
第 1 层模型给出正确答案却没有执行要求的测试，算成功吗？
控制终态必须回到验收条件，而不是文本的可信程度。
参考解答
若任务契约要求运行测试，就不能判成功。答案或代码正确只是部分条件，缺少测试证据时标为待验证；还有预算则补跑测试，没有环境则明确交付范围和未验证项。只有用户明确调整验收契约后，才可能按新范围完成，不能由模型单方面删去要求。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
研究任务没有确定答案
改变的条件：验收由自动测试变为证据覆盖与人工判断
延伸问题：资料研究怎么判断完成？
推导与参考解答
先规定覆盖范围、必须查阅的来源类型、引用可回读及未解决问题的呈现方式。运行时能自动检查引用和必填项，争议结论交人工或专门评审。达到范围并如实报告未知可算完成，不能要求模型保证世上没有遗漏，也不能用搜索次数替代证据覆盖。
保持不变的原理：完成始终依赖预先定义的可观察条件，只是验证器从测试变为证据审查。
定时任务反复运行
改变的条件：一次任务变成每日多次运行
延伸问题：今天失败后，明天能自动沿用昨天的成功状态吗？
推导与参考解答
每次运行绑定输入快照与验收证据。昨天已发布的事实可复用，今天的数据刷新、权限和预算重新检查；相同业务动作沿用稳定操作键，新的日期产物使用新的业务标识。一次成功不能覆盖新输入下的失败，系统应分别展示每次运行结果。
保持不变的原理：任务生命周期和业务操作生命周期必须分开。
易错点
- 把 max_turns 当成总费用或总工具次数限制
- 把模型最终文本直接映射成业务成功
- 超时后无条件重试有副作用的工具
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能区分模型建议完成与业务验收，并给出有界停止条件。
- 中高级信号
- 把轮数、工具次数、费用、取消和错误分类落实到运行时。
- 资深信号
- 能解释共享预算预留与外部动作未知状态，并用反例验证。
巩固练习 按需完成 · 建议 15 分钟
画出一个工具循环的状态机，模拟模型连续三次要求相同失败动作。
展开验收要求与检查点
- 重复失败会有界终止
- 模型声称完成仍要通过验收
- 停止原因可追踪
重点检查
- 能解释模型调用轮次与工具执行次数的区别
- 把最终文本与业务验收区分
- 给出预算、取消、异常的终态和记录方式