这两年大家聊 AI，大多还停留在“问它一个问题，它回你一段话”。这当然有用，但说实话，距离真正的生产力工具还差一截。

真正让人上头的，不是 AI 会不会解释概念，而是它能不能接入你的环境、理解上下文、调用工具、持续执行任务，并且在你不盯着它的时候，把事情推进下去。

我最近比较稳定的一套方式，就是把 OpenClaw 和 ACP 结合起来用。前者负责把 AI 接到真实世界，后者负责把复杂任务交给更专业的 agent 去跑。它们组合起来，形成了一种非常顺手的工作流：

主助手负责沟通、理解意图和调度；ACP 负责深入执行。

这篇文章就聊聊，这套工作流到底解决了什么问题、怎么协作、适合什么场景，以及为什么我觉得它比“直接让 AI 改代码”更靠谱。

一、问题不在模型不够聪明，而在“不会干活”

普通聊天式 AI 最大的问题，不是回答得不够聪明，而是它通常缺少三样东西：

• 上下文持续性：聊完就散，下一轮像失忆
• 工具能力：知道该怎么做，但碰不到你的文件、项目、文档、消息渠道
• 任务执行能力：能提建议，但不能持续把事情做完

所以很多时候，你会遇到一种很熟悉的情况：

1. 你跟 AI 说想做个功能
2. 它给你一套看起来很合理的方案
3. 真正落地时，还得你自己去翻仓库、改代码、跑命令、看报错、来回修

这就导致一个尴尬局面： AI 像一个很会说的顾问，但不像一个真的能下场干活的搭档。

而 OpenClaw + ACP 的组合，核心就是在补这块。

二、OpenClaw 是“入口层”，ACP 是“执行层”

如果让我用一句话概括这套工作流：

OpenClaw 负责把 AI 放进你的工作环境，ACP 负责让 AI 以 agent 的方式持续执行复杂任务。

OpenClaw 擅长什么？

OpenClaw 更像是一个操作系统层的 AI 接入框架。它能让你的助手：

• 读取和写入工作区文件
• 调用本地命令和工具
• 接入聊天平台
• 操作文档、知识库、飞书等外部系统
• 通过技能（skills）加载特定工作流
• 保持一定的会话和上下文连续性

你可以把它理解成： “让 AI 不再只活在聊天框里，而是活进你的环境里。”

ACP 擅长什么？

ACP 更适合承担那些复杂、耗时、需要多步推进的任务，比如：

• 大块代码生成或重构
• 多文件联动修改
• 持续迭代的工程任务
• 需要独立 session 的深度执行
• 代理式任务拆解与执行

也就是说，ACP 更像是一个专业执行工位。 它不一定负责第一轮和你沟通需求，但很适合接手明确任务，然后在自己的执行上下文里一直做下去。

三、为什么这套分层很重要？

关键在于：不是所有任务都适合由主对话直接执行。

举个很典型的例子。

如果你在聊天窗口里说：

“帮我把这个项目里的登录流程改成 token refresh 机制，并补上错误处理和测试。”

如果让主助手直接硬改，通常会遇到几个问题：

• 聊天上下文里塞太多代码，容易乱
• 修改范围一大，主线程会变得很重
• 用户同时还想继续聊别的，容易互相干扰
• 出错时难以追踪到底在哪一步偏了

而 ACP 方式更像这样：

1. 你在 OpenClaw 里提出需求
2. 主助手理解任务、补足上下文、定义边界
3. 把任务交给 ACP agent
4. ACP 在独立 session 里深入执行
5. 主助手回收结果、整理成你能看的结论

这就有点像现实中的团队协作：

• 主助手像 PM / Tech Lead / 调度员
• ACP agent像具体干活的工程师

这种分层最大的好处，是把“对话”和“执行”解耦了。

四、一个顺手的实际工作流长什么样？

我现在更偏好的流程，大概是这样的。

1. 在主会话里描述目标，而不是上来就盯代码

比如：

• “给这个项目加一个博客发布工作流”
• “把这段脚本重构成可维护的模块”
• “做一个飞书文档同步能力”
• “帮我梳理一下 OpenClaw 的 node 连接问题”

这一层最重要的不是细节，而是意图、范围、约束。

主助手适合做这些事：

• 澄清需求
• 判断要不要调用 skill
• 判断是不是该启用 ACP
• 整理任务说明，减少执行歧义

2. 复杂任务交给 ACP，避免主线程变成施工现场

当任务明显属于以下情况时，我倾向于直接交给 ACP：

• 涉及多个文件
• 需要跑命令、看输出、反复修
• 一轮搞不定，需要连续迭代
• 任务执行时间长
• 希望保持一个单独的 agent 工作上下文

这时候的重点不是“让 AI 立刻回答”，而是“让 AI 进入工作状态”。

3. 主助手负责把执行结果翻译成人话

很多 agent 真正执行完后，原始输出未必适合直接给人看。 这时候主助手的价值就出来了：

• 总结改了什么
• 哪些地方有风险
• 哪些还需要人工确认
• 下一步建议怎么做

这一步其实很关键。 因为多数人不缺一个会输出日志的 agent，缺的是一个能把执行过程整理成决策信息的助手。

五、这套工作流最适合哪些场景？

场景一：代码类任务

这是最直接的。

比如：

• 新功能开发
• 大范围重构
• 修复杂 bug
• 按现有风格补测试
• 跨文件迁移逻辑

主助手先看懂需求，再把明确任务发给 ACP。 这样不会把主会话搞得满屏都是补丁和终端输出。

场景二：文档与知识库工作

很多人低估了 AI 做文档工作的价值。

比如：

• 根据项目结构写博客
• 把会话整理成文档
• 把 Feishu 文档和本地内容打通
• 从已有项目里提炼说明文档
• 统一格式、补 frontmatter、整理结构

这类任务表面看不复杂，但其实很吃上下文。 OpenClaw 的 skill + 工具能力在这里特别顺手。

场景三：长期工作流自动化

这类最像“真正的数字助理”：

• 周期性检查状态
• 从消息入口接收任务
• 自动整理记忆和上下文
• 做跨系统协调
• 有需要时再拉起 ACP 做重活

这不是一个单点能力，而是一种“调度体系”。

六、我为什么更偏向“默认用 ACP 做项目任务”

说得直接一点： 对工程类任务，直接在主对话里硬做，短平快还行，但一复杂就容易乱。

而 ACP 的价值在于，它让复杂任务有了这些特性：

• 独立执行上下文
• 持续性
• 更适合长任务
• 不污染主聊天线程
• 更容易回溯

所以如果是认真做项目，而不是随手改一行，我会更倾向于：

主会话负责定义任务，ACP 会话负责完成任务。

这种分工会让整个系统更稳定，也更接近真正的协作，而不是“把所有事都塞进一个聊天框”。

七、这不是“全自动”，而是“人机分工更合理”

这里也得泼点冷水。

OpenClaw + ACP 很好用，但它不是魔法。它真正强的地方，不是替你做所有决定，而是把人该做的事和AI 该做的事分得更清楚。

人更适合：

• 定目标
• 做优先级判断
• 决策取舍
• 设定边界和风险容忍度
• 做最终验收

AI 更适合：

• 读上下文
• 执行重复性步骤
• 跑工具链
• 做第一轮实现
• 归纳总结结果

这套工作流最舒服的状态，不是“我一句话，AI 全自动把一切做完”，而是：

我负责判断方向，AI 负责高质量推进。

这才是现实里真正可落地的协作方式。

八、一个我很喜欢的变化：AI 从“回答器”变成“工作节点”

以前我们用 AI，经常把它当成一个超级搜索框。 现在我更愿意把它看成一个工作节点。

什么意思？

就是它不只是“被问一下然后回答”，而是能：

• 接受任务
• 读取环境
• 使用工具
• 进入专门执行上下文
• 完成阶段性产出
• 再把结果回传给你

这个变化很重要。 因为一旦 AI 变成工作节点，它就不再只是信息消费工具，而变成了工作流的一部分。

OpenClaw 负责把这个节点接进来，ACP 负责把这个节点跑起来。

九、结语：真正有价值的，不是更会说，而是更会协作

如果只把 AI 用来问答，那它当然已经很强了。 但如果你希望它真的参与工作，光靠聊天是不够的。

你需要的是：

• 能接入真实环境的入口
• 能处理复杂任务的执行层
• 能在两者之间做任务编排的工作流

这也是为什么我觉得 OpenClaw + ACP 这套组合很值得用。 它不是单纯让 AI 回答更长、更像人，而是让 AI 更接近一个真正能协作的搭档。

说到底，生产力工具的价值，不在于它多会说， 而在于它能不能把事情往前推。

而这，才是我最看重的部分。