What feature would you like to see?
Context / 背景
我在做一些工具，把 Kimi CLI 当作执行引擎；我也希望参与 Kimi CLI 开发贡献。
I’m building tooling that uses Kimi CLI as an execution engine, and I’d like to contribute to Kimi CLI.
在提交 PR 之前，我想先确认：网页端的 Agent Swarm 能力，未来是否会以“可调用接口”的形式向 CLI/ACP/Wire 开放。
Before drafting PRs, I want to clarify whether the web “Agent Swarm” capability is planned to be exposed as a supported callable interface via CLI / ACP / Wire.
Main question / 核心问题
Kimi CLI 是否计划提供一个稳定、可集成的 Swarm API（不要求 UI 形态一致，但希望能被外部工具调用与编排）？
Is there a plan for Kimi CLI (or ACP/Wire) to expose a stable, supported, callable Swarm API (UI parity not required, but callable/orchestratable by third-party tools)?
Clarifying questions / 细化问题
如果会开放：预计以什么 surface 形式？（CLI command / ACP endpoint / Wire protocol events 等）
If yes: what’s the intended surface (CLI command / ACP endpoint / Wire protocol events, etc.)?
如果不会开放：官方更推荐社区走哪条路？（把 CLI 当黑盒单 agent 执行器，在外部实现 orchestrator？）
If no: is the recommended approach to treat CLI as a black-box single-agent executor and implement orchestration externally?
如果会但不在近期：能否给一个最小路线图/拆分思路（例如先开放事件流/状态，再考虑 nesting / roles 等）？
If planned but not soon: is there a minimal roadmap (e.g., events/state first, then nesting/roles later)?
Why this matters / 为什么问这个
这会决定我（以及社区）贡献的方向：是优先补齐 Swarm 的可调用接口/事件流，还是只做 coding UX 和工程稳定性。
This determines whether community contributions should focus on exposing swarm primitives/events vs. improving coding UX and stability only.
Additional information
No response
What feature would you like to see?
Context / 背景
我在做一些工具，把 Kimi CLI 当作执行引擎；我也希望参与 Kimi CLI 开发贡献。
I’m building tooling that uses Kimi CLI as an execution engine, and I’d like to contribute to Kimi CLI.
在提交 PR 之前，我想先确认：网页端的 Agent Swarm 能力，未来是否会以“可调用接口”的形式向 CLI/ACP/Wire 开放。
Before drafting PRs, I want to clarify whether the web “Agent Swarm” capability is planned to be exposed as a supported callable interface via CLI / ACP / Wire.
Main question / 核心问题
Kimi CLI 是否计划提供一个稳定、可集成的 Swarm API（不要求 UI 形态一致，但希望能被外部工具调用与编排）？
Is there a plan for Kimi CLI (or ACP/Wire) to expose a stable, supported, callable Swarm API (UI parity not required, but callable/orchestratable by third-party tools)?
Clarifying questions / 细化问题
如果会开放：预计以什么 surface 形式？（CLI command / ACP endpoint / Wire protocol events 等）
If yes: what’s the intended surface (CLI command / ACP endpoint / Wire protocol events, etc.)?
如果不会开放：官方更推荐社区走哪条路？（把 CLI 当黑盒单 agent 执行器，在外部实现 orchestrator？）
If no: is the recommended approach to treat CLI as a black-box single-agent executor and implement orchestration externally?
如果会但不在近期：能否给一个最小路线图/拆分思路（例如先开放事件流/状态，再考虑 nesting / roles 等）？
If planned but not soon: is there a minimal roadmap (e.g., events/state first, then nesting/roles later)?
Why this matters / 为什么问这个
这会决定我（以及社区）贡献的方向：是优先补齐 Swarm 的可调用接口/事件流，还是只做 coding UX 和工程稳定性。
This determines whether community contributions should focus on exposing swarm primitives/events vs. improving coding UX and stability only.
Additional information
No response