决策与执行分离：Morphz 是如何调用工具的

把会话管理、模型调用和工具执行放进一个本地程序，是搭建 Agent 很直接的办法。但用户的工作不一定只在这台电脑上。如果每换一个工作环境，就部署一个独立的 Agent，背景需要重新解释，进展需要另外同步。工具分布在不同的地方，连带着对工作的理解也被分开了。

这种绑定并不是必需的。访问本地文件、运行本地软件，需要的是一个能在当地执行操作的程序，并不要求负责理解任务和作出决策的 Agent 也部署在那里。执行程序与 Agent 之间，完全可以通过网络连接。

Morphz 按照这个思路，将决策与执行分开。一个 Agent 服务维护认知、会话和任务，各台设备提供自己的文件、工具和计算资源。用户换了终端，面对的仍然可以是同一个 Agent；接入新的工作环境，也不必再建立一份独立的认知。

多端使用的是同一个 Agent

在 Morphz 中，会话、认知和执行设备是分别管理的。会话负责用户与 Agent 的交互；认知保存 Agent 对工作的理解；执行设备决定文件操作和命令实际发生在哪里。

这意味着，用户从哪个终端发来消息，并不决定任务只能在哪台机器上执行。终端可以用来查看进度和发出要求，实际工作则交给已经接入并获得授权的设备。

Morphz 已经实现了同一认知上下文中的多会话共享。一段会话里形成的判断和经验，可以被另一段会话使用。各段会话仍然保留自己的输入输出和工作进度，回复也回到发起交互的会话。用户既能换个终端继续原来的工作，也能开一个新会话处理其他事情。

这些会话还能同时推进工作。一个会话等待工具返回时，另一个会话可以继续处理用户的新要求。多个工作线程通过上下文事务修改共享认知，运行时负责提交和冲突检查。执行结果也会回到对应的工作线程，不会因为用户切换了终端就失去归属。

所以，多端同步不再是几个独立 Agent 之间搬运记忆。用户访问的是同一个 Agent；需要延续的任务、会话和认知，本来就由这个服务维护。

把工具留在需要它的环境里

Agent 经常被安装在用户电脑上，一个直接的原因是它需要使用那里的文件、命令和软件。模型接口可以在云端，但修改项目、运行测试或访问内网服务，仍然需要合适的执行环境。

这些需求决定了操作要在哪里发生，却不要求负责决策的 Agent 逻辑也部署在那里。

Morphz 将执行环境单独建模。Agent 服务负责组织模型调用、维护上下文和调度工作；执行程序负责在指定环境中落实操作，再把结果交回来。两部分可以在同一台机器上，也可以通过网络连接。

用户电脑上可以只运行 morphz-edge。它不负责调用模型，也不独立维护另一份 Agent 认知。完成与服务端的配对后，它主动建立连接，接收操作，在本地检查权限并执行。这种连接方式也适用于服务端无法直接访问的内网设备。

每台电脑分别接入服务即可，电脑之间不用相互配对，也不用选一台作为主控。接入时需要说明的是这台设备能提供什么、允许做什么，而不是重新建立一个负责同样工作的 Agent。

工具调用如何找到正确的设备

同一个 Agent 可以使用多个环境，工具调用就必须明确目的地。否则，一条命令中的“当前目录”到底属于哪台机器，很容易变得含糊。

Morphz 用执行节点（Execution Target）标识操作发生的环境。每个节点有稳定的身份，并记录平台、工作区、可用工具、授权范围和连接状态。模型可以用 list_targets 查看可用节点，用 inspect_target 查看具体信息；需要解析 SSH 目的地时，使用 resolve_target。

调用工具时，target 指明执行位置。例如，一台 Linux 测试机已登记为 target-linux-tests，待测代码也已准备在它的 /srv/project 目录中，模型可以向 exec 提交：

{
  "target": "target-linux-tests",
  "command": "cargo test",
  "cwd": "/srv/project"
}

这条请求使用测试机上的目录、命令和依赖。Morphz 服务自身部署在哪里，不改变这些参数的含义。代码和文件的准备、传输，也要根据执行节点的环境安排。

工作线程会保留自己的执行节点。第一次物理操作建立绑定后，后续省略 target 的调用继承这个位置；需要去另一台机器工作的部分，由绑定相应节点的新线程承接。改变会话默认选择的设备，不会把正在执行的线程悄悄切换到另一台机器。

目前，本机执行、托管 SSH 和边缘节点通过统一的执行接口接入。本机使用本地工具；托管 SSH 由运行时管理连接和主机密钥校验；边缘节点通过主动出站连接接收任务。模型使用节点提供的能力，不需要为每次调用重新编排连接流程。

执行任务有自己的身份和状态

把工具调用送到远程，只解决了操作如何到达的问题。实际工作还需要知道：操作是否已经开始、执行到了哪里、有没有完成，以及结果应该交给谁。

Morphz 接纳工具调用后，会记录对应的执行任务，包括它所属的 Agent、工作线程、工具调用和执行节点。运行时检查工具能力与授权，将任务交给相应执行器，并保存执行路径和状态。

输出、退出状态和任务完成事件随后返回运行时，交给对应的工作线程。Agent 根据结果继续判断，必要时更新认知或安排下一步操作。

这种任务身份在连接不稳定时也有用。连接断开，并不能证明命令没有执行；如果结果暂时无法确认，后续需要根据记录和节点上的实际情况处理，不能把请求随意重发到另一台设备。

设备也仍然需要在线才能提供自己的工具。如果用户电脑离线，依赖其本地文件和环境的任务就无法在那里继续执行。服务保存着工作状态，并不意味着它能代替一台不可用的设备。

权限和数据如何处理

接入同一个 Agent，不要求所有设备开放相同的权限。开发机可以允许修改项目文件，生产服务器可以只允许读取日志。Morphz 分别检查节点使用授权和具体操作权限，边缘设备也保留本地检查及撤销授权的能力。

沙箱限制可访问的资源，审批决定某项操作是否获准执行。可复用授权通过有范围、有期限的能力租约管理，不能因为一次操作获批，就把整台设备长期开放给 Agent。

使用云端 LLM 时，本地 Agent 本来就会将选入请求的内容发送给模型服务。Agent 服务化后，这些内容经由 Agent 服务组织，再进入模型请求。执行环境在本地、认知服务在云端，并不等于将用户数据公开，也不要求把整台电脑的文件上传过去。

如果 Agent 服务由第三方托管，它会成为数据处理链路中的一个环节，需要明确访问、日志和留存规则；自行部署则可以由用户管理这一环节。数据如何处理，应当落实到具体的授权和服务策略，而不能只凭“Agent 安装在本地还是云端”来判断。

执行环境不只限于用户电脑

决策与执行分离，也没有规定 Agent 必须在云端。

用户可以让 Agent 在本地运行，把需要隔离的代码交给远程沙箱执行。也可以把 Agent 部署成云端服务，通过 Edge 使用用户电脑上的环境。两种方式使用的是同一种分工，只是决策和执行的位置不同。

现有的本机、SSH 和边缘节点接入，让不同机器能够按这套方式提供能力。远程沙箱也可以通过执行接口接入，文件准备、权限和任务回收则由相应的环境管理。

这个接口还为机器人、外设和其他智能终端留下了扩展空间。它们需要适配自己的控制方式、反馈和安全限制，但不必因此各自实现一整套 Agent 逻辑。新增的执行能力，可以交给已有 Agent 结合任务和认知来使用。

从单机程序到 Agent 服务

执行环境独立之后，Agent 可以按一项长期服务来建设。认知、会话和任务状态由服务统一维护，执行能力则来自分别接入的设备。升级 Agent 逻辑不必同时升级每台设备上的执行程序，接入或替换设备也不必迁移整套 Agent。

这让工程工作的对象更明确：服务端管理状态、调度和恢复，执行端管理环境、资源和操作权限。Morphz 已有的持久任务记录、版本检查和执行状态跟踪，都是为了让这些部分能够可靠地一起工作，而不是只在一次连接顺利完成时才有结果。

对用户来说，最终改变的是使用方式。无论从哪个终端进入，面对的都可以是同一个了解工作进展的 Agent；需要在哪个环境里做事，就让它使用那个环境的能力。

执行节点的配置与接入方法见工作区与执行节点。多会话如何共享认知，见会话与并发工作；执行任务与工作线程的关系见线程、激活与目标。