在上次发布了如何用 TRAE 部署 OpenClaw “小龙虾”之后呢，后台也收到了很多留言，大家问的最多的一个问题就是什么时候可以用自己的“小龙虾” 安排 TRAE 帮他干活呢？
想象一下这个场景：你在路上、在咖啡馆、或者只是暂时离开了工位，但你仍然希望用一句自然语言，调度自己电脑上的 TRAE 去看代码、分析项目、实现功能、整理结果。这正是这个方法想解决的问题。
今天为大家带来一个 TRAE 友自己的实践，看他是如何通过一个指令，就安排 TRAE 帮他干活的～
方案介绍
在开始之前，我们先简单理解一下这个方案。
-
OpenClaw：你可以把它想象成一个超级聪明的大脑，一个全能的 AI 助手。它能理解你的话，帮你思考和决策。
-
TRAE：这则是一个任劳任怨的“动手专家”，一个安装在你电脑里的 AI 驱动的集成开发环境（IDE）。它熟悉你电脑里的所有文件和项目，能真正地编写代码、执行任务。
-
TRAEClaw 插件（来自 TRAE 友开发），就像连接大脑和双手的“神经”。它的作用，就是把你在任何地方（例如飞书）对 OpenClaw 下达的命令，精准地“翻译”并传递给你自己电脑里的 TRAE，让 TRAE 这个最熟悉你工作环境的“本地专家”来完成实际操作。
整个过程就像这样：你（在任何地方） → 对话 OpenClaw → TRAEClaw 插件（传递指令） → 你电脑上的 TRAE（执行任务）
配置前准备工作
在正式开始配置之前，你需要保证自己完成了以下操作：
-
你的电脑 / 机器上已经安装 TRAE 国际版（https://www.trae.ai/）
-
至少完成过一次 TRAE 登录
-
本地已经配置好可用的 OpenClaw（这个部分可以参考往期官方账号发布的教程：如何用 TRAE 快速部署 OpenClaw）
-
推荐使用 MacOS 系统
一句话配置
只需要对你的 OpenClaw 发出一句指令，对，就是这么简单。
如果你还没有将 OpenClaw 对接到 飞书，你也可以直接在 OpenClaw 的对话页面（http://127.0.0.1:18789）发出指令，如果你配置了飞书，你可以直接在飞书聊天框发出这句指令。
请先阅读 https://github.com/firerlAGI/TraeClaw 仓库里的 AgentS.md 和 AI_INSTALL.zh-CN.md， 然后在 macOS 上通过 npm 安装并启用 TRAEclaw（TRAE-ide）， 验证 openclaw plugins info TRAE-ide 和 openclaw config validate， 提醒我重启 OpenClaw Gateway，再执行一次 TRAE_status，并告诉我接下来怎么用 TRAE_delegate。
通过飞书部署的 OpenClaw 发出
通过 OpenClaw 后台发出
安装后展示
环境介绍：MacOS 15.6.1，TRAE 国际版 3.5.37，OpenClaw 3.11，openclaw models：GLM-4.7
左右滑动查看更多
案例一：用 OpenClaw 指挥 TRAE 制作一个官方论坛前端网页
提示词如下：
使用TRAE模仿https://forum.TRAE.cn/这个网站，开发一个静态网页。注意在TRAE- project 这个文件夹中进行开发。
案例二：用飞书指挥 OpenClaw 作为项目经理，不断打磨案例一中的论坛前端
提示词如下：
现在任命你为这个项目的项目经理 不断打磨这个前端页面的项目，直到和https://forum.trae.cn/ （这个是TRAE的中文社区）做到一致，遇到问题及时向我报告。
图 1：我和我的 OpenClaw 在飞书上的对话（我让他作为项目经理）
图 2：OpenClaw 用项目经理的身份帮我下发的指令，我仅用了上面的那一句提示词，这些指令完全是 OpenClaw 下发的。
图 3：模仿的前端页面，该说不说，还是挺还原的
你也可以告诉你的 OpenClaw：
“让 TRAE 给刚才那个网页加一个更好看的导航栏。”
“让 TRAE 调整一下字体和颜色，风格要更活泼一点。”
TRAEClaw 插件介绍
目前只完成了 Mac 端 OpenClaw 较为稳定的适配，并且 OpenClaw 接入的模型会影响实际效果。注意：目前插件只能对接 TRAE 国际版。
这是一款我自己开发的插件。简单来说，只要安装了它，就可以让 TRAE 与你的 OpenClaw 无痛衔接，把“会理解任务的 AI”与“真正能在本地工程里执行任务的 AI IDE”连成一体。
TRAEClaw 的作用，是让 OpenClaw 能够把 TRAE 桌面端当作一个真正可调用的 IDE 执行器来使用。前者负责理解自然语言、拆解意图与编排任务，后者负责进入本地项目环境，完成代码理解、文件操作与实际执行，而 TRAEClaw 则负责把这两端准确连接起来。
TRAEClaw 采取的是一种更克制、更工程化的方式：它将 TRAE 作为一个可调试的 Chromium / Electron 桌面界面。
他并不依赖“侵入式改造”去接管 TRAE，而是在尽可能保持原有应用结构完整的前提下，为 OpenClaw 打开一条稳定可控的调用通道。
整个插件架构分为四层：
-
插件层
这一层直接挂在 OpenClaw 里，拿到 TRAE_status、TRAE_new_chat、TRAE_delegate 这类工具。用户在 OpenClaw 里发起调用时，首先进入这一层。
-
客户端协调层
插件内部会先做一些通用工作，比如读取配置、检查 TRAEClaw 是否可用、必要时自动启动、整理请求参数、格式化返回结果。这一层的作用是把 OpenClaw 的工具调用，转换成稳定的本地 API 请求。
-
本地网关层
本地网关是整个系统的中枢，负责提供 HTTP 接口、管理会话、处理状态检查、做安全控制，并把“发消息”“新建会话”“切换模式”这些请求转给底层自动化驱动。这一层让插件和 TRAE 的 UI 自动化解耦，后续能力扩展也更方便。
-
自动化执行层
底层通过 CDP 连接 TRAE 的调试目标，再通过 DOM 选择器去识别输入框、发送按钮、回复区域等界面元素，完成实际的输入、提交、等待响应和结果提取。这一层可以理解为“真正替用户在 TRAE 里操作界面”。
目标链路如下：OpenClaw -> TRAE_delegate -> TRAEClaw -> TRAE 桌面端
当前插件主要提供三个能力：
-
TRAE_status：查看 TRAE 当前是否 ready
-
TRAE_new_chat：新建一个 TRAE 对话
-
TRAE_delegate：把任务直接委托给 TRAE
插件还提供了更直观的斜杠命令：
-
/TRAE <任务>
-
/TRAE process <任务>
其中 /TRAE 适合直接交任务，可以直接将<任务>中的内容原封不动的传进 TRAE 中，而不需要 Open Claw 理解后再传达，/TRAE process 则适合在你希望连执行过程也一起回传时使用，会展示 TRAE 智能体的思维链。
在日常开发中，其实直接用自然语言说“帮我用 TRAE 完成什么任务”“帮我用 TRAE 制作一款软件”之类的提示词，就能触发这个插件！
开发的心路历程
最近，在 TRAE 的飞书社群里，我看到大家反复讨论一个问题：能不能用手机对接 TRAE IDE。
OpenClaw 的出现和爆红，让这种想象第一次变得足够具体。它让“用一句话发起任务”这件事不再停留在演示层面，而开始有了真正可感知的产品形态。但与此同时，我也一直有一个很强烈的判断：如果只是直接调用 Coding Model 去做项目开发，它或许足够惊艳，却未必足够贴近真实工程。 真正复杂的开发过程，往往仍然需要发生在 AI IDE 里，需要依赖项目上下文、代码环境、工程状态，以及那种更深入的理解与执行能力。
而我自己作为 TRAE 的 Ultra 用户，日常已经深度依赖 TRAE IDE 参与项目工作。也正因如此，一个想法越来越清晰：如果能把 OpenClaw 的“理解意图”和 TRAE 的“执行工程”真正连接起来，会不会就能拼出一种更完整的体验？
于是，TRAEClaw 这个项目的念头慢慢成形。
我想做的，并不只是一个“手机对接 IDE”的工具，也不只是为两个产品之间补一条通信链路。更准确地说，我想验证的是另一种人机协作方式：人用自然语言发出意图，系统自动找到最合适的执行位置，再把结果带回到人与机器的对话之中。
在这个设想里，OpenClaw 负责“听懂人话”，TRAE 负责“动手干活”，而 TRAEClaw 负责“把话传到手”。它们看上去是三个独立的角色，但理想状态下，它们不应该被用户感知为三个分离的系统，而应该像同一套神经系统的不同部分：理解、传递、执行、反馈，连续发生，自然闭环。
我一直很喜欢一种技术产品的状态：它不只是功能成立，而是让人第一次意识到，原来这件事本来就应该这样发生。
对我来说，这个项目有趣的地方，也恰恰在这里：
如果这条路能走通，那么我们得到的也许不只是一个桥接工具，而是一个更早期的信号：下一代开发体验，不一定发生在单一产品内部，而可能诞生于多个智能体与执行环境之间的协同。
而 TRAEClaw，想做的就是这件事的一次认真尝试。
GitHub 和 npm 包地址
项目地址
-
GitHub 仓库：
https://github.com/firerlAGI/TraeClaw
-
npm 包：
https://www.npmjs.com/package/traeclaw
目前，这个插件会优先适配 macOS 端。这背后主要并不是功能取舍的问题，而是出于稳定性和复现成本的综合考虑。
相较而言，macOS 在 TRAE IDE 的启动方式、调试端口、窗口管理、路径结构以及自动化行为等方面，都表现出更高的一致性。这样的系统环境，更有利于问题定位、链路调试和方案收敛，也更容易打磨出一条稳定、可控、可复现的接入路径。
当然，这并不意味着 Windows 端会被搁置。实际上，Windows 版本也在持续推进中。只是从工程实现的角度来看，我更希望先把一端真正做到稳定可用，再逐步扩展到更多平台。
写在最后
技术的有趣之处，就在于它总能将我们的想象变为现实。
TRAE 鼓励每一位开发者激发创造，发挥自己的想象力，我们期待有更多有意思的开发奇思妙想，每一位 TRAE 友 都是我们产品发展道路上的共建者！
