最近在阿里云的「万有无界」里看到一个功能，叫「本地接入」1。平台给你一段 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. 现在都有谁在做，做到了什么程度？
  6. 最后也是最要紧的：这样一来，平台是不是可以像控制木马一样控制我的电脑？

本文就顺着这几个问题往下讲。架构部分主要以开源的 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

可是平台在云上，电脑在家里的路由器后面，平台要怎么找到它？

二、平台与本地的连接

现象

一台普通的开发机，通常没有公网 IP。它在家用路由器或公司防火墙的 NAT 后面，外面的服务器根本没法主动连进来。

第一次尝试：开端口或打隧道

最直接的办法是让本地 agent 当服务端：开一个端口，或者用 Cloudflare Tunnel、ngrok 之类的工具打一条隧道，让平台通过 webhook 推任务进来。

社区里确实有人这么做。比如自托管 Cyrus（把 Linear 的 issue 派给本地 Claude Code 的开源项目）时，就需要一条隧道来接收 Linear 的 webhook3。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：

  • daemon 启动后和服务端保持一条 WebSocket 连接。有新任务时，服务端只通过它发一个“唤醒”信号，daemon 再主动来领取任务。
  • 万一 WebSocket 断了，daemon 还会每 30 秒轮询一次作为兜底，保证任务不会因为一次断线永远卡在队列里。
  • daemon 每 15 秒发一次心跳，服务端据此判断这台电脑是否在线。

这里有个容易忽略的细节：电脑离线了怎么办？ 万有无界和扣子的处理很简单：关掉终端或电脑休眠，agent 就掉线，要重新走一遍接入流程12。Multica 则让任务在队列里等：只有当运行时的心跳缺席超过一个宽限期，并且这条任务自己也已经排队这么久，它才会失败6。这样你合上笔记本去开会，回来打开电脑，积压的活会自动接着干。

连上了，平台说“去干活”。可是 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 接口里：

type Backend interface {
    Execute(ctx context.Context, prompt string, opts ExecOptions) (*Session, error)
}

源码注释写明，这个设计照搬了开源项目 happy-cli 的 AgentBackend 模式7。真正的复杂度都藏在 ExecOptions 里：工作目录、模型、思考强度、要续上的会话 ID、MCP 配置，以及一大堆超时（握手超时、首轮无进展超时、空闲超时、中断确认超时）。每一个超时背后，大概都有一次某家 CLI 卡死的经历。

新的问题：在现场干，还是在现场的副本里干

能驱动 CLI 了，下一个问题是它在哪个目录里干活。这恰恰是“现场”最难处理的地方：

  • 如果直接在你的目录里干，它能看到你所有的未提交改动，可两个任务同时来，就会在同一份工作副本上打架；
  • 如果每次给它一个干净的新目录，并发是安全了，现场却又丢了。

Multica 给了两种模式8。in_place（原地）让 agent 直接在你的目录里工作，同一时间只允许一个任务，后到的任务进入 waiting_local_directory 状态排队。worktree（并行）则给每个任务一个独立的 git worktree，并且把你未提交的改动和未跟踪的文件回放进去。文档的原话是：「智能体从你眼前的状态开始，而不是从 HEAD 开始。」做完的结果落在一个 agent/<agent>/<issue> 分支上，同一个 issue 下一轮的评论会在这个分支上接着干。

会话也是现场的一部分。Multica 会保存 CLI 返回的会话 ID（Codex 的 thread、Claude Code 的 session），同一个 issue 的下一次运行会被路由到能访问这段会话的那台电脑上去续接9。

到这里，平台已经能把活派给本地 agent，agent 也能在现场把活干完。可是干完之后呢？

四、agent 反向操作平台

现象

“派活”只是平台到 agent 的一个方向。一个真正的“同事”还要能反过来在平台上干活：中途汇报进展，把任务状态改成“待审核”，拆出子任务，@ 另一个 agent 帮忙。否则它只是一个被远程打开的终端，而不是平台上的成员。

第一次尝试：把最终输出贴回去

最简单的办法是等 CLI 跑完，把它的最终输出当成一条回复贴回平台。很多 IM 桥接项目就是这么做的。

问题是这只能“一问一答”：agent 没法在干到一半时汇报，没法修改平台上的对象，更没法把活转交给别的 agent。而且平台也分不清这条回复是谁、凭什么权限写的。

解决：同一个 CLI，加一张一次性的工牌

Multica 的做法分三步，都可以在源码里找到910：

  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 用它写回的每一条评论，都记在这个智能体的名下。

下面这张图把整个往返串起来了。顺着强调色的那条线，可以看到这张工牌是怎么从平台签发、经由你的电脑、最后又回到平台上留下痕迹的。

一次派活的完整往返 Issue MUL-42 指派给智能体后在平台上产生一条 Run，并签发运行级令牌 mat_9c…；你电脑上的守护进程通过出站连接领取这条 Run，把说明文件和令牌写进工作目录，启动 Codex；Codex 调用 multica CLI，用同一个令牌把评论和状态写回 MUL-42。 平台（云端） 你的电脑 · 用户 dev 指派后入队 领取 写入 启动 调用 写回 Issue MUL-42 assignee Codex 工程师 status in_review comment by Codex 工程师 Run task 7f3a… status running token mat_9c… expires ≤ 24h multica CLI 以智能体身份 comment add MUL-42 status in_review auth mat_9c… Codex app-server thread resume turn brief + 任务 shell git, gh, npm 守护进程 multica daemon 连接 出站 WebSocket 心跳 15s 轮询 30s 兜底 工作目录 每次运行一个 AGENTS.md brief MULTICA_TOKEN mat_9c… cwd 你的仓库 平台从不连进你的电脑， 连接由守护进程主动发起。 令牌只对这一次运行有效，写回的评论记在智能体名下。
图 1 · 平台签发的一次性令牌顺着“领取 → 写入 → 启动 → 调用”走一圈，又回到平台上，agent 就以智能体身份完成了反向操作

一个踩出来的规则：别在后台等

这套“反向操作”还有一个不太直观的约束，写在 Multica 给 agent 的说明文件里9：顶层的这一轮一结束，平台就认为任务结束了。 所以 agent 不能把一个命令丢到后台、然后说“我等它跑完再汇报”，因为没有人会来叫醒它。

源码注释里记录了这条规则是怎么来的：最初只写了原则，agent 还是会执行 gh pr checks --watch 一直盯着 CI，后来只好在说明里点名禁止 gh pr checks --watch、gh run watch 和 sleep 轮询，并告诉它「本地测试通过；CI 运行中：<PR 链接>」就是一次完整的交付。真要等一个外部条件，就用 multica issue wakeup create 让平台记住，条件满足后再开一次新的运行。

这也说明了“反向操作”的本质：平台是记忆，agent 是一次次短暂的执行。 状态要写回平台，而不是留在 agent 的脑子里。

机制讲完了。这件事现在都有谁在做？

五、行业现状

把市面上的方案放在一起看，可以用两个问题把它们分开：agent 的推理循环跑在哪里？平台能不能用程序给它派活？ 按这两个问题，大致能分出五种架构：

架构agent 循环在哪怎么连接代表
A. 平台配对 + 本地连接器本地平台生成一次性 token 的命令，本地连接器出站连回平台万有无界、扣子 3.0、阿里云 AgentCore
B. 本地 daemon 领任务本地daemon 长连接或轮询领任务，再启动无头 CLIMultica、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”设计的，远程传输还在草案阶段；A2A 是服务器对服务器的协议，默认对方有一个可以直接访问的地址，并不适合躲在 NAT 后面的个人电脑。万有无界宣传支持 A2A，但目前没有公开接口规范13。现阶段各家用的基本都是自己的私有长连接协议。

这么多平台都在你的电脑上开了一个口子。这个口子到底有多大？

六、安全风险

现象：这和木马有什么区别

把前面几节串起来看，会得到一个让人不太舒服的结论：一个常驻后台的进程，主动向外连接一台服务器，等着远端发来指令，然后在你的电脑上执行任意命令。这个描述和远程控制木马的结构是一样的。

那它拿到的是“最高权限”吗？准确地说不是 root，而是启动它的那个系统用户的全部权限。Claude Code 甚至会在 root 下拒绝跳过权限检查，Multica 的源码里专门处理了这个报错，提示用户换一个非 root 用户来运行 daemon14。可是在一台个人开发机上，“你这个用户的全部权限”几乎就是所有值钱的东西：代码、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 的远程任务默认也是 bypassPermissions16。
  • 把审批转到手机或 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、文档。任何能把文字塞进它上下文的人，都可能借它的手执行命令。这条路完全不经过平台的身份校验。

下面这张图画的就是第三条路。

一条指令和你的私钥之间隔着什么 群聊 @ 和 Issue 评论要经过平台的成员身份校验才能派活给 Codex；README 里夹带的文字被 Codex 直接读到，不经过平台。Codex 的沙箱被设成 danger-full-access、审批自动通过，CLI 权限层形同虚设，指令一路走到用户 dev 能碰到的 ~/.aws/credentials。 指令从哪来 平台 你的电脑 · 用户 dev 派活 群聊 @Codex 修一下 CI Issue MUL-42 评论 README 夹带的指令 这条路不经过平台的 身份校验。 平台 校验 成员身份 派给 在线 daemon Codex daemon 拉起 sandbox_mode danger-full-access 审批 自动通过 CLI 权限层 虚线：本来存在，无人值守时被关掉 用户 dev 能碰到的 ~/.ssh/id_ed25519 私钥 ~/.aws/credentials 云凭据 git push origin main 仓库写权限 10.0.0.0/8 内网
图 2 · 身份校验只守住了经过平台的那条路；CLI 权限层被关掉之后，一条夹带的指令和你的云凭据之间，只剩系统用户这一层

被忽略的一点：现场会串味

还有一种风险不来自攻击者，而来自“现场”本身。Codex 自带一个自动记忆功能，会把每轮对话的摘要写进 $CODEX_HOME/memories/，下一轮再读回来，用户级的 ~/.codex/memories/ 也可能被读到。Multica 在源码里专门把它关掉了，原因写在注释里：在 GitHub issue #3130 的复现中，一个全新任务的第一轮就读到了用户本机另一个项目的记忆18。

这说明现场是一把双刃剑：它让 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），外加一层适配；工作目录在“原地”和“回放了现场的 worktree”之间二选一。
  4. agent 怎么反过来在平台上干活？ 给它一份说明文件、一个和人一样的 CLI，以及一张只对这一次运行有效的令牌；状态写回平台，而不是留在 agent 的脑子里。
  5. 现在谁在做？ 几乎所有人。连接层已经收敛，差距在于平台能不能用程序派活、agent 能不能反向操作平台；标准协议还没跟上。
  6. 是不是像木马？ 结构上是，它拿到的是启动它的那个用户的全部权限，而且很多方案在无人值守时关掉了 CLI 的权限层。区别在于知情、认证和审计。真正的边界不在 agent CLI，而在你给它的那个账号、容器或虚拟机。

把本地 agent 变成平台上的 bot，本质上是在自己的电脑上安装一个远程执行代理。它能带来的效率是真实的，它打开的口子也是真实的。用之前，先想清楚这个代理以谁的身份在跑。

参考资料

Footnotes

  1. 万有无界文档：创建 Agent · 本地接入；产品页：万有无界 - 企业多 Agent 协作平台 ↩ ↩2

  2. 扣子文档：接入本地 Agent ↩ ↩2 ↩3 ↩4

  3. Hookdeck：How to run Claude Code as a Linear agent with Cyrus and Hookdeck CLI ↩

  4. OpenAI Codex 文档：App server ↩ ↩2

  5. Claude Code 文档：Remote Control ↩ ↩2

  6. Multica：CLI_AND_DAEMON.md；守护进程与运行时 ↩ ↩2

  7. Multica 源码：server/pkg/agent/agent.go ↩

  8. Multica 文档：项目资源 ↩

  9. Multica 源码：server/internal/daemon/execenv/runtime_config_sections.go；文档：AI 编程工具对照 ↩ ↩2 ↩3

  10. Multica 文档：认证令牌 ↩ ↩2

  11. Claude Code 文档：Push events into a running session with channels ↩ ↩2

  12. 阿里云 AgentCore 文档：本地纳管 Agent 使用说明 ↩

  13. 品玩：阿里云万有无界公测报道；ACP：agentclientprotocol.com ↩

  14. Multica 源码：server/pkg/agent/claude.go ↩

  15. Multica 文档：安全模型 ↩ ↩2 ↩3

  16. CodeBuddy 文档：远程控制 ↩

  17. 钉钉：一条命令，把本地 AI 变成钉钉群内的机器人 ↩

  18. Multica 源码：server/internal/daemon/execenv/codex_memory.go ↩