先说结论

这场 B站 Builder Club 交流日的主题分享，主讲人是 GitHub 中国区 Top 100 开发者、Open CLI 作者、Apache 项目核心成员卡比，主题是如何「Harness」大模型——让 AI 说真话、记得住、不跑偏。他把这件事拆成三层功夫：管好上下文、用方法论替代 Skill、建立长活 Agent 与 Agent Team。整场最有记忆点的判断是一个「暴论」：所有 Skill 都会死，生命力不超过几个月——因为模型每训练一轮，Skill 的内容就会被吸收进预训练，留到最后的不是提示词工程，而是能激活模型参数的方法论名字。另一个反直觉的事实是：你感受到的「AI 很强」，一半功劳属于 Harness 而非模型——上下文里的状态栏让模型在第九十九轮仍记得第一轮的初心，而稀疏注意力机制让名义上一百万 token 的窗口实际有效的可能只有几十 k。对普通使用者的启示很直接：上下文是需要主动管理的资源，而编排能力——拆解任务、管理状态、沉淀流程——正在成为人相对于 Agent 的最后位置。

Harness 是什么：从聊天框到运行时

卡比从时代切换讲起。ChatGPT 时代是「文本进、文本出」，你让最早的 ChatGPT「帮我创建一个文件」，它只能回复一段文字；Agent 时代之所以能真的把文件建出来，是因为我们给 AI 提供了一套运行时脚手架（Harness）——AI 回复代码或指令，框架负责执行。在他看来，这套框架由四个部分组成：上下文管理与 Memory、工具调用、任务规划与分解，以及 AI 的 Tracing。

工具调用带来的能力扩展是直观的：以他自己的 Open CLI 为例，AI 能通过 CLI 工具查看网页内容、主动压缩自己的 Memory、执行代码。任务规划则回答了一个关键问题：为什么 AI 执行到第九十九轮，还记得第一轮提出的目的是什么？因为 Harness 内部有一套任务拆解与规划的流程。他引用了分享当天的一条新闻：Claude Code「完成了费马大定理的证明」——这类需要约五天才能完成的复杂任务，正是靠拆解成子任务、逐层推进来完成的。对这条当日新闻，本文按分享者转述记录，未做独立核实。

Tracing 的价值则连接到模型训练本身：Harness 可以把 AI 每一轮的思考路径全部记录下来，放进后训练数据。他举的例子是刚发布的 GPT-6（分享当日新闻）——它的 Computer Use 能力之所以丝滑，是因为 GPT 把操作电脑的轨迹全部放进了模型内部，模型「学会了使用工具的路径」。

落到具体结构上，现在的 AI 上下文一般分四层。第一层是系统提示词，卡比给了一个精辟的定性：它相当于模型的「激活参数」——你定义 AI 是猫娘，它就回复「喵」；你定义它是财经调研专家，模型里财经金融相关的参数就会被激活。第二层是工具描述层，包含 MCP 和 Skill。第三层是对话层，记录每一轮的对话、回复、思考和工具调用。第四层是 AI 状态栏——把「主要目标是证明费马大定理、目前进行到第几步」这类目标与进度显式记录在这里，就是长任务不跑偏的机制。「现在的 AI 你使用起来很强，并不仅仅是模型的能力，实际上也有 Harness 的功劳」，状态栏就是典型例子。

上下文管理：有效上下文才是真瓶颈

理解了四层结构，第一个推论是工具层要省着用。卡比算了一笔账：一个 MCP 的描述可能占用 1k 到 10k token，装十个 MCP 就是 10k 到 100k；而据他所说，千问 3.7 的上下文窗口也才 256k——装二十个 MCP 就可能把窗口塞满。很多人习惯在全局空间装一百个 Skill、十来个 MCP，在了解上下文设计之后，这个习惯需要重新审视。

第二个推论更隐蔽：标称窗口不等于有效上下文。他指出目前主流的上下文实现机制是稀疏注意力——名义上有一百万 token 的窗口，实际真正有效的可能只有 50k，超出部分被「稀疏掉」了。这解释了一个常见困惑：明明十句话之前说过的内容，二十句之后模型就忘了——不是因为你没压缩，而是因为那些内容虽然在窗口里，却已经不在有效范围内。他给现场听众留了一个思考题：用 Claude 时上下文用到 500k，该不该压缩？压缩哪些内容？他的建议是，每个使用者都应该随时清楚当前窗口里装了什么、什么时候该主动压缩。

具体怎么防腐，他给了三个做法。其一是主动压缩加落盘：有效窗口快满时让模型压缩，压缩前把关键信息保存到本地，比如 memory.md 或记忆类 MCP（他提及的工具名转写为「OpenWakeng」，未能核实原名）。其二是「窗口笔记」：他自己的开发习惯是每完成一个任务，先写一份 note 记录做了什么、调研了什么、做了哪些实验，保存到笔记里之后再把上下文压缩掉，继续下一个任务。其三是分治上下文：把子任务派给子 Agent，所有中间过程的上下文都留在子 Agent 上，主 Agent 的上下文不被腐化。

这套逻辑也重新定义了系统提示词的写法。卡比明确反对半年前流行的那种复杂写法，尤其是禁令式的提示词——「不许用这个、不许用那个」效果往往不好，因为随着模型能力变强，不应该靠下限制来指挥它。他写项目级系统提示词只包含三样东西：你是什么、你做什么；当前项目的代码地图（让模型了解整个项目上下文）；以及尽量短——「系统提示词现在不是越长越好了」，因为绝大部分通用提示词已经被预训练进了模型内部。

所有 Skill 都会死：方法论是一句顶一万句

第二部分卡比自称要放一个「暴论」：目前所有的 Skill 都会死，生命力不会超过几个月。机制很简单——模型每训练完一轮，之前所有 Skill 的内容都会被训练进预训练，既然知识已经进了模型内部，Skill 的存在意义就只剩一点点。

他举的案例很具体：Superpowers，一套头脑风暴类 Skill，半年前相当好用；但半年后再装它，模型反而会「降质」——因为它的上千行内容模型已经全会了，那些行数对模型来说都是废话，只会干扰思考。取而代之的是新 Skill Grill Me（转写名称，未能进一步核实），只有三行，却比之前一千行的版本更好用。由此他给出了 Skill 的真实定位：每个 Skill 的作用都是「给预训练提供养料，养料完它就死掉了」——这是它的功能，而不是它的缺陷。

Skill 死后留下什么？方法论。卡比把方法论定义为「把一整套 Skill 变成一个名字」，这个名字激活模型内部的一整套流程知识。他举了几个例子：最基础的是第一性原理（转写原稿作「低信原理」，据上下文校正如是）——只需对 AI 说出这五个字，模型能力立刻提升超过 20%（节目称），因为模型会自动按第一性原理的路径思考，根本不需要你花一千字去教它。类似的还有对抗式审查，以及最近很火的消融实验——他说 ChatGPT 5.6（转写版本号）非常喜欢过度设计、堆冗余测试，你只要说「帮我进行消融实验」，它就会自动把多余的设计和思考全部去掉。还有一个是独立思考：Claude 有个出名的毛病是谄媚，你明明说错了它也会来一句「You are almost certainly right」，但只要加上「保持独立思考」几个字，它就不再附和你。

这一机制的底层与前文「系统提示词即激活参数」完全同构：通过一个方法论的名字激活模型的参数域，让模型变得更聪明。用他的话说，「所有的方法论都是一句顶一万句」，「模型聪不聪明，也看你怎么用」。

长活 Agent：一个开源社区的真实实验

第三部分从卡比自己的项目讲起。他们的 Apache 项目（转写为「Apache Maka」，未能核实项目原名）约有十个 maintainer，社区每天有超过一百个 PR 需要 review，纯靠人工根本看不过来。他们的方案是：每人维护四到五个长活 Agent，并给 Agent 制定一套方法论和流程——先对 PR 分类（是 commit 提的、maintainer 提的、还是首次贡献者提的？是 bug 修复、文档改动还是核心设计？），然后按「复现、定位、评分、改进」的固定路径推进，评分通过且无可改进即 approve，另设定期巡检让 AI 自动运行。据他介绍，这套体系已经在社区连续运行约一个月，全部成员靠它维护项目。

长活 Agent 和普通一次性会话的差别，被卡比总结为三重资产的累积。其一是可复用的上下文：一次性会话用完即弃，每次都要重新导入项目的全部背景；而长活 Agent 一直存活，它记得项目的所有相关信息。其二是做事风格：就像公司里每个人都有自己的风格，Agent 在长时间运行中会形成自己的审美——知道怎么拆任务、怎么 review、什么样的 PR 算过，他形容这「类似一套 RSI（递归自我改进）」。其三是工作流与准则：Agent 会沉淀出自己的 principle，甚至会在工作过程中把好用的经验自动总结成 Skill，方便自己复用。到这个阶段，一个长活 Agent 就「像一个人一样」了。

多 Agent 三形态与人的位置

一个长活 Agent 够吗？显然不够——你需要很多个做不同任务的 Agent，于是进入多 Agent 的组织问题。卡比把当前的多 Agent 形态分为三类。第一类 Agent Swarm 适合能拆成若干独立并行任务的工作：十份文档要翻译，派十个 Agent 同时做，彼此互不依赖。第二类 Agent Graph 处理有前后依赖的任务链：前端依赖后端、review 依赖测试，任务构成一张图，逐层递归推进。他再次引用费马大定理的新闻：Claude Code 的证明用的正是一套 DAG 框架，把证明任务编排成有依赖关系的工作图逐层完成——他补充说，这套 Graph 是 Claude Code 的内部产品，并未对外开放，Codex 目前也没有推出正式的 Agent Graph 产品（均为分享者转述）。

第三类 Agent Team 则是根本不同的架构：前两者都有主从关系、有协调者，而 Team 是对等的——每个 Agent 都像独立的人，有自己的独立 Memory，且都是长活 Agent。它最大的难点在于编排与维护：怎么给每个 Agent 赋予独立角色、分配任务、决定它装什么 Skill、它如何承担和协作。他提到两个 Agent Team 形态的产品 Rapid Build 和 Growbot（转写名称，未能核实），以及他们自己社区的 Agent Team 群作为实例。

Maka 的 Graph 实现值得展开：他们搭建了一套控制面集群（转写作 Sequoia），定义一个主 Agent 负责任务拆分、规划和监督——追踪整个状态图推进到了哪一步；每个子 Agent 则配了一套 AI Infra 框架，其全部的 log、快照、Memory、Session 都被全量保存，汇入控制面，直到整个任务推进完成。

讲完全部技术方案，卡比把位置留给了人：「我们人目前是 Agent 最核心的部分」——任务拆分、上下文管理和记忆，目前都依赖人来完成。他最后的建议是把自己常用的流程和策略沉淀成 CLI、MCP 或脚本，并且让它们符合一套设计哲学：AX，即「让 AI 友好」。

这对使用者意味着什么

把整场分享收拢成三件事：管理好上下文，用好方法论，建立自己的长活 Agent 和 Agent Team。这三件事背后有一条一致的主线：模型会持续吸收一切显式知识——今天写的千行 Skill，就是明天预训练的养料；而 Harness 的价值随之从「往窗口里塞知识」转向「管理状态、记录轨迹、组织协作」。

对读者的可操作启发至少有三条。第一，把上下文当作要主动管理的资源：用任何模型之前，先想清楚当前窗口里装了什么、占用了多少、什么时候该压缩，任务结束先落盘笔记再压缩上下文。第二，用方法论的名字替代长提示词：第一性原理、对抗式审查、独立思考——先给模型一个激活点，而不是写一千字的教程。第三，观察 Skill 生态本身就是观察模型能力边界的窗口：哪些 Skill 死了，说明哪些能力已经进了模型；而那些模型还没吸收的流程——尤其是你自己工作流里独有的部分——才是值得沉淀成长活 Agent 和 AI 友好工具的地方。