第 24 章 · 把能力交出去
老板先看这一句： 项目结束才算数——而真正的结束,是能力交到业务方手里自己转,而不是绑在某人身上。如果系统只有 Agent 落地工程师调得动,他一走就荒,你投的钱就烂在交付里。你要问一句:「这个项目交出去后,运营自己能改口径、调阈值、标记错误吗?交接验收谁现场走了一遍?」那三样不能省:配置化界面、规则模板、反馈闭环——它们决定你买来的是「一次演示」还是「一套持续运转的能力」。
离不开的「专家」,是失败的交付
有个项目我做得挺得意:上线后跑得很稳,业务方很满意。得意了大概两个月,我发现不对劲——业务方隔三差五就找我:「想加一类新问题的回答,你帮忙调下」「这个阈值想改改,你来弄」。每一次都得我上手,因为整套东西只有我调得动。
我成了这个系统离不开的「专家」。听着像是被需要,其实是交付失败。因为业务天天在变,而我不可能永远待在这个项目上。真正成功的交付,不是「我一直在」,而是「我走了它照样转」。
Agent 落地工程师的终点不是做出一个好用的智能体,而是把方向盘交到业务方手里,让他们能自己开。 这一步,对应成熟度从 L4 到 L5 的跨越——从「我带着交付」到「他们自主运营」。这一章讲怎么把方向盘交出去,而不是永远自己攥着。
为什么交不出去
先想清楚:为什么系统总离不开 Agent 落地工程师?几乎都是因为「怎么调」这件事,只存在于 Agent 落地工程师的脑子和手上。
- 想加一类新回答?得改提示词——而提示词只有 Agent 落地工程师懂怎么改、改完怎么验。
- 想调个阈值?得动配置——而配置藏在代码里,业务方碰都不敢碰。
- 效果变差了?只有 Agent 落地工程师会看评估集、会定位问题。
根子是:系统的「可调部分」没有对业务方开放,全锁在技术黑箱里。 交接的本质,就是把这些「常改的旋钮」从黑箱里拆出来,做成业务方也能安全操作的东西。
三样东西,让业务方自己开
要让业务方自主运营,至少交付这三样。
一、配置化界面——把常改的旋钮搬到台面上。 把业务方最常要调的东西——分类口径、预警阈值、回答话术、知识库条目——从代码里抽出来,做成一个他能点、能填、能保存的界面。他不需要懂提示词,只需要在界面上「加一条口径」「把阈值从 0.7 调到 0.8」。判断哪些该配置化,就看第 21 章那个变更池:被反复提的「优化类」变更,就是该做成旋钮的。
二、规则模板——让他照着填,不必从零想。 光给界面还不够,业务方常常不知道「该怎么填才对」。给他模板:新增一类问答长什么样、一条预警规则该包含哪些字段、话术要避开哪些雷区。模板 = 把 Agent 落地工程师的经验固化成填空题,降低他自己动手的门槛和出错率。
三、反馈机制——让系统能从使用中继续变好。 交出去不等于撒手不管质量。要给业务方一个简单的反馈通道:AI 答错了,他能一键标记「这条不对」。这些标记自动沉淀成新的失败样本,喂回 Golden Dataset(第 22 章)。这样即使 Agent 落地工程师退到幕后,系统仍能靠日常使用持续进化——这正是第 12 章那个「闭环」在交接之后的延续。
| 交付物 | 让业务方能 | 替代了原来谁的活 |
|---|---|---|
| 配置化界面 | 自己调口径/阈值/话术 | Agent 落地工程师改代码 |
| 规则模板 | 照着填,不出错 | Agent 落地工程师手把手教 |
| 反馈机制 | 标记错误、喂回评估集 | Agent 落地工程师人肉收集失败样本 |
交接不是甩手,是换挡
把方向盘交出去,不是一脚下车走人,而是换个位置继续在。参照第 20 章那四个阶段,交接大致这么换挡:
- 先并排开:Agent 落地工程师调、业务方看,边做边讲「为什么这么调」。
- 再让他开、你盯着:业务方上手用配置化界面调,Agent 落地工程师在旁边兜底、纠偏。
- 最后你退到幕后:业务方独立运营日常,Agent 落地工程师只做两件事——监控(盯成本、质量、失败率有没有异常)和阶段性升级(重大能力迭代)。
到了最后这一步,你和这个项目的关系,就从「司机」变成了「4S 店」——平时他自己开,定期回来保养,出大问题才找你。这才是 L5 的样子:你的价值不再靠「在场」证明,而靠「系统在你不在时依然良好运转」来证明。
一份简单的交接说明要配齐:怎么用配置界面、常见问题怎么处理、出大问题找谁怎么关(呼应第 23 章的回滚)。第 12 章那个案例,Week 4 就给运营留了这么一份「怎么自己调」的说明。人机边界与自主运营的对接,可对照附录 B 的介入点图。
上线以后，进入六步运营闭环
- 观察经营结果：先看业务指标是否变化，不把调用量当成价值。
- 查看质量与风险：按场景拆解采纳率、错误率、人工接管、高风险拦截和失败类型。
- 补充上下文：更新知识、规则、数据口径和系统接口，优先修复反复出现的信息缺口。
- 调整人机边界：根据真实表现收紧或放开权限，重新设置置信阈值和人工确认点。
- 优化成本与体验：调整模型、缓存、批处理和交互，不让调用成本或复核负担吞掉收益。
- 沉淀公共能力：把可复用的数据、接口、评估集、工作流和治理规则提供给下一个场景。
应用上线不是项目终点。只有当企业形成固定负责人、运营看板、反馈渠道、复盘节奏和扩展标准，Agent 才从一次项目变成组织能力。
交出去以后看什么
自主运营不是没人管，而是换一组指标看盘。最小运营仪表盘可以包含：
| 指标 | 用来发现什么 |
|---|---|
| 调用量 / 活跃用户 | 业务方是不是真的在用 |
| 采纳率 | AI 输出是否有用 |
| 人工复核量 | 人审是否过重，是否吃掉效率收益 |
| 失败率 / 超时率 | 工具、接口、模型是否稳定 |
| Top 失败类型 | 下一轮优化该改哪里 |
| 成本 / 次 | 是否出现调用膨胀 |
| 高风险拦截数 | 风险控制是否在工作 |
交接也要验收。不是发一份说明文档就算，而是让业务方现场完成一次独立操作：
- AIBP 自己新增一条分类口径或调整一个阈值。
- 系统自动跑 Golden Dataset 回归。
- 回归不退化后发布到试用环境。
- Agent 落地工程师只旁观，不代操作。
- 发布后看运营仪表盘，确认采纳率、失败率、成本没有异常。
这五步走完，才说明方向盘真的交出去了。
支持机制也要分层：业务方能自助处理的，不要找 Agent 落地工程师；AIBP 能处理的，不要找平台；只有工具故障、权限问题、重大退化，才升级给 Agent 落地工程师或平台团队。否则交接以后，Agent 落地工程师仍然会被所有小问题拖回一线。
📍 场景示例：老陈的运营自己把差评预警阈值从 0.7 调到 0.8
客服 Agent 交出去前，每次调阈值、加口径都得找 FDE 改代码。交接时老陈要求做成配置化界面：运营自己把「差评预警阈值从 0.7 调到 0.8」、自己加一条「FR/ES 差评归高优先」口径。Week 4 验收时，运营独立完成一次调口径 + 回归不退化，FDE 只旁观——现在 FR/ES 咨询 T+1 才回的时差缺口，运营自己就能改规则补上。
| 维度 | 改造前 | 改造后 |
|---|---|---|
| 调阈值 / 口径 | 找 FDE 改代码 | 运营在界面自己调 |
| 交接验收 | FDE 代操作 | AIBP 独立完成 + 回归 |
| 时差缺口 | 靠 FDE 排期补 | 运营即时改规则 |
老板决策点： 把「运营能否独立运营」列为结项硬验收——交不出去，就不算项目做完、投入没收回。 ——对应 → L5
常见坑
- 把自己做成离不开的专家。 所有调整只有 Agent 落地工程师会,系统绑死在一个人身上,交付名成实败。
- 可调部分锁在代码里。 常改的旋钮不做配置化,业务方碰不了,只能次次找你。
- 只给界面不给模板。 业务方对着空界面不知道怎么填,还是得依赖 Agent 落地工程师。
- 交接=撒手。 一交了之,不留监控和反馈机制,系统慢慢跑偏无人察觉。
- 没写交接说明和关停预案。 业务方不知道出事找谁、怎么关,一遇故障就抓瞎。
本章产出
老板行动点： 把「业务方能否独立运营」列为项目结项的硬验收——要求团队交付配置化界面与交接说明,并让 AIBP 现场独立完成一次调口径/改阈值的操作;交不出去,就不算项目做完,也不算这笔投入收回。
往交付包里放一份「自主运营交接包」:
列出业务方日常最常要调的 3–5 个「旋钮」,为每个设计出配置化的操作方式和填写模板;设计一个「标记错误 → 喂回评估集」的反馈通道;再写一页交接说明(怎么调、出事找谁、怎么关)。这套东西交出去,你才算真正完成了从 L4 到 L5 的跨越。介入点与人机边界可对照 附录 B,关停回滚对照 附录 F。
成熟度自检
- [ ] 我能把常改的能力做成配置化界面 + 模板,让业务方自己调(→ L5)
- [ ] 我能建立反馈闭环并退到监控/升级角色,让系统在我不在时持续运转(→ 巩固 L5)