Agent 的可信与不可信：从局部事实到系统承诺
Agent 工程需要管理的，是系统在什么依据之上，向用户承诺了什么。 一个局部已经证明的事实，能够支持多大范围的结论；一次有效的授权，允许哪些实际动作；一份成功回执，究竟说明哪件事已经发生。这些问题决定了模型的能力怎样变成可以采用的成果。
一套系统完全可能在多个环节都产生真实的成功信号，最终却给出不可靠的答案：代码确实通过测试，工具确实读取了资料，计算确实按公式完成，报告也确实保存了。失误发生在交接处——下一个环节需要相信的事情，已经超出了上一个环节实际证明的范围。
例如，“从官网读到了两份基金披露”逐渐变成“两份资料可以直接比较”，“计算得到了一个差值”又变成“一只基金更适合用户”。中间没有出现明显的接口错误，承诺却在不断扩大。
把这种现象称为未经充分依据的信任升格，有助于把分散在提示注入、研究证据、工具授权、AI Coding 和交付验收中的问题放到一起理解。这个说法描述的是一类组合错误，不是一条可信度排行榜，也不能解释所有故障：服务宕机、实现缺陷和错误的业务规则仍需要各自处理。
本文沿一个基金比较功能的开发与使用展开。贯穿情境是教学示例；穿插的工程反例分别来自已发表的实际观察或受控验证，不把不同时间的事件拼成一次事故。我们最终要回答的是：面对一个仍会犯错的模型，怎样决定哪些结果可以采用，哪些动作可以放行，以及哪些检查根本不必再加？
一、从一个任务开始：局部正确为什么组合不出整体可信？
假设团队正在开发一个基金比较功能，用户提出这样的要求：
比较甲、乙两只基金，解释已披露持仓的重叠和费用差异，把报告存好，让我之后能够继续查看。
Coding Agent 实现了资料读取、持仓比较和报告保存。测试使用同一统计日期的完整样例，断言数字和文件都符合预期。研究 Agent 随后处理真实输入，找到两份官方材料，计算共同持仓并生成报告。
到了这里，下面这些事情仍然可能没有成立：甲、乙的披露日期是否一致；提取的表格覆盖的是全部持仓还是部分持仓；费用是否对应用户指定的份额；用户后来读到的是否就是刚才审查过的那一版报告。
注意，测试样例没有错，官方网站也没有造假。问题在于测试覆盖的条件与本次任务的条件不同，而系统把前者的成功无条件沿用了过来。
| 环节已经确认的事实 | 下一环节准备采用的判断 | 仍需成立的条件 |
|---|---|---|
| 两份材料来自可核对的公开来源 | 它们能够回答当前比较问题 | 对象、日期、覆盖范围与问题相符 |
| 程序按输入计算了重叠 | 这个数值说明两只基金整体重复程度 | 输入覆盖和分母足以支持该范围 |
| Reviewer 同意报告结论 | 关键错误已有机会被发现 | Reviewer 实际看到了必要材料，并按适当标准核查 |
| 保存接口返回成功 | 用户以后可以取得这份成果 | 对应版本已持久保存，且用户能经正式入口读取 |
要让局部正确组成整体可信，需要同时满足组件行为与交接条件。一个组件只保证“按输入计算”，调用者就不能把它当成“输入已经正确”；一个保存服务只保证某个版本已提交，研究模块就不能借这份回执证明报告内容正确。
这与普通软件的接口契约有连续性。Agent 带来的额外难点是：很多交接通过自然语言完成，模型还可能根据刚刚读到的内容临时选择下一步。原本附着在材料上的条件，很容易在摘要、协作和继续研究时消失。
所以，评审一次交接时，最有效的起点是找出这个差距：当前依据支持的范围，和下游准备作出的承诺，是否一致？
二、先分清三种承诺，才谈得上相信谁
我们常把“可靠”“安全”“已完成”连在一起说，但它们需要的依据不同。沿着同一份报告，可以区分三种承诺。
研究判断回答“这句话在这些条件下是否成立”。它需要相关事实、适用的比较方法，以及与结论强度相称的核验。例如，同期已披露持仓的交集可以支持一项限定范围的描述，不能自动支持对全部资产的判断。
行动权限回答“谁可以在当前任务中，对哪个对象做什么”。它来自有效身份、用户委托和执行策略。报告写得正确，并不会因此获得发送给其他人的权限；一次发送已经获准，也不证明报告正确。
执行事实回答“某个动作是否真的产生了指定效果”。它需要执行服务的回执、资源状态或对应产物的实际读取。模型说自己保存了，与保存服务确认某个版本已经提交，拥有不同的证明能力。
这解释了为什么不适合用一个总分决定一切。来源得分再高，也不能补偿没有授权；执行记录再完整，也不能补偿错误的比较前提。把这些维度加权成一个“95 分可信”，反而可能遮住真正没有满足的条件。
我们需要相信的最小对象，因此是一项具体、有范围的声明。例如：
依据同一统计日期的两份指定版本材料，下面列出了双方已披露部分中的共同持仓；未披露部分没有纳入。
这句话说明了对象、范围和依据。它比“这个 Agent 可信”更容易核对，也更容易在条件变化后判断还能不能使用。
把声明、支持它的论证和证据分开，在可靠系统工程中已有成熟做法。OMG 的 结构化保证论证元模型 SACM就分别表达主张、论证与证据之间的关系。这里借用的是这种组织思路：让人看得见结论依赖什么；应用可以通过已有资料引用、版本信息和验收记录表达，不必先建设一个新的证明平台。
三、资料真实之后，还缺哪一步才能成为结论？
回到甲、乙基金。两份官方披露都真实，其中一份截至六月末，另一份截至九月末。模型发现了共同持仓，便在摘要里写：“两只基金目前重合度很高。”
这一步新增了两个原材料未必支持的前提：不同日期能够代表同一时刻；已披露部分能够代表整体。若暂时无法补齐资料，系统仍然可以描述这两份历史披露之间的交集，但应保留日期和覆盖限制，避免把它写成当前全部持仓的结论。
在《AI Coding 最贵的不是写代码，而是决定什么值得验证》记录的一次真实研究中，报告已经完成，人工复核却发现“某项跟踪约束比另一项严一倍”缺少同口径依据。后续重读一手材料并撤回该推断，原报告保留，更正另行保存。这个观察说明的不是计算工具失灵，而是材料措辞被转换成数量关系时，比较前提没有成立。
确定性计算在这里仍然非常重要。把单位、精度和公式交给可复算的程序，可以减少一类错误。但程序能够忠实地计算错误口径的数据，因此输入与公式为什么适用，仍然需要被解释和核查。
关键不是禁止推理得到新结论，而是让新增的结论有可说明的推导。 两个已经核对的数值，当然可以通过正确的减法得到差值，不必为了每个差值再找第二份资料。保留条件的摘要也可以复用原证据。真正需要补证的，是推导偷偷增加的前提，例如从样本扩展到总体、从历史扩展到当前、从风险描述扩展到个人适合性。
这对架构产生了一个直接影响：资料的出处不能只剩一个 URL。决定结论的日期、版本、覆盖范围和计算口径，需要能够沿引用关系被找回来。并非每个字段都必须进入模型的每一轮上下文，但在它支撑重要判断时，应当让实际判断者取得它。
同样，评测也要针对这类变化构造样例。继续增加十组同日期、完整表格的正常输入，可能不如补一组“日期不同但文件都真实”的反例。后者检验的是系统能否识别比较条件，而不是再证明一次解析器能读表。
四、交接最容易丢掉的，往往是使结论成立的条件
研究越长，系统越需要摘要、缓存、子 Agent 和历史回读。它们帮助模型处理有限上下文，也增加了信息被重新解释的机会。
原始材料写着“截至六月末、已披露的前若干项持仓”，第一轮摘要变成“主要持仓”，第二轮交接再变成“基金持仓”，最终报告就可能讨论“组合整体”。每次改写看起来都很自然，几个决定范围的词却消失了。金融 Agent 的可信证据链已经具体讨论过这种范围扩张；将它放进全景，重点在于看见各类交接共同承担的责任。
信息可以变短，条件不能在没有依据时变宽。 一个摘要可以省去重复文字，但如果省掉日期会改变比较结论，日期就是当前任务中不可丢的部分。工程上要保护的是有意义的关系，而不是要求所有摘要逐字保留原文。
还有一种更危险的变化：资料不仅丢了条件，还取得了原本没有的指令身份。
在内容信任的受控回归中，Web 内容经过晚期请求转换，被放进最终 SDK 请求的 system 位置。该验证使用真实协议映射与模拟网络发送，暴露的是应用侧的结构错位，没有证明发生过真实线上攻击。它提示我们：仅在入口告诉模型“网页只是资料”，不足以证明后续转换始终保留了这个身份。
这与前面的研究错误具有相似的交接结构，但不是同一种漏洞。一个扩大了结论适用范围，另一个改变了内容权威。前者需要业务口径与语义核查，后者需要来源身份、请求装配和执行权限的约束，不能都交给一个泛泛的“可信度检查”。OWASP 的 Prompt Injection 指南也把外部内容诱导与最小权限、执行控制放在一起讨论，单靠提示文本不足以承担全部防护责任。
长期记忆和其他 Agent 的意见同样需要这种区分。过去保存的一条建议可以作为研究材料，不能因为被召回就成为用户今天的新授权。子 Agent 的结论也可能非常有价值，但“内部协作者提供”只说明来源，不能代替对其依据和适用条件的判断。
这里值得坚持的原则是：传递内容时，保留它为什么可以被使用的依据；改变它的身份或用途时，由有相应职责的机制重新判断。
五、验证者增加了，发现错误的机会增加了吗？
甲、乙的比较已经生成，团队决定增加一个 Reviewer。主 Agent 把报告和摘要交过去，Reviewer 表示“分析合理”。
如果摘要已经删掉披露日期，这个 Reviewer 就没有足够材料检查日期是否一致。再增加一个只读同样摘要的 Reviewer，依然没有补上这个缺口。
这不是纯粹的假设。此前的 Reviewer 受控集成验证发现：系统调用了原始资料读取，但完整内容没有真正进入 Reviewer 输入，实际交付的仍是不完整摘要。修复落在已有材料的交接处。这项验证证明了材料进入输入的行为得到修正，不能据此声称审查者的全部语义判断已经可靠。
不过，“使用同一来源”不等于“复核没有价值”。一个检查者重新计算数字，另一个核对日期和份额，即使读同一份原文，也可能发现不同错误。换模型、换提示或独立上下文可能增加发现问题的机会，但它们都只是实现手段。
我们真正要问的是：这个检查是否增加了区分正确与错误的能力？它所依赖的前提，是否恰好也是我们正在怀疑的那个前提？
| 眼前的疑点 | 更有针对性的核查 | 难以补上缺口的做法 |
|---|---|---|
| 两份材料能否同口径比较 | 核对原文中的日期、份额、指标定义与覆盖 | 让更多模型评价同一段已经删去条件的摘要 |
| 计算是否忠实执行既定方法 | 独立复算或检查可重复的计算过程 | 只评价报告是否专业、语言是否连贯 |
| 报告是否保存了正确版本 | 从正式读取入口取得对应版本并核对 | 询问生成者“你确定保存成功了吗” |
同一原则也适用于 Coding Agent。实现、测试和说明由同一个 Agent 生成，完全可以是高效的工作方式；问题在于三者是否共同继承了未核对的需求假设。测试由另一个 Agent 编写，也不会自动让业务前提变得独立。
在这个基金功能里，验收条件可以提前写成可观察的行为：日期不同要在比较中明示；部分持仓不能被称为全部持仓；保存以后要能读到指定版本。然后用会挑战这些条件的输入验收，而不是从已经写出的实现倒推所有预期结果。
连测试自身的前提也要有观察依据。Agent 测评全景记录过一个受控恢复测试：夹具宣称旧 Worker 已停止，实际上旧进程仍能继续写入。只有把故障注入放到实际写入接缝，才真正开始检验所声称的恢复情境。绿灯是否有价值，取决于测试实际制造了什么条件、检查了什么结果。
Anthropic 在 Demystifying evals for AI agents中区分执行记录与环境中的最终结果，并强调模型评分需要与人工判断校准。对我们而言，可迁移的做法是：确定性约束、语义判断和实际效果各用适合的方法核对，让一次评分回答清楚的问题。
所以，新增 Reviewer 前应先说清它要发现的错误、需要看到的材料，以及已有检查为什么不足。如果只是把相同的缺失输入再评价一次，先修交接更有意义；若已有审查者拿到完整材料后已经能够完成相同检查，就可以暂缓增加新的角色和串行调用。
六、信任会过期：重查哪些结论，取决于哪些前提变了
报告今天完成，明天甲基金发布了新一期持仓。用户回来问：“现在的结论还一样吗？”
旧报告仍然是一份真实的历史成果，但其中“当前重叠”的适用性需要重新判断。若新材料改变了持仓数据，重叠计算及依赖它的解释就需要更新。费用资料、份额和比较条件均未变化的部分，则可能继续复用。
这时，两个极端都不理想：把整份报告一律视为永久有效，会忽略变化；每次重做全部研究，又把仍成立的部分一起丢掉。更有用的做法是沿依赖关系定位受影响的判断。
这条原则可以同时解释几种工程选择：资料更新后检查依赖它的研究结论；实现改变后运行覆盖受影响承诺的回归；报告改版后检查原评审是否仍适用于新内容；任务恢复时检查当前动作是否仍在原授权范围内。
已有授权不应仅因重启就失效，也不应因为历史摘要写着“用户批准”而无限延续。它能否复用，取决于真实授权对主体、资源、动作、版本和有效条件作了什么约定；需要重新检查，并不等于每次都要重新询问用户。
实际效果还要独立处理。保存请求已经发出，但网络中断导致没有取得回执，此时“没有看到成功”不能直接解释成“从未保存”。应先查询原操作或对应版本；只有执行协议明确允许时，才以原幂等身份安全重试。让模型重新推理一遍，无法补出远端有没有提交这个事实。
所谓局部未知，也应沿依赖关系传播。拿不到可比持仓，可以交付已核对且独立成立的费用说明，却不能保留依赖持仓比较得出的整体风险排名。如果依赖关系本身不清楚，就需要扩大复核范围，不能为了省事宣称其他部分一定不受影响。
由此可以得到一项实用判断：失效范围应跟随真实依赖；验证范围应覆盖受到影响的承诺。 小任务可以用已有版本引用和几条明确的验收条件表达这些关系，只有跨时间复用、分支或纠错复杂到难以维护时，才值得增加更系统的依赖记录。
七、让自主探索扩大，把承诺落到正确的位置
如果每一个推理步骤都要先完全证明，研究根本无法开始。模型需要提出暂时没有证据支持的假设，选择搜索路线，尝试计算，然后根据新发现修订判断。这样的探索正是 Agent 的价值之一。
可以严格约束的是这些候选结果在什么条件下被采用：假设成为面向用户的结论之前，说明依据和限制；调用触达受保护资源之前，检查真实授权；系统声称完成之前，确认对应效果。
这里的“边界”发生在实际行为处。搜索本身也会接触网络、消耗预算，查询参数还可能携带敏感数据，因此探索同样需要资源和数据范围约束。不能把所有控制推迟到最终报告发布时才做。
因此，让 Agent 更自主，不必等同于放松所有门槛。可以允许它自主选择查哪份材料、怎样拆解问题、何时补证；在权限与后果明确的边界上，仍然执行稳定约束。减少重复询问和无效审查，与保留关键保护可以同时成立。
把规则写进代码也不是最终证明。授权服务可能配置错误，计算程序可能有缺陷，人工评审同样可能漏看。代码的优势在于检查位置明确、规则可审阅、行为可复测，并能在模型无法随意改写的执行路径上实施约束。我们依然需要核验这些机制，尤其是实际效果能否绕过它们。
工程上总会存在一组必须依赖的基础：身份从哪里来、规则由谁维护、实际写入经过哪里、哪个记录代表提交。合理目标是让这组基础足够小、责任明确并可以持续验证，而不是通过无限增加审查者，假装彻底消除了信任前提。
一次设计评审，怎样真正使用这个视角？
先选择一项用户确实依赖的承诺，例如“报告按指定范围完成比较，并保存为之后可读取的版本”。然后沿着这项承诺反向找依据：比较需要哪些材料与前提，保存需要什么授权，用户读取由什么事实确认。
来到每个关键交接点，问三个具体问题即可：
- 这里实际已经确认了什么？ 写清范围与版本，不用一个笼统的“成功”。
- 接下来准备据此断言、执行或向用户承诺什么？ 看是否扩大了对象、时间、权限或效果范围。
- 多出来的部分由什么支撑？ 可能是有效推导、已有业务约束、当前授权，也可能确实还缺一项核验。
这三个问题不会自动导出更多模块。若现有工具网关已经完整覆盖同一授权边界，就沿用它，不另建一个由模型判断权限的权威；若原始资料仍可取得、使用资格有效且满足本轮条件，就修好实际交接，避免重复抓取；若一个版本的验收仍然适用，就复用回执；若还缺比较前提，就补针对性材料，或者收窄结论。
也要给额外验证一个停止条件。确定性检查已经覆盖了所需约束，新增 Reviewer 又没有针对尚存的具体错误提供新的辨别能力，就可以停止增加流程。对于低后果、可撤回的探索，保留可追溯结果和合理预算往往更有用；涉及权限、敏感数据和不可逆效果时，必要控制不能由一次漂亮评分抵消。
结尾：我们最终交付的，是一项可以负责的承诺
回到甲、乙基金的任务。一个有用的结果可以按各自日期与覆盖范围说明已披露持仓的交集，交付口径已经核对的费用说明，并对暂时缺少依据的整体判断保持开放；补齐同期资料后，再更新相应比较。报告保存之后，用户取得对应版本，后续资料变化也能说明哪些部分需要重查。
这种结果既没有把不确定性全部藏起来，也没有因为一项未知而放弃其他有效工作。模型仍然可以积极研究，系统则明确知道哪些判断已有依据、哪些动作已经获准、哪些效果确实发生。
下次看到一个 Agent 说“完成了”，最值得追问的并非它表现得多有把握，而是：它完成的具体是什么，这项承诺依赖什么，现在这些条件还成立吗？
当这些问题有清楚的答案，我们就有理由在相应范围内采用它的结果，也有办法在前提改变时及时修订。Agent 的自主性由此获得了可以扩大的基础：探索范围可以更广，对用户作出的承诺始终具体。
延伸阅读
- 一份报告背后的九个架构判断：沿报告任务理解职责与取舍。
- 金融 Agent 的可信证据链：深入资料、数字、版本与消费关系。
- AI Coding 最贵的不是写代码，而是决定什么值得验证：理解关键假设与验证投入。
- Agent 测评全景：分别检查执行、质量与真实交付。
如果这些工程判断对你有帮助，欢迎在 ETF Agent Engineering Notes 点一个 Star，继续交流可复核的 Agent 实践。