Proposal: Agent-first design direction for Apollo / 提案：Apollo 的 Agent-First 设计方向

**Is your feature request related to a problem? Please describe.**

Apollo already provides Portal workflows, OpenAPI, and consumer token support for configuration management. However, its current control plane is still primarily oriented toward human operators, while automation is treated as a secondary access path.

As AI agents begin to participate in software delivery workflows, Apollo does not yet provide a native product model for agent-driven operations. In particular:

- machine access is still mainly represented as `Consumer + static token`
- some write APIs still rely on human-oriented fields such as `releasedBy`, `operator`, and `dataChangeCreatedBy`
- Apollo does not yet expose a clear agent-oriented control surface covering identity, execution context, delegation, governance, and audit
- the current automation model is still closer to "script access to existing APIs" than a first-class agent model

From this perspective, Apollo may benefit from a broader agent-first design direction, rather than only incremental API extensions.

**Describe the solution you'd like**

I would like Apollo to explore an **agent-first design direction**.

A possible direction would be:

- introduce `Agent` as a principal distinct from `User` and `Consumer`
- provide a clearer control plane for agent-driven operations
- model agent identity, session, delegation, policy, and audit more explicitly
- make governance a native part of the product model where appropriate
- provide official tooling for this direction, likely starting with a CLI and evaluating MCP later

To keep the first iteration practical, Apollo could start from a limited subset of agent-facing capabilities while keeping the broader design direction open.

At the same time, existing OpenAPI v1 and consumer-based automation flows should remain compatible.

**Describe alternatives you've considered**

A few alternatives that were considered:

- extending `Consumer` directly instead of introducing `Agent`
- keeping governance concerns entirely outside Apollo
- treating agent support only as a tooling layer on top of existing APIs
- starting with MCP first instead of CLI first

At the moment, a more suitable path seems to be:

- keep `Consumer` and `Agent` separate at first
- let Apollo gradually introduce native agent-oriented capabilities if this direction is accepted
- start with a simpler official tool surface first, then evaluate broader protocol integrations later

**Additional context**

Some preliminary implementation thoughts:

- new public API contracts could be defined in `apollo-openapi`
- the main control-plane implementation could live in `apollo-portal`
- `apollo-agent-cli` could initially stay in the main `apollo` monorepo and be published as an independent artifact or binary

---

**你的特性请求和某个问题有关吗？请描述**

Apollo 当前已经具备 Portal、OpenAPI 和 consumer token 等配置管理能力，但整体控制面仍然主要围绕人工操作设计，自动化更多是作为附加访问路径存在。

随着 AI Agent 开始参与软件交付流程，Apollo 目前还没有为 agent 驱动的操作提供一种原生的产品模型。比较明显的点包括：

- 机器访问目前主要还是 `Consumer + 静态 token`
- 一些写接口仍然依赖 `releasedBy`、`operator`、`dataChangeCreatedBy` 等面向人工操作的字段
- Apollo 还没有形成一套清晰的、面向 agent 的控制面，去承载身份、执行上下文、委托关系、治理和审计等能力
- 当前自动化模型整体上更接近“脚本调用现有 API”，而不是一套一等公民级别的 agent 模型

从这个角度看，Apollo 也许值得探索一个更宽泛的 agent-first 设计方向，而不仅仅是在现有 API 上做增量扩展。

**清晰简洁地描述一下你希望的解决方案**

我希望 Apollo 可以探索一个 **agent-first 的设计方向**。

一个可能的方向是：

- 引入 `Agent`，并将其与 `User`、`Consumer` 区分开
- 为 agent 驱动的操作提供一套更明确的控制面
- 更显式地建模 agent 的身份、session、委托关系、策略和审计
- 在合适的范围内，让治理能力成为 Apollo 原生产品模型的一部分
- 提供适合这类方向的官方工具，初期可以先从 CLI 开始，后续再评估 MCP

为了让第一阶段更现实，Apollo 可以先从一小部分面向 agent 的能力开始演进，同时保持整体设计方向的开放性。

同时，现有 OpenAPI v1 和 consumer 自动化流程应继续保持兼容。

**清晰简洁地描述一下这个特性的备选方案**

目前也考虑过几种替代方案：

- 不引入 `Agent`，而是直接扩展现有 `Consumer`
- 将治理相关问题完全继续放在 Apollo 外部
- 只把 agent 支持看成现有 API 之上的一层工具封装
- 不从 CLI 开始，而是优先做 MCP

现阶段看，比较合适的路径可能是：

- 初期先把 `Consumer` 和 `Agent` 作为不同模型看待
- 如果社区认可这个方向，Apollo 再逐步引入原生的 agent 能力
- 先从更简单的官方工具形态开始，后续再评估更广泛的协议集成

**其它背景**

一些初步实现想法包括：

- 新的公共 API 合同可以定义在 `apollo-openapi`
- 主要控制面实现可以放在 `apollo-portal`
- `apollo-agent-cli` 初期可以保留在 `apollo` 主仓库中，并作为独立 artifact 或二进制发布