作者：Joscha Koepke，Connectly 产品总监
为什么发布和整合是两个完全不同的问题——以及完成这两者需要什么。
发布是让代理上线运行。整合则是代理可靠地创造价值的过程：解决客户问题、将意图转化为营收，并周复一周持续改进。如今被庆祝的大多是发布。而整合才是真正的工作开始的地方。
以下是演示阶段没有人告诉你的事情：你构建的代理，其目标用户是一个沟通清晰、遵循流程、始终围绕主题的人。这样的用户根本不存在。
真实的客户会发送语音消息和模糊的照片。他们在一条消息里写三个请求。他们开始一段对话时询问某个产品，然后话题中途转向质疑一笔费用。他们使用不在你训练数据中的俚语、缩写和方言。他们放弃流程，几小时后回来，期望代理还记得上下文。尤其是在消息渠道上——对话本质上是非正式和异步的——想象中的用户与真实用户之间的差距是巨大的。
这就是为什么演示会撒谎。演示是有一个配合用户的理想路径。生产环境是其他所有情况。而其他所有情况占据了你大多数的流量。
这个差距中的每一次失败都有代价：一个未被服务的客户、一笔未成交的销售、一个本不该升级到人工的投诉。规模化之后，这些失败无声积累，直到体现在你的留存数据上。
没有解决好生产运营的团队往往会撞上同一堵墙。代理发布了，初期指标看起来很有希望。然后，几周几个月后，裂缝开始出现。
一个提示词被更新以处理新的用例，无声地破坏了现有用例的行为。没有人注意到，因为两周内没有回归测试。模型提供商更新了 API，某部分对话的延迟急剧上升。客服工单增多，但花了好几天才找到根本原因。一个对某个客户群体运行完美的流程，对另一个群体无声失败，因为边缘案例从未被测试。构建代理的团队现在将大部分时间花在救火上，而不是改进代理。
这就是失败的整合。不是灾难性的失败，而是一种缓慢、代价高昂的漂移——代理停止改进，并开始成为一种负担。
根本原因几乎总是相同的：团队优化了让代理上线，而不是长期运营它。
整合一个代理意味着解决四个在构建阶段很少浮现的问题。
每次变更前进行回归测试。 当你的知识库、提示词或模型发生变化时，总会有东西出问题。问题在于是你先发现，还是你的客户先发现。整合做得好的团队，在任何变更上线之前，都会在数百个真实对话模式上运行自动化模拟。
实时防护措施，而不是第二天早晨的报告。 生产中的对话会走向没有人预料到的地方。在 12 小时后的批量报告中发现这一点，不算治理。你需要一个策略层，在每次对话发生时进行监控，并在出现问题时自动响应。
精确到对话轮次的可观测性。 当生产中出现问题时，你需要知道确切的位置。不是"本周响应质量下降了"，而是"当用户在同一条消息中包含一个问题和一个请求时，这个特定流程会崩溃"。
无需 sprint 即可发布变更的能力。 客户需求在不断变化。如果对代理的每次变更都需要一个工程周期，你的代理就会落后于你的业务。能从代理中获得复利价值的团队，可以在数小时内更新逻辑、验证并发布。
这些都不光鲜，但也不是可选的。这是一个在第一天运行的代理与在第 365 天仍在运行的代理之间的差距。
构建还是购买的问题，通常是围绕初始代理来框架的。这是错误的框架。
真正的问题是，你是否应该构建并维护评估基础设施、防护层、可观测性工具、回归测试框架和支撑代理在生产中运行的迭代流水线——无限期地。
对于大多数公司来说，这是隐藏在第一个项目内部的第二个工程团队。每个维护代理基础设施的工程师，就是一个没有在改进核心产品的工程师。而且与代理本身不同，这种基础设施不是竞争优势。
正确的平台让你的团队专注于真正区分你代理的东西：你的工作流、你的业务逻辑、你的升级规则、你的品牌声音。它所吸收的是下面的一切——让灯保持亮着的部分，这样你的团队就可以专注于改进代理。
错误的平台会让你变成工单提交者。每次流程变更都要通过他们的队列。每次迭代都要等他们的 sprint。你最终会得到一个在购买时就被冻结的代理，慢慢地落后于你的实际业务。
在发布之前，或在决定当前方法是否有效之前，请问自己这些问题：
如果以上任何一个答案是否定的，你只是做了一次发布。整合还在你前方。
目标从来不是一个在第一天运行的代理，而是一个持续赢得信任的代理：解决更多问题、转化更多意图，每周都在改进。这才是证明投资合理的东西。在此之前的一切都只是概念验证。
发布是容易的部分。为整合而构建。
