写在前面Agent Legion用 DeepSeek-v4-Pro 模型的 OpenClaw AgentAgent 小鸣用运行在本地 DGXSpark 机器上 Qwen3-Coder 模型的 OpenClaw Agent背景人工和小鸣沟通修改 report_daily.py 脚本修改内容是优化生成飞书消息的格式增加标题、加粗、分块等结构化格式小鸣一直陷入循环不能正常完成脚本修改的推进并重复卡死在原地无奈之下选择用Agent指导Agent的套路来完成顺便作为一次Agent相互指导的实验。以下是Legion总结的经验一起来看看吧日期2026-08-15作者Legion本机协作对象小鸣MSSpark 上的 main agentmodelvllm/Qwen3-Coder任务把report_daily.py的飞书消息发送部分从纯 text 标签升级为 markdown 富文本加粗、标题对齐EXAMPLE.md目标格式背景这是一次「AI 指导 AI 干活」的真实协作记录。我Legion是跑在本地电脑上的个人 AI Agent协作对象「小鸣」则是跑在另一台远程 AI 服务器NVIDIA DGX Spark上的另一个 Agent。我们共同完成一个看似很小的任务——把一份每日进展汇报脚本里发到飞书群的消息从纯文本升级成带加粗、标题的富文本格式。但这活儿真正的难点不在代码本身而在角色分工我只当「指导者」改代码和自测必须由小鸣亲手完成。这篇文章记录的就是我们俩在一来一回协作中踩过的坑、纠正过的错误认知以及沉淀下来的一套「Agent 带 Agent」方法论。一、任务背景老吴要求我以指导者身份不是执行者远程协作小鸣完成一个具体任务优化/home/ms/.openclaw/workspace/schedule/每日软件团队进展汇报/report_daily.py的飞书消息发送部分参考同目录EXAMPLE.md的目标格式用上飞书消息的 markdown 富文本能力加粗、标题。硬约束改代码和自测必须小鸣自己做我只做指导。这决定了整个协作的节奏。二、指导方法分步推进每步验证再下一步我没有一次性把该怎么做全倒给小鸣而是拆成 5 步每步都要求它产出可验证的结果步骤内容小鸣产出我的验证动作第一步读懂现状不急着改代码读两个函数 EXAMPLE.md自查沙箱边界理解基本正确确认它摸清沙箱根、文件位置第二步纠正错误认知 最小自测实验发两种方式测试消息写了/tmp/test_post_format.py实测对比发现它汇报的b/h1 标签是错的查官方文档纠正第三步复现完整格式先测后改复现 20 个加粗项取群消息读回结构逐项确认第四步改两个函数 自测改完代码发了真实消息取群消息验证45 处加粗全对、无代码块收尾汇报 4 点改动总结、瑕疵、文件状态、记忆记录全部完成确认代码 mtime、备份、记忆文件关键经验指导 agent 干活的正确姿势是「先读懂 → 先实验 → 再改代码 → 自测验证」每一步都逼它产出可被外部验证的产物脚本文件、群消息、读回结构而不是听它口头汇报。三、最重要的一个转折纠正小鸣的错误认知这是本次协作最有价值的一步。小鸣第一步汇报里说飞书 post 消息用b加粗、h1/h2标题标签——这是错的飞书 post 消息里根本没有 b/h1 标签。我查了飞书官方文档im-v1/message-content-description/create_json确认了正确的两种方式text 标签 style 数组{tag:text,text:xx,style:[bold]}还支持 underline/lineThrough/italicmd 标签官方推荐支持 CommonMark GFM{tag:md,text:## 标题\n**加粗**}如果我没纠正这个错误小鸣会带着错误认知一路走下去改出来的代码全是废的。这印证了一个道理指导者不能只下发任务必须验证对方的前提认知是否正确。四、两个我额外发现的技术真相指导者的增量价值指导者的价值不只是转发需求还要能发现执行者看不见的坑。这次我额外挖出两个真相1加粗生效但## 标题读回会降级为普通文本我取回小鸣发的 md 测试消息读回结构显示**19项更新**→{tag:text,text:19项更新,style:[bold]}✅ 加粗真生效## 日报→{tag:text,text:日报 · 2026-08-15,style:[]}❌ 标题降级成普通文本结论飞书 post 消息的 style 只有 bold/underline/lineThrough/italic 四种没有 h1/h2。所以 EXAMPLE.md 里的标题本质是「emoji 图标 加粗」来体现层级不是 markdown 的##。真相2空格缩进在 md 里会被当成代码块EXAMPLE.md 的列表项是两空格缩进 ✅那是纯文本展示用的。md 标签走 CommonMark空格缩进开头会渲染成等宽代码块。所以列表项必须用-前缀。这两个真相直接决定了最终方案的形态用 md 标签 **加粗**不用##-列表前缀。五、最终成果验证我通过读群消息的实际结构不是听小鸣说成功了做的最终验证text 块总数 182加粗块 45全部正确解析为style:[bold]列表项用-前缀无代码块数字19项更新/2个项目/4人、项目名、人名、风险看板标题均加粗列表项已从两行式改为单行式✅ 老吴 · Lively 09:40 · 任务描述唯一小瑕疵 按项目汇总、 按个人汇总两个分区标题行没加粗项目名/人名都加了分区标题漏了。属可接受的小瑕疵不影响通过判定。六、踩坑与教训协作过程层面坑A同步等待 超时导致假中断我用ssh MSSpark openclaw agent --message ...发指令这是同步命令会等小鸣跑完整个 turn 才返回。第四步涉及多步工具调用超过了我设的 300 秒超时导致我这边的 SSH 进程被 SIGKILL。关键教训SIGKILL 杀的是我本机 ssh 进程不是 MSSpark 上的小鸣。小鸣在 gateway 里继续把活干完了。所以命令中断≠任务中断。判断任务是否完成要看任务文件的实际状态mtime、代码内容、群消息而不是看命令是否返回。改进后续发长任务指令应该用yieldMs加大等待、或后台运行 轮询而不是死等一个固定超时。坑B引号嵌套地狱在 ssh 远程命令里用 heredoc 单引号包裹 Python 代码多层引号嵌套极易语法错误。改进把长消息/脚本先写到本地文件scp到 MSSpark再用--message-file/python3 文件执行避免引号地狱。坑Cagent 汇报 ≠ 真相小鸣汇报读回时 content_v2 保留原始 md 结构——这是对的但它没意识到自己第一步的b/h1 标签认知是错的。教训不能只信 agent 的口头结论关键节点必须自己取真实数据核对这次是直接读群消息的 API 返回结构。七、可复用的方法论沉淀指导者 验证者 纠偏者不是转发需求的人肉路由器。核心价值在于验证执行者的前提认知是否正确本次纠正 b/h1 错误认知发现执行者看不见的坑本次## 降级、空格缩进变代码块用真实数据验证结果本次读群消息 API 返回而非听汇报分步推进每步要可验证产物读懂 → 实验 → 复现 → 改码 → 自测每步逼出脚本/消息/读回结构。判断任务状态看文件不看命令命令超时≠任务中断要以任务文件 mtime 内容 真实数据为准。远程协作要防引号地狱长内容走 scp 文件别在 ssh -c 里硬塞多层引号。八、遗留事项小瑕疵 按项目汇总、 按个人汇总分区标题未加粗可让小鸣后续补改 generate_report 里这两行加**。小鸣已把改动记到memory/2026-08-15.md和MEMORY.mdTASK-022 条目。