第一个智能体上线时，团队几乎感受不到“平台”的存在：几个人盯着输出、随手改提示词、遇到异常就人工接管，也能跑得不错。真正的问题出现在第二、第三条业务线要复制时：权限重新谈一遍，数据重新接一遍，评测集重新搭一遍，效果好坏还只能靠业务方一句“还行”。这时瓶颈已经不在模型能力，而在平台是否具备了可复制交付的基础设施。
平台能力可以分成三层
最容易被看见的是交付层：统一的开发与编排框架、工具与 API 网关、知识库与检索服务。它们决定复制一个场景到底要多少人天。工具接入如果每次都从零对接，第三条业务线开始成本就会失控；知识治理如果不沉淀，同一个业务概念会在不同场景里被反复定义。
更关键的是治理层，而这一层最容易被低估。智能体注册表值得单独拎出来说：每个上线的智能体都应有唯一负责人、版本号、接入系统清单、权限清单、评测结果和变更记录。缺少这一项，规模化之后企业连“到底有多少个智能体在跑、跑的是哪个版本”都答不上来，治理也就无从谈起。与之配套的是统一权限体系，包括单点登录、基于角色或属性的访问控制、工具级授权、敏感数据脱敏、临时授权与审批。这些能力后补的迁移成本远高于前置建设。
最后一层是验证能力：模型路由与版本管理、日志追踪、评测流水线。它们的价值不在于“能测”，而在于把评测绑定到变更上——模型切换、提示词调整、知识库更新、工具接口变更，都应自动触发一轮核心回归，防止效果在无人察觉时悄悄回退。
先做什么
如果资源有限，优先级应当是注册表、统一权限、评测流水线。原因很实际：它们牵涉跨场景的数据结构和组织约定，越晚做越难统一；而编排界面、开发工具这类能力可以边用边补，业务感知也更直接。
场景复制的顺序同样是一门平台能力。按任务复杂度和自主程度分层，先复制低自主、标准化程度高的场景，再进入需要跨系统执行但规则清晰的流程，最后才碰高自主、高复杂度的任务。顺序颠倒，失败成本会成倍放大，还会消耗业务方对平台的信任。
判断平台能力是否到位，不必看功能清单有多长，看四个信号就够：新场景上线周期是否可控，权限变更是否全程留痕，评测能否在发布前自动运行，故障发生时能否定位到具体智能体、具体工具调用和具体版本。四个都成立，才谈得上复制；有一个不成立，说明平台还停在“能开发”的阶段。