当大多数团队还在讨论"智能体能做什么"的时候，在政府部门、税务、医疗这类强监管场景里，真正的问题早已换成了另一个：你敢不敢让它做？
一个面向消费者的聊天机器人答错一次，代价是一次糟糕的用户体验；而一个税务智能体对错综复杂的申报做出错误处置，代价是纳税人的真金白银、机构的公信力，以及无法向审计交代的合规黑洞。在这类场景里，"大概率正确"和"基本可用"都不构成上线理由：系统必须是可复制的、可解释的、可验证的。
Palantir 的两位工程师 Vishesh Patel 和 Anchey Peng 最近完整分享了他们在这个方向上的工程实践：如何为美国国税局（IRS）这类机构构建能够给出可验证结果的智能体工作流。他们把整套方法论称为"确定性设计"（Deterministic by Design）：不是寄望于更大的模型或更长的提示词，而是从架构层面把不确定性压缩到它该在的地方。
这套实践之所以值得细读，是因为它几乎没有依赖任何"独家黑科技"。它回答的是每一个想把智能体推入生产环境的团队都会撞上的五个问题：
单一智能体的准确率为什么总会触顶？
上千页的规则手册如何变成可执行的系统？
智能体和人类审核者如何看到同一个世界？
这样的系统怎么做测试？
人在整个回路里到底扮演什么角色？
一、政府级 AI 的三道门槛
在企业内部工具里，AI 的评判标准往往是"效率提升"；而在政府场景里，任何自动化系统先要跨过三道门槛。
第一道是可复制性。同一个案件，今天处理和下个月处理，由这个智能体处理和由那个智能体处理，结论必须一致。政府行为讲究平等对待，如果两个情况相同的纳税人得到了不同的处置，这本身就是行政瑕疵。对应的技术答案是确定性。
第二道是上下文。税务决策不存在于真空中：一个申报调整牵涉纳税人的历史申报、往来函件、账户状态。智能体要做出合法合规的判断，必须和办案人员站在同一个事实基础上。对应的答案是语义数据层。
第三道是准确性。这里的准确性不是演示里的"看起来不错"，而是可度量、可回归、可向监督机构证明的准确。对应的答案是评估体系。
这三道门槛构成了整场工程实践的坐标系。后面所有的架构决策：决策树、语义层、三层测试、人工审核，都可以看作是对这三行的逐行兑现。
一个具体的战场：IRS 的复杂申报
以 IRS 的一个典型场景为例。一份复杂申报今天由人工处理，需要一到两个小时：材料包到达后，办案人员要通读扫描表格、手填字段和 PDF；然后对照数百页的规则手册判断适用条款；接着调取账户信息、历史申报和往来函件进行核对；最后才能做出处置，转交部门、发出新函件，或者执行税务调整。
注意这个流程的两个特点。
其一，它是多模态的脏数据环境：扫描件、手写体、非结构化 PDF 混杂在一起。
其二，它的每一步都依赖前一步的正确性：读错一个字段，后面的规则匹配和历史核对全都是在错误的地基上盖楼。记住这两点，它们是理解后面所有架构决策的钥匙。
二、"一个超大提示词"的天花板
面对这样一个流程，今天绝大多数团队的第一反应：Palantir 称之为"naive build"，是这样的四步：
第一步，创建一个巨大的提示词，把整个申报包作为 PDF 塞给大模型；第二步，给规则手册建一个 RAG 索引，让模型自己检索并解释规则、判断 eligibility；第三步，给智能体配上查询遗留系统的工具，让它自己查纳税人的历史申报和案件记录；第四步，给智能体配上生产环境的操作工具，让它自动完成调整。
这个方案的迷人之处在于它真的能"跑起来"。给一个演示案例，它往往能给出看似合理的结论。但把它推入生产环境，问题会以结构性的方式暴露出来。
具体走一遍它的执行过程就能看清：智能体对整个 PDF 包做一次性抽取；然后评估纳税人的申报主张；用 RAG 加语义搜索去规则手册里找相关章节；调用工具查询账户历史；翻找相关申报和往来信件；在手填字段和系统 API 代码之间做翻译；最后得出最终决定，并直接在生产环境执行。
这条链路看起来流畅，实则每一步都在积累误差。而最终暴露的是四个无法靠"调提示词"解决的问题：
第一，准确率触顶。 单个智能体、单个巨型提示词，把文档理解、信息抽取、规则解释、数据查询、决策推理全部压进一次（或少数几次）模型调用里。每个子任务单独看可能有 90% 的准确率，但它们串联相乘之后，端到端的可靠性迅速跌破生产可用的底线。更麻烦的是，这个天花板不随提示词工程的努力而显著移动。因为错误的来源是架构本身：你用同一个概率性组件去承担了确定性和非确定性两类性质完全不同的工作。
第二，规则解释不一致。 让模型通过 RAG"理解"规则，意味着同一条规则在不同上下文、不同检索结果下会被解释出不同的含义。规则手册的本质是法律文本，它需要的是被执行，而不是被解读。把法律解释交给每次运行都可能不同的概率采样，等于把"同案同判"原则交给了随机数。
第三，遗留系统的结构摩擦。 政府机构的遗留系统有自己的数据模型、状态机和怪癖。让智能体即兴地调用查询工具、在手写字段和 API 代码之间自由翻译，短期看灵活，长期看是在每个案件上重复发明适配逻辑，错漏无法穷尽。
第四，全自动化侵蚀信任。 当系统直接在生产环境执行处置、没有任何人看过一眼，那么第一次出错。不是"是否会发生"，而是"何时发生"，就会让整个项目在机构内部失去政治生命。信任一旦失去，再先进的模型也救不回来。
这四个问题指向同一个诊断：这不是模型能力问题，也不是提示词水平问题，而是架构问题。解药不是更强的模型，而是重新划分系统里"确定性"与"概率性"的边界。
三、把上千页规则手册变成一棵决策树
Palantir 的第一步，是彻底改变规则的存在形式：不再让模型在运行时"阅读理解"规则手册，而是把规则手册翻译成代码，工程团队与政策专家坐在一起，把上千页的规则逐条落地为一棵版本化的、可测试的决策树，并且规则变更要和政策专家一起评审，就像评审法律条文一样。
在 IRS 的场景里，这棵决策树大致长这样：材料包先经过预处理（拆解函件、旋转归一化图像、生成 PDF 目录）；然后进入抽取环节，从信件和表格中提取结构化字段；接着进入语义数据层，把抽取结果挂载到纳税人、申报表、往来函件等业务对象上；然后识别申报主张，这封纳税人来信究竟所为何事；再往后是确定性的分支判断：是身份盗用问题吗？是调整总收入变更吗？是地址变更吗？每个分支沿着规则继续下行；之后汇总证据，为人工复核准备好全部依据；最后的处置动作，由税务审查员确认后执行。
这张架构图里藏着整个方法论的核心：树上有两类节点，确定性规则节点和 LLM 节点，它们的分工是有原则的。
凡是规则能写清楚的：阈值判断、资格条款、分支逻辑，一律用代码实现。代码是确定的：同一份输入，一万次运行得到同一个答案，并且每一次分支选择都有据可查。LLM 只出现在决策树真正需要它的位置：处理歧义、理解 messy 的非结构化文档、从手写扫描件里提取字段、判断一封自由格式来信的主旨。这些是确定性代码 genuinely 做不好的事情，也正是大模型真正擅长的事情。
这个分工原则带来一个常被低估的好处：错误的可归因性。naive 方案里端到端出错时，你无法定位是抽取错了、规则理解错了还是查询错了；而在决策树上，每个节点的输入输出都是明确的，错误天然落在某个具体节点上，可以被单独复现、单独修复、单独回归测试。
沿着这棵决策树，整套方法论可以总结为五根支柱：
其一，把规则手册代码化为决策树。与用户并肩工作，把规则翻译成版本化、可测试的决策逻辑，变更与政策专家共同评审。
其二，只在决策树需要的地方使用 LLM。把模型用在歧义和脏文档上，而不是用在确定性代码能处理的规则上。
其三，使用受治理的语义层。把业务上下文和数据统一进一致的词汇表。
其四，为每个任务选择对的模型。使用若干有边界的模型，每个任务由专门的模型承担，并在每一层做测试。
其五，把动作暂存起来供人工审核。每一个写回操作都经过人确认，既保证准确性，也形成自我改进的闭环。这五根支柱共同运行在一个持久的智能体运行时之上。
四、受控语义层：让智能体和人看到同一个世界
五根支柱里最容易被忽视、却可能最关键的一根，是受治理的语义层。
它解决的问题是：在一个既有智能体、又有人类审核者的系统里，双方必须共享同一个数据世界。纳税人不是一个数据库表的主键，申报表不是一堆 JSON 字段，往来函件不是文件服务器上的路径，它们是业务对象，有自己的属性、关系和生命周期。语义层把底层杂乱的数据源统一成这套一致的业务词汇表，智能体的每一个判断、每一次工具调用，都发生在这层受治理的抽象之上，而不是直接怼在原始库表上。
这件事的价值在"人工审核"环节才真正显现。试想一下，如果审核人员看到的界面和智能体"看到"的数据不是同一个东西。智能体基于一堆原始字段做了判断，而审核者面对的是另一套业务视图，那么审核就退化成走过场：人根本无法有效地复核机器的推理依据。只有当双方共享同一套语义对象时，"审核"才真正意味着"验证机器做了什么"，而不是"重新做一遍"。
与语义层配套的是模型策略上的另一个取舍：不为所有任务使用同一个模型。Palantir 称之为 k-LLM 方法：一个任务簇由若干有边界（bounded）的模型组成，每个任务分配给专门的、受约束的模型：抽取手写体用一个模型，判断信件主旨用另一个模型，生成函件草稿再用一个。每个模型的职责被收窄到它可以被充分测试的范围内。
这带来两个直接收益。一是成本与性能的最优化：简单任务不需要旗舰模型，困难任务值得更强的模型，各得其所。二是避免供应商锁定：当新模型出现时，可以只替换某一个任务节点，而不用重做整个系统。架构把"模型"从一神教变成了可替换的零部件。
五、三层测试：像对待代码一样对待智能体
"确定性设计"最实在的部分，是它把智能体系统拉回了软件工程熟悉的领域：分层测试。
第一层，确定性节点的单元测试。决策树上的规则节点是普通代码，享受普通代码的一切待遇：单元测试、边界用例、回归套件。规则手册里的每一条"如果 AGI 变化超过 X 且申报年度早于 Y，则适用条款 Z"都变成一个可测试函数，政策变更就是一次代码变更加一次测试更新。
第二层，LLM 节点的评估。每个模型节点都有自己的评估集，从真实案件（脱敏后）构建的黄金数据集，持续度量这个节点在其收窄职责上的准确率。模型升级、提示词调整之后，评估集立刻告诉你这个节点变好了还是变坏了。评估不再是"凭感觉"，而是和单元测试一样进入流水线的关卡。
第三层，端到端集成测试。整棵决策树从材料包进入到处置动作暂存，全链路在测试环境重放，验证节点之间的契约没有破裂、整体行为符合预期。
这三层合起来回答了一个困扰所有智能体项目的问题：你怎么知道它还在正常工作？ naive 方案的答案是"不知道，直到用户在社交平台上挂出来"；而这套架构的答案是和任何严肃软件系统一样的，每一次变更都被测试金字塔兜住，区别只是金字塔里为概率性组件增加了评估这一新物种。
六、人在回路：不是被取代，而是被加速
整套架构的最后一环，也是立场最鲜明的一环：每一个写回生产系统的动作，都必须经过人工审核。
注意这里的措辞不是"关键动作"或"高风险动作"，而是每一个写回动作。智能体的终点不是"执行"，而是"暂存"，它把证据汇总好、把建议处置准备好，呈现在税务审查员面前，由人点击确认后才真正生效。机器做足了所有的准备工作，人保留最终的决定权。
这个设计初看是妥协，实则是整个系统最聪明的部分，因为它同时解决了三个问题。
其一，信任：机构敢上线一个"人始终握有否决权"的系统，这是全自动化方案永远拿不到的政治资本。
其二，准确性：最后一道防线由最了解业务的人把守，机器的错误止于审核界面，不会变成纳税人的麻烦。
其三，也是最深的考量：每一次人工更正都会回流成为新的评估案例。审核者改掉一个错误抽取、否决一个错误分支，这些更正被系统忠实地记录下来，汇入黄金数据集，成为下一轮评估和模型改进的养料。人的每一次纠正都在让系统变得更好，这是一个自我改进的复利回路。
于是人的角色被重新定义了。naive 叙事里，自动化的终点是"人据称被取代"；而在这条路径上，结果是办案人员从一份复杂申报一两小时的手工流程，被加速到十分钟的审核确认，人没有被移出回路，而是被提升到了回路中价值最高的位置。
七、确定性红利
把这一切合起来看，回报是三个维度的。
准确性：多模型分工让每个任务用上成本和能力都合适的模型，同时避免了供应商锁定。
确定性：同样的输入产生同样的输出，行为可预测，信任因此有了地基。
可追溯性：全量日志记录每一个决策的依据，操作可逆，历史决策反哺未来决策。这既是审计的要求，也是系统自我改进的原料。
最后，用一张对比表收束整个讨论，同样一个 IRS 场景，naive build 与确定性设计在八个维度上的分野：
规则：一个用提示词转述，一个代码化、版本化、确定执行。
模型：一个模型包打天下，一个 k-LLM 按需分工。
同一份输入跑两次：一个给出不同答案，一个给出相同答案且附带完整血缘。
遗留系统：一个靠即兴工具调用，一个靠受管连接器和明确的数据模型。
写回：一个直接写生产环境，一个经人工审核后点击提交。
质量：一个凭感觉，一个对黄金数据集做评估。
失败处理：一个重试加祈祷，一个检查点、重试与恢复机制。
人的角色：一个"据称被取代"，一个从两小时加速到十分钟。
这张表值得多看一遍，因为它揭示了一个反直觉的结论：限制，是这套系统能力的来源。 限制 LLM 只出现在它真正擅长的地方，换来了规则执行的确定性；限制智能体不能直接写生产，换来了机构的信任和持续变好的评估飞轮；限制每个模型只干一件窄事，换来了每一层都可测试。所谓"确定性设计"，本质上是承认概率模型的能力边界，然后围绕这个边界做诚实的工程。
对于正在把智能体推向生产的团队，无论是否在政府场景，这都是一份值得放在案头的参考架构：别问模型还能做什么，先问系统的哪一部分必须永远正确。
参考资料：Palantir: Deterministic by Design | Prodacity 2026（https://www.youtube.com/watch?v=Bp516S8xkPE）。
提醒：请朋友们将“智见AI视界”加“星标”，觉得写得好就点击右下角“拇指”和“收藏”哦，不然会慢慢收不到文章推送~
关联阅读