说完了前面的发展史，我们可以看到，模型能力很重要，但一个 Agent 能不能把任务做完，还取决于它外面有哪些东西。

我们可以用一个非常朴素的说法：模型像一个会思考和表达的核心，Harness 是让这个核心持续工作的环境。它把任务和信息送进去，把工具调用接出来，把执行结果送回去，再决定继续、重试、交接还是结束。

我倾向于把 OpenAI、Anthropic、Google 理解为在模型、工具组织、多模态等方向上各有强调。但不能把三家划成互斥的路线：它们都在做模型和产品，也都在做工具与多模态。“哪家语言最好”“哪家代码最强”，还要看具体版本和任务，不能用一个永久标签替代实际测试。

以前我们需要专门的 PPT 工具做演示，现在也可以让模型用 HTML 做一个能展开、能交互的讲稿。视频、语音、新闻稿、代码动效，也越来越容易生成。这当然带来了便利，同时也带来了大量质量参差不齐的信息。

所以我认为，真正稀缺的已经不只是信息，而是我们筛选信息的能力，以及还能留给自己多少精力。每天看了很多视频，不代表真正吸收了多少东西。你可能只是越来越累，越来越难形成自己的判断，跟着信息流里的意见往前走。

这里我提出第一个观点：AI 最值得帮我们做的事情之一，就是高效地获取、过滤和提炼信息。把一个十几分钟、二十几分钟的视频，整理成有来源、有重点、能判断值不值得继续看的内容。对确实可复用的部分，再沉淀成自己的 Skill。

我需要保留精力去做一些看起来“没有产出”的事情：发呆、思考、钻研一个问题。时间很公平，精力却非常容易在不知不觉中被花掉。AI 如果只是给我更多内容，就没有帮到点上；如果它帮我少看一点、看准一点，才有意义。

当然，信息先过 AI，也可能把模型的遗漏和偏见带进来。所以摘要要保留原文链接、时间戳和不确定项；影响判断的重要内容，仍然回到原始材料。过滤不等于把判断权也一起交出去。

接下来我们讨论：Agent 的注意力是怎么被消耗的？模型一开始可能会看到系统指令、项目约定、Skill 目录、工具定义，再加上用户任务和历史消息。这里面有很多东西，对任务有帮助；但堆得过多，也会增加干扰。

不同产品、不同信息层有各自的预算：自定义指令、项目约定、Skill 目录和正文，并不共用一个统一上限。管理上下文时，先看清楚被限制的是哪一层。

下面把不同层的预算放在一起看。字符、字节和 Token 各有自己的口径，实际使用时按对应产品的配置来管理。

The budget scales at 1% of the model’s context window.

this list uses at most 2% of the model's context window

Free and Go users can save up to 1,500 characters

loads a CLAUDE.md file of up to 4 MiB in full and skips a larger file.

MCP 的确不只有工具。Resources 可以提供数据，Prompts 可以提供可选择的提示模板，Tools 则让模型提出操作请求。协议的 Sampling 能力还允许服务器向客户端请求模型生成，但仍然受客户端控制。

MCP 可以参与上下文的组织，但它没有天然的权限去任意读取、改写整个模型上下文。尤其是服务器传来的说明，并不自动变成最高优先级 System Prompt。

真正影响上下文占用的，是宿主怎样发现工具、是否延迟加载描述、怎样把资源和结果送给模型，以及收到太长的工具输出后怎样处理。

Claude Code truncates tool descriptions and server instructions at 2KB each.

假设你装了 100 个 Skill。它们不会全部以完整正文进入上下文；但目录本身也会占预算。描述被缩短或条目被省略之后，模型可能更难准确匹配任务。实际表现可能是不调用、选错，或者需要你明确点名。

所以我的建议仍然是：对 Skill 做严格管控。全局只放经常需要、触发条件清楚的能力；面向特定项目的流程，尽量放进项目。不是安装得越多，Agent 就越强。

同样，AGENTS.md 和 CLAUDE.md 也需要分层。全局写长期稳定的个人约定，项目级写架构入口、环境和验证方法，具体领域的细节再放到靠近相关目录的文件里。项目大，不代表每次都要把所有项目知识一次性喂进去。

比如，我也会把自建 API 的接入说明放在合适的项目约定里，让 Agent 开发相关软件时知道怎样接入。这里有价值的是我自己的环境和工作习惯，不是一份网上复制来的通用长文件。

你会发现，这些东西在做同一件事情：渐进式披露。先知道去哪里找，再在需要的时候读取；先有一份简短地图，再进入具体房间。Skill 再次被读取后，任务相关步骤会重新进入当前上下文，这比指望模型一直记住很早以前的长篇说明更稳妥。

项目目标：把用户提供的研究材料整理成可追溯的讲稿。 入口：README.md 说明目录；docs/sources.md 记录资料来源。 环境：先阅读项目已有配置，沿用现有依赖与构建方式。 验证：对照验收清单检查链接、数值、版式与交互。 完成：报告已完成内容、验证结果和剩余不确定项。 敏感配置：从项目约定的环境变量读取凭据。 权限边界：公开发布与对外发送遵循用户已授权的范围。

那么问题来了：当我们执行了很长的任务，读了很多文件，聊了很多轮，上下文快满的时候会发生什么？如果没有处理，后续请求就可能无法容纳更多输入和输出。很多 Harness 会提前压缩历史，让任务继续。

你可以把它类比成写一份交接摘要，再接着工作。但实现不一定真的是“重新开一个窗口”：有的在当前会话里替换历史，有的调用远端压缩接口，有的保留结构化或不透明的状态。完整历史是否还存在，也要看产品如何持久化。

压缩的风险是有损：它可能漏掉约束、细节和早先的决策理由。这不是说每次压缩都会明显变差，而是我们不能把摘要当成完整原文。所以需要可回看的记录、外置状态，以及清楚的下一步。

那我们要怎么做？第一种方法，是把任务拆到一个上下文内能比较稳定完成的规模。第二种方法，是把重要状态留在文件和任务记录里，让模型在压缩之后还能找到方向。

我这里用的是 codex-handoff。当一个任务的历史太长、响应开始变慢时，我会明确调用它，把当前目标、已经完成的工作、关键决策、验证结果和剩余步骤整理成一份紧凑的连续性提示。它一般控制在 2,000–4,000 个中文字左右，详细资料尽量用文件和链接指向原件。

接下来，它会找到当前保存的项目，创建一个新的、用户可见的 Codex 任务，让新任务从明确的第一步继续。旧任务保留为历史，停止继续编辑。同一个任务的目标还在，但新任务不必每轮都背着完整聊天记录。

这里，Plan 负责总体路线，Handoff 负责当前现场。这个 Skill 的具体实现是直接创建新任务，因此需要 list_projects 和 create_thread 等能力；普通的“继续做”不会触发它。它也不会把创建新任务替换成写一份 Markdown 文件。

codex-handoff GitHub 文档 ↗ · 查看上传版本与复制全文

哎，这里终于涉及到 Subagent 了。它的一个优势，是把一个边界明确的任务交给另一个工作上下文：它只需要知道完成这件事所需的信息，不必背着主会话里的全部历史。

例如主 Agent 负责整合，子 Agent 分别检查资料、实现一个模块、审核一个结果。它们最后交回必要的结论和证据，主 Agent 就少读一些中间过程。这跟人类分工协作很像：每个人先把自己的事情做好。

但“新上下文”并不意味着模型能力天然更强。有的系统会继承历史，有的从少量任务说明开始；如果交接不完整，它反而可能不知道关键约束。真正的优势是减少无关干扰、隔离任务、并行推进，而不是凭空增加智力。

我自己的使用感受是，有些产品即使有子 Agent，也不一定在我期待的时候主动调用。遇到确实可拆分的复杂任务，我会明确说：请积极使用 Subagent，给每个子任务明确边界，并说明各自的验收结果。这个体验与产品版本、配置、任务有关，不能说所有 ChatGPT 都是同一种行为。

Multiagent 的另一个好处，是可以用新的上下文来审查结果。我自己刚做完一件事，很容易沿着已有的思路继续看；换一个审查者，可能更容易问出我没问过的问题。

但多叫几个模型来辩论，并不保证结果一定正确。它们也可能共同相信一个错误。更有价值的是：审查者能看到原始需求、产物、测试结果和来源，然后逐条判断到底有没有完成。

这里我推荐我自用的思路：Implementation Critic。完成一个交付物后，调用独立、只读的 implementation_critic。主 Agent 只传原始需求和已做事项，审查者自行检查产物和证据，返回 PASS、NEEDS FIXES 或 BLOCKED，并给出明确修订方向。修复时只处理失败项，已经通过的部分尽量保持稳定。

当然，我也发现这个 Skill 有时会过度触发：任务中途，甚至刚开始就来审核。它是不是也可能帮助提前发现问题？有可能，但我没有实验能证明。更稳妥的做法，是把“计划审查”和“成品验收”分开，写清触发条件，再观察它到底减少了多少返工。

查看 Implementation Critic 完整 Skill 与 Agent 配置

Plan 模式的作用，是在真正执行前，先把计划摆出来，让你有机会纠正目标、约束和实现方向。对于复杂任务，我愿意用更强的模型做规划，再让合适的模型负责实现。

但这里不需要用“把强模型的潜空间传给弱模型”来解释。真正传过去的是一份显式的中间产物：任务拆分、约束、接口、验收标准。它可能降低实现难度，也可能因为错误假设把问题带下去，所以仍然需要检查。

我很喜欢的一类 Skill，是用连续提问帮我梳理需求。这里可以用 grill-me。它强调把需求问透：你到底想解决什么问题，哪些边界情况必须考虑，哪几个选择会改变实现方式。这是一种苏格拉底式提问。

这种方法不只用于写代码。做 PPT、写文章、设计一个项目，也可以先被认真地问几轮。然后把达成共识的计划变成可执行阶段。阶段状态及时记录下来；当当前任务过长时，再明确调用 codex-handoff，把这些状态交给新任务。这样计划、执行、审查、交接就连接起来了。

grill-me ↗ · grilling ↗ · handoff ↗

当你和 Agent 对话时，有没有发现，它有时会反复告诉你“我没有做什么”？你只是要求改一个地方，结果它花了很多篇幅汇报自己避开了什么。

所以我现在会做一个改进：对于语言风格和一般输出要求，尽量直接写目标行为。比如“先给结论，再给必要证据”，比堆一长串不喜欢的句式更容易执行。你希望它关注什么，就把那个东西写清楚。

这个做法对我很有帮助，但我不把它解释成模型有一个独立的“不要空间”。模型处理否定的效果会受任务和表达影响，这里没有证据能用一个固定潜空间机制解释所有现象。

同时，明确的权限边界和禁止事项仍然有价值。像不得泄露凭据、发布前遵循授权范围，这些不能为了“全用正面表达”就删掉。我们要减少的是无用的反复，不是必要的约束。

回到前面那个问题：一年前的模型已经能完成我的工作，为什么我还要用新的？如果旧模型已经稳定、便宜、够用，继续用当然有意义。

但模型价格不是全部成本。一个更强的模型，如果能少误解一次需求、少来回沟通几轮、少让我查十几个错误，可能反而更便宜。尤其当任务模糊、跨很多文件、需要高质量判断时，人的检查和返工成本常常比一次调用费更值得关注。

所以我更喜欢按任务选模型：难题和关键判断用强模型；规则清楚的任务用轻量模型；稳定重复的动作写成脚本。Subagent 也遵循这个原则，不必让最贵的模型处理每一项小事。

至于模型是不是越来越偏代码、写作是不是变差，这里面既有可测的产品变化，也有个人偏好。Strawberry 数字母、某种过度迎合的口吻，都不能单独证明整个领域在退步。保留自己的测试集，比跟着一次热帖判断所有模型更有用。

这是选择模型的思考框架，不是某个厂商的计费公式。

前面讲了这么多 Skill，我更想强调的是：它们不是装得越多越好，而是要能解决你自己的问题。先用一个真实任务试，再看哪里误触发、哪里没完成，逐步修改。

我的视频工作流负责从收藏夹扫描新内容、提取转写，再把值得复用的方法交给 Skill Vault。Skill Vault 负责收藏、索引、推荐与项目级安装。这样一个视频就不只是看完即止，而是可能成为以后真正能调用的工作方法。

讲到这里，我想把整场内容收回来。AI Agent 很重要的一件事，是管理它的上下文，管理它每一步应该关注什么。Skill 的渐进式披露、明确任务边界的 Subagent、流程编排、状态交接，都是在帮助它把注意力放到当前任务上。

同样的思路，也可以作为一个类比放到我们自己身上。人的精力不是模型的 Token 窗口，但我们确实需要减少无关信息的挤占。让 AI 帮我浏览、过滤、提炼，再把真正值得看的内容交给我，是我更愿意长期使用它的方式。

如果你说“AI 自己也很啰嗦，我读它的文字就已经很累了”，那么可以试试 I have ADHD 这样的表达约定：先说下一步，句子短一点，重点少一点，把细节放到需要时再展开的地方。

我们要留下的，是判断什么值得做、定义什么叫做好，以及做出选择的能力。让 AI 帮我省下一些精力，我才能把这些精力，重新花在自己真正想做的事情上。