260 步流程和 90 天调价一万次：Agent 上岗要多久

lgf228

19人浏览 · 2026-11-04 03:30:40

lgf228 · 2026-11-04 03:30:40 发布

📋 目录

🎬 开场：这期节目的争议在评论区
📊 一、先把硅谷那 90 亿美元摆清楚
🔍 二、260 步：一个客服 Agent 到底在做什么
⏱️ 三、部署周期的三等分，和那个被忽略的成本
👥 四、三类角色，和"部署是一支队伍的工作"
📐 五、标准化与个性化，和 AgentOne 这条路
🧮 六、模型选择服从业务账本：Token 成本怎么进决策
🏗️ 七、领码 SPARK：中国式部署的对应物
✅ 八、可以带走的判断清单

🎬 开场：这期节目的争议在评论区

《硅谷101》第 248 期，嘉宾是阿里巴巴集团副总裁、瓴羊 CEO 朋新宇（花名小芃）。节目时长 1 小时 3 分 54 秒，2026 年 8 月播出。

主持人开场就点出了争议所在：硅谷之前讲过一期 FDE，评论区分成两派。 一派说 AI 真的在帮企业落地，另一派质疑"20 年前就有厂商开发，这是不是换个名字、新瓶装旧酒"。

这期节目就是冲着这个质疑去的。 而朋新宇的回答方式很有意思——他没讲模型，也没讲平台，他讲了两个数字。

数字	出处
一个"催发货"客服 Agent 要跑通 260 步流程	06:33 段落
一个顶级人类投手在 90 天内调价 1 万次	12:30 段落
部署周期：三分之一熟悉岗位、三分之一建模、三分之一在实际使用中调教 AI	36:06 段落

这三个数字把问题从"模型够不够强"拉回到"企业有没有把工作做成可学习、可度量、可验收的系统"。

而这恰恰是本栏目 10 月 12 日发过的《FDE 岗位涨了 5230%》那篇没有覆盖的角度——那篇拆的是岗位市场（5230% 这个数字有多虚、全市场只有 224 个在招岗位）；这篇拆的是部署方法论（一个 Agent 到底怎么才能上岗）。

顺便说明一下这期的背景：硅谷正在往这个方向砸钱。 主持人提到 OpenAI 成立部署公司、Anthropic 拉黑石和高盛做合资公司、微软成立 Microsoft Frontier Company。四个项目加起来约 90 亿美元，集中在 2026 年 5 月到 7 月这八周里。

所以这场讨论的时点很有意思：硅谷用 90 亿美元押注"派人进客户现场"，而中国这边有一个人已经带着团队做了 5 年。

📊 一、先把硅谷那 90 亿美元摆清楚

主持人提到的这几笔，数字和结构都很值得看。因为90 亿这个总数只是四个数的和，而它们背后的结构完全不同。

公司	时间	金额	组织形式	早期客户
Anthropic	2026-05-04	15 亿美元	与 Blackstone、H&F、高盛的合资公司（外部资本）	私募股权持有的企业组合
OpenAI	2026-05-11	40 亿美元以上	独立部署公司，TPG 领投，估值超 40 亿；收购 Tomoro 带来约 150 名 FDE	复杂业务企业
AWS	2026-06-30	10 亿美元	内部投入，无外部投资人	Allen Institute、Cox Automotive、NBA、NFL、Ricoh、西南航空
Microsoft	2026-07-02	25 亿美元	内部投入，约 6000 人	LSEG、联合利华、蓝多湖乳业、埃森哲
合计	8 周内	约 90 亿美元	两家合资 + 两家成本中心	—

第二列和第三列的组合，是这张表最关键的信息。

为什么 Anthropic 要拉私募股权进来？ 因为私募股权公司手里有几百家需要 AI 部署的投资组合企业——它们既有资本，也有权力强制推行采用。 这等于给 Anthropic 了一条通往集中客户群的专属渠道，不用从零建一支 FDE 队伍。

各合伙人承诺约 3 亿美元，Anthropic 自己出约 3 亿。

而 AWS 和微软是纯内部投入。 这两种选择的区别在于：

结构	它在赌什么	风险
合资公司（有外部资本）	企业 AI 实施是一门可持续收费的服务生意	依赖 PE 交易流；PE 推动旗下公司采用时可能存在利益冲突
内部投入（无外部资本）	这是分发策略——让更多工作负载跑在自己的云上	变成成本中心而非利润中心；微软的 Frontier 客户拿到的本质是"把微软的路线图装进你的架构"

AWS 的打法细节值得看： 5-6 人一组，约 45 天一个交付周期，按结果固定定价而非按小时计费——这直接挑战了咨询行业的经济模型。它的目标写得很直白：不是让客户长期依赖外部团队，而是项目结束后客户具备独立运行能力。

1.1 岗位数据：溢价确实存在，但要看来源

主持人引用的 OpenAI 数据：旧金山 FDE 岗位要求最高 50% 出差时间，年薪 16.2 万到 28 万美元并提供股权。

这个数字在招聘市场上可以交叉验证。 第三方汇总的 FDE 岗位索引（2026 年 8 月快照）里：

公司	岗位	薪资区间
OpenAI	Forward Deployed Engineer – SF	16.2 万~28 万美元
OpenAI	FDE – Semiconductor	16.2 万~30.2 万美元
OpenAI	FDE, Life Sciences – SF	19.8 万~33.5 万美元
Scale AI	FDE, GenAI	17.94 万~22.425 万美元
Palantir	FDSE（纽约）	13.5 万~20 万美元
Striim	FDE（美国远程）	20.5 万~22 万美元

注意一个细节：同一家公司不同岗位的区间差异很大（OpenAI 的 Life Sciences 岗比 SF 通用岗高 3.6 万起）。这说明薪资不是按"岗位名"定的，而是按行业场景的稀缺度定的。

中国这边，朋新宇的回应是：

「如果换个名字就能够去工资升级，这个不符合企业逻辑，不符合市场逻辑。」

他把这个溢价归因到稀缺，并把稀缺拆成三样东西：AI 的锐度、行业的深度、数据的宽度。

1.2 为什么现在才砸钱

有一组数据解释了时机。Publicis Sapient 的调查：73% 的企业说自己用 AI，但只有 10% 说 AI 已经进入核心运营。 德勤 2026 年的报告里：91% 的中国受访制造企业表示 AI 实施未达预期。

注意这两组数字的方向：不是"企业不想用"，是"企业不会用"。 模型已经足够多，缺的是把工具嵌进业务流程的人。

🔍 二、260 步：一个客服 Agent 到底在做什么

现在回到朋新宇给的两个数字。第一个是260 步。

朋新宇的描述是：一个"催发货"客服 Agent 要处理的不是一句问答，而是一条包含判断、查询、审批和执行的长流程。

这 260 步里，每一步都可能是一次 LLM 调用，也可能只是一次数据库查询。但它们的区别在于——每一步的失败代价不一样。

2.1 把 260 步拆开看

这是这类 Agent 场景的真实结构：

步骤类型	典型动作	失败后果	AI 适合度
意图判断	理解客户说的是"催发货"还是"投诉"	走错流程，后面全错	高（有多轮上下文可参考）
查询	查订单状态、查物流、查库存	查错但可纠正	高
判断	该不该赔付、该不该升级、能不能退	判断错直接影响钱	中——需要明确规则和历史样本
审批	超额赔付要主管批	越权或卡死	低——必须是规则强制
执行	发短信、提交退款、改订单状态	不可逆	低——必须幂等且可撤销

这张表的核心是最后两列的错位。 AI 能力最强的部分（意图判断、查询）恰好是失败代价最低的部分；失败代价最高的部分（审批、执行）恰好是 AI 最不该单独决定的。

260 步这个数字真正的价值，不是"很长"，而是它暴露了一个事实：

企业内部的工作从来不是"一个任务"，而是一条带判断、审批和不可逆操作的链。

而 2026 年大多数关于 Agent 的讨论，讨论的还只是"一个任务"。

2.2 为什么这条链比想象中长

一个常见的误解是：业务方描述需求时说的是一句话，系统上线时发现是 260 步。

这中间发生的事是：

业务方说的："帮我催一下发货"
系统实际要做的：
  ① 确认是哪张订单（可能多张、可能含预售）
  ② 判断是否已发货（区分承诺发货/实际发货/物流揽收）
  ③ 判断是否在承诺时效内（不同时效承诺规则不同）
  ④ 查物流轨迹是否异常
  ⑤ 区分是仓库问题/承运商问题/系统问题
  ⑥ 若是仓库问题 → 催仓库（内部系统）
  ⑦ 若是承运商问题 → 催承运商（外部接口）
  ⑧ 判断是否需要给客户补偿
  ⑨ 计算补偿金额（可能涉及多级审批权限）
  ⑩ 走审批流
  ⑪ 通知客户
  ⑫ 更新工单状态
  ...（还有 248 步）

而这 260 步里，每一步都有它自己的"业务规则"，这些规则往往是散落在不同地方的：

规则的存放位置	典型形态	问题
老系统的代码里	硬编码 if-else	没人敢改，改错就是事故
产品文档里	PDF、Wiki	已经过期
老员工脑子里	口口相传	人一走就永久丢失
会议纪要里	散落在几十份纪要中	没人知道哪份是最新版本

这就是 260 步真正的成本所在：不是流程长，是流程的知识散在四个地方，且没有一个地方是完整的。

2.3 第二组数字：90 天调价 1 万次

第二个数字是：一个顶级人类投手在 90 天内调价 1 万次。

这个数字为什么重要？因为它不是"重复劳动"——调价是一个判断动作。什么时候该降、什么时候不该降、降到多少、竞争对手会不会跟、跟了之后我的毛利还剩多少。每一次调价都是一次基于当时信息的决策。

而 AI 要学的，不是这 1 万条规则，是这些决策背后的判断。

朋新宇在节目里把这个问题转化成了一个工程问题：怎么把经验、数据和反馈接到系统里。

这正好是本栏目 10 月 27 日发过的《Skill 磨好了就能复用？》讲过的同一个问题——但那个角度讲的是 Skill 的维护成本，这个角度讲的是"判断"如何被提取出来。

提取判断的三种可操作方式：

方式	做法	优点	局限
标杆预设	把该岗位最好的那个人（工作 5-10 年的投手、客服）的决策模式做成 Agent 的初始预设	有明确的人可问，有明确的产出可对照	标杆只有一个，容错低
规则显性化	把散落的规则从代码、文档、老员工嘴里挖出来，写成可执行的判断标准	可审计、可迭代	挖的过程极耗时，且挖出来的是"规则"不是"判断"
持续反馈	让 Agent 上线后持续接收业务负责人的纠错，用真实反馈修正	贴近真实业务	需要有人持续投入——这就是三等分的第三段

朋新宇的方法是三者叠加，而他也点出了其中最现实的一条：

「哪里耗人最多，我开始琢磨，能不能帮我提高人效；哪里耗时最多，能不能帮我提高速度；哪里耗钱最多，能不能帮我提高 ROI。」

注意这个顺序——他不是从"哪个场景最酷"出发，而是从"耗人/耗时/耗钱"出发。 这跟硅谷那套"从模型能力和演示效果出发"是两种不同的起点。

⏱️ 三、部署周期的三等分，和那个被忽略的成本

现在到整期最有价值的一段：部署周期的三等分。

朋新宇的划分是：

阶段	占比	在做什么
① 熟悉岗位	1/3	理解这个岗位每天在干什么、卡在哪儿、什么算做好了
② 建模	1/3	把工作拆成流程、数据、判断标准、系统方案
③ 实际使用中调教	1/3	上线后持续纠错、补充规则、优化判断

这个划分透露的信息比它看起来更多。

先看这三个阶段各自的产出物和成本性质：

这张图上三个阶段各有不同的产出物和成本性质，这是最容易被漏算的地方：

第一，1/3 用来"熟悉岗位"——这是纯人力成本，没有任何自动化红利。

如果你在规划一个 Agent 项目的工期，这 1/3 是最容易被漏算的。因为它的产出物是"理解"，不是"代码"。 它不进任何工时系统，不出现在任何一个里程碑里。

而它偏偏是最不能省的：跳过这一步，第二步建模会建模出一个"看起来对但业务不认"的流程。 第三步调教会变成无底洞——因为你不知道它到底哪儿理解错了。

第二，1/3 用于建模——这是数据治理的成本，不是开发成本。

"建模"具体指什么？把 260 步拆开、把散落在四个地方的业务规则挖出来、把"什么算做对了"写成可执行的验收标准、把每个判断需要哪些数据说清楚。

这一步的产出物大部分是文档和数据，不是软件。 而它的瓶颈是业务专家的时间——那些最懂流程的人，往往也是最忙的人。

第三，1/3 用于实际使用中调教——这是最容易被低估的一段，因为它没有终点。

项目类型	上线后还需要人管吗
一次性数据处理任务	不需要，跑完就结束
持续运行的 Agent（客服、投放、运营）	需要，而且是长期需要

而这一段需要的人，不是什么高级工程师——是那个"最佳实践员工"。

3.1 三等分对项目管理意味着什么

如果企业按"三个月上线"的节奏规划，而实际上第 3 个三分之一是持续的，那么项目实际上永远在"进行中"。

这个结构性事实有几个直接推论：

推论	说明
上线不是一个日期，是一个阶段	项目验收标准应该定在"进入调教期"，不是"完成上线"
预算必须包含上线后的持续投入	只算前 2/3 的预算，实际超支是必然的
人不能撤	上线后撤走部署团队，等于把调教能力一起撤走
验收标准要分层	“跑通了”（阶段二完成）和"能用"（阶段三开始）是两个不同的验收

这最后一条是本篇对企业最实用的判断：把"上线"和"能用"分开定验收。

因为按上表的划分，"上线"只意味着 2/3 走完——此时 Agent 还在不断犯错、不断被人纠正、不断改规则。

一个在验收会上演示成功的 Agent 和一个真正能用的 Agent，中间隔着整整一个三分之一。

👥 四、三类角色，和"部署是一支队伍的工作"

朋新宇对 FDE 团队画像的描述，是这期节目第二个高价值段落。

他说得很直接：

「我们的做法不是一个人，而是一个组织。」

三类角色：

角色	职责	用人规模	关键能力
BA（业务分析师）	以业务结果定方向	需要多个	懂业务目标、能把结果翻译成可度量的指标
AI 架构师	选模型、搭系统方案、做工程组合	少量	模型/系统/工程判断力
业务负责人 / 最佳实践员工	承担"教练"角色，持续给 Agent 反馈	需要多个，且必须是"最好的那个人"	熟悉岗位、有判断能力、愿意投入时间

第三行是整套方法论的关键，也是最容易被资源规划漏掉的一行。

"最佳实践员工"这个角色为什么不能省？ 回到第 2 节那个 90 天调价 1 万次的投手——他的价值不在于他调价的动作，而在于他判断"这次该不该降"的依据。 而这个依据从来没有被写下来过，因为写下来对人类同事来说是多余的（做这行的人本来就懂）。

但对 Agent 是必需的。

所以"标杆预设"这个方法的真正成本是：你要让那个最懂的人，把他本来不需要解释的东西解释出来，而且要解释很多遍。 这是典型的"隐性知识显性化"成本——和本栏目 11 月 2 日发过的《上下文放在哪：Agent 的失忆症和一张存储账》讲的完全是同一件事。

4.1 三类角色的错配风险

错配	症状	后果
BA 缺位	没人能说清"这个 Agent 要改善哪个业务指标"	上线后无法判断有没有用，只能靠感觉续命
AI 架构师缺位	上来就追 SOTA 模型	见第六节，账算不过来
最佳实践员工缺位	Agent 上线后没人纠错	Agent 会在第三阶段原地打转，越用越差

第三行是最隐蔽的。 因为它的表现是"上线了，但效果一般"，而这很容易被解释成"AI 不行"或"这个场景不适合"，而不是"你抽走了那个喂它的人"。

4.2 三类角色怎么配

这三类角色在部署周期里各自对应一段，不是并行上三条线：

角色	主要出现在哪一段	介入时机	撤走会怎样
BA	① 熟悉岗位 + ② 建模	定义业务指标、判断标准	Agent 上线后无人判断有没有用
AI 架构师	② 建模 + ③ 调教（技术侧）	选模型、搭方案、处理调教中的工程问题	调教只能靠改 prompt，改不动根因
最佳实践员工	① 熟悉岗位（提供标杆）+ ③ 调教（持续）	全程，且强度最大	Agent 越用越差

第三行是全表最重的一格。 前面第二节说过，判断从来没有被写下来过——因为对人类同事来说是多余的。这意味着最佳实践员工在①阶段的投入，本质是在做"隐性知识显性化"；在③阶段的投入，是让显性化过的东西持续跟上业务变化。

4.3 朋新宇对"换个名字"的回应

他在节目里的原话：

「原来这拨人做运维就是这个系统就这样子，我是保证你健康运转着。但如果没有做任何变化，他凭什么会要去溢价？」

这个区分很精确，因为它指出了一个真实存在的岗位替代关系：

传统运维	FDE
保证系统正常运行	保证系统按业务目标往好的方向走
出问题才动	主动识别"哪里在变差、怎么干预、怎么调教"
技能项：技能的调整、数据的调整、语料的调整、上下文的调整、memory 的管理	同样的技能项，但用在业务结果上

第二行的最后一项"memory 的管理"值得单独提一句。 这是在传统运维职责表里完全不存在的活——因为传统系统没有记忆。 而 Agent 有，且它的记忆是持续污染的。

📐 五、标准化与个性化，和 AgentOne 这条路

接下来是标准化的问题，这是所有 To B 的 AI 公司都要面对的。

朋新宇把 AgentOne（瓴羊的企业级 Agent 平台）的逻辑概括为：先把通用能力做成产品，再接入企业的私有数据和权限，处理具体业务中的个性化问题。

他给了一个很简洁的总结：

「用标准化的方式解决个性化的问题。」

5.1 两条路的对比

	定制化项目	标准化平台
交付方式	一单一做	通用能力 + 私有数据/权限接入
可复制性	难——每个客户重做一遍	强——通用部分一次做完
成本结构	边际成本不降	边际成本随客户数下降
风险	做成项目公司，永远追不上需求	平台僵化，个性化做不进去
失败模式	长尾堆积，永远无法收敛	通用部分够用但个性部分差口气

第二行和第五行是两种失败模式的对照，这比"哪条路更好"有用得多。

定制化项目的核心问题是：它的产出是项目，不是产品。 项目做完就没了，下一个客户从零开始。而"三等分"的第三段（上线后调教）又让这件事更糟——每个客户的调教成果都留在了那个客户的系统里，回不到平台。

标准化平台的核心问题是：通用部分和个性部分的边界划在哪。 划得太靠里，平台退化成模板；划得太靠外，客户觉得"这不就是个空壳"。

5.2 划界的判据

朋新宇的方法是：通用能力做产品，私有数据和权限做接入。

这个划法背后的判据是"变化频率"和"数据主权"：

判据	归属	举例
变化频率高（每周都在改的规则）	属于客户侧，不能进平台	客服话术、促销规则
数据主权明确（客户的私有数据）	属于客户侧，走接入	订单数据、客户档案、权限体系
变化频率低（稳定的流程骨架）	属于平台，通用能力	意图分类、流程调度、工具调用框架、判断标准的表达方式
技术实现	属于平台	模型路由、缓存策略、可观测性

这张表的价值在于它给出了一个可操作的检验：如果你发现自己在平台里写了某个客户的业务规则，那一定是划错了。

🧮 六、模型选择服从业务账本：Token 成本怎么进决策

这一段是本篇对企业技术决策者最实用的。

朋新宇的态度是：企业不一定要追 SOTA 模型，只要在准确率、延迟、Token 成本和业务收益之间算得过来，模型策略就有成立的理由。

主持人问他 Token 成本时，他的说法是：「模型用什么不是老板最先关心的事，能不能把账算清楚才是。」

6.1 四个变量怎么进决策

变量	常见的错误算法	正确的算法
准确率	直接比 benchmark 分数	比在你的具体任务上的准确率（同一个模型在不同任务上差距可能是"锯齿"的两端）
延迟	比首 token 延迟	比端到端完成时间——260 步流程里，单步延迟 200ms 和 800ms 的差别会被放大 260 倍
Token 成本	比单价	比单次任务完成的总成本（= 单价 × 这个流程实际消耗的 token）
业务收益	拍一个数	这个流程一年跑多少次、每次省多少

第二行值得展开，因为它是本篇最容易被忽略、也最贵的错误。

一个 260 步的流程，如果每步都要调一次大模型，那么单步延迟不是工程指标，是产品指标：

场景	单步延迟	260 步累计	体验判断
高频场景（客服）	200ms	52 秒	勉强可用
高频场景	800ms	3 分 28 秒	不可用
异步场景（催发货）	800ms	3 分 28 秒	无所谓（用户不需要等）

同一个模型、同一个流程，在客服和催发货两个场景里的价值完全不同。 而如果只比"模型选型表"上的延迟数字，你完全看不出这个差别。

6.2 Token 成本的正确算法

再回到底层：260 步 × 每次调用的 token 数 × 单价 × 一年执行次数 = 这个流程一年的模型账单。

这个公式里有三个变量是可以在选型阶段就估的：

变量	怎么估	常见错误
每步调用的 token 数	按流程步骤数 × 每步的上下文长度估	忽略"每步都带完整历史"——这在 Agent 里极常见
每步的上下文长度	系统提示 + 工具返回 + 对话历史	工具返回往往是最大的一块（可能几千 token）
缓存命中率	取决于前面有没有做前缀缓存	默认按 0 算——这是最大的成本漏项

第三行值得单独说。 本栏目今天发过的另一篇《前缀缓存种成一棵树》讲的就是这个：前缀缓存能把多轮场景的后缀命中率做到接近 98%，但它只在"token 序列完全相同"时生效——这意味着你的流程设计（每步带多少历史、怎么裁剪）直接决定了缓存能不能命中。

所以"选哪个模型"这个问题，在 260 步的流程里，权重其实小于"流程怎么设计"。

🏗️ 七、领码 SPARK：中国式部署的对应物

前面六节是朋新宇的方法论。这节转到领码 SPARK 融合平台，看看这四条设计线在"企业级 Agent 部署"这件事上对应什么。

先说为什么这个映射是成立的： 260 步流程里最难的三件事——规则散落四处、判断标准不明确、权限与数据要接进来——正好就是数据治理要解决的三件事。

7.1 iPaaS 接数据 → 对应第 2 节的"规则散落四处"

260 步流程里的业务规则，散在老系统代码、PDF 文档、老员工脑子、几十份会议纪要里。在 Agent 接入之前，这些必须先汇到一个地方。

iPaaS 的意义不是"把数据接进来"这么技术化的事，而是：给这些规则一个统一的、可被 Agent 调用的接口。

具体对应四类数据源：

规则来源	接入形式	交给谁处理
老系统硬编码规则	从代码反推，落到规则表	规则引擎
产品文档	文档解析后人工校对	规则引擎
老员工的经验	访谈采集，结构化成标杆预设	业务负责人 + 标杆员工
历史决策数据	从业务系统拉	判断标准的训练/调优

注意第三行和第四行——它们是"数据"但不能自动接。 因为老员工的经验存在于人脑里，历史决策数据需要先标注"当时为什么这么决定"，否则就是一堆没有上下文的动作记录。

这是 iPaaS 能力的边界：它能自动接结构化的数据源，接不了需要人解释的东西。 而后者恰恰是 Agent 最需要的。

7.2 治理中心前置 → 对应第 3 节的"三等分不能省第一步"

三等分里第一段是"熟悉岗位"，第二段是"建模"。建模的产出物——判断标准——必须在 Agent 上线之前写完，而不是边跑边定。

这就是治理中心"前置"的含义：把标准写在前面。

具体到 260 步流程，每一步的判断标准要写成可执行的：

判断步骤	判断标准要写清	谁定义	怎么验收
是否在时效内	时效规则表 + 订单类型的例外	业务规则	用历史订单跑，看判断与人工是否一致
是否需要赔付	赔付规则 + 金额分级	业务规则 + 财务	用历史赔付案例回测
该不该升级	升级触发条件	业务负责人	抽样复核

这张表的核心是"谁定义"这一列——它和第四节的"最佳实践员工缺位"是同一个问题的两面。 判断标准必须由业务侧定义，因为只有他们知道"当年为什么这么判"。

而治理中心的作用是让这些标准可追溯、可版本化、可审计。 这和本栏目 10 月 27 日发过的《Skill 磨好了就能复用？三笔维护成本没人算过》讲的"判定标准版本化"是同一件事——判断标准是会变的，不版本化就会出现"上周的规则跑今天的数据"这种无法排查的问题。

7.3 全域守卫划权限 → 对应第 2 节表格里的"审批"和"执行"

第 2 节那张表里，失败代价最高的两步是审批和执行。它们必须是规则强制，而不是模型判断。

全域守卫的设计逻辑是：权限跟着数据和动作走，不跟着模型走。

动作	该由谁决定	权限怎么划
意图分类、查询	模型	读权限，按步骤最小化
判断（赔付/升级）	模型建议 + 规则卡口	金额分级，超额触发审批
审批	规则强制，人确认	按金额和类型分级授权
执行（退款、改订单）	规则强制	幂等、可撤销、单笔限额

"最小权限"这个词在这里要重新理解。 传统最小权限是"少给"；Agent 场景下更准确的说法是**“精确到动作和时效”**——给的是"执行退款这一类动作 24 小时内的权限"，不是"给这个 Agent 整个系统的读权限"。

这两者的差别，就是出了事能不能止损。

7.4 与 Dify 分工 → 对应第 5 节的标准化边界

朋新宇说"用标准化的方式解决个性化的问题"，这个划分在平台层的对应是：编排和执行分开。

层	负责	为什么分开
编排层（Dify 这一层）	260 步的流程定义、每步带什么上下文、判断标准怎么表达	这是业务逻辑，每家企业不同，必须能定制
执行层（SPARK）	数据接入、权限校验、模型调用、缓存、可观测性	这是系统能力，跨企业通用，不该每家重做

混在一起的具体后果，在第 6 节已经出现过一次： 为了省事把上下文拼在别的地方拼，会破坏前缀结构，缓存全部失效，成本反而上升。

7.5 一张可以直接用的部署自查表

检查项	问自己的问题	不合格的表现
规则收口	260 步里的判断规则，现在在几个地方？	至少三个地方，且没人知道哪个是最新的
标杆可及	那个"最佳实践员工"，一周能拿出多少时间给 Agent 反馈？	答不上来，或者答案是"没有这个人"
标准前置	判断标准是在上线前写完的，还是边跑边定？	标准文档里写着"待补充"
三段预算	上线后的持续调教，人力和预算算进去了吗？	只算到"上线"为止
分层验收	"上线"和"能用"是分开定的验收吗？	只有一个验收点，在演示当天
模型账本	这个流程一年的模型账单是多少？	不知道，因为"还没上线"
权限分级	审批和执行两步，是规则强制还是模型决定？	模型决定，且没有金额上限

这张表第一行和最后一行，是最省事也最管用的两个检查点。 第一行五分钟就能问出来，最后一行是安全底线——如果审批和执行是模型说了算，那么一次提示注入的后果就是真的赔钱。

✅ 八、可以带走的判断清单

260 步不是"流程很长"，而是暴露了一个事实：企业内部的工作是带判断、审批和不可逆操作的链。 而大多数关于 Agent 的讨论，讨论的还只是"一个任务"。
这 260 步真正的成本不是长度，是知识散落在老系统代码、PDF、老员工脑子、几十份纪要里，没有一处是完整的。
90 天调价 1 万次这个数字的意义：AI 要学的不是这一万条规则，是这些决策背后的判断。 而判断从来没有被写下来过——因为对人类同事来说是多余的。
部署周期三等分（熟悉岗位 / 建模 / 实际使用中调教）意味着"上线"不是一个日期，是一个阶段。 上线只意味着 2/3 走完。
第三段是长期的，需要人，而且需要的是"最好的那个人"持续投入。 抽走他，Agent 会在上线后原地打转，越用越差。
“部署是一支队伍的工作”——BA 定方向、AI 架构师搭方案、最佳实践员工当教练。 第三行最容易被资源规划漏掉。
FDE 的溢价来自"让系统按业务目标往好的方向走"，不是"让系统正常运行"。 传统运维不需要管的 memory 管理，在 Agent 场景是硬职责。
标准化的判据是"变化频率"和"数据主权"：稳定流程骨架进平台，客户规则和数据走接入。 如果你在平台里写了某个客户的业务规则，一定是划错了。
模型选择服从业务账本，且账本里权重最大的往往不是模型，而是流程设计。 260 步 × 每步上下文长度 × 单价 × 年执行次数——这个乘法里，缓存命中率是最容易漏算的一项。
在 260 步的流程里，单步延迟是产品指标不是工程指标。 800ms × 260 = 3 分 28 秒，同一个模型在客服和异步场景里的价值完全不同。
对应到企业：规则收口、标杆可及、标准前置、三段预算、分层验收、模型账本、权限分级——七项里答不上三项，先别规模化。
最后一条数据纪律： 硅谷那 90 亿美元是四笔不同性质的钱（两家合资 + 两家内部投入），不要当成同一种东西加总；OpenAI FDE 旧金山 16.2 万~28 万美元是基础薪资+股权，不含总包；国内 FDE 岗位"上半年同比增长 2100%"是招聘平台口径，与本栏目 10 月 12 日发过的 5230% 那个单一招聘站指数不是一回事，两者不能混用。