艾普AI白皮书：27个工程模式破解Agent生产断层

在企业内部落地 Agent，常见的路径差不多：花三周做出一个能跑通流程的 Demo，评审会上大家鼓掌；半年后它仍在运行，可没人敢让它碰生产数据。

艾普 AI 生产力研究院出品的《企业级 Agent 设计白皮书》共 191 页，想补的正是中间这道断层——Agent 在生产环境稳不稳，关键不在模型有多大，而在你把多少判断搬进了工程结构。

判断不该只靠模型

过去软件的控制流由代码说了算，Agent 则把其中一部分判断交给模型：请求进来，要先分辨是查询、分析还是执行；工具返回结果后，得判断证据够不够；长任务失败时，还要决定继续、重新取证、回滚，还是转交人工。

如果这些判断全由模型用自然语言来表达，程序既没法据此控制执行，也没法恢复任务。报告给出的办法，是把判断落到路由、状态、证据、权限、日志、回滚、评测这七处，整理成五个工程契约。

五个契约里，证据契约最该优先看：RAG 只提供业务资料，员工 ID、批次号、金额这类当前状态要从工具返回值和会话状态里取，两类信息都得核对。

契约要做的，就是把判断从对话挪到接口上。

核心是两条轴，标的是责任，不是技术栈

全书的核心结构由两条轴构成。纵轴是七个认知功能：感知、记忆、推理、行动、反思、协作、治理；横轴是六种执行拓扑：链式对应顺序，路由负责分流，并行是并发，循环是迭代，层级为分层，编排是协调。

两轴一交，得到 42 格。比如记忆配编排，就是进度追踪，需要在多次工具调用之间维护任务台账；推理配路由，则是复杂度路由，要在请求进入主循环前选好路径。光说一句「我们做了 Agent 编排」，讲不清系统承担的是哪一类责任。

空格与模式一样，也是结论——它说明这块还没人跑通。

27 个模式，第一版只上 3 个

坐标有了，更现实的问题是第一版上几个模式。六步法的第二步，对七个认知功能分别打 None、Light、Heavy，得到一条七维能力向量；第六步则要求先用两三个模式，把从输入到验收的最小闭环跑通。

另有一份十问清单，问的都与位置有关：目标存在哪里，资料能否查到原文和版本，金额由哪个系统维护，路由结果是结构化决策还是一段话。好几项答不上来，系统就还停留在原型阶段。

同样是 Agent，起步规模能差出一倍多，差别就在会不会写。

能写，就得先装刹车

执行型这一类共 8 个模式，比多 Agent 协作还多出两个。多出来的分两种：A1 工具调度、A2 规划执行负责动手；M3 进度追踪、G1 审批门、G2 爆炸半径控制负责善后。

报告把这条定成硬规定：凡是带写权限的 Agent，G1、G2 和 X1 都必须进设计评审。模式能不能省，取决于你的 Agent 会不会改变外部状态。

配套的例子是一批 18 人薪酬付款。批准之后，运行时依旧限定单次最多写 20 条、一段运行最多 40 条，不许并发开两个付款批次，创建后为待提交、外部确认前可撤，熔断之后只能读。批准了，不等于权限无限。

批准只是把门打开，门后每一步仍在收窄。

它没讲的，恰恰是我的推荐理由

它的空白也很明显。全书找不到一个失败项目的基线数据，讲模式失效只有定性描述；成本口径则完全没提，token 和人工复核的账根本算不出来。

七个认知功能的案例几乎全落在「补丁债务」上，翻车写得很实在，可惜一段就收了尾，没给出复盘结论。

这些空白反倒标出了它的定位。整本 191 页只出现 3 个百分号，全在同一段，引的是 ACL 2025 一篇论文的 31.9% 和 36.7%，后面还专门补了一句「相对基线提高 51%，不是提高 51 个百分点」。作者愿意把别人论文的提法往回摁，说明他清楚这数字会被读成什么样。

白皮书里没有效果承诺，给的只是检查项、失效方式和验证指标。拿它当评审清单是合适的，拿它当ROI依据就不合适了：按它评审，方案会变严；按它估算能省多少人力，一定会落空。

具体到不同岗位，用法也不一样：负责架构评审的可以把十问清单直接当检查表用，一页纸问下来，对方是原型还是生产系统就清楚了；已经上线一个、正要接第二个的，该盯的是层级委派、扇出聚合和交接链；做选型采购的，则拿它来判断供应商说的东西究竟落在哪个格子里。