从 Prompt 到 Harness：企业级 Agent 工程的完整演进之路

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

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

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

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

更棘手的是，这不是一个"截断旧消息"就能解决的问题。四个原因让简单截断变得不可能：第一，截断的 JSON 是残废数据，LLM 无法从中提取有效信息——一个被砍掉后半段的嵌套 JSON 连 parse 都无法 parse。第二，OpenAI 协议要求 tool 消息必须紧跟其对应的 assistant tool_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  → 继续循环：执行工具 → 获取结果 → 回到 Thoughtcontent     → 步骤完成：提取输出 → 写入 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、文件系统），支持冷启动预热和热迁移。

一个关键的设计决策：Slot 是无状态的执行单元。任务状态不在 Slot 里持有，而在 L2 的执行账本中。这使得 Slot 可以随时被回收或迁移，任务在另一个 Slot 上恢复执行——这就是第四章讨论的"断点续传"在分布式环境下的延伸。

L2 Agent Runtime 层——解决"任务如何被可控、可恢复、可审计地执行"。这一层是第四章所有运行时机制的集大成：自由对话引擎处理非结构化交互，ReAct Skill 引擎执行单步微循环，PERO Step 引擎管理多步骤编排，执行账本（Execution Ledger）以事件溯源模式记录每一个状态变更，SSE 事件流作为实时通信通道，断点续跑机制保障故障恢复。

L2 的一个重要特性是执行模式的自适应切换：同一个 Capability 可能在"对话模式"（单轮 Q&A）和"任务模式"（PERO 多步编排）之间动态切换。判断依据是意图识别的复杂度评分——简单查询直接走对话模式，复杂操作自动升级为 PERO 编排。这让系统对用户来说是"无感"的：用户只是在和一个 Agent 对话，但后台的执行引擎在根据任务复杂度自动选择最优执行路径。

L3 记忆与语义层——解决"系统如何越用越懂人、越跑越会做、越久越懂业务"。三层记忆体系（个人记忆、Agent 记忆、业务记忆）在第四章已详细展开。这里补充一个关键组件：DataProductStore 共享黑板。它不仅是跨 Agent 的状态共享（SharedBlackboard），还承担了语义索引的角色——每个数据产物（report、decision、insight）都带有语义标签，支持基于意图的检索而非仅凭 key 的精确匹配。

这意味着当一个 Agent 需要"上个月的客户流失分析"时，它不需要知道具体的数据 key，而是描述意图，DataProductStore 返回语义最相关的数据产物。这是从"文件系统"到"知识图谱"的跃迁。

L4 Agent OS 认知层——解决"感知什么？判断做什么？调度谁来做？做完怎么评？"。这是组织级 Agent 系统的"大脑皮层"。感知模块持续监听业务数据流中的异常信号（第 5.4 节的 Sensor Skill）；判断模块将异常信号映射为可执行的任务（Reasoner Skill 做归因）；调度模块决定任务由谁执行（Silicon Employee 负责分派和编排）；评估模块在执行完成后闭环验证效果。

L4 的核心创新是注意力经济：组织每天产生的信号远超 Agent 处理能力，不可能什么都管。注意力控制器维护一个动态优先级队列，根据信号的严重性、时效性、影响面做排序，只让最重要的事情进入"认知处理通道"。这和人类管理者的工作方式一致——不是什么都亲自做，而是选择性关注。

L5 自主进化与治理层——解决"Agent 怎么安全地变更好？执行结果如何反哺系统？"。这一层涵盖完整的 Agent 生命周期管理：训练（Knowledge Pack → Skill Bundle 编译）、评测（Eval Run 覆盖率和正确率指标）、认证（通过评测门槛后签发证书）、发布（灰度 → 全量的滚动升级）、值班（OnDuty Schedule Policy 决定谁在什么时间段响应）、告警（执行异常实时报警 + 自动降级）、修正（Self-Feedback Engine 生成 Patch）、回流（Patch 生效 → 更新记忆层）。

L5 的设计哲学是：Agent 的进化应该像软件发布一样被治理。不受管控的自我进化是危险的（Agent 可能"学会"绕过安全约束），但完全静态的 Agent 又无法适应业务变化。治理层在这两个极端之间找平衡——Strategy 和 Action Chain 允许自动进化（快速适应），Policy 必须人工审核（守住底线）。

系统的一等对象不是 workspace / terminal session / tool list，而是 execution request / workflow context / planDefinition / execution ledger / governance contract。这意味着做的不是"通用 Agent 工具云化"，而是业务执行范式工程化。这个区分至关重要——前者是给开发者用的 SDK/IDE，后者是给组织用的执行操作系统。

五层架构的顶层设计是"云端 Agent OS 组织大脑 + OpenClaw 执行操作系统"的双 Agent 平台。这个分离不是技术偏好，而是来自一个深刻的认知：思考和执行是两种根本不同的能力，混在一起会互相拖累。

类比人类组织：战略部门和执行团队如果混编，要么战略被执行细节淹没（CEO 亲自改 bug），要么执行缺乏深度思考（一线员工凭直觉做决策）。分离带来专注，专注带来深度。

核心原则是：云端 Agent OS 持有认知真相（知识、规则、标准），OpenClaw 持有执行真相（在岗状态、任务单、Slot 占用），双方通过显式 Contract Layer 协作，不直接互相侵入。

Agent OS Skill 负责认知层任务（知识理解、计划生成、结果评估），不操作浏览器、不占用 slot——它的计算资源 100% 用于"想清楚"。OpenClaw Skill 负责执行层任务（browser/desktop/shell 操作、证据采集），不定义组织知识——它的资源 100% 用于"做到位"。铁律：Agent OS 不修改运行中 slot 状态，OpenClaw 不修改组织知识真相。

Contract Layer 是双方的"外交协议"，定义了四种交互契约：TaskOrder（Agent OS 下发的结构化任务单，包含目标、约束、验收标准）、StatusReport（OpenClaw 回报的执行状态和阶段性产物）、EvidencePackage（OpenClaw 采集的执行证据，用于 Agent OS 做效果评估）、SlotAllocation（Agent OS 请求执行资源时的分配协议）。

这个分离带来的最大价值是：认知层和执行层可以独立演化。当更强的推理模型出现时，只需要升级 Agent OS 的认知内核，执行集群完全无感；当新的执行环境出现（比如 Android 设备、IoT 终端），只需要扩展 OpenClaw 的 Bridge Runtime，认知层无需任何修改。这就是关注点分离在 AI 系统中的工程红利。

治理闭环

治理闭环的完整链路形成一个从知识到执行再回到知识的完整环路：Knowledge → Knowledge Pack → Skill Bundle 训练 → Eval Run → Certification → Agent Release → OnDuty → Schedule Policy → Task Order → Execution → Alert/Remediation → Learning Sample → 云端 Agent OS 采纳更新。

每个环节都有明确的质量门控（Quality Gate）：Knowledge Pack 需要经过格式校验和一致性检查；Eval Run 必须达到预设的准确率阈值；Certification 由自动化评测 + 人工抽检双重确认；Release 采用灰度策略（先 5% → 20% → 50% → 100%）。

Agent 的发布状态机是：candidate → shadow → probation → active → degraded → retrain → offboard。关键的状态转换逻辑：shadow 期间 Agent 接收真实任务但结果不生效（仅记录和对比），这类似于软件的 A/B 测试；probation 期间结果生效但有人工审核兜底；degraded 由告警系统自动触发，当连续 N 次执行失败率超过阈值时 Agent 被自动降级，停止接收新任务。

我们做的不是 Claude Code 竞品，而是企业执行系统。两者服务的用户群体、解决的核心问题、面临的约束条件都截然不同——差异体现在三个层面：

一等对象不同。 这是最根本的差异。我们的一等对象是带业务上下文的执行请求（Execution Request 不是一个简单的 prompt，而是携带了 planDefinition、parameterBindings、knowledge scope、governance contract 的结构化指令）、workflow 编排器（管理步骤间的数据流转和条件分支）、类型化数据流转与物化策略（输出不是文本，而是带 schema 的结构化数据产物）、结构化审计与计费（每一步的 token 消耗、执行时长、调用链路都被记录用于成本分摊）。Claude Code 的一等对象是 workspace、session、tools、subagents——它面向的是开发者的探索式工作流，不需要这些企业级的管控能力。

数据流转范式不同。 我们靠显式状态流转——参数绑定（A 步骤的输出字段 X 绑定到 B 步骤的输入参数 Y）、context path 提取（从嵌套 JSON 中按路径精确取值）、outputMode（决定步骤产物以何种形式持久化）、inputMaterialization（决定步骤输入以何种形式物化到上下文）、inheritedContext（子 Skill 继承父 Skill 的哪些上下文变量）。这些机制确保数据在多步骤、多 Agent、多层级嵌套中零损耗地流转。Claude Code 靠模型记忆——上一轮说什么，下一轮自己想办法记住。这在 3-5 步的开发任务中足够优雅，但在 15+ 步的业务流程中会因为"数据搬运谬误"（第一章 1.3 节）而崩溃。

知识定位不同。 在我们的系统中，知识不是"参考资料"，而是强规则执行面。这意味着：知识按业务域限定适用范围（A 业务的规则不会泄漏到 B 业务）；知识有预召回和运行时检索两种模式（高优先级规则预装，长尾规则按需检索）；检索命中的知识结果会继承给后续步骤和子 Skill（不需要每步重新检索）；知识约束口径和边界，违反时系统拒绝执行而非仅仅"建议"。在 Claude Code 中，知识是通过 CLAUDE.md 注入的上下文参考——它是"建议"性质的，模型可以选择忽略。

这三个差异指向一个总结：Claude Code 解决的是"个人开发者如何更高效地编程"，我们解决的是"组织如何将业务流程可靠地委托给 AI 执行"。前者的容错靠人类兜底（开发者看一眼代码就知道对不对），后者的容错必须内建于系统（业务人员无法审核 Agent 的每一步推理）。

在 Agent 运行时之上，我们还在探索从"工具型 Agent"到"认知型 Agent"的跃迁。工具型 Agent 是"人说什么做什么"的执行器，认知型 Agent 是"自己知道应该做什么"的思考者。这个跃迁的路径被我们抽象为五层认知模型——每一层解决的问题层次递进，上层依赖下层作为基础设施。

L1 语义层：让所有人说同一种"数据语言"。 MetricRegistry 统一指标口径 + 版本管理。这看起来是最"低技术"的一层，但恰恰是最关键的基础设施。如果"日活用户"在 A 系统指"当日登录"，在 B 系统指"当日有行为"，那么任何上层的感知和推理都建立在沙子上。MetricRegistry 为每个指标定义唯一口径、计算公式、数据源、更新频率和版本历史。当口径变更时，所有引用该指标的 Sensor Skill 自动收到通知并重新校准阈值。

L2 感知层：用正确的工具做正确的事。 Sensor Skill 支持三种触发模式——定时触发（cron 表达式）、事件触发（数据流变更通知）、阈值触发（指标越界告警）。一个关键的设计决策：阈值判断用 execute_code（Python/JS 脚本）而非 LLM。理由很简单——"3.5% > 3.0%" 这种判断不需要花 LLM 的 token，用代码执行确定性 100%，成本几乎为零。LLM 的 token 预算应该留给真正需要"理解"的任务。这是"让系统做系统擅长的事"（第一章 1.3 节）原则的又一次体现。

感知层还有一个"降噪"职责：原始信号量级可能是日均数千条，但真正需要进入推理通道的可能只有几十条。Sensor Skill 的规则引擎负责信号合并（同类异常聚合）、去重（短时间内同一指标的重复告警）、优先级标注（基于影响面和时效性打分）。

L3 推理层：统计先行，LLM 解读。 Reasoner Skill 采用"三步法"——第一步统计归因（用代码跑同比/环比、相关性分析、异常检测算法），第二步 LLM 叙述解读（将统计结论翻译为业务语言），第三步标注置信度（LLM 对自己的解读给出 high/medium/low 置信标签）。

为什么不让 LLM 直接做归因？因为 LLM 的"推理"本质是概率性的模式匹配，面对数值型分析时容易出现"看起来合理但实际上错"的hallucination。统计工具给出的是确定性结论（"上周三开始下降，降幅 12%，同期流量下降 8%"），LLM 负责的是在统计事实基础上做语义关联（"流量下降可能与竞品同期促销有关"）。前者不可能错，后者可能错但有价值。把两者分开，系统的可信度骨架是统计工具保证的。

置信度标注的工程意义在于：下一层（决策层）可以根据置信度决定是直接执行还是需要人类确认。high confidence 的建议可以走自动审批通道，low confidence 的建议必须等人工确认。

L4 决策层：CEO 做选择题不做填空题。 Advisor Skill 将推理层的分析结论转化为可执行的建议选项（通常 2-3 个方案，各有利弊分析），通过 ApprovalGateway 提交给人类决策者。人类看到的不是一份 20 页的分析报告（那等于什么都没说），而是一个结构化的决策卡片：问题一句话描述 + 影响面量化 + 2-3 个方案选项 + 每个方案的预期收益/风险/成本。

ApprovalGateway 支持三种模式：严格审批（所有决策必须人工确认）、阈值审批（影响面低于 X 的自动通过）、事后追认（先执行后通知，限于可逆操作）。模式的选择取决于操作的可逆性和影响面——修改一条文案是可逆的低影响操作，可以事后追认；调整预算分配是不可逆的高影响操作，必须严格审批。

L5 元认知层（Meta-Agent）：知道自己不知道什么。 这是最高层的认知能力，包含三个子系统：

注意力控制器——动态调整采集频率和关注焦点。当系统发现某个业务板块的异常频率上升时，自动提高该板块的 Sensor Skill 采集频率，同时降低平稳板块的频率。这是"注意力经济"的工程实现——认知资源有限，必须动态分配。

自我评估引擎——校验预测是否兑现，校准置信度偏差。L3 推理层给出的"置信度"是否准确？如果标注 high confidence 的判断有 40% 是错的，说明模型过度自信，需要校准。自我评估引擎通过回溯验证（判断生效后实际结果如何）持续校准置信度模型。

能力演化引擎——发现能力盲区，提议新 Skill。当系统连续多次在某类任务上执行失败或需要人工兜底，能力演化引擎会识别这个"盲区"并提议创建新的 Skill 来覆盖。这是"知道自己不知道什么"的工程实现——不仅能做事，还知道哪些事做不好，并主动弥补。

演进路径是：V1 让系统"会做事"（工具执行层面的可靠性）→ V2 让系统"知道做得对不对"（自我评估和置信校准）→ V3 让系统"知道还需要学什么"（元认知和自主进化）。我们当前在 V1 → V2 的过渡阶段，V3 是 FY27 的目标。

回顾一年的工程实践，有五条认知在反复验证中越来越清晰。它们不是孤立的经验，而是彼此关联、互相印证的认知网络。

第一，"LLM 越跑越蠢"是个工程问题，不是模型问题。 上下文中 70% 的噪音数据稀释注意力，换更大的模型也掩盖不了。这条认知的实践意义是：当 Agent 表现下降时，先看上下文质量再考虑换模型。我们在 S2 初期走过弯路——花了两周评估更大参数的模型，最终发现问题出在工具返回的 JSON 没有被压缩。模型换了一轮回来，指标没变；上下文管理做了一周，指标提升 40%。诊断方向错了，一切努力都是浪费。

第二，上下文管理是分层防御的系统工程。 L1 拦截单次大数据，L2 压缩中等数据，L3 压缩累积膨胀，L4 补偿按需取回——四层各管一段，缺一不可。这条认知的深层含义是：没有银弹。业界不断有人提出"一个巧妙的压缩算法解决一切"的方案，但实际上不同粒度的膨胀需要不同的武器。就像网络安全需要防火墙 + WAF + IDS + 审计日志，不是一层能搞定的。分层的另一个好处是降低单层的复杂度——每层只做最简单的事，组合起来覆盖全场景。

第三，Agent 的动作空间必须被治理，能力应以演化方式出现。 不控制 Action Space，工具越多 Agent 越蠢——这是 Claude Code 团队 "Think Like an Agent" 分享中最让我共鸣的观点。工具数量从 5 增加到 50，不是"能力增强 10 倍"，而是"选择困难增加 10 倍"。每多一个工具，LLM 在规划时需要评估的选项空间就大一圈，幻觉和错误选择的概率随之上升。渐进式披露不仅优化了 token economy（少展示 = 少 token = 更聚焦），还定义了 Agent 的成长路径——从能做 3 件事到能做 30 件事，应该是一条有节奏的进化之路，而不是一次性全部暴露。

第四，工具设计有半衰期。 模型能力升级后，旧的防御机制可能变成不必要的约束。好的系统设计应当能从模型进步中"免费"获益。这是一条容易被忽视的认知。我们的五层修复管道在 S1 时期是必需的——那时候模型的参数格式遵从率只有 70%。但到 S2 中期，模型升级后遵从率提升到 90%+，五层管道中有三层的触发率降到了 <5%。如果系统不能感知到这种变化并自动减负，它就永远背负着"对抗旧模型"的历史包袱。这就是为什么第四章强调"可观测性先行"——没有数据就无法知道哪些防御已经过时了。

第五，信任建立不能跳过人工确认。 AI 准确率即使达到 95%，剩下 5% 的错误一旦直接写入数据库，用户会立刻对整个系统失去信任。信任建起来很慢（需要连续 20+ 次正确执行），毁掉只要一次（一个严重错误）。这条认知指导了整个治理体系的设计：Agent 的状态机为什么要有 shadow 和 probation 阶段？因为直接 active 就是跳过了建立信任的过程。ApprovalGateway 为什么要区分"严格审批"和"事后追认"？因为信任是分级别的——对于已经验证 1000 次没出错的操作类型，可以逐步放开自动化。

本文的主线可以用一个类比贯穿：大模型是一块"裸 CPU"，而我们全年的工作就是在为它逐步补齐操作系统的各个子系统。

回顾整条路径，可以看到一条清晰的演进主线：

Prompt 工程阶段，一切围绕一段文本。把角色、规则、约束堆进 System Prompt，靠 ⚠️ 标记和格式强调引导注意力。核心贡献是验证了方向——"AI 能做大促"从概念变成了现实，活动举办效率提升 50%。天花板是指令遵从率在长链路中急剧下降（3 步 95% → 10 步 <70%），上下文无法管理（每步都在膨胀），执行无法容错（纯内存 while 循环）。

Context 工程阶段，一切围绕信息管理。四层上下文防线 + 三层记忆 + 单一表示原则 + Prompt 预算预检。这对应操作系统的"内存管理子系统"——解决的是有限资源（128K 上下文窗口）的高效分配问题。核心贡献是让 Agent 在 30+ 步的复杂任务中推理质量不退化，Token 消耗降低 60%+。天花板是单次执行内的信息虽然管住了，但跨执行的知识无法积累（每次对话都是新生），系统无法自我改进（踩过的坑重复踩）。

Harness 工程阶段，一切围绕完整的 Agent 生命周期。PERO 编排 + 断点续传 + 知识体系 + 进化体系 + 多 Agent 协调 + Capability Runtime。这对应操作系统的"进程调度 + 文件系统 + IPC"——不仅有内存管理，还有了持久化存储（知识体系）、进程管理（PERO + 断点续传）、进程间通信（SharedBlackboard）。核心贡献是从"脆弱的脚本执行"升级为"健壮的运行时系统"。天花板是单体 Agent 无法承载组织级的复杂任务——需要多 Agent 协作、需要组织级治理、需要自主进化。

Agent OS 阶段，一切围绕认知操作系统。五层架构 + 双 Agent 平台 + 四层嵌套循环 + 三条闭环 + 五层认知模型。这是操作系统的完整形态——不仅有各个子系统，还有了统一的内核调度（云端 Agent OS 认知层）、设备驱动（OpenClaw 执行集群）、用户态/内核态分离（认知与执行分离）。这是当前正在构建的阶段。

每一层的出现都是因为前一层遇到了天花板。而每一层的设计，都尽可能地为下一层的出现提供基础设施——L2 的执行账本为 L4 的调度层提供了可审计的决策依据，L3 的记忆体系为 L5 的进化层提供了知识积累的载体。好的分层架构不仅解决当前问题，还为下一阶段的演进铺平道路。

Agent 系统设计的本质不是控制 LLM 的行为，而是为 LLM 创造一个"犯错成本最低、正确路径最短"的执行环境。

这句话需要被真正理解。"犯错成本最低"不是说容忍错误——而是说当错误发生时，系统有检查点可以回退（断点续传），有结构化的失败记录防止重蹈覆辙（已放弃的路径），有自动降级而非整体崩溃的容错机制（Prompt 预算预检的瀑布降级）。"正确路径最短"不是说限制模型的行为——而是说通过 Action Space 裁剪减少无效选项，通过 parameterBindings 消除不必要的数据搬运，通过 DataBus 预取让需要的信息唾手可得。好的环境让正确的行为成为最自然的选择。

从防御到赋能，不是从严格到松散，而是从被动到主动，从修补到设计，从对抗到协作。防御范式的隐含假设是"模型会犯错，我来兜底"；赋能范式的隐含假设是"模型有能力，我来创造条件"。两者的区别不在于控制的松紧，而在于控制的方向——前者是"堵住错误的出口"，后者是"打开正确的入口"。

一句话概括全年的认知进化：从"AI 能做事"到"AI 稳定地、大规模地做事"。下一步要解决的是让 AI 学会自己决定做什么事——从被动的执行者进化为主动的认知者。这条路的尽头不是"更聪明的工具"，而是"真正的认知伙伴"。

走到今天这一步，回头看第一章的四面墙壁——上下文窗口、注意力稀释、数据搬运、无状态——它们没有消失，但它们已经不再是"天花板"，而变成了"设计约束"。约束不是敌人，约束是创造力的起点。在这四面墙壁围成的房间里，我们构建了一套完整的操作系统。而操作系统的意义，是让墙壁内的空间变得无限大。

参考与致谢

本文的技术方案和认知演进基于以下工作：ReAct Loop（Yao et al., 2022）、ReCAP（2024）、Anthropic Claude Code Team "Think Like an Agent"（2025）、OpenAI Codex sandbox checkpoint/resume 机制、OpenCode session compaction + tool result truncation 策略、Douglas McGregor X/Y Theory（1960）、W. Edwards Deming 质量管理理论、Richard Thaler Nudge Theory（2008）、Ludwig Wittgenstein "语言的界限就是世界的界限"。

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

点击阅读原文即可体验！