Evan Kormos：用证据逐步降低智能体监督

我有二十年软件交付和开发经验，其中十五年在企业金融服务领域。在 Coinbase，我关注如何在受政策约束的工作流中建立对智能体的信任。

政策规定组织希望工作如何进行，包括风险和合规要求。我把它视为组织意图：用“必须”“可以”“应该”等词设定边界。

书面政策与运行中的系统是两回事。政策在特定时间修订，产品和运营却持续变化；实现仍须处于适用规则之内。

智能体横跨人员、流程和技术三个类别：它与人协作，执行部分流程，也使用技术工具。今天我重点讨论它与流程的交点。

先画出工作流。例如，开户前可能需要核验身份，变更上线前可能需要批准。依赖关系和关卡应明确表达。

有向无环图（DAG）表示向前推进的步骤和依赖。相互独立的审核可以并行，再汇合结果，同时保留必要检查。

Kormos 以 Apache Airflow 为定义依赖关系的工具例子，并列举贷款、代币上线和软件交付流程。

在工作流的一个节点内部，工作可以反复迭代。代码审查中，变更接受检查、根据反馈修改，再重复这一循环，直到达到验收标准。

有环图可以描述这种内部循环；LangGraph 等工具可以帮助管理状态。这个例子经过简化，真实工作流可能复杂得多。

外层流程提供政策边界，人员和智能体则可在具体步骤内协作。两层分别回答什么可以继续，以及工作如何改进。

除了正常路径，还要设计异常流程。被取消的变更或未通过的安全检查应当可见并得到适当处理，而不是悄悄卡住。

加快一个步骤会改变其他步骤的负载。例如代码审查变快后，瓶颈可能转移到设计或安全扫描，因此团队需要观察整个流程的指标。

工作并行化后，运营可见性尤其重要。应在需要的环节增加能力，同时保留流程要求的控制。

AI 的输入和输出具有变化性。Kormos 认为更好的上下文有助于提高输出质量和成本效率，但具体收益取决于任务和实现。

提供上下文的一种方法，是告诉智能体它在整个 DAG 中的位置和状态，让它理解自己的工作与上下游流程的关系。

检查环节决定工作是否足够好、能否继续。更多迭代不会自动带来更好结果：循环的可信程度取决于评估它的检查。

传统软件通过测试建立信心。智能体输出具有概率性，同一个请求可能有多个可接受答案，不能只依赖唯一的精确匹配。

应建立有代表性的评估数据集，与领域专家定义质量标准，并对输出反复评估。用统计方式观察结果，而不是凭一次回答的印象判断。

执行轨迹展示运行过程中发生了什么，与评估互相补充。二者共同为智能体在流程中的表现提供证据。

对每个节点，可以问：工作能否按政策检查、循环能否设限、过程能否追踪、失败时能否交还人处理？满足这些条件的节点可能更适合自动化。

并非每个决策都要交给智能体。Kormos 认为，即使流程其他部分有智能体协助，涉及政策的重大决策也可以继续由人主导。

先从人工监督开始：人员核验输出，领域专家定义质量标准，团队完善评估数据集和检查机制。

如果实测表现达到适当的政策阈值，再转向抽样。人员检查一部分结果，同时用系统评估和轨迹监测未人工查看的输出。

只有进一步证据支持时，人员才主要处理异常。他们仍需更新数据集、检查和质量标准；减少逐项审查并不意味着取消责任。

设计原则是让外层流程受控、可预测，同时允许步骤内部在边界内适应。评估提供的是证据，而不是无条件保证。

质量是团队共同的工作：随着智能体改变工作流，工程师、领域专家和流程负责人需要把产品反馈带入评估与交付流程。