你不知道的 Agent：原理、架构与工程实践 ✍ 阿里云开发者🕐 2026-05-02📦 60.8 KB 🟢 已读 本文深入剖析了 Agent 系统的工程实现，强调 Harness（测试与约束基础设施）比模型能力更关键。文章详细阐述了 Agent Loop 的稳定性、上下文分层管理以避免 Context Rot、工具设计的 ACI 原则、记忆系统的多维度分类，以及基于失败案例的评测体系。最后通过 OpenClaw 案例，展示了如何利用 Prompt Caching 和按需加载 Skills 来优化系统架构。 AgentLLM工程实践Harness上下文管理OpenClaw工具设计评测体系Prompt Caching # 你不知道的 Agent：原理、架构与工程实践 **来源**: 阿里云开发者 **发布时间**: 2026-04-28 00:32:00 **字数**: 17155 | **阅读时长**: 69 分钟 **链接**: [https://www.bestblogs.dev/article/5a46573c](https://www.bestblogs.dev/article/5a46573c) ## 摘要 文章基于作者的技术实践与独立思考，深入剖析了 Agent 系统的工程实现细节。核心观点包括：Agent Loop 的核心逻辑稳定，新能力通过扩展工具集、调整系统提示和状态外化接入；Harness（测试与约束基础设施）对系统稳定性的影响常大于模型本身；上下文需按常驻层、按需加载、运行时注入、记忆层和系统层分层管理，避免噪声稀释关键信号；工具设计应遵循 ACI 原则，以 Agent 目标而非 API 操作为粒度，并提供结构化错误和示例；记忆系统需区分工作记忆、程序性记忆、情景记忆和语义记忆，通过 MEMORY.md 和 Skills 协作实现跨会话一致性；多 Agent 组织需先建立结构化通信协议、任务图和隔离边界，再谈协作与并行；评测体系应从 20-50 个真实失败案例起步，优先使用代码评分器，并先排查评测系统本身的问题再修改 Agent。文章最后通过 OpenClaw 案例展示了这些原则的落地实现。 ## 核心要点 ### 1. Agent 核心循环稳定，新能力通过扩展工具集、调整系统提示和状态外化接入。 Agent Loop 的核心逻辑（感知-决策-行动-反馈）抽象后不到 20 行代码，新增能力不应修改循环内部，而是通过扩展工具集、调整系统提示结构、将状态外化到文件或数据库来实现。 ### 2. Harness（测试与约束基础设施）对系统稳定性的影响常大于模型本身。 Harness 包括验收基线、执行边界、反馈信号和回退手段。在代码编写等高可验证任务中，决定系统能否稳定运行的往往是这些外围工程条件，而非模型能力。 ### 3. 上下文需按信息使用频率和稳定性分层管理，避免 Context Rot。 上下文应分为常驻层、按需加载、运行时注入、记忆层和系统层。确定性逻辑应交给外部系统处理，不进入上下文。Skills 按需加载、Prompt Caching 等策略可有效降低上下文成本和提升稳定性。 ### 4. 工具设计应遵循 ACI 原则，以 Agent 目标为粒度，并提供结构化错误和示例。 工具应对应 Agent 要完成的目标而非底层 API 操作，描述应说明何时用、何时不用，返回与下一步决策直接相关的字段，错误应结构化并包含修正建议。调试 Agent 时应优先检查工具定义。 ### 5. 评测体系应从 20-50 个真实失败案例起步，优先使用代码评分器，并先排查评测系统问题。 评测的核心是测试用例、评分标准和自动验证。有明确正确答案的任务优先使用代码评分器。看到评测分数下降时，应先检查运行环境、评分器 bug 等基础设施问题，再修改 Agent。 ## 金句摘录 > 模型负责推理，外部系统负责状态和边界，一旦这个分工确定下来，核心循环逻辑就很少需要频繁调整了。 > Harness 要做的就是把任务推进右上角，让对错有机器可以执行的判断标准，而不是靠人盯。 > 调试 Agent 时应先检查工具定义，大多数工具选择错误的原因出在描述不准确，不在模型能力。 > 评测出问题了，你拿到的是一个失真的信号，基于它去改 Agent，改的方向可能从一开始就是错的。 > 先有可持久化任务图，再引入有身份的队友，再引入结构化通信协议，最后再加交叉验证或外部反馈。 --- ## 正文 阿里妹导读 文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。 这篇文章主要讲 Agent 架构里几块最影响工程效果的内容，包括控制流、上下文工程、工具设计、记忆、多 Agent 组织、评测、追踪和安全，最后再用 OpenClaw 的实现把这些设计原则串起来看一遍。 整理下来，有几处判断和我原来想的不太一样，更贵的模型带来的提升，很多时候没有想象中那么大，反而 Harness 和验证测试质量对成功率的影响更大，调试 Agent 行为时，也应优先检查工具定义，因为多数工具选择错误都出在描述不准确，另外，评测系统本身的问题，很多时候比 Agent 出问题更难发现，如果一直在 Agent 代码上反复调，效果未必明显，读完这篇，这几个问题应该能有些答案。 一、Agent Loop 的基本运转方式 Agent Loop 的核心实现逻辑抽象后其实不到 20 行代码： ``` const messages: MessageParam[] = [{ role: "user", content: userInput }]; ``` 对应的控制流如下，感知 -> 决策 -> 行动 -> 反馈四个阶段不断循环，直到模型返回纯文本为止：  看过不少 Agent 实现和官方 SDK，结构都差不多，循环本身相当稳定，从最小实现一路扩展到支持子 Agent、上下文压缩和 Skills 加载，主循环基本没有变化，新增能力通常都是叠加在循环外部，而不是改动循环内部。 新能力基本只通过三种方式接入：扩展工具集和 handler、调整系统提示结构、把状态外化到文件或数据库，不应该让循环体本身变成一个巨大的状态机，模型负责推理，外部系统负责状态和边界，一旦这个分工确定下来，核心循环逻辑就很少需要频繁调整了。 **Workflow 和 Agent 有什么区别** Anthropic 对这两类系统有一个直接区分：执行路径由代码预先写死的是 Workflow，由 LLM 动态决定下一步的是 Agent，核心区别在于控制权掌握在谁手里，现实中很多标着 Agent 的产品，深入看其实更接近 Workflow，不过两者本身并无高下之分，真正重要的是给任务找到更适合的解决方案。 维度 Workflow Agent 控制权 代码预定义，同输入必走同一路径 LLM 动态决策，可能需要评测验证 执行方式 工具顺序固定，错误走预设分支 工具按需选择，模型可尝试自我修复 状态与记忆 显式状态机，节点跳转清晰 隐式上下文，状态在对话历史中累积 维护成本 改流程需修改代码并重新部署 调整系统提示即可，无需重新部署 可观测性 日志定位节点，延迟可预估 需完整执行记录理解决策链，轮数不固定 人机协作 人在预设节点介入 人在任意轮次介入或接管 适用场景 流程固定、输入边界清晰 需要中间推理与灵活判断 放在一张图里看，会更直观：  **五种常见控制模式** 大多数 AI 系统拆开看，其实都是这五种模式的组合，很多场景并不需要完整的 Agent 自主权，把其中几种模式搭起来就够了，关键还是看任务本身适合哪一种设计。 1. **提示链 Prompt Chaining**：任务拆成顺序步骤，每步 LLM 处理上一步的输出，中间可加代码检查点，适合生成后翻译、先写大纲再写正文这类线性流程。 2. **路由 Routing**：对输入分类，定向到对应的专用处理流程，简单问题走轻量模型，复杂问题走强模型，技术咨询和账单查询走不同逻辑。 3. **并行 Parallelization**：两种变体：分段法把任务拆成独立子任务并发跑，投票法把同一任务跑多次取共识，适合高风险决策或需要多视角的场景。 4. **编排器-工作者 Orchestrator-Workers**：中央 LLM 动态分解任务，委派给工作者 LLM，综合结果，nanobot 的 `spawn` 工具和 learn-claude-code 的子 Agent 模式都是这个原型。 5. **评估器-优化器 Evaluator-Optimizer**：生成器产出，评估器给反馈，循环直到达标，适合翻译、创意写作这类质量标准难以用代码精确定义的任务。  二、为什么 Harness 比模型更关键 Harness 是指围绕 Agent 构建的测试、验证与约束基础设施，这里的 Harness 至少包括四个部分：验收基线、执行边界、反馈信号和回退手段。 模型虽然重要，但决定系统能不能稳定运行的，往往是这些外围工程条件。这个判断在代码编写这类高可验证任务上最成立，但在开放式研究、多轮协商这类弱验证任务里，模型上限本身仍然更关键。 **OpenAI 的 Agent 优先开发实践** 3 个工程师 5 个月写了百万行代码，将近 1500 个 PR，是传统开发速度的 10 倍。这个速度背后不是模型有多强，而是几个工程决策做对了： 1. **Agent 看不到的内容等于不存在**：知识必须存在于代码库本身，外部文档对运行中的 Agent 不可见，`AGENTS.md` 只保留约 100 行作为索引，细节拆到各 docs 目录按需引用。 2. **约束编码化而非文档化**：写在文档里的规范很容易被忽略，编码进 Linter、类型系统或 CI 规则里的约束才具备可执行性，架构分层靠自定义 Linter 机械强制，不靠人工 Review。 3. **Agent 端到端自主完成任务**：从验证当前状态、复现 Bug、实现修复、驱动应用验证，到开 PR、处理 Review 反馈、自主合并，全链路不需要人介入，查日志、查指标、查追踪都由 Agent 主动完成。 4. **最小化合并阻力**：测试偶发失败用重跑处理而不是阻塞进度，在高吞吐环境下等待人工审查的成本往往高于修复小错误的成本。写代码的纪律没有消失，只是从人工 Review 变成了机器执行的约束，一次写进去，到处生效。  APP 把日志、指标、追踪三路数据经由 Vector 分发到 Victoria 存储层，对应 LogQL、PromQL、TraceQL 三个查询接口，Codex 通过这三个接口查询、关联、推理，完成改动后重启应用、重跑工作负载，结果再打回给 Codex，UI Journey 也作为输入接入。整套可观测性栈按任务临时创建、任务完成即销毁，Agent 不需要等人告知错误，直接查询系统状态验证修改是否生效。 **Harness 的关键结论是什么**  图里用任务清晰度和验证自动化程度把任务分成四种状态，右上角目标明确、结果可以自动验证，是最适合 Agent 发挥的区域，左上角任务清楚但验收还得人盯，吞吐量天花板是人的审查速度，右下角有自动化反馈但目标模糊，系统会高效地往错误方向跑，左下角两者都缺，Agent 基本起不到作用。 Harness 要做的就是把任务推进右上角，让对错有机器可以执行的判断标准，而不是靠人盯。 三、上下文工程为什么决定稳定性 Transformer 的注意力复杂度是 ，上下文越长，关键信号越容易被噪声稀释，实践里最常见的失效模式是无关内容一旦占到上下文的大头，Agent 的决策质量就会明显下滑，这类现象通常被叫作 Context Rot，很多看起来像模型能力不足的问题，往往可以追溯到上下文组织不当。 **上下文为什么要分层** 问题通常不是窗口不够长，而是信息密度不对，偶尔用的东西每次都加载进来，稳定的规则和动态的状态混在一起，模型能看到的内容越来越多，但真正有用的部分越来越难被注意到。  解决方式是按信息的使用频率和稳定性分层管理，每层只放自己该放的东西： - **常驻层**：身份定义、项目约定、绝对禁止项，每次会话都必须成立的内容，保持短、硬、可执行 - **按需加载**：Skills 和领域知识，描述符常驻，完整内容触发时再注入，不用的不占位置 - **运行时注入**：当前时间、渠道 ID、用户偏好等动态信息，每轮按需拼入 - **记忆层**：跨会话经验写入 `MEMORY.md`，不直接进系统提示，需要时才读取 - **系统层**：Hooks 或代码规则处理确定性逻辑，完全不进上下文 **别把确定性逻辑放进上下文**，凡是可以通过 Hooks、代码规则或工具约束表达的内容，都应交给外部系统处理，而不是让模型反复读取。 **三种常见压缩策略** 策略 成本 丢什么 适用场景 滑动窗口 极低 早期上下文 简短对话 LLM 摘要 中 细节，保留决策 长任务、含关键决策 工具结果替换 极低 工具原始输出 工具调用密集型 滑动窗口实现最简单，但会丢掉早期决策背景。LLM 摘要的进阶做法是 branch summarization，摘要时明确保留架构决策、未完成任务和关键约束。工具结果替换里，`micro_compact` 每轮替换旧工具输出，`auto_compact` 在上下文超阈值时自动触发。 **Prompt Caching 减少重复开销** LLM 推理时，Transformer attention 会为每个 token 计算 Key-Value 对，如果当前请求的输入前缀和之前某次请求完全一致，这部分 KV 就不需要重新计算，直接从缓存读取，这就是 Prompt Caching 的底层原理。命中的前提是精确前缀匹配，不是内容相似就能触发，任何一个 token 不同都会破坏匹配，所以缓存友好的设计核心是稳定性，系统提示、工具定义、长文档这类在多轮请求里基本不变的内容天然适合缓存，动态信息（当前时间、用户输入、工具调用结果）放在后面，不影响前缀的稳定性。 这和上下文分层设计直接相关。常驻层越稳定，前缀命中率越高，边际成本越低，所以「常驻层短而稳定」不只是为了节省 token，也在保护缓存命中。Skills 延迟加载的好处也在这里，按需注入的内容不破坏系统提示前缀，而是追加在稳定前缀之后，工具定义同样参与缓存计算，接了很多 MCP 工具的 Agent 如果工具集频繁变动，缓存命中就会不断失效。有一个反直觉的地方：稳定的大系统提示，比频繁变动的小提示实际成本更低，因为写入成本只付一次，后续每次调用读取的折扣可以达到 90%。 **为什么 Skills 要按需加载** Skills 是上下文工程里非常有效的一种模式，核心思路是：**系统提示只保留索引，完整知识按需加载**。 ``` const systemPrompt = ` ``` Skill 描述要足够短，避免常驻上下文持续涨 token，也要足够像路由条件而不是功能介绍，至少说明什么时候用、什么时候不要用、产出物是什么，最直接的写法是 Use when / Don't use when 再补几条反例，很多路由失败不是模型能力问题，而是边界写得不清楚。系统提示里也要把调用规则写明确：每次回复前先扫描 `available_skills`，有明确匹配时再读取对应 `SKILL.md`，多个匹配时优先选最具体的那个，没有匹配就不读取，一次只加载一个。  图里的数据很直接：没有反例时准确率从基准 73% 掉到 53%，加上反例后升到 85%，响应时间还降了 18.1%。反例不是可选项，是 Skill 描述能不能起作用的关键。 Skills 不能等 Agent 想起来再用，要每轮都先扫描描述，但扫描成本要足够低，实际加载数量也要受控，如果 Skill 会触发外部 API 写操作，系统提示里应显式补充速率限制要求，尽量批量写入、避免逐条循环、遇到 429 主动等待。 Skill 描述符有两个写法陷阱值得单独说。第一个是字数： ``` # 低效（约 45 tokens） ``` 路由准确率差距不大，但每个启用的 Skill 描述符都常驻上下文，Skill 一多，长描述的累积成本很可观。第二个是精度：描述太短（`help with backend`）等于任何后端工作都能触发，路由会乱。真正有效的描述符是路由条件，不是功能介绍，"何时该用我"比"我能做什么"重要得多。 数量上同样要控制：常驻系统提示的只放高频 Skill，低频的不要塞进默认列表，需要时再手动引入，极低频的直接用文档替代就够了，不必做成 Skill。几个典型反模式：正文几百行工作手册全塞进 Skill 正文而不是拆成 supporting files；一个 Skill 试图覆盖 review、deploy、debug、incident 五件事；有副作用的 Skill 没有显式限制调用时机。这三个问题都会让 Skill 路由失准，而且很难排查。 Skills 和 MCP 在上下文成本上的特征并不相同，很多 MCP 会把完整结果直接返回给模型，更容易迅速吃掉上下文预算，CLI + 单句描述的 Skill 更接近模型熟悉的调用方式，在大多数可过滤、可拼接的数据读取任务里也更简洁，当然 MCP 也有明确适用场景，例如 Playwright 这类需要维护状态的任务。 **压缩最容易丢掉什么** 压缩阶段最常见的问题，不是摘要不够短，而是保留顺序设错了，LLM 通常会优先删除那些看起来还可以重新获取的信息，早期的 tool output 通常最先被移除，但与之相关的架构决策、约束理由和失败路径也很容易一并丢失。最好在 `CLAUDE.md` 或等价文档里明确写出压缩时的保留优先级： ``` ### Compact Instructions 如何保留关键信息 ``` 压缩时还有一条容易踩的坑：不要改动标识符，UUID、hash、IP、端口、URL、文件名这类值必须原样保留，一旦把 PR 编号或 commit hash 改错一位，后续工具调用就会直接失效。 **文件系统为什么适合做上下文接口** Cursor 把这种方式叫 Dynamic Context Discovery，默认少给，只在需要时读取。文件系统天然适合做这个接口，工具调用经常返回大量 JSON，几次搜索就能堆出成千上万 token，不如直接写入文件，让 Agent 通过 grep、rg 或脚本按需读取，工具写文件，Agent 读文件，开发者也可以直接查看。 Cursor 在 MCP 工具上也验证过这个方向：他们把工具描述同步到文件夹，Agent 默认只看到工具名，需要时再查询具体定义，A/B 测试中，调用 MCP 工具的任务总 token 消耗减少了 46.9%。 同样的思路也适用于长任务压缩，压缩触发时，不直接丢弃历史，而是把聊天记录完整保留为文件，摘要里只引用文件路径，后续如果 Agent 发现摘要缺少细节，仍然可以回到历史文件里检索，这样压缩就变成了一种有损但可追溯的操作，而不是一次不可恢复的硬截断。 四、工具设计决定 Agent 能做什么 上下文决定模型能看到什么，工具决定模型能做什么。工具定义的质量比数量更关键，仅 5 个 MCP 服务器就可能带来约 55,000 tokens 的工具定义开销，相当于在 200K 上下文里还没开始对话就用掉了近三成，工具一旦过多，模型对单个工具的注意力也会被稀释。 工具问题多数不在数量不够，而在选不对、描述看不懂、返回一堆没用的、出了错 Agent 也不知道怎么改。 维度 好工具 差工具 粒度 对应 Agent 要完成的目标 对应 API 能做的操作 示例 `update_yuque_post` `get_post + update_content + update_title` 返回 与下一步决策直接相关的字段 完整原始数据 错误 结构化，含修正建议 通用字符串 `"Error"` 描述 说明何时用、何时不用 只写功能说明 **工具设计如何演进** 工具设计大致经历了三个阶段，早期做法是直接把现有 API 封装成工具扔给模型，后来发现模型选错工具，问题不在模型能力，而在工具本身的设计视角就错了，原来是给工程师设计的，不是给 Agent 设计的。 **第一代，API 封装**：每个 API Endpoint 对应一个工具，粒度过细，Agent 往往需要协调多个工具才能完成一个目标。 **第二代，ACI，即 Agent-Computer Interface**：工具应对应 Agent 的目标，而不是底层 API 操作，不要只给一个像 `update(id, content)` 这样的通用接口，而是直接给一个 `update_yuque_post(post_id, title, content_markdown)`，一次把目标动作说完整。 **第三代，Advanced Tool Use**：在工具设计之上，进一步优化工具的发现、调用和描述方式，主要包括三个方向： - **Tool Search，动态工具发现**：别把全部工具定义一次性塞给模型，Agent 通过 `search_tools` 按需发现工具定义，上下文保留率可达到 95%，Opus 4 的准确率也从 49% 提升到 74%。 - **Programmatic Tool Calling，代码编排**：别让中间数据一轮轮穿过模型，而是让模型用代码编排多个工具调用，中间结果在执行环境中流转，不进入 LLM 上下文，token 消耗可从约 150,000 降到约 2,000。 - **Tool Use Examples，示例驱动**：每个工具附带 1-5 个真实调用示例，JSON Schema 只能描述参数类型，但无法表达调用方式，加入示例后，工具调用准确率可从 72% 提升到 90%。 **ACI 工具设计有哪些原则** 类比 HCI 对人的影响，工具设计对 Agent 的影响一样直接，不能只看「工具能不能调用」，还要看「调用错了之后能不能自己修回来」。 三个原则放在一起看更清楚，差的做法参数模糊、错误不可修正、定义实现分离： ``` // 差：参数模糊，出错只返回字符串，Agent 不知道怎么修正 ``` 好的做法用 `betaZodTool` 把定义和实现绑在一起，参数描述直接约束格式，错误结构化给出修正建议： ``` const updateTool = betaZodTool({ ```  左边是差工具设计，工具只说自己能做什么，不说明什么时候该用、什么时候不该用，结果是 Agent 容易选错工具、填错参数，报错后不断重试绕圈，右边是符合 ACI 原则的工具设计，边界清楚、结构化错误给出修正建议，Agent 更容易一次选对，失败后也能快速修正。 调试 Agent 时应先检查工具定义，大多数工具选择错误的原因出在描述不准确，不在模型能力，工具数量也要克制，能用 Shell 处理的、只需静态知识的、更适合 Skill 的，都不需要新增工具。 **为什么工具消息也要隔离** 框架运行过程中会产生一些内部事件：压缩发生了、通知推送了、某个工具调用被跳过了，这些事件需要记在会话历史里，但不应该直接进 LLM，否则模型会看到一堆它不理解的字段，白白消耗 token。 解决方式是在框架层分两种消息类型：给应用层用的 `AgentMessage` 可以携带任意自定义字段，真正发给 LLM 的 `Message` 只保留 `user`、`assistant`、`tool_result` 三种标准类型，调用前过滤一遍，会话历史保留完整框架状态，LLM 只收它需要的部分。 五、记忆系统如何设计 Agent 不具备原生的时间连续性，会话结束后，上下文随之清空，下一次启动时也不会自动保留此前状态，要让系统具备跨会话的一致性，记忆层得单独设计，对 Agent 来说它是一层基础设施，不是可以事后补上的能力。 **四种记忆分别存在哪里** 这里不是按存储介质来分，而是按 Agent 实际要解决的问题来分： - **上下文窗口，工作记忆**：当前任务所需的最小信息，token 有限，得主动管理 - **Skills，程序性记忆**：怎么做某件事，操作流程、领域规范，按需加载不默认常驻 - **JSONL 会话历史，情景记忆**：发生了什么，磁盘持久化，支持跨会话检索 - **`MEMORY.md`，语义记忆**：Agent 主动写入认为重要的事实，每次启动时注入系统提示 ![四种记忆类型与存储位置：上下文窗口位于运行时 messages[]，Skills、JSONL 会话历史和 MEMORY.md 位于磁盘，生命周期和注入方式各不相同](https://wechat2rss.bestblogs.dev/img-proxy/?k=a1fe2703&u=https%3A%2F%2Fmmbiz.qpic.cn%2Fmmbiz_svg%2FQ3auHgzwzM6RUVDUAvBfm5tJqVTlE7pA7uxx3WlHbic0PI3gehku7ictQib67QYMjFqFTzzGazfXczRWauatogib0nZJxichVrekmoS4kzAZg0OTS7icRdEmOD4A%2F640%3Fwx_fmt%3Dsvg%26from%3Dappmsg%26tp%3Dwebp%26wxfrom%3D5%26wx_lazy%3D1%23imgIndex%3D9) 左侧是 Agent 运行时，只有上下文窗口存在于 `messages[]` 中，会随着会话结束一起清空，右侧是磁盘上的持久层，Skills 文件按需加载，JSONL 会话历史保留完整过程并支持检索，`MEMORY.md` 则沉淀 Agent 主动写入的稳定事实，并在后续会话中持续注入。 **MEMORY.md 和 Skills 如何协作** 实际系统实现方式不同，但核心都在解决两件事：重要事实要留下来，注入模型的内容又不能失控。 **ChatGPT 四层记忆** 拿它当一个产品实现来看，它没有使用向量数据库，也没有引入 RAG 检索增强生成，整体结构比很多人的预期更简洁： 层 内容 持久化 Session Metadata 设备、地点、使用模式 否，会话级 User Memory 约 33 条关键偏好事实 是，每次注入 Conversation Summary 约 15 个最近对话的轻量摘要 是，摘要预生成 Current Session 当前对话滑动窗口 否 **OpenClaw 混合检索** - `memory/YYYY-MM-DD.md`，追加写日志，保留原始细节 - `MEMORY.md`，精选事实，Agent 主动维护 - `memory_search`，70% 向量相似度 + 30% 关键词权重的混合检索 这个设计的好处是可读、可改、可检索，Markdown 文件可以直接查看和修订，搜索时按相关性拉取需要的内容，而不是把全部记忆一次性塞进上下文，对大多数 Agent 来说，记忆库规模并不需要一开始就引入向量存储，结构化 Markdown 加关键词搜索已经具备足够好的可调试性、可维护性和成本表现，只有当规模超过几千条、并且确实需要语义相似度检索时，再考虑引入向量检索会更合适。 **记忆整合如何触发并回退** 有了记忆分层之后，下一步要处理的就不是「要不要存」，而是「什么时候整合，以及整合失败怎么办」。  这张图强调的不是「把旧消息删掉」，而是把它们从活跃上下文中安全移出，左边是持续增长的对话消息流，中间用 `tokenUsage / maxTokens >= 0.5` 作为触发阈值，达到阈值后，成功路径会先对待整合消息做 `llmSummarize(toConsolidate)`，再把摘要追加到 `MEMORY.md`，最后只更新 `lastConsolidatedIndex`，失败路径则把原始消息写入 `archive/`，保留完整历史，避免整合失败时丢失上下文。 最关键的不是摘要写得多漂亮，而是流程本身必须可回退，系统只移动指针，不删除原始消息，即使整合失败，也还能回到原始存档继续工作。 六、如何逐步放开 Agent 自主度 这里说的自主度，不是少几次人工确认，而是让 Agent 能在更长时间跨度内稳定推进任务，前提也不是直接放权，而是先补齐三类基础设施：跨 session 续跑、单个 session 内的进度约束，以及慢速 I/O 的后台接入。 **长任务如何跨 session 继续** 长任务最常见的失败，不是单步报错，而是 session 结束时任务还没做完，即使启用 compaction，也挡不住两类问题：一是在单个 session 里试图做完整个应用，结果上下文先耗尽，二是只做完一部分，下一轮又无法准确恢复现场，过早判断完成。 更稳定的做法，是把长任务拆成 Initializer Agent 和 Coding Agent 两个角色协作，这种模式最适合代码生成、应用搭建、重构迁移这类单个 session 做不完、但又能拆成一批可验证子任务的工作。 Initializer Agent 只在第一轮运行一次，负责生成 `feature-list.json`、`init.sh`、初始 git commit 和 `claude-progress.txt`，先把任务变成可持久化的外部状态，后面的多个 session 由 Coding Agent 循环执行，每次从 `claude-progress.txt` 和 `git log` 恢复现场，定位当前任务，实现一个功能，跑测试，更新 `passes` 字段，提交代码后退出，这样即使中途崩溃，也能直接从文件系统里的状态继续，而不是从头再来。  进度要放在文件里，不要放在上下文里，功能清单用 JSON，不用 Markdown，结构化格式更适合模型稳定修改，当 `feature-list.json` 里所有功能都变成 `passes: true`，任务才算完成。 **为什么任务状态要显式写出来** 跨 session 解决的是「下次从哪里继续」，单个 session 内还要解决「当前做到哪一步」，长任务一旦拉长，没有外部进度锚点，Agent 很容易偏航，或者在还有任务未完成时过早结束。 任务状态要显式记录为外部控制对象，而不是留在模型的工作记忆里： ``` { ``` 约束很简单，同一时间只能有一个 `in_progress`，每完成一步都先更新状态，再继续下一步，必要时再加轻量校正，例如连续多轮未更新任务状态时，自动注入 `<reminder>` 提示当前进度。 **后台 I/O 如何接入** 自主度提高以后，真正容易拖慢主循环的，通常不是模型推理，而是文件操作、网络请求和长耗时命令这类外部 I/O，这些操作一旦阻塞主循环，执行节奏就会明显变差。 务实的做法，是把慢速 subprocess 放到后台线程，通过通知队列在下一轮 LLM 调用前注入结果，主循环不需要感知太多并发细节，只要在每轮开始前检查是否有新结果，再决定继续执行、等待还是调整计划，这通常比把整个 loop 改造成复杂的 async runtime 更稳，也更容易维护。 七、多 Agent 如何组织 一说到多 Agent，不少人先想到的就是并行，但工程上先要解决的其实是隔离和协作，这里对应的是两种完全不同的工作模式。 指挥者模式是同步协作，人与单个 Agent 紧密互动，每一轮都要调整决策，缺点也很明显，session 一结束，context 就没了，产出物也是短暂的。 统筹者模式是异步委派，人在开始时设定目标，中间让多个 Agent 并行工作，最后再审查产出，这样人只在起点和终点出现，中间产出会变成分支、PR 这类可持久化工件，多 Agent 的主要价值也在这里，不是单纯多开几个模型，而是把人的持续参与，变成对工件的最终审核。  常见的组织方式是主 Agent 作为 Orchestrator 统筹全局，下挂多个子 Agent 独立并行工作，它们之间通过 JSONL inbox 协议通信，用 Worktree 隔离文件修改，用任务图管理依赖关系。  **子 Agent 适合做什么** 子任务里的搜索、试错和调试过程，不该污染主 Agent 的上下文，主 Agent 真正需要的只是结论，探索细节留在子 Agent 自己的消息历史里。 ``` // 子 Agent 有独立的 messages[]，跑完只回传摘要 ``` **为什么协作方式要写成协议** 多 Agent 协作一旦靠自然语言来对齐，很快就会出问题。模型记不稳谁承诺了什么，也记不稳谁在等谁的结果，任务开始互相依赖之后，就得先把协议写清楚： ``` // 消息结构：结构化，有状态，append-only，崩溃可恢复 ``` 这里至少要先有三样东西，协议、任务图、隔离边界，主 Agent 通过 JSONL 消息队列分派任务给子 Agent，子 Agent 执行后只回摘要，搜索和调试细节留在自己的独立上下文里，`.tasks/` 记录任务图和依赖关系，`.worktrees/` 隔离每个子 Agent 的文件修改，顺序也别反过来，协议先定，隔离先做，再谈协作和并行。  **多 Agent 下幻觉会互相放大** 多个 Agent 频繁互动时，错误也会被一层层放大，Agent A 先带偏，Agent B 跟着强化，Agent C 再继续叠加，最后所有 Agent 都收敛到同一个高置信度的错误结论，交叉验证的价值就在这里，它能打断这条链，让某个 Agent 独立判断，而不是顺着前面的结论继续走，这里也有顺序，先有可持久化任务图，再引入有身份的队友，再引入结构化通信协议，最后再加交叉验证或外部反馈，比如独立的第二个 Agent、单元测试、编译器或人工审查。  **子 Agent 的深度限制和最小提示** 子 Agent 有两个基本限制，第一是深度限制，防止无限递归生成孙 Agent，设一个最大深度就够了，第二是最小系统提示，只给 Tooling、Workspace、Runtime 三节，不带 Skills 和 Memory 指令，避免权限外泄，也避免破坏隔离边界。 八、Agent 评测如何做 Agent 做得对不对，最终要靠评测来判断，很多团队会把这一步往后放，结果就是改了 Prompt，不知道是否变好，换了模型，也不知道是否退化，最后只剩下一组无法解释的波动数字，评测的核心是测试用例、评分标准和自动验证，真正的难点不是有没有分数，而是这些分数能不能反映真实质量。 **为什么 Agent 评测结构更复杂**  上半是传统 Single-turn 评测，一个 Prompt 进去，模型输出一个 Response，判断对不对就结束了，下半是 Agent 评测，要先准备好工具、运行环境和任务，Agent 在执行过程中多次调用工具、修改环境状态，最后的评分不是看它说了什么，而是跑一批测试验证环境里真正发生了什么，结构上复杂了不止一个层级，这也是为什么传统评测方法在 Agent 场景里往往不够用。  这张图里真正需要记住的，其实就三组概念，第一组是 `task` 任务、`trial` 单次运行、`grader` 评分器，分别对应测什么、跑多少次、怎么打分，第二组是 `transcript` 完整执行记录和 `outcome` 环境最终结果，评测不能只看其中一边，第三组是 `agent harness` 被评测的 Agent 运行框架和 `evaluation harness` 评测基础设施，后者负责把任务跑起来、打分、汇总结果，`evaluation suite` 就是一批任务的集合，是评测跑起来的原材料。 **评测现状与常用指标** Agent 的评测比传统软件更难，输入空间近乎无限，LLM 对提示措辞高度敏感，同一任务在不同运行之间也可能出现差异，从调查数据看，很多团队的评测体系仍不成熟，人工审查和 LLM 评分依然是最常见的做法。   左图是评测方式，右图是常用指标，人工标注和 LLM judge 加起来占主导，传统 ML 指标只有 16.9%，还有近四分之一的团队还没开始做评测。 在具体统计方式上，最常用的是两个指标，用途不同，不能混用： 指标 含义 场景 Pass@k k 次至少一次正确 探索能力上限，能力突破时重跑 Pass^k k 次全部正确 上线回归，每次变更都跑 Pass@k 适合在开发阶段回答「这个 Agent 理论上能不能做到」，Pass^k 适合在上线前回答「已有功能有没有被改坏」，混用容易误判，回归测试过松会漏掉问题，能力评测过严又会让每次小改动都告警。 **三类评分器的区别** 评测是否可靠，首先取决于评分器选得对不对： 类型 典型做法 确定性 适用场景 代码评分器 字符串匹配、单元测试 pass/fail、结构比对、工具调用参数验证 最高 有明确正确答案的任务 模型评分器 按评分标准打分、两个答案对比选优、多个模型投票取共识 中 语义质量、风格、推理过程 人工评分器 专家抽样审查、标注队列校准 可靠但慢 建立基准、校准自动 judge 代码评分器最不容易因设计不当引入噪声，有明确正确答案就优先用它。 「看 Agent 怎么说」和「看系统最后变成什么样」是两件事，Agent 说「订票已完成」，这是在看执行记录 transcript，数据库里确实生成了一条订单，这才是在看最终结果 outcome，只看执行记录会漏掉「说了但没做到」，只看最终结果又可能看不出中间步骤走歪了，两类都要覆盖。 Anthropic 在《Demystifying evals for AI agents》里提到过一个机票预订 Agent 的例子，Opus 4.5 在一次运行中发现了航空公司政策里的漏洞，为用户找到了更便宜的方案，如果只按预设路径打分，这次运行会被判失败，但看最终结果，用户拿到了更好的方案，只盯着执行过程会漏掉这类情况，两类都覆盖才能看清楚。 **如何从零搭起评测体系** 不用等有了完整体系再开始，20 到 50 个真实失败案例就够启动，来源优先选已经在手动检查的内容，那些才是真正反映实际用途的，在做这件事之前，有一个判断标准值得记住：如果两个领域专家拿同一个案例独立判断，结论不一致，这个案例的验收标准就还没写清楚，先解决定义，再收集数据。 环境隔离是经常被忽略的细节，每次运行都要从干净状态开始，测试之间不能共享缓存、临时文件或数据库状态，否则一个任务的失败会污染下一个，表面看起来是模型出了问题，实际是环境脏了。 测试用例要同时覆盖正例和反例，只测「应该做 X」，评分器就只会往一个方向优化，把「不应该做 X 的情况」也加进来，才能发现 Agent 在边界上的行为是否正常。 评分器选择按顺序来：有明确正确答案用代码评分器，需要判断语义质量再用模型评分器，遇到拿不准的案例，人工标注一批，用来校准自动评分器的漂移，定期读完整执行记录，不要只看聚合分数，评分器本身的 bug 通常只有在看具体 Trace 时才会暴露。 体系搭起来之后，把「当通过率接近 100% 时补充更难的任务」也当成常规工作，评测套件饱和了不是好事，意味着它已经不能再反映真实能力边界。 **先修评测，再改 Agent** 一个常见误区是，看到 Agent 表现下降，就立刻着手修改 Agent 本身，而忽略了评测系统可能先出了问题，评测出问题了，你拿到的是一个失真的信号，基于它去改 Agent，改的方向可能从一开始就是错的，甚至会把本来运行正常的部分改坏。 评测系统常见的出错来源有几类：运行环境资源不足导致进程被杀、评分器本身有 bug 把正确答案判成失败、测试用例和生产场景脱节、或者只看聚合分数而漏掉某一类任务系统性变差，这些问题在表现上都和模型退化一模一样，很难从结果数字上直接区分。  红色是基础设施错误率，蓝色是模型得分，资源上限越严，环境越容易在内存峰值时崩掉，评测直接记失败，但模型其实没答错，随着上限放开，红色跌到接近 0，蓝色几乎不变，说明之前的「失败」不少是环境噪声，看到评测分数下降，先查环境，再动 Agent。 九、如何追踪 Agent 的执行过程 先把 Trace 能力搭起来，没有完整记录，失败案例就没法稳定复现，Agent 出现问题时，传统只监控延迟和错误率的 APM 往往帮助有限，接口层看起来可能一切正常，但真正的问题出在模型某一轮做出了错误决策，只有回看完整 Trace 才能定位。 **Trace 里需要记录什么** ``` 每次 Agent 运行： ``` ``` 每次 Agent 运行： ``` 条件允许的话，这套系统还应具备语义检索能力，能够查询「哪些 Trace 里 Agent 混淆了两种工具」这类问题，而不只是精确字符串匹配，规模一旦上来，靠人工全量审查是跟不上的，自动化是前提。 **两层可观测性如何分工** 第一层是人工抽样标注，基于规则采样错误案例、长对话和用户负反馈，由人工判断执行质量和失败原因，主要用来摸清失败模式，并给第二层提供校准数据。 第二层是 LLM 自动评估，对更大范围的 Trace 做全量覆盖，以第一层标注结果作为校准依据，只跑第二层，评分标准很容易漂移，只靠第一层，规模上又覆盖不了真实流量，两层要一起用。  **在线评测如何做采样** 全量运行在线评测成本高，完全随机采样又容易错过关键 Trace，更稳妥的做法是对 10% 到 20% 的 Trace 运行在线评测，按规则路由采样而不是随机： - **负反馈触发**：用户明确表示不满意的 Trace，100% 进队列 - **高成本对话**：token 消耗超过阈值的，优先审查，往往代表 Agent 在绕圈子 - **时间窗口采样**：每天固定时间段随机采，保持对正常流量的覆盖 - **模型或 Prompt 变更后**：头 48 小时全量审查，确认没有退化 **事件流为什么更适合做底座** Agent Loop 在 `tool_start`、`tool_end`、`turn_end` 三个节点发出事件，完整 Trace 同步落盘，再分发给日志系统、UI 更新、在线评测、人工审查队列这些下游，事件一次发布，多路消费，主循环不需要为了任何下游改代码。  ``` # Agent 执行时 emit 事件 ``` 十、用 OpenClaw 看 Agent 如何落地 前面几节讲的是原则，这一节直接看 OpenClaw 怎么落地，上下文分层、Skills 延迟加载、结构化通信协议和文件系统状态，在这个系统里都能找到对应实现。 **整体架构：五层解耦** OpenClaw 可以拆成五个层次，最上面是负责连接和消息分发的 WebSocket 服务，底部是 `SOUL.md`、`MEMORY.md`、Skills 等配置文件。  层 实现 主要职责 关键设计决策 Gateway WebSocket 服务，端口 18789 接住外部连接，统一路由消息和系统控制信号 Channel 和 Agent 不直接通信，统一走 Gateway，控制入口集中 Channel 适配器 23+ 渠道，统一 adapter 接口 对接 Telegram、Discord 等不同渠道，负责消息收发和格式适配 新增渠道不修改 Agent 代码，渠道差异收敛在 adapter 层 Pi Agent 对外像一个可调用服务，工具调用支持流式返回 维护 Agent 主循环、会话状态、调度和工具调用 Agent 核心循环和渠道完全解耦，支持流式工具调用和长期运行 工具集 shell / fs / web / browser / MCP 提供 Agent 可以调用的外部能力 按 ACI 原则设计，工具面向任务目标，返回结构化结果和错误 上下文 + 记忆 Skills 延迟加载 + `MEMORY.md` 整合 管理系统提示、运行时上下文和跨会话记忆 50% token 阈值自动触发整合，常驻信息尽量轻，知识按需加载 **消息总线如何把渠道和 Agent 隔开** 加上定时任务之后，系统不再只有用户消息这一个入口，OpenClaw 就在渠道和 Agent 之间加了一层 MessageBus，Channel 只管收发，AgentLoop 只管处理，互不干扰。 ``` // 入站消息结构，Agent 不知道来自哪个平台 ``` **一条最小可运行链路** Channel 适配器把消息写入 MessageBus，AgentLoop 从 Bus 中消费消息，处理完成后再把结果发回去。 ``` // MessageBus：渠道和 Agent 之间的解耦层 ``` `dispatch` 不做 `await`，不同 session 的消息可以并发处理，互不阻塞，但同一 session 内的消息必须串行，否则并发写历史和触发 compact 会有竞态，生产环境要对每个 sessionKey 维护一个队列或 mutex。 `session` 由 AgentLoop 统一管理，不下沉到 Channel 层，渠道适配器只管输入输出，换成 Discord，Agent 核心代码不需要动。 **系统提示如何按层叠加** OpenClaw 的系统提示可以从 `SOUL.md` 看起，这个文件定义了 Agent 是谁、按什么方式做事、什么情况下算完成。 ``` # SOUL.md，定义 Agent 的身份、约束和完成标准 ``` 系统提示不是单文件，而是按层加载，顺序从下到上分别是：平台与运行时信息、身份层、记忆层、Skills 层、运行时注入，对应到文件，大致就是 `SOUL.md`、`AGENTS.md`、`TOOLS.md`、`USER.md`、`MEMORY.md` 和 Skills 索引一起组成常驻部分，再按当前会话补充时间、渠道名、Chat ID 这些动态信息。 三种触发模式的加载范围也不同，普通会话加载完整系统提示，子 Agent 只加载最基础的运行时信息，不带记忆和 Skills，heartbeat 模式则单独加载 `HEARTBEAT.md`，也就是不等用户发消息，而是由系统按固定节奏唤起 Agent 检查是否有任务需要继续处理，长任务里再额外加一行身份重申，主要是为了压住任务漂移。  **cron 和 heartbeat 如何主动触发** cron 按计划直接触发 Agent，heartbeat 每 5 分钟轮询一次待处理任务，这两种模式都不等用户发消息。 ``` interfaceCronTask{ ``` **长任务如何恢复** 长任务中途崩溃，如果没有恢复机制，就只能从头再来，OpenClaw 的做法很直接，把任务进度写到磁盘，重启后从断点继续，任务超过半小时，崩溃恢复是必选项，不是可选项。 ``` interface TaskState { ``` **为什么安全边界要先于功能** 开放 Shell 权限之后，`git push`、`rm`、数据库写入这类操作都可能被触发，安全边界要先于功能，三件事必须先到位：谁能用、能在哪用、做了什么可以追踪。 **白名单授权**，只有授权用户可以触发 Agent： ``` const AUTHORIZED_USERS = new Set(["user_id_tang", "user_id_other"]); ``` **工作空间隔离**，shell 工具需要强制进行路径检查，越出工作空间目录就直接报错： ``` const WORKSPACE = path.resolve("/Users/tang/workspace"); ``` **操作审计日志**，每次执行都记一笔，方便后续审计和排查： ``` async function auditedShell(args: string[], userId: string): Promise<string> { ``` **安全和可用性的两层兜底** 除了权限、路径和审计，系统还要补两层兜底，一层防内容注入，一层防模型服务故障。 **Prompt Injection** 白名单和工作空间隔离解决的是越界操作，但还不够，Agent 读取的网页、邮件、文档本身也可能带攻击指令，这就是 Prompt Injection，单靠输入过滤基本挡不住，更实用的做法是按 source-sink 拆，不可信输入从哪里进来是 source，最终可能触发的危险操作是 sink，让 Agent 即使被注入，也没有机会把危险动作执行出去： - **最小权限**：不给 Agent 不需要的工具，没有 sink，source 侧的注入就无法落地 - **敏感操作显式确认**：向第三方传信息、调用写操作，执行前必须让用户确认，不能静默执行 - **标注外部内容边界**：外部拉取的内容进入上下文时显式标注来源，声明哪些内容不可信 - **关键路径加独立 LLM 验证**：同一上下文中的 Agent 很难判断自己是否已被注入，关键操作引入独立 LLM 复核更稳妥 最直接的做法，就是先把外部内容明确标成「不可信输入」，不要和系统提示混在一起。下面这个例子表达的就是这个意思： ``` function wrapUntrustedContent(source: string, content: string): string { ``` 敏感操作的显式确认也一样，本质上是把「先确认再执行」做成系统步骤，而不是让模型自己判断。 **Provider 故障切换** 模型服务出故障是常态，不是例外。Anthropic 返回 503、OpenAI 触发限速都很常见，所以这里要加一层 fallback，当前 Provider 挂了就自动切下一个，不用人盯： ``` const providers = ["Anthropic", "OpenAI", "Anthropic Sonnet"]; ``` **工程实现遵循什么顺序** 1. **单渠道先跑通**，Telegram -> Agent -> Telegram 完整链路，不要第一版就抽象多渠道 2. **安全边界先于功能**，工作空间隔离、白名单、参数验证，加任何新功能之前就要到位 3. **记忆整合要早做**，不加整合，第 20 轮对话之后基本就垮了 4. **Skills 先于新工具**，领域知识用文档管理，比加新工具更灵活 5. **第一个失败就建评测**，把第一个真实失败案例转成测试用例，不要等积累够了再开始 十一、Agent 落地里的常见反模式 这类问题都很常见，很多看起来像模型能力不够，回头看其实是工程约束没立住： 反模式 问题 怎么修 系统提示当知识库 越来越长，关键规则被忽略 约定留在系统提示，领域知识移到 Skills 工具数量失控 Agent 频繁选错工具 合并重叠工具，明确命名空间 缺少验证机制 Agent 说完成了，但没法验证 每类任务绑定可执行的验收标准 多 Agent 无边界 状态漂移，故障归因困难 明确角色和权限，worktree 隔离，设置 maxTurns 记忆不整合 长对话第 20 轮后决策质量下降 监控 token 占用，超阈值自动触发整合 没有评测 改了一个地方不知道有没有引入回归 每个真实失败案例立刻转成测试用例 过早引入多 Agent 协调开销超过并行收益 先建任务图，验证单 Agent 上限后再扩展 约束靠期望不靠机制 规则在文档里，Agent 选择性遵守 期望 -> 工具验证 / Linter / Hook 十二、划重点 最后压缩一下上下文，方便回看，如果你有更好的 Agent 开发经验，也欢迎一起交流： 1\. Agent 核心是感知、决策、行动、反馈的稳定循环，控制流基本不变，新能力主要通过工具扩展、提示结构调整和状态外化实现。 2\. Harness，也就是验收基线、执行边界、反馈信号、回退手段，往往比模型本身更决定系统能否收敛，高质量自动化验证和清晰目标缺一不可。 3\. 上下文工程的重点是防 Context Rot，通过分层管理常驻信息、按需知识、运行时信息和记忆，再配合滑动窗口、LLM 摘要、工具结果替换和 Skills 延迟加载，才能把信号质量稳定住。 4\. 工具设计按 ACI 原则来做：面向 Agent 目标，不是面向底层 API，边界明确，参数防错，定义里直接给示例，调试时优先检查工具描述，而不是先怀疑模型能力。 5\. 记忆可以分成工作记忆、程序性记忆、情景记忆和语义记忆，`MEMORY.md`、按需检索和可回退整合，是跨会话保持一致性的关键。 6\. 长任务稳定运行靠的是状态外化，Initializer Agent 把任务变成文件系统状态，Coding Agent 循环可重入，进度通过文件传递，不依赖上下文窗口。 7\. 多 Agent 要先有任务图和隔离边界再引入并行，协议先于协作，子 Agent 只回传摘要，搜索和调试细节留在自己的上下文里。 8\. 评测上，Pass@k 验证能力边界，Pass^k 保证上线质量，评测系统出问题先修评测再动 Agent，不要基于失真信号调整方向。 9\. 可观测性上，Trace 是排查的前提，事件流做底座一次发布多路消费，人工标注校准 LLM 自动打分，两层要一起用。 10\. OpenClaw 把前面这些原则放进了一个可运行系统里，真正让 Agent 跑稳，靠的不是更复杂的循环，而是消息解耦、状态外化、分层提示、记忆整合和安全边界这些工程细节。 ## 参考资料 1\. OpenAI, Harness engineering: leveraging Codex in an agent-first world [https://openai.com/index/harness-engineering/](https://openai.com/index/harness-engineering/) 2\. Cloudflare, How we rebuilt Next.js with AI in one week [https://blog.cloudflare.com/vinext/](https://blog.cloudflare.com/vinext/) 3\. Simon Willison, I ported JustHTML from Python to JavaScript with Codex CLI [https://simonwillison.net/2025/Dec/15/porting-justhtml/](https://simonwillison.net/2025/Dec/15/porting-justhtml/) 4\. Anthropic, Introducing Agent Skills [https://claude.com/blog/skills](https://claude.com/blog/skills) 5\. Anthropic, Managing context on the Claude Developer Platform [https://claude.com/blog/context-management](https://claude.com/blog/context-management) 6\. LangChain, State of Agent Engineering [https://www.langchain.com/state-of-agent-engineering](https://www.langchain.com/state-of-agent-engineering) 7\. Anthropic, Measuring AI agent autonomy in practice [https://www.anthropic.com/research/measuring-agent-autonomy](https://www.anthropic.com/research/measuring-agent-autonomy) 8\. OpenAI, Designing AI agents to resist prompt injection [https://openai.com/index/designing-agents-to-resist-prompt-injection/](https://openai.com/index/designing-agents-to-resist-prompt-injection/) 9\. Anthropic, Demystifying evals for AI agents [https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
H Hermes Harness 架构深度解析 本文深入分析了 NousResearch 的 Hermes 开源 Agent Harness 架构。文章指出 Hermes 全面实现了包括上下文管理、子代理管理、会话持久化等在内的九大核心组件。作者详细探讨了其独特优势：统一的运行时支持多种模型提供商、复杂的三层系统提示词组装、基于 SQLite 的会话即基础设施设计，以及内置的消息网关和 Cron 系统。文章最后展望了其向一级编排能力演进的方向。 技术 › Hermes ✍ Aparna Dhinakaran🕐 2026-05-30 AgentHarness架构分析LLM上下文管理开源子代理系统设计
A Agent Harness 拆解：AI Agent 的工程化基础设施 本文深入探讨了 Agent Harness 的概念，即包裹在 LLM 外部、将无状态模型转化为可用智能体的完整软件基础设施。文章引用了 Anthropic、OpenAI 和 LangChain 的实践，详细拆解了生产级 Harness 的 12 个核心组件（如编排循环、记忆系统、上下文管理、验证循环等），并阐述了如何通过优化这层“操作系统”来解决遗忘、工具调用失败和上下文腐烂等工程难题。 技术 › Harness Engineering ✍ 土豆本豆🕐 2026-05-21 AgentHarnessLLM架构设计LangChainClaudeOpenAI上下文管理工程化Agent拆解
A Agent 记忆架构指南：为什么你需要 Wiki 和 录音 文章探讨了 AI Agent 开发中的记忆瓶颈，指出单纯扩大上下文窗口并不足以解决遗忘问题。作者提出了 GBrain 和 Lossless 两个核心模式：GBrain 像公司 Wiki，用于跨会话查询事实和决策；Lossless 像会议录音，允许在长对话中无损检索原始细节。文章详细解释了二者的区别、应用场景以及如何在 OpenClaw 和 Hermes 运行时中集成。 技术 › Agent ✍ Vox🕐 2026-05-18 AgentGBrainLosslessOpenClawHermes上下文管理记忆架构RAGLLM开发指南
一 一文搞懂 Agent Harness：如何给 AI 大脑装上身体 本文基于对 ShareAI 创始人新璐的访谈，深入解读了 Agent Harness 的核心概念与架构设计。文章指出，Harness 是模型之外赋予 AI 行动能力、记忆与协作能力的“身体”。通过剖析 Claude Code 的三层结构——执行层、记忆层与治理层，作者阐述了从“流程驱动”向“模型自主决策”转变的工程实践。文章强调，优秀的 Harness 应提供类 UNIX 的稳定环境与结构化的记忆机制，从而释放模型的潜能，使其成为真正的智能合作伙伴。 技术 › Agent ✍ Saito🕐 2026-05-06 AgentHarnessClaude Code架构设计工程实践LLM人工智能ShareAI播客笔记技术洞察
A Agent 工程方法实践：Claude Code 与 OpenClaw 的深度对比 文章深入对比了 Claude Code 和 OpenClaw 两个 Agent 框架的工程实现。两者虽都采用 Agent = Model + Harness 的理念，但架构迥异：Claude Code 采用分层堆叠架构，服务于单线程深度编程场景，追求精确可控；OpenClaw 采用管道架构，面向多并发的生活场景，追求自主进化。文章从架构、循环、工具、指令、上下文、记忆等九个维度详细拆解了各自的工程设计权衡。 技术 › Harness Engineering ✍ Mr Panda🕐 2026-04-26 AgentClaude CodeOpenClaw架构设计上下文管理记忆系统工程实践
如 如何真正防止 Agent 重复犯错：Skillify 实践指南 本文批评了 LangChain 等框架虽有工具但缺乏工作流，导致 AI Agent 测试困难。作者提出“Skillify”模式：通过构建包含确定性代码和单元测试的 Skill（技能），将潜在的 LLM 推理转化为确定性的工具调用。文章以日历查询和时区计算为例，展示了如何利用“薄框架、厚技能”架构，永久修复 Agent 的重复性错误。 技术 › Agent ✍ Garry Tan🕐 2026-04-22 AgentLLMSkillifyOpenClaw测试架构设计工程实践确定性代码
模 模型是引擎，系统是车身：AI 架构工程随笔 文章反驳了 Kyle Kingsbury 关于 LLM 不可靠的结论。作者认为，裸模型仅是“引擎”，其不可预测性需通过“车身”工程（如 Harness、Resolver、确定性工具）来解决。不应测试模型本身，而应测试由模型、路由和工具组成的完整系统。 技术 › Hermes ✍ nash_su🕐 2026-04-20 AI架构LLMAgentHarness工程化系统设计OpenClaw方法论
如 如何优化你的 AI Harness：配置、框架与子代理指南 文章指出工程师的关注点已从 IDE 转向 AI Harness，并介绍了提升 Harness 输出质量的关键方法。核心策略包括：保持配置文件（如 .md）精简，采用渐进式披露原则以节省上下文；利用 R.P.I 框架（Research, Plan, Implement）像资深工程师一样分解问题；以及通过子代理清理主上下文窗口。文章强调，Harness 的核心在于工程判断力。 技术 › 工具与效率 ✍ Alex Ker🕐 2026-04-19 AIAgentHarnessLLM工程化Prompt上下文管理子代理Claude Code最佳实践
H Hermes-Agent vs 自建OpenClaw Harness：Agent操作系统的记忆与架构实战对比 文章基于 Harness Engineering 三大支柱（评估闭环、架构约束、记忆治理），深度对比了 Nous Research 的 Hermes-Agent 与作者基于 OpenClaw 自建的 MemOS 系统。Hermes 主打“有界热记忆 + CLI 优先”，适合个人快速启动；自建方案则采用“无界记忆 + Hook 机制强制捕获”，实现多 Agent 协作与权限隔离，适合团队长期积累。 技术 › Agent ✍ huangserva🕐 2026-04-10 AgentHarness记忆治理HermesOpenClaw架构设计实战对比MemOSLLM多Agent系统
你 你不知道的 Claude Code：架构、治理与工程实践 本文基于作者深度使用 Claude Code 的实战经验，深入剖析了 Claude Code 的六层架构模型。文章详细阐述了上下文治理的成本构成与最佳实践，解释了 Skills、Hooks、Tools 和 Subagents 的区别与设计原则，并分享了如何利用 Prompt Caching 和 Plan Mode 优化系统性能与稳定性。 技术 › Claude ✍ Tw93🕐 2026-03-21 Claude CodeLLMAgent架构设计工程实践上下文管理Prompt Engineering
B BestBlogs 早报｜实现周期骤缩后，创业者如何重选问题 本期早报探讨了 AI 智能体缩短实现周期后，创业者的机遇与挑战。文章涵盖 Sam Altman 对创业窗口的判断、GPT-5.6 的效率工程实践，以及如何通过 Skill Harness 将模型能力封装为可维护的产品功能。 技术 › Skill ✍ ginobefun🕐 2026-07-30 GPT-5.6Agent创业效率工程ProductHarnessSkillLLMOpenAI
实 实战踩坑：便宜模型执行、贵模型编排？没这么简单！ 文章通过三个真实案例，验证了“贵模型编排、便宜模型执行”这一省钱策略。作者发现，虽然便宜模型在文本判定等任务上能打平顶尖模型，但在高复杂度代码和开放式视觉任务上存在局限。关键在于控制模型能力代差和任务可验证性，否则返工成本将抵消节省的 token 费用。 技术 › Agent ✍ WquGuru🕐 2026-07-28 LLMAgent模型编排成本优化Claude Code多模型协作工程实践