Coinbase工程师：如何判断AI智能体能否无人值守

AI智能体能不能真正接管一条业务流程，不是靠感觉拍板，而是有一套可以验证的判断标准。Coinbase 工程师 Evan Kormos 在 AI Engineer 的分享中，给出了一套从流程图到评估体系、再到逐步放权的完整方法论。

从政策出发，把「意图」写成规则

Kormos 的起点很有意思：不是模型，不是工具，而是政策（policy）。他把政策称为「组织最初的意图」，或者「最初的 system prompt」——它规定了工作应当如何完成，尤其是在风险与合规层面。写法上要用 must、may、should 这类明确的规范动词。

关键动作是把**构建态（build state）和运行态（run state）**分开。政策是在某个时间点被定义或修改的，而系统一直在运行、一直在变化。两者分离之后，政策的变更才有一个类似「编译」的时刻，不会和运行时的快速演进搅在一起。

在经典的人、流程、技术三元模型里，Kormos 把智能体看作横切这三者的运营层：它和人协作、自己执行流程中的一部分、本身又由技术构成。而这次分享的焦点，落在「智能体与流程的交汇处」——给它什么工作、划什么边界、如何建立对其产出的信任。

DAG 与 DCG：外圈确定，内圈自适应

流程的基本形态是一张图。业务期望工作沿着特定方向、经过一道道关卡流动，比如变更要审批后才能上线，客户要完成验证后账户才能开立。这种不回环的流程，用一个**有向无环图（DAG）**就能表达步骤与依赖关系。开源世界里 Apache Airflow 就是用 Python 代码把流程及其依赖表达为 DAG 的典型例子。

DAG 示意图

Kormos 举了几个用 DAG 表达政策驱动流程的场景：商业贷款、在特定区域上币、以及受监管的软件交付。软件交付是当下智能体采用率最高的领域，也是他重点展开的例子。

有意思的是，DAG 里的每一个节点内部，其实是一个循环。以代码评审节点为例：执行若干步骤，判断工作是否「足够好」，够好就放行到下一步，不够好就吸收反馈、迭代重来。这构成了一个有向循环图（DCG），开源工具 LangChain、LangGraph 可以帮忙管理 DCG 的状态。

这就是整套方法的核心配方——外面保持确定性，里面保持自适应。外圈的流程、关卡、政策边界是稳定的；内圈的「生成—检查—迭代」允许智能体反复尝试。

DAG（有向无环图）是描述流程步骤与依赖关系的经典数据结构，其“无环”特性保证工作只能单向推进、不会出现循环依赖，因此天然适合表达带有审批关卡的业务流程。DCG（有向循环图）则允许节点之间存在回路，用以刻画“生成—检查—迭代”这类需要反复尝试的环节。两者结合的关键在于嵌套关系：DAG 的每个节点内部封装一个 DCG 循环，外层保证流程的确定性与可审计性，内层容纳智能体的自适应行为。LangGraph 等工具通过状态机与检查点机制管理 DCG 的循环状态，使迭代过程可暂停、可恢复、可追踪。

例外流与瓶颈：加智能体后最容易忽略的两件事

流程不会总按计划走，所以必须设计例外流（exception flow）。原则有两条：不让工作卡住，也不为每一个边缘情况预先设计。例外流应当被监控——如果交付的代码被取消、没通过安全标准，这类事件恰恰是你最需要知道的。

例外流处理

另一个更隐蔽的问题是流量迁移。智能体加入后，某个环节变快，下游的压力会立刻显现：代码评审快了，构建就得跟上；构建快了，安全扫描就成了新瓶颈。Kormos 的判断是，随着流程被并行化和加速，瓶颈会不断转移，因此流程整体的可观测性和度量，比工作流工具的编写本身更重要。

循环的可信度，取决于「检查」

为什么这件事难？Kormos 点出 AI 工程的一个基本挑战：输入输出的高度可变性。他相信更高质量的输入能以更低的算力成本换来更好的输出，而这又回到「可信上下文」的构建上。

构建可信上下文

他给了一个具体做法：把 DAG 的状态注入智能体，让它知道自己处在全局的哪个位置，从而具备更长的时间视野——这也反过来要求优化这个循环的成本与效率。

但真正的关键在「检查」这一步。定义什么算「好」是最难的部分，同时还要有可靠的评估方式，否则更多的通过次数并不等于更好的结果。用他的话说：循环的可信度，只等于检查的可信度。

用评估体系替代「对模型的感觉」

传统软件用单元测试、测试用例这些系统性机制建立质量信心，代码变更时能发现是否破坏了别的东西。但智能体是概率性的：同一个请求可能产生不同答案，多个答案可能都合格，因此逐字比对输出远远不够。

Kormos 给出的替代方案是：构建有代表性的数据集，明确定义「好」的标准，反复成系列地运行评估，把输出当作统计对象来看，而不是做单次对比。再叠加 evals 与 traces（运行时日志），就形成了一套可以补充传统软件测试的置信机制。这意味着对智能体质量的判断从「感觉」变成了「研究和统计数据」。

在 AI 工程语境中，evals（评估）指用一组有代表性的输入样本系统性地衡量模型输出质量的方法，区别于传统单元测试的确定性断言，evals 关注的是统计意义上的通过率与分布。traces（追踪）则记录智能体一次完整运行中的每一步调用、输入输出与中间状态，是事后归因和发现失败模式的原始材料。二者互补：evals 回答“整体质量是否达标”，traces 回答“某次失败究竟发生在哪一步”。将 traces 中暴露的典型失败案例回流到 evals 数据集，可以形成持续改进的闭环，这正是用工程手段替代主观感觉建立质量信心的核心机制。

哪些节点可以交给智能体？

回到贷款的例子：KYC、财务审核可以并行，信用备忘录、风险审查、文档、决策按序推进。对 DAG 中的每个节点，都要问一组问题：

能否容易地对照政策进行检查？
能否在有限的循环内运行？
能否被追踪（trace）？
出问题时能否回退到人工？

如果这些问题的答案都是「是」，这个节点就相对适合自动化。Kormos 强调，讨论的重点不是「要不要用 AI」，而是「是否期望 AI 在某一点上接管决策」。像最终决策这类环节，仍然应当由人来驱动。

贷款流程中的并行与串行节点

“能否回退到人工”这一条实质上是 human-in-the-loop（人在回路）设计的落地要求。在智能体系统中，回退能力意味着节点需要保留完整的中间状态与决策依据，使得人工接管时能够从断点继续而非从头重来。这通常依赖检查点（checkpoint）机制与可持久化的运行状态。此外，可回退也隐含了权限边界的设计：智能体的动作应当是可撤销或可覆盖的，尤其是涉及生产环境变更、资金流转等高风险操作时，必须预留人工干预的接口。缺乏回退设计的自动化节点，一旦出错往往代价高昂，因此这一条常被视作节点能否自动化的否决性条件。

逐步放权：从全量监督到处理例外

这套方法最后落在一个分阶段的放权路径上，Kormos 称之为「爬山」：

全量监督：智能体与人工协同，人工逐一验证输出，与领域专家一起打磨数据集、定义「好」的标准，把置信机制搭起来。
抽样检查：当实测置信度达到政策设定的阈值，转为人工只看一部分输出，同时通过 traces 做更系统的评估，确保人工没看到的部分依然达标。
例外处理：越过置信门槛后，人工主要处理流程中的例外，同时仍作为参与者持续完善数据集、保障输出质量。

这条路径的意义在于，无人值守不是一个开关，而是一条有度量、有门槛、可回退的渐进曲线。

几条结论

Kormos 的收尾很凝练：外圈确定性、内圈自适应；用评估与统计建立质量信心，而不是对模型的感觉；质量是团队运动，AI 工程师要负责把来自各方的产品信号转化为构建良好、背后有 MLOps 支撑的应用；智能体在整个运营模型上都会带来加速。

对正在考虑让智能体接管真实业务流程的团队来说，这套框架的价值不在于某个工具选型，而在于它把「能不能信任」拆解成了可以被设计、被度量、被逐步验证的工程问题。