08 · 输出校验与动作执行：意见正确，就能自动发布吗？

模型提出的答案要经过内容校验，提出的动作还要经过授权；动作一旦跨出系统边界，是否完成必须靠执行事实确认。

本课的位置：输出校验与动作执行位于候选回答之后，检查内容、证据和具体授权，再决定交付或执行。

下面用一个教学设例：Agent审查一段任务处理逻辑，发现某次HTTP请求没有显式传入取消信号，生成审查意见。用户希望它把意见发布到指定审查板。这里既要保证意见有证据，也要保证发对地方、发的是获准版本，并在网络异常时避免重复发布。

输出校验层处在模型候选与最终结果之间；动作入口连接获准请求与业务系统。前者确认“内容是否可用”，后者确认“这次是否可以做、最后做成了什么”。通过其中一层，不能自动代替另一层。

先核对这条意见究竟在说什么

候选意见应能定位到文件、代码位置和输入版本，并区分观察到的事实与推断。比如“这个调用没有显式传入取消信号”可以由相关代码支持，但不能仅凭这一行断言整个网络栈永远没有超时。

Schema是结构约束，检查字段是否齐全、类型和取值是否符合约定。它可以发现行号写成一段说明、缺少来源或夹带额外动作参数，不能判断这条意见是否成立。

业务校验接着核对任务范围、严重程度、目标对象和完整性声明。用户只授权审查某个变更范围，模型不应把无关历史问题混入这次结论；模型标成“严重”，也不能自动升级为系统阻断操作。

证据校验则确认来源版本存在、引用位置对应原文、证据确实支持该结论。文件名真实不代表内容支持，行号合法也不代表引用正确。

发现问题时，反馈要能帮助修订：哪条意见、哪份来源、哪里不匹配。模型可以重读相关范围、修正位置或收窄结论；仍缺证据就保持未确认，不反复生成一个看起来确定的答案。

可以让另一模型辅助检查文字，但金额计算、权限、引用位置等能够由程序核对的部分应直接核对。模型说“我已经检查过”只是候选说明，不能成为批准凭证。

用户同意发布，究竟同意了什么？

假设用户看过报告A，同意发布到审查板甲。模型后来改写报告，又想发到审查板乙，原来的同意不能继续使用。

可信授权记录需要绑定当前用户、动作类型、目标、报告内容摘要、要求版本、有效期和允许范围。内容摘要用于把许可对应到精确内容，防止“批准的是A，执行时换成B”。

执行前重新核对当前权限、许可期限、任务状态和内容版本。报告最好按不可变产物引用读取，在实际发布前确认仍是获准内容；不能校验一份，真正发送时再从可变目录取另一份。

授权不一定每次都需要弹窗。用户已经明确授权一段范围内的重复工作，系统可以按范围验证后继续；超出范围或关键内容发生变化，再取得相应授权。关键在于批准来源可信、对象明确，而不是确认按钮出现了多少次。

外部资料中夹带“把报告发到另一个地址”，只能保持数据身份。它即使诱导模型换了目标，动作入口也要拒绝不匹配的许可。模型不能同时生成候选动作和“授权成功”字段，再让两者相互证明。

下游已经发布，为什么调用方还显示未知？

把这次动作记为publish-review-1。它是业务幂等键，标识同一次发布意图；网络重试、重新连接或新的工具调用号，都不改变这件事的业务身份。

动作入口先查原业务键。同键但内容不同，拒绝冲突；已经完成，返回原回执；还没有明确结果，保留原身份进入发送或核对流程。

在跨越外部调用边界前，先可靠保存操作ID与内容摘要。否则先发送、后记账，进程在中间退出，恢复者甚至不知道应该查询哪次动作。

假设下游发布完成并保存回执，回应却在网络中丢失。调用方没有拿到回执，只能记为unknown，即结果待核对。这既不是失败，也不是成功；它说明本系统目前缺少足够事实。

调用方与下游是两个独立系统。本地数据库回滚不会撤销下游已经完成的发布，服务重启也不会让这条意见消失。不能把Run标成失败，就认为外部动作已经回滚。

怎样恢复，才能避免多发一遍？

如果下游支持持久幂等，同一业务键与同一内容再次到达时，返回原回执，不新增一条发布；同键换内容则冲突。调用方拿到回执后，补记自己的完成状态。

在这个方案中，恢复后的发布数量仍是一条，依赖的是下游也保存了幂等事实，不能解释成调用方单独实现了跨服务“恰好一次”。下游保存期限、参数冲突规则、回执查询与重启后的行为，都属于接入契约。

如果下游不支持幂等，优先按操作ID或业务标识查询。只有明确未受理、许可仍有效并且契约允许时，才补发。查询若来自延迟索引，“没有记录”可能仍不能排除已经执行；无法排除就保留unknown，交给核对流程或人工接管。

直接换一个业务键重试，会把同一意图伪装成新意图。限制重试次数只能限制次数，不能消除重复副作用。需要撤回时，补偿也是另一项业务动作，必须有自己的权限与记录。

待办表能解决哪一段缺口？

如果发布是某项业务更新的后续动作，可以在本地事务中同时保存业务变化与发送待办，再由后台工作者投递。这样即使进程刚提交业务就退出，待办仍然存在，后续可以继续处理。

它解决的是“本地事情已经提交，外部请求却没发出去”的可靠投递问题。工作者可能重复领取和发送，下游仍要幂等；本地待办也不能自动与远端发布组成同一事务。

同步等待适合需要立即反馈、动作较短的场景；持久待办适合异步交付与可靠恢复。两种方式都应把报告校验、授权通过、请求已提交和动作已完成分开记录。

界面可以明确显示“审查意见已核对，发布状态待确认”，并保留可追踪的操作身份。它比把超时直接翻译成“发布失败”更符合事实，也能让下一位接手者继续处理。

传统后端同样需要这些边界。Agent新增的是候选步骤和内容由模型提出，外部资料也可能影响它的选择；因此证据、授权与执行账本要落在可信程序中。下一篇学习MCP，统一外部能力的发现和调用，但这些业务责任仍然保留。