AI 工作流认知 从编排到架构

一个具体的例子：OpenClaw（一个国产 AI 编码工具）在某些场景下比 Claude Code 表现更好。它的模型并不更强——相反，底层模型能力其实更弱。但它做对了一件事：打通了用户的所有上下文——飞书文档、项目代码、聊天记录、个人笔记，全部对 AI 开放。

这就像"把龙虾从鱼缸放回了大海"——能力没变，但因为环境足够开阔，它能做的事情一下子多了很多。

上下文分两种：内部上下文是你自己的东西——个人笔记、团队会议纪要、项目背景、价值观和偏好；外部上下文是互联网上的公开知识，经过筛选浓缩后的行业最佳实践、调研报告等。两种都要喂给 AI，缺一不可。

当前最大的痛点是上下文碎片化：笔记在一个 App 里，文档在飞书，聊天在微信，代码在 GitHub。AI 没有办法在需要的时候即时触达所有信息。解决这个问题，比优化任何 prompt 都重要。

这是一个反直觉的发现。很多人在研究怎么让多个 AI Agent 分工协作——谁负责写代码、谁负责测试、谁负责审查。但实测下来，不同编排模式的效果差距不大。当前最有效的实践就是一个主 Agent 加若干子代理，甚至不需要给子代理做固定分工。

为什么？因为 Agent 不像人。 人有自己的性格、知识背景、思维习惯——这些是天然的差异化。但 Agent 的所有"个性"都来自你给它的上下文。你给它一份前端文档，它就是前端专家；你给它一份测试规范，它就是测试工程师。本质上，Agent 只是上下文的一个动态排列组合。

两个 Agent 之间唯一真正不同的，是它们各自积累的持久化记忆——过去犯过的错、学到的经验、踩过的坑。除此之外，分工只是上下文的分配，不需要复杂的组织架构。

结论：所谓的多 Agent 编排问题，退化为上下文和记忆的编排问题。 与其设计复杂的 Agent 组织结构，不如把精力花在整理上下文和积累记忆上。

既然上下文是核心，那怎么管理上下文？目前看到三种模式，代表了三个演进阶段：

元级控制为什么需要独立的角色？因为 AI 在自己的上下文里工作时，无法对自己"内观"——"不识庐山真面目，只缘身在此山中"。你需要一个站在外面的观察者（Observer），看整个系统运行得怎么样；还需要一个架构师（Architect），根据观察结果决定该怎么调整环境。

这可能是最重要的一个认知转变。过去我们跟 AI 协作，本质上是"Manager 模式"——像经理带下属一样，一步步检查、纠错、指导。现在需要切换到"Architect 模式"——像系统架构师一样，设计环境和规则，然后放手让 AI 自己探索。

关键原则：可衡量的，让 AI 自我进化。不可衡量的，由人来设计标准。

什么是可衡量的？代码是否通过测试、部署是否成功、性能指标是否达标——这些有明确的好坏标准，AI 完全可以自己判断和优化。

什么是不可衡量的？"这篇文章的叙事有没有品味"、"这个教育方案是否真正关注了学生"、"这个产品决策是否符合价值观"——这些需要人来定义标准。这也是 AI 时代人最核心的价值所在。

把前面的洞察组合起来，就形成了一个四层自治系统的架构设想：

你今天精心设计的工作流编排，半年后大概率过时。不是因为设计得不好，而是因为模型能力在进化。

半年前需要 5 个 Skill、3 个子代理、一套复杂的闭环验证流程才能完成的任务，现在可能只需要一句话描述目标就行了。就像一个足够聪明的新员工，你什么都不用教，他自己看完知识库就能上手——你之前设计的那套"新员工培训流程"自然就失效了。

这意味着两件事：

1. 编排是战术，架构是战略。 不要把最多的精力花在打磨编排细节上。编排的边际收益会随模型进化趋近于零。

2. 优先构建不会过时的东西——上下文完备度（你的知识库、经验库、价值观描述）和记忆持久化机制（怎么积累经验、怎么索引知识）。这些是真正的资产，不会因为模型换代而失效。

AI 要变聪明，光靠模型升级不够——它需要一套记忆积累机制，就像人通过经验变聪明一样。三步缺一不可：

第一步：建立规则。 告诉 AI 怎么工作。犯了错必须反思，把错误原因记录下来。遇到不确定的假设时先暂停，问自己"还有没有其他可能性"——先广度搜索，再深度搜索，不要一条路走到黑。

第二步：建立索引。 给 AI 一张"地图"——你有哪些知识库、调研文档、过往经验，它们在哪里、关于什么主题。索引本身不需要很长（1000-1500 字足够），但背后链接的知识库可以非常庞大。关键是让 AI 知道"去哪里找"。

第三步：沉淀踩坑经验。 每次遇到新问题并解决后，把解决方案更新到索引里。下次遇到相同问题，AI 直接复用——不用从头推理，不会再犯同样的错。

这是一个滚雪球的过程：索引越来越完善 → AI 越来越聪明 → 犯的错越来越少 → 积累的经验越来越多。单纯堆 CLAUDE.md 写一大堆规则是"伪持久化"——没有索引和经验沉淀，规则只是静态文本，不是活的记忆。

一个有生命力的 AI 系统（不是机械执行的自动化脚本）需要三种力量同时在场：

递归是引擎——简单规则不断自我展开。每完成一轮任务，不是停下来等指令，而是自己问"基于现在知道的一切，最值得做的下一件事是什么？"然后继续。就像一个有自驱力的员工，做完手头的事会自动找下一件事做。

迭代是方向盘——在反馈中螺旋上升。做了一件事 → 看结果 → 发现问题 → 修正 → 再做。闭环验证就是迭代机制的具体实现。没有迭代，递归会跑偏；没有反馈，系统会在错误方向上越走越远。

涌现是两者运行足够久后的意外产物——自下而上的创造。当你给 AI 足够的上下文和自由度，它会产出你没有预想到的东西。涌现不能被计划，但可以被允许——你要做的是创造条件，而不是规定结果。

三者的嵌套关系：递归提供持续性（不停下来），迭代提供方向性（不跑偏），涌现是两者运行足够久之后自然发生的事。

不要跟 AI 讲"你应该怎么做"，只告诉它你最终想要达到什么。

为什么？因为当你基于自己的经验去拆解任务路径时，这个拆解本身可能就是错的。人类习惯用传统的组织逻辑来分解问题——先做 A、再做 B、最后做 C。但 AI 的工作方式完全不同，它可能会找到一条你完全没想到的、更好的路径。你的中间步骤规划，反而限制了 AI 的发挥空间。

一个典型的例子："帮我写一个解析 JSON 的函数"是 V1.0 的说法；"我需要从这个 API 获取用户数据并展示在页面上，你来设计方案"是 V4.0 的说法。后者给了 AI 足够的自主空间，它可能会告诉你其实不需要手动解析，直接用某个库就行。

当然，这对模型能力有要求。给高层目标而不给中间步骤，需要 AI 有强逻辑推理、自我反思、不偏离目标的稳定性。顶级模型（如 Opus）收敛速度快得多，弱模型容易做着做着就偏了。所以 模型能力决定你能在多高的抽象层级上跟它对话。