我如何通过远程协作配置出第一个需求分析 Agent「敖丙」很多人理解 Agent 部署重点还停留在“把模型跑起来”。但真正要把一个 Agent 变成可协作、可调用、可长期运行的数字同事重点其实不在模型本身而在于你如何通过主控把它接入自己的工作流。这次我做的不是单独部署一个聊天机器人而是通过与主控助手的持续交互远程配置了我的第一个 Agent 员工——敖丙。他的角色是需求分析师。他的工作方式是我只与主控交互涉及需求分析的任务由主控自动调度给敖丙执行。这篇文章记录的就是这套协作 Agent 的实际配置过程。一、目标不是“再装一个 AI”而是创建一个可协作的同事一开始我给主控提出的不是一个纯技术需求而是一个明确的协作目标在远程 Ubuntu 主机上部署并配置 OpenClaw创建一个独立 Agent敖丙给他定义清晰角色需求分析师让他拥有独立模型配置与工作空间最终实现我只和主控交互主控负责调度需求分析任务自动交给敖丙如果敖丙不在线则由主控兜底完成也就是说这次配置的最终产物不是一个“能聊天的模型”而是一个被纳入协作链路的 Agent 员工。二、第一步先远程接管主机我要配置的目标机是一台 Ubuntu 主机主控先替我完成了基础接管动作检查主机是否在线确认 SSH 端口可达使用账号密码直接登录确认系统版本与 shell 环境这一步的重要性在于先建立一个稳定的远程操作入口。Agent 配置是后面的事前提必须是主机真的可控。三、第二步清理旧环境安装最新版 OpenClaw接入主机后主控没有急着往下配而是先检查了机器上是否有已有版本。很快确认这台主机上原本装过旧版的 openclaw-cn​。因此配置流程先变成识别旧版安装来源卸载旧版 openclaw-cn​安装最新版官方 openclaw​考虑到远程 Linux 主机在国内网络环境下安装 npm 包容易不稳定主控采用了更适合国内环境的方式使用国内 npm 镜像使用用户级全局安装目录最终远程主机成功安装新版 OpenClawCLI 可正常工作。这一步的价值在于先把底座清干净再去做 Agent 配置。四、第三步修复 Gateway让 OpenClaw 真正可运行装完 CLI 后还不能说明 OpenClaw 已经完全可用。主控继续帮我检查gateway 状态systemd 服务状态service 文件是否仍残留旧版入口最终确认并修复后​openclaw-gateway.service​ 正常接管Gateway 恢复可运行状态后续 Agent 能建立在一个稳定服务之上这一步非常关键。因为很多人验证到 openclaw --version​ 就结束了但真正做协作 Agent真正跑起来的是 gateway而不是版本号。五、第四步创建第一个 Agent 员工——敖丙当 OpenClaw 基础环境稳定后我开始通过主控定义这个 Agent 的职责。我告诉主控名字叫敖丙身份第一个 Agent 员工职责需求分析师风格专业、结构化、克制关系设定称呼主控为老大然后主控在远程主机上为敖丙创建了一个独立 AgentAgent IDaobing​并且给他建立了独立工作空间写入了完整的角色文件包括身份文件角色设定用户背景工作边界输出规范到这一步敖丙已经不是“主控的一个 prompt 分身”而是一个具备明确职责边界的独立 Agent。六、第五步给敖丙配置独立模型链路有了角色以后还要给他配置一条真正独立的模型调用链路。我的要求是不沿用主控默认模型敖丙走自己的本地 OpenAI 兼容模型服务模型引用设为local-openai/gpt-5.4​主控随后完成了几件关键事指定敖丙的模型端点修正为局域网真实可访问地址将模型引用明确切到 local-openai/gpt-5.4​配入 API Key验证 /v1/models​验证 /v1/chat/completions​这一步很重要因为它把“配置文件里写了模型”推进到了“模型真的能返回内容”。最终敖丙具备了自己的模型运行链路本地模型源有效 API Key明确 model id可真实调用七、第六步固定敖丙所在主机的 IP为了让整个协作链路稳定我又让主控把敖丙所在主机固定到一个静态局域网地址。目标是将这台主机固定为 192.168.2.25​主控先完成只读检查当前网卡名当前网关当前路由Netplan 配置状态随后我在本机完成静态地址配置主控再帮我验收结果。最终确认主机地址192.168.2.25/24​默认网关192.168.2.1​路由状态为proto static​这一层的意义在于后续无论是 SSH 管理、Gateway 访问还是局域网内部的 Agent 协作都会更加稳定。八、第七步确认 OpenClaw 开机自启配置一个 Agent如果每次都要手动上线那它就不能算真正的“同事”。所以接下来我让主控检查这台机器上的 OpenClaw 是否已经具备开机自启能力。主控重点检查了​openclaw gateway status​​systemctl --user status openclaw-gateway.service​最终确认OpenClaw Gateway 已经挂载为 systemd 用户服务当前处于运行状态敖丙作为其中的独立 Agent将随 Gateway 可用而可用这意味着敖丙不再是“我想起来才启动的工具”而是一个具备长期在线能力的 Agent 节点。九、第八步验证主控能否把任务交给敖丙这一步是整套配置里最重要的一步。因为我的真实目标从来都不是我直接登录敖丙去跟他说话而是我只和主控对话主控在背后把需求分析任务交给敖丙执行。所以我专门让主控去验证这一点。主控先帮我打开了 OpenClaw 的 HTTP Chat Completions 入口然后重启 Gateway。随后开始做真实派单测试调用 OpenClaw Gateway指定 model openclaw/aobing​发送一个需求分析类任务观察敖丙是否真正接单并返回结果最终测试成功。敖丙返回了一个简短但结构化的需求分析结果包含目标用户核心流程待确认问题到这一步整个协作链路终于成立我 → 主控 → OpenClaw Gateway → 敖丙 → 模型 → 返回结果这不是理论可行而是已经实际跑通。十、第九步确定最终协作规则技术链路打通以后我又补了一条更重要的规则我只和主控交互需求分析类任务默认优先调度给敖丙如果敖丙不在线、不可用、没上班则由主控直接兜底完成主控随后把这条规则记入长期记忆确保它不是一次性的对话约定而是后续可持续执行的协作规则。从这一刻开始敖丙不再只是“一个配置好的 Agent”而是我工作流里一个有边界、有角色、有接入方式的数字同事。十一、这套远程协作配置最大的价值是什么如果只看表面这次做的事情似乎只是装 OpenClaw建一个 Agent配一个模型测一次接口但真正的价值其实在于完成了下面这件事把一个模型能力转化成了一个可以被主控调度、可以纳入组织分工的协作角色。也就是说重点不是“敖丙能回答问题”而是敖丙有明确职责需求分析主控有明确职责调度、整合、兜底我只有一个交互入口主控工作流没有被多 Agent 打碎复杂能力被藏在后台协作中这才是 Agent 真正接近“员工化”的开始。十二、如果你也想这样配置一个协作 Agent关键要点只有五个1. 先稳定远程主机再谈 Agent不要一上来就配 prompt。先确认 SSH、网络、服务基础设施都是稳定的。2. Agent 必须独立真正能协作的 Agent必须至少有独立身份独立工作空间独立职责边界独立模型配置3. 模型可配置不算完成真实调用成功才算一定要验​/v1/models​​/v1/chat/completions​4. 最终要验证“主控能不能派单”如果主控不能把任务交给子 Agent这个 Agent 只是一个摆设配置。5. 协作规则要明确至少要定义清楚什么任务交给谁谁对外汇报子 Agent 不在线时谁兜底