夜雨聆风最近想学 AI Agent 的朋友，应该都跟我有同感：这领域实在太乱了。
每周一个新工具、一个新框架、一个新模型，每次发布都喊着“这次改变一切”。说实话，追了两个月我就放弃了——根本追不上。
后来我想明白了一件事：工具在变，但底层的核心思想其实没怎么变。
今天这个叫“技能”，明天那个叫“规则”，后天又冒出个“工作流”……名字五花八门，解决的都是同一个问题。只要你把背后的逻辑搞懂了，这周流行什么工具根本不重要。
所以我把 Agentic Engineering 里最核心的 30 个概念整理了一遍，用最通俗的大白话讲给你听。分三篇发，这是第一篇，我们先从“Agent 到底是什么”和“怎么配置它”说起。
现在是个 AI 工具都管自己叫 Agent，搞得这个词都快没意义了。
其实很简单：Agent 不是只回答一次就结束的聊天机器人，它会反复执行一个循环。
普通聊天机器人：你问 → 它答。
Agent 的工作方式：你给个目标 → 它思考下一步 → 调用工具 → 看结果 → 再决定下一步 → 一直干到完成为止。
它不是一次性输出答案，而是产出一连串的动作，每一步都依赖上一步的结果。
编程是最典型的例子。你让 Agent 去修一个失败的测试，它可能先看报错，再打开相关文件，改几行代码，重新跑测试，又看到新错误，再修……直到测试全过。
这种场景下 Agent 很有用，因为任务一开始就不是完全确定的。
比如：
“帮我调试这个失败的测试”
“调研这个主题，总结最佳资料”
“看看这些工单，帮我草拟回复”
“审查代码库，找出问题”
但不是说啥都得用 Agent。如果你只是要格式化个日期、转个 JSON、重命名文件、生成个简短回答，普通提示词或者写个小脚本就完事了。
Agent 不是免费的——每一次循环都花时间，每一次工具调用都花钱。循环越长，越难预测它下一步会干啥，调试也越麻烦。
所以原则很简单：
简单问题 → 普通提示词
固定步骤 → 写脚本
需要灵活决策、每一步都依赖反馈 → 用 Agent
Agent 的循环其实就三步，不神秘：
思考 → 行动 → 观察
先思考：模型看当前对话、目标、可用上下文，决定下一步做什么。
然后行动：调用工具。工具可以是读文件、跑命令、查数据库、调 API、用 MCP，或者问别的服务。
注意，模型不会自己直接执行，外面有一层“控制器”接收工具调用，检查是否合法，安全地执行，再把结果返回。
最后观察：工具的结果回来，变成对话的一部分，Agent 有了新信息，于是开始下一轮。
这个模式有人叫 ReAct，有人叫“思考-行动-观察”，也有人直接叫 Agent 循环。名字不同，本质一样。
这种做法的好处是：模型不用一次性猜对整条路径，它走一步看一步，根据真实结果再决定下一步。这就是 Agent 比普通提示词更强大的地方——它可以犯错，看到结果，然后在下一次尝试中纠正自己。
还有两个变体值得了解：
并行工具调用：有时候 Agent 一次性调用多个工具，比如同时读三个文件，而不是一个一个读。这在代码库分析或调研时省时间，但要注意——如果两个调用同时编辑同一个文件，可能起冲突。
阻塞 vs 非阻塞执行：大多数 Agent 是阻塞的——调用工具，等结果，再继续。但有些 Agent 可以在后台跑长任务，同时干别的事，这叫异步执行。处理大工作流很有用，但管理难度也更高。
“状态”这个词在 Agent 工程里有两种意思。一种是“任务进度”——做到哪一步了；另一种是“Agent 此刻知道什么”——这是我们重点说的。
Agent 的状态通常分两部分：
第一部分是上下文窗口——也就是模型当前能看到的所有东西。包括你的最新消息、系统指令、之前的工具调用和结果、以及任何被加入对话的信息。这就像 Agent 的“工作记忆”。
但它有容量限制，也就是令牌限制。而且在达到硬上限之前，上下文也可能变得混乱——太多旧信息会让 Agent 注意力分散。会话结束后，这个上下文通常就消失了。
第二部分是上下文窗口之外的东西——模型看不到，除非主动去取。比如：
磁盘上的文件
数据库记录
保存的记忆
API 返回结果
搜索引擎结果
文档
项目历史
模型不会自动知道这些。它没打开的文件就不能推理，没取回的数据库记录就不能用，没被拉回上下文的过往决策也记不住。
所以记住一句话：Agent 只跟它当前能看到的东西工作。其他的都得在需要的时候拉进来。
那状态应该存在哪？
对大多数开发者工作流来说，文件是最佳默认选择。容易读、容易改、容易用 Git 追踪、容易对比差异，人和 Agent 都能自然操作。
记忆（Memory） 用来存那些跨会话保留但不需要完整 Git 历史的东西，比如用户偏好、项目规则、重复指令。
数据库 适合需要结构化、多用户多 Agent 同时查询更新的信息。
状态在多 Agent 场景下会变得更棘手。两个 Agent 读同一个文件通常没事，但要是同时写同一个文件，就会出问题——经典的竞争条件。所以隔离的工作区很有用。
对于编码 Agent，Git worktree 是个好办法，每个 Agent 有自己独立的副本，各自工作，之后再合并。
子 Agent 稍微好管理一些，它通常带着全新的上下文窗口启动，父 Agent 只给它完成特定任务所需的信息。
判断任务拆分得好不好，有一个简单信号：如果父 Agent 需要传给子 Agent 一大堆上下文，那这个任务可能没拆对。好的子任务应该是聚焦的，不需要“整个世界”就能干活。
总结一下状态的核心思路：
上下文窗口 = Agent 当前能看到的
文件、记忆、数据库 = 信息可以存在模型之外的地方
好的 Agent 设计，本质就是决定什么留在外面、什么拉进来、什么时候拉
当你开始用多个 Agent 时，新的问题来了：它们怎么配合？
有三种经典模式，反复出现。
模式一：规划器 / 执行器
一个 Agent 负责规划，另一个负责执行。规划器思考任务拆解，执行器照着计划干活。
比如让你做一个功能，规划器先拆分：先改数据库 schema，再写 API，再更新前端，最后写测试。然后执行器一步步去实现。
这种模式适合长任务，你不想让 Agent 不经过思考就直接埋头写代码。
模式二：路由器 / 专家
一个 Agent 当路由器，读请求，然后决定交给哪个专家 Agent 处理。每个专家只做一类事。
比如：
安全审查专家
调试专家
文档撰写专家
测试编写专家
代码评审专家
这样系统更容易管理，每个专家角色窄、提示词清晰、工具集小，行为更可预测，而且不一定每个任务都用最强的模型，成本也更低。
模式三：Map-Reduce 并行
把一个大的任务拆成许多小任务，多个 Agent 同时处理这些小片段，最后另一个 Agent 合并结果。
比如审查一个很大的 PR，你可以按文件拆分：一个子 Agent 审文件 A，另一个审文件 B，第三个审文件 C……最后汇总 Agent 把所有人的意见合并成一份总结。
这种模式适合读密集型的任务：代码审查、调研、文档分析、大篇幅内容审核。
注意，实际工作中这些模式经常混着用。规划器拆任务，路由器分给不同专家，专家并行干活，再合并，最后送审。
关键在交接——每两个 Agent 之间传递信息时，上下文要刚刚好。太少，下一个 Agent 看不懂；太多，下一个 Agent 会混乱或者浪费上下文。
好的多 Agent 设计，本质上就是划清边界：一个 Agent 的工作在哪结束，下一个从哪开始？需要传递什么信息？
简单总结：
需要事前充分规划 → 规划器/执行器
不同任务需要不同专家 → 路由器/专家
大任务可拆成小块并行 → Map-Reduce
不管用哪种，交接越清晰，整个系统越可控。
配置层：Agent 的控制面板
每个 Agent 开始工作前都有一套系统提示词，告诉它怎么用工具、怎么格式化输出、怎么调用、怎么在特定环境里表现。
但默认的系统提示词不知道你的项目——不知道你的编码风格、包管理器、文件夹结构、团队规则。你不给它项目专属指令，它就靠猜。
于是麻烦来了：你可能用 pnpm，它却建议 npm；你的 Python 项目用 uv，它却让你 pip install；它可能写出防御性过强的啰嗦代码，只因为训练数据里这种模式很常见。
Agent 配置文件就是来解决这个问题的。它是一个项目级的指令文件，Agent 在会话启动时加载它，把它放在上下文中。
你可以把它当成项目的“规则手册”，告诉 Agent：
项目怎么运行
用哪些工具
遵循什么模式
避免什么
哪些规则绝对不能打破
Claude Code 用 CLAUDE.md，很多其他工具用 AGENTS.md，名字不同，本质一样。
配置文件不需要长，短一点通常更好。可以包含：
项目用的包管理器
测试命令
格式化命令
重要文件夹约定
函数长度限制
命名规范
安全规则（比如“永远不提交密钥”）
行为规则（比如“修改文件前先读一遍”）
这些小小的指令能省掉大量糟糕输出。没有配置文件，Agent 就按“最可能”的方式猜；有了配置文件，它按你的规则来。
但有一个常见错误：往配置文件里塞太多东西。复制一份长长的 AI 生成的规则文档，加一堆泛泛的建议，比如“写整洁的代码”“用最佳实践”——听起来有用，其实帮不了多少，模型本来就知道这些通用道理。
它需要的是具体的项目指引。
所以保持配置文件短小精悍、务实管用。尽量控制在 100 行以内。删掉任何不能改善 Agent 工作质量的内容。别把它当普通文档，要像代码一样对待——变化时审查，Agent 反复犯错时改进，没用的规则及时删。
好的配置文件不是为了给 Agent 留下印象，而是为了减少它的猜测。它猜得越少，干得越好。
配置文件是始终生效的，而可复用工作流文件只在 Agent 需要的时候才加载。
你可以把它们看作针对特定任务的小型操作指南。
比如：
一个工作流文件专门讲怎么写测试
另一个讲怎么审查 PR
另一个讲怎么迁移数据库
还有一个讲怎么更新文档
Agent 不需要时时刻刻带着所有这些，它只需要在正确的时候拿到正确的那一份。
这些文件通常用 Markdown 写，顶部带一小段元数据（YAML frontmatter），包括名称、简短描述、什么情况下使用、适用于哪些文件或文件夹。
描述是最重要的部分——它告诉 Agent 什么时候该用这个工作流。描述清晰，Agent 就能在恰当的时机选对；描述模糊，Agent 可能无视它，也可能在错误场合乱用。
有些工作流还支持 glob 模式（文件匹配规则），比如只在 *.test.ts 或 docs/ 文件夹下生效，让指令更聚焦。
不过真正的价值不在文件格式，而在指令本身的质量。一份简短清晰的工作流，能让小模型表现更好，因为它给了模型一个更好的过程来遵循。
SkillsBench 的研究里有个很有意思的结论：研究者测试了 11 个领域 86 个任务，给模型配上人类写好的简短工作流，结果 Claude Haiku（较便宜模型）加上人工编写的技能，得分超过了没有这些技能的 Claude Opus（更强模型）。
翻译成人话就是：一个便宜的模型配上好指令，比一个强大但没有好指令的模型表现更好。
这说明过程很重要、指令很重要、好的工作流很重要。
但研究也发现，让模型自己写技能时，提升效果就消失了。这很合理——AI 自己生成的通用指令往往变成噪声，听着像那么回事，但给不出清晰的指引，只是往上下文里堆文字，反而可能拖累表现。
所以可复用工作流文件不应该是冗长的通用文档，而应该是短小、具体、基于真实工作的。
简单分层：
配置文件放“始终成立”的规则
工作流文件放“特定任务”的流程
实时提示词放当前请求的独特性
三者配合，Agent 需要猜测的地方就少了，输出质量自然更高。
如果你用 Agent 来写代码，工作流框架能帮上大忙。没有清晰流程的话，Agent 可能工作得很随意——有时候太快跳进代码，有时候跳过测试，有时候改了代码后还解释自己为什么对，即使结果并不好。
工作流框架给 Agent 提供了一套可重复的工作方式。不只是依赖模型从训练数据里记得什么，框架给它一个文档化的流程。
比如框架可以引导 Agent 完成：
规划任务
编写或更新测试
实现修改
调试错误
审查最终结果
这很重要，因为编码不只是“写代码”。好的编码有节奏：先理解问题，再计划改动，做最小可用的更新，测试，审查，需要时改进。工作流框架就是让 Agent 每次都遵循这样的流程。
不同工具实现方式不同——有的用技能，有的用钩子，有的用斜杠命令，有的用可复用提示词，有的全组合起来。机制不同，目标一样：给 Agent 更好的工作方法。
比如 Superpowers 提供了一套精选的技能，覆盖头脑风暴、测试驱动开发、调试、代码审查等常见编码工作流，还加了更严格的规则让 Agent 真正去执行流程，而不是跳过重要步骤。
Get Shit Done 类似，用斜杠命令、钩子和元提示来操作。
Compound Engineering 则把工作分成四个阶段：计划 → 工作 → 审查 → 沉淀。“沉淀”这个部分很关键——系统会从之前的工作中捕获有用的模式和解决方案，让后续任务越来越轻松。
这些框架外表看着不同，但核心思想一致：Agent 不应该上来就敲代码，先理解它在构建什么，再遵循清晰的流程，最后对照真实目标检查结果。
有了好的工作流框架，Agent 就从“快速猜手”变成了“更有章法的编码助手”。你仍然需要审查输出、了解改了什么、对最终代码负责，但有了好框架，Agent 的轨道更稳，结果通常也更好。
提示词缓存听起来技术感很强，其实道理很简单。
Agent 经常反复发送同样的信息：系统提示词、项目配置文件、加载的工作流文件、工具指令、重要规则……这些重复的部分叫“稳定前缀”。
没有缓存的话，模型每一轮都要重新读一遍同样的前缀，消耗更多令牌、更费钱、更慢。
提示词缓存解决了这个问题——把稳定部分存起来，模型不用每次重新处理。第一次调用发送完整上下文，系统把它写入缓存，后续调用就可以低成本复用。
简单说：第一次调用贵，后面几次就便宜了。而且响应速度也更快。
大多数 Agent 编码工具在后台自动处理，你可能看不到，但它影响很大——它改变了对长会话成本的认知。
以前一个大配置文件可能因为反复加载显得很贵，有了缓存，稳定指令的成本在首次调用后就小很多。
这不代表你可以写又长又乱的配置文件——烂上下文还是烂上下文。但意味着一个有用的配置文件或可复用工作流，实际成本比看上去低。
需要注意缓存过期。缓存不会永远存活，通常有个时间限制（TTL，存活时间）。会话活跃时缓存保持“温热”，但如果你暂停太久——喝杯咖啡、看文档、被拉去开会半小时——回来缓存可能就过期了，下次调用得重新写入。
有些工具或服务商允许你选更长的 TTL，越长缓存越持久，但创建成本可能更高。根据自己的工作流选就行。
上下文腐烂指的是，随着上下文窗口越来越拥挤，模型的表现会下降。
提示词缓存能降成本，但去不掉那些令牌——它们仍然在上下文里，模型还得从一堆东西里找出真正重要的。即使是强模型也扛不住这种压力。
文档短的时候，模型找细节容易；上下文越长，准确率就开始下滑——有用的信号被太多周围文字淹没了。
配置文件、技能、记忆、工具结果都有同样的问题。如果你不断往里加通用规则、长笔记、旧消息、没用过的指令，Agent 就越来越不聚焦。
原因很简单：注意力是有限的。模型得把注意力分散到上下文里的每一条信息上，你加得越多，重要内容跟噪音的竞争就越激烈。
所以“更多上下文”不一定更好。长上下文在信息有用时是好事，但长而乱的上下文会让 Agent 表现更差。
原则是：保持上下文精简，配置文件简短，工作流文件具体，删掉任何不能帮 Agent 做出更好决策的内容。每一条令牌都应该凭本事留在那里。
配置层就聊到这里。下一篇我们来看看，Agent 开始工作后，它能伸手拿到哪些能力——工具、记忆、搜索、子 Agent，以及怎么让它们协同工作。
