智能体平台的设计原则：把五类变化隔在平台里

智能体平台，指的是把模型、工具、权限、上下文与编排这五类容易变化的部分集中管理，让上层的业务流程不必因为底层更换模型或新增工具而重做。它常被理解成一份功能清单，其实更像一道隔离层：判断平台做得好不好，方法是看一次底层变化会让多少上层工作跟着重做

五类变化

• 模型：能力、价格与可用性都在变，换模型不该影响业务逻辑。
• 工具与接口：业务系统升级、接口调整、字段增删是常态。
• 权限与身份：人员变动、岗位调整与组织重组都会影响可见范围。
• 上下文与知识：内容持续更新，来源与格式也在增加。
• 编排与流程：业务规则会调整，步骤的先后与分支随之变化。

这五类变化的共同点是：它们都来自平台之外，而且一定会发生。把应对它们的工作当成一次性项目，过几个月就要重来一遍，而且每一次都由不同的团队各自处理，标准很难一致。

平台的职责

• 统一接入：模型、工具与数据源用同一套方式接入，换掉其中一个不影响调用方。
• 统一身份：谁在调用、代表谁、能访问什么，由平台集中判断。
• 统一记录：每次调用留下输入、输出、依据与时间，供复核与审计。
• 统一降级：模型或工具不可用时，有一致的降级与提示方式，而不是每个流程各写一套。
• 统一评估：用同一套问题集衡量改动前后的效果，而不是凭感觉判断。

与业务系统的边界

平台不持有业务事实。库存、订单、客户与合同的状态一律以业务系统为准，平台只做读取与编排。这条边界建立不起来的典型症状，是平台里出现了第二份数据 —— 两边不一致时，谁也说不清以哪边为准。

同样，平台也不应当承担业务规则的最终解释权。规则怎么定由业务方确认，平台负责把它落成可执行的步骤，并保证每一步都可追溯。把解释权收到技术侧，短期推进快，长期会积累大量无人认账的判断。

五类变化里先做哪一层

最先需要被隔离的是权限与记录。它们不影响功能能不能跑通，却决定了这套东西能不能被审计 —— 等业务流程都建好之后再来补，改动面会大很多。相比之下，编排的抽象可以晚一点做，因为流程本身还在调整，过早抽象往往要推倒重来。

什么时候算过度设计

把五类变化全部抽象一遍，也会带来另一种问题：接口层数太多，一处改动要在多个地方同步。判断标准很实际 —— 如果某类变化在过去一年里只发生过一次，就不必为它专门做一层。

验收口径

• 更换模型或新增一个工具时，不需要改业务侧的处理流程。
• 每一次调用都能查到它用了哪些工具与知识、依据是什么。
• 权限判断集中在一处，而不是各流程自行实现。
• 平台里不存在与业务系统不一致的第二份业务数据。