---
title: "把本地 Agent 变成平台上的 Bot：架构、现状与安全风险"
description: "阿里云万有无界、扣子、Multica 都支持把电脑上的 Claude Code、Codex 这类编程 agent 接进平台，让同事在群里 @ 它干活。顺着这个功能往下追：为什么要把 agent 留在本地，平台怎么找到一台没有公网 IP 的电脑，怎么把交互式 CLI 变成可调用的 worker，几个任务和你自己怎么共用同一个现场，agent 又怎么反过来以平台身份干活；最后看看现在都有谁在做，以及这件事和“给电脑装了个木马”到底差在哪里。"
pubDate: 2026-10-14
tags: ["AI", "Agent", "架构", "安全"]
clc: "TP18"
hero: "./hero.svg"
refs:
- id: "1"
title: "创建 Agent · 本地接入"
url: "https://docs.wanyo.cn/agent/create"
collect: "wanyo-agent-create"
site: "万有无界文档"
- id: "1b"
title: "万有无界 - 企业多 Agent 协作平台"
url: "https://www.qianwenai.com/agents/wanyou"
collect: "qianwenai-agents-wanyou"
site: "万有无界"
note: "产品页"
- id: "2"
title: "接入本地 Agent"
url: "https://docs.coze.cn/cozespace_local_agent"
collect: "coze-cozespace-local-agent"
site: "扣子文档"
- id: "3"
title: "How to run Claude Code as a Linear agent with Cyrus and Hookdeck CLI"
url: "https://hookdeck.com/webhooks/platforms/how-to-run-claude-code-as-a-linear-agent-with-cyrus-and-hookdeck-cli.md"
collect: "hookdeck-webhooks-platforms-how-to-run-claude-co"
site: "Hookdeck"
- id: "4"
title: "App server"
url: "https://learn.chatgpt.com/docs/app-server"
collect: "chatgpt-app-server"
site: "OpenAI Codex 文档"
- id: "5"
title: "Remote Control"
url: "https://code.claude.com/docs/en/remote-control"
collect: "claude-remote-control"
site: "Claude Code 文档"
- id: "6"
title: "CLI_AND_DAEMON.md"
url: "https://github.com/multica-ai/multica/blob/main/CLI_AND_DAEMON.md"
collect: "github-multica-ai-multica-cli-and-daemon-md"
site: "Multica"
- id: "6b"
title: "守护进程与运行时"
url: "https://multica.ai/docs/daemon-runtimes"
collect: "multica-daemon-runtimes"
site: "Multica"
- id: "7"
title: "server/pkg/agent/agent.go"
url: "https://github.com/multica-ai/multica/blob/main/server/pkg/agent/agent.go"
collect: "github-multica-ai-multica-server-pkg-agent-agent"
site: "Multica 源码"
- id: "8"
title: "项目资源"
url: "https://multica.ai/docs/project-resources"
collect: "multica-project-resources"
site: "Multica 文档"
- id: "9"
title: "server/internal/daemon/execenv/runtime_config_sections.go"
url: "https://github.com/multica-ai/multica/blob/main/server/internal/daemon/execenv/runtime_config_sections.go"
collect: "github-multica-ai-multica-server-internal-daemon"
site: "Multica 源码"
- id: "9b"
title: "AI 编程工具对照"
url: "https://multica.ai/docs/providers"
collect: "multica-providers"
site: "Multica 文档"
- id: "10"
title: "认证令牌"
url: "https://multica.ai/docs/auth-tokens"
collect: "multica-auth-tokens"
site: "Multica 文档"
- id: "11"
title: "Push events into a running session with channels"
url: "https://code.claude.com/docs/en/channels"
collect: "claude-channels"
site: "Claude Code 文档"
- id: "12"
title: "本地纳管 Agent 使用说明"
url: "https://help.aliyun.com/zh/agentcore/guidelines-for-the-use-of-local-nanoagent"
collect: "aliyun-zh-agentcore-guidelines-for-the-use-of-lo"
site: "阿里云 AgentCore 文档"
- id: "13"
title: "阿里云万有无界公测报道"
url: "https://www.pingwest.com/w/317000"
collect: "pingwest-w-317000"
site: "品玩"
- id: "13b"
title: "agentclientprotocol.com"
url: "https://agentclientprotocol.com/"
collect: "agentclientprotocol"
site: "ACP"
- id: "13c"
title: "Core Concepts and Components in A2A"
url: "https://a2a-protocol.org/latest/topics/key-concepts/"
collect: "a2a-protocol-latest-topics-key-concepts"
site: "A2A Protocol"
note: "A2A Server（Remote Agent）是一个暴露 HTTP 端点、实现 A2A 协议的 agent"
- id: "14"
title: "server/pkg/agent/claude.go"
url: "https://github.com/multica-ai/multica/blob/main/server/pkg/agent/claude.go"
collect: "github-multica-ai-multica-server-pkg-agent-claud"
site: "Multica 源码"
- id: "15"
title: "安全模型"
url: "https://multica.ai/docs/security-model"
collect: "multica-security-model"
site: "Multica 文档"
- id: "16"
title: "远程控制"
url: "https://www.codebuddy.ai/docs/zh/cli/remote-control"
site: "CodeBuddy 文档"
- id: "17"
title: "一条命令，把本地 AI 变成钉钉群内的机器人"
url: "https://www.dingtalk-global.com/zh/news/activity/make-ai-help-team-work-dingtalk-dws-team-bot-260706"
collect: "dingtalk-global-zh-activity-make-ai-help-team-wo"
site: "钉钉"
- id: "18"
title: "server/internal/daemon/execenv/codex_memory.go"
url: "https://github.com/multica-ai/multica/blob/main/server/internal/daemon/execenv/codex_memory.go"
collect: "github-multica-ai-multica-server-internal-daemon-2"
site: "Multica 源码"
- id: "18b"
title: "[Bug]: Reused Codex CODEX_HOME leaks stale memories into unrelated issue tasks"
url: "https://github.com/multica-ai/multica/issues/3130"
site: "GitHub · multica-ai/multica"
- id: "19"
title: "server/internal/daemon/local_directory.go"
url: "https://github.com/multica-ai/multica/blob/main/server/internal/daemon/local_directory.go"
collect: "github-multica-ai-multica-server-internal-daemon-3"
site: "Multica 源码"
- id: "20"
title: "server/internal/daemon/execenv/local_worktree.go"
url: "https://github.com/multica-ai/multica/blob/main/server/internal/daemon/execenv/local_worktree.go"
collect: "github-multica-ai-multica-server-internal-daemon-4"
site: "Multica 源码"
- id: "21"
title: "Worktrees"
url: "https://learn.chatgpt.com/docs/environments/git-worktrees"
collect: "chatgpt-environments-git-worktrees"
site: "OpenAI Codex 文档"
- id: "22"
title: "Run parallel sessions with worktrees"
url: "https://code.claude.com/docs/en/worktrees"
collect: "claude-worktrees"
site: "Claude Code 文档"
---
最近在阿里云的「万有无界」里看到一个功能，叫「本地接入」[^1][^1b]。平台给你一段 `curl` 命令，命令里带着一个 60 秒内有效的 token；在自己电脑的终端里执行它，保持终端别关，平台就能识别到你本机的 agent。接入之后，这个 agent 出现在平台的 Agent 列表里，「和云端 Agent 一样可对话、可拉入频道」，同事在频道里 @ 它，它就在你的电脑上开工。
再往外看，这并不是一家的想法。字节的扣子 3.0 有 coze-bridge，Multica 有 `multica daemon`，钉钉有 `dws dev connect`，Anthropic 和 OpenAI 也各自给 Claude Code、Codex 做了远程能力。大家都在做同一件事：**把一个跑在个人电脑上的编程 agent，变成平台可以调用的 bot。**
这个方案最厉害的地方在于，本地的 agent 带着完整的上下文现场：你的代码、没提交的改动、它自己的会话历史、你登录好的各种工具。平台侧则可以直接把平台上的活派给它。但仔细想想，又有几个问题绕不过去：
1. 云端 agent 已经很多了，为什么还要把 agent 留在本地？
2. 一台躲在家用路由器后面、没有公网 IP 的电脑，平台是怎么找到它、给它派活的？
3. 这些 agent CLI 是给人在终端里用的交互程序，怎么把它们变成能被程序调用的 worker？
4. 好几个任务同时派下来，你自己也还在改代码，agent 是直接在你的目录里干，还是在一份副本里干？
5. 派活只是一半。agent 怎么反过来，以平台成员的身份在平台上干活？
6. 现在都有谁在做，做到了什么程度？
7. 最后也是最要紧的：这样一来，平台是不是可以像控制木马一样控制我的电脑？
本文就顺着这几个问题往下讲。架构部分主要以开源的 Multica 为例，因为它是少数把整条链路的源码和设计文档都公开了的实现。
---
## 一、本地上下文现场的价值
### 现象
先看云端 agent 是怎么干活的。把一个 issue 交给 GitHub Copilot 的云端 agent、Codex cloud 或者 Devin，它们的第一步几乎都一样：在厂商的云上开一个干净的沙箱，把仓库 clone 下来，装依赖，然后开始读代码。
这个流程对一个开源仓库的小 bug 很好用。可一旦换成我们日常真实的工作，问题就来了：
- 我本地有一半没提交的改动，想让 agent 接着往下改，云端看不到；
- 仓库要连公司内网的数据库和服务才能跑起来，云端沙箱连不进去；
- 我在本机登录好了 `gh`、`aws`、`kubectl`，配好了几个 MCP server，云端要重新配一遍凭据；
- 前天我和 Codex 在终端里聊了一下午，它已经摸清了这个模块的来龙去脉，云端的新会话什么都不知道。
### 分析：现场由什么组成
这些问题背后是同一件事：**agent 干活需要的不只是代码，而是一整个“现场”。** 把它拆开看：
| 现场要素 | 本地 agent | 云端沙箱 |
|---|---|---|
| 代码 | 眼前的 checkout，包括未提交改动、未跟踪文件，甚至几十 GB 的大仓库 | 每次重新 clone，只有已经推送的内容 |
| 会话 | CLI 自己的会话历史可以续上 | 大多每次全新开始 |
| 凭据与工具 | 本机已登录的 CLI、SSH key、MCP server、skills | 要单独注入 secret |
| 网络 | 能访问内网、VPN 后面的服务 | 通常只有公网 |
| 额度 | 用你自己的 ChatGPT / Claude 订阅 | 按 token 或 credits 另外计费 |
### 第一次尝试：把现场搬上云
最直觉的思路是把现场搬过去：给云端沙箱配 devcontainer、注入 secret、开 VPN 隧道。这能解决一部分问题，但总有搬不动的东西。未提交的改动要先推到某个分支，会话历史在本机的 `~/.codex` 里，内网要单独打通，每多一样东西，就多一份配置和一份泄露的风险。
### 解决：反过来，让 agent 留在现场
既然现场搬不动，那就反过来：**agent 留在现场，只把“派活”这件事搬上云。** 平台负责“谁、什么时候、干什么”，本地负责“在现场干”。
这正是万有无界、扣子和 Multica 的共同思路。扣子的文档说得最直白：「扣子只提供对话入口，Agent 本身仍运行在你自己电脑上，不会迁移到云端。」[^2]
把两条路放在一起看，差别就很清楚了。往云上搬，现场里的每样东西都要单独接一根管子；留在现场，跨过网络的只有派活这一件事。
图 1 · 把现场搬上云，每样东西都要单独接一根管子，会话历史还搬不过去；让 agent 留在现场，跨过网络的只剩一条派活消息
**可是平台在云上，电脑在家里的路由器后面，平台要怎么找到它？**
---
## 二、平台与本地的连接
### 现象
一台普通的开发机，通常没有公网 IP。它在家用路由器或公司防火墙的 NAT 后面，外面的服务器根本没法主动连进来。
### 第一次尝试：开端口或打隧道
最直接的办法是让本地 agent 当服务端：开一个端口，或者用 Cloudflare Tunnel、ngrok 之类的工具打一条隧道，让平台通过 webhook 推任务进来。
社区里确实有人这么做。比如自托管 Cyrus（把 Linear 的 issue 派给本地 Claude Code 的开源项目）时，就需要一条隧道来接收 Linear 的 webhook[^3]。Codex 的 `app-server` 也能监听 WebSocket 端口。
但这条路的问题很明显：你等于在自己电脑上开了一个对外的入口，鉴权全靠自己做好。Codex 的文档就专门提醒过，app-server 的 WebSocket 传输还是“experimental and unsupported”，而且「Non-loopback WebSocket listeners currently allow unauthenticated connections by default during rollout」[^4]，也就是说，非回环地址上的监听在推出阶段默认不做鉴权。
### 解决：由本地主动连出去
几乎所有成熟的方案都选了反方向：**不让平台连进来，而是让本地进程主动连出去，然后一直保持这条连接。** 出站连接能穿过 NAT 和绝大多数防火墙，本机也不用开任何入站端口。
Anthropic 对 Claude Code Remote Control 的描述就是这个模型：「Your local Claude Code session makes outbound HTTPS requests only and never opens inbound ports on your machine. When you start Remote Control, it registers with the Anthropic API and polls for work.」[^5]
剩下的问题是：一条出站连接，平台怎么知道它是“你的”？答案是**配对**。平台先生成一个短期有效的一次性 token，你在本机执行带着这个 token 的命令，本地进程用它向平台证明身份，换来一个长期凭据。万有无界的 token 有效 60 秒，扣子是 60 分钟[^2]，Multica 用 `multica setup` 完成同样的事。
Multica 的守护进程（daemon）把这套机制做得比较完整[^6][^6b]：
- daemon 启动后和服务端保持一条 **WebSocket** 连接。有新任务时，服务端只通过它发一个“唤醒”信号，daemon 再主动来领取任务。
- 万一 WebSocket 断了，daemon 还会每 **30 秒**轮询一次作为兜底，保证任务不会因为一次断线永远卡在队列里。
- daemon 每 **15 秒**发一次心跳，服务端据此判断这台电脑是否在线。
为什么出站就行、入站就不行？关键在路由器的 NAT 表。家里所有设备共用一个公网地址，路由器只有在里面的设备先发起连接时，才会记下一条“公网端口对应哪台内网机器的哪个端口”的映射。从外面主动推进来的请求查不到映射，路由器不知道该转给谁，只能丢掉（除非你在路由器上手动配了端口转发，那就是上面“开端口”的那条路）。而 daemon 连出去的那条 WebSocket 一直不断，映射也就一直在，平台的唤醒信号顺着它就能回到你的电脑上。
图 2 · 平台推进来的请求在 NAT 上找不到映射，只能被丢掉；daemon 主动连出去的 WebSocket 在路由器上留下一条映射，唤醒信号就顺着它回来
这里有个容易忽略的细节：**电脑离线了怎么办？** 万有无界和扣子的处理很简单：关掉终端或电脑休眠，agent 就掉线，要重新走一遍接入流程[^1][^1b][^2]。Multica 则让任务在队列里等：只有当运行时的心跳缺席超过一个宽限期，**并且**这条任务自己也已经排队这么久，它才会失败[^6][^6b]。这样你合上笔记本去开会，回来打开电脑，积压的活会自动接着干。
**连上了，平台说“去干活”。可是 agent CLI 是给人用的交互式终端程序，daemon 要怎么驱动它？**
---
## 三、交互式 CLI 的程序化驱动
### 现象
Codex 和 Claude Code 生来是给人用的：你在终端里打字，它回答、提议改代码、问你要不要执行某条命令。daemon 没有手，也没法盯着屏幕。
### 分析：每个 CLI 都留了一个“无头”入口
好在这些 CLI 都提供了给程序调用的接口，只是各家不一样：
- Claude Code 可以用 `-p` 以非交互模式运行，并以 `stream-json` 的格式把每一步输出成结构化事件；
- Codex 提供 `app-server`，一套 JSON-RPC 2.0 协议：`thread/start` 新建一个会话线程，`turn/start` 发起一轮任务，`turn/steer` 在一轮任务进行中插话[^4]；
- 还有不少工具实现了 ACP（Agent Client Protocol，Zed 牵头的编辑器与 agent 之间的协议）。
如果平台想同时支持很多家 CLI，就需要一层适配。Multica 支持 26 种 agent CLI，它的做法是把差异收敛到一个只有一个方法的 Go 接口里：
```go
type Backend interface {
Execute(ctx context.Context, prompt string, opts ExecOptions) (*Session, error)
}
```
源码注释写明，这个设计照搬了开源项目 happy-cli 的 AgentBackend 模式[^7]。真正的复杂度都藏在 `ExecOptions` 里：工作目录、模型、思考强度、要续上的会话 ID、MCP 配置，以及一大堆超时（握手超时、首轮无进展超时、空闲超时、中断确认超时）。每一个超时背后，大概都有一次某家 CLI 卡死的经历。
**能驱动 CLI 了，下一个问题是：它该在哪个目录里干活？**
---
## 四、现场的并发与隔离
### 现象
第一节的结论是 agent 要留在现场。最直接的理解，就是让 daemon 把 CLI 的工作目录设成你的仓库，比如 `~/work/shop-api`。
可一旦它成了平台上的 bot，情况就和你自己在终端里用它不一样了。设想这样一个下午：你正改着 `internal/refund/calc.go`，还没提交；同事在频道里 @ 它修 MUL-42（退款金额算错了）；几分钟后，另一个同事又 @ 它查 MUL-43。三方同时在写同一份工作副本：
- 两个任务的改动交错落在同一棵目录树上，`git status` 里分不清哪一行是谁改的；
- 一个任务为了跑测试执行了 `git stash` 或者切了分支，另一个任务脚下的文件就变了；
- 你自己的半成品也混在里面，agent 可能顺手把它“修”掉，也可能把它当成需求的一部分。
这里其实有两个问题：**任务和任务之间要隔离，任务和你之间也要隔离。**
### 第一次尝试：一个目录同一时间只给一个任务
最省事的办法是排队。Multica 的 `in_place`（原地）模式就是这么做的：daemon 给每个目录挂一把锁，同一时间只让一个任务进去，后到的任务进入 `waiting_local_directory` 状态等待[^8]。锁按解析完符号链接之后的真实路径来加，两条不同的路径指向同一个目录，也会排进同一个队列。daemon 还拒绝把 `/`、`/Users`、`/home` 或者你的 home 目录本身当作工作目录，因为那等于把整个账号都交给了 agent[^19]。
排队解决了任务之间打架，却带来两个新问题。
第一是慢。前一个任务要跑 20 分钟的构建，后面的人就得等 20 分钟。Multica 在 issue #7344 里就踩过这个坑：连一轮只读的聊天都排在了构建后面，后来只好把聊天从锁里豁免出去[^19]。
第二个更根本：**这把锁锁不住你。** 源码注释说得很直白，这把锁只防“两个长时间运行的编码任务把改动交错写进同一棵树”，它从来不是通用的写屏障，也成不了，因为你的编辑器、终端和脚本一直在不加锁地写同一个目录[^19]。文档也提醒，原地模式下智能体会直接看到并修改当前分支和未提交的文件，Multica 不会替你切分支、stash、commit 或者开 PR[^8]。任务结束后，它的改动和你的半成品混在同一个工作副本里，中间没有一条清楚的边界。
### 第二次尝试：每个任务一份干净的副本
要隔离，最顺手的工具是 git worktree。同一个仓库可以同时检出多棵工作树，每棵在自己的目录、自己的分支上，共用同一个对象库。给每个任务 `git worktree add` 一棵，任务之间互不干扰，也碰不到你的目录。
Multica 关联 GitHub 仓库时，默认就是这么做的：在本机 clone 一份缓存，每次运行开一棵 worktree，同一个仓库上的运行可以随意并发[^8]。agent 仍然跑在你的电脑上，凭据、内网、CLI 的登录状态这些**机器层面**的现场都还在。
但 `git worktree add` 检出的是 `HEAD`。你还没提交的那半个 `calc.go`、刚写好还没 `git add` 的 `scripts/backfill.sql`，在新的工作树里统统不存在。agent 会去 review 一份你已经不用的代码，第一节说的**目录层面**的现场又丢了。
这也是为什么 Multica 在文档里把“直接关联本地目录”称为「逃生舱，不是更方便的默认项」，它举的典型用户是一个 checkout 就几十 GB、没法每次重新 clone 的游戏项目[^8]。目录层面的现场最有价值，也最难安全地用起来。
### 解决：副本从你眼前的状态开始
Multica 的 `worktree`（并行）模式把前两次尝试拼在了一起：**用 worktree 拿到隔离，再把你的目录原样回放进去，拿回现场。** 它分三步走[^20]：
1. **给你的目录拍一张快照。** daemon 把 `GIT_INDEX_FILE` 指向自己工作区里的一个临时 index，在上面执行 `git add -A` 和 `git write-tree`，再用 `git commit-tree -p HEAD` 生成一个提交。这个提交的树就是你此刻的目录：已跟踪文件的修改、未跟踪的新文件、删除和权限变化都在里面。整个过程只往对象库里写数据，不碰你的 index、文件和 stash，也不用去抢 `.git/index.lock`。
2. **在 worktree 里回放快照。** daemon 在自己的目录（默认是 `~/multica_workspaces/`）下开一棵 worktree，检出分支 `agent//`，再用 `git cherry-pick --no-commit` 把快照放进去。文档的原话是：「智能体从你眼前的状态开始，而不是从 `HEAD` 开始。」[^8]
3. **把结果交付成一个分支。** agent 跑完后，它留下的未提交改动会被自动提交到这个分支上，然后 worktree 被删掉。你用 `git log`、`git diff` 审阅，自己决定 merge 还是 cherry-pick，Multica 不替你合并。如果连这次提交都做不了，比如仓库开了 `commit.gpgSign` 而 daemon 拿不到签名密钥，worktree 会被刻意保留下来，不会连同改动一起删掉。
图 3 · 快照把你眼前的目录拍成一个提交，回放进独立的 worktree；agent 从这里开始干，结果交付成一个分支，你的工作副本从头到尾只被读过
同一个 issue 的下一轮评论来了，又会怎样？daemon 会重新检出同一个分支，让 agent 站在上一轮的成果上接着干。这时不能把你的整个目录再回放一遍，否则上一轮已经带进去的改动会被重复提出，和 agent 改过的同一行撞车。所以 Multica 在你的仓库里给每个分支留了一个隐藏 ref `refs/multica/local-state/`，记下上一轮看到的目录状态，下一轮只回放“上一轮到现在”你新改的部分[^20]。
如果你新改的行恰好 agent 也改过，git 判断不了谁对，这一轮就带着冲突启动，由 agent 先把合并做完。冲突没解决，这一轮就什么都不交付，下一轮再把同样的改动送上来[^8]。宁可失败，也不悄悄丢掉你的修改。
副本也有它的代价。快照用的是 `git add -A`，被 `.gitignore` 忽略的文件不会被带过去：`.env` 不在，`node_modules` 也不在，agent 要么重新装依赖，要么就缺一份配置。未跟踪的文件超过 2000 个或 200 MiB，任务会直接失败，而不是从一棵你认不出来的树开始[^8]。
### 别家怎么选
这个两难不是 Multica 一家的。从 IM 和平台接进来的方案，大多默认原地干活。Claude Code 的 Remote Control 以服务模式运行时，默认 `--spawn same-dir`，文档直说「all sessions share the current working directory, so they can conflict if editing the same files」，需要时可以切成每个会话一棵 worktree[^5]。阿里云 AgentCore 的本地纳管默认在执行连接命令的那个目录里干活，不同会话默认可以同时跑 2 个，文档没有提到隔离[^12]。
桌面上的编排工具则普遍默认一个任务一棵 worktree，分歧在于带不带你没提交的改动。Codex app 会带过去：「If you chose a branch with local changes, Codex applies the uncommitted changes to the worktree as well.」[^21] Claude Code 的 `--worktree` 默认从仓库的默认分支切出，只检出已跟踪的文件[^22]。至于 `.env` 这类被忽略的文件，两家都用一个 `.worktreeinclude` 文件列出需要额外复制过去的内容[^21][^22]。
把三种做法放在一起对比：
| | 原地（`in_place`） | 干净的副本 | 回放现场的 worktree |
|---|---|---|---|
| 看得到没提交的改动 | 能 | 不能 | 能，被忽略的文件除外 |
| 多个任务同时跑 | 排队 | 可以 | 可以 |
| 会不会写你的工作副本 | 会 | 不会 | 不会 |
| 结果在哪 | 混在你的工作副本里 | 一个分支 | 一个分支 |
### 现场的最后一块：会话
会话也是现场的一部分。Multica 会保存 CLI 返回的会话 ID（Codex 的 thread、Claude Code 的 session），同一个 issue 的下一次运行会被路由到能访问这段会话的那台电脑上去续接[^9][^9b]。在 worktree 模式下，它和分支一起构成了一条连续的工作线：分支记着代码改到了哪，会话记着 agent 想到了哪。
**到这里，平台已经能把活派给本地 agent，agent 也能在现场把活干完。可是干完之后呢？**
---
## 五、agent 反向操作平台
### 现象
“派活”只是平台到 agent 的一个方向。一个真正的“同事”还要能反过来在平台上干活：中途汇报进展，把任务状态改成“待审核”，拆出子任务，@ 另一个 agent 帮忙。否则它只是一个被远程打开的终端，而不是平台上的成员。
### 第一次尝试：把最终输出贴回去
最简单的办法是等 CLI 跑完，把它的最终输出当成一条回复贴回平台。很多 IM 桥接项目就是这么做的。
问题是这只能“一问一答”：agent 没法在干到一半时汇报，没法修改平台上的对象，更没法把活转交给别的 agent。而且平台也分不清这条回复是谁、凭什么权限写的。
### 解决：同一个 CLI，加一张一次性的工牌
Multica 的做法分三步，都可以在源码里找到[^9][^9b][^10]：
1. **告诉 agent 它在哪。** 每次运行前，daemon 在工作目录里写一份说明文件。按 CLI 的不同，它叫 `CLAUDE.md`、`AGENTS.md` 或其他名字，开头第一句是：「You are a coding agent in the Multica platform. Use the `multica` CLI to interact with the platform.」
2. **给它和人一样的工具。** agent 用的是人也在用的那个 `multica` CLI：`multica issue comment add` 发评论，`multica issue status` 改状态，`multica issue wakeup create` 设置一个稍后再来干活的提醒。
3. **给它一张只对这一次运行有效的工牌。** daemon 领取任务时，服务端签发一个以 `mat_` 开头的临时令牌 `MULTICA_TOKEN`，它绑定当前的用户、工作区、智能体和这次运行，最长有效 24 小时，运行结束就清理掉[^10]。agent 用它写回的每一条评论，都记在这个智能体的名下。
下面这张图把整个往返串起来了。顺着强调色的那条线，可以看到这张工牌是怎么从平台签发、经由你的电脑、最后又回到平台上留下痕迹的。
图 4 · 平台签发的一次性令牌顺着“领取 → 写入 → 启动 → 调用”走一圈，又回到平台上，agent 就以智能体身份完成了反向操作
### 一个踩出来的规则：别在后台等
这套“反向操作”还有一个不太直观的约束，写在 Multica 给 agent 的说明文件里[^9][^9b]：**顶层的这一轮一结束，平台就认为任务结束了。** 所以 agent 不能把一个命令丢到后台、然后说“我等它跑完再汇报”，因为没有人会来叫醒它。
源码注释里记录了这条规则是怎么来的：最初只写了原则，agent 还是会执行 `gh pr checks --watch` 一直盯着 CI，后来只好在说明里点名禁止 `gh pr checks --watch`、`gh run watch` 和 `sleep` 轮询，并告诉它「本地测试通过；CI 运行中：」就是一次完整的交付。真要等一个外部条件，就用 `multica issue wakeup create` 让平台记住，条件满足后再开一次新的运行。
这也说明了“反向操作”的本质：**平台是记忆，agent 是一次次短暂的执行。** 状态要写回平台，而不是留在 agent 的脑子里。
**机制讲完了。这件事现在都有谁在做？**
---
## 六、行业现状
把市面上的方案放在一起看，可以用两个问题把它们分开：**agent 的推理循环跑在哪里？平台能不能用程序给它派活？** 按这两个问题，大致能分出五种架构：
| 架构 | agent 循环在哪 | 怎么连接 | 代表 |
|---|---|---|---|
| A. 平台配对 + 本地连接器 | 本地 | 平台生成一次性 token 的命令，本地连接器出站连回平台 | 万有无界、扣子 3.0、阿里云 AgentCore |
| B. 本地 daemon 领任务 | 本地 | daemon 长连接或轮询领任务，再启动无头 CLI | Multica、Cyrus、Factory、Warp |
| C. 会话中继 | 本地 | 厂商中继镜像一个正在运行的会话，人从手机或网页操控 | Claude Code Remote Control、Codex Remote、Copilot CLI |
| D. IM 桥接 | 本地 | 本地进程直接连 IM 的长连接，群里 @ 就是派活 | 钉钉 `dws dev connect`、cc-connect、OpenClaw、Claude Code Channels |
| E. 云端循环 + 本地执行 | 云端 | 本地 worker 出站连接，只替云端执行文件编辑和命令 | Cursor My Machines、Devin Outposts |
这张表里有三点值得展开。
**第一，连接层已经收敛了。** 从阿里、字节、钉钉到 Anthropic、OpenAI，几乎所有人都用了“出站长连接 + 一次性配对 token”这套组合。万有无界的 curl 加 60 秒 token、扣子的 coze-bridge 加 60 分钟 token、钉钉的一条 `dws dev connect`，本质上是同一件事。2026 年，“能把本地 agent 接上平台”已经是标配，不再是什么新鲜能力。
**第二，“遥控器”和“同事”不是一回事。** C 类方案（Remote Control、Codex Remote）主要是让**人**从手机上操控自己电脑上的会话，平台本身并不主动派活。真正让平台用程序派活的，是 A、B、D 三类。Anthropic 的 Claude Code Channels 是官方给出的一个口子：一个 MCP server 可以把聊天消息、CI 结果、webhook 事件推进一个**正在运行的**本地会话，Claude 处理完再从同一个通道回复[^11]。至于 E 类，虽然也用了你的电脑，但推理和会话都在厂商云上，本地只是执行工具的“手”。它保留了文件、内网和凭据这部分现场，却没有保留本地 CLI 的会话和你的订阅额度。
**第三，反向操作几乎没人公开讲清楚。** 万有无界和扣子的公开文档都写了“平台 @ 本地 agent”这个方向，但本地 agent 用什么身份、通过什么接口反过来操作平台，没有公开。阿里云 AgentCore 的本地纳管 agent 则「只能作为 Team Worker 使用，不支持设置为 Leader」[^12]，也就是只能接活，不能派活。Multica 是少数把这一层公开出来的实现。
标准协议也还没跟上。ACP 默认走 stdio，是为“编辑器和本机 agent”设计的，对远程 agent 的完整支持还在推进中[^13b]；A2A 是服务器对服务器的协议，默认对方暴露一个可以直接访问的 HTTP 端点[^13c]，并不适合躲在 NAT 后面的个人电脑。万有无界宣传支持 A2A，但目前没有公开接口规范[^13]。现阶段各家用的基本都是自己的私有长连接协议。
**这么多平台都在你的电脑上开了一个口子。这个口子到底有多大？**
---
## 七、安全风险
### 现象：这和木马有什么区别
把前面几节串起来看，会得到一个让人不太舒服的结论：一个常驻后台的进程，主动向外连接一台服务器，等着远端发来指令，然后在你的电脑上执行任意命令。这个描述和远程控制木马的结构是一样的。
那它拿到的是“最高权限”吗？准确地说不是 root，而是**启动它的那个系统用户的全部权限**。Claude Code 甚至会在 root 下拒绝跳过权限检查，Multica 的源码里专门处理了这个报错，提示用户换一个非 root 用户来运行 daemon[^14]。可是在一台个人开发机上，“你这个用户的全部权限”几乎就是所有值钱的东西：代码、SSH 私钥、`~/.aws/credentials` 里的云凭据、浏览器的 cookie 文件、公司内网。
它和木马的区别不在能力，而在于**你是知情安装的、有身份认证、有审计记录**。
### 分析：CLI 自带的权限层去哪了
Claude Code 和 Codex 本身是有权限设计的：Claude Code 有权限模式和 allow/deny 规则，Codex 有只读、工作区可写、完全访问三档沙箱和审批策略。问题在于，桥接层会不会保留它们。
情况分成三种：
- **主动关掉的。** Multica 在无人值守时给 Codex 用 `sandbox_mode = "danger-full-access"`，给 Claude Code 用 `--permission-mode bypassPermissions`，审批请求自动应答。它的安全文档说得很坦白：「请把每一次运行都当作无沙箱来对待」[^15]。腾讯 CodeBuddy 的远程任务默认也是 `bypassPermissions`[^16]。
- **把审批转到手机或 IM 上的。** Claude Code Channels 可以把权限请求转发到聊天里让你批准；钉钉的 `dws dev connect` 在执行前会推一张审批卡片，「你点同意才真正执行」[^17]；扣子让你给每种 agent 单独选权限档，比如 Codex 可以选“请求批准”或“完全访问权限”[^2]。
- **决策在厂商云上、你的电脑只负责执行的**，也就是 E 类。它在结构上最接近远程控制：推理发生在别人的服务器上，你的电脑只负责照着执行。
为什么这么多平台选择把审批关掉？因为 bot 是无人值守的，每一步都等人点“同意”，就没法异步干活了。Multica 的理由更进一步：半吊子的文件系统沙箱会让 `gh`、`aws`、`kubectl` 处于“未登录”状态，以难以排查的方式破坏正常工作，却依然挡不住 agent 读取凭据再通过网络发出去。所以它「不假装自己是边界」[^15]。
### 真正的风险在三个入口
比“权限有多大”更值得关心的，是**谁能让它用上这些权限**。一条指令要走到你的私钥面前，有三条路：
1. **谁能给它发指令。** 工作区成员、群里能 @ 它的人。各家都做了账号绑定和白名单：Multica 的 IM 机器人对每条消息都重新校验发送者的成员身份，Claude Code Channels 只接收白名单里的发送者，还提醒你「Anyone who can reply through the channel can approve or deny tool use in your session」[^11]。
2. **平台本身。** 成千上万台开发机都主动连着同一个平台，等它发指令。平台一旦被攻破，它就是一个现成的僵尸网络控制端。中继不做端到端加密的方案（Claude Code Remote Control 的会话内容会经过 Anthropic 的服务器[^5]），厂商还能看到内容。
3. **提示词注入。** agent 会读 issue、网页、README、文档。任何能把文字塞进它上下文的人，都可能借它的手执行命令。这条路**完全不经过平台的身份校验**。
下面这张图画的就是第三条路。
图 5 · 身份校验只守住了经过平台的那条路；CLI 权限层被关掉之后，一条夹带的指令和你的云凭据之间，只剩系统用户这一层
### 被忽略的一点：现场会串味
还有一种风险不来自攻击者，而来自“现场”本身。Codex 自带一个自动记忆功能，会把每轮对话的摘要写进 `$CODEX_HOME/memories/`，下一轮再读回来，用户级的 `~/.codex/memories/` 也可能被读到。Multica 在源码里默认把它关掉了，注释写的理由是不让宿主机或之前任务的记忆越过工作区边界[^18]。起因是 GitHub issue #3130：Multica 复用了同一个 `CODEX_HOME`，一个毫不相干的新任务一启动，就被注入了另一个已经删掉的项目留下的记忆[^18b]。
这说明现场是一把双刃剑：它让 agent 更懂你，也可能把不该带进来的上下文带进来。Multica 的选择是只保留**可见、可编辑**的上下文通道，也就是 issue 的描述和评论、会话 ID、说明文件和 skills，把不透明的记忆关掉。
### 解决：把边界放在 agent 外面
既然 agent CLI 自己的权限层靠不住，合理的做法就是把边界放到它外面。Multica 的建议按从轻到重排列是：专用 Unix 用户、容器、虚拟机[^15]。结合前面三个入口，可以整理成一份清单：
- **换一个人来跑。** 用专用的系统账号、容器、虚拟机，或者一台专用的 Mac mini 来跑 daemon，不要用你自己的账号。
- **只给最小的凭据。** 用只对一个仓库有效的 deploy key，而不是个人 SSH 私钥；云凭据用权限收窄的临时 token；无关的生产凭据不要留在这个账号的 home 目录里。
- **限制出网。** 给这个账号或容器加出网白名单，读到了凭据也发不出去。
- **收紧“谁能派活”。** 只让需要的人能触发它，群聊里不要默认对所有人开放。
- **危险操作保留人工审批。** 推送到主分支、删除、部署这类操作，宁可慢一点，也要转到手机上让人点一下。
- **关掉不透明的记忆，保留审计日志。**
---
## 小结
回顾一下这条问题链：
1. **为什么要把 agent 留在本地？** 因为 agent 干活需要的是整个现场：未提交的改动、会话历史、本机凭据、内网和订阅额度。现场搬不上云，就让 agent 留在现场，只把派活搬上云。
2. **平台怎么找到一台没有公网 IP 的电脑？** 不让平台连进来，而是让本地进程主动连出去，用一次性 token 完成配对，再靠心跳和轮询兜底保持在线。
3. **怎么把交互式 CLI 变成 worker？** 用各家 CLI 的无头接口（`-p`、`app-server`、ACP），外加一层适配。
4. **agent 在哪个目录里干活？** 原地干看得到现场，却只能排队，也锁不住你自己的改动；干净的副本能并发，现场又丢了。回放现场的 worktree 两头兼顾：先给你的目录拍一张快照，在独立的工作树里回放，结果交付成一个分支，你的工作副本从头到尾只被读过。
5. **agent 怎么反过来在平台上干活？** 给它一份说明文件、一个和人一样的 CLI，以及一张只对这一次运行有效的令牌；状态写回平台，而不是留在 agent 的脑子里。
6. **现在谁在做？** 几乎所有人。连接层已经收敛，差距在于平台能不能用程序派活、agent 能不能反向操作平台；标准协议还没跟上。
7. **是不是像木马？** 结构上是，它拿到的是启动它的那个用户的全部权限，而且很多方案在无人值守时关掉了 CLI 的权限层。区别在于知情、认证和审计。真正的边界不在 agent CLI，而在你给它的那个账号、容器或虚拟机。
把本地 agent 变成平台上的 bot，本质上是在自己的电脑上安装一个远程执行代理。它能带来的效率是真实的，它打开的口子也是真实的。用之前，先想清楚这个代理以谁的身份在跑。
---
## 参考资料