读取知识与改变现实是两条路径
一句话收获：模型生成行动意图，不代表外部系统已经执行。
这个场景在解决什么问题
这个场景要划清一条边界：模型"说句话"和"真的改变现实"之间，隔着好几道门——回答、查询、候选行动、真实执行，是四个不同环节。
观察方式是"让模型从解释走向外部行动，看每一道控制门"。它的价值在于：很多人以为"模型说帮你下单了 = 真的下单了"，其实中间有查询、有候选、有权限校验、有回执验收，少一道都可能出事故。
先理清这条判断链（文字版）
判断"模型到底有没有真的改变现实"，按这条链一步步加控制门：
- 先看它是不是只是生成解释：给了建议，但外部对象和状态没变？（第 1 步：生成解释）
- 再看它是不是只是查询事实：用只读工具拿到当前状态，但没有写入？（第 2 步：查询事实）
- 再看它是不是只是提出行动：给出了候选写入，但还没执行？（第 3 步：提出行动）
- 最后看它有没有执行与验收：通过校验后写入，并重新查权威状态验收？（第 4 步：执行与验收）
一句话串起来：先分清"回答"还是"行动" → 再分清"只读"还是"写入" → 再分清"候选"还是"已执行" → 最后确认"已执行 + 已验收"。每一道门，都挡住了"嘴上说说"变成"真做了"。
逐层详解
第 1 步：生成解释
原文：模型给出建议，外部对象和状态没有变化。
白话：模型只是"说了句话"——给了个建议，但外部的那个对象（比如订单、工单）和它的状态，一点没变。文本生成只改变了当前这段对话，没改变现实。
类比：生成解释是"嘴上说说"——你朋友建议你"该去健身了"，但你的身体状态、健身房会员卡，什么都没变。
举例：模型回答"建议你给这个客户发一封跟进邮件"，但系统里并没有真的创建任何邮件任务，客户的跟进状态也没变。它只是给建议，不是做动作。
为什么重要：文本生成只改变当前对话——它产生的是"话"，不是"事"。
怎么验证（证据点）：
- 回答存在
- 外部状态不变
- 无工具回执
别踩的坑（边界）：建议出现不等于任务已创建——模型说了"建议创建任务"，不代表任务真的被创建了，别把建议当结果。
落地检查：先区分回答和行动——先确认这一步到底是"给建议"还是"做动作"，两者性质完全不同。
第 2 步：查询事实
原文：只读工具取得当前状态并返回结构化证据。
白话：用"只读"工具（只能查、不能改）去拿到当前状态，返回的是结构化的证据。查询扩大了模型"能看到什么"，但不产生写入的副作用——查一下，没改任何东西。
类比：查询事实是"看一眼"——你去银行柜台查余额，看到了数字，但账户里的钱一分没动。
举例：模型要判断"该不该催款"，先调一个只读接口查"这笔订单当前是否已付款"，拿到结构化返回 {"paid": true}。它只是看到了状态，没有做任何写入。
为什么重要：查询扩展观察空间，但不产生写入副作用——看，不等于改。
怎么验证（证据点）：
- 查询已执行
- 状态可查
- 无写入
别踩的坑（边界）：读取成功不授予写权限——能查到数据，不代表你有权去改它，读和写是两种权限。
落地检查：感知工具和执行工具风险不同——把"只能读"的工具和"能写"的工具分开管理，读工具的风险远低于写工具。
第 3 步：提出行动
原文：模型根据事实提出候选写入，尚未执行。
白话：模型根据查到的实时事实，提出了一个"候选的写入动作"（比如"把订单状态改为已发货"），但还没执行。模型只负责提候选，真正校验权限和状态的是程序。
类比：提出行动是"填好申请表还没交"——你把变更单填好了，但还没递出去、没审批、没生效。
举例：模型查到订单已付款，于是提出候选动作"调用发货接口，参数为订单号 123"，但这个候选还没执行，等着程序去校验参数、校验权限、校验状态。
为什么重要：模型负责候选，程序负责权限和状态校验——模型只"提方案"，方案能不能执行，得程序把关。
怎么验证（证据点）：
- 行动候选
- 参数待检查
- 权限待确认
别踩的坑（边界）：候选格式正确不证明允许执行——参数格式填对了，不代表你有权执行、不代表现在该执行。
落地检查：行动意图必须经过模型外检查——候选动作一定要经过模型之外的程序去校验权限和状态，不能模型说执行就执行。
第 4 步：执行与验收
原文：工具通过校验后写入，系统重新查询权威状态并验收。
白话：候选动作通过校验后，工具才真正写入（改变现实）；写完之后，系统还要重新去查一遍权威状态，确认"现实真的变了"，这才算验收通过。
类比：执行与验收是"真的做了 + 拿小票确认"——不只是把变更单交上去，还要等它生效、再回来核一眼"确实变了"，才算完事。
举例：程序校验通过后，调用发货接口把订单改成"已发货"，然后系统重新查询订单系统，确认"当前状态确实 = 已发货"，并留下这条回执作为验收证据。
为什么重要：外部回执与权威状态共同证明现实变化——光有"写入"还不够，得有回执 + 权威状态双重确认。
怎么验证（证据点）：
- 工具回执
- 权威状态更新
- 验收通过
别踩的坑（边界）：页面提示成功不能替代外部证据——前端弹个"成功"，不代表后端系统里状态真的变了，要拿权威系统的证据。
落地检查：执行和验收属于不同环节——执行是"写入"，验收是"回查确认"，两个环节分开做，不能省。
落地可行性小结
本场景涉及的技术栈：只读工具、写入工具、权限校验、权威状态查询、外部回执。
真实落地怎么做：把"回答 → 查询 → 候选行动 → 执行 → 验收"拆成明确的分段，每段之间加控制门——候选行动必须经程序校验，执行后必须回查权威状态。
要检查什么：这一步是只读还是写入、有没有权限校验、有没有工具回执、有没有回查权威状态、验收证据是否留存。
常见坑：把模型的建议当成已经执行；把"能读"当成"能写"；候选格式对就以为能执行；用页面提示"成功"替代权威系统的证据。
回顾
- 模型生成行动意图 ≠ 外部系统已经执行，中间隔多道门。
- 生成解释只改对话、不改现实；查询事实只读不写、读权限≠写权限。
- 模型只提候选行动，权限和状态校验由程序负责，必须在模型外检查。
- 执行要拿工具回执，验收要回查权威状态，两者是不同环节。
- 页面提示成功不能替代外部权威证据。