在实现了 multica + brains 的共生系统后，我开始反过来想一个问题：Agent 应用之间到底该怎么调用。它们自己已经有 Agent 模块，能调用 Agent 能力；但与此同时，我又希望它们能彼此连接，甚至被 openclaw 这类前台 Agent 统一管理。这样一来，怎么标准化调用关系，怎么限制、规划和设计大大小小的 Agent 能力边界，就成了一个问题。
过去在微服务和复杂系统里，我们其实已经有一套相对成熟的互联方式：Service Provider 暴露 OpenAPI，Service Client 负责调用，再把多个接口拼成业务流程。这套方式很有效，但它缺少业务语义，调用方往往还是要写很多定制逻辑。
如果把 API 保留给 Provider，把业务规则补进 Skill，再让 Agent 充当 Client，服务间调用也许会变成另一种样子。
传统互联方式，问题不在 API 本身
过去的典型模式很清楚：Service Provider 暴露 OpenAPI，Service Client 基于接口定义生成或编写调用代码，再把多个接口拼成业务流程。这套模式没有问题，它解决的是标准化调用。
但它的缺口也很明显：API 定义的是能力边界，不定义业务规则。 即使是 HATEOAS 或 GraphQL，也更擅长处理资源访问和查询表达，不太擅长直接承载这类业务规则：当订单金额小于 100 时，先查库存，再推荐一个适合“随手加一件”的商品。
这些逻辑以前当然也能做，只是往往要写很多定制代码，把多个 API、业务规则、异常处理和流程判断缝在一起。
Agent 让调用方开始带着业务规则工作
Agent 出现之后，我越来越觉得，应用间互联可能会多出一种新的实现方式：
- Provider 继续暴露 API
- Skill 补上业务规则、用户用例、多个 API 之间的业务联系，以及调用策略
- Agent 作为调用端，加载 skill 后去理解并调用这些能力
也就是说，可以把它粗略理解成：
OpenAPI ≈ Skill + API
我不是想替代 OpenAPI。更像是在说：传统 OpenAPI 主要解决“能不能调”，而 Skill 补上了“在什么业务语境下怎么调”。
Skill 里可以放的不只是接口说明，还可以包括：
- 用户用例
- 一个或多个 API 的业务含义和联系
- 业务上的调用规则
- 技术上的异常处理策略
这样一来，Service Provider 基本不需要变化，真正变化最大的其实是 Client 侧。过去要靠代码实现的大量集成逻辑，未来可能有一部分会转成 Prompt + Skill 驱动的调用和编排。
两种模式：Choreography 和 Orchestration
这件事我觉得可以分别从 Choreography 和 Orchestration 两种模式来看。
在 Choreography 里，没有一个中心编排者。每个应用或服务仍然像微服务一样协作，只是 Service Client 不再只是硬编码逻辑，而可以由 Agent + Skill 来承担，因此调用会更语义化、更业务化。
在 Orchestration 里，我觉得更有意思：位于中心的管理者，甚至可以完全由 Agent 来实现。也就是一个 Supervisor Agent，在掌握必要上下文之后，去自主调用各个应用和服务，完成原本需要大量 Client 代码才能完成的集成流程。
说“0 代码开发”肯定是夸张了。更接近的说法是：在 Service Provider 已经提供标准 API 的前提下，Client 侧那部分定制化集成代码，可能被 Agent + Skill 大幅替代或减少。
我现在更倾向于这样理解它
这还是一个很早期的个人想法，但我现在越来越倾向于这样看：Agent 不只是给现有应用加一个智能模块，它也可能成为下一代 Service Client。
如果这个方向成立，未来应用间互联要开放的，可能就不只是接口，还有能力和业务规则。
Needs Verification
Skill的最小可复用结构，还需要更多实践验证。- 哪些 Client-side 集成逻辑适合被 Agent 替代，哪些仍然应该保留在代码里，需要更清晰的边界。
- Supervisor Agent 在真实生产场景下的可靠性、审计和失败处理，还需要更多样本。