You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue makes Maka an ACP client, allowing users to run an external agent inside Maka Desktop. Google Antigravity is the first concrete integration and acceptance case.
Users need to select an external execution agent, authenticate it, and use it through Maka's existing conversation interface. Adding each agent as a bespoke chat integration would duplicate session, interaction, history, and UI logic. Treating a complete external agent as an AI SDK model provider would also conflate agent-owned execution with Maka-owned model/tool execution.
This work does not expand the server scope of #3132 or restore the retired gemini-cli / Antigravity account-provider preview from #3054. The new integration uses Google's official ACP agent as a separate execution backend.
Desired outcome
User-visible result
A user can configure a locally installed official Antigravity ACP executable, sign in with Google, select Antigravity and a model in the Maka Desktop composer, and complete a coding task through Maka. The existing conversation surface shows streamed replies, tool activity, output, file diffs, permission choices, and agent questions. The user can stop execution and, after restarting, resume the same external session.
The Antigravity process runs behind Maka; this does not embed the Antigravity IDE.
Desktop design: a unified executor and model picker
Extend the existing composer model entry instead of adding a separate “Maka vs. external agent” toggle. The trigger shows the selected executor icon and model. Its popover has an executor rail on the left and that executor's model choices on the right:
[Executor icon · Model name v] [Supported mode v]
+--------------------+--------------------------------+
| Execution agent | Search models |
| | |
| * Maka | Models for this executor |
| Antigravity | Model A |
| | * Model B |
| | Model C |
| | |
| Manage agents | Connection state / setup |
+--------------------+--------------------------------+
Selecting the left rail browses an executor; selecting a model commits the complete executor/model choice and closes the popover.
The Maka branch retains its existing connection groups and model choices. The Antigravity branch uses models returned by its account/session configuration, without inventing an LLM connection.
An unconfigured or unauthenticated Antigravity entry can show setup/login actions, but cannot be committed as an executable selection.
Initially, Maka does not override the model or mode: use the current values returned when the ACP agent creates a session. Show the concrete values when available and an honest “Agent default” label otherwise. This does not promise to inherit the user's Antigravity IDE model selection. Verify that omission is supported; if the agent requires explicit configuration, include the necessary selection and application in PR 2 rather than deferring them to PR 4.
New drafts retain Maka's existing defaults. Do not add new global remembered-selection or project-precedence rules in this scope.
Switching executors preserves draft text and attachments. Unsupported attachments remain visible with an actionable validation message; they are not silently removed or sent.
Once a task exists, its executor is fixed. Model changes are allowed only while idle and when supported. Other executors explain that switching requires a new task.
Do not copy T3's favorites, multi-account management, or entire advanced-settings surface.
Desktop surface
Change
Settings
Add External Agents for official installation or existing-program selection, connection checks, Google sign-in, and diagnostics.
Composer
Extend the existing model entry with the unified picker; show only supported mode controls.
Conversation
Reuse existing message, tool-output, and diff presentation.
Interaction area
Reuse forms for external permission options and agent questions.
Task/history surface
Identify the executor and show interrupted, restoring, and restore-failed states.
Task Entry continues to supply the Host/project target. Executor selection and submission belong to the existing composer/task-creation flow, not a new responsibility inside Task Entry.
AcpAgentBackend is a sibling of AiSdkBackend, not an AI SDK provider or a layer inside it. Maka owns task/run identity, admission, persistence, subscriptions, and interactions. Antigravity owns its reasoning loop, tools, and execution context.
Register the ACP implementation and use prepare/build/send/stop/dispose.
SessionManager and Host execution coordination
Keep task creation, turn admission, stop, and retirement in the existing authority.
SessionEvent to RuntimeEvent mapping, stores, and subscriptions
Convert ACP updates into the existing event pipeline; do not add an ACP transcript store.
HostedInteractionBridge and InteractionCoordinator
Reuse admission, answers, closure, and settlement.
Settings request and presentation infrastructure
Reuse loading, write guards, action guards, browser opening, errors, and status presentation.
Existing tool and file_diff presentation
Adapt data rather than create an Antigravity-specific renderer.
History pagination and reading-position control
Continue consuming the canonical Maka transcript.
Start with an internal ACP module in Runtime Host, not a new workspace package. Use the official ACP SDK rather than reimplement JSON-RPC. Separate shared connection/session handling from Antigravity-specific launch, authentication, and compatibility logic, but introduce extension hooks only when used. Settings checks and task execution are real consumers of the shared connection code.
Future standard ACP agents should reuse this implementation through configuration and, where necessary, small agent-specific adaptations. A future non-ACP agent can implement its own sibling backend. Do not prebuild an unused plugin/capability framework.
Existing OAuth and model UI contracts contain LLM-provider assumptions. Reuse their lower-level presentation and lifecycle primitives, but do not fabricate provider identities to force ACP authentication or model selection through them.
Protocol, interaction, and lifecycle rules
Use a local stdio connection and one external process per active task, owned by the Host. In PR 2, an active task includes a live session waiting for its next turn: retain its process while idle. Closing the UI does not implicitly stop a task. Retirement and Host shutdown clean up owned processes, including owned helpers. PR 2 must handle crashes, cancellation races, and cleanup itself; process loss leaves readable history with continuation explicitly unavailable until restoration is delivered.
Convert text, tool activity, output, diffs, and completion into existing backend events. Merge partial updates by tool-call ID and preserve arrival order. Add shared event fields only with a same-PR producer and consumer.
External tool notifications are observations, not instructions for Maka to execute the same tool. Do not fabricate Maka tool-dispatch journal entries.
Use HostedInteractionBridge.admitFormRequest for external option-based interactions. Map the ACP option ID to the form's single_select.value and its display text to label; return the original ID through the existing settlement path.
Clearly identify external permission requests and preserve the agent's allow/deny choices. Do not reinterpret them as Maka sandbox grants or route them through legacy permission events. Antigravity-specific question detection stays in its adaptation code.
Implement the verified, necessary ACP text-file callbacks with workspace/path/symlink checks. Do not advertise terminal capability. Do not claim that agent-owned tools run inside Maka's built-in sandbox.
Cancellation settles outstanding interactions, sends ACP cancel, and continues consuming updates until the prompt finishes. A bounded timeout terminates the owned process and records interruption rather than false successful cancellation. Preserve the actual stop reason.
Maka stores visible history; the external agent owns its execution context. A crash does not automatically resend a prompt.
Restore through negotiated resume/load support. Load replay is handled as restoration, not appended as a new turn. Define replay deduplication and reconciliation when the agent has progressed beyond Maka's last durable event; do not blindly discard or append all replay. If history cannot be reliably aligned, show an explicit history-gap/restoration status instead of claiming intact history. Failure keeps history readable and offers retry/new task without silently replacing the external session or resending a prompt.
Use a Maka-managed or user-installed official Antigravity ACP distribution, including its matching helper. The official process owns credentials. Do not assume IDE login is reusable.
PR1 setup behavior has now been exercised with official ACP 1.1.1 on macOS arm64; see #5164. Task execution, model/mode and restoration behavior are not established by these setup checks. Record and verify the actual version/platform, authentication, event shapes, cancellation, and restoration before relying on them. T3's Antigravity adapter is an implementation reference, not a substitute for real-agent acceptance.
Pre-implementation verification
Verify the official binary before implementing the behavior that depends on it; record the actual version/platform and sanitized evidence. Reference code and negotiated protocol support do not replace real-agent checks.
Before PR 1 authentication: verify official server/helper layout, initialization, authentication methods, authorization-link output, authentication completion and process exit. Connection checks must not log in, create a session or send a prompt. PR1 setup evidence is recorded in feat(desktop): install and configure Antigravity ACP #5164.
Before PR 2 execution: verify session creation, omitted model/mode initialization, required file callbacks, text/tool/diff/permission/question events, multi-turn prompting and cancellation. Probe cross-process resume/load feasibility here as well, so the task binding does not assume unverified restoration behavior.
Before PR 3 restoration: verify restoration of the same session across process restarts, replay shape, deduplication and crash-window reconciliation before implementing persistence/restoration behavior.
Before PR 4 configuration: verify actual model/mode discovery, selection/application and failure behavior. Configuration required to execute belongs in PR2 and must be verified there.
If required behavior is unavailable, revise that PR's scope and acceptance criteria before implementation. Do not record credentials or private project content. Completing PR1 setup checks does not mark task, model or restoration behavior as verified.
Incremental PR plan
Implement the following in order: settings/authentication → complete execution → restoration → dynamic models/modes. Restoration precedes dynamic selection because it determines session continuity and future process-reclamation options; optional model selection can wait when agent-selected initialization has been verified.
Each PR is independently deliverable and verifiable, but may depend on already merged PRs. Every new production interface, field, or capability must have a real producer and consumer in that same PR, including its necessary protocol, storage, Host, and Desktop changes. A mock/test consumer or a promised later PR does not satisfy this requirement. Update protocol decoders and the compatibility epoch whenever required.
Reuse RuntimePolicy read/write, revision protection and migration, existing Settings and Host setup operations; limit setup to the local macOS arm64 Host.
Provide Install for the pinned official Google ACP 1.1.1 distribution and its matching helper. Reuse the configured proxy; verify archive size/SHA-256 and executable hashes, publish a versioned installation atomically, and reuse a verified managed copy. Clean staging on failure/cancellation.
After installation, check ACP and save the executable through the existing Settings mutation. A changed configuration or Host target invalidates late results.
Read an existing saved configuration; offer Choose existing program through the native file picker for independently installed ACP. Keep this action visible beside Install/Reinstall in both configured and unconfigured states, explain that an existing ACP needs no reinstall, and save the native picker result immediately through the existing Settings mutation. Remove the path editor and Advanced settings foldout. Do not scan disks/PATH or treat an installed Antigravity IDE as an ACP installation.
Follow Maka's Models-style branded agent list and Settings rows. Show the official download source, inline progress/cancel/retry, separate connection and Google-account status, and English/Simplified Chinese/Traditional Chinese text. Configured does not mean authenticated.
Directly consume the internal ACP SDK connection and verified Antigravity adaptation from setup install/check/login operations. Reuse oauth_presentation and Host residency/drain/shutdown; release temporary server/helper processes on success, failure, cancellation and disconnect. Official credentials remain owned by Antigravity.
Cover controlled stdio, installer integrity/cleanup, persistence and stale-result guards; run affected package tests, typecheck, architecture and protocol compatibility checks.
Record real official 1.1.1 configuration, connection, Google login, restart/relogin and cleanup; additionally verify real Desktop download cancellation/retry, managed installation, automatic save and handshake. See feat(desktop): install and configure Antigravity ACP #5164 and its verification document. The newer login after managed installation has no captured terminal result and is not counted as another successful authentication.
Give setup browser presentation a bounded window covering initialization/authentication, release it on terminal/cancel, and test delayed links, expiry and unchanged regular OAuth behavior.
Complete setup-flow acceptance using the existing verified official program: Settings save → connection check → Google login success → cancel a live login → Retry → login success; no temporary server/helper remained at terminal results. The user explicitly requested skipping the repeated slow download and reusing /tmp. Earlier managed installation/automatic-save evidence remains separate; this does not claim another fresh full download. Acceptance evidence and screenshots (including the subsequent layout refinement): feat(desktop): install and configure Antigravity ACP #5164.
Boundary: no task backend/executor types, session/prompt/restore fields, model catalog, new workspace package, automatic discovery, automatic upgrades or multi-account support. User-triggered managed installation is included in PR1 and supersedes the original installation exclusion.
Acceptance: install or choose an existing official program → save → check → Google sign-in → cancel/retry, with actionable failures and no temporary-process leaks. Installation does not create sessions or send prompts.
PR 2 — Unified picker and a complete task-execution slice
Extend the current composer model entry with the two-column picker. Preserve the Maka model branch; Antigravity initially offers “Use agent default” only after verifying that the agent accepts omitted model/mode configuration. Use the session's returned current values without promising to inherit IDE settings. If explicit configuration is required, deliver the necessary selection and application in this PR.
Connect unavailable/setup states to PR 1's settings flow.
Add executor selection, task binding, external admission without a Maka LLM connection, and registered AcpAgentBackend together.
Implement session creation, multi-turn prompting, text/tool/output/diff projection, form-based permissions/questions, stop, failure states, and process cleanup.
Implement required file callbacks and gate unsupported operations in both Host admission and UI.
Intermediate behavior: verified agent-initialized model/mode (or required explicit configuration); live-session multi-turn execution with processes retained while idle. After restart or process loss, history is readable, but continuation is explicitly unavailable. Crash states, cancellation races, and owned-process/helper cleanup are complete in this PR.
Acceptance: real read/edit/test/follow-up, diff display, permission rejection, questions, cancellation, persistence, draft preservation, and task isolation.
PR 3 — Restore sessions and process reconstruction
Write and consume the necessary external session identity/restoration metadata in this same PR through backend preparation. Tasks created under PR 2 without this metadata remain readable but cannot resume; never create a replacement external session for them silently.
Restore when the user continues a task; loading the task list must not launch all agents.
Use verified resume/load support. Implement replay deduplication and crash-window reconciliation with canonical history, including an explicit history-gap state when reliable alignment is impossible. Never automatically resend an interrupted prompt.
Reuse task readiness, history, and composer state for restoring/failure, retry, and new-task actions.
Complete installation, login, limitations, and troubleshooting documentation.
Acceptance: restart and continue the same real external session with intact context and no duplicate history; failed restoration does not resend prompts, switch backend, or silently start a replacement session.
PR 4 — Dynamic models and supported modes
This extends the current executor's configuration; it never switches an existing task's executor. It may follow the core integration release if verified agent-initialized configuration is sufficient. Any configuration required to execute already belongs in PR 2.
Populate PR 2's existing picker with Antigravity's actual models; use the current configuration area for supported modes.
If discovery requires a session, use a configuration probe session in the selected workspace only when the user explicitly browses that executor. Release it after discovery; do not create a Maka task or send a prompt. Existing tasks read their own session configuration.
Apply a new task's selection before its first prompt; allow existing-task changes only while idle.
Update values after agent confirmation, retain the old value on failure, and revalidate selection at actual creation. Never silently substitute a model after account/catalog changes.
Producer → consumer: catalog/configuration → existing picker/mode controls → ACP configuration → current value and execution.
Acceptance: selected configuration affects execution; unavailable models cannot send; browsing does not commit a selection or create a task; keyboard navigation, focus return, narrow windows, and localized states work.
Final acceptance criteria
The complete Desktop path works with a recorded official Antigravity version: configure → Google sign-in → select Antigravity/model → create task → edit and test → inspect tools/diffs → answer interactions → follow up → cancel → restart and continue.
Draft browsing and committed executor/model selection are distinct; existing tasks cannot change executor.
Unsupported attachments and controls are handled explicitly without losing draft content.
Real-agent checks cover authentication and actual tool/session behavior; fixtures do not contain tokens or private project content.
Existing Maka execution remains functional, and shared ACP dependency changes preserve maka --acp server behavior.
Every new production interface, field, or capability has a real consumer in the same PR; existing seams are used before introducing another abstraction.
Initial scope
Local Maka Desktop on macOS arm64, local Runtime Host, and an official Antigravity ACP process installed through an explicit Install action or selected by the user. Out of scope: automatic discovery/upgrades, remote execution/OAuth forwarding, multi-account management, external subagent orchestration, steering, rewind, and cross-agent continuation. TUI product work is deferred while the Host implementation remains reusable.
Alternatives or workarounds
Use Antigravity separately: possible today, but does not provide the unified Maka task/history/interaction experience.
Wrap Antigravity as an AI SDK model provider: rejected because a complete agent owns session state and tools, unlike a model call. Use a sibling AgentBackend implementation instead.
Build a separate external-agent chat stack: rejected because Maka already has execution, interaction, persistence, and presentation seams.
Embed the IDE or wrap the ordinary CLI: unnecessary for this scope because an official ACP distribution exists.
Implement infrastructure-only PRs before wiring UI consumers: rejected; the PRs above deliver vertical production slices.
This proposal was prepared with AI assistance from the design discussion. Real-binary verification remains an explicit implementation and acceptance requirement.
English
Problem
This is a follow-up tracking issue for #3132, specifically the ACP client / Antigravity use case.
The two directions are distinct:
maka --acp.Users need to select an external execution agent, authenticate it, and use it through Maka's existing conversation interface. Adding each agent as a bespoke chat integration would duplicate session, interaction, history, and UI logic. Treating a complete external agent as an AI SDK model provider would also conflate agent-owned execution with Maka-owned model/tool execution.
This work does not expand the server scope of #3132 or restore the retired
gemini-cli/ Antigravity account-provider preview from #3054. The new integration uses Google's official ACP agent as a separate execution backend.Desired outcome
User-visible result
A user can configure a locally installed official Antigravity ACP executable, sign in with Google, select Antigravity and a model in the Maka Desktop composer, and complete a coding task through Maka. The existing conversation surface shows streamed replies, tool activity, output, file diffs, permission choices, and agent questions. The user can stop execution and, after restarting, resume the same external session.
The Antigravity process runs behind Maka; this does not embed the Antigravity IDE.
Desktop design: a unified executor and model picker
Follow the interaction structure of T3 Code's ProviderModelPicker and ModelPickerSidebar, using Maka's existing UI primitives and styling.
Extend the existing composer model entry instead of adding a separate “Maka vs. external agent” toggle. The trigger shows the selected executor icon and model. Its popover has an executor rail on the left and that executor's model choices on the right:
Task Entry continues to supply the Host/project target. Executor selection and submission belong to the existing composer/task-creation flow, not a new responsibility inside Task Entry.
Architecture: reuse existing seams
flowchart TD UI[Maka Desktop] --> Host[Runtime Host] Host --> Backend[AgentBackend] Backend --> Native[AiSdkBackend] Native --> SDK[AI SDK / models] Backend --> ACP[AcpAgentBackend] ACP --> Client[ACP SDK connection and session handling] Client --> Profile[Antigravity adaptation] Profile --> Agent[Official Antigravity ACP process]AcpAgentBackendis a sibling ofAiSdkBackend, not an AI SDK provider or a layer inside it. Maka owns task/run identity, admission, persistence, subscriptions, and interactions. Antigravity owns its reasoning loop, tools, and execution context.AgentBackend,BackendRegistry,PreparedBackendFactorySessionEventtoRuntimeEventmapping, stores, and subscriptionsHostedInteractionBridgeand InteractionCoordinatorfile_diffpresentationStart with an internal ACP module in Runtime Host, not a new workspace package. Use the official ACP SDK rather than reimplement JSON-RPC. Separate shared connection/session handling from Antigravity-specific launch, authentication, and compatibility logic, but introduce extension hooks only when used. Settings checks and task execution are real consumers of the shared connection code.
Future standard ACP agents should reuse this implementation through configuration and, where necessary, small agent-specific adaptations. A future non-ACP agent can implement its own sibling backend. Do not prebuild an unused plugin/capability framework.
Existing OAuth and model UI contracts contain LLM-provider assumptions. Reuse their lower-level presentation and lifecycle primitives, but do not fabricate provider identities to force ACP authentication or model selection through them.
Protocol, interaction, and lifecycle rules
HostedInteractionBridge.admitFormRequestfor external option-based interactions. Map the ACP option ID to the form'ssingle_select.valueand its display text tolabel; return the original ID through the existing settlement path.PR1 setup behavior has now been exercised with official ACP 1.1.1 on macOS arm64; see #5164. Task execution, model/mode and restoration behavior are not established by these setup checks. Record and verify the actual version/platform, authentication, event shapes, cancellation, and restoration before relying on them. T3's Antigravity adapter is an implementation reference, not a substitute for real-agent acceptance.
Pre-implementation verification
Verify the official binary before implementing the behavior that depends on it; record the actual version/platform and sanitized evidence. Reference code and negotiated protocol support do not replace real-agent checks.
If required behavior is unavailable, revise that PR's scope and acceptance criteria before implementation. Do not record credentials or private project content. Completing PR1 setup checks does not mark task, model or restoration behavior as verified.
Incremental PR plan
Implement the following in order: settings/authentication → complete execution → restoration → dynamic models/modes. Restoration precedes dynamic selection because it determines session continuity and future process-reclamation options; optional model selection can wait when agent-selected initialization has been verified.
Each PR is independently deliverable and verifiable, but may depend on already merged PRs. Every new production interface, field, or capability must have a real producer and consumer in that same PR, including its necessary protocol, storage, Host, and Desktop changes. A mock/test consumer or a promised later PR does not satisfy this requirement. Update protocol decoders and the compatibility epoch whenever required.
PR 1 — Install, configure, connect, and authenticate from Settings — implemented in feat(desktop): install and configure Antigravity ACP #5164; check this item after merge.
oauth_presentationand Host residency/drain/shutdown; release temporary server/helper processes on success, failure, cancellation and disconnect. Official credentials remain owned by Antigravity./tmp. Earlier managed installation/automatic-save evidence remains separate; this does not claim another fresh full download. Acceptance evidence and screenshots (including the subsequent layout refinement): feat(desktop): install and configure Antigravity ACP #5164.PR 2 — Unified picker and a complete task-execution slice
AcpAgentBackendtogether.PR 3 — Restore sessions and process reconstruction
PR 4 — Dynamic models and supported modes
Final acceptance criteria
maka --acpserver behavior.Initial scope
Local Maka Desktop on macOS arm64, local Runtime Host, and an official Antigravity ACP process installed through an explicit Install action or selected by the user. Out of scope: automatic discovery/upgrades, remote execution/OAuth forwarding, multi-account management, external subagent orchestration, steering, rewind, and cross-agent continuation. TUI product work is deferred while the Host implementation remains reusable.
Alternatives or workarounds
AgentBackendimplementation instead.This proposal was prepared with AI assistance from the design discussion. Real-binary verification remains an explicit implementation and acceptance requirement.
中文
问题
这是 #3132 的后续追踪 issue，对应其中提出的 ACP client / Antigravity 使用案例。
两个方向需要区分：
maka --acp将 Maka 暴露为 ACP Agent / 服务端。用户需要选择外部执行者、完成认证，并通过 Maka 现有聊天界面使用它。如果每接入一个 Agent 都单独实现聊天集成，就会重复建设会话、交互、历史和 UI。如果将完整外部 Agent 当作 AI SDK 模型 provider，则会混淆外部 Agent 自己管理的执行循环与 Maka 管理的模型调用和工具执行。
本方案不扩大 #3132 的服务端范围，也不恢复 #3054 已退役的
gemini-cli/ Antigravity 账户 provider 预览。新的接入方式是将 Google 官方 ACP Agent 作为独立执行 backend。期望结果
用户最终看到的效果
用户配置本地安装的官方 Antigravity ACP 程序，完成 Google 登录，在 Maka Desktop 输入框中选择 Antigravity 和模型，然后通过 Maka 完成编码任务。现有聊天界面展示流式回复、工具活动、输出、文件 diff、权限选项和 Agent 提问。用户可以停止执行，并在重启后恢复同一个外部会话。
Antigravity 进程在 Maka 后台运行，不嵌入 Antigravity IDE。
Desktop 设计：统一的执行者与模型选择器
参考 T3 Code 的 ProviderModelPicker 与 ModelPickerSidebar 的交互结构，使用 Maka 已有 UI 基础组件与样式实现。
扩展现有 Composer 模型入口，不增加独立的“Maka / 外部 Agent”开关。按钮显示当前执行者图标和模型，展开后左侧切换执行者，右侧显示其模型：
Task Entry 继续提供 Host 与项目目标。执行者选择及提交属于现有 Composer / 任务创建流程，不向 Task Entry 加入新的会话创建职责。
架构：复用已有 seam
flowchart TD UI[Maka Desktop] --> Host[Runtime Host] Host --> Backend[AgentBackend] Backend --> Native[AiSdkBackend] Native --> SDK[AI SDK / 模型] Backend --> ACP[AcpAgentBackend] ACP --> Client[ACP SDK 连接与会话处理] Client --> Profile[Antigravity 适配] Profile --> Agent[官方 Antigravity ACP 进程]AcpAgentBackend与AiSdkBackend并列，不是 AI SDK provider，也不位于AiSdkBackend内部。Maka 管理任务和 run 身份、执行准入、持久化、订阅与交互；Antigravity 管理自身推理循环、工具和执行上下文。AgentBackend、BackendRegistry、PreparedBackendFactorySessionEvent到RuntimeEvent的映射、存储与订阅HostedInteractionBridge与 InteractionCoordinatorfile_diff展示首期在 Runtime Host 内增加内部 ACP 模块，不提前新建 workspace package。使用官方 ACP SDK，不重新实现 JSON-RPC。共享连接和会话处理与 Antigravity 启动、认证、兼容逻辑分开，但仅在实际使用时增加扩展点。设置检查与任务执行是共享连接代码的真实消费者。
未来标准 ACP Agent 优先通过配置复用，必要时增加小范围厂商适配；非 ACP Agent 可以实现并列的 backend。不提前建设无人使用的插件或能力框架。
已有 OAuth 和模型 UI 契约包含 LLM provider 假设。复用底层展示与生命周期基础能力，但不通过伪造 provider 身份强行接入 ACP 认证或模型选择。
协议、交互与生命周期规则
HostedInteractionBridge.admitFormRequest。ACP option ID 映射为表单single_select.value，显示文本映射为label，通过现有结算路径回传原始 ID。PR1 设置流程已使用 macOS arm64 官方 ACP 1.1.1 实测，见 #5164；这些设置验证不代表任务执行、模型/模式及恢复行为已验证。实施时必须记录并验证实际版本、平台、认证、事件结构、取消和恢复行为。T3 的 Antigravity 适配是实现参考，不能替代真实 Agent 验收。
实施前真实能力验证
在实现依赖某项能力的功能前验证官方程序，记录实际版本、平台和脱敏证据。参考代码及协议能力声明不能代替真实 Agent 验证。
必要能力不可用时，先修改对应 PR 的范围和验收标准再实施。记录中不得包含凭据或私有项目内容。PR1 设置检查完成不代表任务、模型或恢复能力已验证。
PR 拆分实施计划
按 设置与认证 → 完整执行 → 会话恢复 → 动态模型与模式 的顺序实施。恢复决定会话连续性和后续进程回收选择，优先于动态选模；确认 Agent 可自行初始化配置后，非必要的模型选择可以后置。
每个 PR 必须可独立交付和验收，可以依赖已合入的 PR。每个新增生产接口、字段或能力的生产者与真实消费者必须在同一 PR 出现，同时交付所需协议、存储、Host 与 Desktop 改动。仅有 mock、测试消费者或承诺由后续 PR 接线不算闭环。涉及协议变更时同步更新解码器及兼容性 epoch。
PR 1 — 在设置中安装、配置、连接与认证 — 已在 feat(desktop): install and configure Antigravity ACP #5164 实现，合并后勾选总项。
oauth_presentation和 Host residency/drain/shutdown。成功、失败、取消及客户端断开后释放临时 server/helper，凭据仍由官方进程管理。/tmp中程序；之前的托管安装/自动保存证据单独保留，不宣称本轮重新完整下载。验收记录、成功截图及后续布局调整截图见 feat(desktop): install and configure Antigravity ACP #5164。PR 2 — 统一选择器与完整任务执行闭环
AcpAgentBackend。PR 3 — 会话恢复与进程重建
PR 4 — 动态模型及支持的模式
最终验收标准
maka --acp服务端行为。首期范围
本地 macOS arm64 Maka Desktop、本地 Runtime Host，以及用户点击安装或手动选择的官方 Antigravity ACP 进程。不包含自动发现或自动升级、远程执行/OAuth 转发、多账户管理、外部子 Agent 编排、steering、会话回退或跨 Agent 续接。TUI 产品入口后续再做，Host 实现保持可复用。
备选方案或临时做法
AgentBackend。本提案依据设计讨论，由 AI 辅助整理。官方二进制实测仍是明确的实施与验收要求。