AI Agent 这个词在过去一年里被反复提及，但真正动手搭过一套能跑起来的 Agent 系统的人都知道，从"知道它是什么"到"让它稳定干活"之间隔着一整条工程化的鸿沟。我前后参与过几个 Agent 项目的落地，从最初用几十行代码拼一个能调用工具的循环，到后来处理记忆污染、工具调用失败、循环失控这些真实问题，踩过的坑比看过的论文多得多。这篇内容想做的事情很直接：把 AI Agent 从概念拆到工程实现，用七个核心要素讲清楚它由什么构成，再用七个决策点讲清楚搭建时每一步该怎么选、为什么这么选。不管你是刚接触 Agent 开发的新手，还是已经写过 Demo 但卡在稳定性上的开发者，都能从这里找到可以直接参考的思路和方案。关键词覆盖 AI Agent、LLM、工具调用、循环机制、Agent 架构、Agent 记忆、Agent 安全等核心方向，内容偏工程实践，不堆概念。
1. 先把 AI Agent 的边界划清楚：它和 LLM、Harness 到底什么关系
很多人第一次接触 Agent 的时候，脑子里其实是一团浆糊的：LLM 是模型，Agent 是应用，Harness 又是什么？这三个东西经常被混着说，导致后面设计架构的时候概念错位。我先把这层关系理清楚，因为这是后面所有决策的基础。
1.1 LLM 是大脑，但不是 Agent 本身
LLM（大语言模型）本质上是一个输入文本、输出文本的概率模型。你给它一段 prompt，它给你一段回复，仅此而已。它没有记忆、没有手脚、没有目标感，甚至不知道自己上一轮说了什么——除非你把历史对话重新塞给它。所以一个裸的 LLM 调用，哪怕模型再强，也只是一个"高级文本补全器"。
Agent 不一样。Agent 是一个系统，它把 LLM 当作推理核心，在外面套上一整套机制：让它能感知环境、能调用工具、能记住事情、能循环执行直到完成任务。换句话说，LLM 是发动机，Agent 是整辆车。发动机再好，没有变速箱、方向盘、油箱，车也跑不起来。
这个区分为什么重要？因为很多新手会误以为"换个更强的模型，Agent 就好了"。实测下来，模型能力提升确实有帮助，但 Agent 的稳定性瓶颈往往不在模型，而在工具调用的容错、循环的终止条件、记忆的管理这些工程环节上。我见过用中等模型跑得很稳的 Agent，也见过用顶级模型照样翻车的系统，差别就在工程实现。
1.2 Harness 是 Agent 的"测试跑道"
Harness 这个词在 Agent 语境里，指的是一套用于驱动、约束和评估 Agent 的外围框架。你可以把它理解成"测试跑道"或者"脚手架"：它负责给 Agent 喂输入、捕获输出、模拟工具环境、记录每一步的状态，方便你调试和评估。
Harness 和 Agent 的区别在于：Agent 是干活的，Harness 是观察和驱动干活的。举个例子，你要测试一个能查天气、能订机票的 Agent，Harness 会模拟出天气 API 和订票 API 的返回，然后按预设场景一步步驱动 Agent，看它在每个决策点做了什么选择。没有 Harness，你只能手动一遍遍试，效率极低，而且没法复现问题。
在实际项目里，我强烈建议在 Agent 开发早期就把 Harness 搭起来。哪怕只是一个简单的脚本，能记录每轮的输入、LLM 输出、工具调用参数和返回结果，都能帮你省下大量排查时间。后面讲循环机制和容错的时候，你会更深刻地体会到这一点。
1.3 一个常见的认知误区
有个很普遍的误解是：Agent 就是"LLM + 工具调用"。这话对了一半。工具调用确实是 Agent 的核心能力之一，但只有工具调用远远不够。一个真正的 Agent 还需要：目标分解能力（把大任务拆成小步骤）、状态管理能力（记住做到哪了）、错误恢复能力（工具失败了怎么办）、终止判断能力（什么时候算完成）。这些加在一起，才构成一个能自主运行的 Agent。
所以当你看到"AI Agent 搭建"这类话题时，不要只盯着工具调用那一块。工具调用是显性的、好理解的，但真正决定 Agent 能不能用的，是那些隐性的工程机制。
2. 解构 AI Agent 的七个核心要素
把 Agent 拆开来看，我习惯用七个要素来描述它的构成。这七个要素不是学术定义，而是从工程实现角度出发的拆解，每一个都对应着代码里实实在在的模块。理解这七个要素，你就知道一个 Agent 系统里到底有哪些零件，每个零件负责什么。
2.1 要素一：推理核心（LLM）
推理核心就是 LLM，负责所有的"思考"工作：理解用户意图、决定下一步做什么、生成工具调用参数、判断任务是否完成。它是整个 Agent 的决策中枢。
选型上要考虑几个维度：推理能力、上下文窗口、工具调用支持、延迟和成本。推理能力决定了 Agent 能不能处理复杂任务；上下文窗口决定了它能"看到"多少历史信息；工具调用支持（也就是 function calling 能力）决定了它能不能规范地输出结构化调用；延迟和成本则直接影响用户体验和运营开销。
我的经验是，不要一上来就追求最强模型。先用一个中等能力的模型把整个流程跑通，把工程问题暴露出来，等流程稳定了再考虑升级模型。因为很多问题根本不是模型能力不够，而是你的 prompt 设计、工具描述、循环逻辑有问题。换模型解决不了这些。
2.2 要素二：工具集（Tools）
工具是 Agent 的"手脚"，让它能跟外部世界交互。查数据库、调 API、读写文件、执行代码、搜索网页，这些都是工具。工具的定义通常包括：名称、描述、参数 schema、执行函数。
这里有个容易被忽视的点：工具的描述质量直接决定 Agent 用得对不对。LLM 是根据工具描述来决定调不调、怎么调的。如果你的描述含糊不清，比如写个"查询数据"，模型根本不知道查什么数据、参数怎么填。好的工具描述应该像写给新员工的说明书：这个工具干什么、什么时候用、每个参数什么含义、有什么限制。
工具的数量也要控制。我见过有人一口气给 Agent 挂了三四十个工具，结果模型选择困难，经常调错。实测下来，单次可选的工具控制在 10 个以内比较稳，超过的话建议做工具分组或者分层路由。
2.3 要素三：记忆系统（Memory）
记忆让 Agent 能记住事情。它分短期记忆和长期记忆。短期记忆就是当前对话的上下文，通常直接放在 prompt 里；长期记忆则是跨会话持久化的信息，需要存到外部存储（数据库、向量库等），用的时候再检索出来。
短期记忆的管理核心是"上下文窗口怎么用"。对话轮次多了，历史会撑爆窗口，这时候就需要做压缩、摘要或者滑动窗口。长期记忆的核心是"存什么、怎么取"。不是什么都要存，存太多检索出来的都是噪音；也不是随便取，检索策略不对会取到无关信息干扰推理。
记忆这块是 Agent 工程里最容易出问题的地方之一。后面讲决策点的时候我会专门展开。
2.4 要素四：规划模块（Planning）
规划模块负责把复杂任务拆解成可执行的步骤。简单任务可能不需要显式规划，LLM 直接一步步做就行；但复杂任务，比如"帮我调研一下某个行业的竞争格局并写份报告"，就需要先拆成"确定调研维度→搜集资料→整理分析→撰写报告"这样的步骤。
规划的实现方式有好几种：一种是让 LLM 一次性输出完整计划（plan-and-execute），一种是边做边规划（ReAct 风格），还有一种是分层规划（先定大方向再细化）。选哪种取决于任务的可预测性。任务流程固定就用前者，任务开放多变就用后者。
2.5 要素五：执行循环（Loop）
执行循环是 Agent 的"心跳"。它驱动着"思考→行动→观察→再思考"这个循环不断运转，直到任务完成或触发终止条件。这个循环看起来简单，但里面藏着大量工程细节：循环怎么终止、每轮怎么组织上下文、工具调用失败怎么处理、怎么防止死循环。
循环机制是 Agent 稳定性的关键。一个设计不好的循环，要么提前终止（任务没做完就停了），要么永不终止（陷入死循环烧钱），要么中间出错就整个崩掉。后面我会用一整个决策点来讲循环的设计。
2.6 要素六：状态管理（State）
状态管理负责记录 Agent 运行过程中的所有关键信息：当前任务是什么、做到哪一步了、已经调用了哪些工具、得到了什么结果、有没有出错。它是循环能够"接着上次继续"的基础，也是调试和恢复的依据。
状态管理做得好，Agent 就能支持中断恢复、支持多轮任务、支持并行子任务。做得不好，Agent 就是一次性的，中间断了就得从头来。在工程实现上，状态通常用一个结构化的对象来维护，每轮循环更新它。
2.7 要素七：安全与约束（Guardrails）
安全与约束是 Agent 的"刹车和护栏"。它确保 Agent 不会做出危险操作：不会调用不该调的工具、不会泄露敏感信息、不会执行破坏性命令、不会陷入无限循环烧光预算。
这一块在实际项目里经常被忽略，直到出事才想起来。我见过 Agent 因为工具描述不清，误删了数据库记录的案例。安全约束包括：工具调用的权限控制、输入输出的内容过滤、循环次数和 token 消耗的上限、危险操作的二次确认等。这些机制必须在设计阶段就考虑进去，而不是事后补。
3. 七个决策点：搭建 Agent 时每一步该怎么选
理解了七个要素，接下来是更实际的问题：真正动手搭的时候，每个环节面临哪些选择，怎么选才不踩坑。我把搭建过程归纳成七个决策点，每个决策点都对应一个关键的工程取舍。
3.1 决策点一：Agent 架构选哪种范式
第一个决策是架构范式。主流的几种包括：ReAct（推理与行动交替）、Plan-and-Execute（先规划后执行）、Reflection（带自我反思）、Multi-Agent（多智能体协作）。
ReAct 是最基础也最常用的，适合大多数中等复杂度的任务。它的逻辑是：每轮先推理当前该做什么，然后执行一个动作，观察结果，再进入下一轮。优点是灵活、实现简单；缺点是对于长任务容易迷失方向。
Plan-and-Execute 适合流程相对固定的复杂任务。先让 LLM 生成完整计划，再逐步执行。优点是全局视野好、执行效率高；缺点是计划一旦有偏差，后续全错，而且重新规划的成本高。
Reflection 是在前两者基础上加一层自我检查：做完一步后，让 Agent 评估自己做得对不对，不对就修正。这能显著提升质量，但会增加 token 消耗和延迟。
Multi-Agent 是把任务分给多个专职 Agent，各司其职。适合特别复杂的场景，但协调成本高，调试困难。
我的建议是：从 ReAct 起步，把基础流程跑通。如果发现任务太长容易跑偏，再引入规划；如果发现质量不稳定，再加反思；只有当单 Agent 确实扛不住时，才上多 Agent。不要一上来就搞最复杂的架构。
| 架构范式 | 适用场景 | 主要优势 | 主要代价 |
|---|---|---|---|
| ReAct | 中等复杂度、开放任务 | 灵活、易实现 | 长任务易迷失 |
| Plan-and-Execute | 流程固定的复杂任务 | 全局视野、高效 | 计划偏差代价高 |
| Reflection | 质量要求高的任务 | 输出质量高 | token 与延迟增加 |
| Multi-Agent | 超复杂、可分工任务 | 专业分工 | 协调与调试成本高 |
3.2 决策点二：工具怎么设计和分组
工具设计是 Agent 能不能用好的关键。前面提过，工具描述要像说明书，这里再补充几个实操要点。
第一，工具粒度要适中。太粗（一个工具干太多事）会导致参数复杂、模型难填；太细（一个工具只干一件小事）会导致工具数量爆炸、模型选择困难。经验法则是：一个工具对应一个明确的、原子性的操作。
第二，参数 schema 要严格。用 JSON Schema 明确定义每个参数的类型、是否必填、取值范围。这不仅是给模型看的，也是运行时校验的依据。我见过因为 schema 不严，模型传了个字符串给需要整数的参数，直接报错的案例。
第三，工具要分组。当工具超过 10 个时，按功能分组，让 Agent 先选组再选工具。或者用分层路由：一个轻量模型先判断该用哪类工具，再交给主模型处理。
第四，给工具加"使用示例"。在描述里放一两个调用示例，能显著提升模型用对的概率。这招实测非常有效。
3.3 决策点三：记忆策略怎么定
记忆策略的核心问题是：什么进短期记忆、什么进长期记忆、怎么检索。
短期记忆方面，我的做法是保留最近 N 轮完整对话，更早的做摘要压缩。N 的取值取决于任务类型，一般 5 到 10 轮。摘要压缩要保留关键信息（用户的核心诉求、已达成的结论、待办事项），丢掉寒暄和冗余。
长期记忆方面，要区分"事实型记忆"和"经验型记忆"。事实型记忆是用户偏好、历史信息这类，存结构化数据或向量库；经验型记忆是"上次这类任务怎么做的"，可以存成案例供检索。
检索策略上，纯向量检索容易召回语义相近但实际无关的内容。我的经验是混合检索：向量相似度 + 关键词匹配 + 时间衰减，综合排序。另外，检索出来的记忆不要全塞进 prompt，要控制数量，一般 top 3 到 5 条就够，多了反而干扰。
注意：记忆污染是 Agent 安全的一个真实威胁。如果长期记忆里被写入了错误或恶意的信息，后续所有依赖它的推理都会出错。所以写入长期记忆前要有校验，敏感信息要过滤。
3.4 决策点四：循环怎么终止
循环终止是 Agent 稳定性的命门。终止条件设计不好，要么任务没完成就停，要么停不下来。
终止条件通常有几类：任务完成（LLM 明确表示做完了）、达到最大轮数、达到 token 或时间预算、遇到无法恢复的错误、需要人工介入。
我的做法是组合使用：设置一个合理的最大轮数（比如 15 到 25 轮，视任务复杂度），同时设置 token 预算上限，再加上任务完成的判断。任何一条触发就停。这样既能防止死循环，又不会因为单一条件的误判而提前终止。
任务完成的判断要小心。不能只靠 LLM 说"我完成了"，因为它可能自我感觉良好但实际没做完。更好的做法是让 Agent 在声称完成时，输出一个明确的完成信号（比如特定的标记或结构化输出），并且最好有验证步骤。
3.5 决策点五：错误怎么恢复
Agent 运行中出错是常态：工具调用失败、参数格式错误、API 超时、模型输出不符合预期。错误恢复能力决定了 Agent 是"一碰就碎"还是"皮实耐用"。
我的错误处理分三层。第一层是重试：对于瞬时错误（网络抖动、限流），自动重试几次，带退避。第二层是修正：对于参数错误、格式错误，把错误信息反馈给 LLM，让它重新生成。第三层是降级：对于无法恢复的错误，记录状态，优雅退出，并告知用户发生了什么。
关键点是：错误信息要完整地反馈给 LLM。很多人只告诉模型"失败了"，模型根本不知道怎么改。要把具体的错误内容、期望的格式都告诉它，它才能自我修正。这是 Agent 自主容错的核心。
3.6 决策点六：上下文怎么组织
上下文组织直接影响 LLM 的推理质量。每一轮循环，你都要决定往 prompt 里放什么：系统指令、工具定义、历史对话、当前状态、检索到的记忆、上一步的观察结果。
组织原则是：重要的放前面和后面，次要的放中间（模型对首尾更敏感）；结构要清晰，用明确的分隔符区分不同部分；控制总量，别把窗口塞满，留出空间给模型的输出。
我习惯的模板是：系统指令（角色、目标、约束）→ 工具定义 → 长期记忆（检索结果）→ 历史对话（压缩后）→ 当前状态 → 本轮任务。这个顺序实测下来模型理解得比较清楚。
3.7 决策点七：怎么评估和迭代
Agent 搭出来只是开始，能不能持续优化靠的是评估体系。没有评估，你改了一个 prompt 都不知道是变好了还是变差了。
评估的核心是构建测试集：收集一批有代表性的任务，每个任务有明确的期望结果或评判标准。然后每次改动后跑一遍，看通过率、平均轮数、token 消耗这些指标的变化。
评判标准可以是精确匹配（适合有确定答案的任务），也可以是 LLM as Judge（让另一个模型来打分，适合开放式任务）。LLM as Judge 要注意校准，最好人工抽检一部分，确保评判模型的标准和你的预期一致。
迭代的节奏上，我建议小步快跑：一次只改一个变量（比如只改工具描述），跑评估，看效果，再决定下一步。同时改多个变量，你根本不知道是哪个起了作用。
4. 循环机制深挖：Agent 的心跳是怎么跳的
循环机制值得单独拿出来讲，因为它是 Agent 区别于普通 LLM 调用的本质特征，也是最多坑的地方。我把它拆成几个层面来讲。
4.1 一轮循环里到底发生了什么
一轮完整的循环，大致是这样的：首先，系统把当前状态（任务、历史、上一步结果）组织成 prompt 发给 LLM；LLM 返回一个决策，可能是调用某个工具，也可能是给出最终答案；如果是调用工具，系统解析出工具名和参数，执行工具，拿到结果；然后把这个结果作为"观察"加入状态，进入下一轮。
这个流程听起来简单，但每一步都有细节。比如 LLM 返回的决策怎么解析？现在主流是用 function calling 的结构化输出，比早期靠正则从文本里抠要可靠得多。但即便如此，也要处理模型返回格式不对的情况。
再比如工具执行的结果怎么处理？如果结果很长（比如返回了一大段网页内容），直接塞进上下文会撑爆窗口，需要做截断或摘要。如果结果是错误，要按前面说的错误恢复策略处理。
4.2 循环失控的几种典型场景
循环失控是我踩过最贵的坑。几种典型场景：
第一种是"原地打转"。Agent 反复调用同一个工具，拿到同样的结果，但就是不推进。这通常是因为任务描述不清，或者工具返回的信息不足以让它做下一步决策。解决办法是在循环里加"重复检测"：如果连续几轮调用相同工具、相同参数，就强制中断或提示模型换思路。
第二种是"无限细化"。Agent 觉得任务永远没做完，一直往下拆。这通常是终止条件太宽松。解决办法是设置硬性的轮数上限，并且在 prompt 里明确"达到什么标准就算完成"。
第三种是"错误循环"。工具一直失败，Agent 一直重试同样的调用。解决办法是限制单个工具的重试次数，超过就换策略或退出。
提示：给循环加一个"预算看门狗"非常有必要。监控累计 token 消耗和轮数，超过阈值立即中断。这个机制能帮你避免半夜被账单惊醒。
4.3 怎么让循环既灵活又可控
灵活和可控是一对矛盾。太灵活容易失控，太可控又显得死板。我的平衡做法是：在关键节点设硬约束，在非关键环节给自由度。
硬约束包括：最大轮数、token 预算、危险工具的白名单、必须人工确认的操作。这些是红线，不能碰。
自由度体现在：具体用哪个工具、怎么组织参数、怎么分解步骤，这些交给 LLM 自主决定。只要不碰红线，就让它发挥。
另外，我会在系统指令里明确告诉 Agent 它的"工作边界"：能做什么、不能做什么、遇到不确定的情况怎么办（比如询问用户而不是瞎猜）。清晰的边界能大幅减少失控。
5. 工具调用与记忆管理的工程细节
工具调用和记忆管理是 Agent 工程里最需要打磨的两块。这一节把实操细节摊开讲。
5.1 工具调用的完整链路
一次工具调用，从 LLM 决定调用到结果返回，中间经过好几个环节：LLM 输出调用意图 → 解析出工具名和参数 → 参数校验 → 权限检查 → 执行工具 → 处理结果 → 格式化返回给 LLM。
每个环节都可能出问题。参数校验能拦住格式错误；权限检查能拦住越权操作；执行环节要处理超时和异常；结果处理要控制长度和格式。把这些环节都做扎实，工具调用的成功率会高很多。
我特别想强调参数校验。用 JSON Schema 做严格校验，类型不对、必填缺失、取值越界都拦下来，并且把具体的校验错误反馈给 LLM 让它重试。这一步能挡掉相当一部分失败。
5.2 工具返回结果的处理艺术
工具返回的结果，不是原样塞给 LLM 就完事。要考虑几点：
长度控制。结果太长要截断或摘要。截断要保留关键部分（比如开头和结尾），摘要要用 LLM 生成。我一般设一个阈值，比如超过 2000 token 就处理。
格式规整。把结果整理成 LLM 容易理解的格式，比如结构化的 JSON 或者清晰的文本。杂乱的原始数据会让模型困惑。
错误标记。如果工具执行失败，要明确告诉 LLM 这是错误，并附上错误原因，而不是返回一个空结果让它猜。
5.3 记忆写入的时机和校验
长期记忆什么时候写？我的做法是在任务完成或阶段性完成时写，而不是每轮都写。每轮都写会产生大量冗余和噪音。
写入前要校验：这条信息是否准确（有没有事实错误）、是否有价值（是不是通用经验）、是否安全（有没有敏感信息）。校验可以用规则，也可以用 LLM 辅助。
写入的内容要结构化：包含时间、任务类型、关键结论、适用条件。这样检索的时候才能精准匹配。
5.4 记忆检索的排序策略
检索出来的记忆怎么排序？纯按向量相似度排，经常把语义相近但实际无关的排前面。我的综合排序公式大致是：相似度得分 × 权重1 + 时间新鲜度 × 权重2 + 使用频率 × 权重3。具体权重根据场景调。
另外，检索结果要做去重和多样性控制。如果 top 5 里有 3 条说的是同一件事，那实际有效信息只有 1 条，浪费了上下文空间。
6. 安全约束与容错：让 Agent 皮实起来
Agent 一旦接入真实系统，安全就是绕不开的话题。这一节讲怎么给 Agent 装上护栏，以及怎么让它具备自主容错能力。
6.1 工具权限的最小化原则
给 Agent 的工具权限，遵循最小化原则：只给完成任务必需的权限，不多给一分。比如一个只读查询的 Agent，就不要给它写权限；一个只能操作特定表的 Agent，就不要给它全库权限。
权限控制可以在工具层面做（不同工具不同权限），也可以在参数层面做（限制参数取值范围）。对于危险操作（删除、修改、支付），强制要求二次确认，或者干脆不让 Agent 自动执行，转人工。
6.2 输入输出的内容过滤
Agent 的输入（用户消息、工具返回）和输出（给用户的回复、工具调用参数）都要过滤。输入过滤防止 prompt 注入和恶意指令；输出过滤防止敏感信息泄露和不当内容。
prompt 注入是 Agent 特有的风险：用户可能在输入里藏指令，试图让 Agent 执行非预期操作。防御手段包括：把用户输入和系统指令明确隔离、对用户输入做清洗、关键决策加校验。
6.3 自主容错的实现思路
自主容错是指 Agent 遇到问题时能自己想办法解决，而不是直接崩掉。实现思路是：把错误当作一种"观察结果"反馈给 LLM，让它基于错误信息调整策略。
比如工具调用参数错了，把校验错误反馈给 LLM，它重新生成正确参数；比如某个 API 挂了，告诉 LLM 这个工具暂时不可用，让它换别的工具或换思路。
关键是错误信息要具体、可操作。笼统的"出错了"没用，要告诉它"参数 age 应该是整数，你传了字符串 abc"。
6.4 监控与告警
生产环境的 Agent 必须有监控：调用成功率、平均轮数、token 消耗、错误分布、异常中断次数。这些指标能帮你及时发现问题和优化方向。
告警要设阈值：比如错误率超过某个值、单次任务 token 消耗异常高、出现死循环迹象，都要触发告警。别等到用户投诉才发现问题。
7. 从 Demo 到生产：我踩过的那些坑
最后这部分，分享几个我在实际项目里踩过的坑，都是文档里不会写、但真实会遇到的。
第一个坑是"工具描述想当然"。我写过一个查询工具，描述就一句"查询用户信息"，结果模型经常传错参数。后来把描述改成"根据用户 ID 查询用户的基本信息，包括姓名、邮箱、注册时间。参数 user_id 是必填的字符串，格式为 U 开头的 8 位编号"，调用成功率立刻上去了。工具描述真的要当产品文案来写。
第二个坑是"上下文塞太满"。早期我为了信息全，把能塞的都塞进 prompt，结果模型反而抓不住重点，推理质量下降。后来学会做减法，只放当前决策必需的信息，效果反而更好。上下文不是越多越好，是越精准越好。
第三个坑是"忽略循环预算"。有次测试一个任务，Agent 陷入了一个隐蔽的循环，跑了一晚上，第二天看到账单才反应过来。从那以后，所有 Agent 我都强制加 token 和轮数上限，这是保命机制。
第四个坑是"记忆污染"。有次长期记忆里混进了一条错误的用户偏好，导致后续好几天的推荐都不对。排查了半天才发现是记忆写入时没校验。现在写入长期记忆前，我都会过一道校验。
第五个坑是"评估缺失"。早期改 prompt 全凭感觉，改完觉得"好像好点了"就上线，结果经常是按下葫芦浮起瓢。后来老老实实建了测试集，每次改动都跑评估，才发现很多"感觉变好"的改动其实是负优化。
这些坑说到底都指向一个道理：Agent 工程是个细致活，魔鬼在细节里。模型能力固然重要，但真正决定 Agent 好不好用的，是这些工程细节有没有做到位。把七个要素理解透，把七个决策点做扎实，再配上持续的评估和迭代，一个稳定的 Agent 系统就成型了。至于具体用哪个框架、哪种语言，反而是次要的——Rust 也好，Python 也好，框架只是工具，思路才是核心。
