AI Agent演示用了12个工具，生产环境只需1个岗位

演示卖的是可能性，生产买的是可靠性。每增加一个工具，故障模式、延迟和权限范围都在成倍增长。

Marcus站在白板前，身后的屏幕上还亮着演示画面。董事会很喜欢：Agent读取邮件、查询CRM、更新Jira、起草回复、安排会议、订购午餐。然后CISO往前倾了倾身子："如果第四步在苏黎世订错了会议室，谁来承担故障责任？"没有人能回答。

这就是问题所在。演示卖的是可能性，生产买的是可靠性。每增加一个工具，故障模式、延迟和权限范围都在成倍增长。诚实的推销不是"数字员工"，而是"这一个工作流，提速40%，发送按钮由人来按"。

为什么12个工具变成了生产灾难

AI Agent在生产中失败的地方，不是LLM本身，而是集成边界。

演示到生产的典型工具坍缩比例是 12 → 1——选择那个能为项目买单的岗位。这是从多个试点复盘（pilot postmortem）中反复出现的模式。

更关键的是交互复杂度的增长曲线：N²。复杂度比工具数量增长得更快。10个工具意味着45条两两交互路径需要测试，12个工具则接近66条。你测试的不只是工具本身，而是组合。

在一个实际案例中，演示环节中12个工具全部运行正常。到生产环境时，Jira的字段schema无预告更新，Agent在第4步静默失败，整个链条崩溃。没有人知道该paged谁——因为答案是"AI团队"，而AI团队成了穿着风衣的12个单点故障。

N² 复杂度从何而来：当 Agent 能调用 N 个工具时，需要验证的不只是每个工具单点的正确性，还包括工具之间所有可能的两两（以及更高阶）组合。两两路径数量是 C(N,2)=N(N-1)/2，这正是 N² 曲线的来源：10 个工具是 45 条，12 个是 66 条。工程上的后果是，集成测试用例数量随工具数呈平方增长，而每个用例又需要独立的 mock、超时配置和断言，维护成本进一步放大。

为什么故障往往是静默的：演示脚本通常走的是“幸福路径”，即上游返回值恰好满足下游的字段假设；而生产中的第三方 API 会随时调整 schema、限流或返回部分数据。Agent 若没有显式的字段校验和失败上报，就会在链条中段返回一个看似成功的空响应，导致下游步骤基于错误输入继续执行。这类静默失败不会抛异常，只会让最终结果悄悄偏掉，因此“谁来 on-call”这个问题才会如此难答。

如何诚实地做演示

展示一个岗位上的幸福路径。展示置信度低时的停止条件。展示审计日志。不要为任何一项道歉——那就是产品本身。

演示规则：如果你无法为每次工具调用指定一个on-call负责人，就砍掉工具，直到你能做到。

每个演示中的工具都需要一个具名的人类负责人、一个on-call轮值表和一个回滚方案。12个工具意味着12个可能在你不注意时改变行为的API。当演示进行到主题演讲中途Jira更新了字段schema导致你的demo崩溃时，谁会收到告警？如果答案是"AI团队"，那你就有了12个穿着风衣的单点故障。

利益相关者记住的是蒙太奇，财务记住的是事故。为财务而构建。

生产环境中的四个硬性约束

生产想要一条编排好的路径——12个演示工具变成3个有明确边界的自有组件。

故障隔离：一个工具宕机不应毒化整条链。如果日历服务挂了，草稿仍然应该保存并支持手动发送。

补偿动作：每个关键步骤都需要fallback。日历失败，草稿还在；CRM不可用，邮件仍能起草。

每步延迟预算：用户不会为订购午餐等45秒。每个工具调用都有延迟成本，累加起来会超出用户耐心阈值。

权限最小化：演示账号仍然会泄露。为每个工具单独限定权限范围，不要用一个宽泛的OAuth token覆盖所有服务。

董事会记住的是蒙太奇。支持团队记住的是哪个集成在周五下午4点坏了。

补偿动作（compensating action） 借用自分布式事务中的 Saga 模式：当一个长流程的某一步失败时，系统不去回滚已经完成的步骤，而是执行一个语义上可接受的替代动作，让整体仍能收敛到有意义的终点。对 Agent 而言，这意味着日历预约失败时保存草稿并提示手动发送，CRM 写入失败时退回邮件通道，而不是整条链路抛错。

每步延迟预算 是把用户体验拆解成可度量的时间片。假设用户能容忍 10 秒，那么每个工具调用的 P95 延迟、模型推理时间和网络往返必须共享这 10 秒，任何一项超标都要有降级策略（如跳过可选步骤、返回缓存结果）。

权限最小化 则要求每个工具使用独立的、作用域受限的凭证，而不是一个覆盖全部服务的宽泛 OAuth token——后者一旦泄露，攻击面等同于整个集成集合。

把"哇"翻译成路线图

演示的掌声过后，运行一次无情的优先级排序会议：在试点用户的一周中，哪一个步骤节省的时间最多？构建那个。毫无愧疚地降低其他所有事项的优先级——它们是续集，不是发布阻塞项。

诚实的路线图写的是"Q3：邮件到工单草稿"，而不是"数字员工"。

对你意味着什么：用平均诊断时间（mean time to diagnose）而非功能数量来衡量生产就绪度。一个有日志的可靠工作流胜过12个打动投资人的脆弱工具。对比那些专注做一件事的实用工具——那才是你的Agent应该复制的能量。

生产过滤器：你会把这个工作流托付给你自己的日历吗？如果不会，砍工具直到你愿意为止。

集成测试矩阵

12个工具意味着组合爆炸的测试路径。你无法在没有配对测试的情况下发布——A然后B、B在C期间失败、D超时。生产是一个状态机；演示跳过了边。

对你意味着什么：在写测试之前坍缩工具，而不是在事故之后。一个岗位，一个你真正能每晚运行的矩阵。

配对测试（pairwise testing） 是一种用组合数学压缩测试空间的方法：与其穷举所有工具组合，不如保证任意两个工具的所有取值组合至少被覆盖一次。对于 12 个工具，完整的 N² 路径可能上千，而配对覆盖通常只需十几到几十个用例，能在可控成本下捕捉绝大多数交叉故障。

状态机视角：把生产工作流建模为状态机后，“边”就是状态之间的转移条件。演示之所以跳过了边，是因为它只走了一条主路径；而生产中的重试、超时、并发和部分失败都会走出额外的边。测试矩阵的本质，就是为这些边逐一写出预期的转移目标，而不是只验证每个节点能返回 200。

演示后的范围合同

与sponsor签一份内部范围信：v1岗位、v1工具、v1负责人、v1指标。不在信上的任何内容都是第二阶段。这能防止六个月后当一切都不够可靠时有人说"但演示做了12件事"。

生产级Agent是一个一个工作流地赢得信任的。每增加一个工具就是一个供应商关系、一次凭证轮换和一轮on-call值班。尽早坍缩，衡量可靠性，只在v1变得无聊时才扩展。

你的下一步行动

把你的AI管道画成依赖图——每个服务、每个API、每个库。数节点。然后划掉每一个对成功生产运行非严格必需的东西。剩下的图就是你的生产架构。划掉的节点是你的演示复杂度。

先发布最小图，只在数据证明你需要时才添加复杂度。

如果演示做了12件事，就意味着12个供应商关系、12次凭证轮换，以及12次没人报名参加的周五下午4点告警。写v1范围信——一个岗位、一个主工具、一个具名on-call负责人、一个指标——在掌声消退前让sponsor签字。其他一切都是第二阶段，不是破碎的承诺。