OpenClaw 协作链路：先别让 AI 们开会，先把任务交付跑顺

这篇文章想介绍的项目，不是某一个页面，而是壹企云创现在正在摸索的一条 AI 协作链路。

它要解决的问题很直接：多个 AI agent 看起来像团队，但如果上下文、边界和验收标准不清楚，就会互相返工、失联、跑偏，最后没有人对交付结果负责。

所以我现在把协作方式往回收。

不是因为多 Agent 没价值，而是因为我已经看过它失控的样子。几个 agent 各自分工：有人规划，有人执行，有人审核，有人巡检。听起来像个小公司。再配上飞书、知识库、GitHub、部署平台，好像只要流程搭起来，它们就能自己滚起来。

现实是，滚是滚起来了，但经常滚偏。

有 agent 干完活不汇报，有 agent 反复返工，有 agent 因为模型超时直接失联。更离谱的时候，几个定时任务互相触发，一个把任务打回重做，一个又重新执行，来回循环十几次。

看日志的时候我人都麻了：这不是 AI 团队，这是半夜没人看管的自动化养蛊场。

所以现在的判断很明确：先把一条简单交付链路跑顺，再谈复杂协作。

现阶段的问题是什么

AI 协作的难点，不是“每个 AI 会不会干活”。

很多时候，单个 AI 的能力已经够强。真正麻烦的是它们合在一起以后，系统层面会出问题。

问题一：每个角色都在完成职责，但没人负责最终结果

Planner 会认真拆任务，executor 会认真执行，reviewer 会认真挑毛病。

单独看都没错。

但如果没有一个清楚的目标和停止条件，它们可能一直循环：计划、执行、审查、返工、再计划、再执行。

每个角色都觉得自己没错，最后项目没有前进。

问题二：AI 很容易自信脑补

给一句“帮我优化一下页面”，它当然也能动。

但它可能不知道：这是 Hexo 还是 Next.js？能不能改配置？要不要兼容移动端？什么叫“优化”？构建失败算不算完成？

上下文不清楚，AI 就会补。

而 AI 最可怕的地方不是不会做，是脑补得很自信。

问题三：复杂流程会放大基础设施问题

模型超时、凭据过期、文件传不过去、消息没同步、任务状态不一致，这些单独看都是小问题。

但如果你把它们放进一个自动流转的多 Agent 系统里，小问题会被放大成循环、误判和失控。

所以，现阶段壹企云创不适合先模拟一个完整 AI 公司组织架构。

小公司先别模拟大公司。一个人加几个 AI，也别急着模拟完整团队。

我们怎么解决

现在更靠谱的模式不是“OpenClaw 统一派单给所有 Agent”。

更准确地说，是这样：

飞书里把想法聊清楚
        ↓
OpenClaw 整理成完整任务书
        ↓
把任务书交给 Claude Code / Codex
        ↓
执行 Agent 改代码、测试、提交、部署
        ↓
OpenClaw 复盘并沉淀到知识库

这个链路不酷，但它能用。

OpenClaw 不是老板，也不是工头。它更像一个长期在场的参谋和整理者。

我会跟它聊公司方向、产品取舍、博客内容、工具怎么搭、这件事到底要不要做。聊到最后，它应该产出一份可以直接交给执行 Agent 的东西：背景清楚，目标明确，范围边界写好，验收标准也写好。

Claude Code 和 Codex 是另一层。

它们现在也接进飞书了。要改代码时，我不一定需要 OpenClaw 去转交。我完全可以把 OpenClaw 整理好的任务书复制过去，直接让 Claude Code 或 Codex 执行。

执行完以后，它们负责把代码推到 GitHub，或者完成部署动作。至于飞书知识库回写、复盘、把踩坑沉淀成后续可读的公司记忆，这个主要还是 OpenClaw 的活。

这条链路里各自负责什么

现在的分工可以很朴素：

角色	该做什么	不该做什么
我	判断方向、取舍优先级	被流程拖着走
OpenClaw	梳理上下文、写任务书、复盘沉淀	假装自己能调度一切
Claude Code / Codex	拿清楚任务改代码	猜业务目标
GitHub / EdgeOne	留下代码和部署结果	承担产品判断
飞书知识库	保存长期记忆	变成没人看的档案馆

这套分工的核心不是“谁更厉害”，而是“谁承担哪类不确定性”。

人承担方向不确定性。
OpenClaw 承担上下文整理。
执行 Agent 承担代码实现。
GitHub 和部署平台承担结果留痕。
知识库承担长期记忆。

分清楚以后，协作才不会变成互相猜。

用了哪些方法

这条链路里最重要的方法，不是多么高级的框架，而是任务书。

Claude Code 和 Codex 很强，但它们不是读心术。更好的方式是把任务写成一份完整工单。

至少要包含这些东西：

1. 背景：这个项目是什么，现在为什么要改。
2. 目标：改完应该达到什么效果。
3. 范围：哪些文件能动，哪些不要动。
4. 约束：不要引入新依赖，不要改配置，不要动敏感信息。
5. 验收标准：构建要过，页面要能访问，某个功能要能跑。
6. 失败处理：如果测试失败，先自己修；修不了再汇报具体错误。
7. 汇报格式：改了什么，怎么验证，还有什么风险。

说白了，别把 AI 当“聪明实习生”，要把它当“很能干但上下文有限的外包工程师”。

给它一句方向，它会自己脑补。

给它一张施工图，它能干得很快。

一个可直接复用的任务书模板

后面如果要让 Claude Code 或 Codex 做事，我会尽量按这个格式来：

## 背景
这是一个 Hexo + Fluid 的博客，当前站点用于记录 AI、产品和自动化实验。

## 目标
优化文章页标题样式，让标题不再显得过大，并保持移动端可读。

## 范围
只允许修改：
- source/css/nmdft.css
- 必要时修改 _config.fluid.yml

不要修改主题源码，不要引入新依赖。

## 验收标准
- npm run build 通过
- 文章页标题在桌面端和移动端都不过度夸张
- 暗色模式仍然可读

## 汇报
说明改了哪些选择器、为什么这么改、如何验证。

这份东西啰嗦，但有效。

AI 协作很多时候不是“让 AI 更聪明”，而是让任务更少歧义。

之前遇到的问题，最后怎么处理

之前我会想让 agent 之间“像团队一样协作”。

一个 agent 当 planner，一个 agent 当 executor，一个 agent 当 reviewer。听起来合理吧？人类公司也是这么分工的。

问题是，人类团队里有很多默认能力：知道什么时候该停，知道一个任务重复返工三次就不对劲了，知道“先别动，我问一下”也是一种进展。

AI agent 没有这些默认能力。你没写清楚，它就不会自动有。

所以现在的处理方式是：

• 先减少自动互相触发；
• 先让人决定方向和优先级；
• 先让 OpenClaw 把任务说清楚；
• 再让执行 Agent 去改代码；
• 最后用测试、构建、部署结果验收。

也就是说，先不追求“AI 们彼此开会”。

先追求“我说一件事，它能被稳定做完”。

当前成果是什么

这条链路现在带来的价值主要有三点。

第一，任务更清楚。

过去一句“优化博客”很容易跑偏。现在会变成：改哪个页面、解决什么问题、不能动什么、怎么验收。

第二，返工少一点。

执行 Agent 拿到的是施工图，不是模糊愿望。即使出错，也更容易定位是需求没写清，还是代码没做好。

第三，沉淀更完整。

OpenClaw 不只参与执行前的整理，也负责事后的复盘。哪些判断对了，哪些坑踩过，哪些方案下次可复用，都可以进入知识库。

这对壹企云创很重要。我们现在不只是要做一个项目，而是要逐步形成一套一人公司加 AI 的工作方式。

还需要解决什么

这条链路还不完美。

后面还需要继续处理：

• 不同 Agent 的凭据和权限隔离；
• 任务状态和完成结果的统一记录；
• 什么时候适合自动派发，什么时候必须人确认；
• 如何避免知识库变成没人看的归档；
• 如何让复盘真正影响下一次任务书。

但这些都应该在“稳定交付”之后再慢慢加。

如果基础链路没跑顺，越复杂的协作框架越危险。

暂时的结论

真正的 AI 工作流，不是把人从流程里拿掉，而是把人最该做的部分留下来。

人负责判断方向、提出问题、决定取舍。

OpenClaw 负责陪我把事情想清楚，整理成任务书，记住后来发生了什么。

Claude Code 和 Codex 负责执行、试错、修复、提交。

暂时先这样。

不华丽，但能交付。