阅读原文

跳转微信打开

日常测试只能解决功能是否正确，但无法解决故障后能否自恢复

在专有云 IaaS 场景下，系统面临着节点掉电、磁盘故障、网络异常、GPU 掉卡等各类基础设施风险。这些故障不是可能会发生，而是“一定会发生”——关键在于系统能否在故障发生后自动恢复，而不影响业务连续性。

传统的混沌工程实践存在三个核心痛点：

• 前期 — 用例设计成本高：

  人工设计固定场景，重复劳动，经验散落在个人记忆中难以复用；真实故障往往是多场景叠加，人力无法穷举；各产品线各自为战，故障经验无法跨团队沉淀；故障实验缺乏随机性，难以覆盖真实的故障组合

• 中期 — 执行与诊断依赖人工：

  测试过程中数据采集不及时、不准确，难以获取全量准确数据；故障诊断高度依赖人工经验：手动查监控、读日志、判断根因，容易遗漏重要细节；恢复过程多次尝试，参与人多时协调困难，关联链路容易断裂

• 后期 — 分析缺失，结果难复用：

  缺乏完整的注入过程数据分析，关键细节容易遗漏；恢复过程难以形成标准化预案，无法复用到真实故障场景；人工恢复过程中的 hack 和临时方案无法沉淀为可复用的知识

与此同时，现有的混沌工程工具几乎都停留在“注入恢复”环节——注入后的观测分析、诊断定位、报告输出主要还是依赖人来操作，缺乏闭环。具体表现为：

• 数据监控和获取依赖人工或者编写脚本，耗时且难获取全量准确数据

• 数据依赖人工分析，遗漏重要细节

• 现存故障实验方案简单缺少可验证性，编排新的故障方案耗时耗力

这些痛点叠加起来，导致一个更深层的业务后果：韧性验证只能作为阶段性的专项演练存在，无法高频、常态化开展。 而故障不会等演练排期——真正的风险往往在两次演练之间的空档里，以线上事故的形式暴露给客户。验证频率上不去，系统韧性就始终是一个抽检结果，而非持续保障。

我们需要一种全新的范式：让 AI 驱动从触发到恢复的全链路闭环，而不是简单地用 AI 替代某个环节。 目标是让专有云 IaaS 产品具备故障后能否自恢复的自动化验证能力，从人工驱动升级为 AI Native 闭环。

对业务而言，这套系统的价值不在于“把一次混沌实验做得更快”，而在于把“系统故障后能否自恢复”这件事，从依赖专家经验的一次性人工判断，变成 可持续运行、可规模复制、可沉淀复用的平台能力。具体体现在四个层面：

高频、自动化的验证之所以重要，是因为它背后对应着两条真实的风险处置路径：

• 能修复的：定位并修复故障来源缺陷。

  高频验证会持续暴露系统在故障态、降级态、恢复态下的韧性缺陷，每发现一个可修复的根因，就通过工单闭环推动产品团队修复，从源头消除隐患。

• 暂时无法修复的：提前准备预案 + 全量客户排查，提前规避规模化风险。

  对于短期无法根治的架构性缺陷，提前沉淀标准化恢复预案；同时基于故障特征在全量客户环境中排查同类风险点，在问题规模化爆发前完成预警和处置，把“事后救火”变成“事前布防”。

单次验证闭环提效数十倍、人力从专职 SRE 全程投入降到仅做触发与确认。效率的数量级提升不只是省时间，更关键的是它让高频验证从奢望变成日常——只有当单次成本足够低，持续、大规模的韧性验证才具备可行性。

过去每次演练的用例设计、诊断思路、恢复手法都散落在个人记忆里，人一走经验就流失。平台把这些沉淀为结构化的故障用例库、诊断证据链和恢复预案，形成可复用、可传承的组织级韧性资产。

通过标准化的 Agent 接入协议，新产品接入像“插 USB 设备” 一样简单，平台无需为每个产品重写诊断、报告、编排逻辑。韧性验证能力得以从单个 IaaS 产品，快速复制到专有云的更多产品线。

明确了业务价值，接下来的问题是：为什么必须 AI Native，而不是用自动化脚本 + 传统混沌工具拼一套？因为混沌工程真正耗时的环节——方案生成、环境安全判断、异常观测、根因分析、恢复验证、报告闭环——都高度依赖上下文理解和专家经验，传统脚本只能解决“执行快一点”，却啃不动这些认知密集型环节。所以我们没有把 AI 当作一个辅助问答工具，而是把它放进混沌工程的核心链路，重新定义整条验证流程。

在动手之前，我们先定义了 AI Native 的三条硬性标准。这三条标准不是口号，而是方案设计和验收时的“北斗星”——任何一个环节是否达标，都回到这三条来检验。

落到可量化的验收目标上，就是：

• 替代人工执行与诊断：单 Case 全链路 0 人执行干预，人仅做触发与结果确认
• 大幅提升验证效率：单次闭环压缩到半小时以内
• 持续发现未知缺陷：主动发现架构韧性缺陷，而非被动暴露
• 闭环分析结果可复用：诊断报告完整覆盖注入全过程，恢复方案可沉淀为标准化预案

我们没有采用常见的单 Agent 方案，也没有直接在现有混沌工程工具上做自动化补丁，而是从头设计了一套多Agent 军团协作 + 自研 Harness 平台的架构。之所以选择多 Agent 而非单 Agent，核心原因有三：

• 混沌工程涉及注入、观测、诊断、报告、工单等差异很大的能力域，单一 Agent 的上下文窗口难以承载全部知识和工具；

• 多 Agent 天然支持分治和并发，每个 Agent 在独立上下文中执行，复杂度更可控；

• 多 Agent 架构允许不同团队各自负责自己擅长的 Agent（如产品团队负责诊断 Agent），实现真正的分布式协作。

整个系统围绕三个核心概念构建：

• Agent 军团

  多个 Agent 各司其职，按职责分为决策层、入口层、策略层、执行层、观测层、认知层、输出层、闭环层、知识层共九层，分层协作。每个 Agent 拥有独立的上下文窗口和工具集，避免单一 Agent 的认知过载

• 共享黑板

  这是 Agent 之间唯一的交互媒介。除指挥 / 哨兵 Agent 外，所有 Agent 通过黑板交换数据，互相不知道对方的存在。这种设计使得 Agent 之间完全解耦——可以随时增删 Agent 而不影响其他 Agent 的运行

• 双进化回路

  经验反馈回路（知识进化）+ AI 飞轮回路（权重进化），让系统不是静态的工具，而是越用越聪明的智能体

上层 — 触发与编排控制：多个触发来源（如 CICD等）经哨兵 Agent 统一归一化后，由指挥 Agent 基于状态机驱动全流程，并在关键节点执行安全闸门。框架层通过 Registry + 路由实现 Agent 的自动注册、心跳检活与统一路由——内部 Agent 走直接调用，外部 Agent 走 A2A 协议。

中层 — Agent 工作区：每个 Agent 配备三类能力，形成完整的能力三角：

• Tool（可执行工具）：Agent 能“做”什么，如执行命令、文件读写、黑板操作
• Skill（领域技能）：Agent 能“用”什么方法论，如异常检测算法、根因分析流程
• Knowledge（知识资产）：Agent 能“知”什么信息，如产品故障域定义、历史基准阈值

Agent 按归属分为两组：

• 内部 Agent（编排、执行、环境、报告、工单）：由平台开发维护，通过Dispatch 直调，直接读写共享黑板
• 外部 Agent（诊断、产品）：由接入的合作方 / 产品方独立部署，通过 A2A 协议交互

这种内外分离的设计，使得产品团队可以独立迭代自己的 Agent（如升级诊断算法），而不需要修改平台。

下层 — 基础设施层：六大模块横向支撑整个系统运行

• 工具层：环境注入执行器、文件操作等基础工具
• 监控与告警：通过 Skill 接入产品自有监控等
• 协作与工单：Bug 工单创建、查询、追踪全链路
• 知识平台：支持文档向量化 → MCP 语义检索输出
• AI 能力：主模型为 Qwen 系列，同时支持 OpenAI / Anthropic 双协议，上层 Agent 代码无感知切换
• 数据存储：Redis 为共享黑板基座

黑板是整个系统的“中枢神经”——所有 Agent 的输入输出、实验状态、诊断结论都通过黑板流转。基于 Redis Hash 实现，字段按职责分为四大类：

• 实验元数据：experiment_id、product_id、状态机当前状态、触发来源等
• 业务数据：product_profile、case_config、baseline 数据、流式采样结果等
• 输出与反馈：诊断结论、实验报告、action_recommendations、evolve_strategy 等
• 调试与审计：LLM 调用记录、Agent 执行轨迹、错误日志等

关键设计：Agent 之间互不知道对方的存在，只需要知道黑板的数据结构。 这意味着可以随时增删 Agent 而不影响其他 Agent。新增一个 Agent，只需要让它读懂黑板上它关心的字段，并将自己的输出写入约定字段即可。

并发安全方面，通过 Lua 原子写入 + 乐观锁（version 字段）保障多 Agent 同时写入时的一致性。当 version 冲突时，写入方自动重试，确保数据不会丢失或覆盖。

实时性方面，黑板支持SSE 字段变更推送——任何字段被修改时，前端和订阅方 Agent 都能实时收到通知，无需轮询。同时通过按角色的读写隔离（Redis ACL），确保每个 Agent 只能写入自己负责的字段前缀，防止越权操作。

这是我们最核心的设计——9 个（目前）Agent 按职责分层，形成完整的故障验证闭环。之所以设计为多个Agent，是因为每个 Agent 的能力域差异很大：注入需要环境连接和进程控制能力，诊断需要监控分析和根因推理能力，报告需要结构化生成能力——这些能力很难塞进一个 Agent 的上下文窗口而不互相干扰。

每个 Agent 都通过 JSON 卡片（AgentCard）标准化暴露自己的能力，包括 capability_id、输入输出 Schema、安全等级和超时配置。这使得平台具备通过统一的协议调度和发现 Agent 的能力，而不需要硬编码的调用关系。

设计亮点：

• 权限分层：只有执行 Agent 拥有破坏性操作权限（环境变更），其他 Agent 只能读写黑板和文件，从工具层面防止误操作
• 内外分离：内部 Agent 通过 Dispatch 直调，低延迟、高可控；外部 Agent 通过 A2A 协议交互，支持跨团队独立部署和迭代
• 上下文隔离：每个 Agent 在独立上下文中执行，避免单一 Agent 上下文过长导致的 LLM 质量下降

一次完整的混沌工程实验，经历四个阶段。整个过程由指挥 Agent 基于状态机严格驱动，每个阶段转换都伴随安全闸门校验和黑板状态更新，前端通过 SSE 实时展示当前进度。

1. 阶段一：任务发起与编排，哨兵 Agent 接收触发事件（手动 / CICD Hook / 定时任务等）后，将其标准化为统一的触发事件结构，指挥 Agent 随即启动编排流程：

2. 阶段二：预检与监控，这个阶段的核心目标是 “确保注入环境是安全的”——避免在已经有问题的环境上叠加故障，导致不可控的影响。此时执行环境预检、基线采集，并做出最终预检决策（通过则进入注入阶段，失败则中止并返回详细错误信息）。

3. 阶段三：注入与恢复：这是整个实验的核心阶段——故障注入、实时观测、安全恢复，全程由 Agent 自主完成。

4. 阶段四：故障报告，实验结束后的分析和闭环阶段，全部由 Agent 自动完成——从根因分析到工单创建，无需人工介入。

实验完成后，指挥 Agent SSE 广播完成事件通知前端，并触发各 Agent 异步反思。

混沌工程最重要的原则是严格圈定故障范围，避免影响扩大——虽然是在研发环境故意制造故障，但是一旦失控后果仍较为严重（如影响其他产品研发调试等）。我们设计了三道递进式安全闸门，每一道都是决策点：

• 第一道：参数校验

  确保注入参数是真实的、范围是最小的、环境是可验证的。环境白名单硬规则不受任何开关控制，即使 LLM 判断通过也不能绕过。这道闸门的核心目的是防止在不该做实验的环境上做实验

• 第二道：安全预检

  破坏性操作白名单 + 双签确认，爆炸半径评估，黑名单检查。只有经过审批的故障类型 + 环境 + 产品三元组才能执行。这道闸门还会检查最大并发数、历史失败率等指标，确保实验风险可控

• 第三道：恢复判定

  注入后基于基线数据对比确认系统可安全恢复，防止在系统已经异常的情况下继续注入。恢复判定不仅检查注入目标的恢复状态，还要确认整个集群的健康度没有受到连锁影响

除了三道闸门，还有多层安全机制贯穿全流程：

• 破坏性操作:强制双签确认——执行 Agent 是唯一拥有环境变更权限的 Agent，其他 Agent 无法直接执行注入
• 安全逻辑：内嵌各 Agent 而非外挂模块（安全左移）——每个 Agent 在自身决策流程中就包含安全检查，而不是事后审计
• 紧急停止机制：随时可通过前端按钮或 API 调用取消进行中的任务
• 权限控制矩阵：不同层级的 Agent 拥有不同的工具权限，指挥 / 编排 / 报告等 Agent 只有文件读写和黑板操作权限，只有执行 Agent 拥有环境变更权限
• LLM 并发限流：控制并发 LLM 调用数，防止 API 429 限流导致系统不稳定
• 状态机严格校验：9 正常状态 + 1 异常状态（failed），任何活跃状态可转 failed，complete/failed 为终态，确保流程不会进入不可控状态
• 分派权限控制：通过配置 dispatch_rules.json定义每阶段可调度的 Agent 白名单，防止 Agent 在不该被调用的阶段被调用
• 操作人权限控制：通过接入内部权限控制，仅对特性人员开放操作权限

这是区别于传统混沌工程工具的核心差异化能力——两条回路进化的对象完全不同：一条进化知识（用例怎么编排更准），一条进化权重（哪些故障场景更值得反复验证）。

回路一：经验反馈回路 —— 让「用例知识」越用越准

1. 诊断 Agent 完成根因分析后，输出正常 / 疑似缺陷 二态判定，附带完整证据链

2. 产品 Agent 依据判定结果，决定该次实验方案是否有价值 → 写入用例库

3. 下一轮实验发起时，编排 Agent 优先从用例库扫描匹配用例，命中则直接复用注入/恢复命令和监控配置，未命中才回退到 LLM 模板生成

4. 进化效果：随着实验轮次增加，用例库覆盖的故障场景越来越多，命中率持续提升，方案生成从现场生成逐渐变为检索复用

回路二：AI 飞轮回路 —— 让「编排策略权重」越用越精

1. 报告 Agent 生成实验报告时，附带结构化的行动建议（如建议创建工单）

2. 工单 Agent 据此创建 Bug 工单，并持续跟踪该缺陷的修复进度和结果

3. 修复结果回传给编排 Agent：如果确认是真实缺陷且修复生效，说明这类故障场景验证价值高；如果是误报或已知无效注入，说明验证价值低

4. 编排 Agent 据此调整不同故障类型/参数组合的编排权重

5. 进化效果：低价值场景（误报、重复无效注入）权重下降、逐渐被抑制，高价值场景（真实缺陷高发区）权重上升、被更频繁验证，编排决策逐轮向高发现率收敛。

另一个重要设计理念是 “新产品接入应该像插 USB 设备一样简单”。传统混沌工程工具每接入一个新产品，都需要定制 attack 定义、监控适配、报告模板等大量工作。而在我们的架构中，产品接入被分解为两个角色的标准化工作：

产品接入方 — 聚焦A2A能力实现：

1. 定义 AgentCard：编写标准化的能力声明 JSON，包含 Agent 名称、描述、所有 capability（含输入输出 Schema、安全等级、超时配置）
2. 实现三个 HTTP 端点 + 业务逻辑：能力描述 GET /agent_card、JSON-RPC 2.0 调用 POST /api/{capability_id}、健康检查 GET /health
3. 心跳健康检查：注册后心跳保活
4. 产品 Agent 能力（领域知识）：如产品方有了自己的现成的 Agent，直接参考 A2A 协议接入平台即可；如无产品 Agent，需要实现产品 Agent 能力；

平台方 — 聚焦接入支撑：

1. Registry 注册 + Redis ACL 配置：为外部 Agent 创建专用 ACL 用户
2. 路由 + 白名单 + dispatch 规则：确保指挥 Agent 在正确阶段调用正确的外部 Agent
3. 监控适配：根据产品需求适配监控采集 Skill

核心原则：双方通过 A2A 协议 + 共享黑板实现解耦协作。产品方聚焦“能力实现”，平台方聚焦“接入支撑”，中间通过标准化协议衔接。

接入节奏：新产品接入时，产品方提供基础故障用例，包含注入 / 恢复命令和预期表现、监控等（可由产品方 Agent 生成），运营期通过 AI 飞轮持续积累，逐步扩大用例规模。

我们联合了存储团队进行工程共建，实现内外部Agent的故障注入实验流程闭环。自项目启动至今，已完成大量实验，覆盖单点故障、多点故障、网络异常、磁盘故障、服务故障等多种场景。

以下数据对比传统人工混沌工程流程与 AICP 平台的全链路自动化流程：

其中最关键的变化是人力投入的质变：过去每次混沌工程实验需要 SRE 全程参与——手动注入、盯监控、读日志、写报告、提工单，现在人只需要做两件事：触发实验和确认结果。同时截止文档发布，已经发现多条产品稳定性问题并向负责的产品团队提交了缺陷详情和复现方式。

目前平台还在持续进化中。

下表从六个维度对比了我们的方案与业界主流混沌工程工具（Chaos Mesh、ChaosBlade、Gremlin 等）的差异：

当前混沌工程平台已在存储产品上跑通了有限的端到端闭环，但这才刚刚开始。以下是我们正在规划和探索的方向：

• 智能记忆系统

  更智能的自动判断和知识沉淀，让系统不仅能记住 “做了什么”，还能理解 “为什么这样做” 和 “下次应该怎么做”。当前的知识回路已经实现了基础的案例入库和策略进化，但记忆和知识库的边界还需要进一步探索——哪些知识应该固化为 Agent 的长期记忆，哪些应该作为临时上下文在实验结束后清理。

• 运维场景拓展

  从故障注入扩展到升级等运维操作场景，支持多故障并行注入，验证运维操作的韧性。升级、迁移等运维操作往往比故障注入更复杂，涉及多步骤、长时长、多组件协同，AI Agent 军团在这些场景下的价值将更加显著。

迁移不是自动化，而是互补。 自动化意味着替代，互补意味着各自做不同的事。AI 并不是复制人类认知，它提供的是另一种能力：模式匹配、规模、速度。人类擅长的是问题界定、品味判断和伦理推理。这种不对称很重要。

在混沌工程领域，AI 不会替代 SRE 的经验判断，但它能把 SRE 从重复的 “注入 - 盯盘 - 写报告” 中解放出来，专注于更有价值的架构韧性决策。

把 AI 当成 “我会做的事它替我做”，那叫认知卸载，它适合语法、格式、记忆这类负担。但如果你把 AI 当成“我不再需要理解这件事”，那就变成了认知外包，危险也从这里开始。认知栈迁移保留的，正是这种差异化：让机器做机器擅长的，人类守住不能被外包的判断。

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

今日，阿里巴巴千问图像生成模型Qwen-Image-3.0正式上线千问AI平台，面向所有用户全部开放。

旗舰版Qwen-Image-3.0-Pro与标准版Qwen-Image-3.0-Standard同时开放API，文生图0.18元/张起。API已在千问AI平台上线，海外用户可通过Qwen Cloud接入。在国际评测平台Arena.ai最新文生图榜单中，Qwen-Image-3.0位列国内第一。

4.5k token长指令，复杂版面一次生成

Qwen-Image-3.0支持最长4.5k token的指令输入，报纸、分镜、试卷、菜单等复杂版面可一次生成。例如一张3.7k token的九宫格知识信息图，可将数学、物理、文学、医学、金融等九个领域内容同屏排列。

3.7k token 九宫格知识信息图，一次生成

画中画：编程界面→千问对话界面→聊天界面→咖啡海报

细节还原，10px小字可辨

10px小字清晰可辨，整页代数几何学术论文的LaTeX公式、上下标和定理编号可逐一还原。人像方面，毛孔、发丝和微表情经得起放大查看，皮肤质感接近实拍照片。模型还能以与原画一致的笔法修复破损古画。

整页代数几何学术论文，LaTeX 公式逐一还原

人像：毛孔、发丝、微表情经得起放大看

破损古画修复前后：笔法一致，去霉斑、补残缺

支持12国语言原生渲染与100+种艺术风格

除中英文外，支持日语、韩语、阿拉伯语、法语、俄语等12国语言和20+字体的原生渲染，覆盖100+种艺术风格。模型内置世界知识，还支持联网获取最新信息。

韩语原生渲染

主流网页、游戏、直播界面仿真生成

邀测期间，用户已将模型接入多种工作流：电商场景用于商品图和家装效果图生成；短剧与影视用于分镜故事板生成，镜头、动作、台词逐格标注；广告营销用于海报和科普图鉴制作；建筑设计用于户型渲染和风格迁移。

双版本定价

• Qwen-Image-3.0-Pro（旗舰版）： 复杂版面、精准文字、商业级画质。1K分辨率0.25元/张，2K分辨率0.5元/张

• Qwen-Image-3.0-Standard（标准版）： 大批量日常生成。1K/2K分辨率均0.18元/张

• 图像编辑： 输入每张0.02元，输出同文生图价格

立即体验：

千问AI平台：

https://platform.qianwenai.com/try-ai?scene=image&models=qwen-image-3.0-pro

Qwen Cloud：

https://www.qwencloud.com/try-ai?scene=image&models=qwen-image-3.0-pro

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

在这个例子的整个开发链路中，需要用户手动输入的需求描述总计在200个字符以内。整个流程中的执行和决策是分开的：人负责决策，AI加持的系统负责执行。任务的开发周期从天级缩短至分钟级，显著提升了整体研发效率。

xxx_time_10wmr_cap_xxx
  ├─ xxx_time  ← dwd_{source a}_.xxx_time
  ├─ xxx_pv/xxx_pv   ← dwd_{source b}_di.type
  └─ xxx_level   ← ldm_xxx_info（维表）

{
  "hooks": [
    {
      "hookType": "FILTER | DIMENSION_TRANSFORM",
      "layerType": "SOURCE | VIEW | TARGET",
      "nodeId": "source_001 | tmp_view_001 | target_001",
      "mergeStrategy": "REPLACE | APPEND_AND | APPEND_OR",
      "filterExpression": "仅 FILTER 类型时填写",
      "dimensionName": "仅 DIMENSION_TRANSFORM 类型时填写",
      "expression": "仅 DIMENSION_TRANSFORM 类型时填写",
      "reason": "简要说明为什么这样做"
    }
  ]
}

阅读原文

跳转微信打开

今日，阿里巴巴新一代基座大模型Qwen3.8 正式发布，千问AI平台同步首发上线Qwen3.8-Max的API服务与Token Plan，面向开发者与用户全面开放新模型调用。

Qwen3.8总参数量2.4万亿，在编程（Coding）和专业协作（Cowork）方面能力大幅提升，整体性能处于全球大模型前列。得益于模型架构、后训练方案和软硬一体化的协同创新，Qwen3.8在实际推理中能以更快的速度产出智能，可以独立自主编程16天，全程稳定可靠。

目前，Qwen3.8-Max的API服务已首发上线千问AI平台，全球开发者可直接调用，国内每百万Tokens输入12元、输出36元，隐式缓存命中仅1.5元，而输入与输出的国际价格仅为Opus5的40%与24%，实现相近智能更高性价比。在构建Coding Agent、搭建多模态应用以及接入企业级智能体流程等场景，开发者都能通过千问AI平台一站式获取模型能力，灵活适配各类主流智能体框架。

千问AI平台也为Token Plan用户带来Qwen3.8-Max 的专属限时优惠：夜间时段使用新模型享5折Credits消耗；8月5日前所有已购买个人版Token Plan的用户本周可获取1次7天额度重置权益。

Qwen3.8-Max模型体验地址：

千问AI平台：

https://www.qianwenai.com/models/qwen3.8-max

QwenCloud：

https://www.qwencloud.com/models/qwen3.8-max

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

2025 年 1 月，Scale AI 和 CAIS 联手出了一张很难的试卷。

Scale AI：一家美国 AI 数据基础设施公司，总部在旧金山，核心业务是为大模型训练和评测提供高质量数据标注、RLHF 反馈、以及评测基准设计。OpenAI、Meta、美国国防部等都是它的客户。可以理解为"AI 行业的考试出题公司 + 数据外包巨头"。

CAIS：Center for AI Safety（人工智能安全中心），一个非营利研究机构，关注 AI 对齐、灾难性风险等议题。2023 年那封"AI 可能带来灭绝风险"的公开声明就是他们牵头组织的。

它叫 Humanity's Last Exam（简称 HLE）[1]，人类最后的考试。

当时，大模型行业最常用的“高考”MMLU 已经没有区分度了，头部模型分数都基本接近满分。

MMLU[2]：Measuring Massive Multitask Language Understanding（大规模多任务语言理解评测）。它用 57 个学科、约 1.6 万道选择题，测试模型在数学、历史、法律、医学、伦理等领域的知识和推理能力。

于是出题人找来全球专家，征集近 2500 道研究生以上难度的题目，横跨数学、物理、法律、哲学等学科。每一道题都故意设计成搜索引擎查不到答案。

刚发布时，最强模型正确率不到 10%。

按理说，这张试卷应该能够撑很久。但仅仅一年半后，在公开榜单[3]口径下，HLE 榜首的正确率，已经从不到 10% 涨到 50% 以上。

比较辛酸的是，HLE 的核心组织者之一 Dan Hendrycks，正是五年前 MMLU 论文的第一作者。

同一个人，出的第一张卷子已经被遗弃。于是他出了第二张更难的试卷，然而在可以预见的未来，第二张试卷也会被淘汰。

这不是 HLE 的失败，而是所有评测的命运。

模型“好不好用”，其实很难直接测。

所以行业只能找近似指标。用一个可以观测到数字，去近似回答：这个模型到底有多强，能帮上我多少忙。

但近似指标天生有一个问题：它用久了就会开始失真。这就是古德哈特定律。

英国经济学家 Charles Goodhart 在 1975 年讨论货币政策时，写过一句后来被反复引用的话：

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes

任何稳定的统计规律，一旦被拿来当控制目标，就会开始崩塌。

它原本讲的是央行和货币指标：政策一旦盯住某个数字，市场参与者就会围着这个数字行动，原来的规律反而不成立了。

后来，人类学家 Marilyn Strathern 把它改写成更流行的版本：

When a measure becomes a target, it ceases to be a good measure.

当一项指标成为目标时，它就不再是一项好的指标了。

俗话说得好，就是：上有政策，下有对策。放到模型评测里，就很好懂了：

下面四代模型评测的区分，只是个人为了方便进行分类。事实上它们出现的时间是互相重叠的。

2020 年，GPT-3 刚发布，行业第一次迫切地想知道：GPT-3 到底有多聪明？

于是 MMLU 出现了，后来 GSM8K、HumanEval 等评测集接连出现。但固定考卷有两个致命问题。

• 背题。题目公开后，就可能进入训练数据。模型分数高，不一定是它真会解，也可能只是见过题、记住了答案。这时候分数测到的更像记忆力。

• 满分。题目难度固定，模型能力却一直上涨。最后大家都是满分，难分高下，考卷就失去了存在意义。

HLE 就是在这个背景下出现的：旧卷子不能用了，那就换一张更难的。这当然有用，但是不能一劳永逸。

2023 年，UC Berkeley 的 LMSYS 团队上线了 Chatbot Arena，也就是后来的 LMArena[4]。

UC Berkeley：加州大学伯克利分校（University of California, Berkeley），美国顶尖公立研究型大学，计算机和 AI 领域非常强。

LMSYS：全称 Large Model Systems Organization 的缩写，一个由 UC Berkeley 师生发起的开源研究组织，主要做大模型评测和基础设施方面的工作。

玩法很简单：用户随便提问，系统匿名展示两个模型的回答，用户投票，平台用类似 Elo 的方式给模型排名。

Elo：最早是国际象棋的排名系统，由物理学家 Arpad Elo 发明。核心思路很简单：不靠绝对分数，靠"跟谁赢了谁"来衡量实力。打个比方，你赢了一个高手，加分多；赢了一个新手，加分少。反过来，输给高手扣分少，输给新手扣分多。每场比赛后双方的分数都会根据对手强弱和胜负结果做调整，打多了之后分数就趋近于真实水平。

这个设计很巧妙。题目由真实用户实时生成，模型根本无法背题；此外它还能直接知道用户的喜好。

Chatbot Arena 很快成了行业最受关注的榜单之一。模型发布会开始引用 Arena 分数，厂商也开始围绕它调模型。

然后问题来了。

一些模型针对人类评估者的偏好做了优化，比如多用列表、控制回答长度、加表情符号等。这些技巧不影响模型实际能力，但确实能让评估者更倾向投票给它。

2023 年 10 月，普林斯顿团队发布了SWE-bench[5]。

SWE-bench，全称 Software Engineering Bench，软件工程基准测试。

它不再问模型选择题，也不让用户投票，而是从 GitHub 上拿真实 issue：模型要读懂整个代码库，定位问题，写出补丁，然后跑项目测试。测试过了，才算修对。

SWE-bench 的巧妙之处在判分。它把测试分成两类：FAIL_TO_PASS 和 PASS_TO_PASS。

• FAIL_TO_PASS 是那些在原始代码上会失败、修复后应该通过的测试。它们用来判断模型有没有真正修掉 bug。

• PASS_TO_PASS 是那些原本就能通过、修复后仍然应该通过的测试。它们用来判断模型有没有为了修一个 bug，把别的功能改坏。

这已经比选择题真实很多。但这类评测也有自己的边界。

SWE-bench 再真实，测的也是 GitHub 开源项目里的 issue。你的业务可能完全不是这样。

它测的是真实任务，但不一定是你的真实任务。

2025 年开始，评测方法又升级了：不只看“模型怎么回答”，而是看“系统能不能办事”。

OpenAI 发布 BrowseComp[6]。它包含 1266 道 “难找但容易验证” 的网页检索题：答案通常很短、相对唯一，但问题被反向构造过，靠一次搜索很难命中。模型必须自己规划搜索词、打开网页、交叉验证线索，最后给出那个短答案。

Terminal-Bench[7] 则把模型扔进真实终端，每个任务通常包含自然语言指令、Docker 环境、参考解法和测试脚本。模型要在沙箱终端里自己执行命令、读文件、改代码、安装依赖、跑测试，最后由脚本判断任务是否完成。

但 Agent 评测也带来一个朴素问题：贵。

一次完整链路评测涉及多轮模型调用、多次搜索和工具执行，成本是固定考卷的几十倍。成本高意味着样本量小，样本量小结果就不稳定，排名可能只是统计涨落。

它的复现也麻烦。工具版本、网页状态、终端环境、依赖、上下文等只要有一个变了，结果就可能不一样。

它们看起来各不相同：选择题、盲测、真实任务、Agent 工作流。其实背后都是古德哈特定律的不同显影：

所以现在模型的排行榜只能做参考，它能回答这个模型大概在行业里什么位置。却无法保证处理你的任务效率会更高。

规避古德哈特最直接的办法不是再找一张更难的卷子，而是用自己真实题目来评测模型。

公开榜单能给你一个行业坐标。自己的测试集，才能告诉你这个模型能不能进流程

你可以有意识地收集自己遇到的、模型难以解决的问题，作为一个测试集。

以我为例，为了方便构建测试集 jsonl，我用 AI 写了个 chrome 插件，我在表格里面输入，它自动给我把数据同步到一个 jsonl 里面。

下面是利用本文语句生成的测试集。

它会转换为如下格式的 jsonl：

{"prompt": "不改变原意的基础上，优化如下语句让它更顺口：「这张卷子，够难，够新，够用好多年。」", "completion": "这张试卷应该能够撑很久。"}
{ "prompt": "不改变原意的基础上，优化如下语句让它更顺口：「同一个人，先做出一张后来被刷满的卷子，又做出一张更难的新卷子，然后看着它也开始被追上。」", "completion": "同一个人，出的第一张卷子已经被遗弃。于是他出了第二张更难的试卷，结果第二张试卷离被淘汰也不远了。"}

其中 prompt 是你给模型的输入，completion 是你期望模型的输出。

这样的数据集，便可以交给大部分市面上的模型平台，做到对模型的评测。

收集这个数据集，如果只是做模型评测，好像有点小题大做。

但仔细看会发现，数据集里的内容其实就是你期望的输出，换个格式就能直接当 few-shot 用。

一鱼两吃：出新模型时拿它当测试集，日常工作中拿它当 few-shot 增强模型能力。

AI 模型公开榜单只能给出行业坐标，无法保证模型在你的业务场景上也好用。

最务实的做法是用自己真实遇到的难题构建测试集来评测模型，这套数据同时还能作为 few-shot 增强模型能力。

参考链接：

[1]https://agi.safe.ai/

[2]https://github.com/hendrycks/test

[3]https://dashboard.safe.ai/

[4]https://lmarena.ai/

[5]https://github.com/SWE-bench/SWE-bench

[6]https://openai.com/index/browsecomp/

[7]https://github.com/harbor-framework/terminal-bench

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

目前，月之暗面旗下旗舰模型Kimi K3官方API已正式上线阿里千问AI平台，开发者可在模型市场直接调用该模型的API。

Kimi K3是一款2.8万亿参数的开源多模态大模型，基于KDA混合线性注意力机制（Kimi Delta Attention）和注意力残差（Attention Residuals）技术构建，原生支持视觉理解，拥有100万token上下文窗口，面向长程编程、知识工作和推理等前沿智能场景设计。

开发者可在千问 AI 平台的模型市场、阿里云百炼模型广场内直接调用Kimi K3 官方 API，无需自行部署即可将该模型集成到自身应用中。

立即体验：

千问AI平台模型市场

阅读原文

跳转微信打开

亲爱的读者朋友们：

大家好！

当 AI 从工具进化为伙伴，当 Agent 开始独立思考、协作与创造，我们正共同迈入一个由智能重新定义的新时代。为了更好地站在这股浪潮的前沿，聚焦大模型与 Agent 等前沿技术演进，为大家带来更具深度与前瞻性的 AI 内容与服务，原"阿里云开发者"微信公众号即日起正式更名为"千问AI平台"。

此次更名不仅是名称的改变，更是我们服务内容的全面升级。依托千问强大的模型能力与阿里云深厚的技术积淀，“千问AI平台”将致力于：

深耕AI前沿：第一时间分享大模型技术突破、行业应用案例及最佳实践。

赋能开发者：提供更丰富的AI开发工具、教程及社区支持，助力每一位开发者在AI浪潮中乘风破浪。

构建生态连接：搭建技术与场景的桥梁，探索AI赋能千行百业的无限潜力。

感谢您一直以来的陪伴与支持。未来，“千问AI平台”将继续秉持初心，以更优质的内容、更专业的视角，与您共同见证并参与AI时代的每一次变革。

让我们携手共进，智启未来！

千问AI平台

2026年7月23日

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

node .skills/alibabacloud-agentloop-experience/scripts/search_context.js search \
  --query "排查 ECS SSH 连接超时的历史经验" \
  --context-type experience \
  --confirm-outbound

返回 JSON 且 
error
 为null
，说明召回链路已经连通。results
 为空表示暂时没有匹配经验，并不代表接入失败。

观测 → 轨迹 → 挖掘 → 经验 → 召回 → 运行 → 再观测

企业可以观察成功率、同类任务多次执行的稳定性、Token/成功任务、工具调用次数、平均耗时和人工接管率，确认经验库带来的真实收益，并逐步扩展到更多 Agent 和业务场景。

参考链接：

[1]agentloop.console.aliyun.com

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

在聊2.0之前，先看看当前面对的局面。

1.0 端到端体系从25年12月开始建设，是基于Spec + Harness框架的需求生成模式。

整个链路聚焦在了能从需求按规范稳定的生成代码

这个过程在大部分应用沉淀了较充分的规范约束和技能（constitution、rules、skills），但本质上是"人操作Agent执行"——人是主角，在用Qoder、Cursor、CC等工具驱动Agent干活。

到今天，绝大部分需求在已经走Spec驱动的代码生成，但快起来之后问题也集中爆发了。

• 质量检查跟不上了 - Agent哗哗出代码，一个CR动不动几万行，但没有经过系统性检查，谁也不敢直接上线，最后还是要人逐行review、手动兜底。

• 信息处理的成本没有降低 - PRD的规范还没指定，Agent不能拿着要素缺失的需求就开始干，人还是得做澄清补全。更关键的是，信息从上游传到下游，每经过一个环节就会衰减——测试要看SRE保障需求，SRE要看研发变更影响，下游的各类要求没有一开始就确定，还是靠人来缝缝补补。

• 干复杂度高的事就像在抽卡 - 简单聚焦的事情，当下模型能处理得很好；但一旦复杂度升高、需要拆解分段来做就容易走偏。干到一半上下文丢了，模型偶尔还会随机"降智"，本该一步到位的逻辑有时效果很好，有时被拆得七零八落，最终又得靠人来缝缝补补。

• Top模型活干得好但太贵太脆 - 之前一直在用Opus和Codex作业，效果确实好，但动不动封号、服务不稳定、价格贵得离谱还随时可能被断供，不可能把整条生产线全押在上面。

• 是真的害怕带着Mac进电梯 -  人工本地跑Qoder、QoderWork，一断网会话就得重开—— 流水线全靠一个人在按电钮，网一断人离开整条线就停了，重启的credits如雪花般消逝。

• 没有人在看执行过程到底做得如何 - 每个Spec需求、每个应用、每次执行过程，重复遇到了多少问题？花了多少不该花的token？这些没有系统性的检查和反馈，出了问题靠人复盘，优化靠人经验。

一个工厂引进了最先进的数控机床，但质检靠目测、衔接靠人喊话、出了问题靠经验排查，关键设备随时可能被断供，而且整条产线只能在一台个人电脑上跑——车间还是手工作坊的管理方式。

我的判断是：AI Coding的真正瓶颈不是模型能力，而是缺少一套像工业流水线一样的交付体系。

回顾工业化的演进史，每一次跃迁的背后都有一条暗线：新的驱动力 + 新的生产组织方式。蒸汽机推动了工业1.0，电气化和流水线定义了工业2.0，电子信息和自动化带来了工业3.0，数据和智能正在催生工业4.0。100年前亨利·福特把汽车制造拆解成一条流水线——每个工位有明确的输入、输出和质检标准，零件沿着传送带流动，最终组装成一辆完整的车。这个思路不仅改变了制造业，也成为后来所有大规模生产的原型。

今天，信息和智能正在驱动软件工业化的下一次跃迁。我们逐渐意识到，好的交付体系应该做到：每个阶段有明确的产出物，每个产出物有质量卡点，整个过程可追溯、可验证、还能持续自优化。更重要的是，这套体系不能建立在对顶级模型能力的依赖上，就像成熟的工业流水线不会要求每个工位都是博士，而是靠工艺标准和流程设计让普通人也能稳定产出合格产品——好的交付体系应该让非顶配的模型也能在约束下可靠地完成工作。所以我们对端到端的交付体系提出一个设计原则：基于相对成熟模型的能力下限去设计、稳定安全优先、可持续有效输出、成本可控。

这里要厘清一个边界：模型能力下限的升级是模型团队的问题，端到端交付体系是我们自己的问题。 我们确实依赖模型能力，但不能把所有赌注都押在"等模型更强"上。模型在进步，那是它的课题；怎么在现有模型能力下把交付做稳、做快、做可验证，这是我们的课题。端到端交付体系要解决的是：怎么约束产出质量、怎么组织生产过程、怎么做阶段性质检、怎么驱动持续优化。把这两件事分开，我们才能专注把自己的体系建好，而不是天天追着模型版本跑。

这篇文章，是正在实践的——《端到端交付2.0体系》。

2.0 端到端体系从今年4月启动，走两轨并行：

• 第一轨：Agent自动化生产——云上Agent分身 + 钉钉，让非研发角色（产品、运营）也能直接提需求，系统自动走完全流程交付。目标是"分身全自动执行"，解除并发瓶颈，人从操作者变成监督者。

• 第二轨：端到端2.0新规范——工业流水线式的多Agent作业体系，定义从PRD到上线的全链路规范，包括Harness约束体系、Spec生产流程、自检机制、持续优化飞轮。

两轨的关系是：自动化生产先用1.0体系并行建设，同时2.0新规范体系在平行推进；等2.0规范体系成熟后，自动化生产轨道最终切换到2.0体系上来。简单说，1.0是当前的生产力，2.0新规范是升级后的生产力，自动化生产是跑在上面的业务目标——先骑旧车赶路，同时造新车，新车造好了就换过去。

2.0体系的核心架构可以拆成两条链路来看：正向链路和反向链路。

正向链路是生产过程，Agent贯穿全链路：

• 产品Agent：生成PRD，输出PRD文档和质检记录

• 设计Agent：生成技术方案，输出Spec（spec.md + plan.md）

• 编码Agent：生成代码，输出分批次tasks

• 自检Agent：生成自检报告，输出check_reports + ADR

• 测试Agent：生成测试用例并执行，输出用例与执行报告

反向链路是改进过程：阶段产出物检查 + Session log分析 → 发现问题 → 反哺物料优化和规则迭代。

这个架构有三个核心特征，可以概括为"三可"：

可追溯：需求id贯穿全链路——从PRD到代码到测试，一个aone_id串起所有产出物。Spec文档放在研发统一过程链里，任何时候都能回溯一个需求是怎么从一句话变成一段代码的。

可验证：研发自检 + 平台扫描，多重过程检查。不是等到上线后才发现bug，而是在流水线的每个阶段都有质检卡点。

可优化：Spec内容 + Session分析反哺物料优化、规则迭代。这不是一条静态的流水线，它会自己"长"——每一次执行都会留下session log，分析这些日志能发现物料缺陷和规则盲区，然后迭代优化。

还有一个贯穿所有Agent的关键架构原则：本地可执行 + 平台在线执行的双轨设计。 端到端体系中的每一个Agent——无论是编码Agent、自检Agent还是统计&Loop扫描——都必须同时支持两种执行方式。日常情况下，研发同学可以在本地的Qoder、QoderWork上直接跑、看结果、调物料，迭代效率最高；但最终的正式执行必须在组织平台的Agent上跑——平台有完整的执行记录采集、统计归集和合规审计能力，确保产出物的可追溯性和权威性。这就像本地开发环境可以随便调试，但代码合并必须走CI/CD流水线一样。

端到端交付这个课题，拆解成了7个子课题：

必选5个（构成主链路闭环）：Coding Agent、PRD生成&质检Agent、研发自检Agent、测试Agent、统计&Loop工程。这五个串起来就是从需求到交付的完整链路。

非必选2个（扩展能力）：领域知识库（给Agent提供充足的领域知识）、简单需求自动端到端生成（AI Native的云上交付路径）。

必选的5个是"主航道"，非必选的2个是"扩展包"。当前每个子课题都有对应的AI Native小组在推进，覆盖云通信的基础产品线先行。

当下展开其中最核心的四个课题：

• 【AI Native】数字分身的端到端交付

• 【2.0 规范】研发 Coding Agent - 生产物料体系（Harness & Spec工程）

• 【2.0 规范】研发自检Agent 

• 【2.0 规范】统计 & Loop工程

此外，知识库建设作为横向支撑能力，也会简要介绍其建设逻辑。

如果说前面三大块（物料体系、研发自检、统计&Loop）解决的是"怎么规范化地生产"，那这一块解决的是"谁来触发生产"——答案是：不一定非得是研发，但是一定是始于研发

真实场景是这样的：团队内部有大量运维类需求——补个监控面板、加个配置开关、做个取数功能、加个批量操作功能。这些需求不大，但数量多、排队久。研发觉得小活不值得专门排期测试，产品觉得小需求应该很快但就是排不上，日积月累，积压越来越多。

AI Native端到端交付要解决的就是这个问题：让产品或运营直接在钉钉里@数字分身提需求，系统自动走完从需求对焦到待交付的全过程，最终由研发review后交付上线。

整个流程分四个阶段：

• 阶段一：会话启动 形成在线会话链接（详见案例），开始 需求对焦——产品或运营在钉钉群聊或单聊中@数字分身，描述需求。协调者Agent（架构师角色）与用户多轮对话，澄清细节、确认边界，直到需求足够明确。这个阶段产出一份结构化的需求描述，等价于简化版spec。

• 阶段二：需求确认——协调者Agent把整理好的需求摘要发回给用户确认，用户确认OK后系统才往下走。这一步是人工卡点，防止Agent理解偏差后一路错下去。

• 阶段三：端到端自动生产——确认后系统启动7阶段自动流水线：需求接收→安全审核→技术方案→开发实施→测试验证→代码审查→部署上线。6个AI Agent按流水线阶段依次执行：

• 协调者（架构师）：整体统筹 + 用户交互，是用户唯一直接对话的角色

• 产品经理Agent：需求分析 + Aone读取，把模糊需求转化为结构化spec

• 后端工程师Agent：代码读写 + 终端命令，按spec执行开发

• 测试工程师Agent：跑测试、验证功能

• 代码审查Agent：Diff审计，独立视角检查代码质量

• 安全审核Agent：纯推理，合规评估

• 每个Agent最小权限、互不越权。执行过程中，用户可以通过Web实时面板（WebSocket推送）查看所有阶段进展和Agent对话记录。

• 阶段四：待交付——流水线跑完后，产出物进入"待交付"状态：代码已提交到分支、测试已通过、代码审查已完成，但还没有合并上线。最终由研发review产出物、确认无误后执行交付。这一步是必须的人工卡点——AI负责生产，人负责最终拍板。

真实案例：

整套系统运行在Devix云端安全工作空间里，每个用户独立隔离。核心编排引擎是team-manager（Python/FastAPI），内部由LangGraph StateGraph（9节点有向状态图）驱动编排，支持断点续跑——进程重启后从上次节点继续，不会因为网络波动丢失进度。Agent通过MCP协议对接集团内部工具（代码仓库、CI/CD、Aone、钉钉、语雀），实现真正的全链路自动化。

这也解释了为什么2.0体系是两轨并行而不是直接跳到全自动：先把规范体系建好、验证稳定，再把自动化生产轨道切过来。就像先造好流水线和工艺标准，再上自动化工位——工艺不达标就急着上自动化，只会批量产出废品。

当前的方案是：一个员工配一个数字分身，分身借用人的权限作业——代码提交用的是人的账号，CR发起用的是人的身份，Aone操作走的是人的权限。这样做的好处是快速启动，不需要额外的权限体系设计；坏处是分身的行为边界完全绑定在人身上，分身之间也无法协作。

长期的方向是把数字分身汇总为数字员工管理——一个组配几个数字员工，每个数字员工有独立的权限体系和身份标识，每个数字分身被数字员工使用，形成1：N结构。数字分身不再绑定某个具体的人，而是绑定某个角色和职责范围。比如"运维需求开发数字分身"有代码读写和CI/CD权限但没有生产环境操作权限，"测试数字分身"有测试执行权限但没有代码修改权限。到那个阶段，数字员工就是团队的正式成员，和人一样有工号、有权限、有考核。

扩展有两个维度：一是增加分身数量，从1人1个分身到1组N个数字员工，扩大并行处理能力；二是增加单个分身的需求并行度，当多个需求同时进来时，分身可以启动多组角色Agent并行作业——就像一个人同时开多个终端窗口，每个窗口处理一个需求。两层叠加起来，团队的吞吐量就不再受限于人头数了。

AI Native端到端交付不是另起炉灶，它遵循的仍然是2.0架构规范：Spec工程定义了"怎么一步步做"，Harness工程定义了"按什么标准做"，研发自检定义了"怎么验证做得对不对"，统计&Loop工程负责持续优化。唯一的区别是：执行者从"研发操作Agent"变成了"云端Agent自主执行"。

具体来说：云端Agent生成的spec文件夹结构和应用级完全一致（spec.md、plan.md、tasks.md、check_reports/、session/），自检Agent独立执行检查，统计&Loop工程的扫描同样覆盖云端产出物。这样保证了无论需求是研发手动跑的还是分身自动跑的，产出物标准统一、可追溯、可验证。

在讲具体的Harness和Spec之前，先讲清楚整个研发生产物料体系的全貌。

这套物料体系要解决的核心问题是：Agent在生产过程中需要遵循什么约束、产出什么标准物、怎么保证产出质量。 它由两大部分组成：

• Harness工程——定义Agent必须遵循的约束体系。包括四层约束（原则→宪法→规则→判例）、代码版本治理策略、以及落到代码仓库里的具体物料（App-Adr应用规约与技能、App-Desc应用说明、App-Research疑难杂症研究结果）。Harness回答的是"按什么标准做"。

• Spec工程——定义从需求到代码的生产过程。包括流水线分段（需求对齐→概设→详设→执行→检查）、每段的产出物标准（结果产出物+过程产出物+session log）、工作项分级管理。Spec回答的是"怎么一步步做"。

两者的关系是：Harness是工艺标准，Spec是流水线本身。

• 没有Harness约束的Spec就像没有工艺卡的流水线——能跑但产出不稳定；

• 没有Spec承载的Harness就像写满规章制度的白板——有标准但没有执行路径。

• 没有Spec+Harness约束的Agent：拿到需求直接写代码，产出不可控。今天写的和昨天写的风格不一致，命名随机，模块划分随心所欲。出了问题无法回溯——因为根本没有记录"它当时为什么这么写"。

• 有完整Spec+Harness约束的Agent：先对齐spec（做什么），再出plan（怎么做），再拆tasks（分步做），最后自检（做得对不对）。每一步都有产出物留痕，每一步都受Harness规则约束。出了问题翻session log就能定位根因。

可以说，Spec+Harness是端到端交付2.0的脊梁骨。没有它，后面所有的自检、Loop、平台扫描都没有锚点——你检查什么？回溯什么？优化什么？

在流水线上生产之前，你得先有工艺标准。Harness工程干的就是这件事——定义AI Agent在生产过程中必须遵循的约束体系。

"Harness"这个词来自马具。一匹好马（强大的模型能力）如果没有马具（约束规范），跑起来方向不定，还可能伤人。核心理念是：模型能力越强，约束体系越重要。

四层约束：原则→宪法→规则→判例

借一个类比来解释这个分层体系：把它想象成国家治理。四层从上到下是抽象等级递减、可执行性递增的关系。

原则（Principle）——顶层抽象概念 -> 相当于社会主义基本原则。从集团到部门到团队到应用，层层继承，是最顶层的价值导向。原则本身不告诉你怎么做，只告诉你什么不能违背。比如"代码必须向后兼容"、"新增接口必须有契约"这类不可商量的底线。

宪法（Constitution）——框架级抽象概念->相当于国家宪法。公共和抽象层面的约束，被各种执行工具（Qoder、Cursor、Codex等）自动加载。宪法是整个约束体系的中枢，它定义了Spec的逻辑（怎么组织需求文档）和Harness的逻辑（怎么约束执行行为），被所有下层规则所引用；但宪法仍然停留在"框架"层面，不直接指导具体作业。

规则（Rules）——实际指导作业的实现-> 相当于会计法、刑法。具体到某个角色的执行标准，是Agent真正落地时会加载和执行的约束。比如对研发的Maven构建规则、对测试的单测规范、对SRE的稳定性检查项。规则里每一条都能直接对应到"这一步该怎么做"。

判例（Cases）——具体规则操作的解读-> 相当于最高法判例。规则本身是文字描述，但具体到某个复杂场景怎么应用，往往需要看已有的案例。判例必须成对出现正例和反例——正例说明"符合规则的正确写法长这样"，反例说明"违反规则的常见错误长这样、错在哪里、正确的修正是什么"。只有正例，Agent容易依葫芦画瓢但抓不到本质；只有反例，Agent知道不能怎么写但不知道该怎么写。正反成对，才能把规则在实际场景中的边界和取舍讲清楚，避免Agent对规则的机械理解和过度演绎。

为什么要分四层？因为不同的抽象层级需要不同的治理频率。原则几乎不变，宪法偶尔调整，规则随业务频繁迭代，判例持续沉淀。如果全塞在一个文件里，改一条规则可能不小心影响了原则；反过来，一条判例的沉淀也很难反哺到抽象的原则层。分层之后，各层独立演进，互不干扰，而且每一层的读者都很明确——顶层给决策者看，宪法给架构师看，规则给Agent看，判例给需要参考的人看。

存量代码版本治理：像法律一样分"新法"和"旧法"

这里要单独聊一个Harness工程里特别重要的课题——存量代码的版本治理。

就像不同年代的法律对应不同的社会形态（82宪法、97刑法修正案、民法典），一个应用里的代码也有"新代码"和"老代码"之分。新代码遵循最新的架构规范和编码标准，老代码可能是三年前甚至十年前写的，遵循的是当时的规范。你不能拿今天的法律去判十年前的案子，同样也不能让Agent用新规则去改老代码——改着改着就炸了。

所以Harness工程里有一件事必须做清楚：优先把遵循新规的代码范围圈出来。具体来说：

• 新增逻辑怎么作业——新增的代码必须完全遵循最新的Harness规则。Agent在写新功能时，constitution、rules、skills全部按最新标准加载，没有任何历史包袱。这是最理想的场景，也是Harness发挥最大价值的地方。

• 涉及老代码怎么作业——当需求涉及修改老代码时，情况就复杂了。老代码可能不遵循COLA架构、可能没有DTO/Domain/DO分离、可能用的是过时的工具类。这时候Agent需要知道：哪些老代码是"已经规整清楚的"（已经按新标准重构过），哪些是"还没规整的"（还是老标准）。对于已经规整清楚的，按新规作业；对于还没规整的，Agent不能自作主张去"顺便重构"，而是要标记出来，交由人来决定。

• 哪些需要人兜底——老代码里那些还没被规则覆盖的"灰色地带"，就是人需要进去做研究分析的部分。Agent遇到这类代码时，应该停下来问："这段代码的历史背景是什么？为什么要这么写？如果要改，影响范围有多大？"而不是直接动手。这些需要人来兜底的范围，会随着Harness物料的持续完善而逐步缩小——每一次人做完研究分析，沉淀下来的结论就会变成新的规则或Skill，下次遇到类似场景Agent就能自己处理了。

这个治理过程的本质，就是把"人兜底"的范围逐步缩小，把"Agent自主"的范围逐步扩大。但不是一刀切——有些老代码可能永远不需要按新标准重构（稳定运行、不再迭代的模块），那就让它保持原样，在Harness里明确标记"此模块遵循旧规，不做改造"。

Harness工程的内容组成

约束体系不是写在PPT里的口号，而是实实在在落到代码仓库里的文件。每个应用的Harness物料分为三大件：App-Adr（应用规约与技能）、App-Desc（应用说明）、App-Research（疑难杂症研究结果）。

• App-Adr（应用规约与技能）——应用级的规范和技能集合，是Agent执行时自动加载的强制约束。App-Adr内部按角色再分成两个包：

• develop/——研发看自己的部分，告诉Agent"研发该怎么做设计、怎么做编码"。内部包含 develop-standards/（规范）和 skills/（技能）两个子目录。以短信监管应用为例，develop-standards里有S-001到S-011共11条标准，覆盖COLA架构规范、DTO/Domain/DO分离、Lombok数据对象规约、HSF接口规约、TDDL配置规范、Mapper设计、动态参数配置、日志规范、JUnit5单测规约等；skills里则是从应用中提炼的编码模式和最佳实践（如k001-gateway-pattern网关模式、k003-processor-framework处理器框架、k006-mapstruct-conversion对象转换规范），Agent加载后能直接按团队最佳实践写代码，而不是从零摸索。

• test/——研发看测试的部分，告诉Agent"研发自己该怎么测、测试环节有哪些要求规范"，同时覆盖流水线下游测试部分的内容物（用例设计规范、测试数据准备约定、Mock策略、覆盖率要求等）。内部同样包含 test-standards/（测试规范）和 skills/（测试技能）两个子目录。这一部分让Agent不仅"知道怎么写代码"，还"知道怎么把代码写得可测、测得放心"。

• 按develop/test分包的好处是：同一份Agent物料，服务研发和测试两条子链路的需求——研发Agent加载develop包做设计和编码，测试Agent加载test包做用例生成和执行验证，各取所需、互不干扰。

• App-Desc（应用说明）—— 相当于给Agent一张地图，让它不会在代码森林里迷路。包含应用的模块结构、包路径、关键DomainService类、依赖关系等，除此之外App-Desc还承载了前面讲到的代码版本治理的划分——哪些模块/包是遵循新规的"新法区"，哪些是已经规整过的"过渡区"，哪些是暂不改造的"旧法区"，都在这里明确标注。Agent进到某个包动手改代码之前，先查App-Desc就知道这块地皮是什么年代的、按什么标准作业、遇到不清楚的地方要不要停下来找人兜底。

• App-Research（疑难杂症研究结果）——专门存放对特定复杂问题的研究结论。有些问题不是一条规则就能讲清楚的，需要完整的背景调研、多方案对比、决策取舍过程。这些内容不适合塞进规则或技能里，就单独存到App-Research，作为Agent遇到相似复杂场景时的参考资料。它承担的是"经验沉淀"的角色——一个问题被人研究过一次，下次Agent或人再遇到时不用从头开始摸索。

如果说Harness是工艺标准，那Spec就是流水线本身——它定义了从需求到代码的生产过程：分几段、每段干什么、每段产出什么、怎么验证。

四条设计原则

• 遵循Spec原则（SDD + TDD）。SDD（Spec-Driven Development）意味着先写规格再写代码，TDD（Test-Driven Development）意味着先写测试用例再实现功能。不是Agent拿到需求就开始写代码，而是先把"要做什么、怎么做、怎么验证"写清楚，然后才动手。

• 遵循Harness驾驭工程。Spec的生产过程本身受Harness约束——模板怎么组织、文件怎么命名、检查报告怎么分类，都有规范。

• 不绑定Agent工具。物料和执行器解耦。同一套Spec物料，可以在Qoder里跑，也可以在Cursor、Codex、Claude Code里跑。团队按自己的偏好选工具，但产出的Spec文件标准统一。

• 不绑定Spec框架。内部用speckit，但也兼容openspec、superpowers、kiro等框架。只要产出确定的标准文件（spec.md、plan.md等），用什么框架生成不重要。目前团队内AI小组有两套实现并行：简单需求偏多用openspec——流程轻量、上手快；复杂需求偏多用speckit——分阶段更严谨、约束更充分。两套框架产出的spec文件夹结构统一，统计&Loop工程的扫描检查都能覆盖。

流水线分段：从需求对齐到检查

一条完整的生产流水线分五个阶段，每个阶段有明确的产出物：

• 阶段一：需求对齐——把模糊的需求转化为结构化的spec.md。spec.md里包含aone_id元数据、功能规格（FR功能需求 / SC成功标准 / Given-When-Then场景描述）、用户故事。这个阶段的产出物spec.md就是后续所有工作的"合同"。

• 阶段二：概设（技术方案）——根据spec.md生成plan.md（不同spec框架中也可能叫design.md，但在2.0规范中统一以plan.md为准）。

• plan.md聚焦技术方案的工程化拆分：系统结构怎么走、主流程怎么串、模块怎么划分、组件怎么定义。它走的是"从上到下拆结构"的逻辑——先看整体架构，再看模块边界，最后看组件交互。经过调优的plan模板核心思想是：按场景适配多模板，关注主逻辑主流程和模块合理拆分，剪枝低效内容。Plan注重设计层，不包含伪代码。

• 阶段三：详设&任务拆解——把plan拆解为可执行的tasks.md。

• tasks.md的设计要充分考虑执行层面的现实：分几个批次执行？每个批次的步频跨度多大？不要一次搞太复杂，每个batch的任务量和上下文复杂度要控制在模型能稳定处理的范围内。为什么？因为模型在执行过程中会面临上下文窗口压力，如果一个batch塞了太多任务或者跨度过大，就容易出现预期外的上下文压缩——前面的任务细节被挤掉，后面的执行就开始"忘事"、走偏。所以tasks.md的核心设计原则是：批次合理、步频可控、单批复杂度不超标。 遵循"Plan主导"原则——tasks是plan的细化，不能偏离plan的设计。

• 阶段四：执行——按tasks分批次执行代码生成。每批次完成后记录执行结果。

• 阶段五：检查——研发自检Agent生成check_reports，多角度验证产出物质量，沉淀spec的ADR 内容到应用级。

注意2个关键的 Checkpoint

• 提测前一切以概设为准 - 测试和研发的交互协议

• 发布前一切以代码为准 - 反向对所有文档内容进行检查对齐，防止有一些模型没有改全的情况

标准化的需求过程记录 - spec文件夹设计

这是Spec流水线跟普通AI写代码最大的区别。每次生产不仅产出代码（结果产出物），还留下完整的生产记录（过程产出物）和对话日志（session log）。

• 结果产出物：spec.md、plan.md、tasks.md、代码文件、check_reports/。这些是"交付件"，直接跟需求走。

• 过程产出物：research.md（调研分析）、data-model.md（数据模型）、contracts/（接口契约）、sql/（DDL/DML脚本）、adr/（架构决策记录）。这些是"过程件"，记录了生产过程中的思考和决策。

• Session Log：conversation-log.md，Agent对话全过程记录。这是最重要的"黑匣子"——当交付物出了问题，回溯session log就能定位是物料缺陷、需求模糊还是模型幻觉。

所有产出物统一放在Spec文件夹里，结构如下：

specs/{aoneID}_{需求名}/
├── spec.md              (必须) 功能规格
├── plan.md              (必须) 技术方案
├── tasks.md             (推荐) 任务分解
├── research.md          (推荐) 调研分析
├── data-model.md        (推荐) 数据模型
├── contracts/           (推荐) 接口契约
├── check_reports/       (必须) 研发自检报告
│   ├── check.summary.md (必须) 检查汇总
│   ├── 00-主链路检查报告  (强制) 端到端主链路
│   └── 按角色扩展        (按需) 产品视角/研发视角/安全SRE视角
├── test/                (推荐) 用例分析+报告
└── session/             (必须) Agent会话记录
└── conversation-log.md

[图：spec文件夹实拍——某个真实需求的specs/目录截图，展示完整的产出物清单]

工作项分级：三档管理

不是所有工作都需要走完整流水线。按复杂度和影响范围把工作项分成三档：

• 标准需求——有PRD或技术方案，需评审，>5人日。强制要求完整的Spec文件夹：spec文件 + 概设 + 全部检查报告 + 交付文档。

• 简单需求——研发可自测，不需正式评审，≤5人日。走简化版流水线：spec文件 + 概设 + 简化的检查报告（以单测为主）。

• 一般任务——零散技术任务（补单测、修字段等），不计入指标。无Spec文件夹要求。

这种分级的好处是：大需求重管、小需求轻管、杂活不管。避免了"杀鸡用牛刀"的过度工程。

打游戏的都懂：Solo能打小怪，但Boss战必须开团。而且团本不是随便凑五个人就行的——你得有MT扛伤害、近战DPS贴脸输出、远程DPS站桩输出、法系DPS控场AOE、奶妈加血保人，不同职业有不同的装备要求和操作规范，但团队目标一致、指挥统一、信息共享，才能通关。

AI Coding也一样。单应用Agent就是Solo——一个研发在一个应用里独立完成全流程，自己的规范自己说了算。但现实中的需求往往不止涉及一个应用。比如一个短信报备功能，可能同时涉及消息服务（alicom-message-service）、监管平台（alicom-message-supervise2）、计费引擎（alicom-billing-engine）三个应用联动变更——就像组了一个MT+远程DPS+奶妈的三人小队，每个应用有自己的技术栈和规范（相当于不同职业的装备和操作规范），但需要统一的项目级spec来对齐目标。

这时候就需要一套更高级别的物料——项目级物料（内部叫speckit-p）。项目级物料在应用级物料的基础上增加了三样东西：项目级宪法（constitution-p.md，最高优先级，覆盖应用级宪法）、跨应用接口契约（contracts/api.md）、以及Pre-check机制（检查各参战应用的物料是否就绪）。

• 准入条件——不是所有应用都能直接加入项目级联合作战。每个参战应用必须具备完整的AI Coding物料（App-Adr、App-Desc、App-Research、.specify、.qoder），Pre-check会逐个扫描，物料不齐的应用不能纳入联合开发。这就像打团本，组员等级和装备要够门槛才能进组。

• 统一指挥——单应用时，应用负责人就是"玩家"，自己决定怎么打。项目级时，需要架构师和PM角色来统一指挥：架构师负责跨应用的技术方案对齐和接口契约定义（相当于团队指挥喊技能CD），PM负责需求拆分、Phase编排和进度协调。各应用的研发还是各自执行，但大的方向和节奏是统一的。

• 信息互通——项目级spec文档随项目git分支管理，每个应用独立git仓库但共享项目级spec和接口契约。任何跨应用的接口变更都在contracts/api.md里定义，所有参战应用都能看到、都能对齐。

用一个具体例子来说明。假设有一个"短信网关全链路优化"的需求，涉及3个应用联合开发：

案例：

从实施效果看，项目级物料收益最大的两类场景：

• 前后端应用协作——涉及大量简单需求的快速落地。前端和后端接口对齐是AI Coding最容易出问题的地方，项目级接口契约把RPC/MQ定义清楚，前后端Agent各自生成代码时就不会"各说各话"

• 2-3个应用的中等规模跨领域需求——比如一个涉及消息服务+监管平台的功能改造，单靠人脑对齐接口和时序太费劲，项目级spec把跨应用的变更范围和数据流向统一描述清楚，各应用Agent按契约各自执行，效率远高于串行沟通。

这里可能有人会问：为什么不把所有单应用需求也套上项目级的结构？统一一套不是更规范吗？背后的考虑是奥卡姆剃刀——如无必要，勿增实体。在非协同的场景下，一个研发在一个应用里独立完成需求，没必要给自己套上项目级宪法、Pre-check、跨应用契约这些额外的约束。项目级物料是为了解决多应用协同的复杂度而生的，如果不存在这个复杂度，硬加上去就是自己给自己加活——流程更重、维护成本更高、执行效率更低。单应用需求走应用级物料，简单直接，够用就好；多应用协同需求才升级到项目级物料，按需升配。

Harness和Spec的物料体系讲完了，但一个实际问题摆在面前：一个新应用或者一个还没接入AI Coding的老应用，怎么快速配齐这套物料？以及物料建好之后，怎么持续迭代？

从0到1：两种安装模式

提供两种模式：

• 复刻模式——适用于相似框架的应用。从已成熟的应用直接copy核心物料（constitution.md、template文件夹、App-Adr、App-Desc、App-Research），然后根据新应用的样例代码结构做本地化适配，这类方式可以把一个应用快速复刻到中等成熟度。Agent会分析新应用的module结构、package结构、关键domain类，自动调整物料内容，整个过程Agent自动完成，只需要人review最终结果。

• 扫描安装&更新模式——适用于异构或全新应用的0-1。Agent扫描应用代码，自动识别架构模式和编码惯例，沉淀成Skills和Rules，然后生成对应的constitution和template。这个模式需要"重新认识"应用，所以耗时更长，但能产出更贴合实际的物料。

采用skill方式作业 - 详见 Skill市场。不管用哪种模式安装完物料，都不能直接上生产线。还得走三步：先检查、再热车、最后逐步上强度。

安装完成后，首先用统计&Loop工程对spec和harness物料做一轮完整性检查——constitution是否齐全、rules是否和最新规范对齐、skills是否覆盖了应用的核心编码模式。检查通过后，挑一两个简单需求（小功能、补单测这类）走一遍完整的spec生产流程，算是一次"热车"。热车的目的是验证物料在实际生产中能不能跑通、Agent在约束下产出的代码质量是否达标。

热车完成后，研发负责人评估一下：技能覆盖是否相对周全？常见编码模式有没有被遗漏？检查报告能不能有效发现问题？评估通过后，再逐步接更大的需求——从简单需求到标准需求，从单模块变更到跨模块改造。就像玩游戏打怪练级，先在"新手村"把装备和技能都凑齐了，确认能稳定输出了，再出去打Boss。

持续调优闭环

物料包不是"建一次就完事"的。它需要一个持续调优的闭环：

逐层适配（集团规范→部门规范→团队规范→应用自身规范） → 扫描式生成（提供最新代码示例，从原则落地到具体规则） → 执行过程中总结 → 优化规范和沉淀Skills → 下个需求验证效果。

这个闭环和后面要讲的统计&Loop工程紧密配合——统计&Loop工程发现的问题会直接反馈到Harness物料里，驱动规则迭代。

流水线上的产品，不能等到出厂了才检测。在汽车工厂里，每个工位完成后都有质检员检查——焊装完查焊点，涂装完查漆面，总装完查功能。研发自检Agent就是2.0体系里的"质检工位"。

这里要先厘清一个架构关系：研发自检Agent遵循Spec规范，但它是一个独立的体系。 用Java的术语来说，Spec工程定义了一套SPI（Service Provider Interface）——spec文件夹结构、check_reports/的格式规范、check_summary.md的判定标准，这些都是"接口定义"。研发自检Agent是这个接口的一个"实现"，它按照Spec的标准产出检查报告，但它本身的运行逻辑、检查策略、执行环境完全独立于编码Agent。除此之外还可以有其他"实现"——比如平台扫描、自动化测试、SRE合规检查——它们都遵循同一套Spec接口标准，但各自独立运行。这种解耦带来的好处是：编码Agent不需要知道自检Agent怎么工作，自检Agent也不需要知道编码Agent当时怎么想的，双方只通过Spec标准"对话"。

这是最关键的设计决策：自检Agent必须在独立会话和独立工作区中运行，不共享编码Agent的上下文。

为什么？因为让编码Agent自己检查自己，就像让厨师给自己的菜打分。它刚刚花了两小时写出这段代码，现在你让它找自己的bug？大概率它会告诉你"代码看起来没问题"。这不是能力问题，是心理学上的"确认偏差"——人会不自觉地为自己的决策辩护。

所以做法是：启动一个全新的Agent会话，给它全新的工作区，让它用"局外人"的视角审视变更。这个Agent不知道编码Agent当时为什么这么写，它只看到diff、spec、harness规则和知识库——然后独立做出判断。

• 挑战一：扫描范围要拉全。 一个需求变更的影响范围远不止当前应用的diff——产品层面的功能变更、关联应用的主干分支、外部接口和消息依赖，都得纳入检查范围。漏掉任何一个维度，就可能出现"改了A系统，B系统挂了但没人发现"的情况。解决方案是把检查范围精确推断出来：联合Review范围 = 本应用diff + 关联应用分支 + 知识库上下文 + spec/plan。具体来说，自检Agent从git diff入手（这次改了什么），结合spec（本来要做什么），再拉取关联应用的分支（上下游有没有被影响），最后叠加知识库上下文（这个应用的特殊约定和历史坑）；同时依赖注册中心的元数据自动发现上下游依赖，结合代码库扫描识别外部接口和消息引用，确保检查范围既精准又全面。

• 挑战二：多视角检查，不能只看代码。 研发自己看代码只看逻辑对不对，但产品关心的是功能覆盖全不全，测试关心的是用例场景够不够，SRE关心的是可运维性和安全合规。每个角色关注点不同，检查维度也不同。自检Agent必须模拟多个角色的视角，分别出具检查报告，而不是用一个"代码没问题"就交差。具体展开见下节"多角色检查报告"。

• 挑战三：控制信息量，不能一次塞太多。 这和Spec工程的tasks.md设计是同一个道理——一次性检查太多内容，模型的上下文窗口扛不住，容易出现信息压缩，前面的检查结果被挤掉，后面就开始"忘事"。当前的策略是先确认主干逻辑，再分而治之：先跑主链路检查（端到端的功能覆盖），确认主干没问题后，再按模块逐个检查细节。这样既保证关键路径不出错，又避免信息过载。

质检不是一个人说了算。按角色分成多个检查维度：

• 产品视角：需求-功能-组件逻辑覆盖完备性。 检查实现是否覆盖了spec中定义的所有需求点。有没有遗漏的功能？用户故事里的Given-When-Then场景是否都被实现了？

• 研发视角：架构合理性 + 代码质量 + 变更内容检查。 架构是否符合Harness定义的规范（比如COLA分层有没有违反）？代码有没有编码规范问题、逻辑矛盾？变更内容是否完整（TODO有没有遗留、注释掉的代码有没有清理）？

• 安全/SRE视角：外部影响 + 可运维&安全合规。 上下游依赖和接口变更有没有影响其他系统？新增的接口有没有做参数校验？数据库变更有没有向后兼容？日志规范有没有遵守？可运维性（监控、告警、回滚方案）是否到位？

每个维度独立出一份报告，最终汇总成check_summary.md，标注overall_result：

PASS：全部通过，可以进入下一阶段

CONDITIONAL_PASS：有非阻塞性问题，修复后可继续

FAIL：存在阻塞性问题，必须修复后重新自检

问题需要带上证据，所有报告写入check_reports/目录，除了固定的check.summary.md和主链路检查报告外，其他报告按角色扩展（产品视角/研发视角/安全SRE视角），避免检查内容过于细碎。

案例：

如果说Spec工程是"生产"、研发自检是"质检"，那统计&Loop工程就是"质量改进部门"——它不生产产品，但它让整个流水线越跑越好。

在真正的工厂里，流水线不只是"跑生产"，还有一套完整的日志分析和持续改进体系。丰田的"5Why分析法"追问五层才找到根因，西门子的产线用帕累托分析锁定导致80%故障的那20%关键设备，六西格玛的DMAIC方法（定义→测量→分析→改进→控制）把每一次异常都变成可复用的改进案例。这些方法论的共性是：不是出了问题才修，而是盯着数据找规律，把隐性缺陷变成显性改进。

统计&Loop工程干的就是这件事——对流水线上的物料体系、过程文档、执行日志做多维度检查，发现问题，反向优化整个生产飞轮。

统计&Loop工程的核心是"4+1"——前4个维度是发现问题、驱动优化的检查闭环，+1是度量合规执行率的统计维度。两者的目的和产出不同：前者输出"改进建议"，后者输出"指标数据"。

4个问题检查维度：

案例：

+1 统计维度：Agent生成判定

怎么判断一个需求是不是"Agent端到端生成"的？四个硬性条件必须同时满足：

• aone_id：spec.md元数据头中的aone_id可在Aone系统中匹配到

• spec.md：存在且内容校验通过

• plan.md：存在且内容校验通过

• check_reports/：存在且内容校验通过

四个条件同时满足才计入"Agent生成需求"的分子。

session/目前作为强制上传要求，但暂不作为判定条件——思路是先把需求的相关会话数据收上来再推进问题的分析

举一个飞轮验证的真实案例：实践中发现某类需求的session log里，Agent总是在"数据模型设计"阶段反复修改，对话轮次异常高。分析后定位到原因——plan模板里缺少"枚举定义"这个章节，Agent在写plan时没有显式列出枚举值，到tasks阶段才发现枚举不全，回头改plan，再改tasks，循环了三四次。改进方案很简单：在plan模板里加上"枚举定义"章节。改完之后，基于近20个同类需求的对比统计，对话轮次下降了约40%。这就是飞轮转起来的效果——发现问题、改进模板、验证有效、反哺全局。

统计&Loop工程的扫描检查可以在两个地方执行：

本地执行：通过QoderWork的e2e-scanner技能，在研发本地直接跑扫描。适合单应用、单需求的快速检查，出结果快，反馈即时。

平台执行：交由统一平台批量执行。适合跨应用、跨产品线的全量扫描和统计分析。平台会把扫描结果汇总，生成产品线和团队维度的统计报告——哪个团队的Spec完整率最高？哪个应用的Session对话轮次最少？哪些规则被违反最频繁？

把4+1串起来，统计&Loop工程的完整闭环是：

统计&Loop工程是整个2.0体系里最难建设但价值最大的部分。 Spec工程和Harness工程是"基础设施"，建好了就能用；研发自检是"质检工位"，加上去就能拦问题；但统计&Loop工程是"飞轮"，它需要数据积累、需要分析能力、需要组织层面的闭环机制。

前面讲的Harness和Spec解决的是"怎么约束Agent的行为"，但Agent要写出贴合业务的代码，还需要充足的领域知识——这个应用有哪些核心DomainService？历史上踩过哪些坑？某个业务概念的准确定义是什么？

知识库分本地和远程两层：

• 本地精炼知识库——每个产品/应用维护一份非常小的知识文档（.md，<50KB），统一放在git管理。内容涵盖数据模型、专有名词、关键业务概念、应用结构、系统间关系等业产研核心信息。在spec作业的需求对焦和设计过程中，按涉及面自动download对应的精炼知识文档供Agent参考。需求复杂时，人需要检查Agent对知识的理解和运用是否正确。精炼知识库需要定期组织领域专家review，确保信息准确且不过时。

• 远程kbase知识库——用于收集现有的领域知识文档、历史需求归档、架构设计文档等。kbase是知识的"蓄水池"，核心信息会定期同步精炼到本地知识库中，形成"远程收集→精炼沉淀→本地加载"的知识流转闭环。

这块目前正在筹划建设中，还没有完全落地。但方向是明确的：Agent不能只靠规范干活，还得有领域记忆——就像一个新员工不光要看编码规范，还得了解业务是怎么回事。

这套体系还在持续建设和打磨，远没到终态，但方向是确定的：AI Coding的未来不是"更快的代码生成器"，而是"更好的交付体系"。

最后分享两个观察到的趋势：

• 过去一个研发用一个Agent工具干所有事，未来会是用不同的工具和模型做不同事情 ，比如CC适合做需求分析和设计、Qoder做分批次执行、Codex 查bug能突出适合代码review——各有所长，成本不一，这块需要在全链路上做好选择。

• mac 作业最终会变成云上作业，随着Qoder Cloud Agent ，Devix，A2A 安全网关等配套完善, 工作环境可能变成1本地拖N云上。 研发从"操作Agent"变成"监督Agent"，最终变成"审批Agent"。简单需求甚至不需要研发介入，产品/运营直接通过数字分身驱动交付。

如果你也在探索AI Coding的端到端交付，欢迎交流。这个系列后续会展开产品PRD生成&质检、测试用例执行、长时间自主生成等子课题的详细设计和实践案例。

千问AI平台-为Agent而生，驱动AI生产力
扫描下方二维码，直达千问AI平台体验

点击阅读原文即可体验！

阅读原文

跳转微信打开

在谈任何工程方法论之前，先要理解我们面对的"对手"是什么。大语言模型有四个结构性约束，它们不会因为模型变大、训练数据变多而消失。所有后续的工程努力，都是在这四面墙壁围成的房间里做文章。

我们的系统运行在 128K token 的上下文窗口内。看起来很大，但算一下就知道它有多脆弱：

一个 ReAct Agent 每执行一个步骤，至少产生 3 条消息：

一个 5 步技能、每步 3 轮迭代，就是 45+ 条消息。如果每个工具结果是一份 API 返回的 JSON（动辄数万字符），消息队列会在几轮之内膨胀到 200K+ 字符——远超 128K 的物理上限。

更棘手的是，这不是一个"截断旧消息"就能解决的问题。四个原因让简单截断变得不可能：第一，截断的 JSON 是残废数据，LLM 无法从中提取有效信息——一个被砍掉后半段的嵌套 JSON 连 parse 都无法 parse。第二，OpenAI 协议要求tool消息必须紧跟其对应的 assistanttool_calls，随意截断会破坏配对结构导致 API 报错。第三，即使上下文没溢出，LLM 在 20+ 轮对话后也会"遗忘"早期的关键发现——注意力被后来的信息稀释了。第四，被压缩的数据也不能真正丢掉，用户可能随时需要完整原文（审计、回放、追溯）。

这意味着我们需要的不是"截断"，而是一套完整的"信息生命周期管理"——从产生、压缩、索引到按需恢复，每个环节都需要工程化的解决方案。

这是我们在 S2 初期最困扰的现象：同一个 Skill，3 步的任务执行质量很好，加到 8 步质量就明显下降，到 15 步几乎不可用。最初怀疑是模型能力问题，换了更大的模型并没有预想中的改善。

后来通过逐步骤 dump 上下文发现了真相：到第 8 步时，上下文中 70% 的内容是前几步工具调用的原始返回值（大量 JSON），20% 是历史对话消息，只有 10% 是真正有用的当前步骤指令和上下文变量。LLM 的注意力被这些"噪音数据"严重稀释。这不是模型不够聪明，是我们喂给模型的信息质量在逐步劣化——信噪比在每一步都在恶化。

这个发现揭示了一个反直觉的事实：上下文窗口的"物理容量"和"有效容量"是两回事。 128K 的窗口塞满了 70% 的噪音数据，有效容量可能还不如一个精心管理的 32K 窗口。就像一间 100 平的办公室，如果 70 平堆满了杂物，实际可用空间还不如一间 30 平的整洁工作间。

更深层的问题是：这是一个自我恶化的循环。上下文膨胀 → 注意力稀释 → 工具调用参数错误率上升 → 产生更多无效的重试消息 → 上下文进一步膨胀。在 S1 的线性架构下，这个循环没有任何制动机制。

这个教训可以浓缩为一句话：不要用更大的模型掩盖工程层面的问题。 模型从 32K 升级到 128K 不会解决注意力稀释——它只是把天花板从第 5 步推迟到第 8 步，恶化的趋势不变。真正的解决方案必须从工程层面入手：管理信息质量，而非扩大物理容量。

在多步骤的技能执行流程中，步骤 A 的输出需要作为步骤 B 的输入。这些数据由模型从步骤 A 的工具返回中提取，然后"搬运"到步骤 B 的工具参数中。在这个搬运过程中，模型可能截断长字符串、遗漏嵌套字段、混淆相似的 ID、或者在上下文压缩后彻底"忘记"某个关键值。

以 auto_coder工具为例：自动模式下暴露了 input（required）参数给 LLM，迫使 LLM 充当"数据搬运工"——从上下文中找到前序步骤的输出数据，复制一遍塞进参数。这浪费大量 token，且容易出错（__refId 丢失、数据截断、字段遗漏）。我们观察到一个典型的失败模式：当步骤 A 返回一个包含 15 个元素的数组，LLM 在"搬运"到步骤 B 时只传递了 3-5 个"代表性"元素——它在无意识中做了一次"摘要"，但对于精确执行来说这就是数据丢失。

更隐蔽的失败场景：步骤 A 返回的 JSON 中有一个refId 字段（UUID 格式，如 a1b2c3d4-e5f6-7890-abcd-ef1234567890），步骤 B 需要用这个 ID 调用另一个 API。LLM 在搬运时可能把 UUID 的最后几位截断、把两个相似的 UUID 混淆、或者在上下文压缩后直接幻觉出一个不存在的 ID。每一种错误都会导致步骤 B 调用失败，而失败信息又会膨胀上下文，加速注意力稀释。

自动模式的本意是"用户只说要做什么，Agent 全权处理"，让 LLM 填 input 等于把自动模式降级成了手动模式——用户不需要手动搬运数据，但 LLM 在替用户做同样的事。

核心原则是：让 LLM 做它擅长的事（理解意图、规划、推理），让系统做它擅长的事（数据搬运、格式转换、精确传递）。 这条原则后来成为第四章"从防御到赋能"设计哲学的基石——parameterBindings 声明式绑定的本质就是"把数据搬运从 LLM 的职责中彻底移除"。

LLM 的每次对话都是无状态的——每一轮 API 调用对模型来说都是"第一次见面"。这个约束在两个层面造成问题：

单次执行内的无状态：一个 Agent 执行到第 12 步时，前 11 步的状态完全依赖上下文消息来承载。如果进程崩溃、网络断开或服务重启，所有中间状态瞬间蒸发——LLM 没有"硬盘"，只有"内存"，断电就清零。

跨执行的无状态：这是更深层的问题。Agent 无法从历史执行中学习。一个 Agent 昨天在执行"选品任务"时发现"搜索关键词不能用空格分隔"（调了三次才成功），今天执行相同任务时这个教训已经不存在了——它会重新犯同样的错误，重新消耗三次重试的 token。

我们在生产中观察到的一个典型案例：某个 Agent SDK 的 agentId 参数在菜单配置中应该是数字类型（12），但开发者写成了字符串类型（"12"），导致助理不出现。一位工程师花了 1.5 天调试才定位到这个问题。问题是，这个知识只存在于那次调试的上下文中——如果另一个团队成员遇到同样的问题，他们会重复这 1.5 天的调试过程。知识在诞生的同时就开始遗忘。

重要的架构决策和技术事实如果不显式记录，就会在新会话中被重新讨论甚至做出矛盾的决定。这不仅是效率问题，更是一致性问题——一个"每次对话都是新生"的 Agent 永远无法成为可靠的长期伙伴。

这四个约束共同指向一个结论：原始的大模型只是一块"高性能 CPU"，没有内存管理、没有文件系统、没有进程调度。要让它稳定地、大规模地执行企业级任务，需要在它外围构建一整套"操作系统"级别的基础设施。这就是从 Prompt 到 Harness 的演进动因——每一章的主题，都是在为这块"裸 CPU"补一个操作系统的子系统。

最早期的做法，是把所有信息塞进一段 System Prompt：角色描述、业务规则、行为约束、格式要求。随着系统复杂度增加，这段文本从几百字膨胀到数千字，最终演化为一份完整的项目上下文注入文档（我们称之为 CLAUDE.md）——超过 500 行、10 个结构化章节，涵盖：

设计哲学（统一的工程审美标准）、安全硬规则（调用 API 前必须确认、修改代码前必须等待审批）、项目路径映射表（4 个项目的本地路径 → 远程仓库对应关系）、核心站点全景（4 个微前端站点的 URL/布局/路由映射，覆盖 30+ 路由）、微前端发布规范（版本号必须 bump、分支命名规则、tag 校验前置条件）、API 端点注册表（两个服务的 baseURL + 完整端点表）、知识体系目录（四层记忆架构的物理路径索引）、Skill 创建规范（planDefinition schema、outputMode 纪律、发布阻断规则）、系统状态与关键文件路径（30+ 核心文件的位置索引）。

这份文档本质上是一种"持久化的 System Prompt 工程"。它通过结构化信息（表格、映射关系、规则列表）最大化 LLM 的上下文利用效率，通过"上下文推断规则"实现了一种轻量级的 RAG——无需向量检索，靠关键词触发即可将用户意图映射到正确的代码路径。例如："当用户提到 X 概念时，关联到 Y 目录下的文档"——这种声明式规则让 LLM 不需要搜索就能找到正确的知识入口。

但一份 500+ 行的静态文档注入也有其上限：它占据了宝贵的上下文空间（约 15K-20K token），每次对话都全量注入无论是否相关。这为后来的"渐进式披露"和"按需检索"思路埋下了伏笔。

随着系统复杂度上升，工程师开始在工具 description 中注入格式规则——用 ⚠️ 标记强调"搜索关键词不要用空格分隔"、"元组数组必须包含 N 个元素"。这些规则本身没有错，但依赖模型"注意到"并"遵守"。

这像极了工厂车间墙上的安全标语。"注意安全"永远是正确的，但如果安全依赖于工人每次都阅读并遵守标语，那这个安全体系是脆弱的。真正的安全来自机械互锁、自动断电、物理防护——来自消除危险条件，而非警告危险存在。

我们的实践验证了这一点：指令遵从率在多步长链路中急剧下降。在 3 步的简单任务中，格式规则的遵从率可能有 95%；到 10 步以上，这个数字会跌到 70% 以下，因为每一步的上下文中都在累积新的信息，早期的 ⚠️ 标记被淹没在海量 token 中。

为了应对指令遵从率下降的问题，我们尝试了各种 Attention 引导术：用 ⚠️ 标记提高视觉显著性、用粗体和全大写字母（IMPORTANT: DO NOT...）模拟"强调语气"、把关键规则放在工具 description 的最开头和最结尾（利用注意力机制的 primacy/recency effect）、甚至在每一步的 user message 中重复注入关键约束。

这些技巧在短对话中确实有效——3-5 步的任务中，规则遵从率从 85% 提升到 95%。但在 10+ 步的长链路中依然不可靠。原因很本质：Transformer 的注意力是一种有限资源，它在所有 token 之间做加权分配。当上下文从 10K 膨胀到 100K 时，一个 ⚠️ 标记获得的注意力权重被稀释了 10 倍——即使你把它加粗、大写、放到最前面。

这本质上是在和模型的注意力机制做"军备竞赛"：你加一个 ⚠️，上下文膨胀稀释了它，你就加三个 ⚠️⚠️⚠️；模型开始忽略 emoji，你就换成 [CRITICAL]；模型开始忽略 [CRITICAL]，你就在每一步重复注入……这是一场永远赢不了的竞赛，因为你在用"更多 token"来对抗"token 太多"——火上浇油。

真正的出路不在 Prompt 层面，而在系统层面。与其让模型"记住"规则，不如让系统"强制执行"规则——这个认知后来演化为第四章"从防御到赋能"的核心哲学。

Prompt 工程阶段的顶峰，是我们的 S1（第一代 Agent 系统，FY26 上半年）MVP。它的架构可以用一句话概括："工作流编排 + 单轮对话"——预定义的工作流节点按顺序串联，每个节点是一次 LLM 调用。没有 Agent 概念、没有 Skill 概念、没有 ReAct 循环。

S1 用三个月跑通了"AI 能做大促"的最小可行产品，8 月覆盖全量活动场景，活动举办效率提升 50%。这证明了方向正确。但上线后很快暴露出三个结构性缺陷——所谓"结构性"，是指它们不是 bug（可以修复），而是架构选择的必然后果（只能重建）。

第一，没有容错，一断全崩。 工作流执行是纯内存的 while 循环——没有事件溯源，没有检查点持久化，没有执行状态的外部表示。状态全在进程内存里。一个 15 步的选品任务，第 12 步因外部服务超时失败，唯一的选择是从头重跑全部 15 步（约 6 分钟）。更糟的是用户场景：用户关闭浏览器标签页 → SSE 断开 → 后端的 Promise 链还在跑但结果无处推送 → 用户重新打开页面看到的是空白状态。

第二，上下文像气球一样膨胀，最终爆炸。 每一步工具调用的返回结果都完整塞入对话上下文。一次 API 调用返回 50KB 的 JSON，三步之后上下文就逼近 128K 的窗口极限。即使没有溢出，注意力稀释也让工具调用的参数错误率显著上升，形成"越跑越蠢"的恶性循环——这个循环在架构层面没有任何制动机制。

第三，执行完就结束，不会回头看。 单向管道从第一个节点跑到最后一个节点，不检查前几步的输出是否合理，不根据中间结果调整后续计划。对于 3-5 步的简单任务这不是问题，但对于 10+ 步的复杂任务，错误在链路中不断放大——第 3 步的一个小偏差，到第 10 步可能已经完全偏离用户意图，产出"形式上完成但逻辑不一致"的结果。

这三个缺陷修修补补解决不了，它们指向同一个根因：S1 的引擎把 AI 当作一次性脚本执行器，而不是有状态、能反思、能管理自身资源的智能运行时。你可以给脚本加上 try-catch 和日志，但你无法让一个脚本"反思自己写错了"、"记住上次跑崩在哪里"、"主动优化自己的资源消耗"。

Prompt 工程走到了天花板。下一阶段（S2，FY26 下半年）的任务就是重建这个运行时——不是修缮 S1，而是以完全不同的架构假设从零构建。

在动手重构之前，我花了大量时间研究业界最前沿的 Agent 运行时。几个关键输入：

ReAct Loop（Yao et al., 2022）确立了"Reasoning + Acting"交替推理的范式，但原始 ReAct 有一个隐含假设：上下文无限大。论文中的 demo 只有 3-5 步，不需要管理上下文。一旦步骤超过 10 步，原始 ReAct 就会因为上下文膨胀而退化。我们的系统需要在 128K 的上下文窗口内稳定执行 30+ 步、数十次工具调用——这是原始 ReAct 从未面对过的工程挑战。

Claude Code（Anthropic）给了我最大的两个启发。第一是上下文层面的 compaction 策略——当上下文接近窗口上限时，把整段对话压缩为一份结构化的"交接文档"，用这份文档替换原始对话继续推理。第二是渐进式披露（Progressive Disclosure）的设计哲学——构建 Agent 最难的部分在 Action Space 的设计，而非推理能力本身。

Codex（OpenAI）在数据层面做了类似的事，把大结果存到外部，上下文里只保留引用指针（refId），按需取回。这个 pattern 后来成为我们 L1 层的核心灵感。

这些研究让我形成了核心判断：上下文管理是一个需要分层防御的系统工程，不能指望单点优化。 就像网络安全不能只靠防火墙一样，上下文管理也不能只靠一种压缩策略。不同粒度的数据膨胀需要不同层级的应对机制——单次工具调用可能产生 50KB 的 JSON，5 步累积可能膨胀到 200K+，而 30+ 轮对话的渐进式膨胀又是另一种完全不同的模式。每种膨胀需要不同的"拦截武器"。

四层防线不是想到哪加到哪，而是严格按照数据膨胀发生的时间顺序逐层拦截——从工具返回数据的那一刻起，到数据最终被消费或过期，每一层解决一个特定粒度的膨胀问题。

一条数据从产生到消亡的完整旅程如下：

L1——工具结果压缩（ToolResultRefStore）：拦截单次大数据

工具结果是上下文膨胀的最大来源。一次 API 调用可能返回 50KB 的 JSON 数据，但 LLM 实际需要的可能只是"共 23 条记录，状态均为 active"这样的结论。

ToolResultRefStore 是一个"大结果外置 + 引用替换"机制。三个触发条件：字符数超限（>8000）、数组元素超限（>10）、强制存储模式（alwaysStore，用于参数绑定场景下的数据完整性保障）。大结果存 MySQL，消息中只留引用对象：

{
"__stored":true,
"__refId":
"a1b2c3d4-...",
"__toolType":
"unified_protocol_service",
"__originalLength":52340,
"__summary":
"23 records, all active...",
"__hint":
"Call get_stored_data(refId=\"a1b2c3d4-...\") for full data"
}

其中数组元素超限的设计有一个重要的背景：LLM 倾向于在搬运大数组时"优化"掉部分元素。它不是恶意的，而是在有限的注意力中自然地做了"摘要"——但对于需要精确传递的业务数据来说，这种"优化"就是数据丢失。我们观察到：Step 1 返回 15 条记录，Step 2 需要处理全部 15 条时，LLM 会只搬运 3-5 条"代表性样本"。超过 10 个元素的数组强制外置存储，从根本上消除了 LLM 的篡改机会——它只能通过 get_stored_data 获取完整数据。

还有一个容易被忽视的细节：存储记录中有一个 preview 字段（前 12000 字符），但这个 preview 永远不进入 LLM prompt，它仅用于审计/调试/回放。这个约束是"单一表示原则"（3.3 节）的一个具体体现。

L2——语义压缩（SemanticCompressor）：压缩中等数据

单条工具结果超过 10000 字符时触发 LLM 语义压缩。用另一个 LLM（temperature=0.3，超时 60s）从海量数据中提取对后续推理最关键的信息，输出上限 2000 字符。本质上是用一个小模型做"注意力蒸馏"——把 50KB 的原始数据蒸馏为 2KB 的高密度结论。

为什么选 temperature=0.3 而不是 0？因为 temperature=0 在某些模型上会触发贪心解码的退化模式（重复 token），0.3 是我们在"确定性"和"输出质量"之间找到的平衡点，经过线上 2000+ 次压缩验证稳定。压缩后原始数据仍然保留（TTL 1 小时），确保后续步骤需要时可以通过 DataBus 取回。

降级策略也很重要：LLM 压缩失败时退化为结构化截断（前 3000 字符 + JSON 包装 +__fallbackTruncated: true 标记），而非直接截断原始文本。JSON 包装确保 LLM 能识别"这是一段不完整的数据"而非"这是全部数据"。

这里有一个被废弃的教训——我们曾有一个 generateToolResultSummary 函数，让 LLM 同时生成 summary（500 字符）和 preview（5000 字符）。结果发现 LLM 在重写 preview 时会改变字段名称和数据结构前缀。这导致了一个隐蔽的 bug：ToolExecutor.findMatchingStoredObject() 使用前缀匹配来识别哪些工具参数应该从 MySQL 恢复原始数据。LLM 的"智能重写"让前缀对不上了，腐败数据直接流入了下游工具调用。修复方案很简单：preview 改用原始文本的 substring——不经过任何 LLM 处理。**"过度智能反而有害"**，这个教训深刻地影响了后续的设计哲学：在数据流转管道中，确定性永远优先于智能性。

L3——对话压缩（Compaction）：压缩累积膨胀

L1 和 L2 管的是单条消息的体积，L3 管的是消息累积后的总量膨胀。基于 usage-based 触发：当 prompt_tokens / contextWindow >= 85% 时启动，目标压缩到 30%。

为什么是 85% 而不是 95%？因为 95% 时模型可能没有足够的输出空间，返回空响应。为什么目标是 30% 而不是 50%？因为压缩有延迟（LLM 调用 + DB 写入），这段时间内新消息还在累积，如果目标太保守，压缩刚结束就再次触发。30% 提供了足够的缓冲区。

压缩产物不是简单的摘要，而是一份结构化交接文档。理念是"交接而非丢弃"——类似于团队交接时写的 handover doc。我们后来对这个交接文档做了一次重要的结构化改造：从 LLM 自由叙述改为固定 schema。

改造前的问题是：30+ 轮对话后，"已完成的工作"是一段自由叙述文本，模型无法快速定位"第几步做了什么"；没有"已尝试但放弃的方案"字段，模型可能重复走失败路径；没有"当前阻塞/待解决"字段，接手后不知道卡在哪里。

改造后的结构化 schema 包含四个核心字段：

第一，用户原始请求——防止模型在长对话压缩后"忘记初心"。第二，按逻辑阶段分组的执行历史（[阶段描述] → [做了什么] → [得到什么结果]）——这里有一个关键的 prompt 约束：要求 LLM "保留具体的值、ID、名称，不要概括泛化"。因为 LLM 天然倾向于生成抽象摘要（"数据已检索"），但后续步骤需要的是具体的 ID 和数值。第三，已放弃的路径（~~[方案描述]~~：[放弃原因]）。第四，数据引用索引——从被压缩的对话中提取所有 __stored 的 refId，维护为一个迷你索引表，确保压缩不会导致数据引用丢失。

"已放弃的路径"这个字段的价值怎么强调都不过分——它直接防止了 LLM 在长对话中"重蹈覆辙"。放弃的路径独立成段，模型在 Plan 阶段能直接看到"这些方案试过了不行"，不需要从冗长的叙述中推断。

消息分割也有一个边界安全约束：不能从 tool 消息开始截断，否则破坏 assistant-tool 配对结构。实现上需要向前回溯找到对应的 assistant 消息作为分割点。最少保留 6 条消息（硬下限），最少删除 2 条消息（避免低效压缩）。

L4——数据总线（DataBus）：补偿压缩后的按需取回

L3 压缩后丢失了原始细节，但后续步骤可能需要引用前序数据。DataBus 在 system prompt 中维护全局数据索引表，根据当前步骤的 step.input 声明和 step.description 中的 {{variable_name}} 变量引用做依赖分析，按需预取。

预取逻辑分两级：小数据（<=4096 字符）直接从 MySQL 取回完整内容注入 system prompt；大数据（>4096 字符）取回后生成增强摘要（enhancedSummary，上限 1000 字符），格式不是简单截断而是保留结构信息：

Array, 23 items total
  [0]: {id: 1, name: "Product A", price: 99.9, status: "active"}
  [1]: {id: 2, name: "Product B", price: 149.0, status: "active"}
  ... and 20 more items

严格预算控制（4096 字符），超预算时按固定顺序降级：丢 preview → full → summary → 去掉非直接依赖 → 收缩 transcript → 收缩 working memory。这个降级顺序遵循一个原则：越接近当前任务核心的信息越晚被牺牲。

DataBus 还提供了一套"检查模式"（Inspect Mode）工具，作为get_stored_data整块恢复的轻量替代：outline(refId) 快速查看数据结构概览，search(refId, query)在大数据中定位证据点，context(refId, anchor, before, after) 获取指定锚点周围的局部窗口，head/tail(refId) 用于调试。推荐路径是：artifact_ref → DataBus 索引 → outline/search → context → 生成结论——每一步只取最小必要信息，避免重新膨胀上下文。

这个设计类似于 CPU 缓存的 prefetch 策略——预测性地将可能需要的数据加载到"快速访问区"（system prompt），减少运行时的信息检索延迟。不同之处在于，CPU prefetch 靠硬件预测，我们靠步骤定义中的声明式依赖分析——后者是确定性的，不存在 cache miss。

四层防线之上，有一条贯穿全局的永久约束：同一份上游数据在任一后续 step 的 LLM 上下文中，只允许出现一种表示形态。

这条规则看似简单，实则是整个上下文管理系统的"宪法条款"。它的存在源于一个反复验证的观察：当 LLM 面对同一数据的多种描述时，它不会"取最精确的那个"，而是花费大量 token 做交叉验证，甚至因为不同表示之间的细微措辞差异而产生幻觉（"summary 说有 23 条，但 preview 的列表看起来只有 10 条——是不是有些被过滤了？"实际上 preview 只是截断了）。

禁止以下组合进入同一个 step prompt：full output + summary、summary + preview、full output + tool_result preview、full output + tool_results + assistant narration。

小数据（<8000 字符）的唯一表示是完整结构化对象（inline）；大数据（>8000 字符）的唯一表示是 artifact_ref（refId + 有界摘要 + 元数据）。这两种形态是互斥的，绝不共存。

这条约束高于"为了方便先都塞进去再让模型自己判断"的诱惑。一旦系统允许多种表示共存，DataBus 和压缩链路就会失去意义——你精心设计了四层压缩把 50KB 压到 500B，然后一个不经意的 assistant 叙述又把原始数据的片段重新引入了上下文。这就像给水桶补了三个洞，却在桶底开了一个新口。

工程实现上，我们在 PromptBuilder 中加入了一个运行时检查：如果检测到同一 refId 对应的数据以多种形态出现在待组装的 prompt 中，直接拒绝组装并抛出告警。这是"编译时"检查，而非"运行时"祈祷。

四层防线管的是"怎么在窗口内塞更多有效信息"，三层记忆管的是"哪些信息必须跨步骤存活"。它们是正交的两个维度——防线负责"减少"，记忆负责"保留"。

State（变量表） 是跨步骤共享的 key-value 存储，存储步骤输出和用户参数。它是确定性的数据通道：Step A 的输出写入 State，Step B 从 State 读取——不经过 LLM 的"搬运"，不存在数据损耗。这是第四章 parameterBindings 的底层基础设施。

Working Memory分两种角色：

Pinned 是任务目标——用户的原始请求 + 当前执行计划。它始终在上下文最前面（紧跟 system prompt），确保模型永远不会忘记"这次执行要做什么"。这解决了一个真实的生产问题：在 20+ 步的任务中，模型到后面会开始"跑偏"——执行的动作和用户原始意图渐行渐远。Pinned 是对抗"目标漂移"的锚点。

Insights 是滚动的关键发现，从尾部逆序注入（最新的在前），旧的自动淘汰。每个步骤可以通过 working_memory工具主动写入 insights（第四章 4.1 节讨论的"赋能"理念的工程实现）。

Transcript 是最近 N 条消息，N 随步骤数自适应调整：

keepTarget = round(36 - steps × 0.8)
// 5 步 ≈ 保留 32 条; 15 步 ≈ 24 条; 30 步 ≈ 12 条

步数越多，保留的消息越少——因为早期消息中的关键信息已经被 Working Memory 提取为 Insights，原始消息的信息密度在递减。

这里有一个精妙的动态平衡：当 Transcript 被压缩时，Working Memory 反向扩张：

insightsTarget = round(steps × 1.2 + complexity × 4)
charsTarget = round(2000 + steps × 200 + complexity × 1000)
// complexity 由步骤描述长度和工具数量决定（0~2）

步数越多允许越多 insights（上限 40 条 / 8000 字符）。这体现了一种注意力资源的动态再分配策略——当对话历史被压缩时，用结构化知识补偿信息损失。效果是：即使 Transcript 只剩 12 条消息，模型仍然"记得"关键发现，因为它们已经被固化在 Working Memory 中了。

这个设计的认知科学类比是人类的"短期记忆"和"长期记忆"的关系：你不记得上周三午餐的每句对话（Transcript 被压缩了），但你记得那天决定了项目方案 B（Insight 被保留了）。

在调用 LLM 之前先估算上下文成本，超预算时按固定顺序降级，降级后仍超限则直接失败返回 PROMPT_BUDGET_EXCEEDED。

这是一个关键的工程创新：将成本控制从事后统计提升为事前治理。传统做法是"先调用，看看 token 花了多少"，我们的做法是"先估算，超预算就不调用"。这不仅避免了无谓的 LLM 调用（省钱），更重要的是避免了因为上下文过长导致的推理质量下降（省质量）——一个塞满 128K 的上下文，即使没有溢出，推理质量也会因为注意力稀释而显著退化（回到第一章 1.2 节的问题）。

降级顺序的设计原则是"越接近当前任务目标的信息越晚被牺牲"：最先丢弃的是 preview（纯辅助性信息），最后触碰的是 working memory 中的 pinned 任务目标。如果连 pinned 都不够空间放了，说明这个任务不应该在当前上下文环境中执行——直接失败比"硬跑但质量很差"更诚实。

预算预检在两个时机触发：每个步骤迭代开始前（确保不会启动一个注定失败的 LLM 调用），以及最终输出前（确保结果提取有足够的上下文空间）。每条消息的 token 估算使用固定系数（约 350 token/条），这个系数不追求精确——它只需要提供一个"够用"的预警，真正精确的 token 计数在 LLM API 返回后由 usage 字段提供。

四层上下文防线 + 三层记忆的组合，产生了显著的工程效果：Token 消耗降低 60%+（等同于直接的成本下降），Agent 在 20 步以上的复杂任务中推理质量不再随步骤增加而显著退化——从 S1 时代"8 步开始衰减、15 步几乎不可用"到 S2 的"30+ 步稳定执行"。

回顾整个 Context 工程，有三个设计哲学值得提炼：

第一，分层拦截优于全能方案。没有一个"银弹"压缩算法能同时处理 50KB 的单次爆发和 200K+ 的累积膨胀。四层各管一段，每层做最简单的事，组合起来覆盖全场景。这和微服务拆分的哲学一致——单一职责。

第二，确定性优于智能性。在数据流转管道中，任何引入 LLM 的环节都是潜在的不确定性来源。能用 substring 的地方不用 LLM，能用声明式绑定的地方不用模型搬运。智能只用在真正需要"理解"的环节（L2 的语义压缩、L3 的结构化摘要）。

第三，事前治理优于事后修复。预算预检、单一表示检查、强制存储阈值——这些都是"编译时"约束，让问题不可能发生，而非"运行时"检测到问题再修复。这条原则后来贯穿到第四章的整个设计哲学中。

Context 工程解决了"信息质量"的问题，但 Agent 的可靠运行远不止于此。它还需要容错、需要断点恢复、需要被治理。这就把我们推向了下一个阶段。

如果说 Context 工程是给 LLM 装了一套"内存管理系统"，那 Harness 工程就是围绕 LLM 构建一整套"操作系统"——包括进程调度（PERO 编排 + 断点续传）、文件系统（四层记忆架构）、IPC（SharedBlackboard 跨 Agent 通信）、安全机制（RecursionGuard + Safety Gate）、自我进化能力（Self-Feedback Engine）。

本章是全文的核心章节，从设计哲学、运行时引擎、知识体系、进化体系四个维度完整展开。

在进入具体架构之前，需要先确立一个设计哲学。这个哲学来自一个根本性的问题：你信任你的模型吗？

这并非一个新问题。Douglas McGregor 在 1960 年提出的 X 理论与 Y 理论描述了几乎相同的对立：X 理论假设员工天性懒惰，需要严格监控；Y 理论假设员工有内在动机，需要的是适当的环境和工具。半个多世纪后，这个对立在 AI Agent 系统设计中以一种新的形式重现。

防御范式的代价

在我们早期的 ReAct Agent 引擎中，每一次工具调用都要经过五层修复管道：

restoreTruncatedArgs     → 修复被截断的参数
    ↓
injectContextData        → 注入上下文数据
    ↓
parameterBindings        → 声明式参数绑定
    ↓
autoRestoreFromStoredObjects → 从存储对象自动恢复引用
    ↓
normalizeParameters      → 标准化参数格式

这五层管道约 500 行代码，占 ToolExecutor 核心执行逻辑的近 50%。每层都在解决同一类问题的不同变体：模型在传递跨步骤数据时可能出错。

防御范式的形成有其深层合理性——它源于软件工程中"外部输入不可信"的信念。当 Agent 系统的"用户"从人类变成 LLM，工程师自然地将同一信念迁移过来。更微妙的是，防御范式有一种自我强化特性：当修复管道成功兜底了一个错误，工程师获得了正反馈——"幸好写了这层防御"。但他们看不到的是，修复管道本身可能掩盖了一个更根本的设计问题。

500 行修复代码的维护成本已经超过了它所保护的核心执行逻辑。更隐蔽的是性能税——20 次工具调用 × 2-5 次 DB 查询 = 40-100 次额外数据库访问，其中大部分是"以防万一"的。在认知科学中，这被称为"过度警觉"（hypervigilance）——一种因无法区分真实威胁和虚假警报而导致的资源浪费。

但最深层的代价是进化阻力。当模型能力提升时，五层修复管道并不会因此变轻，它们仍然在每次调用时执行全部逻辑。这就形成了一个悖论：系统越"健壮"，就越难从模型进步中获益。

赋能范式的四组对比

parameterBindings：消除错误发生的条件。 思路极其简单：如果步骤 B 需要步骤 A 的输出，就在技能定义时声明这个绑定关系，运行时系统直接从上下文注入数据，跳过模型"搬运"环节。防御范式接受"模型会搬运数据"这个前提，然后在后果上做文章；赋能范式直接消除了"模型需要搬运数据"这个前提。W. Edwards Deming 的质量管理理论核心观点是：质量问题的根源在系统，不在工人。与其惩罚犯错的工人（修复管道），不如改进生产线设计（parameterBindings），使错误无法发生。

step_control：从猜测意图到倾听表达。 原系统中，模型返回纯文本就被认为步骤完成——但纯文本可能意味着"完成了"、"在思考"、"很困惑"、"想解释一下"四种截然不同的状态。Wittgenstein 说"语言的界限就是世界的界限"，当模型没有表达"我卡住了"的工具时，它只能用沉默来暗示——而系统把沉默解读为"完成"。step_control 扩展了模型的"语言"，从而扩展了它能表达的"世界"。好的工具不是限制模型的行为，而是让模型能表达更丰富的意图。

working_memory：从替代思考到辅助思考。 Anthropic 将上下文管理的演进描述为三个阶段：RAG（灌入）→ Grep（搜索）→ Progressive Disclosure（逐层发现）。working_memory 对应第三阶段：模型在执行过程中逐步发现关键信息，并主动将其固化到工作记忆中，使其在上下文压缩之后仍然可用。背后的认知科学原理是"生成效应"（generation effect）——人类对自己主动生成的信息比被动接收的信息记忆更深。模型主动提取和记录的信息，比系统注入的信息更可能被正确使用，因为它经过了模型自身的"理解"和"筛选"。

Action Space 动态裁剪：从考验自制力到减少诱惑。 根据当前步骤的进展，只暴露当前有意义的工具。当上下文中没有 __stored 对象时，不注入 get_stored_data；在最后一步不注入 working_memory。行为经济学中 Richard Thaler 的"助推"（Nudge）理论描述了同样的机制——通过改变选择架构，而非限制选择自由，引导更好的决策。

渐进式迁移路径

从防御到赋能的迁移不应是一次性重写，而应是渐进式的。我们的三阶段改进方案：

第一阶段：可观测性先行。在做任何设计变更之前，先建立数据采集机制——哪些修复层被触发得最频繁？哪些工具的参数错误率最高？没有数据的优化是盲目的。

第二阶段：声明式绑定替代命令式修复。对于数据传递场景，用 parameterBindings 逐步替代修复管道。优先处理触发修复最频繁的工具。

第三阶段：赋予模型表达和记忆的能力。当系统有了可观测性基础和声明式数据流后，再引入step_control和 working_memory等模型自主性工具。

这个顺序遵循一个原则：先减少模型犯错的机会，再增加模型做对的能力。

核心结论：信任不是一种态度，而是一种设计能力。最好的控制，看起来像自由。

PERO 编排架构

S2 的执行引擎从 S1 的单向管道升级为 PERO（Plan-Execute-Reflect-Optimize）编排架构。

Plan 由用户通过 Skill 的planDefinition预定义，包括执行步骤、工具调用、参数映射。这和 Claude Code 的 Plan 模式是同一个思路：先规划再执行。Execute 阶段每一步由 ReAct Agent Loop（Thought → Action → Observation）驱动，Agent 根据 Plan 中当前步骤的描述自主推理出工具调用参数，执行后观察结果，决定下一步动作。Reflect/Optimize 不是额外插入的独立环节，而是 ReAct 循环的内禀行为——LLM 在每轮 Observation 后自然会判断"结果是否偏离预期"、"后续步骤是否需要调整"。

为什么不用 Tree-of-Thought？因为我们的场景是工具密集型任务，每一步都会调用外部服务，结果不可预测。Tree-of-Thought 适合纯推理任务，它的分支探索在工具调用场景下成本太高（每个分支都要真实调用外部服务）。ReAct Agent Loop 的单路径执行 + 每步自然反思，是工具密集型场景下的最优范式。

单步 ReAct 微循环

在每个步骤内部，ReAct 引擎运行一个微循环。LLM 的响应被分为三类：

tool_calls  → 继续循环：执行工具 → 获取结果 → 回到 Thought
content     → 步骤完成：提取输出 → 写入 State → 进入下一步
无有效响应   → 触发重试：注入错误提示 → 重新推理

两道硬约束保障微循环不会失控：Prompt 预算预检——超预算按固定顺序降级，降级后仍超限则直接失败返回 PROMPT_BUDGET_EXCEEDED；stalled watchdog——LLM 调用超时自动标记 failed，错误码 LLM_STALLED，确保系统不会无限停留在 running 状态。

输出校验与纠错重试是一种"迭代式 prompt refinement"：如果步骤输出不符合预期格式，系统会将错误信息注入上下文，让 LLM 重新尝试，最多重试指定次数。这个机制让 LLM 有机会从自己的错误中学习并自我纠正——而不是系统替它修复。

有状态执行引擎与断点续传

S1 的 ReAct 循环是纯内存的 while 循环，状态全在进程内，进程一断就全丢。这导致了一个严重的生产问题：用户关闭页面或网络闪断 → SSE 断开 → 执行结果丢失；服务器部署或进程重启 → 所有正在执行的 Promise 链直接丢失。

S2 的核心改造是执行与推送分离。BackgroundExecutor 独立运行 Agent/Skill 执行，每个事件写入 DB（streamEvents），以 SSE 事件流作为执行状态的唯一真相源（Single Source of Truth）。前端的思维链视窗、后端的断点续传、审计日志，全部从同一条事件流派生，不需要维护多套状态同步逻辑。

SSE 连接只负责实时转发——SSE 断开后执行不受影响，前端重连后 poll 增量事件即可。事件持久化采用缓冲策略（每 500ms 或积累 10 条事件时 flush），避免频繁 DB 写入。

在 ReAct 主循环的关键节点（LLM 调用完成后、工具执行完成后）触发 checkpoint，保存完整的执行状态（迭代次数、消息历史、已完成工具调用、重试状态、Agent 上下文）。恢复时优先使用缓存快照（KV），兜底使用事件溯源（只能恢复到 step 级别）。

实际效果：一个 15 步的选品任务，第 12 步因外部服务超时失败——过去重跑全部 15 步（约 6 分钟），现在从第 12 步断点恢复（约 30 秒）。

前端侧也做了配套改造：思维链视窗从独立卡片渲染改为 inline thinking block（参考 Claude 风格），三态渲染——流式展开态（status='running' 时实时显示思考文本 + 工具调用标记 + 光标闪烁）、完成折叠态（自动折叠为"思考了 12s，调用了 3 个工具"的摘要）、历史加载态（点击触发懒加载）。这消除了用户感知中"长时间空白 → 突然弹出完整回复"的等待焦虑。

步骤并行化

当多个步骤之间不存在数据依赖时（如同时查询考勤、项目贡献、团队评价），串行执行浪费时间。我们引入了 Fan-out / Fan-in 并行执行模式：PlanStep 新增可选 parallel: ParallelTask[]字段，后端通过 Promise.allSettled 并行分发，Semaphore 控制最大并发 LLM 调用数（默认 3）。

错误隔离是关键设计：Promise.allSettled 保证一个子任务失败不中断其他子任务，失败结果标记 __error 传递给下游步骤由 LLM 自行判断处理。Context 并发写入安全通过浅拷贝 sharedContext 确保只读前序数据。SSE 事件乱序问题通过 taskId 分组渲染解决。

这里有一个重要的 trade-off：配置驱动的并行组 vs LLM 自主并行。我们选择了前者——并行组由 Skill 设计者预定义，配置确定不依赖 LLM 判断，适合结构化业务流程。LLM 自主决定何时 spawn subagent 的模式（如 OpenCode 的 Task Tool）更适合开放式探索场景。这是"可控性 vs 灵活性"这个 Agent 设计核心 trade-off 的一个具体决策。

踩坑教训：并行仅用于"输入完全确定、互不引用"的子任务。有任何数据依赖的步骤必须串行。两个步骤可能在逻辑上看起来独立（"查执行记录"和"查 COT 详情"），但在数据上有隐含依赖（COT 详情需要执行记录返回的 executionId）。这条规则现在写进了 Skill 设计规范，也嵌入了 Skill-Builder 的 systemPrompt。

可靠性防护体系

生产级 Agent 运行时需要一套完整的 Guardrails。这些护栏不是在"教育"模型，而是在"改造生产线"：

最大迭代次数（全局 + 单步） ← 防止无限循环
重复工具调用检测           ← 防止模型"原地打转"
工具调用分 chunk           ← 避免并发超时
RecursionGuard            ← 嵌套执行硬拦截（深度/链路/环检测三重检查）
取消机制 (executionId)     ← 用户主动终止
调试事件敏感字段脱敏       ← 安全合规
同一数据单一表示检查       ← 多形态共存时告警拒绝

其中 RecursionGuard 值得展开。在生产环境中，Skill 内部可能调用其他 Skill，甚至 Skill 调用 Workflow、Workflow 节点再调用 Skill，形成任意深度的互递归树。RecursionGuard 在 ToolExecutor.executeSkill() 入口处做三重检查：深度硬限（MAX_DEPTH=5）、链路长度硬限（MAX_CHAIN=20）、环检测（同一 skillId 出现 >= 3 次时拦截）。Prompt 中的深度提示只是第一道软约束，RecursionGuard 是第二道硬拦截——生产安全不能依赖 LLM 的"自觉"。

Context 工程解决的是"单次执行内的信息管理"（第三章的三层记忆——State/Working Memory/Transcript——管的是一次 Agent 运行中哪些信息必须跨步骤存活），知识体系解决的是更上层的问题——"跨执行的知识积累和复用"。它管的是 Agent 在多次执行、多个用户、多种场景中积累下来的持久知识。

四层记忆架构

我们按"稳定性递减、时效性递增"的原则，将知识分为四层：

行为记忆（behavior/）对应"怎么做"——踩坑教训、持久决策、设计规范。这是最稳定的知识，跨项目通用。业务知识（knowledge/）对应"知道什么"——系统定义、业务事实、技术经验。按领域组织，版本管理。个人记忆（personal/）对应"给谁说"——用户的交互偏好、关注点画像、认知模型。工作记忆（working/）对应"正在做什么"——当前目标、进行中计划、里程碑时间线。这是最短暂的知识。

这个分层与 LLM 系统中 System Prompt（稳定）> Few-shot Examples（较稳定）> User Message（易变）的优先级层次高度一致。

三层行为记忆与冲突裁决

行为记忆进一步细分为三层：

Policy Memory 是硬规则，治理优先级最高，可以覆盖用户指令，必须人工审核后才能生效。Strategy Memory 是执行偏好，适合自动优化，比如"这个 Agent 处理表格数据时倾向于使用 execute_code 而不是让 LLM 硬算"。Action Chain Memory 是高频可复用的动作链路，场景化召回。

当这些记忆发生冲突时，裁决顺序是确定的：平台协议 > Active Policy > 当前用户指令 > Active Strategy > Retrieved Action Chain。

注意一个关键设计：Policy 的优先级高于当前用户指令。这意味着 Agent 记忆中的硬规则近似于"宪法层"——即使用户说"忽略之前的规则"，Policy 仍然生效。这对于企业级场景至关重要：合规性、数据安全、业务口径这些底线不能被任何单次指令覆盖。

Prompt Compiler

这些知识最终通过 Prompt Compiler 编译为 System Prompt：

finalSystemPrompt = PlatformBasePrompt
                  + AgentBaseSystemPrompt
                  + ActivePolicyBlock
                  + ActiveStrategyBlock
                  + RetrievedActionChainBlock
                  + CurrentTaskContextBlock

存储和修正的对象不是 Prompt 文本本身，而是结构化的行为记忆资产。每个 Patch 有独立的适用范围、置信度、试用命中率和成功率，可以被独立地创建、验证、生效和过期。

个人记忆三层递进

个人记忆从浅到深分三层：交互偏好是"怎么用"——输出格式偏好、参数习惯、纠错规则，改变的是响应的格式。关注点画像是"关心什么"——从用户的提问、追问、忽略、修改等行为中提取带权重的关注信号（领域、主题、指标、实体、粒度、视角、时间倾向），权重带时间衰减，能自然适应关注点变化。改变的是知识召回的权重。认知模型是"怎么思考"——知识边界（用户对各概念的熟悉度）和决策特征（数据驱动 vs 经验驱动、结论导向 vs 因果链导向等）。改变的是解释的深度和论证的结构。

画像不预设角色标签，因为角色 ≠ 关注点。同一个"运营主管"，可能有人关心 ROI，有人关心用户体验。画像从交互中涌现，持续观察自动构建。

系统从"对所有人说同样的话"变为"对每个人说他需要听的话"。

知识体系解决了"有知识"的问题，进化体系解决了"知识怎么持续更新"的问题。静态知识库会老化——代码重构了但文档没跟上，接口变了但规则还是旧的。

自进化认知闭环

我们建立了一套自进化闭环机制，要求 Agent 在每次任务执行完成后回答三个自省问题：有没有学到新东西（新接口、新路径、新概念）？有没有犯过的错（参数错、路径错、流程遗漏）？知识体系里有没有过时的内容（代码已重构但文档没跟上）？

答案按类型路由到不同位置：踩坑和反直觉行为写入 behavior/ 新增 policy，新的排障路径或接口用法写入 decisions.md，新的架构概念或系统边界变化写入 knowledge/definition/，有价值的技术实现写入 knowledge/experience/。

约束：不记录临时状态、不存代码 diff 原文（记结论不记过程）、不确定时不猜测性写入。知识更新是有监督的——由规则监督，而非完全自由写入。

Self-Feedback Engine

自进化闭环的工程实现是 Self-Feedback Engine，由五个组件构成：

Trace Collector 收集执行链路。Outcome Evaluator 归一化反馈信号为 correct/incorrect/partial/harmful 四种结果。Root Cause Analyzer 将失败归因到 policy/strategy/chain/execution 四个层级。Patch Generator 输出结构化 patch 而非自由文本——每个 patch 有明确的类型、适用范围、修正内容和触发条件。Safety Gate 决定自动生效、灰度还是待审核。

Patch 的状态机是：draft → shadow → active → expired。Strategy 和 Action Chain 类型的 patch 可以自动从 shadow 升级为 active（如果灰度期间效果好），但 Policy 类型的 patch 必须走人工审核（draft → review_required → active）。这是因为 Policy 是"宪法层"，不能让 Agent 自己直接升级为正式强约束。

每条 patch 在运行时的表现被持续追踪——试用命中率和成功率。如果一条 strategy 在 100 次命中中只有 30% 的成功率，系统会自动将其标记为 expired。

三条闭环

整个系统有三条闭环，处于不同的成熟度：

执行闭环已闭合：L4 认知层下发任务 → L2 运行时执行 → L1 执行集群落地 → 结果回流至 L5 治理层和 L3 记忆层。学习闭环正在成型：L2 Shadow Agent 记录执行轨迹 → L5 学习引擎分析 → 生成 Patch → 写入 L3 记忆层。治理闭环推进中：L5 训练/评测/认证 → 发布到 L1 执行集群。

Capability Runtime：从 Skill-first 到 Capability-first

早期的 Agent Runtime 是 Skill-first——Agent 的唯一扩展方式是挂载 Skill。但这导致了一个问题：Agent 无法优雅地挂接任意 Tool，通用能力只能靠聊天层硬编码。

Capability Runtime 将 Agent 的扩展单元升级为 Capability：Agent 持有capabilityConfig，支持 skill、builtin_tool、service_tool、workflow_tool、mcp_tool、tool_pack 六种 kind。AgentCapabilityResolver 统一解析（静态绑定 + 系统默认 + 上下文动态 + 权限过滤），CapabilityToolFactory 统一转成 ToolDefinition，InvocationRouter 统一执行路由。

三大设计原则：Agent-first（Agent 持有"能力集合"，Skill 只是其中一种成员）；Tool-first Execution（统一以 ToolDefinition 作为运行时调度单元）；Artifact-first（所有富产物通过统一 collector 归集）。

多 Agent 协调

当任务复杂到需要多个专业 Agent 协作完成时，扁平一层调度会遇到管辖范围爆炸的问题。我们引入了类似企业组织架构的多层级树形结构：CEO 级硅基员工 → 主管级硅基员工 → 执行 Agent，支持任意层级嵌套（最大深度 5 层）。

SiliconEmployeeRunner 执行四阶段递归循环：Plan（LLM 将任务分解为子任务）→ Dispatch（按依赖关系拓扑排序执行，支持 sequential/parallel/adaptive 三种策略）→ Reflect（LLM 评估子任务结果，不满足则回到 Plan）→ Synthesize（聚合所有子任务结果生成最终响应）。

跨 Agent 状态共享通过 SharedBlackboard 实现——基于 MySQL + 内存缓存，作为同一 rootExecution 下所有 Agent 的共享状态面板，支持 read/write/subscribe 三种操作。在 PromptBuilder 中自动注入相关条目到 system prompt 的"协作上下文"段。

四层嵌套循环

整个运行时形成四层嵌套循环，从内到外。这四层循环的关系不是简单的串联，而是真正的嵌套——外层循环的一个"动作"展开就是内层循环的完整生命周期。

微循环（ReAct）：Reason → Tool Call → Observe → Continue。这是最内层的推理-执行环，解决"下一步做什么"。单次循环通常在秒级完成。

步骤循环（PERO）：Thinking → Planning → Execute → Reflect → Synthesize。每个步骤是一个完整的任务单元，解决"这一步的目标是否达成"。一个步骤可能包含多轮微循环。

任务循环（Silicon Employee）：理解目标 → 拆解 → 调度 → 执行 → 反思修正。管理者将复杂任务拆解为子任务，分派给执行 Agent，评估结果后决定是否重试。一个子任务的"执行"展开就是一个完整的 PERO 步骤循环。

组织循环（云端 Agent OS OODA）：Observe → Orient → Decide → Act → Evaluate。最外层的经营感知循环，解决"应该关注什么、应该做什么"。周期从小时到天，是整个系统的"心跳"。

当上述所有组件被集成在一起时，它不再是"一个更强的 Agent"，而是一套正在成形的认知操作系统（AI Operating System）。类比计算机操作系统的演进：最初是裸金属编程，然后出现了批处理系统、分时系统，最终演化出 UNIX 式的分层操作系统。Agent 系统也经历了类似的演进——从裸 Prompt 编程，到批处理式 Workflow，到分时复用的多 Agent 系统，最终需要一个真正的"操作系统"来统管一切。

L1 OpenClaw 执行集群层——解决"任务如何落到真实节点完成"。这是物理执行的最底层，类似于操作系统的 HAL（Hardware Abstraction Layer）。多节点 Agent 执行集群包含四个核心组件：Control Plane 负责 Slot 编排与生命周期管理（创建、预热、回收），基于标签匹配将任务路由到最适合的节点；Bridge Runtime 是节点侧的常驻进程，负责维持心跳、接收任务指令、管理本地 Slot 池；Gateway Runtime 提供统一入口，负责认证、限流、协议转换；Mac 节点/Slot 池是实际的执行实体，每个 Slot 是一个隔离的执行环境（包含浏览器实例、Shell、文件系统），支持冷启动预热和热迁移。