Agent

一句话核心 从Chatbot到Agent，AI从一个任务变成多个任务的编排，CPU从"配角"重新变成"刚需"——而RISC-V第一次在这个赛道拿到了入场券。 芯片行业最容易被忽视的转向 过去两年所有人都在讨论GPU：谁家的算力更大、谁家的显存更多、谁能跑更大的模型。 但阿里达摩院首席科学家孟建熠说了一句很关键的话： 原来的Chatbot只有一个任务，就是聊天，用GPU就行了。但Agent有很多任务要编排，这部分工作更适合CPU做。 这不是一家之言。黄仁勋在GTC上也发布了全新架构的Vera CPU。 一个隐含的行业共识正在形成：AI的下一个战场不在算力，在任务编排。 玄铁C950：RISC-V第一次打到顶配 孟建熠带队20多年，从2003年中天微开始做CPU IP，中间经历了"除了坚持没有别的故事"的黑暗十年。2018年被阿里收购后转向RISC-V，今年3月终于拿到C950的成绩单。 关键数据：单位频率性能22分/GHz。 对比对象 单位频率性能 x86 最高端 24-25分 Arm 最高端 26+分 玄铁C950 22分 上一代C930 15.2分 这个数字的意义：RISC-V从"只能做低端IoT"的学术产物，第一次在CPU最核心指标上和x86、Arm站在了同一水位。 而且C950原生集成了Matrix矩阵运算引擎，直接支持Qwen3、DeepSeek V3等千亿参数模型。这意味着：不是只有GPU才能跑大模型。 平头哥和玄铁的关系：很多人搞混了 阿里的芯片布局有两条线： 平头哥：做完整芯片（含光NPU、真武训推一体芯片等），全部是玄铁的客户 玄铁：做CPU IP授权，RISC-V架构，400+下游客户 简单说，平头哥是"整车厂"，玄铁是"发动机供应商"。玄铁不造芯片，但它的IP会出现在阿里云的服务器里、全志科技的AI眼镜芯片里、瑞芯微的机器人控制芯片里。 Agent时代CPU为什么重要？ 理解这个逻辑只需要一句话：GPU负责跑模型，CPU负责决定下一步干什么。 Chatbot时代，AI只有一个任务（对话），GPU从头包到尾。Agent时代，AI要同时做搜索、查数据库、调用工具、管理上下文——这些全是CPU的活。 如果CPU很慢，GPU就要等。整体效率不是被最短的板决定的，而是被最慢的环节决定的。 这也解释了为什么孟建熠两年前就立项做C950，那时"龙虾"还没火——他赌的不是Agent这个概念，而是"AGI时代CPU一定会成为瓶颈"这个判断。 RISC-V vs Arm：真正的差异化是"可定制" Arm授权模式是"你不能改我任何一行代码"。玄铁的做法相反：支持客户在自己的IP基础上二次开发和定制化。 这在AI时代可能是一个杀手级差异。AI终端形态百花齐放（眼镜、机器人、车载、边缘设备），每个场景对芯片的需求不同。标准化产品（Arm）很难同时满足所有场景，但可定制的RISC-V可以。 当然，生态壁垒仍然巨大——游戏、应用都针对Arm优化。孟建熠也承认"生态"是最难的事。 商业视角：这意味着什么 RISC-V拿到了云计算入场券。C950的性能已经可以用于云服务器CPU，堆叠多核后能进入数据中心。这意味着在x86和Arm垄断的市场里，出现了第三个可选项。 国产芯片的路径不是"替代英伟达"，而是"找到他们做不了的地方"。孟建熠原话：“我不是说一定要把谁颠覆掉，我认为我一定会找到他们做不了的地方。” “AI芯片=GPU"这个等式正在被改写。C950原生集成矩阵运算引擎，CPU直接跑千亿参数模型——GPU作为AI专用加速器的垄断地位正在松动。 生态建设必须背靠大厂。孟建熠在知合计算做了三年下游产品后得出结论：跳过生态做市场还是很难。阿里+达摩院的生态能力，是玄铁相比其他RISC-V玩家的核心优势。 英伟达也有路径依赖。孟建熠评价英伟达"成本很高”，CUDA仍会长期存在，但RISC-V+定制化这条路线，在特定场景下会更有竞争力。 基于新皮层（第一财经）与阿里达摩院首席科学家孟建熠的对话整理分析。 原文：https://mp.weixin.qq.com/s/W0S8H3ITwgCuGb9wMLgnsA

引子 2026年4月，中国AI产业出现了一个耐人寻味的分化。 一边是阿里巴巴成立 Alibaba Token Hub（ATH）事业群，CEO吴泳铭亲自挂帅，把Token上升为与电商、云智能并列的集团级战略。另一边是腾讯云副总裁李强公开表态：“无论现在Token涨价有多快，卖Token都不是一门好生意。” 同一个市场，两套完全相反的顶层设计。这到底是理念冲突，还是各取所需的理性分野？ 先把结论放前面：这不是谁对谁错的问题，而是两家公司基于不同基因、不同竞争位置，选择了不同的利润池。 一、李强到底在说什么？ 李强的核心论断，用了一个非常精准的比喻： Token = 油耗，大模型 = 引擎。 他的逻辑链条是这样的： 单纯卖Token没有黏性——客户今天用你，明天友商降价就跑了，替代成本极低。 过度补贴只会培养羊毛党——一旦停止补贴，客户流失率极高。 真正的壁垒在"引擎"和"整车"——也就是大模型本身的智能水平，以及应用层的闭环能力。 换句话说，李强并不是在否定Token的价值，而是否定卖Token作为一种独立商业模式的可持续性。这个判断，与NVIDIA黄仁勋把Token定义为"新的大宗商品"，本质上并不矛盾——黄仁勋是从需求侧描述趋势，李强是从供给侧警告同质化风险。 二、阿里为什么要全力推进ATH？ 理解阿里的选择，必须先理解阿里的处境。 维度 阿里的现实 战略动机 云的市场地位 阿里云是中国第一大公有云，但华为云、腾讯云紧追不舍 必须用"AI基础设施"（算力+Token）巩固B端客户黏性 模型生态 通义千问（Qwen）开源生态不错，但C端声量不如元宝/豆包 把Token作为企业入口，绑定客户使用阿里云的推理服务 商业基因 交易平台+基础设施平台 习惯先控货（Token），再在平台上做交易（应用/服务） 竞争焦虑 DeepSeek已经把Token价格打到地板价 必须规模化生产Token，用规模效应压低成本 阿里做ATH的本质，是把Token当成水电煤来卖。水电煤本身利润率不高，但只要你控制了管道和分发网络（阿里云 + 百炼平台），就能锁定大量B端和中小企业的AI入口。 三、两种战略的底层差异 腾讯（李强路线） 阿里（ATH路线） 核心判断 Token是"油耗"，低黏性、高替代成本 Token是"新的大宗商品"，要用规模锁定入口 竞争优势 微信生态、游戏/社交场景、C端触达 阿里云、电商数据、B端企业服务能力 打法 做"整车厂"：混元+QClaw+WorkBuddy+Lighthouse 做"加油站+炼油厂"：通义+ATH+阿里云 风险偏好 厌恶低毛利、转手贸易型收入 愿意在基础设施上长期投入，换取入口控制权 这个对比揭示了一个关键事实：两家公司对"护城河在哪里"的答案是不同的。 腾讯认为护城河在应用层和用户黏性；阿里认为护城河在规模化的基础设施和平台控制力。 四、谁更对？ 短期来看，两条路都能走通，但各自的风险点非常清晰。 阿里的风险：同质化陷阱 如果Token真的沦为完全同质化的大宗商品（就像李强警告的"油耗"），ATH可能陷入价格战泥潭。DeepSeek已经把百万Token价格打到地板价，阿里必须证明ATH不只是"更便宜的API入口"，而是能带来额外价值的智能体操作系统。 腾讯的风险：知行差距 李强的"引擎"论很对，但混元大模型目前的市场声量和性能表现，与GPT、Claude、甚至DeepSeek相比，还有明显差距。“引擎"做得不够好，整车再漂亮也跑不过别人。姚顺雨（前OpenAI研究员）加入腾讯主导混元开发，说明腾讯自己也意识到了这个短板，正在补课。 长期终局 纯卖Token的利润率会被持续压缩。 这一点，李强和黄仁勋的判断其实是一致的。 区别在于： 阿里选择在利润被压缩之前，先用规模和控制力占领市场。 腾讯选择直接跳过红海，做高毛利的应用和模型差异化。 最理想的战略，当然是两者的结合：强大的模型引擎 + 规模化的Token基础设施 + 不可替代的应用场景。 但现实中，很少有公司能同时把三件事都做到极致。 ...

本文由三篇架构师（若飞）深度解读文章综合分析整理，原文分别发表于 2026 年 4 月 8-9 日。 2026 年 4 月初，Anthropic 做了一件事：把 Agent 从"聊天框"里拽出来，按进了"真实工作"里。 4 月 8 日发布 Claude Managed Agents，4 月 9 日 Claude Code 源码 被翻了个底朝天。两件事合在一起看，不是一次偶然的巧合，而是一套完整的战略拼图。 我想用最直白的方式说清楚：Anthropic 到底在干什么，以及这件事对普通人意味着什么。 一、Agent 不再是聊天框 大多数人理解的 Agent，是这样的： 打开聊天框 → 问问题 → 得到回答 → 结束。 Anthropic 想做的完全不同。 Managed Agents 的本质，是把 Agent 从**“会话对象"变成"工作对象”**。 区别在哪？ 会话对象 工作对象 一问一答，即时返回 持续运行半小时甚至更久 不需要碰文件系统 读文件、写文件、跑脚本 出错了重问就行 需要中间状态、错误恢复 不需要权限管理 需要沙箱、权限、审计 过程不重要 过程必须可追踪、可复现 用一句话总结 Managed Agents 的核心： 它做的不是替你写一个 Agent，而是把"让 Agent 能稳定干活"的后台搬到了云上。 ...

一句话总结 Karpathy的LLM Wiki不是又一个笔记工具，而是一个给Agent用的长期工作底座： 传统RAG：查询时临时检索，问完即走，知识不沉淀 LLM Wiki：先编译成结构化知识层，持续回写，复利增长 核心差异：多了一层被Agent消费、持续维护的wiki中间层 一、从"临时检索"到"先编译再查询" 传统RAG的困境 大多数人用LLM和文档打交道的方式： 上传文件 → 提问 → 检索片段 → 生成答案 → 结束 问题： 今天问"这5篇文章共同说明了什么"，模型找5次片段、拼1次答案 过两天换个问法，大概率还要再做一遍 知识不会留下来，不会随着使用慢慢长出来 LLM Wiki的范式 原始资料 → 编译成wiki（摘要、实体、概念、索引） ↓ 查询时读index → 钻具体页面 → 生成答案 ↓ 有价值的结果 → 回写成新页面 核心洞察: “传统知识库更像’临时检索’，LLM Wiki更像’先编译，再查询’。” 二、三层架构：原始资料、Wiki、Schema ┌─────────────────────────────────────────┐ │ Schema（规则层） │ │ AGENTS.md / CLAUDE.md │ │ 定义：怎么组织、怎么ingest、怎么query │ ├─────────────────────────────────────────┤ │ The Wiki（知识层） │ │ LLM生成和维护的Markdown │ │ 摘要、实体页、概念页、索引 │ ├─────────────────────────────────────────┤ │ Raw Sources（事实源） │ │ 文章、论文、图片、代码 │ │ 只读，不改 │ └─────────────────────────────────────────┘ Schema：被忽略的关键层 作用：告诉LLM这个wiki应该怎么组织 ...

一、Michael Burry 的 3 年预言与市场的 40% 反转 2025 年 11 月，以成功预测 2008 年次贷危机而闻名的"大空头"Michael Burry 做出了一个大胆的判断：看空英伟达。他的核心逻辑简单直接——GPU 的生命周期只有 2-3 年，随着新一代芯片的推出，旧卡将迅速贬值，英伟达的高估值难以为继。 这个判断在当时就有争议，但也不无道理。毕竟，科技行业的摩尔定律历来如此：新产品推出，旧产品迅速过时。H100 在 2022 年发布，按照 3 年生命周期的逻辑，到 2025 年应该开始走下坡路。更何况，英伟达已经推出了性能更强、成本更低的 Blackwell 系列。 然而，仅仅 4 个月后，市场给出了截然相反的答案。 根据 GPU 租赁市场的最新数据，H100 的一年期租赁价格从 2025 年 10 月的 $1.67/小时/GPU 暴涨至 2026 年 2 月的 $2.35/小时/GPU，涨幅高达 40%。这张已经"服役"近 4 年的老卡，不仅没有贬值，反而出现了供不应求的局面——所有 GPU 类型的按需租赁容量完全售罄，到 2026 年 8-9 月的所有新增产能已被预订一空。 市场的疯狂程度超出想象： 客户正在争相以 $14/小时/GPU 的价格购买 AWS 的 p6-b200 现货实例 一些 Neocloud 巨头不再出售单节点 H100 正在以 2-3 年前签约时的完全相同的价格续约，一些 H100 合同甚至续约到 2028 年，为期 4 年 寻找哪怕 8 个节点（64 个 GPU）的 H100 或 H200 都不容易 SemiAnalysis 询问的供应商中有一半完全售罄，大多数供应商只会回应他们根本没有 Hopper GPU 的产能即将到期。市场上甚至出现了算力租户像摩纳哥大奖赛期间的公寓一样细分他们的集群并转租算力的现象。有人戏称：Neocloud 包租婆的时代即将到来。 ...

导语 2026年3月31日，AI圈经历了最戏剧性的一天。 Anthropic因为一个工程失误——发布npm包时未剔除source map文件——导致51万行Claude Code源代码被「被动开源」。短短几小时内，代码被下载、镜像，在GitHub上迅速扩散。 但故事远不止于此。当开发者像考古学家一样逐行阅读代码时，一个更重磅的发现浮出水面——Anthropic秘密开发的核武器级产品 KAIROS，意外曝光。 前特斯拉AI总监Karpathy第一时间围观并放话：“这就是Claude Claw。” 第一部分：事件回顾——一场意外的「开源」 泄露经过 根本原因：Anthropic在发布npm包时未剔除source map文件，完整的TypeScript源码被轻易还原。 扩散速度：短短几小时内，代码被下载、镜像，GitHub上fork超4万次。 官方回应：Anthropic发言人表示「没有涉及敏感客户数据或凭证，属于人为错误导致的发布打包问题」。 Claude Code之父Boris Cherny在X上简单表示：「就是开发者的错误。」 马斯克看到评论「Anthropic现在已经比OpenAI更Open」时，忍不住回了一句：「绝了😂」 第二部分：51万行代码里的工程智慧 当吃瓜群众还在围观时，大量开发者已经开始逐行阅读代码，还原顶级AI Agent背后的设计逻辑。 1. 系统提示词：行为控制的范本 完整的system prompt位于constants/prompts.ts，是整个代码库中最有价值的文件。 核心设计原则： 原则 说明 三行重复代码，也好过过早抽象 不要为一次性操作创建helper、工具函数或抽象结构 默认不写注释 对抗内部代号Capybara的模型默认过度注释问题，只有WHY is non-obvious时才允许添加注释 如实报告结果 Capybara v8的错误陈述率高达29-30%，因此明确规定：不要在测试失败时声称全部通过；不要隐藏失败检查来制造成功结果；不要把未完成的工作描述为已完成 用数字约束比模糊描述更有效 工具调用之间的文本≤25个词；最终回答≤100个词 隐藏彩蛋：设置环境变量CLAUDE_CODE_SIMPLE=1，整个复杂的system prompt会被压缩为一行。 2. 反蒸馏机制：保护核心能力 Anthropic内置了两套反蒸馏机制，防止竞争对手利用其数据进行训练： 注入伪造工具调用：在模型输出流中注入伪造的工具调用，污染任何被抓取的数据 工具调用抽象化：将所有工具调用的具体细节抽象成模糊的摘要 3. Prompt缓存：极致精细化管理 代码库中最复杂的非UI代码之一是promptCacheBreakDetection.ts。 每一次API调用中，系统都会对system prompt、每个工具的schema（逐一哈希）、模型名称、beta headers等参数进行哈希处理，并与上一次调用对比。 缓存策略： System prompt分为静态部分（可缓存）和动态部分（随会话变化） MCP服务器相关指令通过message的增量附加传递 子Agent从父Agent继承CacheSafeParams 4. Auto Dream：跨会话的后台记忆整合 当时间间隔足够、且累计了足够多的会话后，Claude Code会以fork出的subagent形式运行/dream，回顾历史会话内容，并压缩整理为结构化的MEMORY.md文件。 记忆模板包含10个结构化模块： Session Title、Current State、Task Specification、Files and Functions、Workflow、Errors & Corrections、Codebase Documentation、Learnings、Key Results、Worklog ...

导语 2026年3月31日，AI圈最炸的事件莫过于Claude Code源代码「被动」开源。 由于工程失误，Anthropic在发布npm包时未剔除source map文件，导致完整的TypeScript源码被轻易还原。短短几小时内，代码被下载、镜像，并在GitHub上迅速扩散。 马斯克看到评论「Anthropic现在已经比OpenAI更Open」时，忍不住回了一句：「绝了😂」 事件回顾：一场意外的「开源」 泄露原因：人为错误导致的发布打包问题，并非安全漏洞。 Anthropic官方回应：「今天早些时候，一个Claude Code版本包含了部分内部源代码。没有涉及或暴露任何敏感的客户数据或凭证。我们正在采取措施防止此类事件再次发生。」 Claude Code之父Boris Cherny在X上简单表示：「就是开发者的错误。」 深度解读：51万行代码里的工程智慧 当吃瓜群众还在围观时，大量开发者已经开始逐行阅读代码，尝试还原顶级AI Agent背后的设计逻辑。 1. 系统提示词：行为控制的范本 完整的system prompt位于constants/prompts.ts，是整个代码库中最有价值的文件。它清晰展示了Anthropic如何在生产级编码Agent中精确控制Claude的行为。 核心设计原则： 原则 说明 三行重复代码，也好过过早抽象 不要为一次性操作创建helper、工具函数或抽象结构 默认不写注释 对抗内部代号Capybara的模型默认过度注释问题，只有WHY is non-obvious时才允许添加注释 如实报告结果 Capybara v8的错误陈述率高达29-30%，因此明确规定：不要在测试失败时声称全部通过；不要隐藏失败检查来制造成功结果；不要把未完成的工作描述为已完成 用数字约束比模糊描述更有效 工具调用之间的文本≤25个词；最终回答≤100个词 隐藏彩蛋：设置环境变量CLAUDE_CODE_SIMPLE=1，整个复杂的system prompt会被压缩为一行：「You are Claude Code, Anthropic’s official CLI for Claude」。 2. 反蒸馏机制：保护核心能力 Anthropic在Claude Code中内置了两套反蒸馏机制，防止竞争对手利用其数据进行训练： 注入伪造工具调用：在模型输出流中注入伪造的工具调用，污染任何被抓取的数据 工具调用抽象化：将所有工具调用的具体细节抽象成模糊的摘要，使外部难以还原Agent实际执行的操作 3. 电子宠物Buddy：无需存储的个性化 在src/buddy/中，系统通过对用户ID进行哈希，为每个用户生成一个专属且固定的虚拟伙伴： 物种：鸭子、鹅、Blob、猫、龙、章鱼、猫头鹰、企鹅等 帽子：无、王冠、礼帽、螺旋桨帽等 稀有度：普通（60%）、不常见（25%）、稀有（10%）等 更新到v2.1.89后，输入/buddy即可启用——即使配置了其它模型也可成功启用。 4. Prompt缓存：极致精细化管理 代码库中最复杂的非UI代码之一是promptCacheBreakDetection.ts。 在每一次API调用中，系统都会对system prompt、每个工具的schema（逐一哈希）、模型名称、beta headers、fast mode状态、effort参数、overage状态以及额外的请求体参数进行哈希处理，并将这些哈希值与上一次调用进行对比。 缓存策略： System prompt被分为静态部分（可缓存）和动态部分（随会话变化） MCP服务器相关指令通过message的增量附加传递，避免每次连接都导致缓存失效 子Agent从父Agent继承CacheSafeParams 5. Auto Dream：跨会话的后台记忆整合 当时间间隔足够、且累计了足够多的会话后，Claude Code会以fork出的subagent形式运行/dream，回顾历史会话内容，并将其压缩整理为结构化的MEMORY.md文件。 ...

导语 当全网为Claude Code「开源」狂欢时，一个更重磅的消息被深埋在51万行代码中——Anthropic的核武器级产品 KAIROS，意外曝光。 前特斯拉AI总监Karpathy第一时间围观并放话：“这就是Claude Claw。” 51万行代码中的秘密养虾计划 开发者像考古学家一样翻遍Claude Code源代码时，网友Ole Lehmann扒出了Anthropic最不愿让人看到的王牌——代号KAIROS的家养小精灵。 “我真不敢相信，这事儿居然没人讨论！” —— Ole Lehmann 这个发现让Karpathy感慨万千，直呼「知音」。因为这完全就是他预言中AI的下一个进化方向：一个「龙虾版」的Claude Code。 KAIROS：OpenClaw的全方位对标 KAIROS的定位，几乎就是对OpenClaw三大核心能力的全面升级： 1. 主动性：主动出击的「龙虾爪」 KAIROS是一个会主动找你的Claude。你还没开口，它可能突然出现，拍拍你肩膀，告诉你它刚刚干了啥。 24小时后台运行：你工作也好，睡觉也罢，它一直都在 心跳机制：每隔几秒收到Prompt——「醒醒，看看现在有啥值得干的活儿没？」 自主决策：判断是动手还是继续安静待着 一旦决定行动，它能：修代码bug、回消息、更新文件、执行任务……你不用再自己开口。 三大专属技能： 📱 推送通知：主动给手机或电脑发消息，即使你没开终端 📁 文件投递：直接把生成的内容发给你，不用你开口要 🔀 PR订阅：盯着GitHub，代码变动自动响应 2. 个性化：会做梦的AI KAIROS每天都会写日报——不是简单的记忆功能，而是详细记录：看到了什么、怎么判断的、做了什么…… 跨会话持续：记录越滚越长，全是追加式，不能删。养得越久，它会越好用。 上下文膨胀解决方案：让它做梦 晚上，KAIROS会运行autoDream流程，把白天学到的东西整合一遍，重新整理记忆。 “人类的设计太神奇了，谁想过睡觉居然能是一种处理上下文膨胀的巧妙设计。” 3. Skill生态：开箱即用 Anthropic本来就是Skill概念的鼻祖，KAIROS可以直接接入Claude Code已有的生态。 场景想象：不睡觉的联合创始人 把这些能力结合起来，KAIROS能做到什么？ 场景 KAIROS行动 你睡觉时网站挂了 自动检测→重启服务器→通知你，你看到消息时一切已恢复正常 凌晨两点收到客户投诉邮件 读完→帮你回复→记录全过程，你醒来时事情已经解决 这不只是员工，应该是个不睡觉的联合创始人。 Karpathy预言：AI的下一个进化方向 早在今年2月，Karpathy就预言：Claw是AI的下一个进化方向。 他用一个比喻说明技术栈的演进： 层级 比喻 用户角色 Chat 自己开车 全程操控 Code 坐副驾当导航 指导+监督 Claw 躺后排睡大觉 完全放权 自主权越来越高，主动性越来越强。 ...

模型能力已经足够强大，真正拖后腿的是稳定性——它跑偏、误判完成、在你不注意的地方悄悄变形。 引言：一个让人警觉的数字 同一个模型，提示词不变，数据不变，只是换一套运行方式，编程基准成绩就能从 42% 跳到 78%。 Anthropic 的例子更直观：同一个模型，单打独斗时看起来像是做完了，真跑起来核心功能却是坏的；换一套带规划、生成、验收的运行框架，成本高了，时间长了，结果反而能用。 这提醒我们：AI 工程的重心，正在从"让模型更会回答"，转向"让系统更稳地交付结果"。 第一部分：Harness 不是"壳"，是控制系统 很多人第一次听到 Harness，会本能地把它理解成"模型外面那层包装"。这个理解不够。 模型自己不会： 保存状态 维护工作目录 判断输出是否满足系统约束 知道什么时候该停、该继续、该回滚 自己搭测试环境 写完后自觉打开浏览器验证 决定这次提交能不能合并 Harness 不是给模型套上的外壳，而是把模型接进工程世界的那层控制系统。 它包括： 状态怎么保存 工具怎么暴露 权限怎么约束 输出怎么验证 上下文怎么管理 任务怎么续跑 什么叫"真的完成了" 这些东西并不花哨，甚至很多都不新鲜——文件系统、测试、日志、浏览器、Lint、计划文件，原本就是软件工程里再普通不过的东西。 但一旦主角从人类工程师换成模型，它们突然重新变成了核心。 因为模型最擅长的是生成，最不擅长的是在约束里稳定收敛。 第二部分：三篇文章的共同指向 2.1 Skills：把隐性知识变成显性协议 Skill 要解决的是提示词漂移、方法失传、工作流无法复用这些问题。本质上，是把原本靠聊天临场发挥的东西，搬进文件系统和版本控制。 2.2 Claude Code 实战：架构决策注入执行流程 Boris 那套 Research -> Plan -> 批注 -> Implement 流程最值钱的地方，在于它把"架构决策怎么进入执行流程"这件事做成了机制。 2.3 OpenClaw 架构：可控、可回放、可解释 lane queue、allowlist、JSONL 回放、语义快照——这些都在回答：系统怎么保持可控、可回放、可解释。 三篇文章，分开看像三个不同话题。放在一起，其实都在做一件事：把原本靠模型临场发挥的部分，改造成可沉淀、可约束、可验证的系统。 第三部分：三篇放在一起，都在做一件事 真正变化快的，往往不是那个最小执行循环，而是循环外面不断加厚的那层工程设施： 知识怎么挂进去 状态怎么存下来 权限怎么卡住 验收怎么接回来 也正因为如此，这一轮大家聊 Harness，越来越像在聊系统设计，而不是某个单点技巧。 ...

太长不看版 如果把《跟Cloudflare大佬学用 Claude Code》《Skills 详解》《深度拆解 Clawdbot（OpenClaw）架构与实现》放在一起看，会发现它们其实都在补模型外面的系统层 Harness 可以粗略理解成"把模型接进真实工作流的控制系统"，里面不只有工具，还有状态、约束、反馈和验收 它现在变重要，原因很直接：模型一旦开始真正动手，系统层问题暴露得比能力问题更快 具体做法会随着模型迭代不断变化，但知识沉淀、硬约束、反馈回路、完成标准这些问题不会自己消失 如果现在准备补 Harness，我会更建议先补统一知识入口、硬约束和验证闭环，再谈多 Agent 和复杂编排 先别把 Harness 当成一层"壳" 很多人第一次听到 Harness，会本能地把它理解成"模型外面那层包装"。这个理解不算错，但也不够。 如果只是为了做一个短对话应用，你确实可以把它理解成包装层。一个聊天窗口，加一个消息循环，再加几个工具，差不多也能跑起来。但一旦任务开始变长，事情就不是"包一层"这么简单了。 模型自己不会保存状态，不会主动维护工作目录，不会判断某次输出是不是已经满足了系统约束，也不会天然知道什么时候该停、什么时候该继续、什么时候该回滚。它当然也不会自己给自己搭测试环境，更不会在写完之后自觉打开浏览器、点一遍页面、看一眼日志，再决定这次提交到底能不能合并。 所以我现在更愿意把 Harness 理解成另一种东西：它不是给模型套上的外壳，而是把模型接进工程世界的那层控制系统。 这里面通常包括几类东西： 状态怎么保存 工具怎么暴露 权限怎么约束 输出怎么验证 上下文怎么管理 任务怎么续跑 什么叫"真的完成了" 把这几样拆开看，你会发现它们并不花哨，甚至很多都不新鲜。文件系统、测试、日志、浏览器、Lint、计划文件、审批机制，这些原本就是软件工程里再普通不过的东西。 但一旦主角从人类工程师换成模型，它们突然重新变成了核心。 因为模型最擅长的是生成，最不擅长的是在约束里稳定收敛。 为什么它偏偏现在火了 如果把时间往前拨两年，你会发现那时候大家最关心的是 Prompt Engineering。核心问题是：怎么把一句话说清楚，让模型按你的意思回答。 后来上下文变长了，任务变复杂了，大家开始聊 Context Engineering。问题也跟着变了，不再是"这一句怎么写"，而是"什么信息应该放进来，什么不该放进来"。 再往后走，就到了今天这个阶段。 Prompt Engineering 和 Context Engineering 当然没有过时。更准确地说，它们被包进了一个更大的问题里。 现在更让人头疼的问题变了：模型能理解需求，但在一个复杂系统里，它能不能把事情从头到尾做稳？ 这也是为什么最近围绕 Harness 的材料，明显都带着一种很强的"实战味"。 Mitchell Hashimoto 提出 Engineer the Harness，出发点很具体：每当 Agent 犯了一个错误，就别只盯着这次对话修修补补，把修复方式沉淀进系统，让它下次别再犯 OpenAI 的 Codex 团队讲得更直接。他们从零开始跑出一个大规模代码库之后，最后得出的重点，落在三件事上：仓库怎么成为统一知识入口，架构边界怎么机械执行，PR 怎么通过 Lint 和测试去卡住错误方向 Anthropic 的材料也很典型。里面有一个很朴素的发现，我一直记得：模型并不擅长评价自己的工作 这句话看起来平淡，其实分量很重。因为它把很多人真实碰到的问题说穿了。页面看起来像是做完了，交互其实没通。功能大体对了，边界条件一跑就露馅。代码能过一部分测试，但系统层面已经悄悄偏离了原本的设计。 ...