做了两年的Agent相关研究和落地，从论文刷到工业界各种框架，最直观的感受是：大家聊Agent的方式已经变了。一年前提到Agent，更多是在聊接口链——“调一次模型、跑一步工具、把结果返回”；现在聊Agent，话题变成了目标管理、记忆分层、技能沉淀、沙箱权限、多Agent协作——我们开始把一个有状态、会反思、能积累经验的主体放进系统里设计了。这种“从工具到伙伴”的范式跃迁，恰恰是Agent论文和工业界实战中分歧最大、也最值得梳理的地方。
这篇文章是这个系列的第一篇，我把读论文时沉淀下来的架构理解、做项目时踩过的坑、以及框架选型的真实心路整理在一起。写出来不是要告诉你什么标准答案，而是把“伙伴型Agent比工具型Agent到底多做了什么、工业界怎么把这些多出来的东西落地”这件事讲透。适合正在入门Agent开发、或者已经在用LangChain、Dify、CrewAI但又觉得“跑得通却不好用”的朋友。
1. 范式跃迁的内涵：Agent从“执行工具”到“协作伙伴”到底变在哪
1.1 工具型Agent：用户拆问题，模型当函数
先定义一下我所说的“工具型Agent”。传统API调用、RAG问答、工作流引擎，本质都是“无状态函数”：用户把目标拆成明确步骤，每一步喂给模型或代码，模型返回结果。比如“把这段英文翻译成中文”，它老老实实翻译，不多做一件事；再比如最常见的RAG系统，用户问一句话，系统检索文档、拼上下文、让LLM作答，全程没有“目标感”，也不存在“下一步该做什么”的决策。
这种模式的优点非常实在：确定性强、调试简单、成本可控。你很清楚每一步在干什么，出了问题定位也快。但它有个致命短板——一旦任务稍微开放一点，比如“帮我把这个GitHub仓库跑起来，顺便总结项目的技术亮点”，用户不仅要清楚自己要什么，还必须清楚怎么做。这恰恰违反直觉：很多时候用户之所以把任务交给Agent，正是因为不想自己去拆解。
工具型Agent适合的永远是“流程已知、边界明确”的场景，比如客服问答、格式转换、数据报表。如果你只是想把LLM接进现有管道，工具型反而省事。问题在于，过去一年大量失败的Agent项目，都是“拿着工具型的架构，硬扛伙伴型的任务”，自然处处碰壁。
1.2 伙伴型Agent：目标导向、记忆与自我纠错
伙伴型Agent的转变不是“多调用几个工具”，而是整个交互范式变了。它有几个核心特征，我一个个说。
第一是目标导向，而非指令导向。用户只给意图，Agent自己拆解子任务。比如“帮我写一份关于Agent安全性的调研报告”，它不会等你告诉它“先搜资料、再列大纲、再写初稿”，而是自己在内部规划出步骤，按序执行，中途发现某个环节走不通还会换方案。
第二是有上下文与记忆。这里的记忆不是单轮对话的history，而是跨会话、跨任务的状态。它记得你上次讨论了什么、你的写作风格偏好、你之前否定过的方案方向。论文里Generative Agents用“观察—反思—计划”模拟了这种记忆演化过程，工业界则落地为向量库、偏好配置、会话摘要的组合。
第三是自我反思与修正。执行失败不是直接抛错，而是分析失败原因、调整策略、重试。Reflexion这篇论文的思路很直接：让Agent在每次尝试后写一段“经验总结”，把失败教训存下来，下一轮直接参考。这个机制在代码类任务里尤其有效，很多Agent“调不好bug”不是模型能力不够，而是根本没人让它停下来反思。
第四是技能沉淀。突出表现在：一次成功的多步操作应固化成可复用的skill，而不是下次重新走一遍试探过程。这一个点我会在第4节专门展开。
伙伴型Agent解决的，是“任务边界模糊、需要试错和调优、要求连续性上下文”的场景。但必须泼一盆冷水：它不是银弹。凡是流程固定、结果可预测的任务，引入自主规划往往是灾难——成本翻倍、出错率升高、用户还看不懂它在干嘛。范式跃迁意味着更多可能性，也意味着更贵的代价，你要学会挑场景。
1.3 跃迁的本质：从“输入输出映射”到“目标、过程与资产”
我自己的体会是，工具到伙伴的跃迁，本质有三层变化。
第一层从“输入输出”变成“目标管理”。工具型关注“这条输入映射到哪个输出”，伙伴型关注“这个目标要分解成哪些子任务，按什么顺序做，哪些可以并行，哪些必须串行”。这需要系统里有一个显式的规划器，而不是依赖模型每次现想。
第二层从“单次执行”变成“过程管理”。伙伴型Agent会多次尝试、中途暂停、根据反馈调整。工业落地意味着：任务状态要可持久化、步骤要可回放、失败要可恢复。这个要求被很多人忽略，逻辑上却让Agent从“函数调用”变成了“工作流状态机”。
第三层从“调用工具”变成“积累资产”。每完成一次任务，系统应当留下可复用的东西——可能是对话记忆、技能包、评测数据集，也可能是业务知识的沉淀。工具时代，这些资产散落在日志里；伙伴时代，它们是Agent能力成长的基础。我认为不理解这层变化，就谈不上真正的Agent工程化。
2. Agent核心架构拆解：多出来的那些“器官”怎么设计
2.1 五层架构总览：从模型内核到执行环境
从工程实现角度看，我习惯把伙伴型Agent分为五层。和我聊过的许多团队结构接近，用来做系统设计时的对照框架非常顺手。
| 层级 | 职责 | 关键问题 | 典型实现 |
|---|---|---|---|
| 模型内核 | 推理、生成、决策 | 选什么模型、温度等参数怎么设 | GPT-4o、Claude、Qwen等 |
| 规划器 | 拆解目标、编排步骤 | 顺序执行还是动态规划 | ReAct、Plan-and-Solve、图状态机 |
| 记忆系统 | 存储与召回上下文、经验、偏好 | 写入什么、遗忘什么、怎么召回 | 向量库、KV存储、摘要压缩 |
| 工具集 | 访问外部世界 | 工具如何描述、如何注册、如何选择 | Function Calling、MCP、Skill |
| 执行环境 | 运行Agent代码、隔离副作用 | 权限边界、资源限制、可回滚性 | Docker沙箱、VM、CLI白名单 |
五个层次不是所有项目都要完整建设，但架构评审时一定要明确：你的Agent属于哪几层，缺了哪层最痛。99%的MVP直接在模型内核上叠工具集就够了，但一旦承担连续多步任务，规划和记忆的缺失立刻成为瓶颈；再做深一点，没有执行环境的安全隔离，你根本不敢给它太高的工具权限。
2.2 记忆系统的分层设计与写入/召回策略
记忆是伙伴型Agent和工具型最直观的区别。论文里有个分层法很经典：短期记忆（当前任务上下文）、长期记忆（跨会话的事实、用户偏好）、程序性记忆（怎么做某件事的流程和技能）、情景记忆（过去的具体案例和反思）。工业界落地不需要照搬这四个名字，但要对应到存储方案。
我推荐一套务实的做法：短期记忆保持为上下文窗口，通过“关键信息定期摘要化”防止膨胀；长期记忆分两类，一类是结构化事实，比如用户偏好、任务状态，放PostgreSQL或Redis，一类是语义信息，比如历史案例、反思记录，放向量库里按需召回；程序性记忆对应Skill注册表和代码库。
比存储更重要的是写入和召回策略。记忆不是越多越好，无脑写入只会让召回变脏。我常用的三个原则：高置信度事实才写入长期记忆，普通对话信息只留摘要；写入前做语义去重，同一事实的新表述要覆盖旧表述，而不是追加；召回时设阈值，低于阈值的宁可不用，也不能硬塞给模型干扰判断。
实操中还经常遇到一个问题：Agent记不住关键事实，或者记住了错误的东西。前者多半是召回策略太紧，后者多半是写入太宽松。治法是给记忆条目加置信度字段和来源标签，召回时优先高置信度来源，这比调prompt管用得多。
2.3 规划与反思机制：把“下一步做什么”从玄学变成工程
纯靠模型“临场发挥”决定下一步，在开放任务里会非常飘。工业级系统一定要在提示词之上再搭一层显式的规划控制。论文里值得借鉴的几种机制，我逐个说一下工程上的落地要点。
ReAct是目前最普及的范式：Reasoning与Acting交替进行，模型想一步、走一步、观察结果、再想下一步。它的优点是灵活，缺点是步数一多容易偏航。工程上要通过“最大步数限制”和“关键节点校验”来兜底。
Plan-and-Solve思路是先输出完整计划，再逐步执行。适合任务目标明确、子任务线性依赖的场合。落地时要把计划保存成结构化JSON，而不是纯文本，这样才能做局部更新——比如执行到第三步发现第二步结果不对，只需替换计划中的后续步骤，而不是重来。
Reflexion则在执行后增加一个反思环节，把失败原因和修正策略写入记忆。我最推荐的工程姿势：把反思作为可选步骤，只有当执行结果低于阈值时才触发，避免每次成功也白烧一轮token。
这几种机制完全可以组合。我的经验是：Plan-and-Solve搭骨架，ReAct处理异常分支，Reflexion做事后复盘，三者结合比单用任何一种都稳。但要警惕规划本身的开销——写一大篇计划却只执行三步，既浪费token又让延迟变高，嵌套层数和并行度都要有上限。
3. 工业界框架与编排选型：LangChain、Dify、CrewAI到底怎么选
3.1 主流框架对比：它们都在解决什么问题
工业界这波框架热，本质上都在解决同一个问题：把上述五层架构的样板代码抽象掉，让你别从零写提示词拼接和工具调用循环。但不同框架的抽象层级和切入角度差异很大，选错等于穿错鞋。
| 框架 | 核心抽象 | 适合场景 | 主要痛点 |
|---|---|---|---|
| LangChain / LangGraph | 链、图状态机 | 需要精细控制流程、追求灵活性 | 学习曲线陡峭，抽象层次多 |
| AutoGen | 多Agent对话 | 研究原型、多角色辩论式协作 | 生产级可观测性弱 |
| CrewAI | 角色与任务 | 模拟团队协作、角色分工明确 | 复杂流程编排能力偏弱 |
| Dify | 可视化工作流 | 业务交付快、非技术人员可参与 | 自定义能力受限 |
| Semantic Kernel | 插件与规划器 | 微软技术栈深度集成 | 社区生态相对封闭 |
| Hermes Agent这类轻量运行时 | 工作台+知识库集成 | 个人知识管理、本地Agent | 生态尚早期 |
以LangGraph为例，它的图状态机设计最接近工业级需要：节点可以被打断、恢复、并行，状态可以被持久化，这对长任务特别重要。但代价是——你写一个简单Agent也得想清楚节点的输入输出schema，新手上手特别容易懵。Dify恰好相反，拖拽式工作流五分钟就能跑通一个RAG问答Agent，可等你需要自定义一个策略——比如根据上下文动态选工具——就会撞上平台限制。
我的建议很朴素：先想清楚你的核心诉求是“快速交付”还是“深度定制”。如果是前者，Dify这类低代码平台是正解；如果是后者，LangGraph或自研更现实。最怕的就是用低代码平台做到一半发现能力不够，又换框架重写，白打工。
3.2 Harness与Sandbox：给Agent套上缰绳和隔离舱
这里要专门讲一个常被忽视的概念：Harness。Harness和Agent的区别，通俗点说——Agent是那个“会思考的飞行员”，Harness是整座“驾驶舱”。Agent负责推理和决策，Harness负责把决策变成安全可控的执行：路由输入输出、注册和鉴权工具、管理生命周期、注入沙箱、限制资源。
为什么工业界越来越强调Harness？因为当你把Agent当作伙伴时，必须给它权力，又必须防它犯错。一个能删文件、发邮件、调支付的Agent，如果没有Harness兜底，等于让一个很有主见的人直接操作生产环境。常见的Harness能力包括：工具调用的权限白名单、执行超时的强制终止、敏感操作的二次确认、可回滚的操作快照。
Sandbox是Harness的物理隔离层。代码类Agent的沙箱最成熟，Docker容器、microVM都是现成方案；语言模型工具调用场景则常用“读操作直接放行，写操作进沙箱目录”。如果Agent要执行网络请求，还要设域名白名单和流量限制。我见过不少团队把Agent包进容器就没再管，结果Agent在容器里还是能访问宿主敏感路径——沙箱配置必须显式做路径映射和权限降级，不能靠默认值。
3.3 我的框架选型建议：什么时候上框架，什么时候自研
我做了几次选型后发现，判断“用框架还是自研”其实有两条很硬的标准。
第一条：你的核心逻辑是否落在框架的“非标准路径”上。如果Agent只有“顺序执行几步工具调用”，任何框架都够用，直接选最顺手、社区最活跃的；如果需要动态规划、并行分支、按状态机的条件迁移，就最好选LangGraph这类显式状态管理的；如果需要深度的权限控制和性能调优——比如每步之间要做敏感词过滤、动态改路由——恐怕就得考虑自研Harness壳，只在里面套现成的编排逻辑。
第二条：你的团队对框架底层的掌控力如何。框架最大的隐性成本不是性能，是“黑盒问题”：框架自己升级了，你的Agent行为莫名变了；某个内部节点报错，你都不知道从哪查起。所以选框架时，我强烈建议优先选有良好可观测性的，能导出详细的trace，能在关键节点注入自定义钩子。这个需求比“支持多少模型供应商”重要得多。
如果你决定自研，从零写一个Harness并不难：最小闭环就是“一个消息总线+一组工具注册表+一个状态存储+一个循环调度器”。难的是做好权限、恢复和可观测。我的建议是：第一版自研Harness就做两件事——把所有外部副作用收敛为统一接口，所有步骤落库并支持回放。能做到这两点，后续扩展就是水到渠成的事。
4. Agent Skills：把一次性过程变成可复用的能力资产
4.1 Tool、Skill、Workflow的区别到底在哪
这三个词被混用得厉害，但它们其实在讲不同层次的东西。Tool是单一能力入口，一个函数调用，比如“读取网页内容”是Tool。Skill是围绕一个目标组织起来的能力包，里面可能包含多个Tool、内部默认参数、多步流程、边界处理和错误恢复逻辑，比如“把网页转成结构化Markdown知识卡片”就是一个Skill。Workflow则是更上层的业务编排，可能串联多个Skill，依赖特定业务状态。
拿真实场景类比：Tool是螺丝刀，Skill是“换轮胎的操作规程”，Workflow是“整车检修流程”。螺丝刀解决一个动作，操作规程解决一类问题，检修流程解决一个完整业务。很多人的Agent其实只配了一套Tool，却在提示词里假装它拥有Skill，结果自然是不稳定——模型根本没拿到怎么“用工具解决复杂任务”的结构化信息。
业界最近对Agent Skills的强调，核心就是把“结构化地描述一类问题的解法”这件事做成标准化资产。Anthropic的Agent Skills方案里，一个Skill就是一个带SKILL.md的文件夹，Markdown描述适用场景和操作步骤，可以附带脚本和测试用例。这种“思路文档+参考脚本+可验证测试”的组合，本质上就是在给Agent沉淀程序性记忆。
4.2 从零构建一个Skill的完整步骤
我以一个内部常用的“网页转知识卡片”Skill为例，拆一下构建流程。第一步明确边界：输入是一个URL，输出是一份固定格式的Markdown卡片，包含标题、核心观点、关键数据和原文链接。第二步写指导文档，也就是SKILL.md，告诉模型什么时候该用这个Skill、处理步骤是什么、遇到反爬怎么办、输出格式样例是什么。
第三步准备脚本和参考代码：把网络请求、HTML解析、正文提取逻辑写成脚本，Agent可以直接调用。脚本要能容错——比如网页是JS渲染的，就提示Agent改用Playwright方案。第四步写测试用例：准备三五篇典型网页，有长文、有列表页、有需要登录拦截的页，跑一遍看输出是否符合格式要求，并把测试结果作为Skill质量基线。
第四步最容易被人跳过，但恰恰最重要。Skill的核心优势之一是可测试。你给Agent配了一个Skill，如果连这个Skill的输入输出边界都不清楚，那它就是个碰运气的黑盒。我用固定样例跑回归，每次升级底层模型或改脚本逻辑时，都能快速发现行为退化。
4.3 Skill的工程化：注册表、测试与版本管理
单机构建Skill不难，难在团队协作时把Skill管起来。我建议做三件基础设施：注册表、测试基线、版本管理。
注册表是一个索引文件，记录每个Skill的名称、描述、适用场景、依赖脚本、版本号。Agent在规划阶段会先用描述做语义匹配，所以描述质量直接影响命中率。描述要写“这个Skill做什么、不做什么、什么时候用、什么时候别用”，而不是一句套话。
测试基线是每个Skill目录下的一组样例和期望输出。每次Agent框架升级、底层模型升级或Skill脚本改动后，都跑一遍基线，比较输出差异。这样可以尽早发现“模型变聪明了反而绕过了Skill”或“脚本接口变了但文档没更新”这类问题。
版本管理听起来重，其实用Git管理Skill目录就够了。每个Skill一个文件夹，内部带CHANGELOG，记录变更原因和影响范围。团队里新同学入坑，翻一遍Skill的CHANGELOG就能了解系统演进，比看代码快得多。把一个“好使的过程”变成“好维护的资产”，这一步是必须的。
5. 实战记录：一个网页转知识卡片任务从拆解到评测
5.1 任务拆解与方案设计
拿一个我实际做过的场景展示完整落地过程：用户输入一个URL，Agent需要抓取网页内容、清洗正文、提取核心观点、按固定格式生成知识卡片，并写入本地知识库。这个任务表面简单，但几个地方极容易翻车：网页结构千奇百怪、正文提取需要启发式规则、生成的卡片要符合格式约束、入库前要判断重复。
方案选型上，没有直接上LangGraph这种重型框架，而是用一个轻量Harness加“规划-执行-反思”循环：一个主Agent负责理解URL类型和选择Skill，具体抓取转换交给“网页转卡片”Skill，入库交给向量化脚本。主流程只有两步，但有一个明确的Reflexion节点——当正文提取出来的文本量远低于预期或解析失败时，Agent会记录原因，并换备选的抓取方案重试。
这种设计的好处是：主流程可控，异常分支灵活。如果直接把所有步骤全交给模型自由发挥，经常出现抓取成功但提取了一堆导航栏文本的情况；如果全部固定死又没法应对特殊网页结构。所以我坚持“Skill解决80%的常规情况，反思节点解决20%的意外情况”。
5.2 核心代码与配置实现
围绕这个场景，最关键的一段逻辑是Agent主循环与Skill注册。精简掉业务细节后，核心结构是这样：
class AgentRuntime: def __init__(self, skills, memory_store): self.skills = skills self.memory = memory_store def run(self, goal: str, max_steps: int = 8) -> str: context = self.memory.recall(goal) for step in range(max_steps): plan = self.plan(goal, context) if plan["action"] == "finished": return plan["result"] result, error = self.execute(plan, context) if error: lesson = self.reflect(goal, plan, error) self.memory.record(lesson) context += lesson return "max_steps exceeded"底层是“规划、执行、反思”三个动作的循环。这里有个细节：execute内部要先查Skill注册表，看有没有匹配的Skill，有就加载Skill指导文档和脚本，没有才退回通用工具调用。我把Skill匹配逻辑放在执行层而不是规划层，因为模型规划时给出的工具名往往不够准确，执行层做语义匹配更稳。
Skill目录的SKILL.md开头大概长这样：
--- name: web-to-card description: 将网页内容转换为结构化Markdown知识卡片。适用于文章、博客、新闻页。 trigger: 用户输入URL并要求总结、存档、生成知识卡片 when_not_to_use: 网页需要登录、内容是视频/图片为主时不要使用 --- 步骤： 1. 用HARVEST_FROM_URL工具获取HTML源码，优先获取正文容器 2. 调用text_extractor.py清洗导航/广告/脚本标签 3. 按卡片schema生成Markdown，包含: title, summary, key_points, references 4. 调用embed_and_store写入向量库，返回卡片ID这段Markdown的价值在于：它把“什么时候用”“怎么用”“用的时候注意什么”一次性打包给了Agent，模型不需要自己把“网页转卡片”拆成tool调用序列。我实测下来，同档任务的成功率比纯工具提示词版本高出约两成。
5.3 评测集构建与质量看板
任务能跑通只是开始，真正决定Agent能不能进生产的，是评测体系。我针对网页转卡片这个场景，建了一个20条的评测集：10条常规博客、5条长文、3条含代码块的页面、2条异常页面（反爬、JS渲染）。每条都手工写好“期望输出要点”，比如标题是否正确、关键观点是否提取完整、格式是否合法。
评估方式不是简单的字符串匹配，而是“要点命中率”：把期望输出拆成若干事实点，人工或LLM作为裁判去核对Agent输出命中了几条。同时记录三个工程指标：平均步数、平均token成本、工具调用失败率。四类指标放一个看板里，任何一次升级都对照着看。
我强烈建议把评测集纳入CI，和代码一起跑。每次改动Skill或升级模型，自动跑一遍20条样例，输出覆盖率和成本变化。没有这套东西，你的Agent项目跑再欢也是裸奔——你根本不知道哪次升级偷偷让成功率掉了15个点。
6. 常见问题与避坑指南：把一路踩过的坑说清楚
6.1 Agent跑着跑着上下文就爆了
长任务最经典的问题，没有之一。多步执行过程中，每次工具返回都是大块文本，上下文窗口很快被塞满。症状不只是报错，更常见是Agent“失忆”：它忘了最初的目标，开始在细节里打转。
我的处理套路有三个优先级：第一，工具输出在上文注入前做截断和摘要，网页正文只保留与当前任务相关的部分；第二，会话历史用滚动窗口加摘要——超过阈值的消息压缩成“到目前为止已完成X、用户目标是Y”的核心摘要；第三，真正需要长期记忆的丢进向量库，按需取。理想状态是，窗口里永远只有当前步骤需要的上下文，历史状态全部外置。
6.2 Agent“记性差”和“乱记”怎么治
“记性差”和“乱记”其实是两个相反的病。记性差的Agent，是召回策略太保守，向量检索阈值设得过高，或者根本没有把关键事实写入长期记忆。乱记的Agent，是写入策略太粗暴，把猜测当成事实存了进去，后续任务被这些脏数据带偏。
治记性差：把阈值下调，并且在写入时同步保存“来源URL”和“置信度”。治乱记：对写入内容做一道校验——凡是涉及具体数字、用户偏好、事实性断言的，要么有来源，要么标记为“推测”。这两条配合起来，记忆系统才真正可信。再补一句：定期清理和合并过期记忆很重要，不然长期运行后向量库会堆满互相矛盾的旧结论。
6.3 工具调用不稳定，时好时坏
同一套提示词，同样输入，Agent有时正确调用工具，有时编一个不存在的参数，这是大家都会撞的问题。根源往往不是模型“笨”，而是工具文档描述有歧义、参数schema过于复杂、或者模型把工具参数当成了自由文本。
我的做法是给每个工具写“说明书”级别的描述：明确参数类型、必填项、取值范围、典型示例、错误含义。工具返回的报错信息也要设计成Agent能读懂的——别说“Error 500”，要说“参数page_size超出最大允许值100”。再用一层强制校验：模型输出先过JSON Schema校验，不合格就自动纠错并重试一次，而不是直接抛给用户。这几板斧下来，工具调用成功率会肉眼可见地提升。
6.4 成本失控、死循环与安全边界问题
Agent在开放任务里，成本失控是必然的，不是偶然的。最狠的情况是反思环节写了几轮长文，token烧掉上千块，结果任务还没完成。我的三条硬约束：每个任务的全局预算上限，达到即停并输出已有结论；每次反思的摘要字数上限，反思不是写论文；外部工具调用的频控，尤其网络请求和数据库查询。
死循环的安全网则是最大步数限制和心跳机制。Agent必须定期报告“我还在做什么”，如果连续几步都在做重复动作，Harness能自动打断并引导换方向。安全边界方面，权限最小化是底线：默认只读，写操作必须明确授权；每步外部副作用可回滚；高危险动作强制二次确认。能把这三条落地，Agent再“皮”也不会造成不可逆损失。
6.5 问题排查速查表
| 症状 | 最可能的原因 | 优先排查方向 |
|---|---|---|
| 上下文溢出 | 工具输出未截断、历史未压缩 | 检查日志中上下文大小变化，做摘要化 |
| 关键事实错误 | 长期记忆污染 | 查写入校验，清理低置信度条目 |
| 工具调用报错 | 参数格式不符合schema | 开启强制JSON校验与自动纠错 |
| 任务重复执行 | 规划器缺少已完成步骤标记 | 在状态中维护已完成集合 |
| 成本异常飙升 | 反思过多、工具调用冗余 | 设置全局预算与反思字数上限 |
| 敏感操作破坏 | 权限过宽 | 默认只读、危险操作走二次确认 |
这张表是我在项目里通用的第一排查顺序，每次线上出问题，先按表定位，再看模型提示词。大部分“诡异问题”追到最后，都是这六个原因之一。
写到这里，这篇“从工具到伙伴”的实战总结第一趴就差不多了。我自己的体会是：范式跃迁不是说工具型架构要被淘汰，而是你要在两种模式之间做清晰判断——固定流程用工具，开放任务用伙伴，成本边界和安全边界永远要提前划好。Action真正带来翻倍体验的反而是那些“小事”：给Skill写好边界说明、给记忆加上置信度、给每一步加预算上限。下一篇准备聊聊多Agent协作模式和评测集的进阶玩法，到时候可以把这些工程细节再往深处挖一挖。
