Agentic Engineering 概念（上）：Agent 的底层逻辑

Agentic Engineering 概念（上）：Agent 的底层逻辑 Agentic Engineering 概念（上）：Agent 的底层逻辑 Modified July 3 Map Reduce 并行模式 ：把一个大型任务拆成许多小任务，多个 Agent 同时处理这些小任务，然后另一个 Agent 合并结果。适合读密集型工作：代码审查、研究、文档分析、大规模内容审查。但最终质量取决于结果合并的好坏。 这些模式不是互斥的，实际工作流经常组合使用。规划者制定计划，路由器分发给专家，专家并行工作，然后另一个 Agent 合并结果。关键是交接。每次一个 Agent 把工作传给另一个 Agent，需要传递恰当的上下文量——不能太少，不能太多。 好的 Agent 设计主要在于清晰的边界。一个 Agent 的工作在哪里结束？下一个从哪里开始？哪些信息必须传递下去？这些边界往往决定了多 Agent 系统的成败。 配置层：Agent 的控制面板 5. Agent 配置文件 每个 Agent 从指令开始。在它回答、使用工具、触碰你的代码之前，背后通常有一个系统提示词。但默认的系统提示词不知道你的项目：不知道你的编码风格、包管理器、文件夹结构、团队规则。 所以如果你不给 Agent 项目特定的指令，它会猜。这就是问题的开始。 Agent 配置文件是一个项目级别的指令文件。Agent 在会话开始时加载它并保持在上下文中。它告诉 Agent：这个项目怎么工作、用什么工具、遵循什么模式、避免什么、哪些规则绝不能打破。 Claude Code 用 CLAUDE.md。其他工具用 AGENTS.md。名字不同，思想一样。 有用的配置文件不需要长。通常越短越好。包括：包管理器、测试命令、lint 命令、重要文件夹约定、函数长度限制、命名规则、安全规则（如"绝不提交密钥"）、行为规则（如"编辑前先读取文件"）。 一个常见的错误：往配置文件里塞太多东西。复制长段的 AI 生成规则文档、添加通用建议、写"写干净的代码""用最佳实践"——这些听起来有用，但通常帮助不大。模型已经知道通用建议，它需要的是具体的项目指导。 保持配置文件短、精、实用。控制在 100 行以内。删掉任何不能改善 Agent 工作的内容。别当作文档写，当代码对待。 6. 可复用工作流文件 配置文件始终是激活的。可复用工作流文件不同——它们只在 Agent 需要时才加载。可以理解为针对特定任务的小型指南。 比如：一个工作流文件解释怎么写测试，另一个解释怎么审查 PR，另一个解释怎么做数据库迁移。 这些文件通常用 Markdown 编写，顶部带 YAML frontmatter，包含名称、简短描述、何时使用、适用于哪些文件或文件夹。 Claude Code 有 skills（.claude/skills/），Cursor 有 rules。不同工具名字不同，但思想类似。 最关键的部分是 描述 。描述告诉 Agent 这个工作流何时有用。如果描述清晰，Agent 能在正确时间选择正确的工作流。如果描述模糊，Agent 可能忽略它或在错误的地方使用。 有个有趣的研究： SkillsBench 测试了 86 个任务，覆盖 11 个领域。使用人类编写 skill 的 Claude Haiku（便宜的模型）得分超过没有 skill 的 Claude Opus（更强的模型）。换句话说：便宜的模型 + 好的指令 强的模型 + 没有指令。 但当研究者允许模型自己写 skill 时，改进消失了。AI 生成的指令通常变成噪音——听起来有用，但不给模型明确的指导 所以：配置文件存始终成立的规则。工作流文件存特定任务的流程。实时提示词存当前请求独有的东西。 7. 工作流框架 没有清晰流程时，Agent 可能以随机方式工作。有时跳进代码太快，有时跳过测试，有时做了修改然后解释为什么正确（即使结果并不好）。 工作流框架给 Agent 一个可重复的工作方式。例如：引导 Agent 先规划任务、写或更新测试、实现变更、调试错误、审查最终结果。 不同工具做这件事的方式不同。有的用 skills ，有的用 hooks ，有的用 slash commands ，有的用可复用提示词。机制不同，目标一样：给 Agent 更好的工作方式。 Superpowers 提供一组精选的 skills，覆盖头脑风暴、TDD、调试、代码审查等常见工作流。 Get Shit Done 类似，但用 slash commands、hooks 和元提示词。 Compound Engineering 把工作分为规划 工作 审查 复合四个阶段，其中"复合"指系统从之前工作中捕获有用的模式和解决方案。 这些框架看起来不同，但核心思想一样：Agent 不应该直接开始写代码，它应该先理解在构建什么，然后遵循清晰流程，然后对照实际目标检查结果。 8. 提示词缓存 Agent 经常重复相同的信息。每一轮可能都包括系统提示词、项目配置文件、加载的工作流文件、工具指令、重要规则和上下文。 没有缓存，模型每轮都要重新读取相同的稳定前缀，意味着更多 token、更高成本、更长延迟。 提示词缓存存储稳定的提示词部分，模型不必每次都完全重新处理。第一轮发送完整的上下文，系统写入缓存。之后，后面的调用可以以更低成本复用。 简单说：第一轮贵，后面就便宜了。 但缓存有有效期（TTL）。如果会话暂停时间太长（比如你去喝咖啡），缓存可能过期。 提示词缓存让重复指令更便宜，但不修复糟糕的上下文。缓存让好的上下文更便宜，不会让弱的上下文变好。 9. 上下文漂移 上下文 随着上下文窗口变得拥挤，模型表现变弱。即使提示词缓存降低了成本，它没有移除 token——它们仍然在上下文里，模型仍然要穿过它们找到重要的东西。 文档短的时候，模型更容易找到细节。但随着上下文变得非常大，准确率开始下降。有用的信号被淹没在过多的文本里。配置文件、skills、记忆、工具结果也会遇到同样的问题。 如果你不断添加通用规则、长笔记、旧消息、未使用的指令，Agent 的注意力会被稀释。"更多上下文"并不总是更好。长上下文在信息有用时能帮上忙，但长而混乱的上下文会让 Agent 更差。 规则很简单：保持上下文精简。保持配置文件简短。保持工作流文件具体。删除任何不能帮助 Agent 做出更好决策的内容。每个 token 都应该值得它占用的位置。 上篇结束。 我们讲了 Agent 是什么、怎么思考、状态在哪、以及怎么配置它。下一篇 （中篇） 进入实战——Agent 能使用什么工具（MCP、实时文档、AI 搜索）、如何获得新能力（可视化输出、持久化记忆、知识搜索）、以及如何让多个 Agent 高效协作（子 Agent、编排、托管）。这些是 Agent 真正干活的部分。 后面继续拆 Claude Code / Agent 工程化实践。 Map Reduce 并行模式 ：把一个大型任务拆成许多小任务，多个 Agent 同时处理这些小任务，然后另一个 Agent 合并结果。适合读密集型工作：代码审查、研究、文档分析、大规模内容审查。但最终质量取决于结果合并的好坏。 这些模式不是互斥的，实际工作流经常组合使用。规划者制定计划，路由器分发给专家，专家并行工作，然后另一个 Agent 合并结果。关键是交接。每次一个 Agent 把工作传给另一个 Agent，需要传递恰当的上下文量——不能太少，不能太多。 好的 Agent 设计主要在于清晰的边界。一个 Agent 的工作在哪里结束？下一个从哪里开始？哪些信息必须传递下去？这些边界往往决定了多 Agent 系统的成败。 配置层：Agent 的控制面板 5. Agent 配置文件 每个 Agent 从指令开始。在它回答、使用工具、触碰你的代码之前，背后通常有一个系统提示词。但默认的系统提示词不知道你的项目：不知道你的编码风格、包管理器、文件夹结构、团队规则。 所以如果你不给 Agent 项目特定的指令，它会猜。这就是问题的开始。 Agent 配置文件是一个项目级别的指令文件。Agent 在会话开始时加载它并保持在上下文中。它告诉 Agent：这个项目怎么工作、用什么工具、遵循什么模式、避免什么、哪些规则绝不能打破。 Claude Code 用 CLAUDE.md。其他工具用 AGENTS.md。名字不同，思想一样。 有用的配置文件不需要长。通常越短越好。包括：包管理器、测试命令、lint 命令、重要文件夹约定、函数长度限制、命名规则、安全规则（如"绝不提交密钥"）、行为规则（如"编辑前先读取文件"）。 一个常见的错误：往配置文件里塞太多东西。复制长段的 AI 生成规则文档、添加通用建议、写"写干净的代码""用最佳实践"——这些听起来有用，但通常帮助不大。模型已经知道通用建议，它需要的是具体的项目指导。 保持配置文件短、精、实用。控制在 100 行以内。删掉任何不能改善 Agent 工作的内容。别当作文档写，当代码对待。 6. 可复用工作流文件 配置文件始终是激活的。可复用工作流文件不同——它们只在 Agent 需要时才加载。可以理解为针对特定任务的小型指南。 比如：一个工作流文件解释怎么写测试，另一个解释怎么审查 PR，另一个解释怎么做数据库迁移。 这些文件通常用 Markdown 编写，顶部带 YAML frontmatter，包含名称、简短描述、何时使用、适用于哪些文件或文件夹。 Claude Code 有 skills（.claude/skills/），Cursor 有 rules。不同工具名字不同，但思想类似。 最关键的部分是 描述 。描述告诉 Agent 这个工作流何时有用。如果描述清晰，Agent 能在正确时间选择正确的工作流。如果描述模糊，Agent 可能忽略它或在错误的地方使用。 有个有趣的研究： SkillsBench 测试了 86 个任务，覆盖 11 个领域。使用人类编写 skill 的 Claude Haiku（便宜的模型）得分超过没有 skill 的 Claude Opus（更强的模型）。换句话说：便宜的模型 + 好的指令 强的模型 + 没有指令。 但当研究者允许模型自己写 skill 时，改进消失了。AI 生成的指令通常变成噪音——听起来有用，但不给模型明确的指导 所以：配置文件存始终成立的规则。工作流文件存特定任务的流程。实时提示词存当前请求独有的东西。 7. 工作流框架 没有清晰流程时，Agent 可能以随机方式工作。有时跳进代码太快，有时跳过测试，有时做了修改然后解释为什么正确（即使结果并不好）。 工作流框架给 Agent 一个可重复的工作方式。例如：引导 Agent 先规划任务、写或更新测试、实现变更、调试错误、审查最终结果。 不同工具做这件事的方式不同。有的用 skills ，有的用 hooks ，有的用 slash commands ，有的用可复用提示词。机制不同，目标一样：给 Agent 更好的工作方式。 Superpowers 提供一组精选的 skills，覆盖头脑风暴、TDD、调试、代码审查等常见工作流。 Get Shit Done 类似，但用 slash commands、hooks 和元提示词。 Compound Engineering 把工作分为规划 工作 审查 复合四个阶段，其中"复合"指系统从之前工作中捕获有用的模式和解决方案。 这些框架看起来不同，但核心思想一样：Agent 不应该直接开始写代码，它应该先理解在构建什么，然后遵循清晰流程，然后对照实际目标检查结果。 8. 提示词缓存 Agent 经常重复相同的信息。每一轮可能都包括系统提示词、项目配置文件、加载的工作流文件、工具指令、重要规则和上下文。 没有缓存，模型每轮都要重新读取相同的稳定前缀，意味着更多 token、更高成本、更长延迟。 提示词缓存存储稳定的提示词部分，模型不必每次都完全重新处理。第一轮发送完整的上下文，系统写入缓存。之后，后面的调用可以以更低成本复用。 简单说：第一轮贵，后面就便宜了。 但缓存有有效期（TTL）。如果会话暂停时间太长（比如你去喝咖啡），缓存可能过期。 提示词缓存让重复指令更便宜，但不修复糟糕的上下文。缓存让好的上下文更便宜，不会让弱的上下文变好。 9. 上下文漂移 上下文 随着上下文窗口变得拥挤，模型表现变弱。即使提示词缓存降低了成本，它没有移除 token——它们仍然在上下文里，模型仍然要穿过它们找到重要的东西。 文档短的时候，模型更容易找到细节。但随着上下文变得非常大，准确率开始下降。有用的信号被淹没在过多的文本里。配置文件、skills、记忆、工具结果也会遇到同样的问题。 如果你不断添加通用规则、长笔记、旧消息、未使用的指令，Agent 的注意力会被稀释。"更多上下文"并不总是更好。长上下文在信息有用时能帮上忙，但长而混乱的上下文会让 Agent 更差。 规则很简单：保持上下文精简。保持配置文件简短。保持工作流文件具体。删除任何不能帮助 Agent 做出更好决策的内容。每个 token 都应该值得它占用的位置。 上篇结束。 我们讲了 Agent 是什么、怎么思考、状态在哪、以及怎么配置它。下一篇 （中篇） 进入实战——Agent 能使用什么工具（MCP、实时文档、AI 搜索）、如何获得新能力（可视化输出、持久化记忆、知识搜索）、以及如何让多个 Agent 高效协作（子 Agent、编排、托管）。这些是 Agent 真正干活的部分。 后面继续拆 Claude Code / Agent 工程化实践。 🔗 原文链接： https://x.com/vincemask/status/2072... https://x.com/vincemask/status/2072... 如果你现在正在学 Agent 开发，我知道那种迷茫感。每周都有新工具、新框架、新模型、新发布，过一段时间之后，你根本搞不清到底该学什么。学工具？学框架？等下一个更好的？ 这是今天 agentic engineering 面临的问题。这个领域发展极快，但核心思想的变化远没有工具快。读完之后，你会用简单的语言理解 agentic engineering 概念。下次你再读到 Agent 文章、看演示、或者看到 AI 新闻时，你能认识背后的原理。 Agent 的核心构建块 1. Agent Agent 这个词现在无处不在。每个新 AI 工具都想叫自己 Agent。但正因如此，它的含义变得模糊了。简单来说： AI Agent 通常是一个不只回答一次就停下来的 LLM。它在一个循环里运行。它能理解目标、决定下一步、使用工具、读取结果、然后再次决定下一步做什么。 普通聊天机器人：你提问 → 它回答。 Agent：你给目标 → 它思考下一步 → 使用工具 → 检查结果 → 继续直到任务完成。 Agent 不产生一个最终答案，而是产生一串动作序列。每个动作依赖之前发生的事情。编程是最清晰的例子之一：你可以让 Agent 调试一个失败的测试。它检查错误、打开相关文件、修改代码、重新运行测试、看到另一个错误、再修复、继续直到测试通过。 任务不是从一开始就完全可预测的时候，Agent 就很有用。比如"调试这个失败的测试""研究这个话题并总结最佳来源""检查这些工单并草拟回复"。 但你不必什么事都用 Agent。如果任务很简单，用普通提示词或小脚本更好。因为 Agent 不是免费的。每次循环都消耗时间，每次工具调用都花钱。 规则很简单：简单答案用普通提示词。固定步骤用脚本。需要灵活性、决策和每一步反馈的时候用 Agent。目标不是到处用 Agent，而是在它们的灵活性真正值那个成本的地方使用。 2. 执行模型 Agent 循环通常遵循一个简单模式。不是魔法，只是一个重复的三步循环： 模型先 思考 ：读取当前对话、查看目标、检查可用上下文、决定下一步该做什么。然后模型 行动 ：通常意味着调用一个工具。模型周围有一个"控制器"层，接收工具调用、检查是否有效、安全执行、返回结果。最后模型 观察 ：工具结果返回，成为对话的一部分。Agent 有了新信息，用更新后的上下文开始下一轮。 这就是循环：思考 → 行动 → 观察 → 再思考 这个模式有不同的名字。有人叫它 ReAct ，有人叫它 思考 行动 观察 ，有人简单叫它 agent loop 。名字不同，但思想一样。模型不会一次性预测完整路径，而是走一步、检查实际发生了什么、基于真实结果决定下一步。 普通 LLM 调用只能基于它当前已经知道的东西回答。但 Agent 可以在执行任务的过程中不断学习。 两种重要的变体： 并行工具调用 ——Agent 可能同时调用多个工具（比如一次读取三个文件），这能节省时间，但如果两个工具试图编辑同一个文件，可能产生冲突。 阻塞 vs 非阻塞执行 ——大多数 Agent 以阻塞方式工作（调用一个工具，等结果，继续）；但有些 Agent 可以在后台运行任务，同时做其他事（异步执行），这对大工作流很有用，但管理起来也更难。 3. Agent 状态 Agentic engineering 里， 状态 有两个含义。第一个是 工作流进度 （Agent 现在在哪、完成了哪一步）。第二个是 Agent 此刻知道什么 ，也就是 Agent 的状态。 上下文窗口 ——模型当前能看到的一切，包括你的最新消息、系统指令、之前的工具调用和结果。像 Agent 的当前工作记忆。但它有限制：模型一次只能容纳固定量的文本（token 限制）。会话结束，上下文通常就消失了。 上下文窗口之外的一切 ——模型看不到、除非去获取的东西：磁盘上的文件、数据库记录、已保存的记忆、API 结果、搜索结果、文档、项目历史。模型不会自动知道这些。它不能推理一个从未被打开过的文件。 所以 Agent 只对它当前可见的东西工作。其他所有东西必须在需要时拉进来。这是很重要的思想：Agent 可能可以访问很多工具和数据源，但能访问不等于知道。如果信息不在上下文中，模型就没有真正使用它。 对于大多数开发工作流， 文件是最好的默认选择 。容易读、容易编辑、容易用 Git 跟踪、容易通过 diff 比较，人和 Agent 都能自然使用。用 memory 保存跨会话的事实（用户偏好、项目规则）。用 database 处理需要结构化的状态（多用户、多 Agent、共享访问）。 但状态在多 Agent 场景下变得更难。如果两个 Agent 同时写入同一个文件，一个可能覆盖另一个的工作。这就是经典的竞态条件。所以隔离的工作空间很有用：对编码 Agent，Git worktrees 可以让每个 Agent 有自己的工作副本。 子 Agent 更容易管理——通常从新的上下文窗口开始，父 Agent 只给它该任务需要的信息。如果父 Agent 需要传递大量上下文给子 Agent，说明任务没有被正确拆分。 简单理解：上下文窗口是 Agent 当前能看到的东西。文件、记忆和数据库是信息可以在模型之外存活的地方。好的 Agent 设计主要就是在决定什么应该留在外面、什么应该进来、以及什么时候进来。 4. 常见 Agent 模式 一旦你开始使用多个 Agent，新问题出现了：这些 Agent 应该如何协作？ 规划者/执行者模式（Planner/Executor） ：一个 Agent 制定计划，另一个执行实际工作。规划思考任务，执行跟随计划行动。这种分离很有用，因为规划和执行需要不同类型的注意力。适合长期任务，你不想让 Agent 不经思考直接跳到代码里。 路由器/专家模式（Router/Specialist） ：一个 Agent 充当路由器，读取传入请求，决定哪个专家 Agent 应该处理。每个专家针对特定类型的工作设计（如安全审查员、调试专家、文档写手、测试写手、代码审查员）。这使系统更容易管理——每个专家有更窄的角色、更清晰的提示词、更小的工具集。行为更可预测，也更便宜（不是每个任务都需要最大的模型）。