理解 Context、Memory、Skills 与 Agents

今天只要开始使用 Coding Agent，几分钟内就会遇到一整套术语：Context、Memory、Agent Files、Skills、Tools，当然还有 Agents 本身。除此之外，还有 AGENTS.md、CLAUDE.md、Custom Instructions、SKILL.md 这类产品特定的名称。

第一眼看上去，它们似乎只是同一件事的不同叫法：

模型以某种方式“知道”的信息。

对于刚开始使用来说，这种理解或许已经够用了。但一旦我们想弄清楚为什么 Agent 会考虑某些信息、另一些信息却已经不可用，为什么它对规则的遵守程度会不同，或者为什么它突然在某个任务上采用了特定 Workflow，这种说法就太模糊了。

更有用的问题其实是：

Coding Agent 到底从哪里获得“该知道什么、该怎么工作”的信息？

一个简单的比喻可以帮助我们理解很多东西。不要把 Agent 想象成人造人，而是把它想象成一个带书桌的工作环境。Model 本身已经带着一些知识和能力。书桌上放着当前任务可用的信息。旁边还有档案、这个工作环境的规则、针对特定工作类型的 Playbooks，以及真正可以执行动作的 Tools。

简化后可以这样理解：

Model
=
已经具备的知识与能力

Context
=
当前放在书桌上的内容

Memory
=
档案或笔记本，
其中的信息之后可以再次
被拿回书桌

Agent Files
=
这个工作环境的规则

Skills
=
针对特定任务类型的
Playbooks 或工作说明

Tools
=
系统用来执行动作的工具

Agent
=
围绕一个任务展开工作，
并组合这些机制的系统

这个比喻描述的是系统中的角色。它并不是说 LLM 像人脑一样工作，也不是说 Agent 就是拥有类似人类记忆的数字员工。

这一点很重要，因为很多误解都来自于把技术机制过于直接地类比成人类认知。

为什么 Context 不是短期记忆

Context 经常被描述成 LLM 的短期记忆或工作记忆。作为非常粗略的日常比喻，这种说法不难理解：信息在有限的处理范围内可用，并影响接下来发生什么。

但从技术上看，这个比喻很快就会产生误导。人类的工作记忆是一种动态的生物状态。内容需要主动维持，会逐渐消退，而且受到许多认知过程影响。

LLM 的 Context 不同。它是某次模型处理过程中被明确提供给模型的信息。只要某条信息仍然包含在当前 Context 中，模型原则上就可以考虑它。但这并不意味着模型会同样可靠地找到、权衡和使用 Context 里的每一部分内容。

所以“书桌”是一个更好的比喻。某份文档可以一直躺在书桌上，但人仍然可能没有注意到其中最关键的那一行。书桌越大，也并不意味着越好；如果桌面被海量材料堆满，真正重要的信息反而可能更难突出。

能放到书桌上，和能够被可靠地使用，是两件不同的事。

Model 本身已经带来了什么

在我们往书桌上摆放任何材料之前，Model 已经存在了。它的 Model Weights 来自 Training 和 Post-Training，并决定了模型原本已经具备哪些能力、已经学到了哪些模式。

在我们的工作环境比喻里，可以把这近似理解成教育、经验和已经内化的知识。但这依然只是对角色的类比。模型不会像人一样“记得自己受过教育”，也没有人类意义上的职业经验。

真正重要的技术区分是：当我们通过 Context 提供额外信息，或者使用 Memory 系统时，通常并不会修改 Model Weights。模型并没有因此重新接受 Training。

如果一个 Coding Agent 记住了某个 Repository 使用 pnpm 而不是 npm，并不意味着 Base Model 突然永久学会了这件事。更可能的情况是，外围系统把这条信息保存了下来，并在之后需要时再次提供。

Context —— 当前书桌上有什么

简化来说，Context 指的是当前处理步骤中可供模型使用的信息。

它当然可以包括用户当前可见的请求。但在真实 Agent 系统中，用户输入往往只是全部 Context 的一小部分。System Instructions、Conversation History、Repository Files、Search Results、Tool Descriptions、Test Results、Compiler Errors、API Responses、加载的 Agent Files、启用的 Skills，以及检索得到的 Memories，都可能进入当前 Context。

一个正在调查失败测试的 Coding Agent，可能同时面对这些信息：

任务描述
+
相关 Repository Files
+
架构规则
+
测试代码
+
上一次失败测试的输出
+
之前的修改
+
当前工作指令

模型并不需要在 Training 时见过这些内容。如果我们把一个新 Library 的文档，或者内部 Repository 的某段代码提供给它，它就可以在当前处理步骤中使用这些信息。

因此，我们可以得到一个很实用的简写：

Context 就是当前放在书桌上的内容。

这其实比很多 Agent 产品界面表现出来的要简单。Agent 打开一个文件，并不意味着这份文件自动变成了 Model Weights 中的新知识。Search Result 也是一样。它们首先只是让额外信息在某一次模型调用里变得可用。

Context Window —— 书桌有多大？

在这个系列的第二篇文章里，我们已经把 Context Window 介绍成一种技术容量上限。简化来说，它描述了单次模型处理里可以同时纳入多少材料。Token Budget 在输入、系统内部 Context 和输出之间如何分配，则取决于具体 Model 和 Product。

在我们的比喻里，这就是书桌的大小。

更大的书桌显然有价值。Agent 可以同时保留更多代码、更多 Conversation History 或更多文档，在必须删除、总结或重新加载内容之前拥有更大的工作空间。

但书桌大并不代表工作环境就准备得更好。一个摆满一万页无序材料的巨大书桌，可能技术上包含所有需要的信息。一个更小的书桌，如果上面恰好只有相关 API 文档、受影响模块、架构规则和当前测试错误，反而可能更适合具体任务。

因此，在真实 Agent 系统里，最好把几个问题分开：技术上能放入多少 Context？其中哪些内容真正相关？系统实际选择了哪些信息，并在什么时候提供？最后，模型对这些被选中的内容到底能多可靠地使用？

大的 Context Window 主要只回答第一个问题。

Context Engineering —— 什么应该放到书桌上？

这就回到了如今越来越常见的一个术语：Context Engineering。

它并不是把尽可能多的材料塞进尽可能大的 Prompt。对于大型 Codebase，更重要的工作往往是筛选真正相关的信息，合理组织，并在需要的时候提供。Anthropic 对此描述的做法是把传统 Retrieval 与 “just in time” 方式结合起来：额外信息只在工作过程中，通过文件、搜索或 Tools 再被加载进来。 [8]

对于一次具体修改来说，有价值的 Context 可能只是受影响模块、当前 Tests、一个 API Contract、少量架构规则，以及失败 Build 的输出。整个 Monorepo、过去五年的全部 ADR、所有曾经写过的 Coding Convention，虽然信息更多，却不自动意味着更好的 Context。

Context Engineering 决定什么应该放到书桌上。

如何系统化地做这件事，本身就是另一个主题。对于这里的 Mental Model，我们只需要记住一点：Context 不是静态知识库。Agent 系统会在工作过程中持续构建它。

Memory —— 工作区旁边的档案

有了前面的区分，我们可以更准确地理解 Memory。

如果一个 Agent 系统需要把信息保留到单个步骤或单次 Session 之外，那么这些信息必须被存储在某个地方。可能是文件、数据库、搜索索引，也可能是其他 Persistency Mechanism。之后，系统可以重新找到相关信息，并把它再次提供给当前任务。

简化来说：

Memory
↓
Retrieval
↓
Context
↓
Model

所以，Memory 与其说像模型的人类长期记忆，不如说更像书桌旁的档案柜或笔记本。

里面可能记录用户偏好的输出方式、团队曾经否决过的某个技术方案、一个不寻常的 Build Step，或者某个长期任务上次中断的位置。

关键在于方向。信息如果只是存在档案里，模型并不会自动使用它。Agent 系统必须先找到它，再以合适的方式把它拿回书桌。

Context 是当前可用的工作材料。Memory 是被保存下来、之后可以再次变成 Context 的信息。

不过，不同产品对这些词的使用并不完全统一。比如 Claude Code 明确把 CLAUDE.md 和 Auto Memory 称为两个互补的 Memory 系统。同时，Anthropic 也说明它们最终都会作为 Context 被使用：CLAUDE.md 保存人维护的持久 Instructions，而 Auto Memory 保存 Agent 自己记录的 Learnings 与 Patterns。 [3]

所以，对于我们的 Mental Model，更有帮助的是按照角色来区分。我们把由人维护的 Repository 和 Project Rules 归入 Agent Files；而这里所说的 Memory，是跨步骤或 Session 被保存，并且之后能够重新提供的信息。

这只是为了理解而划分的类别，不是各家厂商必须遵守的自然法则。真正稳定的技术边界仍然是：保存这类信息通常不会修改 Model Weights。它是 Persistency 与后续复用，而不是自动发生的 Training。

Agent Files —— 我们在这里怎么工作？

到了 Agent Files，术语会变得更加产品化。

AGENTS.md 已经成为一个开放格式，用来给 Coding Agents 提供 Instructions。它可以近似理解成“给 Agent 看的 README”：一个可预测的位置，用来写 Build Commands、Tests、Conventions 和 Project-specific Context。目前已经有越来越多 Coding Agent 工具支持这个格式。 [1]

GitHub Copilot 则有自己的 Repository Instructions，例如 .github/copilot-instructions.md 和按路径生效的 NAME.instructions.md。在 Agent 场景里，GitHub 也支持嵌套的 AGENTS.md；Repository Root 还可以使用 CLAUDE.md 或 GEMINI.md。 [2]

Claude Code 原生使用的是 CLAUDE.md 和 .claude/rules/。它不会自动把 AGENTS.md 当作自己的原生格式读取，但当前文档明确建议：如果同一个 Repository 想让多个 Agent 系统共享规则，可以从 CLAUDE.md 中导入已有的 AGENTS.md。 [3]

因此，把 “Agent File” 当作某一个标准的正式名称并不合适。在这篇文章里，我把它当成一个上位概念：用文件向 Coding Agent 提供 Project-specific Rules 和 Working Context。

核心问题是：

我们在这个项目里是怎么工作的？

这样的文件可以包含 Architecture Rules、Naming Conventions、Dependency Boundaries、Test Strategy、Build Commands，或者其他 Project-specific Decisions。

例如，在一个 Angular 项目里，可以写成：

# Frontend Architecture

- Components 不负责 Business Logic 编排。
- Domain State 位于 `domain/+state`。
- HTTP Access 属于 `infrastructure`。
- 本地 State 使用 Signals。
- 新 Features 必须有 Unit Tests。

这些规则还没有告诉 Agent“如何实现一个 Feature”。它们主要是在告诉 Agent：这个 Repository 里的边界是什么。

另一个项目完全可以合理地使用 NgRx、采用不同的 HTTP 分层方式，或者定义不同的 Test Boundaries。这正是为什么一个好的 Agent File 不应该是一份“所有软件开发都必须遵守”的通用原则清单。

它描述的是：在这里，什么叫做好的工作。

Agent Files 不是万能 Best-Practice 套餐

从这里开始，我们第一次稍微超出纯粹的术语解释。

从一个成功项目里直接拿来一份大型 AGENTS.md、CLAUDE.md，或者一整套 Copilot Instructions，确实很诱人。别人已经投入过时间，而且其中很多规则第一眼看上去也很合理。

问题不在于参考好的想法。问题在于把 Project-specific Decisions 当成 Universal Best Practices。

一个 Repository 可能有意识地使用 Feature Slices，另一个则主要按技术 Layer 组织。一个团队可能以 Signals 为主要 State Model，另一个团队依赖 NgRx。在一个项目里，Integration Tests 是最关键的 Safety Boundary；在另一个项目里，Unit Tests 可能承担更大的责任。即使使用完全相同的 Framework，也不意味着 Architecture Rules 会自动相同。

非常精确地告诉 Agent 一条来自别的项目的规则，并不会自动让结果变好。它可能只是让 Agent 以非常高的一致性执行了错误规则。

Agent Files 不是通用 Best-Practice 套餐。它们必须描述当前项目真实的架构和工作方式。

Skills —— 这类任务应该怎么做？

Skill 回答的是另一类问题。

Agent File 描述的是“在这个环境里怎么工作”，而 Skill 通常描述的是针对某一类任务的 Playbook：

这类任务应该怎么完成？

它可以是 Code Review、系统化 Debugging、TDD、Migration、Architecture Review，或者某种反复出现的 Feature Structure 的工作流程。

在我们的工作环境比喻里，Skill 不是 House Rules，而是 Playbook。

目前已经开放规范化的 Agent Skills 格式，把这个机制表现得很直观。一个 Skill 是一个目录，至少包含一个 SKILL.md。其中有 name、description 之类的 Metadata，以及实际 Instructions。Skill 还可以包含 Scripts、Reference Material 和其他 Assets。这个格式最初由 Anthropic 开发，并在 2025 年末作为开放标准发布。 [4]

一个 Skill 可以近似写成这样：

Code Review

1. 确认相对基线的 Diff。
2. 检查功能需求。
3. 应用项目规则。
4. 查找架构违规。
5. 检查 Tests 与 Verification。
6. 按重要程度整理 Findings。

这与“HTTP Access 必须放进 infrastructure”这类 Project Rule 不同。Skill 描述的是流程。Agent File 提供的是这个流程中需要遵守的规则。

Skill 并不自动等于“已经学会的能力”

Skill 这个词本身容易让人产生误解。

对于人来说，我们通常把 Skill 理解为已经内化的能力。骑自行车、盲打，或者长期练习形成的 Debugging Method，并不会放在一个 Markdown 文件里，每次工作前再重新读取。

而在 Agent Skills 里，情况往往更接近另一种模式。Workflow 被保存成文件或结构化资源。当它变得相关时，Agent 系统可以加载这些 Instructions，并把它们作为额外 Context 提供给 Model。

SKILL.md
↓
加载
↓
Context
↓
Model

它叫 Skill，但从技术上看，很多时候更接近 Playbook，而不是已经内化的能力。

当然，Model 本身已经从 Training 中获得了一些能力。如果某种行为通过 Training 或 Fine-Tuning 被写入 Model Weights，那么它就更接近人类“内化技能”的比喻。

一个解释 TDD Workflow 的 SKILL.md 并不会修改 Model Weights。它只是为 Agent 系统提供了一个可以复用的 Playbook。

Agent File 与 Skill 是互补的

放到具体 Coding Task 里，这个区别会非常清楚。

假设任务是：

实现一个 Update Slice。

Agent File 可能规定：Domain State 位于 domain/+state，Components 不做 Business Orchestration，HTTP Access 必须经过 Infrastructure，新的修改需要 Unit Tests。

而一个 Project-specific Skill 则可能定义真正的工作步骤：

实现 Update Slice

1. 检查或创建 Command。
2. 分析现有 Read State。
3. 实现 Application Use Case。
4. 接入 Infrastructure。
5. 考虑 Invalidation。
6. 增加 Tests。
7. 执行 Verification。

这两个机制并不竞争。Skill 描述的是这类任务通常需要哪些步骤。Agent File 描述的是在当前项目里，这些步骤必须遵守哪些规则。

简化来说：

Agent File
=
我们在这里怎么工作？

Skill
=
这类任务应该怎么做？

或者继续使用工作环境比喻：

Agent File
=
House Rules

Skill
=
Playbook

不同产品在技术实现上并不一定完全按这条边界来划分。但作为 Mental Model，它很有用，因为它把两个不同责任拆开了。

Progressive Disclosure —— 只在需要时把 Playbook 拿到桌上

一旦拥有很多 Skills，马上就会出现 Context 问题。处理一个简单 Bugfix 时，并不需要同时加载 Release Management、Data Migration、UX Review、Incident Response，以及十种不同 Feature Type 的完整说明。

因此，开放的 Agent Skills 规范把 Progressive Disclosure 当作核心设计原则之一。兼容的 Client 可以先只暴露 Skill 的 Name 和 Description；当 Skill 被激活时，再把完整 SKILL.md 加入 Context；额外的 Scripts、References 或 Assets 则可以继续按需使用。具体如何实现 Discovery 和 Activation，仍由各自 Agent 系统决定。 [4]

在我们的比喻里，房间里有一个摆满 Playbooks 的书架。它们不会一直全部摊在书桌上。只有出现相关任务时，合适的 Playbook 才会被拿下来。

这样可以节省 Context，也减少无关 Instructions。同时它再次说明：Skill 并不一定是模型永久“知道”的东西。Agent 系统会组织哪些信息在什么时候进入当前工作区。

可复用，不代表通用

Skills 的确往往比 Agent Files 更容易复用。一个设计良好的 Systematic Debugging、Code Review 或 TDD Workflow，可以在很多项目里成立。

但这仍然不意味着它天然适用于所有项目。

Skill 越接近团队真实的 Architecture 或 Development Process，就越 Project-specific。比如 create-angular-crud-slice 必须知道当前项目对 Slice 的定义。add-domain-command 取决于这套 Codebase 里 Commands、State 和 Application Layer 是怎么组织的。一个 Legacy Migration Skill，甚至可能必须有意识地处理那些绝不应该复制到 Greenfield Project 的结构。

Skill 越接近 Architecture、Domain Rules 和真实开发流程，就越需要针对项目调整。

所以，正确的区分并不是“Agent Files 是本地的，Skills 是全局的”。它们承担的是不同职责。Agent Files 通常天然更偏向环境特定；Skills 描述可重复工作，但可以从高度通用一直到高度 Project-specific。

从这里开始就是 Engineering

Context 和 Memory 可以先比较中性地解释成技术机制：信息被提供、被保存，并在之后再次可用。

Agent Files 和 Skills 则要求团队真正做出决定。我们的 Architecture 到底是什么？哪些 Patterns 是有意保留的，哪些只是历史遗留？哪些 Commands 属于正常 Workflow？哪种修改需要哪些 Tests？在这个 Repository 里，“done” 到底意味着什么？

Skills 还会带来更多问题。这个团队认为好的 Code Review 是什么？哪些 Debugging Steps 被证明有效？Feature 应该怎样切分？哪些 Verification 绝对不能跳过？

一个连自己的工作方式都很难说明清楚的团队，也很难把它变成好的 Agent Files 和 Skills。

从这里开始，就进入了一部分 Engineering。这并不意味着必须先设计出完美的 Agent System 才能使用。更现实的方式是迭代：观察真实 Tasks，找到重复出现的问题，把规则显式化，缩小 Skill 范围，观察 Agent Behavior，再继续优化 Instructions。

Anthropic 也明确建议从 Agent Behavior 中可观察到的具体缺口以及有代表性的 Tasks 出发设计 Skills，并在真实场景中持续观察与调整。 [4]

Skill 不会因为它的 Markdown 写得很漂亮就自动变好。

一个好的 Skill，应该能够在真实任务中可靠地改善 Agent Behavior。

这个原则可以避免一种新的 Cargo Cult：不断收集复杂 Agent Configurations，却从来没有验证它们到底是否产生实际效果。

Matt Pocock 的 “Skills for Real Engineers” —— 灵感来源，而不是蓝图

Matt Pocock 的 Skills for Real Engineers Repository 是一个很好的例子，可以看看这类 Playbooks 可以怎样切分。里面包括 code-review、diagnosing-bugs、tdd、implement、Research 等 Engineering Skills。比如 implement Workflow 会建立在前面已经做出的 Decisions 上，在预先确定的 Seams 上使用 TDD，并在最后执行 Code Review。Debugging Skill 则定义了一个相对严格的循环：Reproduction、Minimization、Hypothesis、Instrumentation、Fix 和 Regression Test。 [5]

真正值得关注的并不是把这些文件原样复制进每个 Repository。更有价值的是它的结构：任务被切得相对清晰，工作方式被明确命名，更大的 Workflow 可以组合更小的 Skills，重复出现的 Engineering Practices 被显式表达出来。

因此，这个 Repository 更适合被当作设计自己 Skills 时的灵感来源。它可以帮助我们理解，哪些工作知识适合被表达成 Playbook；也能看到 Skill 并不只是单个 Prompt Trick，而可以描述完整的 Feedback Loop。

但它不会替团队做 Project-specific Decisions。什么是好的 Review、哪些 Test Boundaries 最重要、应该保护什么 Architecture、什么 Workflow 真正适合当前 Codebase，依然必须在项目内部做决定。

结构可以借鉴，内容仍然需要自己打磨。

Tools —— Agent 用什么来行动？

到目前为止，我们主要讨论了模型得到哪些信息和 Instructions。

Tools 改变的是另一维度：它们让系统能够从环境中获取信息，或者真正对环境执行动作。

Tool 可以读写 Files、搜索 Repository、执行 Shell Command、调用 git diff、启动 Tests、运行 Compiler、操作 Browser、查询 Database，或者访问外部 API。通过 MCP 暴露的 Functions 也可以属于这一类。

在书桌比喻里，Tools 就是工作区里的工具。

一个没有写权限的 Model 可以解释文件应该怎样修改。有了对应 Tool，Agent 就可以真正打开并修改文件。有 Test Runner，它可以观察修改后的效果。有 Git，它可以检查最终 Diff。

于是我们又能看到一个重要区分：

Skill
=
哪些步骤是合理的？

Tool
=
用什么执行某个步骤？

Code Review Skill 可以要求先分析 Diff。git diff 或 Repository Tool 让这一步真正可执行。

Debugging Skill 可以要求用可复现 Test 验证某个 Hypothesis。Shell 与 Test Runner 提供执行能力。

所以，Tools 不是 Skills，Skills 也不是 Tools。

Agent —— 围绕任务组织工作的系统

现在再回到 Agent 这个词，会更容易理解。

这里同样不存在一个唯一的通用定义。OpenAI 把 Agents 描述成可以代表用户以较高独立程度完成任务的系统，并使用 LLM 来驱动 Workflow、使用 Tools 获取信息和执行 Actions。Anthropic 使用更宽泛的 agentic systems 概念，但会区分预定义的 Workflows，以及由 Model 动态控制流程与 Tool Use 的 Agents。 [6][7]

边界并没有被标准化。

对于我们的 Mental Model，更重要的是共同点：Agent 并不是只接收一次 Prompt，然后返回一次 Text。它可以在多个 Steps 中持续查看任务状态、选择下一步 Action、接收环境返回的结果，再根据这些结果继续工作。

简化后：

Task
↓
Agent

Model
+ Context
+ Memory
+ Agent Files
+ Skills
+ Tools

↓
选择 Action
↓
执行
↓
观察结果
↓
选择下一步
↓
...

并不是每个 Agent 都一定拥有这些组件，也不是每个系统都以同样方式组织它们。有些系统没有持久 Memory，有些不支持 Skills，还有一些只允许很少、限制非常严格的 Tools。

相比单次 LLM Call，真正的差别并不是突然多了一个新的“思考组件”，而是多步骤 Workflow 被组织起来了。

Coding Agent 不只是一个 Model，而是处在工作环境里的 Model。

Coding Agent 实际上怎样组合这些东西

来看一个很普通的任务：

修复 Issue 381 里的 Bug，并补一个 Regression Test。

Coding Agent 可能先阅读 Issue，然后搜索 Repository。它打开可能相关的 Files，同时对应路径下的 Agent Instructions 也可能进入 Context。对于错误分析，还可以激活一个 Debugging Skill。

接着，Agent 运行已有 Test，或者先构造一个可复现的失败案例。Tool 返回 Error Message，这个结果又可以成为下一步的 Working Context。Model 根据更新后的状态，决定接下来应该查看或修改哪个 File。

修改之后，Test 再跑一次。可能这时出现了 TypeScript Error。这个新 Observation 又会进入下一个 Model Step。Agent 继续修正 Patch，执行更多 Verification，并在最后检查 Diff。

流程大致可以这样理解：

Issue
↓
分析 Repository
↓
加载相关 Files
↓
应用 Agent Files
↓
使用 Debugging Skill
↓
执行 Test
↓
观察 Failure
↓
修改 Code
↓
再次执行 Test
↓
检查 Diff

一个非常长的 Prompt 同样可以描述其中很多步骤。但 Agent System 还会负责真正组织 Actions、把结果送回流程、管理不断变化的 Context，并协调后续 Model Calls。上一篇文章讨论 Coding Benchmarks 时，我们已经看到：真正被评估的往往就是这样一个完整工作环境，而不是裸 Model。

最终，很多东西都会进入 Context

现在可以把前面的概念再次汇总起来。

Memory 可以存放在当前 Model Call 之外。Agent File 作为文件存在于 Repository。Skill 可以待在 Skill Directory 里，等需要时再激活。Tool 则是存在于 Model 外部的执行能力。

如果模型需要利用这些机制里的信息，相关内容或描述通常都必须以某种形式进入当前 Context。

Agent File ─┐
Skill ──────┤
Memory ─────┤
Repository ─┤
Tool Output ┤
            ↓
         Context
            ↓
          Model

这并不意味着它们在技术上是同一种东西。它们的生命周期、选择规则、持久性、优先级和执行语义都可能明显不同。比如 Tool 仍然是外部能力；只有 Tool Description 和 Tool Result 会成为 Model 可见的 Context。

但对于 Demystification，这里有一个非常关键的共同点：

Agentic AI 周围很多看起来不同的术语，并不是新的“智能类型”，而是在描述不同的信息、规则、工作流程和行动能力如何被提供给模型。

Memory System 决定保存什么、什么时候再取回来。Progressive Disclosure 影响哪个 Skill 在什么时候被完整加载。Agent Files 提供本地规则。Tools 返回来自工作环境的新 Observation，或者让系统可以真正修改环境。

Model 最终处理的，是每一步由这些机制共同构建出来的 Context。

一个紧凑的 Mental Model

机制	核心问题	书桌比喻
Model	系统本来已经会什么？	教育与经验
Context	现在有哪些信息可用？	书桌上的材料
Memory	什么可以保存并稍后再找到？	档案 / 笔记本
Agent File	我们在这里怎么工作？	House Rules
Skill	这类任务应该怎么做？	Playbook / 工作说明
Tool	我可以用什么行动或获取信息？	工具
Agent	这些东西如何组成多步骤 Workflow？	工作组织

和所有比喻一样，不要把它推得太远。Model 没有人类教育，Memory System 没有生物学意义上的长期记忆，Agent 也不是数字员工。

这张表只是区分角色，并不是在模拟人类认知。

大书桌也不会自动带来好工作

从外面看，现代 Coding Agent 很容易像一个完整的智能系统：我们给出任务，观察几步工作过程，最后得到一个 Patch。

但在表面之下，不同机制在共同工作。Model 带来 Training 中形成的能力。Context 提供当前步骤可用的信息。Memory 可以跨时间保存信息，并在之后重新提供。Agent Files 定义本地规则。Skills 描述可重复的 Workflows。Tools 让系统可以从环境中获取信息，或者对环境执行 Actions。Agent 则把它们组织成多步骤过程。

这种区分并不是纯粹的 Terminology Pedantry。它帮助我们判断问题到底发生在哪。是 Model 缺知识？相关信息根本没被加载进 Context？Memory 已经过时？Agent File 和真实 Architecture 冲突？Skill 切得不好？Tool 缺失，或者返回了糟糕的 Feedback？

只有把这些问题分开，“Agent 有时候会做一些奇怪的事”才会变成真正可以技术分析的问题。

尤其对于 Agent Files 和 Skills，有一个非常直接的实践结论：外部 Repository 可以提供很好的想法，但它不了解我们的 Codebase。它也不了解我们的 Architecture Decisions、Legacy Boundaries、Definition of Done，以及真实 Development Workflow。

对于 Agent Files 和 Skills，只复制别人的 Best Practices 不够。它们必须适合自己的 Codebase 和工作方式。

大的书桌、档案、House Rules、Playbooks 和 Tools，已经解释了 Coding Agent 工作环境中的很大一部分。

但还有一个重要特征没有讨论：即使我们给同一个 Agent 相同的 Context、相同的 Rules、相同的 Skills 和相同的 Tools，也不一定每次得到完全相同的 Solution。

底层 Model 是概率式工作的。为什么这会带来结果差异，以及这对 Software Engineering 意味着什么，就是下一篇文章的主题。

参考资料

[1] AGENTS.md: A simple, open format for guiding coding agents. 截至 2026 年 9 月的项目文档。将 AGENTS.md 描述为放置 Build Steps、Tests、Conventions 和其他 Project-specific Context 的可预测位置。

[2] GitHub: Adding repository custom instructions for GitHub Copilot. GitHub Docs，2026 年 9 月。记录 .github/copilot-instructions.md、按路径生效的 .instructions.md，以及 AGENTS.md、CLAUDE.md、GEMINI.md 作为 Agent Instructions 的用法。

[3] Anthropic: How Claude remembers your project. Claude Code Docs，2026 年 9 月。记录 CLAUDE.md、.claude/rules/、Auto Memory、它们如何作为 Context 被加载，以及如何导入现有 AGENTS.md Instructions。

[4] Agent Skills: Agent Skills Overview、Specification 与 How to add skills support to your agent. 开放 Agent Skills 标准，2026 年 9 月。该格式最初由 Anthropic 开发，定义了 SKILL.md、可选 Scripts、References、Assets，以及 Discovery、Activation、Execution 中的 Progressive Disclosure。

[5] Matt Pocock: Skills for Real Engineers. GitHub Repository，2026 年 9 月。包含 TDD、Debugging、Code Review、Implementation、Research、Domain Modeling 等 Engineering Skills。

[6] Erik Schluntz, Barry Zhang / Anthropic: Building effective agents. Anthropic，2024 年 12 月 19 日。区分预定义 Workflows 与由 LLM 动态控制流程和 Tool Use 的 Agents。

[7] OpenAI: A practical guide to building agents. 将 Agents 描述为可以代表用户以较高独立程度完成任务的系统，并使用 LLM 驱动 Workflow Execution 与 Tool Selection。

[8] Anthropic: Effective context engineering for AI agents. Anthropic Engineering，2025 年 9 月 29 日。讨论从纯 Pre-Inference Retrieval 转向 “just in time” 策略，即 Agents 在执行过程中动态加载所需 Context。