知识喂养

上下文视角：无论用哪条路径注入知识，最终都是往上下文里放信息——区别在于什么时候放、放多少、放多久。

前面九节，我们拆解了上下文的各种载体——System Instructions、工具、MCP、Commands、Skills、CLI 工具、Hooks & Plugins。每种载体解决一个问题：怎么把信息送进上下文，或者怎么在上下文流动过程中拦截和修改。

这一节换个视角：你是供给侧。你手里有项目知识、团队规范、个人偏好，怎么系统性地喂进去？

上下文像牛奶

Agent 的能力上限 = 它拥有的高质量上下文。LLM 自带通用知识，但不知道你的项目用什么框架、代码怎么组织、团队有什么规矩。没有这些项目级知识，它只能给通用建议。

但上下文像牛奶：新鲜时营养丰富，放久了变质，塞太多冰箱放不下。知识喂养就是建一条供应链——在正确的时间，通过正确的管道，输送正确剂量的新鲜牛奶。

三条路径

路径	核心机制	注入时机	上下文落点	持久性	适用场景
规则层	System Instructions	会话开始，自动加载	system prompt	默认存在	项目规范、编码约定、安全护栏
能力层	Skills	任务需要时，按需加载	system 或 messages（视工具实现）	会话内持续（部分工具支持停用）	特定领域工作流、最佳实践
项目层	代码库 + 文档结构	Agent 读取文件时	user/assistant messages	按需	项目结构、README、注释、llms.txt

1. 规则层：给 Agent 立规矩

通过项目级指令文件（如 CLAUDE.md、AGENTS.md 等，不同工具使用不同文件名），你写下的规则在每次会话开始时自动注入 system prompt。

这是最直接的知识喂养：

• 项目用什么语言、什么框架、什么包管理器
• 代码风格约定（缩进、命名、commit message 格式）
• 不可逾越的红线（"禁止使用 npm"、"永远先写测试"）

规则层的特点：全局生效、强制执行、每次会话都在。它是 Agent 世界观的地基。

这些规则是两种经验的沉淀：踩坑教训——每条"禁止"背后是一次真实事故；验证过的好做法——每条"必须"背后是反复确认有效的成功模式。新人（和 Agent）不需要亲自踩坑或重新发明轮子，因为这些教训和好做法已经替他们记住了。

代价也明确：它始终占用上下文窗口。塞太多规则，留给实际任务的空间就少了。

2. 能力层：按需加载领域知识

规则层告诉 Agent "该做什么不该做什么"，能力层告诉它"怎么做"。

加载一个 Skill——比如一个专门处理 git 操作的 skill，或一个专注前端设计的 skill——就是把一整套领域知识动态注入 system prompt。Agent 瞬间从"什么都懂一点"变成"这个领域的专家"。

关键区别：按需加载。启动时只有名称和简短描述进入上下文，LLM 判断需要时才加载全文。不需要时几乎不占上下文。

写一个好的 Skill，等于写一份给 Agent 看的领域手册。它包含：决策流程、最佳实践、常用命令、常见陷阱。这些知识只在特定任务场景下需要——不值得塞进全局规则，但在需要时必须完整呈现。

3. 项目层：让你的项目对 Agent 友好

前两层解决"怎么做"的知识。但 Agent 干活时，还需要大量"是什么"的事实信息——你的代码库长什么样、API 怎么调、业务逻辑怎么走。

这些信息不是你直接"喂"的，而是 Agent 在工作过程中自己去"读"的。你能做的，是让它读得更顺畅。

这就是项目层的核心思想：你的代码库本身就是 Agent 最大的知识源。让它对 Agent 友好。

怎么做：

• 知识入口文件：CLAUDE.md、AGENTS.md，以及部分框架和文档站支持的 llms.txt——告诉 Agent "从这里开始了解这个项目"。就像给新人一份 onboarding doc。
• 清晰的项目结构：目录命名有语义、模块划分清楚。Agent 靠文件路径推断上下文，src/utils/helpers.js 几乎不传递信息，src/auth/jwt-validator.ts 一看就懂。
• 代码即文档：有意义的变量名、函数名，关键逻辑写注释。Agent 读代码的方式和你读代码的方式一样——清晰的代码对它也清晰。
• README 和 API 文档保持更新：过时的文档比没有文档更危险——Agent 会基于错误信息做决策。

项目层的特点：不额外占用上下文窗口（直到 Agent 实际读取文件时才进入上下文），但它的质量直接决定 Agent 理解你项目的准确度。

换个角度想：你为 Agent 优化项目结构的过程，其实也在为人类队友优化。一个 Agent 都读不懂的代码库，人类新成员大概率也读不懂。

还有一层：技术选型本身也是上下文。成熟稳定、文档丰富的技术栈，训练数据里高质量样本多，Agent 天然掌握得更好。小众框架或文档稀少的工具，Agent 表现会明显下降——不是它笨，是它训练时没怎么见过。

按需喂养：把 Agent 当人看

Agent 和人一样，记不住所有东西。给它一本大英百科全书，它会直接跳过。

资料放进去，不等于重点就自动对了

把一大堆文档塞进上下文，只能保证 Agent 看得见，不能保证它抓得住当前任务真正依赖的是哪部分。

喂材料之外，最好顺手点明：这次决策主要依据哪几个文件、哪几段、哪条规则。否则它看到的是一堆信息，不是清楚的优先级。

别把完整的 API 文档、数据库 schema 全塞进 AGENTS.md。你应该只给个索引，比如“数据库结构见 docs/db-schema.md”。

等它真要写 SQL 了，它会自己去查。让它自己拉取知识，别硬推。

指令文件自身也该遵循这个原则。与其把所有细节塞进一个文件，不如让它做目录——指向 docs/ 下的详细文档。Agent 启动时看到的是一张地图，不是一本百科全书。需要深入时，顺着指针自己去读。

字典 vs. 语法

两类知识，两种用法。

字典 (llms.txt, API 文档, Schema) 是用来查的，不是用来记的。这是事实，是静态的。把它们放在项目里，让 Agent 需要时自己读。

语法 (AGENTS.md, Skills) 是用来遵守的，不是用来看的。这是规则，是指令。把它们放在 Agent 的核心指令里，强制执行。

API 定义不该塞进指令文件——那是参考文档，让 agent 需要时自己去查。铁律不该散落在某个角落文档里——放在 agent 每次启动必读的位置，否则等于没写。

失败日志怎么变成下一轮的 context

知识喂养不只是你主动把文档、规范、规则推给 Agent。还有一路是 Agent 工作中产生的失败信息，如何自动回流进下一轮请求。

先说清楚：这一步发生在对话历史里，不是 system prompt。每次工具调用失败、命令报错、测试不通过，Agent 收到的错误输出都会作为工具结果追加到后续请求。不同 API 形态不一样：OpenAI 常见做法是追加 role: "tool" message；Claude 常见做法是在 user message 里放 tool_result block。LLM 在下一轮读到这些内容，才能决定怎么调整。

问题在于：失败信息如果不加处理地全量塞进去，很快就会成为上下文噪音。

一次完整的依赖安装错误日志可能很长。全塞进 messages，后续每轮都要带着它滚动。旧错误日志挤占上下文，真正需要的任务信息反而被稀释。

怎么控制：

采集粒度	做法	适合场景
粗：只保留最终状态	只传「失败 / 成功」和一行摘要	简单工具调用、不需要 LLM 自己分析原因
中：截断 + 关键段	保留错误类型、第一条报错、堆栈顶部，以及日志末尾的 summary	多数情况下的合理默认值
细：全量日志	原样传入，不截断；长日志优先保存到文件，只把路径和摘要放进 context	例外情况：调试复杂、LLM 需要完整上下文才能定位

部分 Agent 工具的 hooks 机制允许你在「工具返回」阶段做预处理：拦截原始输出、按格式过滤、只留关键字段，再放进 context。这就是失败日志进入下一轮之前的「摘要/筛选入口」。一个实用的输出格式示例如下：{status, exit_code, failing_command, first_error, relevant_tail}。

另一条思路：diff-first，不是 diff-only。如果 hook 或编排层能控制输入，而上一轮已经传过这个文件的完整内容，这一轮优先传 diff；需要判断意图、接口或上下文时，再补相关片段。避免同一份信息在 messages 里反复出现。

范围控制同样关键。不是所有失败都值得回流。低风险 lint 警告通常不需要进入 messages，但要先判断四件事：是否阻塞执行，是否需要改计划，是否包含新事实，是否重复出现。四项都是否，就可以在 hook 里丢弃或只记到本地日志。只有阻塞执行、需要 LLM 决策的失败，才值得消耗上下文空间。

怎么选

你的知识是……	用……	因为……
全局规则，必须时刻遵守	规则层	每次会话自动生效，不可跳过
特定领域的方法论或工作流	能力层	按需加载，不用时不占上下文
项目的事实信息（代码、文档、结构）	项目层	让 Agent 自己读，你只需维护好源头

成熟的 Agentic 工作流，通常是三层的组合。规则层定底线，能力层补技能，项目层提供事实。

但三层知识都会过时。

知识层	过时表现	后果
规则层	规则互相矛盾——"必须写 JSDoc"早被放弃了，但规则文件里还写着	agent 每次都照做已废弃的规则
能力层	Skill 和新需求冲突——旧的代码风格 Skill 跟当前项目规范打架	agent 行为不一致
项目层	文档腐烂——README 写着旧方案，项目早换了新做法	agent 基于错误信息做决策

加法决定喂什么，减法决定什么时候清。不清的后果不是"浪费空间"，是 agent 基于错误信息做决策。

团队知识债

一个人的 prompt 是习惯。一个团队的 prompt 是系统。

规则债

• 规则常常只增不减。
• 之前加的规则，和最近加的规则，可能早就在打架。
• Agent 不会抱怨规则矛盾，它只会随便挑一个执行。结果看运气。

审计

• 把规则文件和 Skills 当代码一样管理，做review，走PR。
• 定期开会过一遍规则。"这条还用吗？" 没用的就删。
• 知识和技术一样，有债务。借的时候爽，还的时候要命。不审计，等于默许 Agent 在你看不见的地方，按一堆你都忘了的规则干活。

本节小结

• 上下文流动：三条路径，三个注入时机。规则层在会话开始就占位；能力层在任务触发时追加；项目层在 Agent 读取文件时按需进入。知识的"保鲜期"和"占用成本"此消彼长。
• 风险：知识注入过多会挤占推理空间（attention dilution），过少会导致 Agent 基于通用知识臆造不符合项目实际的答案。过时的文档比没有文档更危险——Agent 不会质疑你的 README。
• 可审计性：Agent 做出一个决策时，你应该能追溯：这是基于哪条规则、哪个 Skill 的指导，还是读了哪个文件。知识来源不可追溯 = 黑箱。

下一节看编排模式——知识喂养解决"喂什么"，编排模式解决"怎么让多个步骤高效协作"。