一个部门能把Agent做出来，不代表全公司都能放心复用。Orange Business在10月13日披露Live Intelligence的生产复盘，把关注点放在工具目录、提示版本和多层评测，而不是只展示聊天界面。平台并非今天首次上线，新的价值是说明：当AI跨越多个企业系统时，怎样让业务人员参与改进，又不把权限和责任全塞进提示词。

快速看点：用户、开发者和管理员各有入口；Agent与MCP注册表把复用和工具接入纳入管理；检索质量、执行行为和生产运行分开评测，变更上线前还需回归检查。

从个人助手走向跨系统交付

Live Intelligence分为Portal、Studio和Console。Portal面向业务人员，Studio提供开发与模型接入能力，Console让管理者观察使用、性能和安全控制。三者解决的不是同一个问题：有人需要完成工作，有人负责设计流程，还有人必须知道系统以什么权限运行、出现异常该如何处理。

简单问答或单次API调用，可以由个人助手承担；一旦任务涉及多个系统、持续状态和失败恢复，工程负担就会增加。人力、法务或IT支持等用途在平台中可以成为不同工作流，但不能因为共用一个模型入口，就省略各自的业务检查与数据接入规则。

Orange选择以LangChain和LangSmith组织编排、追踪与评测，而不是从零重复构建所有基础设施。对实施团队，这类选型最需要比较的是可移植性、调试能力和维护责任，不能只看模型响应是否顺畅。框架能缩短一些工程工作，却不会自动替企业定义流程和授权。

双注册表，把可复用能力从提示词里分出来

Agent注册表负责发现、复用、版本管理和治理。一个团队已经做好的能力，可以作为可管理资产被其他团队使用，而不是让每个部门重新写一份相似提示词。提示版本也按环境维护，修改先测试与验证，再进入生产，不必把每次文案调整都混成代码整体改动。

MCP注册表则组织可信工具、连接器和外部能力，让Microsoft 365、CRM、内部API等通过受控接入层与Agent连接。目录中列出工具，只是开始；真正要沉淀的是谁能调用、能访问哪些对象、如何记录操作，以及接口失败后如何返回明确状态。

把这些约束从各团队的临时提示词里提取出来，可以减少重复实施，但也带来平台级责任。共用工具一旦发生权限配置或版本问题，影响范围可能扩大。因此复用应伴随版本固定、变更通知和回退能力，不能把“统一入口”简单等同于“统一正确”。

回答好不好、动作对不对，要分层评测

Orange在生产中采用三层评测。第一层针对RAG，观察问题答案与预期文档的关系，检查检索召回和回答是否有依据；第二层针对Agent行为，检查工具选择、任务完成、拒绝与业务约束；第三层观察生产轨迹，包括延迟、成本、失败、反馈及升级人工的情况。

这种分法能帮助定位原因。一段回答错误，可能是文档没检索到，也可能是提示词、模型、工具或业务逻辑出了问题。如果只保留最后一句答案，多个团队很容易各自猜测；若能看到执行步骤及输入输出，就能把讨论落在同一份证据上，而不是争论模型“感觉如何”。

部署前的回归检查同样重要：比较不同Agent版本，重放历史案例，验证提示或工具修改没有破坏原有行为。失败案例还可以进入离线评测集，支持后续迭代。上线不是评测的终点，生产中发现的坏例子需要回到下一轮验收，而不是只留在聊天记录里。

业务人员参与提示改进和质量评价，技术团队负责应用与流程实现，这是案例中的协作分工。它不意味着任何业务成员都可直接修改生产Agent。对企业而言，参与改进和批准上线是不同权限，只有分清提出建议、验证效果与执行发布，协作才不会变成新的失控入口。

小编判断：规模化的核心是重复交付同样的边界

这份复盘没有提供足以计算通用ROI的完整基线、采用率和任务收益数据。平台覆盖人数不能直接写成活跃使用，客户数量也不能替代逐个项目的上线验收。材料中规划的更复杂保险等流程，仍应与当前实施区分，不宜当成已经完成的生产案例。

更值得借鉴的是交付组织方式：共用能力有目录与版本，工具有受控接入，质量有分层证据，变更有回归闸门。FDE做成一次试点之后，还要回答第二个部门怎样复用、异常由谁处理、更新如何回退。只有这些问题可以重复解决，企业AI才会从单点演示变成可持续运营的平台。