模块化 AI 架构的接口设计，真正昂贵的地方不在于把系统拆成多个服务，而在于必须为每个模块定义稳定、可验证且能够长期演进的责任边界。接口一旦承载状态、计划、动作或证据，系统就不再只是“模型调用模型”，而是进入了协议治理、数据同步和故障追踪的工程范畴。
接口代价来自四个层面
首先是信息建模成本。一个可用接口不能只传递“执行”或“完成”这类粗粒度信号，还要说明目标实体、前置条件、约束、预期状态和执行反馈。字段越少，模块之间越容易误解；字段越多，协议越难维护，版本兼容和异常处理也越复杂。尤其在具身系统中，高层模型输出的语义动作必须与低层控制器理解的对象、状态和安全约束保持一致，否则拆分只会把错误隐藏在模块之间。
其次是同步与一致性成本。显式世界状态、记忆计划和执行反馈都可能存在更新延迟。模型认为物体已经移动，执行器却尚未完成；计划依据的是旧状态，规则引擎读取的却是新状态。此时，接口必须明确状态版本、更新时间和冲突处理方式。否则，系统虽然拥有更多日志，仍无法判断错误究竟来自感知、规划还是状态同步。
第三是性能成本。模块之间增加了序列化、网络传输、检索和校验环节。高风险任务需要更完整的状态与证据，但更长的数据链路也可能拉高推理延迟。接口设计不能只追求信息完整，还要区分实时路径与审计路径：控制环路保留必要字段，完整轨迹和证据则进入可回放的记录系统。
最后是演进成本。接口一旦被多个模块、团队或供应商依赖，字段变更就不再是局部修改。缺少固定 schema、版本策略和回滚机制时，更换一个模块可能迫使整个系统重新测试甚至重新训练。模块化的承诺，只有在局部替换不破坏全局行为时才成立。
如何判断接口值得付出
接口设计不应以模块数量衡量，而应看它是否降低了定位错误和控制风险的成本。至少要验证：失败能否归因到具体模块，状态和动作能否完整重放，关键规则能否在模型之外强制执行，计划是否支持局部修改，以及证据是否能够与最终断言建立对应关系。
因此，端到端路径仍适合低风险、短流程任务；一旦任务具有长时序、强约束或高合规要求，就应逐步外显状态、计划、反馈和证据。接口不是免费的可解释性装饰，而是用额外的协议、延迟和维护成本，换取可控性与责任追踪。真正成熟的架构，不是接口越多越先进，而是只把那些必须被检查、干预和回放的中间环节设计成稳定接口。