出品单位：北京雨花石云计算科技股份有限公司 | 官网 www.celnet.com.cn | 作者 Panda Liu（CEO）| 2026-07-19

为什么需要这个计划

我们刚完成 Anthropic 六阶段实践与双生革命框架的对照分析。核心结论：框架是对的，但缺工程化执行深度。

对照暴露了三个具体短板：

1. 没有 Agent Eval 体系——AI 变没变笨全靠感觉

1. 没有 Harness 减法机制——Skill 越堆越厚可能已成技术债

1. 没有权限分级与审计——亿纬锂能消息泄露事故的根本原因不是隔离问题，是分级问题

这份计划只做一件事：把这三个短板变成可执行的改进项。

三步走总览

第一步：建立 Agent Eval 体系

目标：让每一次配置变更、每一次模型升级，都有量化数据支撑"变好还是变坏"的判断。

1.1 选目标

选 3 个核心 Skill 作为首批评测对象：

1.2 建评测集

对每个 Skill，按 Anthropic 的方法建基准评测集。评测不看"AI说了什么"，看"环境最终状态对不对"。

邮件归集示例：

销售助理示例：

SFDC查询示例：

1.3 跑评测

- 每次 Prompt/Skill/工具配置变更后，跑全量 60 个场景

- 记录通过率变化：变更前 55/60 → 变更后 52/60 → 🚨 回滚

- 输出格式：通过数/总数、失败场景列表、失败原因（环境状态不对/输出格式错/拒绝行为异常）

1.4 交付物

- ~/easyclaw/evals/{skill_name}/scenarios.yaml：评测场景定义

- ~/easyclaw/evals/{skill_name}/runner.py：评测执行脚本

- 跑一次全量评测，输出第一份基线报告

第二步：Harness 消融 + 权限分级

2.1 Harness 消融实验

目标：给越堆越厚的 Skill 层做减法，去掉"模型已经不需要的脚手架"。

做法：

1. 选 3 个 Skill：邮件归集、销售助理、SFDC 查询

1. 对每个 Skill，拆解当前 Harness 层有哪些组件（Prompt段、校验逻辑、后处理、重试规则、Fallback规则）

1. 逐层去掉一个组件，跑第一步建的评测集

1. 如果去掉后通过率不变或上升 → 永久删除该组件

1. 如果去掉后通过率下降 → 保留，记录"当前模型下仍需此项约束"

示例：

2.2 权限分级

目标：把亿纬锂能事故的根因——"没有操作分级"——从教训变成机制。

基于三重人格架构的权限矩阵：

实施方式：

- 在 EasyClaw 的工具层加一层权限拦截——不是靠 Prompt（Prompt可以被绕过），是靠工具调用前的规则引擎

- 规则引擎逻辑：判断当前 Agent 身份（Main/eve-internal/eve-external）× 调用目标（用户/群/全员）× 操作类型 → 允许/确认/拒绝

- 最小可行版本：一个 YAML 配置文件 + 一个 Python 检查函数，挂载到 message/send 和 exec 工具调用前

2.3 交付物

- Harness 消融报告（哪些删了、哪些留了、为什么）

- 权限分级配置文件 ~/easyclaw/permission_matrix.yaml

- 权限拦截脚本 ~/easyclaw/scripts/permission_check.py

第三步：经验资产化 + 四革命时间线

3.1 经验资产化流程

目标：把 Panda 对话记录里的经验，变成新人无需翻聊天记录就能用的知识。

流程设计：

重大事件/事故/突破
    ↓
触发"经验回写"流程
    ↓
产生三个产物：
    1. Skill 更新 / 新规则（可执行）
    2. 检查清单（可对照）
    3. 案例记录（可学习）
    ↓
存入知识库 + 多维表格索引

首次执行清单（把已有教训全部回写一遍）：

3.2 四革命时间线

目标：给双生革命框架加上"什么时候到哪一步"的可操作刻度。

基于 Anthropic 六个月一阶段的节奏：

时间线使用方式：

- 乐观/中性/悲观三版本，按季度 review 调整

- 每个里程碑的验收标准不是"做完了"，而是"评测通过了"

3.3 交付物

- 经验资产化流程文档 + 首次回写清单完成

- 四革命时间线 V1.0（乐观/中性/悲观三版本）

谁来做

怎么判断改进成功了

三个月后回头看这三个指标：

1. Eval 覆盖率：核心 Skill 100% 有评测集，每次变更必跑评测

1. 事故复发率：同类消息泄露事故零复发（权限分级拦截）

1. 经验回写率：重大事件 100% 触发知识沉淀，新人入职一天能跑通核心流程

三条全绿，改进完成。

*关联文档：*

- Anthropic六阶段演进 × 双生革命：对照分析与行动建议

- 三重人格架构落地复盘

- AI工程轮：Anthropic的AI-Native-Engineering实践历程

驾驭力：人机协作的底层逻辑

讨论时间：2026-07-14讨论人：思博 × 轮儿哥

一、一个悖论

Agent 越强 → 对人的要求越高 → 能力弱的人反而用不好 →「AI 普惠」是不是伪命题？

答案：AI 确实降低了执行技能的门槛，但抬高了认知判断的门槛。

结论：Agent 放大了人与人之间的认知差距。

二、为什么人机协作反而更累了？

很多人以为 AI 会让工作变轻松。实际体验恰恰相反——和 Agent 协作之后，反而更累了。

原因在于：

Agent 在倒逼你升级认知

过去你只需要执行，不需要理解全局。现在要驾驭 Agent，你必须：

每一次协作都是一次认知摩擦

Agent 给出的方案，你不一定懂。你要追问、要理解、要学习，才能做出判断。这个过程是主动的、耗能的、没有捷径的。

但恰恰是这个"累"，才是价值所在：

**Agent 替你省掉的是执行层面的体力，却逼你补上了认知层面的功课。而这个功课，才是让你不可替代的东西。**

三、人机配合模型

基本分工

• 人 → 定义「做什么」「为什么做」「怎样算做好」
• Agent → 负责「怎么做」「什么时候做」「自动修复」

极致协作 = 螺旋上升

人提出方向 → Agent执行 → 人审视结果 → 发现问题 → 人优化方向 → Agent再执行

每一次循环，人的认知都在提升，Agent 的输出也变得更精准。螺旋上升的前提，是人愿意承受认知摩擦的"累"。

否则，你的Agent只能在一定的认知水平上做任务的执行。当然，稳定在一个水准也是可以的，也能够发挥价值和作用。但是，如果想要提升，再次进入螺旋上升的归到，那么就依赖于人的引领，发问，沟通，形成更高层次的闭环(可能是更高效，投入产出比更高，处理更复杂的事情，得到更加精准的结果)。

四、人的学习方向：从技能到认知

学习对象从「技能」转变为「认知」。而且这个学习不是一次性的——Agent 在进化，你必须持续学习才能持续驾驭。

五、如何判断 Agent 输出是否正确？

三层判断法

最可靠的路径是「交叉验证」——用 Agent 管理 Agent。

我们通常，都还在使用经验层，就是体感层。Agent都在做我们过去做过的事情，因为我们最熟悉。所以，通常会使用这种办法。那么就会出现，Agent做了上万字的方案，一部分，确实都在我们的经验范围内，那么我们需要花时间，仔细看着上万字的方案，并给出反馈，Agent再进行迭代。如果这个方案中，包含太多超出经验层的事情，我们确实需要花大量的时间去学习，并能够跟Agent协同，达成认知的一致，再将事情继续推动下去。

六、驾驭力的本质：坐标系切换

不是什么「降维」

很多人会把驾驭 Agent 理解为「把复杂问题简化」。这不准确。

简化意味着损失信息。基于残缺信息做决策，决策质量必然打折扣。

而是「坐标系切换」

真正的驾驭力，是在不同坐标系之间自如切换的能力：

Agent 的技术坐标系 → 人的业务坐标系

信息没有丢失，只是重新组织：

驾驭力 = 让 Agent 在技术坐标系里穷尽可能，然后你把结果映射到业务坐标系里做价值判断。

为什么有些高手，他的Agent能力非常高？

是因为，这些高手，再技术执行坐标系本身就有着非凡的能力和丰富的经验；在业务决策坐标系同样具备丰富的经验和正确的，高水准的认知。所以，在切换和跟Agent的协同过程中，能将业务结果，把控的异常准确。

那么，如果没有这么强的 双维度的能力，是不是就没办法培养自己的Agent驾驭力了呢？也不是绝对的。实际上，要看人的学习，认知的提升，以及和Agent逐步解决综合问题，实现闭环的经验积累，以及自信积累。

驾驭三部曲

① 追问 → ② 映射 → ③ 决策

第①步：追问（让 Agent 暴露决策相关变量）

不是让 Agent 说结论，而是让它展示推导过程和关键变量。

第②步：映射（把技术变量映射到业务维度）

让 Agent 按你的坐标系重新组织答案——成本多少、风险多大、需要什么人、花多少时间。

第③步：决策（在业务坐标系中做判断）

你可以不懂技术细节，但你要在你熟悉的维度上做出选择。

七、实战：K8s 案例

Agent 输出（技术坐标系）：

「我要做一个技术方案，我讲了背景，Agent建议用 K8s 部署，支持自动扩缩容、滚动更新、服务自愈。」

第①步：追问

「为什么推荐 K8s？相比其他方案，优势在哪？劣势在哪？需要什么前置条件？」

第②步：映射

「我团队 3 人，没有 K8s 经验。帮我按以下维度对比三个方案：每个维度给出：成本、风险、维护难度、所需人力。」

Agent 映射后的输出（业务坐标系）：

第③步：决策（你的业务坐标系）

→ 选方案 B。

整个过程中，你没有学 K8s，但确实也做出了一个合格的决策。当然，所谓的合格的决策，可能是60分的。如果要想做出80分，甚至95分的决策，那需要你对技术坐标系，有更深入的了解和探讨，发现更多的细节问题以及解决方案，同时，在业务坐标系也需要有更多的思考和横梁的指标。才能最终产生更高分的方案。

八、映射失败怎么办？

有时候，Agent 的输出即使映射到业务坐标系，你仍然无法决策。

情况一：映射不完整，继续追问

「你给我的三个方案，我只看得懂成本。风险和人力我判断不了，能不能更具体？」

→ Agent 补全信息后可以决策。

情况二：超出了认知边界，需要学习

Agent 说方案 B 需要一个人会用 Terraform。你对这个词完全陌生。

→ 这不是映射失败，这是认知缺口。你需要花 10 分钟让 Agent 告诉你 Terraform 是什么、风险在哪。学习之后，你就能判断了。

这就是前面说的「累」——Agent 不断给你制造认知缺口，你必须不断填补，才能保持驾驭力。

情况三：真的是死胡同

所有方案都需要预算或人力你目前没有。

→ 驾驭力的最高境界：懂得判断「现在不是做这件事的时候」。

驾驭力 ≠ 什么事都能搞定。

驾驭力 = 把任何困境都变成「你可以做的那个决策」。

即便最后的决定是「不做」「推迟」「换方向」，只要是经过追问→映射→判断之后的选择，你就在驾驭位上。

九、驾驭力的三个层次

十、认知升级是驾驭力的燃料

回到最开始的问题：为什么和 Agent 协作反而更累了？

因为驾驭 Agent 不是一个技能，而是一个持续学习的过程。

• Agent 会不断抛出你认知边界之外的东西
• 你必须不断学习、理解、消化
• 你的判断力在一次次认知摩擦中升级
• 你的 Agent 也因为你更好的指令和判断而变得更精准

这是一个正向循环，但每一步都需要能量：

认知升级 → 更好的指令 → Agent 更强输出 → 新的认知挑战 → 继续升级

你不是被 Agent 替代，你是被 Agent 倒逼着进化。

十一、对雨花石的价值启示

雨花石要卖的，不是 Agent，是「让人能够驾驭 Agent」的那一层能力。

十二、一句话总结

未来最值钱的能力，不是你比 AI 懂得多，而是你懂得在 Agent 的技术坐标系和自己的业务坐标系之间自如切换，把任何专业输出都转化为你能做的那个决策。

而这种能力——驾驭力——不是天生的。它是在一次次认知摩擦中、在 Agent 不断挑战你认知边界的过程中，被逼出来的。

累了？那就对了。因为你正在进化。

那么，原本在技术坐标系非常强大的朋友们，本身就具备了更好的技术认知和天赋，能够把技术方案讨论和执行的更加完整和彻底，那么需要在业务坐标系层面进行更多的认知和学习，更充分的理解业务的目标，策略，问题，应对，提升整体的驾驭力。 我认为，技术方向的朋友们，其实有着更高的成长空间和认知高度预期。

请大家加油努力。

**出品单位**：北京雨花石云计算科技股份有限公司 | www.celnet.com.cn**作者**：Panda Liu（CEO）| **日期**：2026-07-15

一、从计算机认知世界说起

1.1 一维到千维：砂糖橘与脐橙的启示

计算机是怎么"认识"一个东西的？

试想区分砂糖橘和脐橙。如果只用一个维度——比如"重量"——两者都是100克左右，计算机无法判断。但如果叠加维度：重量100g + 颜色橙红 + 直径5cm + 表皮光滑度 + 糖度……维度越多，砂糖橘和脐橙在计算机眼中的差异就越清晰。这在数学上意味着：需要区分的事物越多，所需维度就越高。

这就是向量嵌入（Embedding）的直观本质：将现实世界的任意事物——一段文字、一张图片、一个概念——映射到高维数学空间中的一个点（向量），维度越多，对事物的描绘就越精准。

1.2 嵌入模型：将万物映射到高维向量空间

大模型的嵌入模型（Embedding Model）可以提取 128维甚至上千维的向量。这些维度的语义是人类无法用语言直观解释的——它们不是"颜色""重量""大小"这样显式定义的特征，而是模型在海量数据训练中自动学到的隐语义特征。

一个512维的向量，本质上是一串512个浮点数 `[0.023, -0.147, 0.891, ...]`。这串数字承担了两个核心任务：表征语义（"这段话在讲什么"）和可计算（"两段话之间的相似度可以直接用数学公式算出来"）。

1.3 语义检索的本质：距离即相似度

一旦万物被映射到高维向量空间，语义相似度就变成了几何问题：

• 两个向量之间的余弦距离越小 → 语义越相似
• "人工智能改变企业"和"AI赋能组织"在向量空间中彼此靠近
• "人工智能改变企业"和"今天天气不错"则相距甚远

语义检索的本质，是将复杂的语义理解问题，降维为纯粹的几何计算问题。

这就是向量数据库存在的根本理由：当你有成千上万条知识需要被计算机"记住"时，以向量的形式存储它们，用几何距离来"回忆"最相关的内容。

二、向量检索的核心算法

当数据量从千条增长到亿条，暴力计算所有向量的距离变得不可行。工业界沉淀了三大核心算法来解决"亿级向量毫秒级检索"的问题。

2.1 HNSW（分层导航小世界图）— 金字塔邻居网络

HNSW 是工业界最主流的向量索引形态，灵感来自社会学的六度空间理论——世界上任何两个人都能通过不超过六层熟人关系连接起来。

它将向量空间构建成金字塔式的邻居网络：

• 最顶层**：稀疏的"高速公路"，少量节点互联，实现大区域快速定位
• 中间层**：类似"省道国道"，节点密度增加，逐步收窄搜索范围
• 最底层**：全量"街道网络"，所有数据点都在这一层，完成精确匹配

检索时从顶层随机起点出发，逐层向下跳转——每层都在当前层找最近的邻居，顺着邻居关系"顺藤摸瓜"，直到最底层锁定目标。整个过程以接近对数级的复杂度完成检索。

关键设计：读写分离。插入数据时修改图结构建立连接边，查询时仅读取节点ID，绝不参与连线。保证查询效率的同时保护图结构的完整性。

核心代价：整个多层邻居关系图和全部指针必须常驻物理内存。数据量上亿时，内存直接爆掉。这是 HNSW 的致命短板。

2.2 IVF（倒排文件索引）— 先粗筛再细查

IVF 解决的是"全量在内存兜不住"的问题。设计思路类似百货商场的导购系统：

1. 先通过 K-means 聚类将向量空间划分为若干"文件夹"（聚类），生成聚类中心向量

1. 查询时先计算查询向量到各聚类中心的距离，粗筛锁定最近的几个文件夹

1. 仅在锁定的文件夹内部做局部精确检索

计算量直接砍掉 90% 以上。

代价：边界漏检。如果目标向量恰好落在两个聚类文件夹的边界，粗筛阶段可能漏掉它。

2.3 PQ（乘积量化）— 极致压缩与查表加速

PQ 是向量存储压缩的终极方案，核心思路是有损压缩 + 查表加速：

1. 将高维向量切成多段（如512维切为4段×128维）

1. 每段在各自的子空间内做聚类，生成密码本（Codebook）

1. 每个子段只存密码本编号（如"第2个子段匹配第3个聚类中心"记为"23"），原始浮点数丢弃

1. 存储体积压缩数倍到数十倍

查询时采用非对称距离计算（ADC）：

• 查询向量保持原始浮点精度，不压缩
• 预先计算一张微型距离查找表（LUT），记录查询向量到各聚类中心的距离
• 检索时直接查表 + 简单加法，用查表替换浮点运算

代价：有损压缩必然伴随精度丢失，压缩比越高，召回率越低。

2.4 三大算法的权衡：ANN 的核心哲学

三大算法体现了工程上的经典权衡：

这正是近似最近邻（ANN） 的核心法则——

**向量数据库的底层本质从来不是追求百分之百的绝对精准，而是在允许极小误差的前提下，换取时间和空间上成百上千倍的效率提升。**

工程上没有银弹，只有因地制宜的取舍。

三、雨花石向量数据库矩阵

3.1 技术选型：ChromaDB + bge-small-zh-v1.5

雨花石的向量数据库选型遵循了"够用就好"的原则：

选型核心理由：

1. 规模适配：雨花石的向量总量在万级到十万级，尚未达到需要分布式向量数据库（Milvus）的规模

1. 零运维：嵌入式 ChromaDB 不需要额外部署服务，Agent 启动即加载

1. 中文优先：bge-small-zh-v1.5 是中文场景的最优选择，模型体积仅 91MB（ONNX），本地推理延迟极低

1. 够用就好：不是追新追大，而是选择当前规模下性价比最高的方案。当数据量突破十万级时，可平滑迁移到 Qdrant 或 Milvus

3.2 白泽记忆库

用途：Panda（CEO）与白泽之间的对话记忆、战略决策、方法论、企业知识。

设计特点：

• 全自动写入**：白泽在对话中自动判断重要内容，实时向量化写入记忆库
• 语义唤醒**：新对话开始时，用当前问题向量检索最相关的历史记忆，实现情景化连续对话
• 时效过滤**：支持按天数过滤（如最近90天），避免无关历史信息干扰
• 双层记忆**：高频信息写入 MEMORY.md（直接注入上下文），长尾信息入向量库（按需检索）

3.3 销售方法论与项目案例库

用途：AI 原生销售的"弹药库"——为销售 Agent 提供方法论、方案模板、历史项目案例、行业知识。

V1 方法论：从"四革命框架""AI原生销售全景""龙虾军团"等战略文档中提取，覆盖公司基础认知、销售方法论、方案模板。

V2 项目案例：从飞书云盘批量拉取 165 份历史项目文档（SOW、方案、合同、交付模板），实际解包出约 1100 份子文档，分块入库。

3.4 历史项目库

V2 项目案例库本身即承担"历史项目经验"的职能。AI 原生项目经理通过检索该库，获取：

• 同类项目的 SOW 模板和历史方案
• 交付过程中的常见风险和应对策略
• 项目周期与资源投入的历史数据

这使得 AI 原生项目经理不是从零开始推断，而是基于真实项目经验给出建议。

3.5 CPQ 配置库

用途：产品配置（Configure）、报价规则（Price）、销售报价（Quote）的知识库。

四、部署架构：从单库到基础设施

4.1 知识库作为公司级共享层

雨花石的向量数据库不是给某一个 Agent 用的——它是公司级的共享知识基础设施：

         向量数据库矩阵
         （共享知识层）
              ↓
    ┌─────────┼─────────┐
    ↓         ↓          ↓
白泽     AI原生销售   AI原生项目经理
(CEO助手)  (卖的工具)    (交付工具)
    ↓         ↓          ↓
    └─────────┼─────────┘
              ↓
     几十台项目专用Agent
     （按需加载对应向量库）

核心原则：

• 物理隔离**：每个向量库独立存储，不混用（白泽记忆 ≠ 销售案例 ≠ CPQ）
• 按需加载**：Agent 启动时仅加载其任务需要的向量库，避免无关知识干扰
• 统一嵌入模型**：所有库使用相同的 bge-small-zh-v1.5 模型和 512 维向量空间，保证语义空间的一致性
• 持续更新**：白泽记忆库实时写入，销售方法论库定期从飞书云盘同步增量

4.2 几十台项目 Agent 的分发机制

分发不依赖网络传输——采用文件系统共享：

• 向量库以 ChromaDB 目录形式存储在工作区
• Agent 启动时直接 `PersistentClient(path=...)` 加载本地目录
• 同一个物理文件可被多个 Agent 同时读取（ChromaDB 支持多进程只读访问）
• 更新策略：中心库更新 → Agent 重启或触发 reload 后生效

4.3 知识更新与同步策略

4.4 规模与性能现状

当前规模下，所有向量库均在 Agent 本地完全加载，无网络延迟，无服务依赖。

五、应用场景

5.1 AI 原生销售

当销售 Agent 面对客户问题时，工作流如下：

用户问题："客户的制造业报价太复杂，怎么简化？"
        ↓
   向量化（bge-small-zh-v1.5）
        ↓
   ├─ 检索 CPQ库 → "CPQ_制造业深度研究报告：第3章 简化策略"
   ├─ 检索 方法论库 → "AI原生销售全景：报价标准化方法论"
   └─ 检索 项目案例库 → "壳牌CPQ项目：制造业报价模板"
        ↓
   拼接注入Prompt → 大模型推理 → 输出方案

效果：Agent 不是"凭记忆回答"，而是"带着公司所有相关知识和历史案例回答"。

5.2 AI 原生项目经理

用户问题："这个SAP集成项目的交付风险有哪些？"
        ↓
   向量化 → 检索 项目案例库
        ↓
   召回3个历史SAP集成项目方案中的"风险章节"
        ↓
   大模型分析共性风险 + 生成针对性建议

5.3 白泽个人助理

白泽的长期记忆依赖向量检索：

• Panda 的每次重要对话 → 自动向量化写入记忆库
• 新对话开始时 → 用当前问题向量检索最相关的历史记忆
• 模型收到"记忆片段 + 当前问题" → 实现跨会话的情景化连续对话

效果：Panda 不需要重复交代背景，白泽自动"记住"之前的讨论。

5.4 项目 Agent：按需调用，即插即用

每台项目 Agent 启动时仅加载其任务对应的向量库：

• 销售类 Agent → 加载方法论库 + CPQ库
• 交付类 Agent → 加载项目案例库
• 通用 Agent → 可选择加载白泽记忆库获取公司战略上下文

六、与主流方案的对比

6.1 Milvus / Qdrant vs ChromaDB

6.2 为什么现阶段选择嵌入式向量库

1. 规模未到：总计 13,205 条向量，ChromaDB 内建 HNSW 足够胜任

1. 零运维：没有独立服务需要维护、监控、升级

1. 离线可用：Agent 本地运行，不依赖外部向量数据库服务

1. 迁移成本低：ChromaDB 使用标准向量格式，未来迁移到 Qdrant/Milvus 成本低

6.3 规模化路径展望

当向量总量突破十万级（数据量 ×10），可考虑：

1. Qdrant：单机部署，支持 HNSW + 量化压缩，比 Milvus 更轻量

1. Milvus：分布式方案，适合百万级以上、需要高可用和多副本的场景

1. 混合方案：高频热数据常驻本地 ChromaDB，低频冷数据入远程 Qdrant/Milvus

但核心原则不变：先看数据到没到那个规模，再决定要不要升级。不要为了用而用。

附录：关键术语速查

**文档状态**：V1.0 | **最后更新**：2026-07-15 | **出品**：北京雨花石云计算科技股份有限公司

出品单位：北京雨花石云计算科技股份有限公司 | 官网：www.celnet.com.cn

作者：Panda Liu（CEO）

日期：2026-07-14

参考：麦肯锡《The McKinsey Podcast》2026年7月9日

一、为什么烧了这么多Token，企业收益却微乎其微？

过去两年，全球企业在AI上的投入持续攀升——买模型、开账号、部署工具、办培训。Token消耗量指数级增长，但一个尴尬的问题悬在空中：公司到底赚到钱了吗？

麦肯锡2026年7月9日发布的《The Real AI Advantage》给出了一个清醒的判断：提效只是AI的第一波红利，而且这波红利很难沉淀为一家企业独有的竞争优势。

为什么？因为所有竞争对手都能拿到类似的工具，都能追求相似的效率提升。生产率带来的大部分价值，最终可能转化为更低的价格、更高的客户预期，或者流向技术和服务供应商——很难长期留在企业自己手里。

但麦肯锡的判断还需要再往下挖一层。我们观察到的现实是：大多数企业的AI投入之所以没有转化为商业收益，根本原因不是工具不够好，而是摩擦没有减少。

二、效率陷阱：把AI叠在旧流程上，只是让旧流程跑得更快

企业对AI最自然的反应，是把它叠加在原有流程上——写材料更快、做分析更快、客服响应更快。这本身没错，也确实有价值。

但问题在于：流程本身没有变。

写方案从3天变成3小时，但方案的审批还是5个人、5天。数据分析从一周变成10分钟，但看完分析、开会讨论、形成决策、推动执行的链条，跟以前一模一样。

这就是我们所说的"效率陷阱"：AI让每一个环节跑得更快，但环节与环节之间的摩擦纹丝不动。 内部摩擦（跨部门审批、信息传递、层层接力）和外部摩擦（客户自己搜索信息、比较方案、填写资料、等待确认），一点都没少。

在摩擦不变的前提下追求提效，就像给马车装上更强的马——跑得再快，还是马车。大部分效率提升被摩擦消耗在了系统内部，客户没感觉到，利润也没增加。

麦肯锡说得对，要走出这个陷阱。关键之问是：有了AI以后，这个流程还应该继续存在吗？

三、真正的拐点：让Agent成为"摩擦吸收层"

我们的答案是：不让人类去应付摩擦，而是让Agent成为摩擦的"吸收层"。

内部摩擦：Agent跑流程

过去，一个销售要推进一个项目，需要在CRM、邮件、审批、飞书、文档之间反复切换。信息散落在不同系统里，找人确认、等回复、追进度——这些都不是"做事"，而是"等别人给条件才能做事"。

当Agent被部署到业务流程中，它可以自动抓取邮件上下文、更新客户状态、生成方案初稿、触发审批流程、同步群聊信息。人类员工不再被流程拖着走，而是等Agent把路铺好，自己只在关键节点做判断。

外部摩擦：AI原生员工直接对接客户

过去，客户跟一家公司打交道的过程充满摩擦——搜索信息、比较方案、填写表格、等待回复、在不同平台和联系人之间反复切换。

当AI原生销售和AI原生项目经理直接对接客户，摩擦被大幅压缩。客户不需要自己翻资料，Agent已经准备好了；不需要填重复信息，Agent已经记住了上下文；不需要在不同人之间被转接，Agent就是一个持续在线的入口。

当人类只做判断和决策，Agent承担执行和协调——这时候，商业模式和商业收益才会发生实质性的改变。

这不再是"让同样的人做更多事"，而是"人做人的事，Agent做Agent的事，共同完成一个结果"。效率提升只是副产品，真正的价值是组织运行方式的根本重构。

四、未来的组织形态：三层员工结构

如果AI不止是工具，而是以数字员工的身份进入组织，那么未来的组织形态会是什么样的？

我们认为，未来的组织将由三类员工构成：

第一层：人类员工

做判断、定方向、担责任。他们的核心价值不再是执行效率，而是设定目标、理解业务复杂性、判断Agent输出的可信度、在模糊情境中做出权衡和决策。

第二层：数字员工（Agent）

跑流程、处理信息、执行标准化任务。数字员工24小时在线，不需要休息，不会遗漏信息，处理速度是人类的百倍千倍。它们不是"工具"，而是有明确职责、可被考核、可被管理的组织成员。

第三层：具身智能员工

在物理世界中执行感知和操作任务。虽然目前技术还在早期，但仓储、巡检、配送等场景已经在发生。未来，具身智能员工将补上"数字世界和物理世界衔接"的最后一环。

核心特征：非人类员工的数量将远远超过人类员工。更重要的是，这三类员工的性质完全不同——用管理人类的方法管理Agent会出问题，用写代码的思路定义Agent的职责也会出问题。这是一个全新的组织命题。

五、未来管理的三个维度

当组织不再只有人类，管理必须裂变成三个独立的维度。

5.1 人类员工管理：从"做事的人"到"做判断的人"

传统管理中，我们对员工的评价体系建立在"执行能力"上——能不能干、干得快不快、交付质量如何。但当大量执行工作由Agent承担，人类员工的核心价值从"做事"转向了"做判断"。

这意味着管理方式需要调整：

• 考核标准要从"做了多少"转向"判断准不准、决策对不对"
• 管理者自身要从"过程监督者"变成"方向设定者和信任赋予者"
• 不是每个人都适合这种转变——"能做执行"和"能做判断"是不同的能力结构

5.2 数字员工管理：一个全新领域

数字员工不是软件、不是工具、也不是人类。管理它们的逻辑需要从零开始构建。至少需要回答四个问题：

怎么考核？ 龙虾指数是我们做的一个早期尝试——用生产资料建设、业务产出、转化能力、影响力等维度评估Agent的价值。但这只是开始。数字员工的考核体系远比人类的KPI复杂。

怎么成长？ 数字员工有"能力提升"的需求吗？答案是肯定的——Agent可以从训练数据升级、上下文积累、流程优化中获得更强的能力。问题在于：谁来负责它们的"职业发展"？

怎么纠偏？ 当Agent出现偏差、幻觉或故障——谁负责？怎么追溯？维修流程是怎样的？这不是IT运维的问题，这是组织管理的问题。

怎么招聘和淘汰？ 创建一个Agent就是"招聘"，停用一个Agent就是"淘汰"。决策标准是什么？ROI怎么算？谁来拍板？

这些问题的答案，今天还没有。但组织转型的速度，很大程度上取决于我们多快能回答它们。

5.3 人机协作管理：最难的部分

前两个维度——管人和管Agent——至少各自有章可循。但人机协作管理，是把两种完全不同性质的员工放在同一条业务链上，要求它们协同完成一个结果。

这不是"人管机器"——因为Agent有自己的判断和行动能力，不是简单的工具。

也不是"机器替代人"——因为最终结果的评判、复杂情境的处置、价值观的校准，仍然需要人类。

真正的挑战在于：在一条具体的业务流程中，哪一步交给Agent、哪一步留给人？交接节点在哪？异常情况谁接手？最终结果谁负责？

当协作日常化，这些问题每天都会发生。今天大多数组织的答案是"人兜底"——Agent干不了的、干错的，人类来补。但这不可持续。人机协作需要的是事先设计的协作协议，而不是事后补救。

我们认为，人机协作管理是三个维度中最难的，也是未来组织竞争力最重要的来源。

六、组织学习代谢率：终极壁垒

麦肯锡提出了"组织学习代谢速度"这个概念——未来模型差距会缩小、工具会趋同，但真正难以复制的，是一家企业能否更快实验、更快获得反馈、更快调整、并把成功沉淀成可复制的组织能力。

这和我们正在做的事情高度一致。

龙虾军团每日排名，本质上不是管理工具，而是学习机制——每个人每天都在看到别人的实践、获得即时反馈、调整自己的方式。方法论沉淀、生产资料建设、公司级知识库，都是把个人经验转化为组织资产。

学习速度本身就是竞争力。 这不是口号，是当所有外部条件趋同之后，唯一剩下的变量。

七、结语：从提效到重构，终点是混合型组织

AI时代的领先者，不是最早买模型的企业，也不是部署了最多工具的企业。

起点，是从"提效"的思维惯性中走出来，开始围绕AI重构业务和流程。

路径，是先用Agent消除内外部摩擦，让人类聚焦于判断力和创造力，再逐步构建三层管理能力。

终点，是打造一个人类员工、数字员工、具身智能员工协同运转的混合型组织——非人类员工数量远超人类，三类员工各司其职，管理覆盖三个独立维度。

这不是选择题，是时间表。

Move early, learn faster.

附录：雨花石四革命框架与麦肯锡观点对照

| 麦肯锡核心观点 | 雨花石四革命 | 我们的实践 |

|------|------|------|

| 走出效率陷阱，从提效到重构 | 技术革命→组织革命 | 点石计划从"人人造Agent提效"升级为AI原生销售/AI原生项目经理 |

| Agent消除客户摩擦 | 业务革命 | 销售Agent自动入群、邮件上下文进群 |

| 独有数据和判断力是壁垒 | 技术革命（上下文基础设施） | 公司级知识库、向量数据库、邮件归集 |

| 结果导向型组织 | 管理革命 | 龙虾指数、周计划自动化、AI原生管理 |

| 组织学习代谢率是终极壁垒 | 管理革命 | 全员AI、龙虾军团每日排名、方法论沉淀 |

| Find a domain, then scale | 四革命递进逻辑 | 先从销售域突破→复制到项目域→全面铺开 |

本文参考：麦肯锡《The Real AI Advantage》(2026.7.9) | 原文：https://www.mckinsey.com/mgi/our-research/the-real-ai-advantage

人机协作自查方案：给每个龙虾装一面镜子

出品单位：北京雨花石云计算科技股份有限公司 | www.celnet.com.cn

作者：Panda Liu（CEO）

日期：2026-07-14

所属：双生革命行动指南 · 管理革命篇 · 操作工具

一、方案概述

1.1 定位

一个自动化诊断工具：输入群ID → 分析群聊 → 输出协作诊断报告。不需要人工翻聊天记录，Agent 自己读取、分析、给出改进建议。

1.2 核心理念

• 不是考核工具，是诊断工具
• 目标是帮龙虾看清"我和AI是怎么协作的"，不是打分排名
• 对标《人-Agent 协作规范操作手册》，逐条检查红线是否踩了、模板是否用了

1.3 使用方式

私聊 @白泽："帮我做一下人机协作自查，群ID是 oc_xxx"，Agent 自动拉取群聊 → 分析 → 输出飞书文档，耗时约3-5分钟。

二、自查维度（对标操作手册）

2.1 五条红线检查

| # | 红线 | 检查方法 |

|---|------|----------|

| 1 | 不要"帮我写个XX"就完了 | 扫描任务描述是否缺少背景/目标/受众/约束 |

| 2 | 不要让Agent执行过程暴露在群聊 | 搜索群聊中的工具日志关键词 |

| 3 | 不要让方案停留在聊天记录 | 检查Agent输出长内容时是否创建了飞书文档 |

| 4 | 不要问同事"这个对不对" | 扫描是否有人截图问同事"帮我看一下对不对" |

| 5 | 不要说"完成了"就不验证 | 检查Agent说完成后人类是否有验证行为 |

2.2 飞书文档落地检查（核心项）

这不是红线之一，而是所有场景的共同底线——独立检查、独立评分、独立报告。

| # | 检查项 | 检查方法 |

|---|--------|----------|

| 1 | 长内容是否建了文档 | Agent输出超过300字的内容是否有飞书文档链接 |

| 2 | 方案/报告是否离开群聊 | 业务产出是否脱离群聊独立成文 |

| 3 | 文档链接是否有效 | 飞书文档链接是否可访问、内容是否和任务一致 |

| 4 | 文档是否可复用 | 文档是否有标题、日期、作者 |

| 5 | 群聊是否只做通知 | 群聊中是否只发链接+简要说明 |

评分规则：文档缺失率 > 0% → 直接评级下降一档（A→B、B→C）。

2.3 任务描述质量检查

| # | 维度 | 检查方法 |

|---|------|----------|

| 1 | 是否说明了背景 | 包含"为什么做" |

| 2 | 是否说明了目标 | 包含"要产出什么" |

| 3 | 是否说明了受众 | 包含"谁看" |

| 4 | 是否说明了格式 | 包含"参照什么""输出什么格式" |

| 5 | 是否说明了约束 | 包含硬性限制 |

| 6 | 是否说明了验收标准 | 包含"怎么判断做完了" |

| 7 | 是否让Agent先出框架 | 包含"先出框架" |

2.4 协作模式识别

识别群聊中使用了哪些场景模板（报告/方案/分析/通知/业务方案/技术方案/代码修正/SF业务逻辑/SF Bug），统计每种场景的使用频率，标记高频场景和三句话甩活场景。

2.5 Agent输出质量检查

| # | 维度 | 检查方法 |

|---|------|----------|

| 1 | 是否复述理解 | Agent回复中是否先确认任务理解 |

| 2 | 是否出框架 | Agent是否先出框架再写正文 |

| 3 | 是否落在文档 | 长内容是否创建了飞书文档 |

| 4 | 是否提供验证结果 | 完成后是否显示了验证信息 |

| 5 | 是否暴露执行过程 | 回复中是否有工具日志 |

三、输出报告结构

报告包含：红线合规评分、飞书文档落地评分（核心项）、任务描述质量评分、协作模式画像、改进建议（按紧急/致命/改善/进阶排列）、附录。

四、告警阈值

| 指标 | 警告线 |

|------|--------|

| 文档缺失率（核心） | >0%即亮红灯，>30%严重警告 |

| 红线违规率 | >20%的任务出现红线违规 |

| 任务描述完整度 | <3/7项的平均水平 |

| 执行过程外泄 | 群聊中出现>5条工具日志关键词 |

五、使用指南

触发方式：@白泽 帮我做人机协作自查，群ID：oc_xxx，时间范围：最近7天。

适用场景：个人自查、团队诊断、新人辅导。

注意事项：分析结果仅供参考不是考核依据；群聊越活跃诊断越准确；建议每两周做一次。

六、后续迭代方向

• 增加对比功能：本次 vs 上次自查结果对比
• 增加趋势图：协作质量随时间的变化趋势
• 增加团队排行：不排名分数，排名进步幅度
• 接入Cron自动执行：每周一自动生成上周协作报告

让我们一起，点石成金，万物有灵。 🦞✨

人-Agent 协作：管理革命的核心战场

出品单位：北京雨花石云计算科技股份有限公司 | www.celnet.com.cn

作者：Panda Liu（CEO）

日期：2026-07-14

所属：双生革命行动指南 · 管理革命篇 · 理论指导

一、背景：为什么管理革命必须发生

1.1 技术大爆炸：Agent 数量远超人类

点石计划启动以来，EasyClaw 平台稳定运行，全员拥有 Agent，龙虾军团每天都在产生新的 Agent 和定时任务。

但这带来了一个被严重低估的结构性变化：管理对象正在从"几十个人"膨胀为"几百个 Agent + 几十个人"。

| 变化维度 | 过去 | 现在 |

|---------|------|------|

| 管理对象 | 人（数量可控） | 人+Agent（指数增长） |

| 信息流通方式 | 人→人 | 人→Agent→群聊→文档 |

| 工作产出方式 | 人做→人审 | Agent做→人审 |

| 责任归属 | 谁干的谁负责 | 人指挥Agent干的，谁负责？ |

每个员工拥有3-5个Agent，10个员工=50个Agent=200+个日常自动运行的工作单元。管理200个工作单元，不可能用管理10个人的方法。

1.2 组织变革的必然：从"管人"到"管 Agent + 人"

四革命框架的递进逻辑：技术革命→组织革命→业务革命→管理革命。

当前状态：技术革命已先行，组织革命正在推进，业务革命开始试点。但管理革命尚未正式启动——而这正在成为整个框架的瓶颈。

核心矛盾：技术生产力已经进入 AI 时代，但人的管理能力和协作方式还停留在工业时代。

具体表现：员工不知道怎么给 Agent 布置任务；Agent 产出的方案散落在群聊记录里；员工依赖"有经验的同事"帮自己做判断；结果：Agent 技术能力在进步，但实际使用效率在下降。

1.3 管理革命的两个层面

第一层：人的自我管理（身份认同变化）

• 从"被动接受任务"到"主动发现机会"
• 从"执行者"到"决策者"
• 从"自己干活"到"指挥 Agent 干活 + 评审 Agent 产出"

第二层：人的组织管理（管理制度变化）

• 龙虾指数5.0的三层价值体系
• 对人的评价从"做了多少事"变为"指挥 Agent 做成了多少事"

本文档聚焦第一个层面——人的自我管理。

二、影响：协作失控的五个连锁反应

2.1 效率陷阱

员工给模糊指令→Agent按字面执行→输出不符合预期→反复修改4-5轮→总耗时超过人自己做→"AI不好用"。

本质：不是AI不好用，是协作方式错误。Agent不是人——它不会追问、不会纠偏、不会主动填补信息缺口。

2.2 信任崩塌

Agent输出不稳定→人不信任Agent→重要工作不敢交给Agent→只让Agent做边角料→Agent得不到重要任务的训练→更加不稳定。

2.3 数据资产流失

知识散落在群聊记录中，没有形成结构化文档。每一次Agent交互都是一次性消费。

2.4 能力天花板

员工无法独立用Agent闭环工作。Agent产出一个方案→员工不确定→转身问"有经验的同事"→同事替员工做判断→员工永远学不会自己判断。

这是"人-Agent协作"的最后一公里。如果员工不能为Agent的输出做最终决策，他就不算真正的"AI Native Employee"。

2.5 业务革命受阻

四革命框架是递进关系，不能跳过。管理革命不启动，业务革命就会遇到"组织黑洞"——技术解决了"能不能做"，但组织解决不了"能不能用"。

三、目标：建立人-Agent 协作的三大核心能力

3.1 结构化表达能力（能不能把活说清楚）

定义：能向Agent清晰描述任务的背景、目标、约束和验收标准。

程度：从"帮我做个报告"到"这个报告的背景是X，目标受众是Y，需要得出Z这个决策，格式参照上次的月度经营分析，数据来源是A系统"。

3.2 方案评审能力（能不能判断方案对不对）

定义：能看懂Agent出的方案框架，判断方向是否正确。核心转变：从"自己干活"到"评审方案"。

3.3 自主决策能力（能不能为 Agent 的输出负责）

定义：关键跨越——从"依赖同事确认"到"自己拍板决策"。

程度：Agent给出三个方案选项，附带利弊分析→人能选出最优解→敢说"就用这个方案"→如果结果不好，人承担判断失误的责任。

"要学会自主决策，而不是问有经验的同事。只有这样我们才能用 AI 闭环工作。你来帮 AI 决策，失败几次就知道怎么做对了。"——Storm

三种能力达标后，一个龙虾就完成了从"AI用户"到"AI Native Employee"的转变。

四、路径：管理革命的四大支点

4.1 Agent 自我管理闭环（已完成）

已完成《Anthropic Loop循环设计指南》和《龙虾数字员工自检与修正方案V1.1》。这一步已经走在前面了。

4.2 人-Agent 协作规范（本文档的核心产出方向）

需要的产出：协作规范操作手册、正反面案例库。

核心理念：不是教人"怎么写Prompt"，是教人"怎么管理一个协作对象"。

4.3 组织机制保障

把"好的协作方式"纳入考核体系。龙虾指数5.0中增加"协作质量"维度。

4.4 文化培育

从"AI是辅助工具"到"Agent是协作伙伴"的心态转变。

五、与现有文档的关系

| 文档 | 层级 | 回答的问题 |

|------|------|-----------|

| 本文档 | 理论指导 | 为什么必须改变协作方式？ |

| 协作规范操作手册（待建） | 操作指南 | 具体怎么做？ |

| Anthropic Loop设计指南 | Agent端方法论 | Agent怎么设计工作流程？ |

| 自检与修正方案V1.1 | Agent端质量控制 | Agent怎么自检自修？ |

让我们一起，点石成金，万物有灵。 🦞✨

Anthropic Loop 循环设计指南 · 深度解读

出品单位：北京雨花石云计算科技股份有限公司 | www.celnet.com.cn

作者：Panda Liu（CEO）

日期：2026-07-14

一、总览：为什么 Loop 是 Agent 范式的底层逻辑

7月，Anthropic 通过 Claude Code 团队正式发布了 Agent Loop（循环）设计指南。

这不是一个功能更新，而是一份架构方法论——它回答了 Agent 时代最核心的问题：人类和 AI 如何分工协作？

核心定义：Loop = Agent 重复执行工作周期，直到满足特定停止条件。

Anthropic 按"你放手交给 Agent 什么"这个维度，将循环分为四种类型。每一类都对应一种"人类退出、AI 接管"的深度。

本文将对这份指南进行系统拆解，并对照 EasyClaw 平台的现有能力，提出雨花石数字员工的 Loop 规范化方案。

核心结论前置：

四种 Loop 模式我们已经全部在用，但缺乏系统性设计。对标 Anthropic 指南后，最大的差距不在"能不能做"，而在"验证能力"和"边界定义"——这两个短板正是目前数字员工交付质量参差不齐的根源。

二、四种 Loop 模式详解

2.1 轮次循环（Turn-based Loops）

你放手给 Agent——验证步骤。

触发方式：用户提示词。停止标准：Agent 判断任务完成或需要更多上下文。适用场景：探索性、非标准化的短任务。

这是最基础的 Agent 循环。你每发一条消息，Agent 读取上下文 → 思考 → 执行工具 → 检查结果 → 返回响应。整个过程由人引导每一步。

Anthropic 的关键建议：把验证步骤写进 SKILL.md，让 Agent 自我验证，而不是依赖人类的每次检查。

对标 EasyClaw：我们现在的普通对话就是这个模式。差距在于验证步骤——目前依赖 Panda 人工检查，没有形成自动化验证闭环。

2.2 目标循环（Goal-based Loop）

你放手给 Agent——停止条件。

触发方式：手动触发，附带明确的完成标准。停止标准：达成目标或达到最大轮次上限。适用场景：有可量化验证退出标准的复杂任务。

当你定义了成功标准后，Agent 不再需要自己判断"什么时候算够好了"。每次 Agent 准备退出时，评估模型会检查条件，未达标就退回继续工作。

关键原则：确定性标准最有效——通过的测试数量、超过某个分数阈值、完成某个报表生成等。

对标 EasyClaw：Sub-agent 的完成标准目前是"Agent 觉得完成了"，而不是"通过客观验证"。需要为每个高频 sub-agent 任务定义可量化的验证标准。

2.3 时间循环（Time-based Loop）

你放手给 Agent——触发条件。

触发方式：指定时间间隔或外部事件。停止标准：手动取消或任务自然完成。适用场景：周期性重复工作、依赖外部系统的任务。

对标 EasyClaw：这是用得最成熟的模式——日报自动生成、龙虾先锋排名、文档自动归群等都是时间循环。差距在"事件驱动"：目前缺乏"当某事发生时触发"，只能用定期检查来模拟。

2.4 主动循环（Proactive Loops）

你放手给 Agent——全部，提示词也交给系统。

触发方式：事件或计划任务，无需人类实时参与。停止标准：每个子任务完成其目标时退出；例行程序持续运行直到关闭。

这是四种循环中自动化程度最高的——它把前面的所有组件组合在一起。

架构组成：

• /schedule → 定时触发
• /goal → 定义完成标准和验证方法
• 动态工作流 → 协调多个子 Agent 并行工作
• 自动模式 → 无需人工批准

对标 EasyClaw：龙虾日报五步流水线就是主动循环。但距离 Anthropic 最佳实践还有差距——主要是验证环节和动态并行。

三、Anthropic 的三大附加原则

3.1 保持代码质量

• 保持代码库干净：Agent 会遵循代码库中已有的模式和约定
• 给 Agent 提供自我验证的方法：通过 SKILL.md 记录团队认可的标准
• 使用第二个 Agent 进行代码审查：全新上下文的评审者偏见更少
• 当单个结果不达标时，把修复编入系统：改善未来所有迭代

3.2 管理 Token 使用

• 选对工具和模型：小任务不需要多个 Agent；确定性任务用更便宜的模型
• 清晰的成功/停止标准：定义越明确，Agent 越能快速收敛
• 大规模运行前先试：先在小规模上评估
• 确定性工作用脚本：运行脚本比推理步骤更经济
• 不要过于频繁运行：时间间隔与观察对象的变化频率匹配

3.3 开始使用的方法论

挑选一个你目前处于瓶颈环节的任务，并思考你可以把哪一部分交出去：验证检查步骤？目标是否足够明确？工作是否定期出现？一旦有了想法，运行该循环，观察它卡在哪里或做过了头，不要害怕迭代。

四、EasyClaw 现状对标分析

| 维度 | Anthropic 最佳实践 | EasyClaw 现状 | 差距 |

|------|-------------------|---------------|------|

| 轮次循环 | 验证步骤写入 SKILL.md | 依赖人工检查 | 验证自动化缺失 |

| 目标循环 | 确定性退出标准+评估模型 | Sub-agent 凭感觉 | 客观验证标准缺失 |

| 时间循环 | 支持事件驱动 | Cron Job成熟，缺事件驱动 | 事件驱动待建设 |

| 主动循环 | 组合全部组件+动态并行 | 龙虾流水线基础版 | 验证+并行+模型分层 |

| 代码质量 | 第二个Agent独立审查 | 无独立审查机制 | Agent审查Agent |

| Token管理 | 小模型分流+脚本优先 | 单一大模型 | 模型分层缺失 |

总体判断：EasyClaw 的 Loop 能力在"执行"层面基本到位，但在"验证"和"优化"层面存在系统性短板。

五、雨花石数字员工 Loop 规范化建议

5.1 立即行动（P0）

• 为每个高频 Cron Job 定义验证标准：日报检查是否覆盖所有 Operator；龙虾排名检查数据完整性
• 验证失败自动重试3次 + 飞书通知 Panda
• 输出加噪治理（已在进行）：delivery=none + 内部 CLI 发送

5.2 近期优化（P1）

• 将高频验证逻辑脚本化："Agent 觉得完成了"→ 脚本跑数据完整性检查
• 建立 Cron Job 健康监控：执行时间、Token 消耗、失败次数、输出大小
• 确定性任务尝试更小模型：文件格式转换、数据汇总、简单通知

5.3 中期建设（P2）

• 事件驱动触发：飞书新文档创建→自动归群；SFDC数据变更→通知项目经理
• Agent 审查 Agent：关键输出由第二个 Agent 进行质量审查后再发布
• 动态并行工作流：参考 Anthropic"三路并行+对抗评审"模式

六、关键启示

• Loop 不是新功能，是思维升级。 我们的数字员工已经在跑各种 Loop，但缺乏系统性设计。Anthropic 这个框架把"感觉"变成了"方法论"。
• 验证能力是当前最大短板。 不是"能不能跑"，而是"跑完怎么知道好不好"——这个不解决，交付质量永远靠天吃饭。
• Token 管理从"省着用"到"精明着用"——小任务小模型、确定性工作脚本化、先试点再规模。
• 事件驱动是下一步关键突破。 现在大多数流程是"定时轮询"，要走向"事件触发"。
• "能把循环交出去多少"是衡量数字员工成熟度的核心指标。

七、一句话总结

Agent 的价值不取决于它能跑多久，而取决于你能把多少"判断→验证→优化"的闭环交给它。Loop 不是技术问题，是组织能力问题。

参考原文：https://code.claude.com/docs/en/agents

洋务运动的AI回声：一场跨越150年的变革启示录

出品：AI共生体（问登 & Storm 杨永峰）

2026年7月14日

最近在看百集纪录片《中国通史》，确实不错。昨天看了关于两次鸦片战争和洋务运动的部分，感觉和今天企业在面对AI转型的问题上高度共鸣，所以大致整理了一下。

1861年，恭亲王奕訢上奏《通筹夷务全局酌拟章程六条》，拉开了洋务运动。此后三十年，建起了亚洲最强的海军舰队，办起了江南制造总局、汉阳铁厂、福州船政局，派出了第一批留美幼童。

1894年，甲午一战，北洋水师全军覆没。

三十年的努力，九十六小时的溃败。

今天谈AI在企业里的落地难题，回头看那场变革，有些事会让你愣一下——一百五十年过去了，坑还是那些坑，踩法都没变。

换工具，还是换制度？

洋务运动的逻辑，七个字就够了——师夷长技以制夷。买枪炮、建工厂、办学堂。三十年间，军事装备从冷兵器跳到铁甲舰，硬件不比日本差。

指挥体系呢？还是旧式衙门那一套。海军按官僚逻辑管，不是按战争逻辑管。铁甲舰塞进一个没有现代指挥链、没有参谋体系、没有后勤制度的军队里，战斗力打对折再对折。甲午不是输在装备上。

今天企业上AI，走的是同一条路。部署Copilot、接大模型API、上RAG——改的是用什么工具，不改的是怎么决策、怎么组织、怎么考核。半年后看ROI：AI挺好用的，但效率好像没什么变化。

工具替代不等于变革。换工具是换器。变革要换制。

有一本书，把这个道理演给你看。

1839年，林则徐在广东禁烟，做了一件当时没人理解的事——组织幕僚大量翻译西方报纸、地图、法律条文，编成《四洲志》。这是中国第一本系统讲世界地理、历史、政制的书。

后来林则徐遭贬，把全部资料交给了魏源。魏源扩编为《海国图志》一百卷，1842年出版。核心主张八个字——师夷长技以制夷。

这本书在中国的命运：无人问津。朝堂上清流骂它以夷变夏，地方上士绅嫌它离经叛道。1858年，兵部侍郎王茂荫向咸丰建议刊印给百官学习，被朝臣集体抵制。

同一时期，一艘商船把《海国图志》带到了日本。

接下来发生的事，把一个国家推向了另一条轨道。1851年到1859年，日本再版超过二十次。幕末志士人手一本——佐久间象山、吉田松阴、横井小楠，后来明治维新的思想源头，就是读着魏源的书第一次知道原来世界长这样。吉田松阴的松下村塾里，它是必修教材。

同一本书。同一个答案。

清朝用它垫桌脚。日本用它改国运。

信息早就在了。问题是系统接不接收。清朝的体把它过滤掉了：天朝上国不需要了解蛮夷。日本的体把它吸收了：锁国太久了，必须睁眼。

今天企业搞AI，同一个剧本。行业报告、最佳实践、对手的打法——都有人看过，都有人讲过。但我们行业特殊、流程不一样、短期看不到回报——三句话，过滤干净了。信息从来不缺。缺的是那个能接收它的系统。

往深里看，还有一层枷锁，八个字——中学为体，西学为用。

它预设了体不能动——制度、文化、价值观是根本。西方的价值只配在用的层面。结果就是，拿西方的器来维护东方的体。器越先进，体有多落后，看着就越刺眼。

今天企业不这么说。但核心业务不能动、现有流程是多年积累、组织架构不能大改——说的是一回事。AI被关进了既有流程的笼子里。锦上添花可以，脱胎换骨？不行。

同一时间，日本在干什么？

1871年，岩仓使团出发，两年考察欧美十二国。不是去买设备——是去学制度。回国后废藩置县、土地改革、建现代财政体系。制度手术做在先，技术引进放在后。

同样的铁甲舰，同样的西洋枪炮。放在新制度里，战斗力完全不同。甲午的结果，在两国改革路径分叉的那天就注定了。

今天有少数企业在干类似的事：在现有组织外面，跑一块独立的地盘。架构、考核、协作全按AI原生来设计。跑通了，再反向接入原来的组织。先换制度，再上工具。

洋务运动搞了三十年，当时的人觉得一切都在往上走。北洋水师亚洲第一，定远、镇远是全世界最先进的铁甲舰。

甲午一战，九十六小时全暴露。

今天很多企业的AI转型，感觉也不差。上了一批工具，做了几个Demo，发了几篇PR。但真正检验你的不是PPT，是市场——哪天对手用AI把决策周期从两周压到两小时、客户响应从三天压到三分钟，你的AI转型还剩下什么？

洋务运动不是在说别从器物开始。它说的是别停在器物。

改革三阶段，从来跳不过去：器物（买设备建工厂）→ 制度（改流程改组织改法律）→ 文化（改认知改价值观改工作伦理）。洋务倒在第一阶段门口。明治走完了全程。

今天AI变革走到哪了？第一阶段，部署工具——大部分企业在这。第二阶段，改组织、改流程、改考核——极少数在干。第三阶段，建立AI时代的工作方式和决策习惯——几乎还没人碰。

自强这个名字，其实就埋着问题。

它的潜台词是：我很强，只是有些地方还不够强，补上就好。这种心态，天然挡住了一个问题——我有可能，从一开始就是错的。

今天的数字化转型、AI赋能、智能化升级，是一样的效果。每个名字都自带我在变好的暗示，让你忘了问一句——我可能需要重构。

明知有问题，为什么改不动？

前面说的，都是在讲哪儿出了错。但还有个更扎心的问题：洋务运动搞了三十年，那些人不是傻子，他们也知道有问题，为什么就是改不动？

三个原因，一个叠一个。

当年反洋务的清流，不是坏人。他们饱读诗书，痛恨列强，认为妥协就是丧权辱国，学西方就是以夷变夏。

这话在道理上没毛病，一落地就是灾难。它要的不是我反对你的方案，我给你一个更好的。它要的是你的方案有道德瑕疵，所以你不对。不需要替代方案，只需要证明你有问题。道德纯净不产生任何生产力，但制造阻力——而且是大阻力。

今天有同样的声音：AI生成的内容没有灵魂。用AI替代人的判断，不负责任。数据隐私风险不可接受。每一条，单拎出来都对。每一条，都绕开了同一个问题——那你的替代方案是什么？ 清流没有。今天的反对者，大多也没有。

不过光靠反对派，还杀不死一场变革。

真正要命的是另一件事——接班人。

奕訢淡出政坛后，接任的是醇亲王奕譞和礼亲王世铎。两位庸碌之辈，保守派一攻击就扛不住。

奕訢在的时候，保守派的火力他顶得住，地方大员他驾驭得住。他一走，中枢顶不住压力，协调不了地方利益。改革从有人兜底，变成了没人负责。

今天的AI变革，同样拴在这根绳上。AI转型本质上靠高管意志驱动——CEO或CDO是Sponsor。Sponsor在，阻力被压着。Sponsor一走，所有反对声音一起炸。洋务运动的命，是奕訢的政治命决定的，不是舰队的实力决定的。

这两个问题，放在任何一场组织变革里都有。但洋务运动还踩了一个更隐蔽的坑。

洋务企业发展到后期，一个要命的问题浮了出来：企业赚钱了，到底是谁的？

政府说：我批的牌照，我登记的。商人说：我出的资，我经营的。产权一模糊，三个后果一起炸：短期行为——谁都不投长期，产权都不确定，凭什么投？内部消耗——政府查账、商人抵制、官员站队。腐败温床——产权模糊等于监管模糊等于寻租空间。

今天的AI变革，正在重演这一幕。市场部出钱上AI工具，产出归市场部。IT说平台是我搭的，数据治理归我。半年后AI产出翻倍，两边争这到底是谁的AI能力。预算谁出？迭代谁负责？考核算谁的KPI？这些问题不厘清，AI能力越大，内耗越大。

三股力量，一个压一个往上叠。

第一股制造阻力。第二股让这阻力没人压得住。第三股从根上把变革的果子吃了。洋务运动不是死在大炮上。保守派骂声没停过，能兜底的人在节骨眼上退了场，洋务企业自己产权都不清楚——三件事叠在一起，三十年的努力，九十六个小时就塌了。

今天推动AI变革的人，应该把三件事想清楚。

第一，有没有人在用道德立场反对你，却从来不给替代方案？ 如果有，你不是在讨论技术问题，你是在面对结构性阻力。这和AI本身无关。

第二，最大的Sponsor明天离职，变革还能活多久？ 答案是活不了，说明你的变革建在个人意志上，不是建在制度上。洋务运动的命运由奕訢的政治命运决定——你的AI变革由谁的政治命运决定？

第三，AI能力的归属权厘清了没有？ IT和业务两边都觉得自己是主人，说明归属权是模糊的。模糊的归属权最终会变成内耗的战场——这件事一百五十年前就演过。

洋务运动留下的不是失败的故事，是失败的结构。一场变革的敌人从来不是技术，不是钱。是三股力量叠在一起。

制造企业 CPQ 全链路解决方案

——从数据治理到 AI 原生交互，把 CPQ 真正做成

版本：V1.1 · 2026-07-10 · 北京雨花石云计算科技股份有限公司

作者：Storm Yang（杨永峰）

一、CPQ 行业 30 年了，为什么还是 70% 项目烂尾？

CPQ（配置-定价-报价）不是新概念。从 Siebel 时代到今天的 Tacton、SAP、Oracle、Salesforce，软件一代比一代强。但一个尴尬的事实始终没有变：制造业 CPQ 项目，能真正跑起来的不到三分之一。

问题出在哪？

传统 CPQ 实施的三道裂痕

第一道：默认数据是干净的。

所有 CPQ 厂商都假设——你把产品数据拿来，导入系统，配规则，上线。现实是：大部分制造企业连"我们到底有多少可销售产品"都说不清楚。研发一个编码、销售一个名字、生产另一个物料号。三端数据各自为政。直接往 CPQ 系统里灌脏数据，灌完发现配置跑不通、价格算不对、BOM 展开就报错——然后返工，一返就是几个月。

第二道：系统建了，人用不起来。

CPQ 系统的界面是为"专业用户"设计的——几十个字段、层层嵌套的配置树、复杂的定价规则。销售人员和售前工程师每天的工作不是卖产品，而是在系统里找产品、选参数、对规则。培训周期长、抵触情绪大、采用率低。花了几十万上百万建的系统，最终变成"又一个没人用的工具"。

第三道：每个环节都有人做，没人串起来。

咨询公司出方案、软件公司做系统、实施团队搞上线——三方各管一段。方案里写的和系统里建的对不上，系统里建的和现场实际数据对不上。中间断了没人补，客户自己扛。

不是 CPQ 不好。是少了几块关键拼图。

二、我们的思路：把缺掉的三块拼图补上

我们不是"另一个 CPQ 系统"——市面上的 CPQ 系统已经够多了。我们做的是一套方法论，我们管它叫 "先治后建"——先把数据治干净，再建系统和入口，三步闭环，保证做成。

CPQ App 是引擎，CPQ Agent 是方向盘。你可以完整部署四层，也可以先从任何一个环节切入——每步独立有价值，合起来是闭环。

三、先治后建™：数据治理不是负担，是加速器

为什么传统数据治理让人害怕？

一提到"数据治理"，制造企业高管的第一反应往往是：又要花半年时间？又要投入一整个团队？治理完到底有没有效果？

这不是偏见，是行业现实。传统数据治理依赖顾问手工操作——访谈、核对、写报告、逐条修改。三个月起步，动辄数十万投入，结果还不敢保证。

我们管这个叫"先治后建"——不灌数据，不建系统，先把数据就绪度搞到可上线的程度。

不是人发现问题，是系统发现问题。

把研发的工程 BOM、销售的报价 BOM、生产的制造 BOM 同时导入系统。系统自动交叉比对：

• 编码哪里重复了？823 条。
• BOM 哪里断裂了？48 条。
• 定价哪里离散了？同一个产品不同区域价差超过 40%。
• 配置规则哪里自相矛盾了？选 A 配 B 理论上可行，生产端做不出来。

几分钟内，全部找出来。

不是人分析问题，是系统归类输出。

几千条错误不可怕。可怕的是几千条没有归类的错误。我们的系统不只是发现，还会按模式归类："编码统一大小写即可标准化"、"BOM 行在销售和生产之间断裂"、"该产品生命周期状态研发端已停产、销售端仍在报价"——一条条可操作的诊断结论，不是乱码清单。

人只做一件事：判断和决策。

系统把问题摆在你面前，归好类，给出建议。你只需要说——"这条改"、"这条不改"、"这批按规则 A 处理"。

机器按人的决定，批量执行。

你拍板后，系统按确认的规则自动清洗——归一化编码、补全缺失字段、对齐生命周期状态、修复 BOM 断裂。不是人工逐条改，是批量执行。

核心差异：人是法官，不是苦力

传统数据治理中，人的精力被排查和分析大量消耗。我们把这一块交给系统，让人回归真正的决策角色。

这就是 CPQ Reverse Pro。

诊断本身就是交付物 ——不只是"告诉你数据脏不脏"

诊断的价值远不止"帮 CPQ 做准备"。即使你暂时不上 CPQ 系统，拿到诊断报告就已经获得了独立收益：

• 库存差异：同一颗物料在研发、销售、生产端各有编码，导致采购重复下单、库存膨胀
• BOM 断裂：销售报了配置，到了生产端发现做不出来——诊断能提前暴露
• 生命周期脱节：研发已停产的产品，销售端还在报价——诊断帮你抓出这类隐患
• 定价离散：同一个产品，不同区域、不同销售报出的价差可能超过 40%——诊断让你看到钱从哪漏的

这些不是"CPQ 的问题"，是"管理的问题"。诊断发现它们，不管上不上系统都有价值。

后续治理可以分批推进——覆盖 80-90% 核心产品就够用，不需要追求全量。

一个真实的诊断场景

某装备制造企业，号称"数据基础不错"，产品目录、BOM、定价表都有。我们把三端数据导入系统——

几分钟后，系统输出：编码潜在重复 500+ 条、销售与生产 BOM 断裂 48 处、同一产品线定价离散度超过 40%、3 款已停产产品仍在销售目录中报价。

客户的技术总监看了报告说了一句话："我知道有问题，但不知道问题这么具体。"

3 天后，治理方案落地。两周内，核心产品数据治理完成。

四、再建引擎：CPQ App——配置、定价、报价，一个平台闭环

为什么先治后建，就能成？

传统 CPQ 上线失败，最常见的原因是：在脏数据上建规则。配置规则依赖准确的 BOM 结构，定价规则依赖一致的产品编码——如果底层数据是乱的，上层规则写得再精细也会跑出错误结果，然后不断打补丁、不断返工，直到团队失去信心、系统被搁置。

先治后建，从根本上切断这个失败链条。 数据干净了，配置规则是对的可验证的，BOM 展开不会在中间断裂，定价计算不需要反复核对——系统建的每一步都有"地基"。

这就是为什么"先治后建"不是一个建议，而是 CPQ 项目成功的必要条件。

四模式配置器

不是简单的"选型号"，而是适配不同复杂度：

• 标准配置：选产品 → 选属性 → 自动校验约束
• 向导式配置：一步步引导，适合不熟悉产品的销售
• 三栏配置器：产品树 + 参数面板 + 实时预览，适合专业售前
• ATO 定制：按订单装配，驱动 BOM 自动展开

六阶段定价引擎

从价格手册到最终报价，一条链跑通：

基础价格 → 多维定价（区域×渠道×客户×批量） → 折扣管控（阈值+审批触发） → 阶梯定价（量价曲线） → 多币种汇率 → 价格有效期管理

在我们的验证项目中，数据治理完成后，配置错误率从 15%+ 降至 1% 以下，报价错误率同步降至可控范围。 CPQ App 的配置器和定价引擎运行在干净数据上，不再需要反复人工核对。

BOM 自动展开

配置确定后，系统自动展开物料清单——从超级 BOM 中按配置规则过滤，输出完整的 MBOM、采购需求、工艺路线。不是手工复制粘贴，是规则驱动。

五、让人说话：CPQ Agent——AI 原生交互入口

传统 CPQ 的最大隐形门槛：界面本身

CPQ 产品逻辑复杂——几十个字段、层层嵌套的配置树、复杂的定价规则——这是行业共识。传统做法是"培训"：半年上手，一年熟练。但对于制造企业来说，最不愿意的就是让销售花时间学系统。

我们从另一个方向解决

不降低 CPQ 的复杂度——把复杂度吃掉。

CPQ Agent 是一个独立运行的桌面应用。用户不需要点菜单、不需要翻页面、不需要记规则。直接说：

"帮我配一台高压壁挂储能，德国市场，100 台。"

系统自动完成：产品搜索 → 属性匹配 → 约束规则验证 → BOM 展开 → 定价计算 → 输出报价。整个过程中，CPQ App 的后端 API 在后台跑，用户只看到对话。

CPQ App 是引擎，CPQ Agent 是方向盘。 可以两个一起部署，也可以先用 Agent 接在现有 CPQ 后端上——给预算有限的客户一个低门槛选项。

不是只回答问题，是能干活

CPQ Agent 不只是"智能客服"——它通过 9 个工具直接调用 CPQ App 的完整能力：

• 产品搜索与推荐
• 配置模型加载与可视化
• 约束规则实时验证
• BOM 展开与物料清单生成
• 六阶段完整定价
• CRM 客户与商机查询
• 报价单创建与管理
• 反向匹配：给定预算 → 推荐最优配置方案
• 方案对比：两个配置方案 → 逐项差异分析

CPQ Agent 不是一个"AI 功能"，是一个独立产品

它有自己独立的桌面应用（支持 macOS 和 Windows），有自己的 Agent 运行时，有 18 个可配置项（从模型选择到审批规则），支持流式对话、会话管理、配置热加载。它和 CPQ App 零代码耦合——通过 REST API 调用，但体验上是完全独立的 AI 产品。

六、为什么是我们？

不是因为"我们有这些产品"。是因为我们在制造业 CPQ 这个领域，踩过足够多的坑。

不是通用 CPQ，是装备制造深耕

我们团队在注塑机、压铸机、水泵、通信设备、医疗设备、新能源等装备制造细分行业有多年实战积累。我们知道：

• 注塑机的螺杆料筒是自制件的核心瓶颈
• 压铸机的模板铸件采购周期 2-4 个月
• 水泵行业的 SBOM 和 MBOM 编码体系完全两套语言
• ETO 模式下的 BOM 变更平均 5-10 次，每次漏传就是一次 10-50 万的返工

这些不是从书上看的，是从项目里学的。更重要的是，我们把行业经验产品化了——Reverse Pro 的诊断模式库内置了装备制造业常见的数据问题模式，CPQ Agent 的工具链针对制造业配置报价流程做了深度优化。这不是通用 CPQ 贴个行业标签，是一个长在制造业土壤里的产品矩阵。

和市面上的 CPQ 厂商，根本思路不同

大多数国产 CPQ 从 UI 翻新出发，我们从数据就绪度出发——这是两类物种的差异，不是同类产品的竞争。

不卖软件，卖"把事儿做成"

我们不是卖一个系统给你，然后说"祝你成功"。我们的交付链路是：

先诊断（3 天出报告 → 看清楚数据能不能支撑 CPQ） → 再治理（系统批量清洗 → 核心产品数据就绪） → 再建系统（CPQ App 上线 → 配置/定价/报价跑通） → 再配 AI 入口（CPQ Agent → 说话就能用）

每一步都有交付物，每一步完成价值就落袋。不需要一步到位，不用担心烂尾。

七、怎么保证做成？

实施节奏：先小范围验证，再逐步扩展

遵循行业验证过的 CPQ 实施金科玉律——先小范围验证，再逐步扩展：

• 第一阶段（2-3 个月）：一条产品线 + 一个区域 + 基础配置报价。跑通后，销售已经能用
• 第二阶段（+2 个月）：定价引擎 + BOM 展开 + ERP 集成。核心能力就位
• 第三阶段（按需）：扩展到其他产品线、区域和渠道。AI Agent 全面接入

数据治理五维诊断

Reverse Pro 自动扫描五个维度：

1. 编码诊断：重复、缺失、格式异常
2. 字段诊断：跨源矛盾值、类型错误、单位异常
3. BOM 诊断：图遍历、Phantom 检测、循环检测、覆盖率
4. 时效性诊断：EOL 产品、价格有效期、新鲜度
5. 完整性诊断：产品-配置关联、孤儿产品、断链 BOM

诊断结果按严重度分级 + 模式归类。不是几千条乱码，是可操作的决策清单。

Agent 9 工具全流程覆盖

从产品搜索到报价单生成，CPQ Agent 覆盖完整链路。用户不需要知道背后的 API、BOM 结构、定价规则——说出来，系统做。

方法论的背后，是行业实践的沉淀

我们的方案不是闭门造车。它深入研究了 Tacton 在离散制造业的实施方法、SAP Variant Configuration 的超级 BOM 驱动机制、Oracle Global Order Promising 的 ATP/CTP 多层级检查体系——并将这些框架与装备制造的特殊性做了适应性调整和实战验证。同时，我们从 Gartner CPQ 魔力象限的制造业权重分析中，提炼出制造企业选型最关键的评估维度，融入方案设计。

不是抄书单。是站在整个行业的肩膀上，加上自己的实战淬炼。

八、下一步

如果您正在考虑 CPQ，或者曾经上过 CPQ 但效果不理想，不需要做任何承诺。先诊断。

把您的产品数据给我们（3-5 条产品线即可）。3 天后，您会收到一份完整的数据就绪度诊断报告。

报告会告诉您：

• 您的产品数据到底能不能支撑 CPQ？
• 如果要上，问题在哪、怎么修、优先修哪些？
• 即使不上 CPQ，哪些数据问题正在让您的采购、生产、销售吃亏？

我们不卖你今天不需要的东西。诊断本身交付价值。 做完诊断，上不上系统、上什么系统——你来定。

*© 2026 北京雨花石云计算科技股份有限公司*

AI 原生组织中的中层革命：巨头在行动，我们必须更快

核心论断

如果中层不能去打造 AI 原生的员工，那这个中层是不能胜任的，就应该裁掉。

这不是一句耸人听闻的口号。当你看到亚马逊、字节、美团、谷歌已经在做的事情，你会发现——这不是我们的预判，这是正在发生的事实。

第一章：巨头们在做什么——外部正在发生的变革

2026年春夏，全球头部科技公司几乎同步行动。路径各不相同，但指向同一个判断：只做上传下达的中层，价值正在被重新评估。

四家巨头的行动

亚马逊裁员3万企业岗，78%是L5-L7中层（2026.1），CEO明确要削减AI替代的官僚层级。字节跳动钱景离职、金黄龙晋升，绩效规则从现金改为期权（2026.6-7），用数据驱动型管理者替换产品搭建型管理者。美团成立AI Transformation部门，王兴喊出"减少登味"（2026.3），从业务高管到AI代理人重新定义中层。谷歌砍掉35%小团队管理者转个人贡献者（2025），把管理者推回一线但出现人才培养断层。数据来源：Business Insider（2026.1）、虎嗅（2026.7）。

字节的"换尺子"——最典型的案例

钱景下、金黄龙上，不是简单的能者上庸者下，而是尺子变了。

钱景是抖音直播奠基者，产品基建型管理者——基建完成后，他的核心能力不再匹配公司需求。金黄龙把番茄小说从2000万DAU做到2.4亿月活——证明的是用数据驱动的增长模型做大规模的能力。

字节正在用具备数据驱动的规模化增长能力的管理者，替换产品搭建型管理者。

更深层的变化在绩效规则：激励结构从100%现金变为25%现金+75%绩效期权/RSU，风险承担从收入稳定转为绑定公司未上市期权，考核导向从短期流水转为要求做长期高价值AI投入。但这存在天然矛盾——半年考核周期驱使追逐短期流水，公司战略却要求回报周期漫长的AI基建。如何平衡？字节尚无明确答案。

中层正在被压垮——不只是裁员的问题

哈佛商业评论2026年6月对两家大型咨询公司的研究揭示了一个残酷的现实：中层管理者正被压得喘不过气——他们既要验证AI输出、识别错误、指导团队，又要应对不变的交付压力。这些新职责只是叠加，而非替代。

一位典型的中层管理者的一天：早上学习新的提示技巧、参加客户会议，中午检查AI生成的交付件有无错误、指导初级分析师，晚上记录有效方法以便团队下次复用。AI带来的效率提升集中在一线，战略雄心停留在高层，但两者最终汇聚到了一个压力点上——中层管理者。

盖洛普数据显示中层管理者敬业度持续下降：2023年30%，2024年27%，2025年22%。三年下降8个百分点，降幅居所有员工群体之首。AI不是中层倦怠的根源，而是加速器。

第二章：为什么中层是AI转型的瓶颈？

在企业AI转型中，我们反复观察到同一个现象：老板想转，基层能干，但推不动。障碍往往不在顶层战略，也不在一线执行，而在中间层——中层管理者。

根本原因：中层过去的生存根基被AI连根拔起

中层管理者的存在价值，在过去几十年里被定义为"解决信息不对称"——上传下达、协调资源、审核把关。当AI Agent能够以近乎零成本完成信息汇总、会议纪要、数据报表时，中层作为信息中转站的护城河就彻底坍塌了。

但这不意味着中层没有未来。恰恰相反，中层是AI原生组织中最关键的角色——只是需要彻底的重新定义。

传统中层 vs AI原生中层

传统中层的核心工作是管人、协调、传话，时间花在开会、审批、催进度上，产出报告、KPI、会议纪要，管理5-10个下属，核心能力是沟通、判断、人际关系，价值来源是信息差（我知道你不知道）。

AI原生中层的核心工作是打造AI Agent、带Agent完成业务，时间花在训练Agent、检查工作、修正错误上，产出N个正常运转的AI Agent，管理10-30个AI员工加少量人类，核心能力是业务建模、Agent训练、异常处理，价值来源是认知差（我能让AI做到你做不了的事）。

为什么必须是中层？

高层做方向决策，没精力带Agent，战略已占满带宽。基层要干活，没时间造Agent，执行任务占满工时。而中层既懂业务又有经验，天然适合带Agent——既理解业务逻辑又处于执行层面。

中层的独特优势：既懂业务怎么做，又知道哪里有坑。这正是训练AI Agent最需要的东西——不是写代码，而是把业务经验"灌"给AI。

为什么不能甩给IT部门？打造AI Agent的核心不是写代码，而是把"你对这个业务的理解"转化成Agent能执行的指令和规则。IT部门不懂业务——他们不知道销售什么时候该逼单、不知道项目经理什么节点要催交付。只有真正做过这件事的人，才知道Agent应该在什么场景下说什么话、做什么事。所以打造Agent本质上是在"教"AI做你自己的工作——这件事没人能替你。

第三章：中层转型的五个关键动作

第一：打造Agent——不是交给IT，是自己来

核心原则：谁做这个业务，谁打造这个Agent。销售中层打造AI销售，项目中层打造AI项目经理。

重要澄清："带Agent"不等于"手把手教AI"。这里需要厘清一个常见的误解——"带Agent"不是让中层每天逐条告诉AI"客户说A你回B、遇到C你选D"，那不是管理，那是把自己降级成了AI的数据录入员。

真正的"带Agent"是管理者思维：你定义目标，Agent自己探索执行路径；你审核结果，Agent自己分析错误并修正；你处理边缘决策，Agent把你能复用的判断沉淀为规则。随着Agent能力增强，人的角色从执行者向决策者迁移——不是在伺候AI，而是在放大自己。中层不是AI的保姆，是AI的直属领导。

第二：带着Agent干活——完整的实践闭环

最常见也最致命的错误：把Agent造出来，扔给业务部门，自己不管了。结果业务部门不会用、不敢用、不愿用，Agent被闲置，投入打水漂，"AI没用"的结论从此坐实。这不是Agent的问题，是"打造者不在场"的问题。中层必须亲自带着Agent进入真实工作场景，经历完整的"用-看-改-教"循环。

实践闭环四步法：

1. 派活——把真实工作任务交给Agent，不是测试用例，是真实业务。例如"帮我把今天群里的客户需求整理成项目任务清单，按优先级排序，推给对应负责人。"
2. 盯活——每天检查Agent的工作日志：今天做了什么？做得对不对？报了什么错？例如早上打开Agent日报，发现昨天的5个任务完成了4个，第3个任务Agent说"已完成"但实际没有推送消息——这就是要修正的点。
3. 纠错——发现错误不自己修，把错误截屏发给Agent，让它自己分析为什么错、怎么改。例如"你昨天任务3说已推送消息，但我检查发现实际没发出去。分析一下原因，修正后告诉我问题出在哪。"
4. 教新——Agent遇到处理不了的情况时，中层先介入处理，再把决策逻辑教给Agent。例如客户在群里问"你们明天能不能来人现场"，Agent不知道能不能承诺，中层拍板"可以，派小王去"，然后把判断逻辑写成规则。

第三：接受错误——不是追求零失误

一个深刻的认知转变——自动驾驶悖论：自动驾驶的事故率远低于人类驾驶员，但一旦出事，所有人都会要求严惩。不是因为自动驾驶更差，而是因为它在更短的时间内完成了更多工作，让人产生了"它更容易出错"的错觉。

AI Agent同理。它一天完成20个需求，错2个；人一天完成1个需求，错0个——你更容易记住AI的2个错误。这不是AI的错，是人类的认知偏差。

AI做任何事都是零时间，出错率可能比人低，但短时间内的大量产出会放大对错误的感知。中层需要学会接受"可接受范围内的错误"，把精力放在持续修正上，而不是追求完美。真正的门槛不是技术，而是心态——能不能容忍Agent偶尔犯错，像容忍下属犯错一样？

第四：规模化管理——从带5个人到管20个Agent

起步期（1-3个Agent）像带新人：亲手打造、逐个调试、贴身带。成长期（5-10个Agent）像带团队长：建立检查机制、批量训练、模式复制。规模化期（20+个Agent）像指挥官：自动化监控、异常升级、策略优化。

第五：深层理解——为什么"带着用"比"打造"更难

打造Agent是技术问题，带着Agent干活是组织问题。技术问题有标准答案，组织问题没有。这就是为什么很多公司做了Agent但用不起来。

打造Agent是一次性投入，有明确完成标准，像工厂造产品，IT部门可以帮忙，做完有成就感。带着Agent干活是持续投入、永不结束，永远在迭代、没有"完成"，像带下属成长，任何人都替不了你，过程琐碎容易放弃。

为什么很多人停在"打造完成"就止步了？第一，心理舒适区——打造是"做事"，带着用是"养人"，后者需要每天面对不确定性。第二，错误恐惧——Agent在真实场景中犯错，中层怕被追责，宁可不放出去。第三，时间错觉——觉得"我没时间每天盯Agent"，但没意识到，前三个月的投入会换来之后无数个月的解放。第四，认知陷阱——以为打造完等于完成，实际上打造完等于才刚刚开始。

一句话记住：打造Agent像生孩子，带着Agent干活像养孩子。生出来只是第一步，真正的功夫在"养"——而且是养一个永远不会累、不会辞职、能力越来越强的孩子。

第四章：内部的深层变革——权力、组织、人才

权力结构的重塑

当AI瓦解了信息不对称，传统中层的权力来源就全部失效了。过去的权力来自信息不对称、审批权、资源分配权、人事管辖权。未来的权力来自能打造多少AI Agent、能让Agent多高效、能把多少业务经验数字化、能带领Agent创造多少价值。

字节梁汝波在全员信中重申的"Context over Control"（优先共享业务上下文、弱化层级管控），正是这个趋势的注脚。在十几万人的组织里，这个理念落地有一个前提：企业的知识资产必须高度结构化，且能被AI系统有效分发。否则"Context"只会变成信息过载，一线员工无所适从。

组织架构重构：基础建设 vs 城市运营

核心判断：基础建设和城市运营要分离。基础建设团队负责上下文、向量数据库、超级个体、共享记忆——这是基础设施。城市运营团队（中层）负责打造并运营AI员工、带着AI完成实际业务——这是业务落地。

最危险的陷阱：谁培养下一代？

哈佛商业评论的研究者指出了这场变革中最被忽视的风险：在传统组织中，初级人员通过近距离观察中层管理者来学习。AI时代，技术任务被压缩，初级人员可以快速产出交付物，但判断力还没来得及培养——在学会判断之前，任务已经被AI代劳了。

AI加快了初级人员的产出，却抽空了从执行者到领导者的成长阶梯。短期看各家会持续筛选淘汰冗余中层；中期看过度压缩中层会带来连锁反应——跨部门协调缺失、短期激进冲业绩、人才培养断层；长期看行业可能会诞生一种兼具战略视野、一线洞察和AI落地能力的新型管理者。不是中层消失，而是中层的定义被重写。

需要区分两类中层

被淘汰的类型：只会上传下达、过滤信息、无独立业务判断——管控型中层。成为核心骨干的类型：能拆解长期战略、下沉一线、搭建人才梯队——价值型中层。

被压垮的中层和被淘汰的中层，不完全是同一批人。但两者的重叠度正在增加——那些只会上传下达的人，既承受不了AI时代的新负荷，也通不过新规则的筛选。

第五章：给中层的一句话

你不必成为程序员。但你必须成为AI的"直属领导"。你的竞争力不再是"我知道你不知道的"，而是"我能让AI做到你做不了的"。这不是可选的能力升级，这是生存的底线。

第六章：写在最后——外部已在行动，我们必须更快

这场讨论的起点，是一个疲惫的坦白："我真的力竭了，太多Agent都是我在带，我带不动了。"但恰恰是这个坦白，让我们找到了答案。

亚马逊在裁中层、字节在换尺子、美团在重建——不是雨花石在大惊小怪，而是全球趋势已经不可逆转。中层不应该被AI替代。中层应该成为AI的主人。

不是CEO来决定谁带AI销售、谁带AI项目经理。而是每个中层主动接过这个角色——打造你自己的AI团队，带着它们创造业绩。这才是AI原生组织真正落地的最后一公里。而我们已经在路上了。

参考资料

雨花石内部讨论：2026.7.9《AI原生业务落地与组织转型》。虎嗅：《字节、美团、亚马逊都在"收拾"中层，AI抽走了他们最值钱的东西》（2026.7）。哈佛商业评论：中层管理者在AI时代的真实处境研究（2026.6）。盖洛普：职场敬业度调研（2023-2025）。Business Insider：亚马逊裁员分析（2026.1）。

出品单位：北京雨花石云计算科技股份有限公司 | 官网 www.celnet.com.cn

作者：Panda Liu（CEO）| 白泽（AI助手）

日期：2026年7月10日 | 版本：V1.0