AI功能的核心难题：知道哪里不该用它

支付决策必须精确且可重复，所以在做的产品里，资金逻辑是确定性代码，Agent 只介入那些真正需要主观判断的环节。

现在每一个 AI 演示都是 Agent 包揽一切：指向问题、端到端推理、对着 trace 惊叹。演示效果惊艳。但当你把它放到真实工作流、真实金钱的场景中，它就崩了——因为让演示出彩的那个特质（模型自由裁量）恰恰是你在输出涉及付款时绝不能允许的。

我花了一段时间做了一套采购到付款的产品：供应商发票进来、提取信息、与采购订单匹配、进入审批流程、对账。这是现在所有人都想上 Agent 的场景。所以我确实上了，某种程度上。但真正有意思的决策、最费时间才做对的决策，不是"在哪里加上 Agent"，而是"在哪里拒绝用 Agent"。

规则：支付决策必须精确且可重复

模型是概率分布。同一个问题问两次，可能得到两个答案。当任务模糊时这是优势，但当任务是"这张 $48,200 的发票是否与这笔采购订单匹配"时，这就是缺陷。匹配、审批引擎、对账：这些必须每次都精确、可审计、结果一致。所以它们是纯粹的确定性代码，路径上不放模型。如果审计员问为什么这笔通过了，答案是可读的代码路径，而不是"模型觉得没问题"。

写下来听起来很明显。但这不是现在大多数人的 AI 功能开发方式。默认做法变成了：先上 Agent，确定性部分只在出问题后才去抠出来。我做了相反的事——默认确定性，只在轨迹真正开放的情况下才用 Agent。

Agent 真正派上用场的三个地方

一旦守住这条线，AI 应该出现的地方就变得非常清晰，因为它们恰恰是确定性规则会变得脆弱或者根本无法处理的地方。

读取混乱的供应商 PDF。发票有一千种不同的版式，基于正则和规则的解析器必输。这是真正的模糊场景：视觉模型进、结构化数据出，按 schema 校验。模型做感知，下游拿到结构化数据后全是代码处理。

从组织架构推导审批工作流。过去 onboarding 一个客户，需要驻场工程师读取对方的 HR 系统手工构建审批规则。真正困难的部分是头衔到签字授权的映射：什么角色审批什么、追溯到具体的人、以及标记数据质量问题（已离职的管理者、两个看起来都像 CEO 的人）交由人工处理。这个判断是模糊的，所以交给 Agent。但它输出的是提案而非决策：人工用自然语言审查和修改之后才能生效。

调查被标记的异常。当某张账单触发了规则，必须有人结合非结构化的上下文、备注、历史发票、供应商历史来做出判断。这是阅读和推理混乱证据，正是模型的强项。所以 Agent 做调查并给出建议，但它不行动——人看到建议后做出决定。

注意这三个场景的共同模式：模型对非结构化输入做感知或判断，然后把提案交给确定性代码或人工。它永远不会在结果上执笔。

人工审核是设计原则，不是免责声明

"人工在环"通常是被拧在自主系统上的安全标签。这里它是结构性的——没有人批准就不能发布。Agent 做推导、读取、调查、建议，然后停下。真正的工程难点在于让这个交接做得漂亮：恰好在决策节点向人工展示 Agent 的结论和理由，让审查快速进行，而不是走个过场或者变成瓶颈。

这也是"AI 会取代这个岗位吗"的诚实回答。在涉及金钱的系统中，Agent 去掉的是繁琐工作（读 PDF、起草工作流、分诊异常），把决策权留在负责人手上。这不是我绕过去的限制，这就是产品本身。

这才是真正的技能

prompt 从来不是难点。把模型接到一个任务上是一个周末的事。真正的难点是对系统的判断：哪些部分必须精确，哪些部分真正开放、两者如何交接而不让模糊的那一半越界做出精确一半本该拥有的决策。做错了，你有一个漂亮的演示，但没有任何财务团队会信任它。做对了，AI 就消失在它该在的地方，剩下的都是乏味、可审计、正确的代码——当输出是别人的钱时，这恰恰是你想要的。

如果想看完整闭环——Agent 从 HR 系统推导审批工作流，然后一张真实发票经过它、附有 live trace、在关卡处暂停等待人工——ledgerloop 的案例研究里有，演示是 live 的，源码在 GitHub 上。用 Mastra 构建。

Originally published at dylan.merigaud.com.