不在电脑前也别把 Agent 放出笼子：LinkGravity 如何把终端会话接进聊天工具
AI 编程 Agent 很适合长时间跑在开发机上：读仓库、改文件、执行测试、等待下一步。但人并不总在终端前。把 Agent 接到 Discord、Telegram 或 Slack，表面上只是“远程发消息”，实际却把两个原本分开的系统连在一起：聊天平台的身份与通知机制，以及本机上能执行工具调用的 Agent。
LinkGravity 是一个面向 Antigravity CLI 的聊天与语音桥接工具。它的仓库说明把定位讲得很直接：把 Antigravity CLI 的提示词转成聊天界面组件；在 Discord、Telegram、Slack 中建立会话，并提供交互式工具审批。项目以 MIT 许可证发布，npm 包 linkgravity 当前提供 lgy 与 linkgravity 两个可执行入口。它不是把一个普通聊天机器人“加上 AI”，而是把已经在本机配置好的 Agent 会话搬到可审阅、可回复的消息界面中。
真正值得关注的问题也因此不是“能不能远程控制”，而是：远程入口怎样仍然保持人对执行动作的知情和决定权？下面以官方 README 公开的安装、配置与命令为边界，拆解这个工作流适合什么场景，又有哪些不能省略的安全条件。
从终端孤岛到可追踪的消息线程
开发中常见的卡点很具体：Agent 正在跑测试，遇到依赖安装、迁移脚本或一条需要确认的 shell 命令；你离开电脑后，只能等它超时，或者干脆预先放开权限。另一个问题是并行性：多个任务混在一个终端复用会话里，回头很难知道某条结果属于哪个需求。
LinkGravity 的设计是让一段 agy 会话映射为聊天平台中的会话。README 说明，在 Discord 和 Slack 中会话使用线程；Telegram 则是平铺式会话。Discord、Telegram、Slack 都支持审批按钮和文件附件；其中 Discord 还支持语音和群组，Slack 也支持线程与群组。这样做的价值并非把终端输出原封不动转发，而是给“等待人工输入”的时刻一个可见、可回应的入口。
以 Discord 为例，开发者可以在一个受限频道启动任务；当 Agent 需要执行命令或工具调用时，操作者在聊天界面看到审批按钮。README 特别说明，串联的 shell 命令会逐条审批；也可以为某条命令或工具设置后续自动允许范围。前者适合首次接入、生产环境和未知仓库，后者才适合已经验证过的重复性动作。把“是否执行”保留为显式交互，比在启动时一口气授予无限权限更容易审计，也更容易在误解需求时止损。
最小安装闭环：先确认本地 Agent，再接聊天入口
官方文档列出的前置条件是 Node.js 18 或更高版本、Python 3.10 或更高版本，以及已安装在本机的 Antigravity CLI。还需要至少一种聊天平台的机器人令牌和允许范围。也就是说，LinkGravity 不负责替你安装或配置底层 Agent；它读取本机已有的 agy 配置，让从聊天平台启动的会话沿用终端里的模型与设置。
官方给出的全局安装与初始化命令如下：
npm install -g linkgravity lgy setup
安装过程会建立自身的 Python 环境，README 表示不需要手工执行 pip install。lgy setup 是关键步骤：它用配置向导选择启用的 Discord、Telegram 或 Slack，录入令牌、允许用户等设置。配置保存到 ~/.gemini/linkgravity/lgy.json，位于包目录之外，因此升级或重装 npm 包不会覆盖它。
配置完成后，官方列出的运行与维护命令是：
lgy start lgy logs -f lgy stop
lgy start 通过 PM2 把机器人作为后台守护进程启动；lgy logs -f 用于跟随日志，lgy stop 停止服务。确认稳定后，才考虑使用 lgy enable 注册开机自动启动。把自动启动放在最后并不是形式主义：先观察真实的审批流、平台事件和日志，才能知道机器人令牌、允许名单与本机 Agent 的组合是否符合预期。
把权限设计成三道边界
远程入口的最大风险不在于“有人发来一条消息”，而在于那条消息可能最终驱动本机执行。LinkGravity 的 README 对此有明确警告：它让 AI Agent 获得运行机器上的广泛访问能力，因此不应公开暴露，也不应部署在你无法完全信任使用者的环境中。
第一道边界是允许用户列表。配置向导中的 allowed users 是基础访问控制，不应省略。README 还说明 Discord 可以限制到一个或多个服务器，并进一步限制频道：若服务器的频道列表留空，该服务器所有频道都可启动会话；若填写频道 ID，则只有列出的频道可用。对需要精细隔离的团队，后一种方式更稳妥。Telegram 和 Slack 在当前文档描述中没有同等的服务器/频道粒度限制，因此更要谨慎收紧允许用户范围。
第二道边界是显式开会话。README 指出新会话由 /new 斜杠命令启动，而不是任何普通消息都会触发。这个约束减少了闲聊、转发内容或频道噪声被误当作 Agent 指令的机会。把任务启动设计成明确动作，是聊天式控制面最便宜也最有效的防误触措施。
第三道边界是工具审批。即使用户已获准进入，shell 命令和工具调用仍默认走审批流程。不要把“允许用户”误解为低风险账号：官方文档的表述很严厉，允许名单中的人应被视为对该机器具有近似完全控制能力的人。审批按钮可以减少意外执行，但不能替代账号安全、最小化可访问仓库、隔离开发机以及对敏感环境的网络限制。
一个适合远程跟进的开发场景
假设你在本机启动一个需要数十分钟的重构任务。正确的使用方式不是让 Agent 获得无人值守权限，而是先通过 lgy setup 只启用自己的 Discord 服务器与专用频道，再由 /new 显式启动会话。任务运行期间，聊天线程承载状态更新；出现文件修改、命令执行等需要确认的动作时，在消息界面逐项核对。
如果它请求运行测试，先看命令的工作目录、目标脚本与影响范围；如果它请求安装依赖或访问外部服务，先确认这是否属于当前任务。对已经验证过的纯读取命令或固定测试，可以考虑使用 README 所述的后续自动允许范围；对删除、迁移、凭据、生产访问和未知网络请求，仍应保持逐次审批。结束后用 lgy logs 回看守护进程日志，而不是只相信聊天里最后一句“已完成”。
这种流程的取舍很清楚：它牺牲了一部分“完全自动化”的速度，换来远程协作时更清晰的会话归属和人为闸门。它尤其适合个人开发机、可控的小团队环境，以及需要在离开终端后继续接收 Agent 进度和审批请求的工作；不适合把公开群组、陌生用户或高权限生产主机直接接入。
还有一个容易被忽略的运行边界：聊天平台只解决“在哪里看见请求”，并没有替你定义任务边界。每次启动前仍应明确仓库、分支、可修改路径、允许的网络访问和停止条件；否则线程虽然清楚，Agent 仍可能在错误的上下文里做出看似合理的动作。对于包含密钥、客户数据或生产配置的仓库，建议先使用隔离的测试副本，并把聊天机器人运行在专用开发机上，而不是把日常主力环境直接暴露为控制面。
结语：远程控制不是减少控制，而是重新放置控制点
LinkGravity 的价值在于把 Agent 的等待、审批与结果放进人们已经频繁查看的聊天界面。但聊天界面不是安全沙箱。安装前应确认 npm 包的仓库归属与版本；配置时应收紧用户和频道范围；运行中应保留对工具调用的人工判断；部署后还要保护好 ~/.gemini/linkgravity/lgy.json，不要提交或分享其中的令牌与设置。
如果你的目标只是“随时能给本机 Agent 回一句话”，这个桥接层很实用。如果目标是让陌生人通过聊天工具驱动机器，它反而提醒我们应先重做身份、权限和隔离设计。把交互移到远程，并不意味着可以把责任也移走。