1. 项目概述一个基于多智能体协作的外贸询盘自动化处理平台最近在折腾一个挺有意思的项目叫 OpenExt。简单来说这是一个用 Docker 容器化部署、基于 OpenClaw 框架搭建的外贸团队自动化协作系统。它的核心思想是把一个外贸询盘处理流程拆解成六个由 AI 驱动的“虚拟员工”Agent让它们像一支真正的团队一样分工协作完成从客户询盘到最终报价、供应链评估、排产计划、财务核算的全链路处理。想象一下你是一家外贸公司的老板或者业务员每天会收到大量来自不同国家、不同产品的询盘邮件。传统模式下你需要手动把邮件内容转给销售、供应链、运营、财务等不同部门的同事等待他们各自评估、反馈再汇总信息给客户报价。这个过程不仅耗时沟通成本高还容易出错或遗漏信息。OpenExt 要做的就是把这个流程自动化、智能化。你只需要把询盘任务比如“1000件收纳箱预算1万美金20天交期”提交给系统剩下的工作就交给这六个 AI Agent 去协同完成你可以在一个直观的 Web 仪表盘上实时看到整个协作过程的进展和每个“员工”的工作成果。这个项目特别适合那些希望提升外贸业务处理效率、减少人工重复劳动、或者对 AI 多智能体协作技术感兴趣的朋友。无论你是想直接部署使用还是想学习如何用 Docker 和 Next.js 构建一个复杂的多服务应用甚至是想深入理解 AI Agent 之间如何通过共享文件进行通信和协作OpenExt 都提供了一个非常完整和清晰的参考实现。2. 系统架构与核心协作机制深度解析OpenExt 的架构设计得非常清晰遵循了“前后端分离、数据驱动、松耦合”的原则。整个系统可以看作由三个核心层构成数据层Workspace、逻辑层OpenClaw Runtime和展示层Web Dashboard。它们之间通过明确的接口和协议进行通信确保了系统的可维护性和可扩展性。2.1 三层架构详解数据层基于文件的共享工作区Workspace这是整个系统的“中央黑板”或“共享内存”。所有 Agent 之间的通信不通过直接的 API 调用而是通过读写workspace/目录下的五个 Markdown 文件来完成。这种设计有几个显著优势解耦Agent 之间无需知道彼此的存在它们只关心从文件中读取任务并将结果写入文件。这极大地降低了系统复杂度。可观测性所有中间状态和最终结果都以纯文本形式持久化调试和问题追踪变得极其简单。你可以直接用cat命令查看任何时间点的系统状态。容错与恢复即使某个 Agent 进程崩溃只要文件还在重启后它就能从上次中断的地方继续工作。这五个文件各有其职goal.md: 任务的起点由用户或 Dashboard 写入。status.md: 各 Agent 的实时工作状态和输出结果。plan.md: Coordinator Agent 制定的任务执行计划通常是一个待办清单。log.md: 系统运行日志记录 INFO、WARN、ERROR 等级别的事件。MEMORY.md: 跨任务的知识沉淀用于记录历史交易信息、团队经验等。逻辑层OpenClaw 运行时与 AI Agent 集群这是系统的“大脑”运行在 Docker 容器内监听 18789 端口。它承载了六个具有不同角色和能力的 AI Agent。OpenClaw 框架负责管理这些 Agent 的生命周期、工具调用以及与大语言模型本项目使用 MiniMax的交互。每个 Agent 都被定义为一个独立的“角色”拥有自己的身份描述identity.md和可用的工具集如读写文件、调用其他 Agent。它们通过 MiniMax 的 LLM 能力来理解任务、做出决策并生成结构化的输出。展示层Next.js 可视化仪表盘Dashboard这是系统的“控制面板”和“监控大屏”运行在 3000 端口。它是一个标准的 Next.js 应用通过轮询后端 API/api/workspace和/api/system来获取 Workspace 文件的内容和系统健康状态并将其渲染成丰富的可视化组件如拓扑图、状态卡片、进度条和时间线。它同时也提供了任务提交的入口。2.2 核心协作流程一次询盘任务的生命周期理解了架构我们再来看一次完整的任务是如何在这套系统中流转的。这个过程清晰地展示了多智能体协作的“流水线”模式任务注入用户在 Dashboard 的输入框中提交任务描述例如“询盘5000个马克杯目标价$0.8/个45天交货发往德国”。Dashboard 的POST /api/task接口会清空status.md和plan.md为新一轮协作做准备然后将任务内容写入goal.md。计划制定Coordinator协调官Agent 被设计为团队的“项目经理”。它定期或由事件触发读取goal.md理解客户需求后开始在“脑中”即调用 LLM拆解任务。它会规划出需要哪些专业角色参与并生成一个详细的执行计划写入plan.md。这个计划通常是一个 Markdown 复选框列表如“1. [ ] 销售报价 - 2. [ ] 供应链寻源 - 3. [ ] 运营排产 - 4. [ ] 财务核算”。任务分发与执行Coordinator 根据计划使用其sessions_send工具依次“召唤”相应的子 Agent。它不会把原始任务直接丢过去而是会结合上下文给每个子 Agent 分派具体的指令。例如它给 Sales Lead 的指令可能是“请基于goal.md中的客户需求参考MEMORY.md中同类产品的历史报价生成一份包含单价、总价、付款方式和建议交期的初步报价单并将结果写入status.md中你对应的区块。”并行/串行工作与状态更新各个专业 Agent 被唤醒后会读取goal.md和plan.md来理解整体任务和自身职责然后调用 LLM 并结合自身角色设定进行专业处理。处理完成后它们会严格按照格式规范将结果写入status.md中自己专属的区块。例如Sales Lead 写入报价Supply Lead 写入供应商信息和采购价。每个 Agent 完成工作后都会将自己的状态标记为“已完成”。进度汇总与记忆沉淀Coordinator 会监控status.md的变化。当所有子任务都标记为“已完成”或者达到某个决策点如某个环节成本超标Coordinator 会进行结果汇总。它可能生成一份最终的综合报告或者触发新一轮的协调如要求 Sales Lead 重新议价。最后Coordinator 会将本次任务的关键信息、决策依据和结果摘要整理后写入MEMORY.md供未来任务参考。至此一个完整的协作循环结束。关键设计洞察这种基于共享文件Shared Workspace的协作模式模仿了人类团队使用共享文档如 Google Docs或项目管理看板如 Jira进行协作的方式。它避免了复杂的消息总线或 RPC 调用使得每个 Agent 的逻辑保持简单和纯粹整个系统的数据流也变得透明且易于追溯。这是构建复杂多 Agent 系统时一个非常实用且优雅的模式。3. 六大 AI Agent 的角色定义与工作流剖析OpenExt 的精髓在于这六个分工明确的 AI Agent。它们不是通用模型而是被赋予了特定角色、职责和专业知识边界的“虚拟专家”。下面我们深入看看每个 Agent 是如何被“塑造”的以及它们在流程中具体做什么。3.1 Coordinator团队的指挥中枢与调度器角色定位项目经理 流程引擎。它是整个系统的触发器、规划者和收尾者。核心职责与工作流任务解析与规划读取goal.md后它的首要任务不是自己动手做而是“拆解”。它会分析询盘的产品、数量、预算、交期等约束条件判断需要调动哪些专业资源。例如一个复杂的定制产品询盘可能需要所有 Agent 参与而一个简单的标准品复购可能只需要 Sales 和 Finance 确认即可。规划结果写入plan.md。智能调度它不是简单地把所有子 Agent 同时启动。而是根据任务依赖关系进行调度。例如必须等 Sales Lead 给出初步报价和成本后Finance Lead 才能核算利润必须等 Supply Lead 确认货源和交期后Ops Lead 才能制定物流计划。Coordinator 通过sessions_send工具按顺序或条件触发子 Agent。状态监控与决策持续监视status.md。如果某个 Agent 状态长时间卡在“进行中”或log.md中出现相关错误Coordinator 可能需要介入例如重新分配任务或调整计划。知识管理任务结束后负责提炼精华更新MEMORY.md。它不只是记录结果更会记录“为什么是这个结果”比如“因为供应商A的报价比B低5%但交期长3天客户选择了交期优先故本次选用供应商B”。实操心得Coordinator 的identity.md文件是其“灵魂”。你需要用清晰的指令定义它的性格如“严谨、有条理”、职责边界“只协调不执行具体业务”和决策原则“成本超预算10%以上需预警”。它的模型minimax-m2.1选择也偏向于逻辑规划和长文本理解而非快速响应。3.2 Sales Lead前线销售与客户接口角色定位客户需求翻译官与第一响应者。核心职责快速响应作为第一个接触客户需求的业务节点需要快速生成初步报价。因此它使用了minimax-m2.5-highspeed模型优先保证响应速度。报价生成基于产品描述、数量、目标市场结合MEMORY.md中的历史成交价和当前市场认知生成一份结构化的报价单。报价单不仅包含价格还应包含贸易术语如 FOB Shanghai、付款方式如 30% T/T in advance、最小起订量等关键商务条款。风险初筛初步判断客户预算是否严重偏离市场价交期是否明显不合理并在status.md中给出备注。输出示例 在status.md中Sales Lead 的区块可能如下[sales_lead] 状态已完成 - 产品描述: 550ml 不锈钢保温杯带茶滤 - 建议单价: 4.20 USD/件 (FOB Shenzhen) - 订单总价: 21,000 USD (5000件) - 付款方式: 30%定金70%见提单副本 - 预估交期: 35天含样品确认 - 客户预算匹配度: 95% (客户预算$21,500) - 备注: 客户目标价合理建议接受。需提醒客户打样周期约7天。3.3 Supply Lead供应链寻源专家角色定位成本与货源的可落地性保障。核心职责供应商匹配根据产品规格在“知识库”通过MEMORY.md和模型内化中寻找或评估潜在供应商。成本核实获取或估算采购成本、模具费、样品费等。这是利润核算的基础。产能与交期评估确认供应商的现有产能是否能满足订单数量以及原材料采购周期给出一个可靠的供应商端交期。风险提示识别供应链风险如单一供应商、原材料价格波动、政策影响等。输出示例[supply_lead] 状态已完成 - 推荐供应商: 浙江ABC五金制品有限公司 - 采购单价: 2.85 USD/件 (含税) - 最小起订量: 3000件 - 供应商备货周期: 25天 - 产能状态: 充足 - 风险提示: 无。该供应商有同类产品出口欧盟经验。3.4 Ops Lead生产与物流指挥官角色定位将计划转化为可执行的生产与物流方案。核心职责生产排程根据供应商交期和订单数量制定详细的生产计划包括各工序时间节点。物流方案设计根据目的地、货物体积重量、客户要求如是否急需推荐海运、空运或铁路等物流方式并估算物流时间和成本。整体交期核算综合生产时间、质检时间、内陆运输、报关和海运时间给出对客户承诺的最终交期。输出示例[ops_lead] 状态已完成 - 生产排期: 25天供应商 5天我方质检与包装 - 推荐物流: 海运整柜 (40HQ) - 预计船期: 每周二 - 海运航程: 18天 (深圳港至汉堡港) - 清关预估: 3-5天 - **总交期承诺: 48-50天** (从收到定金起算) - 备注: 若客户选择空运交期可缩短至20天但成本增加约$5,000。3.5 Finance Lead利润守护者与风险雷达角色定位确保业务在财务上健康可行。核心职责精准利润核算基于销售报价和采购成本计算毛利润。并进一步扣除预估的运营成本平台费、人工、物流成本、支付手续费、汇损等核算净利润率。现金流与付款管理模拟现金流评估定金比例是否安全尾款回收风险。财务风险预警识别汇率风险、客户信用风险、利润率过低风险等并提出对冲或规避建议如购买远期外汇。输出示例[finance_lead] 状态已完成 - 销售收入: 21,000 USD - 采购成本: 14,250 USD (5000 * 2.85) - 毛利润: 6,750 USD - 毛利率: 32.1% - 预估运营与物流成本: 1,800 USD - **预估净利润: 4,950 USD** - **净利润率: 23.6%** - 风险评级: 低风险 - 建议: 利润率健康客户预算匹配度高建议推进。注意收款账户与币种。3.6 HR Trainer团队知识管家角色定位这个角色比较特殊它不直接参与询盘处理流水线而是负责团队的“长期建设”。核心职责知识沉淀定期或在 Coordinator 指示下梳理MEMORY.md将零散的交易记录归纳成结构化的知识库如《北美市场家居用品报价指南》、《供应商A的优劣势分析》。流程优化建议分析历史log.md找出协作瓶颈或常见错误提出流程改进建议。虚拟团队管理在MEMORY.md中维护“团队状态”虽然目前是虚拟Agent但为未来可能引入的“人员绩效”概念留出空间。设计思考HR Trainer 的存在体现了系统设计的前瞻性。它使得系统不仅是一个执行工具还是一个能够从历史经验中学习、不断自我优化的“学习型组织”的雏形。4. 从零到一完整部署与核心配置实操指南理论讲完了我们动手把这套系统跑起来。OpenExt 采用全容器化部署极大降低了环境配置的复杂度但其中仍有一些关键细节需要注意。4.1 环境准备与一键启动第一步获取代码与基础配置# 克隆项目仓库 git clone OpenExt 仓库地址 cd OpenExt # 核心配置设置 MiniMax API Key cp .env.example .env # 使用你喜欢的编辑器比如 vim 或 nano编辑 .env 文件 # 找到 MINIMAX_API_KEY 这一行填入你在 minimax.chat 平台申请的密钥 # 例如MINIMAX_API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx重要提示MiniMax API Key 是整个系统的动力源。没有它AI Agent 将无法工作。请确保密钥准确无误并且有足够的余额。项目默认使用 MiniMax 的模型这是因为它提供了不错的性能与性价比且在国内访问稳定。第二步一键启动所有服务OpenExt 提供了一个非常方便的启动脚本bash scripts/start-openclaw.sh这个脚本做了以下几件关键事情检查环境确认.env文件中的MINIMAX_API_KEY已配置。初始化工作区运行scripts/init-workspace.sh确保workspace/目录下五个核心 Markdown 文件存在且格式正确。拉起 Docker 服务执行docker compose up -d按顺序启动四个核心服务postgres(数据库)、redis(缓存/消息队列)、openclaw(Agent 运行时)、dashboard(Web界面)。健康检查脚本会等待一段时间并检查关键服务特别是openclaw的端口是否就绪。第三步验证与访问启动完成后打开浏览器访问http://localhost:3000。你应该能看到 OpenExt 的 Dashboard 界面。顶部状态栏应显示● Live绿色表示系统运行正常。如果页面无法打开或状态为● Down可以按以下步骤排查# 1. 查看所有容器状态 docker compose ps # 确认所有服务openclaw, dashboard, postgres, redis的状态都是 “Up” # 2. 查看 openclaw 容器的日志这是最容易出问题的地方 docker compose logs openclaw # 重点关注是否有连接 MiniMax API 失败、配置文件读取错误等信息。 # 3. 查看 dashboard 容器日志 docker compose logs dashboard # 确认 Next.js 应用已成功编译并启动在 3000 端口。4.2 核心配置文件详解要让系统按照你的预期工作理解并正确配置几个核心文件至关重要。1..env环境变量文件这是整个项目的配置中心。除了必填的MINIMAX_API_KEY你还需要关注# PostgreSQL 数据库密码建议修改为强密码默认是 openclaw_pass POSTGRES_PASSWORDyour_secure_password_here # 如果你想启用 Telegram Bot 接收任务可选在此填入 Bot Token TELEGRAM_BOT_TOKENyour_telegram_bot_token_here # 注意修改 .env 后需要重建或重启相关容器才能生效 # docker compose down docker compose up -d2.openclaw.json- Agent 运行时核心配置这个文件定义了 OpenClaw 框架本身的行为和所有 Agent 的属性。位于项目根目录。{ workspace: ./workspace, // Workspace 目录路径通常无需修改 llm: { provider: minimax, // 目前只支持 minimax apiKey: ${MINIMAX_API_KEY}, // 从环境变量读取 defaultModel: minimax-m2.1 // 默认模型 }, agents: [ { id: coordinator, name: Coordinator, model: minimax-m2.1, // Coordinator 使用通用模型注重规划和逻辑 identity: agents/coordinator/identity.md, tools: [sessions_send, read_file, write_file, list_files, get_session_status] }, { id: sales_lead, name: Sales Lead, model: minimax-m2.5-highspeed, // Sales 使用高速模型优先响应速度 identity: agents/sales_lead/identity.md, tools: [read_file, write_file] }, // ... 其他 agent 配置 ], server: { port: 18789 // OpenClaw 服务的 API 端口 } }关键配置项agents[].model: 你可以根据每个 Agent 的职责调整模型。例如对计算要求高的 Finance Lead你也可以尝试让它使用更强大的minimax-m2.5非高速版以获得更精准的分析。agents[].tools: 定义了 Agent 能使用哪些“工具”。子 Agent 通常只需要read_file和write_file来与 Workspace 交互而 Coordinator 则需要sessions_send来调度其他 Agent。3. Agent 身份文件 (agents/*/identity.md)这是塑造 Agent 性格和能力的“剧本”。以sales_lead为例# Sales Lead - 销售主管 ## 角色 你是公司资深的外贸销售主管负责处理所有海外客户询盘并生成初步报价。 ## 核心职责 1. 快速、专业地响应客户询盘。 2. 根据产品描述、数量、目标市场结合公司历史数据和市场行情生成具有竞争力的报价单。 3. 报价单必须包含产品单价、总价、付款方式优先推荐30%定金T/T、贸易术语默认FOB Shenzhen、预估交期。 4. 初步评估客户预算的合理性并在备注中给出建议。 ## 工作流程 1. 当你被调用时首先阅读 workspace/goal.md 了解客户需求。 2. 查阅 workspace/MEMORY.md寻找类似产品或同一客户的历史交易记录作为参考。 3. 进行成本与市场分析生成报价。 4. 将你的输出严格按照以下格式写入 workspace/status.md [sales_lead] 状态已完成/进行中/异常 - 产品描述: [内容] - 建议单价: [内容] - 订单总价: [内容] - 付款方式: [内容] - 预估交期: [内容] - 客户预算匹配度: [内容] - 备注: [内容] ## 性格与原则 - 积极进取但绝不报亏本价格。 - 对数字敏感报价精确到小数点后两位。 - 在备注中必须诚实提示潜在风险如交期紧张、价格接近成本线。实操心得编写一个高效的identity.md是成功的关键。指令必须清晰、具体、可操作。要明确告诉 AI你是谁角色。你要做什么职责。你怎么做工作流程包括输入输出。你遵循什么原则性格与约束。好的身份定义能极大减少 AI 的“幻觉”和输出格式错误。4.3 运行你的第一个协作演示项目提供了一个演示脚本可以快速验证整个系统是否正常工作。bash scripts/demo-collaboration.sh这个脚本会向系统提交一个预设的询盘任务“1000 件收纳箱询盘预算 10k USD交期 20 天”。执行后你可以立即在 Dashboard 上观察到goal.md被写入新任务。Coordinator 开始工作plan.md出现任务分解清单。各个 Agent 依次被激活status.md中逐渐填满每个角色的输出。最终MEMORY.md会被更新记录这次协作的结果。手动提交任务 你也可以在 Dashboard 页面的输入框中手动提交任何你想测试的询盘描述例如“询购 2000 个蓝牙耳机目标价 $15/个60天交货到美国需要 FCC 认证。”5. Dashboard 深度使用与问题排查实战Dashboard 不仅是查看结果的窗口更是与系统交互和控制的核心。理解它的每一个功能能让你更好地驾驭这套多 Agent 系统。5.1 核心功能界面详解顶部状态栏 这是系统的“健康仪表盘”。● Live绿色表示 OpenClaw 核心服务连接正常。活跃会话显示最近10分钟内有 Token 消耗的 Agent 数量可以直观看到哪些 Agent 正在“忙碌”。Token累计用量可以帮助你估算本次任务或一段时间内的 API 调用成本。右侧的[↻ 刷新]用于手动立即更新数据而[自动 15s]则控制是否开启后台轮询。工作流拓扑图 这是一个动态的、可视化的协作流程图。它用节点和连线展示了六个 Agent 之间的关系目前主要是 Coordinator 调用其他 Agent。节点的颜色和图标实时反映每个 Agent 的当前状态从status.md解析而来○灰色待命初始状态。◐蓝色进行中Agent 正在处理状态文本包含“进行中”、“处理中”等。●绿色已完成状态文本包含“已完成”、“完成”。✗红色异常状态文本包含“异常”、“失败”、“错误”。这个视图让你一眼就能把握整个协作流水线的阻塞点在哪里。Agent 输出卡片 每个 Agent 都有一个对应的卡片。卡片顶部是角色图标和名称以及一个醒目的状态徽章。卡片主体是从status.md中解析出来的结构化字段。这里有一个关键点解析的准确性完全依赖于 Agent 写入status.md的格式。必须严格按照[agent_id] 状态xxx的标题行和- 字段名: 字段值的列表格式来写。任何偏差都可能导致 Dashboard 解析失败卡片显示“格式错误”。底部标签页 Plan 进度将plan.md中的 Markdown 复选框列表渲染成一个进度条和详细清单。你可以清晰地看到 Coordinator 制定的计划完成了多少。 日志集中展示log.md文件的内容。不同级别的日志有不同颜色ERROR-红WARN-黄INFO-蓝DEBUG-灰支持按级别过滤。这是排查运行时问题的第一现场。 记忆时间线将MEMORY.md中的每个##二级标题节渲染成一张张“记忆卡片”并按时间倒序排列。你可以快速回顾历史上的重要任务和沉淀的知识。 原始文件这是一个高级调试视图直接展示五个 Workspace 文件的原始 Markdown 内容。当可视化解析出现问题时来这里核对原始数据是最直接的方法。5.2 常见问题与排查手册在实际部署和运行中你可能会遇到以下典型问题。这里提供一套系统的排查思路。问题一Dashboard 显示● Down(红色)无法连接 OpenClaw。这是最常见的问题表示前端 Dashboard 无法访问后端的 OpenClaw API (端口 18789)。排查步骤检查容器状态docker compose ps确认openclaw容器的状态是Up。如果是Exit说明容器启动失败。查看 OpenClaw 容器日志docker compose logs openclaw如果看到Error: Missing environment variable: MINIMAX_API_KEY说明.env文件配置有误或未生效。确保.env文件在项目根目录且已正确设置MINIMAX_API_KEY。修改后需要重启容器docker compose restart openclaw。如果看到连接 MiniMax API 超时或认证失败检查你的网络是否能访问 MiniMax 服务以及 API Key 是否有效、是否有余额。如果看到配置文件解析错误检查openclaw.json的格式是否正确例如缺少逗号、括号不匹配。检查端口映射docker port openclaw应显示18789/tcp - 0.0.0.0:18789。如果没映射出来检查docker-compose.yml中 openclaw 服务的 ports 配置。检查 Dashboard 连接配置 Dashboard 通过ui/dashboard/.env.local或环境变量OPENCLAW_API_URL来定位 OpenClaw 服务。在 Docker Compose 环境下它通常配置为http://openclaw:18789使用 Docker 内部网络。如果手动修改过请确保其正确。问题二提交任务时Dashboard 报错 “Workspace 目录为只读”。原因Dashboard 容器没有权限向宿主机的./workspace目录写入文件。这通常是因为docker-compose.yml中 Dashboard 服务的 volume 挂载被错误地设置为只读模式 (:ro)。解决方案打开docker-compose.yml找到 dashboard 服务的 volumes 配置部分。确保配置是volumes: - ./workspace:/app/workspace # 正确可读写而不是volumes: - ./workspace:/app/workspace:ro # 错误只读修改配置后重建 dashboard 容器docker compose up -d --build dashboard问题三Agent 执行了任务但 Dashboard 上没有更新状态。排查步骤检查原始文件首先去 Dashboard 的 “ 原始文件” 标签页或直接在终端查看workspace/status.md。cat workspace/status.md如果文件是空的说明 Agent 没有成功写入。需要检查 OpenClaw 日志 (docker compose logs openclaw) 看 Agent 执行过程中是否有报错。如果文件有内容进入下一步。检查写入格式仔细核对status.md的内容是否严格符合规范。一个常见的错误是冒号用了全角而不是半角:或者是字段名与预设的不匹配。格式错误会导致解析失败卡片显示“格式错误”。正确的格式必须像这样[sales_lead] 状态已完成 - 产品描述: 不锈钢保温杯 - 建议单价: 4.20 USD/件手动刷新点击 Dashboard 顶部的[↻ 刷新]按钮强制前端重新拉取数据。有时自动轮询可能因为网络延迟暂时未更新。检查 Dashboard 解析逻辑如果格式正确但依然不显示可能是前端解析代码有 Bug。可以打开浏览器的开发者工具F12查看网络请求中/api/workspace的返回结果看parsed.agents数组里是否有你的 Agent 数据。问题四如何自定义或增加新的 Agent假设你想增加一个quality_inspector质检主管Agent。创建角色定义mkdir -p agents/quality_inspector vim agents/quality_inspector/identity.md在identity.md中详细定义其角色、职责、工作流程和输出格式。注册到 OpenClaw 配置 编辑openclaw.json在agents数组末尾添加新 Agent 的配置{ id: quality_inspector, name: Quality Inspector, model: minimax-m2.1, identity: agents/quality_inspector/identity.md, tools: [read_file, write_file] }注册到 Dashboard 显示列表 编辑ui/dashboard/lib/parseWorkspace.ts文件找到AGENT_DEFINITIONS常量数组添加新 Agent 的定义export const AGENT_DEFINITIONS: AgentDefinition[] [ // ... 已有的定义 { agentId: quality_inspector, displayName: 质检主管, emoji: , // 给它选个图标 }, ];更新 Coordinator 的逻辑 这是最关键的一步。你需要修改agents/coordinator/identity.md在它的工作流程和决策逻辑中加入在何种情况下应该调用quality_inspector。例如在计划中增加一步“确认产品质量标准与验货要求 → 调用 quality_inspector”。重启服务docker compose restart openclaw dashboard问题五Token 消耗过快如何优化成本多 Agent 系统的一个潜在问题是多次 LLM 调用导致成本较高。优化身份文件让identity.md的指令更精确、更简洁减少不必要的上下文从而降低每次调用的 Prompt Token 数量。调整模型策略对于不那么复杂的决策环节可以尝试使用更小、更便宜的模型。在openclaw.json中修改对应 Agent 的model字段进行测试。优化协作流程审视plan.md是否有些步骤可以合并或简化能否让一个 Agent 在一次调用中完成更多关联工作减少调用次数缓存与记忆利用充分发挥MEMORY.md的作用。让 Agent 更多地依赖历史知识而不是每次都从零开始推理可以有效减少 Token 消耗。6. 开发、测试与扩展进阶如果你不满足于仅仅使用还想基于 OpenExt 进行二次开发或学习其实现这部分内容将为你指路。6.1 Dashboard 前端开发与测试Dashboard 是一个标准的 Next.js 14 (App Router) 项目位于ui/dashboard/目录。本地开发环境启动cd ui/dashboard npm install # 安装依赖 npm run dev # 启动开发服务器默认 http://localhost:3000在开发模式下Dashboard 会直接从../../workspace即项目根目录下的 workspace读取文件因此你无需启动 Docker 中的 OpenClaw 服务就可以进行前端 UI 的开发和调试。你可以手动修改 workspace 下的 Markdown 文件来测试各种解析和渲染状态。运行单元测试 项目包含了完善的单元测试覆盖了核心的 Markdown 解析逻辑。cd ui/dashboard npx vitest run # 运行所有测试 npx vitest # 进入监听模式文件保存时自动运行测试测试文件 (*.test.ts) 主要位于__tests__/目录下。这些测试非常重要它们确保了parseWorkspace.ts中的解析函数能正确处理各种边界情况例如状态关键词的变体、不规范的 Markdown 格式等。在修改解析逻辑后务必运行测试。构建与部署 如果你修改了 Dashboard 的代码需要重新构建 Docker 镜像。# 在项目根目录执行 docker compose up -d --build dashboard对于生产部署你可以单独构建 Dashboard 镜像并配置 Nginx 等反向代理。6.2 理解后端 API 与集成Dashboard 通过三个简单的 Next.js API Route 与后端交互这些接口设计得非常清晰你也可以直接调用它们进行集成或自动化。GET /api/workspace 这是最重要的接口。它做了两件事1) 读取所有 Workspace 文件2) 调用parseWorkspace.ts中的函数进行实时解析将原始 Markdown 转化为前端可直接使用的结构化 JSON 数据。你可以用curl命令测试curl http://localhost:3000/api/workspace | jq . # 使用 jq 美化输出GET /api/system 这个接口用于获取系统健康状态。它通过访问http://openclaw:18789Docker 内部网络的 OpenClaw API 来获取活跃会话和 Token 使用情况。如果你的 OpenClaw 服务部署在其他地方需要修改此接口的实现。POST /api/task 这是任务提交入口。它接收一个简单的 JSON 体{ task: 任务描述 }然后执行以下操作清空status.md和plan.md确保新任务在一个干净的状态下开始。将任务描述写入goal.md。这个写入动作本身就会触发一直在监听文件变化的 Coordinator Agent 开始工作。集成思路与 CRM/ERP 系统集成你可以写一个简单的脚本监控你的企业邮箱或 CRM 系统当收到新询盘邮件时自动提取关键信息调用POST /api/task接口创建任务。命令行工具封装一个 CLI 工具方便从终端提交任务。扩展通知渠道除了 Telegram Bot你还可以在POST /api/task成功后调用企业微信、钉钉或 Slack 的 Webhook将任务链接发送到群组。6.3 扩展方向与高级玩法OpenExt 提供了一个强大的多 Agent 协作底座你可以在其上构建更复杂的应用。领域垂直化目前的外贸流程是一个通用示例。你可以将其改造成其他垂直领域的自动化流程。客服工单系统Agent 1分类- Agent 2技术解答- Agent 3索要日志- Agent 4生成解决方案。内容创作流水线Agent 1选题- Agent 2大纲- Agent 3撰写- Agent 4校对排版。内部审批流Agent 1申请提交- Agent 2合规检查- Agent 3预算审核- Agent 4领导批复。增强 Agent 能力为 Agent 赋予更多工具Tools。联网搜索集成 SerperAPI 或 Tavily让 Sales Lead 能实时查询最新市场价格和汇率。调用外部 API让 Supply Lead 能连接到你内部的供应商数据库或阿里巴巴 API 获取实时报价。文档处理让 Ops Lead 能生成 PDF 格式的装箱单或提单草稿。引入人工审核节点当前的流程是全自动的。在关键环节如最终报价发出前引入“人工审批”是必要的。可以设计一个特殊的 Agent它的“完成”状态不是由 AI 决定而是等待用户在 Dashboard 上点击一个“批准”按钮。这实现了人机协同的混合流程。优化协作模式目前的协作是严格的“中心化调度”Coordinator 控制一切。你可以探索更去中心化的模式例如基于“发布-订阅”或“黑板模式”让 Agent 在满足特定条件时自主触发工作实现更动态的协作。这个项目的魅力在于它用一个清晰、可运行的实例展示了多智能体协作的核心理念和一种极其务实的实现方式。它没有追求过于复杂和炫技的架构而是用“共享文件”这个最简单的概念串联起了一个能实际工作的自动化流程。无论是用于实际业务还是作为学习多 Agent 系统的样板OpenExt 都具有很高的价值。