主题
落地路线与关键取舍
一句话：企业 Agent 平台的落地不是一次性交付，而是按风险从低到高、按确定性从高到低分阶段推进；每一阶段都要有可验收的闭环和可回退的边界，否则平台会在“什么都能演示、什么都不稳定”之间反复。
为什么需要
平台项目最常见的两种失败方式相反：一次做大——同时上多 Agent、自主规划、双闭环、全场景，结果每个模块都停在 70%，没有一条链路可以稳定跑生产，团队在集成阶段耗尽耐心；一直试点——每个业务线做一个小 Demo，都能演示，但权限、审计、成本、恢复没人管，永远无法从“试点”变成“基础设施”。两者缺的是同一条东西：阶段划分与验收标准。平台不是功能清单，而是一组能力按依赖顺序成熟；跳过前置阶段，后面的能力建在沙箱里。
核心机制
推进顺序：四个“先与后”
| 顺序 | 先 | 后 | 原因 |
|---|---|---|---|
| 场景 | 内部科技场景 | 外部业务场景 | 用户可控、容错高、反馈快 |
| 范式 | 工作流型 | 自主型 / 多 Agent | 确定性高，先证明链路 |
| 部署 | 内网闭环 | 互联网闭环 | 数据边界简单，合规压力小 |
| 范围 | 单 Agent | 多 Agent 协作 | 先验证单点，再引入协调复杂度 |
顺序不是保守，而是把不可逆风险往后放。工作流型先跑通，能验证模型、工具、状态、审计四件事；这四件不稳，多 Agent 只会把故障放大。
P0–P3：排期优先级
| 优先级 | 做什么 | 进入条件 | 退出门槛 |
|---|---|---|---|
| P0 | 内部低合规单场景 + 平台基础：身份、审计、模型网关、状态、Trace | 场景步骤可枚举、失败可回退 | 端到端成功率达标，失败可查 |
| P1 | 内部多场景复用：工具、Skill、知识、预算与降级 | P0 连续稳定运行 | 新场景接入不全靠平台团队 |
| P2 | 外部低风险场景 + 双闭环 | P1 资产可复用、审计完整 | 环境切换不改业务代码 |
| P3 | 高合规、强隔离、多 Agent 协作 | P2 的权限与隔离经演练 | 越权被阻断，故障可恢复 |
P0–P3 是排期优先级，不是又一套能力模型；五个阶段回答“能力成熟到哪”，P0–P3 回答“先排谁”。顺序上明确：先用内部低合规场景把平台基础跑通，再谈外部流量和高合规；反过来先接外部高敏场景，通常会把平台团队拖进无休止的合规评审，基础能力反而没人做。
五个阶段
边上的验收条件是阶段之间唯一的通行证，不是建议：前一阶段的验收项不达标就进入下一阶段，等于把未验证的假设叠到下一层上，后面的问题会同时指向三个版本。
| 阶段 | 目标 | 关键交付 | 验收 |
|---|---|---|---|
| 1 基础闭环 | 单 Agent + 工作流跑通 | 模型推理、沙箱、记忆、工具网关、追踪 | 一个场景端到端可用，失败可查 |
| 2 多 Agent 与容错 | 协作与恢复 | 主管编排、会话路由、Skill 市场、熔断与幂等 | 子任务失败可恢复，重复请求不重复执行 |
| 3 长任务与可观测 | 跑得久、看得清 | 异步执行、检查点、全链路追踪、自动评审 | 任务可暂停/恢复/取消，步骤可追踪 |
| 4 合规与双闭环 | 边界与审计 | 三层治理、不可篡改审计、权限体系、第二环境 | 越权被阻断，环境切换不改业务代码 |
| 5 优化与规模化 | 成本与复制 | 冷启动优化、成本归集、场景复制、自愈 | 单位任务成本下降，新场景接入周期缩短 |
每个阶段都要有一条“能对外演示、也能对内验收”的链路。只有演示没有验收，阶段会虚；只有验收没有演示，业务方看不到价值，下一阶段拿不到资源。
12 个业务场景 → 范式匹配
| 范式 | 四个业务场景 | 匹配理由 |
|---|---|---|
| 工作流型 | 合规检查、发布审查、故障处置、报表生成 | 步骤可预先枚举，结果可校验，审计要求高 |
| 主管编排型 | 多专家调查、投研分析、客服升级、跨系统排障 | 任务能分解，但子任务边界需要上层裁决 |
| 自主型 | 探索性数据分析、信息不完整调查、长尾研究、开放域诊断 | 目标清楚但路径未知，允许试错与回退 |
12 类交互场景的清单与叠加问题见 01-项目总览与定位；这里只回答业务场景该选哪种范式。选型顺序仍然是先合规与可审计，再步骤可枚举性，最后才是模型能力。
ModelOps 闭环
| 闸门 | 看什么指标 | 谁能回滚 / 叫停 |
|---|---|---|
| 注册 | 版本号、基座与适配器、训练数据、血缘是否完整 | 训练负责人撤回，平台管理员标记无效 |
| 评测准入 | 评测集分数对基线、安全红线是否 0 违例 | 算法负责人打回，安全负责人一票否决 |
| 灰度 | 5%/20%/50% 各档的错误率、P95、Judge 分、成本 | 发布负责人或值班直接回滚上一版 |
| 上线 | 全量错误率、SLO、单位任务成本、投诉率 | 值班回滚，发布委员会事后复盘 |
| 计费 | 单价版本、租户账单、预算偏差 | 平台运营调价/停用，财务冻结结算 |
| 回滚 | 回滚耗时、旧版可用性、影响面 | 值班可一键回滚，不需要委员会 |
| 退役 | 迁移完成率、调用量、残留依赖 | 模型 owner 申请，平台管理员下线 |
闭环主干是 注册 → 评测准入 → 灰度 → 上线 → 计费 → 回滚 → 退役。注册给模型身份，评测准入决定能不能碰流量，灰度决定放多少，上线后才谈计费和 SLO，回滚是随时可用的刹车，退役回收显存和依赖。每道闸门只问两件事：看什么指标、谁有权叫停；没有这两样，闸门就只是流程装饰。
各阶段的重点
阶段 1 不要做多 Agent，也不要做自主规划。选一个步骤明确、结果可验证、失败可回滚的场景，例如“告警 → 证据收集 → 根因候选 → 处置建议 → 人工确认”，同时验证模型、工具网关、状态外置和证据链。验收写成可检查的条件：任务成功率、P95 延迟、终止原因分布、人工接管率、审计完整率。
阶段 2 的故障从“单点失败”变成“链路失败”。子任务超时有限次重试，仍失败则重规划或降级为只读建议；结果冲突保留来源与置信度，由上层裁决，不静默覆盖；重复投递用幂等键加消费端去重；循环调用用调用图深度限制和重复签名检测；父 Agent 崩溃靠任务图持久化和检查点继续。容错不是“都加重试”：参数错误、权限拒绝、业务校验失败重试只会放大问题，只有超时、限流、临时不可用才值得退避重试。
阶段 3 的长任务门槛不是“能跑一小时”，而是“能安全地跑一小时”：步骤边界可暂停、恢复时清理未提交的工具中间态、取消要传播到子任务和工具调用、每步有耗时/token/结果摘要/错误分类、成本能按任务和租户归集。阶段 4 把规则变成系统能力：默认拒绝出站、不可逆操作强制人工、审计只追加、数据分级不可降级；双闭环靠配置驱动，切换环境只换基础设施适配。阶段 5 的标志不是场景数量，而是新场景的边际成本下降：工具和技能可复用、评测与门禁可复用、成本可归集、故障有 Runbook 和自愈。
建与买的取舍
| 能力 | 建议自建 | 建议采购 / 开源 |
|---|---|---|
| 身份、权限、审计 | 与组织体系强绑定 | 通用 SSO / 审计可以采购 |
| 模型推理 | 数据不能出内网时 | 非敏感场景用云 API |
| 沙箱 | 高隔离、强合规场景 | 中低风险用托管沙箱 |
| 编排与运行态 | 核心差异在调度与治理 | 通用图编排可用开源 |
| 可观测 | 需要跨层 trace 与业务指标 | 通用追踪可采购 |
判断标准是“这是不是我们的差异化能力”。身份、权限、调度和业务知识通常必须自建；模型、向量库、追踪有成熟方案，自建只在数据边界或成本模型不允许时才有意义。
实战场景
场景一：第一天给全团队上重流程，十周后只剩两条能验收的链路
现象：某平台团队在同一季度排满 P0–P3，12 个业务场景同时接入，所有业务方走同一套流程：接入登记、安全评审、评测准入、预算配置。第十周复盘（周数只参考，约束是验收标准）：只有 2 条链路达到阶段 1 的“端到端可用、失败可查”，其余停在能演示不能验收；平台团队 60% 工时在替业务方填表，3 个团队绕开平台自建脚本。以上规模数字为经验值，需校准。
排查：先分清是资源、模型还是流程问题。资源不是——容量前置做过，GPU、向量库、队列都在余量内；模型不是——进入 P0 的那条运维链路，P95 延迟、终止原因分布、人工接管率都达标。卡点两处，都在流程：阶段门禁被“并行推进”顶掉了，P0 退出条件要连续稳定运行，12 条链路同时推进时没有任何一条连续稳定；ModelOps 闸门退化成审批，注册与评测准入只看“材料齐不齐”，没落实“看什么指标、谁能回滚/叫停”，打回后没有负责人也没有时限。
对症做法：退回“一个业务方一条链路”。P0 只保留运维告警处置（工作流型、步骤可枚举、失败可回退），其余场景按进入条件排队、不进当期路线图。一页路线图收敛到六列，每行两个 owner：
text
优先级 | 阶段 | 场景 | 交付 | 验收指标 | 回退方式
P0 | 1 | 运维告警处置 | 单 Agent + 工具网关 + 审计 | 成功率 / P95 / 终止原因 / 审计完整率 | 回退人工流程
P1 | 2 | 多专家调查 | 主管编排 + 幂等 + 熔断 | 恢复率 / 重复执行率 | 降级单 Agent闸门瘦身成三字段：指标、有权叫停的人、响应时限，超时视为放行并留痕；预算与降级由平台团队代配，业务方只交任务样本和验收人。重流程等 P1 的“新场景接入不全靠平台团队”成立以后再上。
复盘要点：“一次做大”失败的原因不是功能不够，是验收并行度超出承载力。不这样做会：阶段 2 的多 Agent 协作继续建在没验证过的状态和审计上，故障从单点失败变成链路失败。
场景二：买回来的平台“有审计、有空间”，接第二个业务方时被迫重做
现象：采购的编排平台功能清单里“日志查询”“多空间隔离”都有，据此判定身份、权限、审计可以不自建。接第二个业务方（风控，内部场景但有合规边界）时提出三条：按部门组织树分级、按自然人溯源、审计只追加不可篡改。三条全不满足——空间在同一租户内共享数据，审计表能 UPDATE，身份对接不了内网目录。接入延期 9 周，三条重做加上首个场景存量数据迁移，投入 2 人 × 14 周。延期与人力为经验值，需校准。
排查：分清是集成问题还是判据用错。集成可以做适配层，组织树映射两周就能接上；真正的问题在判据用错——把“有没有这个功能”当成“这能不能与组织体系强绑定”。建与买那张表的结论不变：身份、权限、审计建议自建的原因是与组织体系强绑定，可采购的是通用 SSO 和通用审计；编排与运行态只在“核心差异不在调度与治理”时才可采购或开源。反向的坑同一条：自建不等于可控，没有 owner、版本和演练的自建系统风险不低于采购，买回来的系统同理。
对症做法：采购结论用“第二个业务方接入演练”验收，四项都对应退出门槛，不通过就当场缩小采购范围。
| 演练项 | 通过标准 | 不通过的处理 |
|---|---|---|
| 越权访问 | 越权被阻断，且落在不可篡改审计里（P3 退出门槛） | 身份、权限、审计移回自建，采购只保留编排层 |
| 租户与部门记账 | 成本能按租户、场景、技能归集（阶段 5） | 自建记账侧或换供应商，不先上线再补 |
| 环境切换 | 内网与互联网闭环切换不改业务代码（P2 退出门槛） | 基础设施适配层自建，替换路径写进合同 |
| 新场景接入 | 业务方自助接入，平台团队不写胶水代码（P1 退出门槛） | 判定该平台只是运行时，不作为治理底座 |
复盘要点：买与建的分界能回答“该不该自建”，第二个业务方才回答“买回来的够不够”。合同里要写明审计模型、租户模型和替换路径；不这样做会：第一个场景跑得越稳，后面的迁移越贵。
场景三：“先做哪个”交给业务方拍脑袋，三个月换不到一个可量化收益
现象：业务方选“开放域诊断”（自主型）作为首个场景，理由是业务价值最大。三个月后拿不出收益结论：没有基线，成功率无从对比，验收会上只放了 12 条用例的录屏；投入 3 人 × 13 周，期间运维告警处置这条本可枚举的链路没人接。投入与时长为经验值，需校准。
排查：三种成因分开验。模型能力不足？把同一批用例的手工作答准确率拉出来对比，模型分数并不低，排除。场景选错？按“先合规与可审计，再步骤可枚举性，最后才是模型能力”的选型顺序打分，步骤可枚举性与结果可校验性两项不过。根因在第三层——验收缺失：结果不可校验时，阶段 1 的五项验收（任务成功率、P95 延迟、终止原因分布、人工接管率、审计完整率）有三项算不出来，做多久都到不了退出门槛。自主型讲的是“目标清楚但路径未知，允许试错与回退”，而这条链路当时连试错成本和接管路径都没设。
对症做法：准入打分表前置，任何一列写不出数值就不排 P0。
| 准入项 | P0 通过标准 | 不满足时的处理 |
|---|---|---|
| 步骤可枚举 | 能列成固定链路，如“告警 → 证据收集 → 根因候选 → 处置建议 → 人工确认” | 先做工作流型壳，把可枚举部分固化 |
| 结果可校验 | 有可判对错的历史样本，按 09-生产治理与降级 的采样口径取 200–500 条真实任务建基线 | 先补标注和基线，期间不上生产 |
| 失败可回退 | 每步失败有明确退路（转人工 / 只读建议） | 判定不平台化，直接做应用 |
| 收益可量化 | 单位任务成本、人工节省工时有当期数值 | 不占平台排期，业务方自建 |
同时给这条链路设死退出条件：连续两个复盘周期低使用或成本高于收益就下线，回收 GPU 和依赖。
复盘要点：选场景的判据不是业务方最想做什么，而是哪条链路能同时满足阶段验收和退出门槛。一次性、低频、强探索的场景直接做应用更便宜，硬塞进平台会把“一次做大”换成“一直试点”。
最小上手
给出一页路线图，至少包含六列：
text
优先级 | 阶段 | 场景 | 交付 | 验收指标 | 回退方式
P0 | 1 | 运维告警处置 | 单 Agent + 工具网关 + 审计 | 成功率 / P95 / 审计完整率 | 回退人工流程
P1 | 2 | 多专家调查 | 主管编排 + 幂等 + 熔断 | 恢复率 / 重复执行率 | 降级单 Agent
P2 | 3 | 长任务报告 | 检查点 + 追踪 + 评审 | 恢复成功率 / 步骤可追踪率 | 取消并转人工每一行都要有业务 owner 和技术 owner。没有 owner 的阶段，延期时没人推动，出问题时没人认领。
生产动作
- 阶段门禁：上一阶段的验收指标不达标，不进入下一阶段；不要把“并行推进”当成加速。
- 容量前置：每阶段开始前估算 GPU、存储、向量库和队列容量，避免上线后才发现瓶颈。
- 成本归集：从第一天按租户、场景、技能记账，后期才有优化依据；预算与降级见 09-生产治理与降级。
- 风险清单：模型不可用、工具超时、知识错误、权限越界、成本超支、供应商变更，各有应对和演练。
- 组织配套与退出机制：明确平台、业务、安全团队的职责；场景长期低使用、成本高于收益或风险不可控时，要能下线并回收资源。
边界
- 阶段不是固定周数：团队规模、合规要求和存量系统差异很大，周数只能参考，验收标准才是约束。
- 不是所有场景都值得平台化：一次性、低频、强探索的场景，直接做应用更便宜。
- 自建不等于可控：没有 owner、版本和演练的自建系统，风险不低于采购。
- 双闭环不是越早越好：第二套环境的运维成本很高，先确认第一套稳定再复制。
- 规模化会暴露组织问题：平台越成功，越需要清晰的接入流程和配额制度，否则会变成新的审批瓶颈。
讲清楚
企业 Agent 平台的落地顺序是“先内部后外部、先工作流后自主、先单 Agent 后多 Agent、先内网后双闭环”。P0–P3 用来排期：先用内部低合规场景把身份、审计、网关、状态和 Trace 跑通，再扩内部场景、外部低风险和高合规多 Agent。五个阶段分别验证基础闭环、协作容错、长任务可观测、合规双闭环和规模化；每阶段都要有可演示的链路、可验收的指标和可回退的方案。12 个业务场景按“工作流 / 主管编排 / 自主”三线匹配，ModelOps 用注册、评测准入、灰度、上线、计费、回滚、退役七道闸门把模型变成可运营资产。建与买的分界是“是否差异化能力”：身份、权限、调度和业务知识自建，模型、向量库、追踪优先用成熟方案。平台能否规模化，不看做了多少场景，而看新场景的边际成本是否下降。
适用：2026 年企业级 Agent 平台落地实践 | 初稿 2026-10