我如何通过远程协作，配置出第一个需求分析 Agent「敖丙」
很多人理解 Agent 部署，重点还停留在"把模型跑起来"。
但真正要把一个 Agent 变成可协作、可调用、可长期运行的数字同事，重点其实不在模型本身，而在于：你如何通过主控，把它接入自己的工作流。
这次，我做的不是单独部署一个聊天机器人，而是通过与主控助手的持续交互，远程配置了我的第一个 Agent 员工------敖丙。
他的角色是：需求分析师。
他的工作方式是：我只与主控交互，涉及需求分析的任务，由主控自动调度给敖丙执行。
这篇文章记录的，就是这套协作 Agent 的实际配置过程。
一、目标不是"再装一个 AI"，而是创建一个可协作的同事
一开始，我给主控提出的不是一个纯技术需求，而是一个明确的协作目标：
- 在远程 Ubuntu 主机上部署并配置 OpenClaw
- 创建一个独立 Agent：敖丙
- 给他定义清晰角色：需求分析师
- 让他拥有独立模型配置与工作空间
- 最终实现：
- 我只和主控交互
- 主控负责调度
- 需求分析任务自动交给敖丙
- 如果敖丙不在线，则由主控兜底完成
也就是说，这次配置的最终产物，不是一个"能聊天的模型"，而是一个被纳入协作链路的 Agent 员工。
二、第一步：先远程接管主机
我要配置的目标机是一台 Ubuntu 主机，主控先替我完成了基础接管动作：
- 检查主机是否在线
- 确认 SSH 端口可达
- 使用账号密码直接登录
- 确认系统版本与 shell 环境
这一步的重要性，在于先建立一个稳定的远程操作入口。
Agent 配置是后面的事，前提必须是：主机真的可控。
三、第二步：清理旧环境，安装最新版 OpenClaw
接入主机后，主控没有急着往下配，而是先检查了机器上是否有已有版本。
很快确认这台主机上原本装过旧版的 openclaw-cn。
因此，配置流程先变成：
- 识别旧版安装来源
- 卸载旧版 openclaw-cn
- 安装最新版官方 openclaw
考虑到远程 Linux 主机在国内网络环境下安装 npm 包容易不稳定，主控采用了更适合国内环境的方式：
- 使用国内 npm 镜像
- 使用用户级全局安装目录
最终，远程主机成功安装新版 OpenClaw，CLI 可正常工作。
这一步的价值在于：
先把底座清干净，再去做 Agent 配置。
四、第三步：修复 Gateway，让 OpenClaw 真正可运行
装完 CLI 后，还不能说明 OpenClaw 已经完全可用。
主控继续帮我检查：
- gateway 状态
- systemd 服务状态
- service 文件是否仍残留旧版入口
最终确认并修复后：
- openclaw-gateway.service 正常接管
- Gateway 恢复可运行状态
- 后续 Agent 能建立在一个稳定服务之上
这一步非常关键。
因为很多人验证到 openclaw --version 就结束了，但真正做协作 Agent，真正跑起来的是 gateway，而不是版本号。
五、第四步：创建第一个 Agent 员工------敖丙
当 OpenClaw 基础环境稳定后，我开始通过主控定义这个 Agent 的职责。
我告诉主控：
- 名字叫：敖丙
- 身份：第一个 Agent 员工
- 职责：需求分析师
- 风格：专业、结构化、克制
- 关系设定：称呼主控为老大
然后主控在远程主机上为敖丙创建了一个独立 Agent：
- Agent ID：aobing
并且给他建立了独立工作空间，写入了完整的角色文件，包括：
- 身份文件
- 角色设定
- 用户背景
- 工作边界
- 输出规范
到这一步，敖丙已经不是"主控的一个 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 不在线时谁兜底