在 FLock 刚发布的 THIS / THAT 1.0 官方仓库中，有一个很具代表性的演示：系统将删除数据库的指令 rm -rf /var/lib/postgresql/data 喂给模型，让其评估该命令是否能在无人工监管的生产环境中直接执行。
模型只需从三个预设选项中做选择：只读状态、修改或删除数据、访问网络。评测结果显示，模型以 99.8% 的高概率判定为“修改或删除数据”——没有废话连篇的思维链（CoT），也没有需要正则二次解析的长文本回答。(GitHub)
它的设计初衷非常务实：将原本抛给对话模型去做、耗时冗长的复杂文本判断，收敛成代码可以直接消费的确定性输出。
截至 2026 年 9 月 22 日，FLock 已公开这个约 19 亿参数模型的权重与本地推理代码。官方测试数据显示，在 RTX 5080 笔记本的基准测试下，单次决策延迟仅约 30.9 毫秒。不过需要说明的是，这仅代表单次模型推理的耗时，并不等同于整条业务链条的端到端耗时。(GitHub)
在此之前，TypeSafe 旗下的 Jev 也已经被引入 Agent 执行链路。9 月 17 日 LangChain 发布的集成指南展示了它的两类典型用法：动态路由模型、以及在工具调用前进行风险把关。决策模型被作为“守门员”，卡在 Agent 触发下一步动作的关键节点上。(LangChain)
这些探索验证了一个工程常识：业务程序中的海量分支跳转，本质上只需要一个边界清晰的离散判断，根本无需每次都做昂贵的自回归文本生成。
但模型选出答案，仅仅是走完了第一步，后续的工程链路远比想象中复杂。
能识别出“某条命令会删除数据”，并不等于“当前操作者有权执行它”；客户在邮件中“诉求退款”，与系统“执行退款动作”之间，也横亘着订单校验、权限审批与流水核对等一系列业务规则。
决策模型压缩了推理耗时，但决策所依赖的业务前提与事实依据，依然必须被严格定义。
在这条落地链路上，Ontology、Graph Engineering 与 THIS / THAT 各司其职：分别负责业务概念建模、执行链路编排，以及局部离散判断。在拼装这套架构之前，我们必须先厘清每一层到底能承诺什么、又无法保证什么。
一个格式合规的答案，离一次真正安全的操作还有多远
THIS / THAT 的核心机制，是直接提取模型在指定 token 位置的隐藏层状态（hidden states），对开发者预先定义的选项标签打分，并归一化为概率分布。它完全跳过了自回归逐字解码的循环；当一次输入包含多个决策点时，甚至可以在同一次前向传播中并发提取多个位置的输出。
这种做法带来了一项确定性保证：输出结果严格封闭在枚举候选集内。开发者定义了退款、技术支持、账单和其他，返回值就绝对不会飘到集合之外。
这极大提升了代码调用的可靠性，却无法解决“选项体系本身是否完备合理”的矛盾。例如，一封客诉邮件同时夹杂了重复扣款与技术故障，如果系统硬性要求单选，那么模型就算输出格式再合规，也无法反映真实的业务意图。
类型系统约束了输出的“格式骨架”，却管不住深层的“业务内涵”。
正因如此，我们不能简单地将决策模型与“让大模型吐长文本再用正则硬抓”做对比。早在 2024 年 8 月，OpenAI 就上线了 Structured Outputs，通过受限解码保证模型严格遵循 JSON Schema 输出。生成式大模型同样能被封装为强类型的结构化接口。(OpenAI)
因此，评估决策模型的实际价值，必须回归具体的业务场景：砍掉解码阶段后，在大幅降低延迟的同时准确率是否达标？输出的置信度是否具备可信的校准？遇到无法裁决的边界场景时，系统是否有完备的降级兜底出口？
技术接口只能在语法层面收敛不确定性；真正的确定性，必须交由清晰的业务定义与流程规则来兜底。
Ontology：先说清楚，什么算一笔退款
Ontology 常被直译为“本体”。这个词容易让人联想到宏大繁琐的知识图谱，但实际落地完全可以从微观领域切入。
早在 1993 年，知识工程学者 Thomas Gruber 就将本体（Ontology）定义为“对概念体系的显式形式化规范”。通俗来讲，它要解决的是系统间“语义不统一”的问题——让不同的软件模块使用完全对齐的词汇、实体与关系，消除业务理解上的歧义。(Tom Gruber)
映射到售后退款场景中，就是在代码层建立统一的事实标准：什么是有效订单？流水记录如何关联？退款申请对应哪一笔支付？审批凭据由哪条业务规则触发生成？
以一个典型的售后请求为例。客户在邮件里称：昨天已有客服同意退款，希望今天收到款项。系统查到了订单与付款流水，却未检索到审批记录。
此时系统应当明确区分并保留两类事实：“客户主观声称已获批”，与“系统客观未查到审批凭据”。
如果在组装上下文时，偷懒将客户的说辞直接格式化为“审批已完成”，下游模型就会拿着一个被污染的状态做推导。此时模型哪怕完全遵从了 Prompt，也会以极高的置信度输出灾难性的错误结论。
这本质上是事实溯源与证据链的问题。
一个严谨的业务数据模型，必须严格割裂“客户陈述”、“系统客观记录”与“待校验信息”。正如 W3C 在 OWL 规范中恪守的“开放世界假设”（Open World Assumption）：知识库中不存在某条记录，只代表当前状态未知，绝不能直接等价于该事实不成立。(W3C)
对退款系统而言，查不到审批记录可能意味着审批尚未发起，也可能意味着分布式事务尚未同步完成。接下来究竟该跨系统二次核验，还是直接转人工，需要由明确的业务策略来裁决。
因此，单薄的枚举标签只能表达局部的意图分类。像 refund / billing / technical / other 这类标签可以给工单归类，却完全无法描述“退款”背后所绑定的业务实体与前置依赖。完整的业务语义，必须由实体间的关联拓扑与状态机共同构建。
在落地初期，完全不需要一上来就重度引入图数据库。围绕退款核心链路把实体关系梳理清楚，按需抽取模型推理所需的上下文切片即可。
还有一个极易混淆的地方：意图识别与动作鉴权，必须物理解耦。
系统必须具备识别“用户意图是删除数据”的能力，哪怕该用户根本没有删除权限。绝不能因为操作被禁止，就粗暴地把“删除数据”从意图分类中剔除，倒逼模型做出南辕北辙的误判。
只有在下游触发动作（Action）决策时，动作候选集才需要受到鉴权与业务状态的严格约束。 此外，“要求客户补充信息”、“直接拒绝执行”等兜底动作，在流程中也必须拥有明确的合法分支。
模型能选什么，完全受限于系统投喂的候选空间。如果正确分支压根没有注入候选集，分类器能力再强也是无米之炊。
Graph：让判断进入一条有边界的流程
理清了业务实体与语义定义，接下来需要编排系统状态的流转时序。
这里的 Graph 主要指计算执行图（Execution Graph）。它与存储知识的图谱有本质区别：知识图表达的是静态的实体关联；执行图则是动态的确定性工作流——负责串联起“查询订单、意图判决、前置校验、动作触发”的每一步流转逻辑。
正如 LangChain 在其“图工程”（Graph Engineering）文章中所指出的，这种架构本质上就是状态机：节点（Node）负责执行确定性的业务代码、模型单点推理，或挂载带内部循环的子 Agent；边（Edge）则负责路由跳转，既包含固定连线，也包含依赖当前上下文的条件分支。(LangChain)
这为上述退款场景提供了一种严密的编排范式。
收到邮件后，系统先查询对应订单。若找不到订单，直接触发“请求补充订单号”分支；找到了，再检索付款与退款流水。邮件的核心诉求，交给经过垂直微调的模型判定；是否已完成退款、金额是否超限，则由确定性代码严格核查。
如果流水显示该笔款项已退回，流程直接流转至“退款进度说明”。对于缺少审批依据的请求，系统可以继续向风控系统核验，或流转至人工坐席。文案生成可以交给通用大模型，但最终的退款转账，仍必须交由带鉴权网关的专用工具执行。
在这套体系下，AI 模型无需“大包大揽”地一步完成全流程；每个决策节点只需在其能力边界内，交出经过校验的局部判断。
这种分工在传统软件工程中早有成熟范式。OMG 的 DMN（决策模型与标记标准）专门用于表达业务规则与决策依赖，并常年与负责工作流编排的 BPMN 协同使用。它提倡将复杂决策拆解为清晰的拓扑依赖，沉淀出高复用性的决策组件。(OMG)
神经符号（Neuro-symbolic AI）领域很早就有类似探索。例如 2018 年的 DeepProbLog 通过“神经谓词”将深度学习接入一阶概率逻辑编程，使感知判断能够参与符号推理。但必须清醒认识到：在工程流里接入一个小分类模型，并不等同于这套系统就天然具备了符号逻辑的完备推理能力。(arXiv)
在成熟的企业级软件中，类似设计也屡见不鲜。例如 Palantir Foundry 的 Action Submission Criteria 机制，能在动作提交时强行校验对象属性与操作者权限。在官方给出的机型调配案例中：提交者必须隶属于指定机务组，调配的目标飞机也必须处于在役状态。(Palantir)
这个案例揭示了一个铁律：一个高危动作能否被触发，必须在执行入口由确定性逻辑做硬性强校验。模型此前给出的置信度再高，也绝不能替代这一道防线。
执行图并不意味着死板地锁死所有路径。在特定节点内，依然可以留给大模型做开放式的自主探索，外层只需卡死工具调用权限、Token 预算与终止条件即可——循环本身，本就是图的一部分。(LangChain)
图工程（Graph Engineering）的核心价值，在于关键节点上的强约束。为了显得复杂而把流程图画得盘根错节，本身毫无工程意义。
一张地图，和模型真正看见的那一小块
在 THIS / THAT 官方发布的 Model Card 中，有一组消融实验相比公开榜单跑分，更能说明其架构设计的精髓。
作者让同一个模型回答相同环境下的问题，一次输入全局完整地图，另一次仅裁剪出答案真正依赖的局部窗口。在 32×32 的地图上，模型准确率从 56.2% 飙升至 97.9%；在 128×128 的地图上，这一对比更是夸张的 47.9% 对 100%。(Hugging Face)
这里的唯一变量，就是模型视野所及的上下文窗口。
然而，实验中的模拟器天然知道答案对应的局部坐标，但真实的工业业务却绝非如此开卷。面对一封售后邮件，系统必须自行判断哪些历史记录相关、哪一版售后条款适用、以及特定审批流水是否与当前工单匹配。
因此，这组测试只能得出一个克制的结论：高相关性的上下文组织，能极大释放小模型的判决潜能；但绝不能简单推导出“只要在企业里堆一套本体工程，就能立竿见影拿到同等收益”。
由此可以抽象出一个不可或缺的架构层——位于底层业务数据与上层决策模型之间的“任务状态构建层”（Task State Assembly Layer）。
它的职责是精准萃取决策所需的关键证据链，标注数据来源与时效，并显式标记缺失字段。喂给模型的应当是一份高度对齐决策问题的精要证据包，而非未经清洗的“业务信息大杂烩”。
在工程部署上还有一个容易踩坑的细节：THIS / THAT 开源代码中对状态文本默认设限为 1,536 个 Token，超限会被直接截断。如果不加过滤地把长篇邮件、历史工单和公司规章一股脑拼进去，排在末尾的关键信息甚至根本进不了模型的视野。
若一锤定音的关键凭证正好被物理截断，后续设定的判定阈值再精细，也是缘木求鱼。
因此，状态构建过程必须具备完全的可观测性：核心字段是否缺失、是否发生 Token 截断、命中的具体版本索引，都应落盘进审计日志。一旦发现关键证据缺失，工作流必须立即转入补全上下文的逻辑。
Ontology 提供业务对象与关系字典；执行图负责推进状态流转；状态构建层据此萃取精准上下文。THIS / THAT 接收到的，正是经过层层脱敏、提纯后的局部判决任务。
这一层不会替模型作答，却决定了模型到底在回答什么。
99% 的把握，为什么仍然可能需要人工
决策模型输出概率值后，开发者很容易产生一个惯性直觉：高于设定阈值就直通执行，低于阈值就转交人工/工单上报。
但真正的深水区在于：这个概率分值在具体的业务场景下，到底能否代表真实的正确率？
Softmax 只能从数学上把输出 Logits 归一化为概率分布，却根本无法保证该数值与真实准确率等价。Guo 等人早在 ICML 2017 的经典研究中就指出，现代深度神经网络普遍存在严重的置信度校准偏差（Miscalibration），并提出了温度缩放（Temperature Scaling）等校正方案。(Proceedings of Machine Learning Research)
一个良好校准的模型，当其给出 80% 的置信度时，在一组同质样本中的实际命中率就必须逼近 80%。这种一致性必须通过严苛的后验评测来验证，绝不能因为字段名写着 probability 就想当然地全盘接受。
校准同样受制于泛化边界。大量分布偏移（Distribution Shift）研究表明，针对特定语料调优的校准参数，一旦换了业务场景就会迅速失效。模型在通用公开基准上测得的高置信度，绝不能直接照搬到垂直行业。(Google Research)
更何况不同框架对 confidence 的定义甚至大相径庭：THIS / THAT 代码里取的是被选中的单一选项概率；而 Jev 衡量的则是全局概率分布的离散集中度。这意味着一旦切换底座模型或框架，原有的置信度阈值必须全盘重测，绝不能无脑套用。 (TypeSafe AI)
即便输出的概率经过了严苛校准，自动化直通执行依然要权衡资损代价。
做个简单的期望值演算：某类高危操作经实测有 1% 的出错率，而单次故障的资损是 10,000 元，则该操作自动执行的单次期望损失为 100 元。若将该流量切给人审复核，综合人审开销与残余漏检风险后的预期成本仅需 20 元，那么选择复核无疑是更理性的商业决策。
将客服工单分错分类，与误删生产数据库的一张核心表，绝不能共享同一套自动化放行标准。
这在学术界正是“选择性分类”（Selective Classification，即带拒绝选项的分类机制）的核心诉求：主动允许系统在不确定时“拒绝作答”，通过牺牲一定的自动化率来换取极低的资损风险。系统真正需要衡量的，是在安全红线内究竟能有多大比例的请求实现无人值守。(arXiv)
这为业务防线的设计换了一个更具务实意义的提问：在业务容忍的资损水位内，我们能把自动化覆盖率推到多少？
硬性权限与关键证据链必须独立设防。缺少审批记录应当在入口处直接熔断并转人工，根本无需耗费算力等模型去“算置信度”。
追问与证据补全链路，必须引入真正的信息增量。 跨库查询、找用户核对订单，都是有效动作；但如果对着同一份毫无变化的输入不断重试 Prompt、试图刷出更高的概率分，纯属掩耳盗铃。
收益要算在整条流程上
现有的前沿工程实践证明了这套解耦架构的优越性，但距离成为通用的工程标准，依然需要大量的产业级验证。
在 TypeSafe 公布的四类典型工作流 Benchmark 中，相比于将厚重规章一锅端塞进“单体大 Prompt”（Monolithic Prompt），这种将链路拆解为“确定性代码 + 狭窄域离散判决”的组合拳，在准确率、端到端成本和时延上均实现了碾压性胜出。这一工程红利也绝非特定模型所独享。(Evals)
当然也要看到其局限：该评测预设了周边业务代码 100% 正确，且参考标签仅靠两款旗舰闭源模型交叉对齐生成。因此它更偏向于实验室基准，不能直接等同于严苛生产环境下的实战表现。(Evals)
对 THIS / THAT 的评估同样需要客观看待其边界：该模型在训练阶段就已全覆盖测试集中的 15 种空间拓扑题型，而作为对照组的第三方托管大模型，在测试时均处于零样本（Zero-shot）冷启动状态。此外，在涉及求最短路径、连通性等图遍历计算时，该模型的表现大幅滑坡。作者也坦陈：图搜索这类算法强项应当直接交给原生代码执行，小模型只应负责语义裁决。(GitHub)
这些边界给出了极其清晰的技术选型指南：能用算法和代码确定性解决的搜索与计算，全部留给代码；反复出现、语义边界收敛的判断点，交给微调后的小决策模型；高阶泛化推理与开放式内容生成，依然保留给通用大模型或人工坐席。
并非所有系统都配得上这套重型武器。
如果业务只需几条固定规则，原生代码足以搞定；在处于 MVP 快速试错期、选项与流程朝令夕改的产品中，过早将语义图谱与执行流固化，反而是沉重的技术负债。唯有当特定语义判决高频出现、底层数据模型开始跨业务线复用时，拆解这套分层架构的 ROI 才会真正爆发。
对准备试用 THIS / THAT 的团队，一个可验证的切入点是单个决策点，例如售后请求分流。
在同一批真实业务样本上，横向对比通用大模型与 THIS / THAT；保留相同的原始事实，对比“全文裸投”与“结构化证据注入”的判决差异；再评估引入前置规则校验与门控之后，整体风控表现的变化。测试集务必覆盖证据缺失、恶意注入与含糊请求，避免只拿阳光场景来自嗨。
整套架构落地后的终极验收指标，必须看系统级的综合账本：端到端自动化跑通的比例是多少？失控故障点在哪里？以及叠加了大模型兜底降级调用与二线人工处理后的真实综合成本是多少。
不仅低置信度的边缘工单需要复盘，高置信度直接放行的样本更要定期抽检。否则你的监控面板里只会躺着系统犹疑不决的个案，而那些“模型极度自信却错得离谱”的高危风险，将直接变成潜伏在日志盲区里的定时炸弹。
这些反馈数据可以用于补充微调集、修正标签语义或调整门控阈值。变更仍应遵循标准的灰度发布机制，生产流程绝不能仅仅因为有了反思回路，就获得随意动态篡改核心规则的权限。
回到仓库里那条删除 PostgreSQL 数据目录的演示命令，模型确实能以 99.8% 的高把握瞬间指出它会“修改或删除数据”。这个结果极具工程价值，但它依然无法证明目标目录是否在清理白名单内，更无法保证敲下回车的人拥有执行权限。
一套成熟的企业级业务系统，必须将完整的证据链钉死在审计日志里，并在条件出现一丝缺漏时坚决截停操作。
模型的判决分值可以充当关键证据，但高危操作的通行权限，绝不能仅由这个分数说了算。