1. 从七个零件到七次抉择：AI Agent 工程实现的底层逻辑

很多人第一次接触 AI Agent 这个概念，脑子里浮现的画面大概是科幻电影里那种能自己思考、自己行动的数字生命。但真到了动手搭建的时候，你会发现它其实更像一台精密的自动化机床——由几个关键部件咬合而成，每个部件在运行时都要做出一系列决策。我过去一年多时间里，前前后后搭过十几个不同形态的 Agent，从最简单的客服问答机器人，到需要多步推理、调用外部工具、维护长期记忆的复杂系统，踩过的坑可以说遍布每一个环节。

这篇文章想做的事情很纯粹：把 AI Agent 从概念到落地的完整链路拆开，先讲清楚它由哪七个核心要素构成，再逐一分析在工程实现中必须面对的七个关键决策点。无论你是刚入门的开发者，还是已经有一定经验、想系统梳理知识体系的老手，都能从中找到可以直接参考的思路和方案。文章会涉及 LLM 模型选型、工具调用机制、循环控制策略、记忆管理、并发处理、安全防护以及可观测性建设等话题，基本覆盖了 Agent 开发中绕不开的核心问题。

我尽量不堆砌术语，而是用实际项目中的例子来说明每个决策背后的权衡。比如为什么有些场景适合用简单的 ReAct 循环，而有些场景必须上 LangGraph 这样的编排框架；为什么工具调用的参数校验比你想的要重要得多；为什么并发能力不是简单加机器就能解决的。这些经验大多来自真实的调试过程和线上事故复盘，希望能帮你少走一些弯路。

2. AI Agent 的七个核心要素拆解

在讨论工程实现之前，有必要先把 Agent 的构成要素理清楚。我习惯把它拆成七个部分来看，这个划分方式不一定标准，但在实际开发和团队沟通中非常实用。每个要素都对应着系统中的一个具体模块或机制，理解它们之间的协作关系，是后续做技术选型和架构设计的基础。

2.1 大脑：LLM 模型的选型与适配

LLM 是 Agent 的推理核心，相当于整个系统的大脑。它负责理解用户意图、规划任务步骤、决定何时调用工具、生成最终回复。目前市面上可选的模型很多，从闭源 API 到开源权重，从通用大模型到垂直领域微调版本，选择范围很广。

选模型的时候，我通常会从四个维度来评估。第一是推理能力，也就是模型在复杂任务上的表现，比如多步逻辑推理、代码生成、结构化输出等。第二是响应延迟，这直接决定了用户体验，尤其是需要多轮交互的场景。第三是成本，包括 token 单价和调用频率限制。第四是可控性，比如是否支持函数调用、是否允许自定义系统提示词、是否有内容过滤策略。

实际项目中，我经常采用混合策略：用能力强的模型做任务规划和复杂推理，用轻量模型做意图分类和简单问答。这样能在成本和效果之间取得比较好的平衡。举个例子，在一个电商客服 Agent 里，用户的第一句话先用小模型判断意图类别，如果是简单的物流查询就直接走预设流程，如果是复杂的退换货纠纷再交给大模型处理。

注意：模型选型不是一锤子买卖。上线后要持续监控各环节的 token 消耗和响应质量，根据实际数据动态调整路由策略。

2.2 手脚：工具调用的设计与实现

工具调用是 Agent 从“能说”到“能做”的关键跨越。没有工具，Agent 只能停留在文本生成层面；有了工具，它才能查数据库、调 API、发邮件、操作文件系统。工具调用的本质是让 LLM 输出结构化的函数调用请求，由外部执行器完成实际操作，再把结果返回给模型继续推理。

设计工具时，有几个细节特别容易出问题。首先是工具描述的清晰度，LLM 完全依赖自然语言描述来理解工具的用途和参数含义，描述模糊会导致调用错误。其次是参数校验，模型生成的参数不一定符合预期格式，必须在执行前做严格校验。第三是错误处理，工具执行失败时返回给模型的信息要足够明确，让模型能判断是重试、换工具还是放弃。

我一般会为每个工具定义三个部分：名称和描述、参数 schema、执行函数。参数 schema 用 JSON Schema 格式定义，明确每个参数的类型、是否必填、取值范围。执行函数里做好异常捕获，把错误信息转换成模型能理解的格式返回。

tools = [ { "name": "query_order_status", "description": "根据订单号查询订单当前状态，返回状态码和描述", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，格式为 ORD 开头加 12 位数字" } }, "required": ["order_id"] } } ]

2.3 记忆：短期上下文与长期知识的管理

记忆系统决定了 Agent 能“记住”多少信息、记多久。短期记忆通常就是对话历史，直接放在上下文窗口里。长期记忆则需要外部存储支持，比如向量数据库、关系型数据库或键值存储。

短期记忆的管理核心是上下文窗口的分配。窗口大小有限，不可能把所有历史都塞进去。常见的做法是滑动窗口加摘要压缩：保留最近 N 轮完整对话，更早的内容用模型生成摘要后保留关键信息。这样既能维持对话连贯性，又能控制 token 消耗。

长期记忆的写入和检索策略更复杂一些。写入时需要考虑哪些信息值得长期保存，比如用户偏好、历史订单、常见问题解决方案等。检索时通常用向量相似度搜索，把当前查询和记忆库中的内容做匹配，取最相关的几条注入上下文。

我在一个内部知识助手项目里用过这样的方案：用户每次提问后，系统会把问答对向量化存入数据库；下次提问时先检索相似历史问答，如果相似度超过阈值就直接返回缓存答案，否则再走完整推理流程。这个策略把平均响应时间降低了将近一半。

2.4 规划：任务分解与执行路径生成

规划能力让 Agent 能把复杂任务拆成可执行的步骤。比如用户说“帮我安排下周去北京的出差”，Agent 需要分解出查航班、订酒店、安排会议、生成行程单等一系列子任务，并确定执行顺序和依赖关系。

规划的实现方式主要有两种。一种是隐式规划，依赖 LLM 在推理过程中自行决定下一步做什么，ReAct 模式就是典型代表。另一种是显式规划，先用模型生成完整的任务列表，再按顺序执行，必要时根据中间结果调整计划。

隐式规划灵活但容易跑偏，显式规划可控但不够灵活。实际项目中我倾向于混合使用：先用显式规划生成高层步骤，每个步骤内部再用隐式推理决定具体操作。这样既有全局视野，又保留了局部灵活性。

2.5 循环：推理与执行的迭代控制

循环机制是 Agent 区别于普通 LLM 调用的核心特征。Agent 不是一问一答就结束，而是会经历“推理-行动-观察-再推理”的多次迭代，直到任务完成或达到终止条件。

循环控制的关键在于终止条件的设定。常见的有最大迭代次数、任务完成标志、连续无进展检测等。没有合理的终止条件，Agent 可能陷入死循环，不断重复同样的操作，白白消耗 token 和时间。

我在早期项目里就遇到过这个问题：Agent 调用搜索工具没找到答案，又换个关键词再搜，反复十几次都没结果。后来加了“连续三次搜索结果相似度超过阈值就终止”的规则，才解决了这个浪费。

2.6 安全：权限控制与风险防范

安全是 Agent 从 demo 走向生产环境必须跨过的门槛。Agent 能调用工具、访问数据、执行操作，一旦被恶意利用或出现意外行为，后果可能很严重。

安全防护要覆盖多个层面。输入层面要做 prompt 注入检测，防止用户通过精心构造的输入让 Agent 执行非预期操作。工具层面要做权限分级，敏感操作需要二次确认或人工审批。输出层面要做内容过滤，避免泄露敏感信息或生成不当内容。

提示：永远不要给 Agent 直接操作生产数据库的权限。所有写操作都应该经过一层业务 API，在 API 层做权限校验和审计日志。

2.7 观测：日志、指标与可追溯性

可观测性决定了你能不能搞清楚 Agent 到底在干什么。一个没有日志的 Agent 系统，出问题的时候只能靠猜，排查效率极低。

我通常会在几个关键节点埋点：每次 LLM 调用的输入输出和耗时、每次工具调用的参数和结果、每轮循环的状态变化、最终任务的完成情况。这些数据汇总到监控面板上，能直观看到成功率、平均轮次、token 消耗、错误分布等指标。

除了指标，完整的调用链追踪也很重要。给每个用户请求分配一个 trace_id，所有相关的 LLM 调用和工具调用都带上这个 ID，排查问题时可以完整还原整个执行路径。

3. 工程实现中的七个关键决策点

理解了七个核心要素之后，接下来要面对的是工程落地时的具体选择。每个决策点都涉及多方面的权衡，没有绝对正确的答案，只有适合当前场景的方案。下面逐一展开分析。

3.1 决策一：自建还是用框架

这是每个 Agent 项目启动时都要回答的问题。自建意味着完全掌控代码，可以针对业务做深度定制，但开发周期长，很多基础能力要自己实现。用框架比如 LangChain、LangGraph、Spring AI 等，能快速搭建原型，但可能遇到框架限制、版本升级、调试困难等问题。

我的建议是分阶段决策。项目初期、需求还不明确的时候，用框架快速验证想法，把核心流程跑通。等业务逻辑稳定了，再评估是否需要把关键模块替换成自研实现。完全自建不一定好，过度依赖框架也有风险，关键是找到适合团队能力和项目阶段的平衡点。

具体评估时我会看几个指标：框架的社区活跃度、文档质量、是否支持自定义扩展、有没有生产环境案例。LangGraph 在编排复杂流程方面确实有优势，但如果你的 Agent 逻辑很简单，用原生 API 加几十行代码就能搞定，没必要引入额外依赖。

3.2 决策二：单 Agent 还是多 Agent 协作

单 Agent 架构简单直接，所有任务由一个 Agent 处理。多 Agent 则是把不同职责分配给不同的 Agent，比如一个负责规划、一个负责执行、一个负责审核，它们之间通过消息传递协作。

多 Agent 听起来很美好，但实际落地时复杂度会指数级上升。Agent 之间的通信协议、状态同步、冲突解决、错误传播都是难题。我见过不少项目一开始就设计多 Agent 架构，结果调试成本远超预期，最后又退回单 Agent。

我的经验是：除非任务确实需要多个独立视角（比如代码生成加代码审查），否则优先用单 Agent 加多工具的方式解决。单 Agent 的推理链路更短，出问题时更容易定位。等单 Agent 确实扛不住了，再考虑拆分。

3.3 决策三：工具调用的粒度怎么定

工具粒度直接影响 Agent 的灵活性和可靠性。粒度太粗，一个工具做太多事情，模型难以准确调用；粒度太细，工具数量爆炸，模型选择困难，调用轮次也会增加。

我一般遵循“单一职责”原则：每个工具只做一件事，但这件事要足够完整。比如“查询订单”和“修改订单地址”应该是两个工具，而不是一个“订单管理”工具带一堆参数。同时，工具的参数设计要尽量扁平，避免嵌套结构，因为模型处理嵌套参数的准确率会下降。

另一个实用技巧是给工具加“使用示例”。在工具描述里附上一两个典型的调用示例，能显著提升模型调用的准确率。这相当于给模型做了 few-shot 提示，效果立竿见影。

3.4 决策四：上下文窗口怎么分配

上下文窗口是稀缺资源，需要精打细算。系统提示词、工具定义、对话历史、检索到的知识、当前查询，这些都要占空间。分配不合理会导致关键信息被截断，或者 token 成本飙升。

我的分配策略通常是：系统提示词和工具定义占 20% 左右，对话历史占 30%，检索知识占 30%，剩余 20% 留给模型输出和缓冲。当然这个比例要根据实际场景调整，工具多的系统提示词占比会更高，知识密集型应用检索内容占比更大。

当上下文接近上限时，要有降级策略。比如优先压缩对话历史，把早期轮次替换成摘要；或者减少检索结果数量，只保留最相关的几条。这些策略要提前设计好，不能等出问题了再临时处理。

3.5 决策五：并发能力怎么扛

“AI Agent 怎么扛并发”是很多人关心的问题。Agent 的并发瓶颈通常不在 LLM 调用本身，而在工具执行和状态管理。LLM API 一般有速率限制，但可以通过队列和重试来平滑。工具执行如果涉及数据库查询或外部 API，延迟可能很高，需要做异步化和连接池管理。

状态管理是并发场景下最容易出问题的地方。多个用户请求同时操作同一份记忆或上下文时，必须做好隔离和加锁。我一般用 session_id 做隔离，每个会话有独立的上下文空间，互不干扰。对于共享的长期记忆，写入时用乐观锁或版本号控制，避免覆盖冲突。

如果并发量确实很大，可以考虑把 Agent 拆成无状态的服务层和有状态的数据层。服务层可以水平扩展，数据层用 Redis 或类似方案做集中管理。这样架构更清晰，扩展也更容易。

3.6 决策六：错误处理和重试策略怎么设计

Agent 执行过程中出错是常态，关键是怎么处理。错误大致分三类：LLM 调用失败（网络问题、速率限制）、工具执行失败（参数错误、外部服务不可用）、逻辑错误（模型推理跑偏、陷入循环）。

对于 LLM 调用失败，简单的指数退避重试通常能解决大部分问题。对于工具执行失败，要把错误信息结构化后返回给模型，让模型决定是重试、换参数还是放弃。对于逻辑错误，需要设置兜底策略，比如达到最大轮次后强制返回当前最佳结果，或者转人工处理。

我习惯给每个工具调用加超时控制，避免某个外部服务卡住导致整个 Agent 挂起。超时后返回明确的错误信息，模型看到后通常会尝试其他方案。

3.7 决策七：怎么评估 Agent 的效果

没有评估就没有优化。Agent 的效果评估比传统软件复杂，因为输出不是确定性的，很难用简单的通过/失败来判断。

我通常从几个维度来评估：任务完成率、平均交互轮次、用户满意度、token 消耗、响应延迟。任务完成率是最核心的指标，但需要明确定义什么算“完成”。对于开放式任务，可以用 LLM as judge 的方式，让另一个模型来评判输出质量。

除了自动化指标，定期的人工抽检也很重要。我会每周随机抽取一批对话记录，人工评估 Agent 的表现，发现自动化指标覆盖不到的问题。这些定性观察往往能揭示出更深层的优化方向。

4. 实操搭建：一个可运行的 Agent 最小系统

理论讲了不少，接下来动手搭一个最小可运行的 Agent 系统。这个系统会包含 LLM 调用、工具注册、循环控制、记忆管理这几个核心模块，代码量不大，但结构完整，可以作为后续扩展的基础。

4.1 环境准备与依赖安装

我选择 Python 作为实现语言，因为它生态成熟、上手快。核心依赖包括 LLM 客户端库、HTTP 请求库、向量数据库客户端。具体装什么取决于你用的模型服务，这里以通用结构为例。

pip install openai httpx numpy

如果你打算用本地模型，可以换成对应的客户端库。向量存储方面，开发阶段用内存版就够，生产环境再换持久化方案。

环境变量里配置好 API 密钥和基础地址，不要硬编码在代码里。这是基本的安全习惯，也方便在不同环境间切换。

4.2 定义工具注册机制

工具注册机制的核心是一个字典，把工具名称映射到执行函数和参数 schema。这样模型输出工具调用请求时，系统能快速找到对应的执行逻辑。

import json class ToolRegistry: def __init__(self): self.tools = {} def register(self, name, description, parameters, func): self.tools[name] = { "description": description, "parameters": parameters, "func": func } def get_schemas(self): return [ { "type": "function", "function": { "name": name, "description": info["description"], "parameters": info["parameters"] } } for name, info in self.tools.items() ] def execute(self, name, arguments): if name not in self.tools: return {"error": f"未知工具: {name}"} try: args = json.loads(arguments) result = self.tools[name]["func"](**args) return {"result": result} except Exception as e: return {"error": str(e)}

这个注册机制的好处是工具定义和执行分离，新增工具只需要注册一次，不用改核心逻辑。参数校验放在执行函数里做，保持注册逻辑简洁。

4.3 实现推理循环

推理循环是 Agent 的心脏。它不断调用 LLM，检查输出中是否有工具调用请求，有就执行工具并把结果追加到对话历史，没有就返回最终回复。

def run_agent(user_input, registry, client, max_turns=10): messages = [ {"role": "system", "content": "你是一个乐于助人的助手，可以调用工具来完成任务。"}, {"role": "user", "content": user_input} ] for turn in range(max_turns): response = client.chat.completions.create( model="your-model", messages=messages, tools=registry.get_schemas(), tool_choice="auto" ) msg = response.choices[0].message if not msg.tool_calls: return msg.content messages.append(msg) for call in msg.tool_calls: result = registry.execute(call.function.name, call.function.arguments) messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False) }) return "达到最大轮次限制，任务未完成。"

这段代码虽然短，但包含了 Agent 的核心逻辑：调用模型、判断是否有工具调用、执行工具、把结果回传、继续循环。实际项目中需要在此基础上加错误处理、日志记录、超时控制等。

4.4 加入记忆管理

记忆管理分短期和长期两部分。短期记忆就是上面的 messages 列表，长期记忆需要额外的存储和检索逻辑。

class MemoryStore: def __init__(self): self.records = [] def add(self, content, embedding): self.records.append({"content": content, "embedding": embedding}) def search(self, query_embedding, top_k=3): if not self.records: return [] scored = [] for r in self.records: score = cosine_similarity(query_embedding, r["embedding"]) scored.append((score, r["content"])) scored.sort(reverse=True) return [c for _, c in scored[:top_k]]

检索到的记忆内容可以拼接到系统提示词里，或者作为额外的上下文消息插入。注意控制注入的记忆数量，太多会挤占上下文窗口。

4.5 配置日志与监控

日志要记录每个关键节点的信息：用户输入、LLM 请求和响应、工具调用参数和结果、循环轮次、最终输出。用结构化日志格式，方便后续分析和告警。

import logging import time logger = logging.getLogger("agent") def log_step(trace_id, step, data): logger.info(json.dumps({ "trace_id": trace_id, "step": step, "timestamp": time.time(), "data": data }, ensure_ascii=False))

trace_id 贯穿整个请求生命周期，排查问题时可以按 ID 过滤出完整链路。生产环境建议接入统一的日志平台，配合监控面板使用。

5. 常见问题与排查技巧实录

Agent 开发过程中遇到的问题五花八门，但有一些是高频出现的。我把它们整理成速查表，附上排查思路和解决方法，希望能帮你快速定位问题。

5.1 工具调用失败排查表

5.2 循环失控的预防与处理

循环失控是 Agent 最常见的异常之一。表现是 Agent 不断重复相似的操作，消耗大量 token 却没有任何进展。

预防措施有几个。第一是设置最大轮次限制，这是最基本的兜底。第二是检测重复操作，如果连续几轮的工具调用参数高度相似，就强制终止或切换策略。第三是在系统提示词里明确告知模型“如果多次尝试无果，应该返回当前最佳结果并说明情况”。

处理已经发生的循环时，先看日志确认循环的模式。是同一个工具反复调用，还是不同工具但目标相同？前者通常是参数问题，后者可能是任务理解偏差。针对性地调整提示词或工具设计，通常能解决。

5.3 上下文超限的应对策略

上下文超限的表现是模型开始“遗忘”早期信息，或者直接报错。这时候需要主动做上下文压缩。

我的做法是分层处理：首先压缩对话历史，把超过 N 轮的旧对话用模型生成摘要替换；其次精简检索结果，只保留相似度最高的几条；最后如果还不够，就缩减系统提示词，去掉非必要的说明。

压缩时要注意保留关键信息。比如用户的核心诉求、已经确认的事实、正在执行的任务状态，这些不能丢。摘要生成时可以用专门的提示词引导模型保留这些要素。

5.4 模型输出不稳定的调优

同一个输入，模型有时给出完全不同的输出，这在 Agent 场景下很让人头疼。造成不稳定的原因可能是温度参数设置过高、提示词有歧义、或者模型本身的能力边界。

调优时先把温度调低，Agent 场景通常不需要太高的创造性。然后检查提示词是否有模糊表述，尽量用明确、具体的指令。如果还不行，考虑换模型或者加 few-shot 示例来约束输出格式。

对于关键决策点，可以加一层校验逻辑。比如模型输出工具调用请求后，先用规则引擎检查参数是否合理，不合理就拒绝并让模型重新生成。

5.5 性能瓶颈的定位方法

Agent 响应慢的时候，需要定位瓶颈在哪个环节。我在每个关键节点都加了耗时统计，包括 LLM 调用耗时、工具执行耗时、记忆检索耗时。

如果 LLM 调用占大头，考虑换更快的模型或者减少上下文长度。如果工具执行慢，看是外部服务问题还是自身实现问题，前者加缓存，后者优化代码。如果记忆检索慢，检查向量索引是否合理，必要时换更高效的索引结构。

并发场景下还要看是否有锁竞争或资源排队。用压测工具模拟多用户同时请求，观察各环节的延迟变化，通常能快速找到瓶颈点。

5.6 安全防护的实操要点

安全防护要从第一天就做，不能等上线了再补。输入层面，对用户输入做长度限制和特殊字符过滤，防止 prompt 注入。工具层面，敏感操作加确认机制，比如删除数据前要求用户二次确认。输出层面，过滤敏感信息，避免泄露内部数据。

权限控制要遵循最小权限原则。Agent 只应该拥有完成任务所必需的权限，多余的权限一律不给。所有工具调用都要记审计日志，方便事后追溯。

注意：不要信任模型生成的任何参数。所有参数在执行前都要做校验，尤其是涉及文件路径、SQL 语句、系统命令的场景。

6. 从能跑到好用：Agent 优化的几个方向

系统能跑起来只是第一步，真正难的是让它稳定、高效、可控。这部分分享几个我在实际项目中验证过的优化方向，每个都能带来可量化的提升。

6.1 提示词工程的持续迭代

提示词不是写一次就完事的，需要根据实际表现持续迭代。我习惯建一个提示词版本库，每次修改都记录变更内容和效果对比。

迭代时重点关注几个方面：指令是否明确、示例是否典型、边界情况是否覆盖。一个实用技巧是把线上出现的 bad case 整理成测试集，每次改完提示词都跑一遍，确保没有引入回归。

另外，不同模型对提示词的敏感度不同。换模型时提示词往往需要重新调优，不能直接迁移。

6.2 工具调用的缓存与批处理

很多工具调用是重复的，比如查询同样的配置、获取同样的用户信息。加一层缓存能显著减少外部调用次数，降低延迟。

缓存的 key 可以用工具名加参数哈希，设置合理的过期时间。对于实时性要求不高的数据，缓存几分钟到几小时都可以。对于写操作，缓存要谨慎，确保数据一致性。

批处理是另一个优化点。如果 Agent 需要查询多个独立的数据源，可以并行发起请求，而不是串行等待。用异步 IO 能大幅缩短总耗时。

6.3 多模型路由的成本控制

不同任务对模型能力的要求不同，全部用最强模型成本太高。我通常配置一个路由层，根据任务复杂度选择模型。

简单任务比如意图分类、实体提取，用小模型就够了。复杂任务比如多步推理、代码生成，才用大模型。路由规则可以基于关键词、任务类型或者先用小模型做一次快速判断。

实测下来，合理的路由策略能把 token 成本降低 40% 到 60%，而任务完成率几乎不受影响。

6.4 可观测性建设的进阶实践

基础的日志和指标之外，还可以做更深入的可观测性建设。比如记录每个决策点的模型置信度，分析哪些环节容易出错。再比如做 A/B 测试，对比不同提示词或模型版本的效果差异。

我还会定期做“回放测试”：把历史请求重新跑一遍，看新版本的表现是否优于旧版本。这能发现一些线上监控覆盖不到的问题，比如边缘 case 的处理。

可视化方面，把 Agent 的执行路径画成流程图，每个节点的耗时和结果都标注出来，排查问题时一目了然。

6.5 用户反馈的闭环利用

用户反馈是最宝贵的优化信号。我在产品里加了点赞/点踩功能，用户可以对 Agent 的回复做评价。这些反馈数据定期分析，能发现系统性的问题。

对于点踩的案例，人工复盘后归类：是理解错误、工具调用错误、还是知识缺失？针对不同类别采取不同措施。理解错误就优化提示词，工具错误就改进工具设计，知识缺失就补充知识库。

这个闭环跑通之后，Agent 的效果会随着使用量增长而持续提升，形成正向循环。

7. 一些踩坑之后的个人体会

做 Agent 这一年多，最大的感受是：不要低估工程细节的重要性。很多在 demo 阶段看起来没问题的地方，到了生产环境都会暴露出来。上下文管理、错误处理、并发控制、安全防护，这些“脏活累活”才是决定 Agent 能不能真正用起来的关键。

另一个体会是，Agent 的能力边界很大程度上取决于工具的质量。与其花大量时间调提示词，不如先把工具设计好。工具描述清晰、参数合理、错误处理完善，模型的表现会自然提升。

最后，保持对新技术的好奇，但不要盲目追新。框架和工具层出不穷，但核心原理是相通的。把基础打牢，理解 Agent 的本质是“LLM 加工具加循环”，剩下的就是在这个骨架上不断添砖加瓦。遇到问题多查日志、多做实验、多复盘，经验积累到一定程度，很多决策会变得直觉化。