很多开发者已经在 Cursor 或 OpenCode 里写代码。真正麻烦的不是再找一个聊天窗口，而是让正在使用的 coding agent 知道团队怎么部署，并且能调用一条受约束、可回读的部署路径。
我们为此加入了 appaloft setup agent。它会在本机检测支持的 agent host，把 Appaloft skill 复制到对应目录，再写入 Local MCP 配置。命令本身不会部署应用，也不会偷偷替用户登录。
appaloft setup agent这篇文章讲的是这条命令背后的取舍：为什么 skill 和 MCP 要一起装，为什么 token 不该写进编辑器配置，以及为什么 agent 学会部署以后，每次发布前仍然要问人。
Skill 负责判断，MCP 负责调用
只安装 MCP，agent 会看到一组 typed tools，却不一定知道应该按什么顺序使用。部署之前要不要先生成 plan？遇到失败应该 retry、redeploy 还是 rollback？什么结果足以证明应用已经能访问？这些都不是 tool schema 能完整表达的。
只安装 skill 也不够。Skill 可以告诉 agent 应该怎么做，但如果没有稳定的调用入口，它最后还是会退回 shell 拼接、解析终端文本，甚至尝试直接操作 Docker、SSH 或 provider API。
所以 setup agent 同时安装两层：
- skill 提供操作协议、风险边界和 surface 选择；
- MCP 把 Appaloft 已有 operation 暴露成结构化工具。
两者仍然落在同一套产品语义上。MCP 不会多出一条 agent 专用的“快速部署”，skill 也不会绕过 CLI、API 或控制面的授权规则。更完整的设计背景可以看《Skill 不是 MCP：AI Agent 如何安全地调用部署控制面》。
配置文件里不放 token
编辑器通常会把 MCP server 写进 JSON 配置。把长期 bearer token 一起写进去看似省事，实际会扩大泄露面：配置可能被同步、备份、截屏，或者在排障时被整段贴出来。
Appaloft 写入的是 token-free Local MCP launcher。它复用 CLI 已有的登录 profile，而不是把凭据复制到 mcp.json 或 opencode.json。这样做没有消灭凭据管理，但把责任留在了更合适的位置：登录和 token 生命周期由 CLI profile 处理，agent host 只知道怎样启动本地 MCP。
这也解释了为什么 setup 和 login 是两件事。setup agent 改的是这台机器上的 agent 配置；它不会替用户打开浏览器、读取 cookie，或者把一次认证动作伪装成安装步骤。
一条命令，仍然要尊重不同 host
Cursor、Claude Code、OpenCode 和 Codex 的 skill 目录与 MCP 配置并不完全相同。setup agent 提供同一个入口，但不会假装所有 host 都有同一种安装模型。
默认流程会处理 universal skill，并在检测到对应目录时配置 Cursor 与 Claude Code。OpenCode 会出现在可选项里，需要时可以显式选择：
appaloft setup agent --agent opencodeCodex 使用专用的 bearer MCP profile，仍然需要文档中的两步：
appaloft auth mcp login
appaloft auth mcp codex install这个差异值得保留。一个统一入口应该减少记忆负担，但不能用统一外观掩盖不同 host 的认证与配置边界。
如果只想复制 skill，也可以使用 skill manager。那条路径不会安装 Appaloft CLI，不会写 MCP，不会创建资源，更不会部署。把这两种安装方式区分清楚，能避免“agent 已经读到文档”被误认为“agent 已经拥有可调用的部署能力”。
Setup 完成后，发布仍是单独动作
Agent 门和 Deploy 门是两件事。
appaloft setup agent 教会现有的 Cursor 或 OpenCode 怎样使用 Appaloft。真正部署当前目录时，走的是另一条明确命令：
appaloft deploy .我们要求 agent 在每次部署前先向人确认。原因不是 agent 不能执行命令，而是部署会改变共享环境：它可能创建或更新资源、使用外部服务、切换可访问 URL，或者让一份尚未评审的代码进入运行状态。
确认也不能只问一句模糊的“可以吗”。Agent 至少应该说清楚准备部署哪个目录、目标 context 是什么、是否缺少配置，以及接下来会产生什么外部影响。执行后，它还要返回这个应用的 live URL；如果没有健康检查或访问回读，就不能把“命令退出”描述成“已经上线”。
这条规则与构建应用的 agent，不该是那个点发布的角色讨论的是同一个问题：写代码和改变共享运行状态之间，需要一个可见的边界。
我们刻意没有塞进去的东西
setup agent 的范围很窄：检测本机 host、复制 skill、写入 MCP launcher。它不负责：
- 自动选择生产环境；
- 替用户完成浏览器登录；
- 在编辑器配置里保存 token；
- 创建托管 sandbox；
- 推断“代码写完了，所以现在应该部署”；
- 把一次安装包装成完整的 agent 平台。
这些限制让命令少了一点魔法，却更容易检查。用户可以分别回答三个问题：agent 学到了什么，它能调用什么，以及这一次是否允许改变运行环境。
给 agent 的最短说明
安装完成后，给 coding agent 的 briefing 可以很短：
使用 Appaloft 处理部署。每次部署前先向我确认；获准后运行
appaloft deploy .，成功时返回这个应用的 live URL，失败时返回具体阶段和下一步，不要绕过 Appaloft 直接操作 Docker、SSH 或 provider API。
Agent 需要更完整的入口时，可以读取 /zh-CN/llms.txt。人类则可以从 Agent 页面安装，再到文件夹部署页面查看 Deploy 门。
我们希望 setup agent 最终解决的是一个很朴素的问题：不用换掉已经在用的 coding agent，也不用给它一包云凭据，就能让它沿着和人类相同、可以确认和回读的路径完成部署。
公开实现与测试记录见 appaloft/appaloft#1316。