1. 为什么我要折腾一个 8 人 AI 开发团队先说结论我花了大概三周时间用 OpenClaw 把 8 个各司其职的 Agent 串成了一条能跑通的开发流水线从需求拆解、接口设计、代码生成、测试用例编写到文档产出基本能覆盖一个中小型项目的日常开发节奏。这套东西不是什么实验室里的玩具它现在就在我本地和一台常开的开发机上跑着每天帮我处理重复度高的编码任务。先说清楚这套东西是什么。OpenClaw 是一个支持多 Agent 编排的开源框架核心配置文件是openclaw.json你可以把它理解成一个团队花名册 工作流调度器。它本身不产生智能智能来自你接入的模型算力OpenClaw 负责的是让多个 Agent 之间能分工、能传话、能按顺序或并行地干活。8 人团队的意思不是真的雇了 8 个人而是我配置了 8 个角色化的 Agent产品经理、架构师、前端、后端、测试、文档、代码审查、以及一个负责统筹的协调者。这套方案解决的核心问题是单个 Agent 干复杂项目时容易精神分裂——一会儿要它想需求一会儿要它写代码一会儿又要它自查上下文一长就开始胡说。拆成多个专职 Agent 之后每个 Agent 的职责边界清晰提示词可以写得很聚焦输出质量明显稳定。适合谁来参考我觉得有三类人一是想入门 AI Agent 开发但不知道从哪下手的开发者二是手里有重复性开发任务、想用自动化提效的独立开发者或小团队三是已经在用单个 Agent 但被上下文混乱折磨得够呛的人。我踩过的第一个坑就是贪多。一开始我想让一个 Agent 同时干产品、架构、编码三件事结果它写出来的需求文档里混着代码片段代码里又混着测试断言整个一锅粥。后来才明白多 Agent 的价值不在于多而在于分分工本身就是质量保障。2. 整体架构设计与角色拆解思路2.1 为什么是 8 个角色而不是 3 个或 15 个角色数量不是拍脑袋定的。我试过 3 个角色的极简版一个负责想一个负责写一个负责查。跑下来发现想这个环节太重了需求分析、技术选型、接口设计全压在一个 Agent 身上它输出的东西经常前后矛盾。后来又试过 15 个角色的豪华版结果协调成本爆炸Agent 之间传话的损耗比干活还多一个简单任务要转七八手每转一手就丢一点信息。8 个是我实测下来比较舒服的平衡点。具体分工是这样的角色职责输入输出协调者拆任务、派活、汇总用户原始需求任务清单产品经理需求细化、验收标准任务清单需求文档架构师技术选型、接口设计需求文档架构说明 接口定义前端页面与交互代码接口定义前端代码后端服务与数据逻辑接口定义后端代码测试用例设计与验证需求 代码测试用例 报告代码审查规范与隐患检查代码审查意见文档使用说明与注释全部产出文档这个分工的逻辑是把思考类和执行类分开把生产类和检查类分开。协调者和产品经理负责想清楚架构师负责定规矩前后端负责按规矩干活测试和审查负责挑毛病文档负责收尾。每个角色的提示词都能写得很窄窄就意味着稳定。2.2 串行还是并行这是个问题Agent 之间的协作模式我试过三种全串行、全并行、混合。全串行就是 A 干完 B 干B 干完 C 干简单但慢一个任务链跑下来要等很久。全并行就是所有 Agent 同时开工快是快但前端还没拿到接口定义就开始写页面写出来的东西跟后端对不上。最后我采用的是混合模式协调者 → 产品经理 → 架构师这三步串行因为后面的活都依赖前面的产出架构师定完接口之后前端、后端、测试可以并行开工等代码产出后代码审查和文档再并行。这样既保证了依赖关系又压榨了并行度。在openclaw.json里这个依赖关系是通过depends_on字段表达的。我一开始没写这个字段结果 OpenClaw 默认全部并行前端 Agent 在接口还没定的时候就瞎写浪费了不少算力。后来加上依赖声明整个流程才顺起来。2.3 模型算力怎么分配才不浪费8 个 Agent 如果都用同一个大模型成本会很高而且没必要。我的分配策略是思考类角色协调者、产品经理、架构师用能力强的模型执行类角色前端、后端、测试用中等模型检查类角色代码审查、文档用中等偏上的模型。这个分配的逻辑是思考类角色的输出是方向性的方向错了后面全错所以值得用好模型执行类角色是按图施工图纸清楚的话中等模型也能干好检查类角色需要一定的判断力太弱的模型挑不出毛病。OpenClaw 支持给每个 Agent 单独指定模型和算力来源。这里要说明一下OpenClaw 本身不绑定特定算力你可以接 API也可以接本地部署的模型服务。我本地用 Ollama 跑了一个中等模型专门给执行类 Agent 用思考类走 API这样成本能压下来不少。具体怎么接后面实操部分会讲。3. 核心配置文件 openclaw.json 逐字段拆解3.1 文件整体结构长什么样openclaw.json是整个团队的大脑它定义了有哪些 Agent、每个 Agent 用什么模型、它们之间怎么协作。我先把我的完整结构骨架贴出来然后逐块讲。{ version: 1.0, team: { name: dev-team-8, mode: hybrid }, agents: [ { id: coordinator, role: 协调者, model: strong-model, prompt_file: ./prompts/coordinator.md, depends_on: [] } ], workflow: { stages: [] }, runtime: { max_concurrency: 4, timeout_seconds: 600 } }这个结构里team.mode我设成了hybrid就是前面说的混合协作模式。agents数组里每个元素就是一个 Agent 的定义。workflow.stages定义阶段和依赖。runtime是运行时参数max_concurrency控制同时最多几个 Agent 在跑我设成 4 是因为我的机器同时跑太多会卡。3.2 Agent 定义里的关键字段每个 Agent 的定义里我觉得最关键的三个字段是id、prompt_file和depends_on。id是唯一标识工作流里引用 Agent 全靠它所以命名要清晰别用agent1、agent2这种后期根本记不住谁是谁。我用的是角色英文名一看就懂。prompt_file指向这个 Agent 的提示词文件。我强烈建议把提示词单独放文件里不要内联在 JSON 里。原因有两个一是 JSON 里写长文本转义很痛苦二是提示词需要反复迭代单独文件方便版本管理。我的提示词文件都放在./prompts/目录下每个角色一个 markdown 文件。depends_on是依赖声明数组里填前置 Agent 的 id。这个字段决定了执行顺序。比如架构师的depends_on是[product_manager]意思是他要等产品经理干完才能开工。这里有个坑我要提醒depends_on只声明直接依赖不要写传递依赖。比如前端依赖架构师架构师依赖产品经理那前端只需要写[architect]不用把产品经理也写进去。OpenClaw 会自动解析传递关系。我一开始把传递依赖也写全了结果工作流引擎报了一堆循环依赖的警告排查了半天才发现是自己画蛇添足。3.3 提示词文件怎么写才聚焦提示词的质量直接决定 Agent 的输出质量。我的经验是每个角色的提示词只写这个角色该关心的事别越界。以产品经理的提示词为例我的写法是这样的结构先定义角色身份再定义输入是什么然后定义输出格式最后给几条硬性约束。身份部分要写清楚你是一个专注于需求分析的产品经理不负责技术实现输入部分说明你会收到一份任务清单输出格式我要求用固定的 markdown 模板包含需求描述、验收标准、边界条件三块约束部分我会写不要输出任何代码、验收标准必须可量化。代码审查角色的提示词则完全不同重点是检查清单命名规范、错误处理、边界情况、安全隐患、性能问题。我会把检查项列成清单要求它逐项过。这里的心得是提示词里的约束要具体不要写注意代码质量这种空话要写所有函数必须有错误处理分支这种可执行的规则。空话模型会忽略具体规则它才会照做。4. 从零搭建的完整实操流程4.1 环境准备与 OpenClaw 安装我的开发环境是 Windows 加 WSL2。这里先说明一下如果你在 Windows 上直接跑 OpenClaw 遇到环境验证问题通常是因为 WSL 没配好。可以在 PowerShell 里运行wsl --status看看状态如果显示未安装或版本不对先把 WSL2 装好再继续。我一开始就是没装 WSL 直接跑报了一堆路径错误装完 WSL2 之后世界就清净了。OpenClaw 依赖 Node.js 环境建议用 Node.js 18 以上的 LTS 版本。安装步骤我整理成清单确认 Node.js 版本node -v低于 18 的先升级全局安装 OpenClawnpm install -g openclaw验证安装openclaw --version初始化项目openclaw init dev-team-8进入项目目录你会看到生成的openclaw.json骨架初始化之后目录结构大概是这样的根目录下有openclaw.json还有prompts/、workspace/、logs/三个目录。prompts/放提示词workspace/放 Agent 的产出文件logs/放运行日志。我建议先把logs/的日志级别调到 debug前期排查问题全靠它。4.2 算力接入的两种方式OpenClaw 本身不提供算力你得告诉它去哪拿。我实测过两种方式各有适用场景。第一种是接 API。在openclaw.json的runtime里配置算力端点或者在环境变量里配置访问凭证。这种方式的好处是模型能力强、响应快缺点是按量计费跑得多成本上来了。我思考类 Agent 走的就是这条路。第二种是接本地模型服务。我在本地用 Ollama 部署了一个中等规模的模型OpenClaw 通过本地端口访问它。这种方式的好处是零边际成本、数据不出本地缺点是模型能力有限、速度取决于你的硬件。我执行类 Agent 走的是这条路。配置本地算力的时候Ollama 要先跑起来确认端口能访问再在 OpenClaw 里填地址。我踩过的坑是 Ollama 默认只监听本地回环地址如果 OpenClaw 跑在 WSL 里而 Ollama 跑在 Windows 宿主机上两边网络不通。解决办法是让 Ollama 监听所有网卡然后在 OpenClaw 里填宿主机的局域网地址。这个细节文档里往往不写但实际部署时特别容易卡住。4.3 八个 Agent 的配置落地配置 8 个 Agent 是个体力活但有几个技巧能让它不那么痛苦。第一先配一个跑通再复制。我先把协调者配好跑一个最简单的任务验证链路通了然后再照着复制其他 7 个。这样出问题的时候范围小好排查。第二提示词文件先写骨架再填肉。每个提示词文件我先写好身份、输入、输出、约束四个标题内容先留空等配置跑通了再慢慢填。这样能快速验证配置结构对不对不用等提示词写完。第三依赖关系画个图再写。我在纸上画了个简单的依赖图谁依赖谁一目了然然后照着图写depends_on比在脑子里想靠谱多了。配置完成后用openclaw validate命令校验配置文件。这个命令会检查 JSON 语法、依赖关系、提示词文件是否存在。我每次改完配置都跑一遍能提前发现大部分低级错误。4.4 第一次跑通全流程第一次跑全流程我建议用一个极简任务比如写一个计算两个数之和的函数。任务虽小但能走完整个链路协调者拆任务、产品经理写需求、架构师定接口、前后端写代码、测试写用例、审查挑毛病、文档收尾。跑的时候盯着logs/里的日志看重点看每个 Agent 的输入输出。我第一次跑的时候发现产品经理的输出被架构师忽略了排查发现是工作流里两个 Agent 之间的数据传递字段名对不上。OpenClaw 默认用output字段传递我在产品经理的配置里自定义了输出字段名导致下游拿不到数据。改回默认字段名就好了。这个坑的教训是除非有特殊需求否则别改默认的字段名。框架的约定是有道理的乱改只会给自己找麻烦。5. 多 Agent 协作中的典型问题与排查5.1 Agent 之间信息丢失怎么办多 Agent 协作最常见的问题就是信息在传递过程中丢失。表现是下游 Agent 的输出跟上游对不上比如架构师定的接口是三个参数后端实现成了两个。排查思路是这样的先看日志里上游 Agent 的完整输出确认信息确实产生了再看下游 Agent 的完整输入确认信息有没有传过去。如果上游有、下游没有那就是传递环节的问题检查工作流配置里的字段映射。如果下游收到了但没按上游的来那就是提示词的问题下游 Agent 没重视输入信息。我的解决办法是在下游 Agent 的提示词里加一条硬约束你的输出必须严格基于上游提供的接口定义不得自行增删参数。加了这条之后对不上的情况少了很多。5.2 某个 Agent 卡住或超时Agent 卡住通常有两个原因一是模型响应慢二是任务太复杂导致模型陷入循环。模型响应慢的话看日志里的请求时间如果单个请求超过一两分钟可能是算力端点的问题检查网络和端点负载。任务太复杂的话表现是模型反复输出类似内容绕不出来。这时候要么把任务拆得更细要么在提示词里加如果信息不足直接说明缺少什么不要猜测。我在runtime里设了timeout_seconds超时后 OpenClaw 会中断这个 Agent 并记录错误。我建议这个值不要设太大600 秒差不多设太大卡住了要等很久才发现。5.3 输出质量不稳定的排查同样的任务有时候输出很好有时候一塌糊涂这种不稳定最让人头疼。我的排查清单是这样的现象可能原因排查方法输出格式乱提示词输出格式约束不明确检查提示词是否有固定模板内容跑偏角色边界不清检查提示词是否越界前后矛盾上下文太长缩短输入或拆分任务遗漏要点约束太多模型顾不过来精简提示词抓核心约束实测下来输出不稳定八成是提示词的问题。提示词越聚焦、约束越具体输出越稳定。我现在的习惯是每次输出不稳定先回去改提示词而不是怀疑模型。5.4 并发跑起来机器扛不住8 个 Agent 如果同时跑对机器压力不小。我的max_concurrency设成 4就是同时最多 4 个在跑其他的排队。这个值要根据你的机器配置调内存小就调低点宁可慢点也别把机器跑挂。另外本地模型服务如果和 OpenClaw 跑在同一台机器上并发高的时候会互相抢资源。我的做法是把本地模型服务单独放一台机器OpenClaw 通过网络访问它这样两边互不干扰。6. 让团队真正好用的几个进阶技巧6.1 给 Agent 加记忆默认情况下每个 Agent 都是无状态的跑完就忘。但有些信息需要跨任务保留比如项目的技术栈约定、代码规范。我的做法是在workspace/下放一个context.md文件每个 Agent 的提示词里都要求先读这个文件。这样相当于给整个团队加了一份共享记忆。这个文件我会定期更新把踩过的坑、定下的规矩都写进去。时间长了它就成了团队的宪法新任务跑的时候大家都照着来一致性好了很多。6.2 用飞书做任务通知和结果汇总Agent 跑任务的时候人不可能一直盯着我接了个飞书机器人做通知。任务开始、结束、出错的时候机器人往群里发消息。产出文件我也会让文档 Agent 整理成表格通过飞书机器人发出来这样在手机上也 OpenClaw多Agent协作实战：8人AI开发团队配置与避坑指南
1. 为什么我要折腾一个 8 人 AI 开发团队先说结论我花了大概三周时间用 OpenClaw 把 8 个各司其职的 Agent 串成了一条能跑通的开发流水线从需求拆解、接口设计、代码生成、测试用例编写到文档产出基本能覆盖一个中小型项目的日常开发节奏。这套东西不是什么实验室里的玩具它现在就在我本地和一台常开的开发机上跑着每天帮我处理重复度高的编码任务。先说清楚这套东西是什么。OpenClaw 是一个支持多 Agent 编排的开源框架核心配置文件是openclaw.json你可以把它理解成一个团队花名册 工作流调度器。它本身不产生智能智能来自你接入的模型算力OpenClaw 负责的是让多个 Agent 之间能分工、能传话、能按顺序或并行地干活。8 人团队的意思不是真的雇了 8 个人而是我配置了 8 个角色化的 Agent产品经理、架构师、前端、后端、测试、文档、代码审查、以及一个负责统筹的协调者。这套方案解决的核心问题是单个 Agent 干复杂项目时容易精神分裂——一会儿要它想需求一会儿要它写代码一会儿又要它自查上下文一长就开始胡说。拆成多个专职 Agent 之后每个 Agent 的职责边界清晰提示词可以写得很聚焦输出质量明显稳定。适合谁来参考我觉得有三类人一是想入门 AI Agent 开发但不知道从哪下手的开发者二是手里有重复性开发任务、想用自动化提效的独立开发者或小团队三是已经在用单个 Agent 但被上下文混乱折磨得够呛的人。我踩过的第一个坑就是贪多。一开始我想让一个 Agent 同时干产品、架构、编码三件事结果它写出来的需求文档里混着代码片段代码里又混着测试断言整个一锅粥。后来才明白多 Agent 的价值不在于多而在于分分工本身就是质量保障。2. 整体架构设计与角色拆解思路2.1 为什么是 8 个角色而不是 3 个或 15 个角色数量不是拍脑袋定的。我试过 3 个角色的极简版一个负责想一个负责写一个负责查。跑下来发现想这个环节太重了需求分析、技术选型、接口设计全压在一个 Agent 身上它输出的东西经常前后矛盾。后来又试过 15 个角色的豪华版结果协调成本爆炸Agent 之间传话的损耗比干活还多一个简单任务要转七八手每转一手就丢一点信息。8 个是我实测下来比较舒服的平衡点。具体分工是这样的角色职责输入输出协调者拆任务、派活、汇总用户原始需求任务清单产品经理需求细化、验收标准任务清单需求文档架构师技术选型、接口设计需求文档架构说明 接口定义前端页面与交互代码接口定义前端代码后端服务与数据逻辑接口定义后端代码测试用例设计与验证需求 代码测试用例 报告代码审查规范与隐患检查代码审查意见文档使用说明与注释全部产出文档这个分工的逻辑是把思考类和执行类分开把生产类和检查类分开。协调者和产品经理负责想清楚架构师负责定规矩前后端负责按规矩干活测试和审查负责挑毛病文档负责收尾。每个角色的提示词都能写得很窄窄就意味着稳定。2.2 串行还是并行这是个问题Agent 之间的协作模式我试过三种全串行、全并行、混合。全串行就是 A 干完 B 干B 干完 C 干简单但慢一个任务链跑下来要等很久。全并行就是所有 Agent 同时开工快是快但前端还没拿到接口定义就开始写页面写出来的东西跟后端对不上。最后我采用的是混合模式协调者 → 产品经理 → 架构师这三步串行因为后面的活都依赖前面的产出架构师定完接口之后前端、后端、测试可以并行开工等代码产出后代码审查和文档再并行。这样既保证了依赖关系又压榨了并行度。在openclaw.json里这个依赖关系是通过depends_on字段表达的。我一开始没写这个字段结果 OpenClaw 默认全部并行前端 Agent 在接口还没定的时候就瞎写浪费了不少算力。后来加上依赖声明整个流程才顺起来。2.3 模型算力怎么分配才不浪费8 个 Agent 如果都用同一个大模型成本会很高而且没必要。我的分配策略是思考类角色协调者、产品经理、架构师用能力强的模型执行类角色前端、后端、测试用中等模型检查类角色代码审查、文档用中等偏上的模型。这个分配的逻辑是思考类角色的输出是方向性的方向错了后面全错所以值得用好模型执行类角色是按图施工图纸清楚的话中等模型也能干好检查类角色需要一定的判断力太弱的模型挑不出毛病。OpenClaw 支持给每个 Agent 单独指定模型和算力来源。这里要说明一下OpenClaw 本身不绑定特定算力你可以接 API也可以接本地部署的模型服务。我本地用 Ollama 跑了一个中等模型专门给执行类 Agent 用思考类走 API这样成本能压下来不少。具体怎么接后面实操部分会讲。3. 核心配置文件 openclaw.json 逐字段拆解3.1 文件整体结构长什么样openclaw.json是整个团队的大脑它定义了有哪些 Agent、每个 Agent 用什么模型、它们之间怎么协作。我先把我的完整结构骨架贴出来然后逐块讲。{ version: 1.0, team: { name: dev-team-8, mode: hybrid }, agents: [ { id: coordinator, role: 协调者, model: strong-model, prompt_file: ./prompts/coordinator.md, depends_on: [] } ], workflow: { stages: [] }, runtime: { max_concurrency: 4, timeout_seconds: 600 } }这个结构里team.mode我设成了hybrid就是前面说的混合协作模式。agents数组里每个元素就是一个 Agent 的定义。workflow.stages定义阶段和依赖。runtime是运行时参数max_concurrency控制同时最多几个 Agent 在跑我设成 4 是因为我的机器同时跑太多会卡。3.2 Agent 定义里的关键字段每个 Agent 的定义里我觉得最关键的三个字段是id、prompt_file和depends_on。id是唯一标识工作流里引用 Agent 全靠它所以命名要清晰别用agent1、agent2这种后期根本记不住谁是谁。我用的是角色英文名一看就懂。prompt_file指向这个 Agent 的提示词文件。我强烈建议把提示词单独放文件里不要内联在 JSON 里。原因有两个一是 JSON 里写长文本转义很痛苦二是提示词需要反复迭代单独文件方便版本管理。我的提示词文件都放在./prompts/目录下每个角色一个 markdown 文件。depends_on是依赖声明数组里填前置 Agent 的 id。这个字段决定了执行顺序。比如架构师的depends_on是[product_manager]意思是他要等产品经理干完才能开工。这里有个坑我要提醒depends_on只声明直接依赖不要写传递依赖。比如前端依赖架构师架构师依赖产品经理那前端只需要写[architect]不用把产品经理也写进去。OpenClaw 会自动解析传递关系。我一开始把传递依赖也写全了结果工作流引擎报了一堆循环依赖的警告排查了半天才发现是自己画蛇添足。3.3 提示词文件怎么写才聚焦提示词的质量直接决定 Agent 的输出质量。我的经验是每个角色的提示词只写这个角色该关心的事别越界。以产品经理的提示词为例我的写法是这样的结构先定义角色身份再定义输入是什么然后定义输出格式最后给几条硬性约束。身份部分要写清楚你是一个专注于需求分析的产品经理不负责技术实现输入部分说明你会收到一份任务清单输出格式我要求用固定的 markdown 模板包含需求描述、验收标准、边界条件三块约束部分我会写不要输出任何代码、验收标准必须可量化。代码审查角色的提示词则完全不同重点是检查清单命名规范、错误处理、边界情况、安全隐患、性能问题。我会把检查项列成清单要求它逐项过。这里的心得是提示词里的约束要具体不要写注意代码质量这种空话要写所有函数必须有错误处理分支这种可执行的规则。空话模型会忽略具体规则它才会照做。4. 从零搭建的完整实操流程4.1 环境准备与 OpenClaw 安装我的开发环境是 Windows 加 WSL2。这里先说明一下如果你在 Windows 上直接跑 OpenClaw 遇到环境验证问题通常是因为 WSL 没配好。可以在 PowerShell 里运行wsl --status看看状态如果显示未安装或版本不对先把 WSL2 装好再继续。我一开始就是没装 WSL 直接跑报了一堆路径错误装完 WSL2 之后世界就清净了。OpenClaw 依赖 Node.js 环境建议用 Node.js 18 以上的 LTS 版本。安装步骤我整理成清单确认 Node.js 版本node -v低于 18 的先升级全局安装 OpenClawnpm install -g openclaw验证安装openclaw --version初始化项目openclaw init dev-team-8进入项目目录你会看到生成的openclaw.json骨架初始化之后目录结构大概是这样的根目录下有openclaw.json还有prompts/、workspace/、logs/三个目录。prompts/放提示词workspace/放 Agent 的产出文件logs/放运行日志。我建议先把logs/的日志级别调到 debug前期排查问题全靠它。4.2 算力接入的两种方式OpenClaw 本身不提供算力你得告诉它去哪拿。我实测过两种方式各有适用场景。第一种是接 API。在openclaw.json的runtime里配置算力端点或者在环境变量里配置访问凭证。这种方式的好处是模型能力强、响应快缺点是按量计费跑得多成本上来了。我思考类 Agent 走的就是这条路。第二种是接本地模型服务。我在本地用 Ollama 部署了一个中等规模的模型OpenClaw 通过本地端口访问它。这种方式的好处是零边际成本、数据不出本地缺点是模型能力有限、速度取决于你的硬件。我执行类 Agent 走的是这条路。配置本地算力的时候Ollama 要先跑起来确认端口能访问再在 OpenClaw 里填地址。我踩过的坑是 Ollama 默认只监听本地回环地址如果 OpenClaw 跑在 WSL 里而 Ollama 跑在 Windows 宿主机上两边网络不通。解决办法是让 Ollama 监听所有网卡然后在 OpenClaw 里填宿主机的局域网地址。这个细节文档里往往不写但实际部署时特别容易卡住。4.3 八个 Agent 的配置落地配置 8 个 Agent 是个体力活但有几个技巧能让它不那么痛苦。第一先配一个跑通再复制。我先把协调者配好跑一个最简单的任务验证链路通了然后再照着复制其他 7 个。这样出问题的时候范围小好排查。第二提示词文件先写骨架再填肉。每个提示词文件我先写好身份、输入、输出、约束四个标题内容先留空等配置跑通了再慢慢填。这样能快速验证配置结构对不对不用等提示词写完。第三依赖关系画个图再写。我在纸上画了个简单的依赖图谁依赖谁一目了然然后照着图写depends_on比在脑子里想靠谱多了。配置完成后用openclaw validate命令校验配置文件。这个命令会检查 JSON 语法、依赖关系、提示词文件是否存在。我每次改完配置都跑一遍能提前发现大部分低级错误。4.4 第一次跑通全流程第一次跑全流程我建议用一个极简任务比如写一个计算两个数之和的函数。任务虽小但能走完整个链路协调者拆任务、产品经理写需求、架构师定接口、前后端写代码、测试写用例、审查挑毛病、文档收尾。跑的时候盯着logs/里的日志看重点看每个 Agent 的输入输出。我第一次跑的时候发现产品经理的输出被架构师忽略了排查发现是工作流里两个 Agent 之间的数据传递字段名对不上。OpenClaw 默认用output字段传递我在产品经理的配置里自定义了输出字段名导致下游拿不到数据。改回默认字段名就好了。这个坑的教训是除非有特殊需求否则别改默认的字段名。框架的约定是有道理的乱改只会给自己找麻烦。5. 多 Agent 协作中的典型问题与排查5.1 Agent 之间信息丢失怎么办多 Agent 协作最常见的问题就是信息在传递过程中丢失。表现是下游 Agent 的输出跟上游对不上比如架构师定的接口是三个参数后端实现成了两个。排查思路是这样的先看日志里上游 Agent 的完整输出确认信息确实产生了再看下游 Agent 的完整输入确认信息有没有传过去。如果上游有、下游没有那就是传递环节的问题检查工作流配置里的字段映射。如果下游收到了但没按上游的来那就是提示词的问题下游 Agent 没重视输入信息。我的解决办法是在下游 Agent 的提示词里加一条硬约束你的输出必须严格基于上游提供的接口定义不得自行增删参数。加了这条之后对不上的情况少了很多。5.2 某个 Agent 卡住或超时Agent 卡住通常有两个原因一是模型响应慢二是任务太复杂导致模型陷入循环。模型响应慢的话看日志里的请求时间如果单个请求超过一两分钟可能是算力端点的问题检查网络和端点负载。任务太复杂的话表现是模型反复输出类似内容绕不出来。这时候要么把任务拆得更细要么在提示词里加如果信息不足直接说明缺少什么不要猜测。我在runtime里设了timeout_seconds超时后 OpenClaw 会中断这个 Agent 并记录错误。我建议这个值不要设太大600 秒差不多设太大卡住了要等很久才发现。5.3 输出质量不稳定的排查同样的任务有时候输出很好有时候一塌糊涂这种不稳定最让人头疼。我的排查清单是这样的现象可能原因排查方法输出格式乱提示词输出格式约束不明确检查提示词是否有固定模板内容跑偏角色边界不清检查提示词是否越界前后矛盾上下文太长缩短输入或拆分任务遗漏要点约束太多模型顾不过来精简提示词抓核心约束实测下来输出不稳定八成是提示词的问题。提示词越聚焦、约束越具体输出越稳定。我现在的习惯是每次输出不稳定先回去改提示词而不是怀疑模型。5.4 并发跑起来机器扛不住8 个 Agent 如果同时跑对机器压力不小。我的max_concurrency设成 4就是同时最多 4 个在跑其他的排队。这个值要根据你的机器配置调内存小就调低点宁可慢点也别把机器跑挂。另外本地模型服务如果和 OpenClaw 跑在同一台机器上并发高的时候会互相抢资源。我的做法是把本地模型服务单独放一台机器OpenClaw 通过网络访问它这样两边互不干扰。6. 让团队真正好用的几个进阶技巧6.1 给 Agent 加记忆默认情况下每个 Agent 都是无状态的跑完就忘。但有些信息需要跨任务保留比如项目的技术栈约定、代码规范。我的做法是在workspace/下放一个context.md文件每个 Agent 的提示词里都要求先读这个文件。这样相当于给整个团队加了一份共享记忆。这个文件我会定期更新把踩过的坑、定下的规矩都写进去。时间长了它就成了团队的宪法新任务跑的时候大家都照着来一致性好了很多。6.2 用飞书做任务通知和结果汇总Agent 跑任务的时候人不可能一直盯着我接了个飞书机器人做通知。任务开始、结束、出错的时候机器人往群里发消息。产出文件我也会让文档 Agent 整理成表格通过飞书机器人发出来这样在手机上也