AI 智能体上线的头 90 天：一份落地实战手册
大多数被开发出来的智能体系统，从未真正进入生产。能进入的那些，几乎总是比团队计划的时间更长、花的钱比预算更多、上线时的范围比最初提案的小。
这并不是因为技术不成熟。是因为上线被当作一个工程项目对待，但上线至少同样多地是一个流程和组织变革。能在生产环境里把智能体系统交付出去的团队，是把它当作一个有结构、有清晰阶段、有清晰交付物、有清晰失败模式的 90 天项目来做的团队。
这是我们和客户一起跑上线时用的手册。它是有立场的。它不会适合所有组织。它是产出最稳定结果的那一种模式。
失败的那种模式
在描述手册之前，先描述一下产生失败的那种模式。它长这样。
团队识别出一条工作流程。它看起来是个好候选——重复、文档密集、让操作人员抓狂。某个人写了一份提案。提案被通过，因为工作流程是真实的、ROI 的预测看起来合理。工程开始开发。第 6 周，演示跑通了。第 8 周，试点开始。第 10 周，试点产出的异常比原来的手工流程还多，操作人员开始绕着系统走，评测套件显示模型在大家都认为是常规的 12% case 上做出自信的错误决策。第 12 周，项目"暂停，重新评估"。
这个模式是一致的：范围弱、演示不是系统、没有审核路径、没有评测套件、没有操作人员的声音。每一个都是可以修的错。加在一起，可靠地产出一个站不住脚的上线。
阶段 1：第 1–30 天——范围梳理与流程映射
头 30 天不是用来开发的。它们是用来确保你接下来要造的东西是正确的那个。
只选一条工作流程。 不是三条。不是一个平台。一条工作流程，从头到尾。那些试图在第一个季度同时交付一个"基础"加多条工作流程的团队，可靠地两边都没交付。选价值 / 复杂度比最高的那条——价值用每周节省的操作人员工时或者错误率的下降来衡量，复杂度用这条流程会碰到的系统数量和它拥有的异常 case 数量来衡量。
记录实际的过程。 不是被文档化过的那个过程——是实际的那个。去和操作人员聊。看他们怎么工作。画清楚每一步、每个决策点、每个异常 case、每一种 workaround。产出是一份流程文档，团队里任意两个操作人员都会认同它。如果你做不出这份文档，这条工作流程就还没准备好被自动化，阶段 1 在做出来之前不该结束。
画出异常路径。 每一条运营级工作流程把大部分时间花在异常 case 上，不是主路径。识别出占操作人员 80% 精力的那 20% case。智能体系统会自动处理简单的 case。这些异常 case 才是系统要路由给人工的地方——而这个路由，就是这个系统本身。如果你没有画过它们，你就没有真正理解这条工作流程。
定义什么叫成功。 用数字写下，这次上线预期要达成什么。每周节省的操作人员工时。错误率的下降。从开始到完成的时长。指标是什么不重要，重要的是它们要能从现有数据里被衡量，并且要由最终为结果负责的人来同意。如果成功被定义为"操作人员喜欢它"，那它永远不可衡量。如果成功被定义为"我们把单 case 的审核时间从 4 小时压到 30 分钟，团队可以在不招人的前提下吸收 30% 的增量"，那它就能被衡量、被跟踪。
阶段 1 结束的时候，你应该有一份工作流程文档、一张异常地图、一个成功定义、以及一个清晰的答案：这条工作流程到底是不是智能体系统的好候选？有时候答案是否定的。那是一次成功的阶段 1。
阶段 2：第 31–60 天——造出能跑的最小系统
第二个 30 天，是造出能在一个真实生产环境里处理一个真实 case 的最小端到端系统。不是演示。不是原型。是一个跑在真实数据上、产出真实输出、有真实审核路径的系统。
先造审核 UI，再做自动化。 直觉是先造智能体、再造审核界面。直觉是错的。审核界面就是系统本身。操作人员的任务是处理智能体处理不了的那些 case，这个界面就是他们要做这件事的工具。如果界面好，系统就工作。如果界面差，系统就不工作——不管智能体多好。
在演示之前写评测套件。 评测套件是工程团队和运营团队之间的契约。它规定了系统要在什么条件下被认为已经准备好进入生产——用真正重要的那些 case 来规定。它应该在 CI 里可跑、有明确的通过阈值、并且要被这条工作流程真正的操作人员评审过。一个没通过评测套件的演示是原型，不是系统。一个通过了评测套件的系统，已经准备好进入试点，即使演示看起来很糙。
为异常而造，不为主路径而造。 主路径是简单的部分。异常路径才是系统真正发挥价值的地方。阶段 1 识别出的每一个异常 case 都需要有明确的处理方式：路由给人工、让操作人员回答一个澄清问题、返回一个结构化错误、升级给资深审核员。如果异常处理没被设计过，系统会在最重要的那些 case 上失败。
收紧策略边界。 智能体只能在一个明确的边界内操作：特定的 case、特定的 action、特定的输出。边界之外的事情会暂停并被路由。边界是用代码强制执行的，不是写在 prompt 里。一句"请小心一点"不是策略。一个拒绝边界外 action 的函数才是策略。
阶段 2 结束的时候，你应该有一个跑在真实环境上的系统，有真实的审核界面，有通过的评测套件，有明确的策略边界。它不需要处理每一种 case。它需要把简单的 case 做对、把难的 case 路由给人工、并且为它做的每一个决策留下记录。
阶段 3：第 61–90 天——试点、衡量、收紧
第三个 30 天，是把系统放进生产、用真实的 case、给真实的操作人员、并且从它做的事情里学习。
跑在真实的 case 上，不要跑在挑过的 case 上。 试点必须在操作人员看到的真实 case 上跑，不是在一个让系统看起来不错的精选集上。试点要找到的，就是系统处理不了的那些 case、审核界面用起来别扭的那些 case、模型自信且错误的那几种 case。这些 case 才是下一个季度要做的工作。
衡量分歧，不只是错误。 一个产出 95% 正确输出和 5% 错误输出的系统，和一个产出 95% 正确输出和 5% 有争议输出的系统，不是同一回事。前者是一个模型在一个明确的子集上失败。后者是一个模型在操作人员会有分歧的那几种 case 上失败——而这才是人工审核真正有价值的几种 case。两个数字都重要。分歧率是收审审核路径更有用的那个指标。
用数据收紧边界。 阶段 2 结束时候的策略边界是一个假设。试点数据会告诉你这个假设哪里对、哪里错。系统自动处理的某些 case 本来应该路由给人工。路由给人工的某些 case 本来可以自动处理。这两个方向都很有用。边界要被证据收紧，不是被直觉。
忍住扩张的冲动。 90 天项目的结束，不是把系统铺到全公司的时候，也不是加第二条工作流程的时候，也不是宣布胜利的时候。那是收尾的时候：把粗糙的边角修掉，把文档更新，培训下一批操作人员，并且确保系统在当前范围下可靠运行。在收尾之前扩张，正是好的智能体系统变成脆弱系统的方式。
阶段 3 结束的时候，你应该有一个在生产环境里跑的系统，定义好的范围、定义好的审核路径、有维护的评测套件、对它擅长什么不擅长什么有一张清晰的图。这是一次成功的 90 天上线。
常见的失败模式
这些是跨行业、跨工作流反复出现的失败模式。
选错了工作流程。 工作流程是某个高层拍脑袋选的，不是操作人员一致认同的。结果是一个解决了操作人员没有的问题的系统。修法：和操作人员一起选工作流程，不是替他们选。
为演示优化。 团队造了在销售演示里看着漂亮的东西，没造在生产里能跑的东西。演示流畅。生产的 case 包含边界 case、格式错误的输入和含糊的语言。修法：先写评测套件，在真实数据上跑系统，并且拒绝交付一个没通过的系统。
没有操作人员的声音。 系统是工程师替操作人员设计的，操作人员参与有限。界面围着数据模型建，不围着工作流程建。操作人员绕着它走。修法：操作人员从阶段 1 开始就是设计过程的一部分，不是末尾被汇报的 stakeholder。
把错误藏起来。 系统出错。团队把错误藏起来、把它磨平、把它悄悄路由掉。操作人员只有在错误出现在一次客户交互里的时候才知道出过问题。修法：每一个错误都记下来、每一个错误都评审、每一个错误都回流到评测套件。
先扩张后收尾。 90 天项目结束。团队在粗糙边角修好之前就把系统铺到全公司。粗糙边角变成事故。事故变成不信任。系统被暂停。修法：在扩张之前先把当前范围收尾。
复利效应
一次成功的 90 天上线不是项目的结束。它是下一个项目的基础。
评测套件变成第二条工作流程的契约。审核界面变成下一条的范式。被建立起来的操作人员信任变成下一次上线的基础。被避免掉的技术债变成下一轮工作的容量。
第一次智能体系统交付得好的团队，第二次交付只需要一半时间，第三次只需要三分之一。第一次交付得很差的团队，往往根本交付不了第二次——因为第一次消耗掉的组织信任，没法留给下一次尝试。
90 天不是延迟。它本身就是工作。做了这些工作的团队，才会一直做下去。