夜雨聆风Agent 表现不好，不一定是模型不够聪明。它可能没有工具、不懂项目流程、忘了旧决定，或者压根没看到这次任务的关键资料。
先看一个很普通的 Issue：
用户登录成功后，偶尔会在 10 分钟内自动退出。 请定位原因、修复问题，并补上测试。把它交给 Coding Agent，可能出现四种结果：
- 它能分析原因，却不能搜索代码、修改文件或运行测试。
- 文件能改，命令也能跑，但它跳过了项目规定的验证步骤。
- 它不知道团队早已决定“Token 只保存在 HttpOnly Cookie”，又写回了
localStorage。 - 错误日志就在附件里，它却没读到，围着无关的登录页面转了半天。
四种失败看起来都可以归结为一句话：这个 Agent 不够聪明。
可真往下查，故障点完全不同。分别缺的是 Tool、Skill、Memory 和 Context。
四种故障不是同一个问题
这四个词经常被塞进“插件”“外挂”“能力扩展”这个大口袋。结果呢？工具越装越多，Agent 仍然会忘、会乱、会答非所问。
先把答案压缩成四句话：
- Tool：它能做什么。
- Skill：这类任务应该怎么做。
- Memory：过去有哪些信息以后还值得用。
- Context：这一次运行里，它眼前到底看到了什么。
短是短，但还不够。下面沿着这个登录故障继续拆。
● ● ●
Tool：给它一双手
Agent 读完 Issue，给出一段像模像样的判断：
可能是刷新 Token 失败，也可能是 Cookie 过期时间设置错误。建议检查鉴权中间件。
然后就停了。
为什么？它没有搜索仓库、打开日志、修改代码和执行测试的入口。它能讨论“应该怎么查”，却无法真正调查。
Tool 是 Agent 与外部环境交互的接口。文件搜索、终端命令、浏览器、数据库查询、Git 操作、测试运行器，都属于这一层。
如果把模型看成一个坐在工位上的人，Tool 就是电脑、终端、测试环境和门禁卡。没有这些东西，它可以讲清楚排查思路，却碰不到真实代码，更拿不到环境反馈。
Tool 让 Agent 与外部环境交互
问题来了：工具是不是越多越好？
不是。
Anthropic 在工具设计文章里专门提醒，功能重叠或用途模糊的工具会让 Agent 更难选择。工具说明和参数本身会进入 Context，工具结果通常也会回来。一次仓库搜索吐出五百个文件，不只是慢，还会把本轮真正重要的信息淹没。
工具的价值不在数量，而在边界清楚、返回结果有用。
对这个登录问题，够用的工具可能只有：
- 搜索并读取仓库文件；
- 查看 Issue 附件和错误日志；
- 修改代码；
- 运行相关单测和集成测试；
- 查看 Git diff。
给它二十个功能相似的搜索工具，未必比一个定义清楚的 search_code 更可靠。工具箱塞满了，找扳手反而更慢。这事儿很像家里的抽屉。
● ● ●
Skill：工具齐了，不代表会干活
现在 Agent 能读文件、改代码、跑命令了。任务开始有进展。
新的问题也来了。
它第一次改完只跑单测；第二次直接执行全部测试，等了四十分钟；第三次没读项目里的 AGENTS.md，顺手升级了一个不该动的依赖。每个动作都会，整套工作却不稳定。
缺的是 Skill。
本文把 Skill 理解成一份可复用的“作业说明”：遇到某类任务时按什么顺序推进、先读哪些文件、使用哪些脚本、哪些动作必须确认、交付前跑什么检查。
它不是一只手，而是手艺。
Tool 与 Skill 的区别
一个面向 Bug 修复的 Skill，可能写着：
- 先复现问题，不要看到报错就直接改；
- 优先运行与改动相关的最小测试集；
- 修复后补回归测试；
- 不随意新增依赖；
- 检查
git diff，确认没有无关修改； - 涉及认证、权限和生产配置时停下来让人确认。
这些规则组合起来，才让一次成功做法变成可重复流程。
我以前容易把 Skill 想成“更长的提示词”。这个说法只对了一半。提示词当然可能是其中一部分，但成熟 Skill 还可以带脚本、模板、参考资料、测试命令和验证清单。更重要的是，它通常按任务加载，不必把所有说明永远塞进全局规则。
不过，Skill 不会凭空创造权限。
Skill 写着“运行集成测试”，如果 Agent 没有终端 Tool，仍然只能给出建议。反过来也一样：它拥有删除数据库、部署生产环境的 Tool，却没有确认规则，风险会更大。
Tool 回答“能不能做”，Skill 回答“怎样稳定地做”。这两个最容易混。
● ● ●
Memory：不是保存所有聊天
登录问题修到一半，Agent 建议：
可以把访问 Token 保存到 localStorage，页面刷新时再读取。
这段代码也许能跑，却违反了团队已经确认的安全约束：Token 只能通过 HttpOnly Cookie 管理。
这个决定并不是当前 Issue 临时写下的。它来自三个月前的架构评审，后续任务还会反复用到。
这就轮到 Memory 了。
Memory 保存的是跨任务仍可能有价值的信息：项目约束、用户偏好、历史决定、已验证经验，以及尚未解决的风险。它跨越单次对话或单次运行。
但“保存”这个动作太容易制造错觉。
资料躺在知识库里，不等于 Agent 已经记住；Agent 记过，不等于这次一定会取出来。
Memory 的保存、检索与过期
一条 Memory 真正发挥作用，至少要经过三步：
- 被保存到某个可持续的位置；
- 在合适的任务里被检索出来；
- 进入当前 Context，让模型本轮能看见。
少一步都不行。
社区里有人讨论 Agent Memory 时提到几个很实在的坑：记录太长、条目重复、内容过期、检索结果含糊。它们迟早会变成 Context 污染。假如旧架构写着“Token 存在 localStorage”，新决定写着“只用 HttpOnly Cookie”，两条同时被取回，Agent 面对的不是更多知识，而是两条互相打架的规则。
所以我更愿意把 Memory 看成一个需要维护的资料库，而不是模型脑内的永久记忆。
什么值得放进去？
- “认证 Token 只能使用 HttpOnly Cookie”值得。
- “这个仓库统一使用
pnpm test”可能值得。 - “刚才为了定位故障临时加了一行日志”通常不值得。
- API Key、密码、Access Token 更不该扔进普通 Memory。
这层最难的不是存，而是删、改和判断时效。写到这里我才发现，Memory 更像档案管理员，不像大脑。
● ● ●
Context：存在，不代表这次看得到
接下来是最容易和 Memory 搞混的一层。
假设架构决定、仓库规范和历史 Issue 都已经保存在项目里。你启动一个新任务，只说：“修复自动退出问题。”
Agent 需要从当前 Issue、项目规则、代码、日志和测试结果里拼出这次工作的全貌。此刻真正进入模型推理范围的内容，才是 Context。
Anthropic 给出的定义很直接：Context 是模型在一次推理时实际包含的 token 集合。它可能包括系统规则、用户消息、工具定义、已加载 Skill、检索资料、历史对话和工具结果。
Context 是当前运行的工作台
可以把它想成桌面。
Memory 是资料柜。Skill 是操作手册。Tool 是桌上的电脑和仪器。Context 则是这次干活时真正摊在桌面上的东西。
仓库里有一千个文件，Agent 没读，模型此刻就看不到；一次性把整个仓库塞进来，重要的 Cookie 过期日志被压在中间，也不代表效果会更好。
Context 不是越长越好，而是越相关越好。
2025 年，Anthropic 在 Context engineering 文章里提出一个很实用的目标：使用尽可能少的高信号 token，最大化得到目标行为的概率。对于长任务，与其开场就塞入全部资料，不如保留文件路径、链接或查询，在需要时通过 Tool 即时加载。
这个判断也解释了两类常见翻车：
- “架构文档明明写过。”——写过，但本轮没有检索或读取。
- “错误日志就在附件里。”——文件存在，但没有进入当前 Context。
我现在看 Coding Agent 的长任务，会特别留意工具返回值。一个命令吐出上万行日志，模型后面的判断就可能被噪声拖着走。更好的做法往往不是增加 Context，而是让工具先过滤：只返回失败测试、相关时间段和关键堆栈。
这里也得收一点：单凭一次错误输出，不能证明一定是 Context 挤压造成的，工具实现和模型判断都可能出问题。但诊断顺序仍然成立——先确认当前 Context 里究竟有什么，再怪模型。
● ● ●
四层其实在一条线上
现在把四层重新拼起来。
你说：“修复登录后偶发退出的问题。”
- 当前 Issue、验收条件和关键日志进入 Context。
- 系统识别 Bug 修复任务，加载对应 Skill。
- Skill 指示读取仓库规范与架构决定，相关 Memory 被取回并进入 Context。
- Agent 按 Skill 调用代码搜索、文件编辑和测试 Tool。
- Tool 返回代码、测试失败和 diff，再进入 Context。
- Agent 根据新的 Context 继续判断，直到测试通过或停在人工确认点。
四层在一次任务中的流动关系
你会发现，四者并不是四个并排的盒子。它们是流动的：
Tool 提供动作，Skill 组织动作，Memory 跨任务保存信息，Context 承载这一次真正参与判断的内容。
其中 Context 像一个窄门。Skill 再完善、Memory 再丰富、Tool 再强，都要通过这个门影响模型当前的决定。
这也是为什么有时“加能力”反而变差：增加十个 Tool，会带来十组定义；保存一堆 Memory，会增加检索噪声；Skill 写成两万字，可能把真正关键的五条规则淹没。
扯远了，回到怎么用。
● ● ●
出问题时，先查哪一层？
下面这个表，我建议直接留着：
搭建一条新工作流时，我会按另一个顺序：
- 先定义本次必须进入 Context 的目标、资料和约束；
- 再给最少且边界清晰的 Tool；
- 把反复成功的做法整理成 Skill；
- 等流程跑稳后，只保存跨任务仍有价值的 Memory，并定期清理。
为什么不先建一个巨大的 Memory 库？因为你还不知道什么信息会被反复用到。为什么不先装五十个 Tool？因为你连第一个稳定任务都没跑通。
从一个具体任务开始，缺什么补什么。
这套顺序不酷，甚至有点慢。但它比“先搭一个万能 Agent 平台”更容易得到可验证的结果。
● ● ●
写在最后
我现在判断一个 Agent 问题，会先问四句话：
- 它有手吗？
- 它学过这门手艺吗？
- 它保存了该保存的旧事吗？
- 这些东西，这一刻真的摆在它眼前吗？
对应的就是 Tool、Skill、Memory、Context。
下次 Agent 表现离谱，先别急着换模型。也别立刻再装一个插件。
看看故障到底在哪一层。很多时候，模型只是坐在一张资料混乱、工具不明、操作手册没翻开的桌子前。
主要参考
- Anthropic：《Building effective agents》
- Anthropic：《Effective context engineering for AI agents》
- Anthropic：《Writing effective tools for agents》
- OpenAI Developers：Skills、Memories、Conversation state 与 Compaction 文档入口