AI Agent智能体实战指南：从ReAct原理到生产落地

在实际工作中，讨论 AI Agent 智能体的场合越来越多，但真正动手做过的人会发现：会调用大模型 API，和能构建一个稳定完成任务的智能体，是两种完全不同的能力。这篇内容围绕智能体的运行机制、学习路径、最小可运行实现、测试评估和生产落地展开，适合准备系统学习 AI Agent、想转智能体开发工程师，或者在项目中引入智能体的开发者。读完至少能判断一件事：网上那些“速成”课程的每一条结论，在真实项目里到底站不站得住。

1. 先弄清 AI Agent 与普通大模型应用的区别

很多初学者是从“调用大模型接口”开始接触智能体的，结果一上来就在 Dify、Coze、LangGraph、MaxKB 这些平台和框架之间来回切换，然后发现每个工具都在讲“工作流、工具调用、知识库、记忆”，反而越学越乱。这里的根因不是工具太难，而是没有先建立智能体的基础模型。

1.1 大模型应用是“一问一答”，智能体是“目标驱动”

普通的大模型应用，流程非常短：用户输入一个 Prompt，模型返回一段文本，请求结束。开发者只需要处理一次输入输出边界，业务上通常适合翻译、总结、生成文案、问答这类相对独立的任务。

智能体应用则不同。用户给的不是一条一次性指令，而是一个目标。智能体需要把目标拆解成若干步骤，判断每一步需要什么工具，执行工具后观察返回结果，再决定下一步动作，直到目标完成。比如“帮我把本周的销售数据整理成报告”，智能体可能要先去数据库查询数据、再调用图表工具生成图形、最后按模板生成 Word 报告，整个过程需要多轮循环。

这里有一个很关键的思维转换：大模型应用开发关心的是“这一句话回答得好不好”，智能体开发关心的是“整个任务是否在有限步骤内完成、中途出错如何恢复、工具调用是否准确”。代码结构上，前者是单次调用，后者是一个带状态的多轮循环。

1.2 标准的智能体工作循环：规划、工具、记忆、行动

不管是自研 Agent，还是使用 Dify、Coze、LangGraph 这类框架，底层几乎都是同一个循环：

1. 规划（Planning）：模型根据用户目标和当前状态，决定下一步需要做什么。
2. 行动（Action）：模型输出工具调用指令，例如查数据库、调 API、搜索知识库。
3. 观察（Observation）：程序执行工具，并把工具结果返回给模型。
4. 循环（Loop）：模型根据观察结果继续决策，直到不再需要调用工具，输出最终回答。

这个过程经常被称作 ReAct 模式，是 Reasoning 和 Acting 的结合。它的价值在于：模型不再一次性靠“记忆”硬答，而是可以借助外部工具验证信息、更新上下文。这也是为什么同样的模型，接入工具后解决复杂问题的能力会出现明显提升。

1.3 为什么工具调用能力决定了智能体边界

大模型本身有知识截止时间，无法实时查询天气、库存、订单，也无法访问企业内部系统。智能体真正在工程上要解决的，就是把模型和外部世界之间的“手”接上。

这里的“手”就是工具调用。技术上通常有两种做法：一种是模型先输出结构化的工具调用指令，程序解析后执行；另一种是程序先检索可用工具，再把工具描述拼进 Prompt 让模型选择。业界更主流的是前者，核心协议是大模型厂商提供的 Function Calling 或 Tool Calling 机制。模型会返回一个类似下面的 JSON 结构：

{ "name": "get_weather", "arguments": "{\"city\": \"北京\"}" }

程序拿到这个结果后，执行本地或远程函数，再把执行结果作为一条 tool 消息回传给模型。这样模型就能基于真实结果继续推理。

这也是智能体开发越来越像“工程问题”的原因：工具的编排方式、参数的 schema 设计、异常处理逻辑、上下文长度管理，每一项都比“提示词写得好不好”更影响成败。

2. 学习路径和前置基础必须按阶段推进

很多学习计划会把“7 天从入门到精通”作为目标，但从教学和工程经验看，7 天足够完成一个最小闭环，也可能让人上手写出第一个 Agent，但离“熟练解决生产问题”还有明显距离。比较稳妥的做法是，把学习分成三个阶段：基础补全、框架实践、项目打磨。

2.1 入门阶段需要掌握的基础项

下面这张表可以作为入门自检清单。每项都要能解释为什么需要，而不只是“听说过”。

能力项	推荐验证方式	建议投入时间
Python 基础语法	能独立写函数、类、异常处理	2 到 3 天
HTTP 与 REST API 理解	能读懂接口文档并完成一次鉴权调用	1 到 2 天
提示词工程基础	能给客服、汇总、分类等场景设计系统提示词	2 到 3 天
JSON 数据结构	会解析、构造、校验复杂嵌套 JSON	1 天
大模型 API 调用	跑通文本生成、流式输出、工具调用	2 天
向量与检索概念	理解 Embedding、相似度检索、召回的作用	2 天
版本管理与调试	会用 Git，能通过日志定位 Agent 停在哪一步	持续练习

这里最容易出现的误区是：跳过 API 调用，直接从可视化平台拖拽流程。平台确实能快速搭建业务 Demo，但一旦进入真实项目，跨系统权限、自定义工具、异常恢复、日志追踪，全都要靠代码能力解决。

2.2 学习环境、项目开发与生产环境要分层选型

智能体平台和框架非常多，选错阶段会很吃力。

工具或框架	定位	适合阶段	注意点
Coze / 扣子	一体化智能体搭建平台	入门体验、产品原型	内置工具多，但与自有系统集成受平台限制
Dify	开源 LLM 应用开发平台	中小项目、知识库问答	可自部署，适合学习工作流编排
MaxKB	知识库问答系统	企业文档问答、客服场景	重在检索和问答，不完全是通用 Agent 编排
LangGraph	基于状态图的 Agent 编排框架	复杂流程、生产系统	需要较强的 Python 和状态机思维
CrewAI / AutoGen	多智能体协作框架	多角色任务研究	多 Agent 的编排成本和可控性需要控制

选型建议遵循一条原则：学习环境追求“快速跑通”，优先用平台；项目开发追求“可控可改”，优先用开源框架或自研；生产环境追求“稳定可观测”，必须考虑日志、监控、限流、安全，而不只是“效果不错”。

2.3 一条可执行的智能体技术栈组合建议

如果从零开始，推荐的技术栈不是把所有框架都装一遍，而是按照“模型层、编排层、工具层、存储层、可观测层”来选择。例如：

• 模型层：本地环境用 Ollama 跑量化模型体验 OpenAI 兼容接口；正式项目按业务选商用或开源大模型。
• 编排层：起步用原生 Function Calling 手写一个循环；项目复杂后用 LangGraph 这类状态框架。
• 工具层：封装成独立函数或 HTTP 服务，输入输出严格定义成可校验的数据结构。
• 存储层：短期记忆放上下文，长期记忆用向量库或 KV 存储，业务数据走业务数据库。
• 可观测层：记录每次模型输入输出、工具调用参数、耗时、费用，便于回放问题。

这套组合的优点是每一层职责清晰。遇到问题能快速定位是模型决策错、工具执行错，还是存储和配置错。

3. 搭建一个最小可运行的智能体循环

理解概念之后，动手写一个最小 Agent 会帮助巨大。下面这个示例不一定适合生产，但它能说明一个智能体循环的完整骨架。建议在自己电脑上跑通后再去接框架。

3.1 环境准备与项目结构

准备条件：

1. Python 3.10 或更高版本。
2. 一个支持 OpenAI 兼容接口的模型服务，可以是远程服务，也可以是用 Ollama 启动的本地模型。
3. 安装依赖：

pip install openai python-dotenv

项目采用最小结构：

agent_demo/ ├── config.py ├── tools.py ├── main.py └── .env

config.py 用来读取环境变量。这样写的好处是，切换模型服务时只需要改 .env，不用改业务代码：

import os from dotenv import load_dotenv load_dotenv() LLM_BASE_URL = os.getenv("LLM_BASE_URL", "http://localhost:11434/v1") LLM_API_KEY = os.getenv("LLM_API_KEY", "EMPTY") LLM_MODEL = os.getenv("LLM_MODEL", "qwen2.5:7b")

3.2 定义两个工具：查天气和计算日期

tools.py 里定义智能体可以调用的函数。这里的天气工具先返回模拟数据，演示串行调用逻辑。真实项目可以替换成天气 API、数据库查询或内部服务接口。

import json from datetime import datetime, timedelta def get_weather(city: str) -> str: # 真实项目可以在这里调用天气 API data = {"city": city, "weather": "晴", "temperature": "18"} return json.dumps(data, ensure_ascii=False) def add_days(date: str, days: int) -> str: dt = datetime.strptime(date, "%Y-%m-%d") result = dt + timedelta(days=days) return result.strftime("%Y-%m-%d")

工具函数的输入参数会由模型根据函数描述自动生成，因此参数名和类型必须和 JSON Schema 保持一致，否则会出现参数解析失败。

3.3 实现 ReAct 主循环

main.py 中包含两个关键部分：模型客户端与工具声明、循环控制逻辑。

import json from openai import OpenAI from config import LLM_API_KEY, LLM_BASE_URL, LLM_MODEL from tools import add_days, get_weather client = OpenAI(base_url=LLM_BASE_URL, api_key=LLM_API_KEY) TOOLS = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的天气情况", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } } }, { "type": "function", "function": { "name": "add_days", "description": "计算某个日期之后第 n 天的日期", "parameters": { "type": "object", "properties": { "date": {"type": "string", "description": "起始日期，格式 YYYY-MM-DD"}, "days": {"type": "integer", "description": "增加的天数"} }, "required": ["date", "days"] } } } ] TOOL_MAP = { "get_weather": lambda **kwargs: get_weather(**kwargs), "add_days": lambda **kwargs: add_days(**kwargs), } def call_llm(messages): resp = client.chat.completions.create( model=LLM_MODEL, messages=messages, tools=TOOLS, ) return resp.choices[0].message def run_agent(user_input): messages = [ {"role": "system", "content": "你是一个智能助手，需要时会调用工具来获取信息，工具结果返回后再给出最终回答。"}, {"role": "user", "content": user_input} ] max_steps = 5 step = 0 while step < max_steps: message = call_llm(messages) if not message.tool_calls: print("[最终回答]", message.content) return messages.append({ "role": "assistant", "content": message.content or "", "tool_calls": [tc.model_dump() for tc in message.tool_calls] }) for tc in message.tool_calls: fn_name = tc.function.name fn_args = json.loads(tc.function.arguments) print(f"[调用工具] {fn_name}({fn_args})") result = TOOL_MAP[fn_name](**fn_args) messages.append({ "role": "tool", "tool_call_id": tc.id, "content": result }) step += 1 print("[达到最大步数，请人工检查上下文]") if __name__ == "__main__": run_agent("今天是2026年1月15日，北京天气适合穿什么衣服？顺便算一下3天后是哪天。")

关键点有三处：

1. assistant 消息在存在 tool_calls 时，必须原样把 tool_calls 传回模型，并且 content 不能省略。
2. 工具执行结果用 role=tool 的消息返回，且需要携带对应的 tool_call_id，模型才能把结果关联到之前的工具调用。
3. 必须设置 max_steps 上限，防止模型陷入“调用工具、看结果、继续调用”的死循环。

3.4 运行验证：看闭环是否完整

运行脚本后，如果一切正常，会看到类似下面的输出：

[调用工具] get_weather({'city': '北京'}) [调用工具] add_days({'date': '2026-01-15', 'days': 3}) [最终回答] 北京今天晴，温度18度，适合穿薄外套。3天后是2026年1月18日。

这个输出证明 Agent 已经完成了一个完整闭环：拆解目标、调用工具、观察结果、汇总回答。学习阶段可以继续做两件事：一是故意让某个工具抛异常，观察循环是否还能收敛；二是去掉 max_steps 上限，制造一个循环场景，体会为什么必须要有终止条件。

注意：模型输出的工具参数不一定总符合预期，JSON 解析失败、参数类型不匹配、工具返回空值，都是智能体开发中最常见的异常来源。最小实现一定要把每一条工具调用的入参和返回值打出来，否则后期很难排查。

4. 关键参数与记忆设计直接影响效果

把最小循环跑通之后，真正影响智能体效果的是参数和记忆设计。这两部分没有统一标准，但有一些通用规律可以遵循。

4.1 模型参数不能照搬“聊天场景”的配置

很多人在之前聊天应用里习惯用较高的 temperature 让回答更有创造性。到了智能体场景，这种参数配置往往会带来灾难：工具调用格式不稳定、参数偶尔多一个字段、回答时偏离任务要求。

参数	建议值	说明
temperature	0.0 到 0.3	Agent 任务要求稳定优先，不建议高随机性
top_p	0.7 到 0.9	和 temperature 二选一调，不建议同时大幅调整
max_tokens	至少给到工具调用所需长度	太短会导致 JSON 输出截断
tool_choice	auto	允许模型自主决定是否调用工具
stop	视使用场景配置	自定义输出格式时可以考虑

参数调整需要结合模型版本测试，不能只凭经验。同一组参数在不同模型上的表现可能差异很大。落地方案时，建议对不同参数组合跑同一批测试用例，用成功率选择配置。

4.2 系统提示词要约束决策边界

智能体的系统提示词和普通聊天不同，至少应包含四部分：

1. 角色定位：说明这个 Agent 要解决什么任务。
2. 可用工具：简要列出什么情况下使用哪个工具。
3. 决策规则：哪些情况必须调用工具，哪些情况可以直接回答。
4. 输出限制：例如禁止编造工具结果、最终回答必须引用工具输出。

示例：

你是订单查询助手。 只有用户询问订单状态、物流信息时，才调用 get_order_status 工具。 没有获取到工具结果之前，禁止编造订单状态。 如果用户问的内容与订单无关，直接说明你的能力范围。

这段提示词的核心价值是减少模型的“自由发挥”。尤其当工具不存在或工具调用失败时，给模型一个明确出口，能显著降低循环卡死概率。

4.3 记忆分三层：短期、长期、外部知识库

智能体的记忆不是一个概念，而是分层设计：

• 短期记忆：当前会话内的上下文消息，通常放在 messages 数组中。
• 长期记忆：跨会话持久化的用户偏好、历史结论，通常存在 Redis、关系库或向量库中。
• 外部知识库：企业文档、产品手册、FAQ，检索后以参考片段形式注入上下文。

短期记忆最容易忽略的是长度管理。多轮工具调用后，上下文会迅速膨胀，最终超过模型窗口。常见做法包括滑动窗口裁剪、关键信息摘要、只保留最近 N 轮原始消息。

MAX_CONTEXT_TURNS = 10 def trim_messages(messages): system = [m for m in messages if m["role"] == "system"] history = [m for m in messages if m["role"] != "system"] return system + history[-MAX_CONTEXT_TURNS:]

这个函数比较粗糙，但能说明思路：系统提示词永远保留，最近轮次保留，中间过程截断。生产项目还需要考虑压缩后是否丢失关键信息。

4.4 多智能体协作不是越多越好

多智能体经常被当作高级玩法，但从工程角度，它只应该在满足特定条件时采用。比如任务需要完全不同领域的专业知识、子任务可以并行执行、单 Agent 上下文已经明显超限。

场景	推荐方案	原因
简单问答	单 Agent	决策链短，成本低，好排查
销售线索分析	单 Agent + 工具	工具足够完成任务
综合市调报告	多 Agent 分工	不同角色需要不同的提示词和工具集
企业客服	单 Agent + 知识库	多 Agent 会带来额外的优先级冲突

多智能体风格的架构可以围绕“主控 + 工人”设计：主控负责拆解和分发，工人只负责执行。这种方式比完全自由协商式的多智能体更可控。

5. 测试与评测是智能体工程化的分水岭

很多智能体 Demo 在演示时效果很好，一上真实数据就漏洞百出。原因往往是缺少测试数据设计和评测机制。

5.1 测试数据集要覆盖正常、边界、对抗和多轮场景

AI Agent 的测试数据集不能只有最终答案正确与否，还应该记录“期望路径”。下面是一个典型的 JSONL 数据设计：

{"id": "case_001", "scene": "正常", "description": "用户查询订单状态", "input": "我昨天下的订单现在到哪里了", "expected_action": "call get_order_status", "expected_answer_contains": "运输中", "pre_context": []} {"id": "case_002", "scene": "边界", "description": "用户未登录", "input": "查一下我的订单", "expected_action": "ask_login", "expected_answer_contains": "登录", "pre_context": []} {"id": "case_003", "scene": "对抗", "description": "用户询问不存在工具能解决的问题", "input": "帮我预测明天彩票号码", "expected_action": "refuse", "expected_answer_contains": "无法", "pre_context": []}

建议按以下比例设计数据：正常场景 50%、边界场景 25%、对抗场景 15%、多轮和长上下文场景 10%。每个用例都带上期望行为，不只是期望答案，这样能同时验证模型决策路径是否偏离。

5.2 评测指标要同时看结果、路径和成本

单看“回答对不对”不够。一个智能体可能回答正确，但中间调了 5 个无关工具；另一个可能回答正确但耗时 30 秒。合理的评测指标至少包括：

指标	计算方式	意义
任务成功率	最终结果符合期望的比例	衡量整体效果
工具调用准确率	正确工具调用次数 / 总调用次数	衡量规划质量
无效轮次比例	未产生工具结果的轮次 / 总轮次	衡量收敛能力
平均执行步数	完成任务的工具调用次数平均值	控制成本
响应时延	从输入到最终回答的时间	影响用户体验
单任务成本	调用模型 token 总数 / 任务数	掌握费用

建议在测试脚本里统一打印这些指标，形成每次迭代的前后对比。只有量化，才能知道改动是否真的带来提升。

5.3 跑回归测试的最小脚本

下面给出一个最小回归脚本，核心逻辑是循环读取测试数据，运行 Agent，记录结果：

import json def run_eval(dataset_path): passed = 0 total = 0 tool_call_total = 0 tool_call_correct = 0 with open(dataset_path, "r", encoding="utf-8") as f: for line in f: case = json.loads(line) result = run_agent_with_trace(case["input"], case.get("pre_context", [])) total += 1 if evaluate_case(case, result): passed += 1 tool_call_total += result["tool_calls_count"] tool_call_correct += result["correct_tool_calls_count"] print(f"任务成功率: {passed / total:.2%}") print(f"工具调用准确率: {tool_call_correct / tool_call_total:.2%}")

run_agent_with_trace 是在 run_agent 基础上增加 trace 记录的函数。生产项目可以用 LangSmith、Langfuse 这类可观测工具替代，也可以先用 JSON 文件把每轮模型输出、工具结果、最终回答全部落盘，后续用脚本分析。

5.4 数据污染与过拟合要早发现

智能体评测很容易被过拟合误导。常见现象是：用开发时的同一条 prompt 反复测试，模型已经“背下”了答案；或者测试集规模太小，只有 5 条用例，根本无法反映真实分布。

预防方式有三种：

1. 测试集按时间分批，每期迭代固定保留一部分“从未调参”的 blind 用例。
2. 同一用例设计多个不同表达，避免模型记住特定句式。
3. 定期从线上真实日志中抽取新用例，补入测试集，替代重复的旧用例。

这里要特别警惕“用训练集当测试集”。如果测试用例是从开发对话中直接复制出来的，结果虚高是必然的，因为模型已经在这些上下文上做过隐式拟合。

6. 常见问题排查链路：先看输入，再看模型，再看工具

智能体出问题时，最忌讳直接怀疑模型能力。规范的排查顺序应该是：输入是否正确、消息格式是否合法、工具参数是否解析成功、工具执行是否异常、模型是否在重复决策、最终是否触发终止条件。

6.1 工具调用返回格式错误怎么查

现象：Agent 已经正确选择了工具，但程序报 JSON 解析失败，或者工具函数抛出参数错误异常。

常见原因：

1. 模型返回的 arguments 不是合法 JSON。
2. 函数 schema 中参数名和代码参数名不一致。
3. 某些参数允许 null，但代码没有做空值处理。
4. 模型返回参数是数组，但代码期望是字符串。

排查方式：

# 把模型返回的原始内容完整打印 print(tc.function.arguments)

解决建议：对工具函数统一做参数校验，入参类型不匹配时返回固定错误信息给模型，而不是直接抛异常。例如：

def get_weather(city: str = None) -> str: if not city: return json.dumps({"error": "missing city"}) return json.dumps({"city": city, "weather": "晴"})

这样模型收到错误信息后会在下一轮自动纠正，而不是让整个 Agent 崩溃。

6.2 Agent 陷入循环或反复调用同一工具

现象：日志中模型连续调用同一个工具，参数也几乎一样，没有推进到最终回答。

常见原因：

1. 工具返回的结果不够明确，模型判断还需要再查一次。
2. 系统提示词没有说明“拿到结果后必须总结”。
3. 上下文过长，模型丢失了之前已经调用过该工具的记录。
4. max_steps 设得过大，掩盖了循环问题。

解决方式：

1. 检查工具返回结果是否包含关键结论，避免只返回原始结构。
2. 在系统提示词中增加出口规则，例如“如果同一工具已经调用过两次，请直接根据已有信息回答”。
3. 如果问题来自上下文丢失，及时裁剪或摘要较早的工具结果。

这一问题的本质是“模型不知道任务已经完成”。给 Agent 明确的终止条件，比提高模型智商更重要。

6.3 API 响应异常与超时处理

现象：调用模型接口随机超时，或者偶发返回空 content。

生产环境必须为重试设计合理策略。最简单的方式是使用指数退避加抖动：

import time import random def call_llm_with_retry(messages, max_retries=3): for attempt in range(max_retries): try: return call_llm(messages) except Exception as e: if attempt == max_retries - 1: raise time.sleep(2 ** attempt + random.uniform(0, 1))

同时客户端要设置连接超时和读取超时，避免服务端一直无响应导致任务挂死。超时值根据模型规模和服务商而定，但一般不建议低于 30 秒。

6.4 生产环境必须补上的保障清单

学习环境只要能跑通即可，生产环境则要额外考虑以下内容：

关注点	实践建议
日志	每次模型调用和工具调用都记录请求 ID、入参、返回、耗时
安全	工具执行前校验参数，禁止模型跨权限调用高危险操作
限流	对模型 API 和工具 API 分别做限流，防止成本失控
监控	统计成功率、平均步数、单任务费用，超过阈值告警
回滚	提示词和工具配置版本化，异常时可以快速回滚
隐私	用户信息脱敏后再进入模型上下文，日志中不落明文敏感数据

生产环境的核心不是“效果更好”，而是“出问题时能快速定位并恢复”。如果没有可观测性，智能体再智能也无法稳定交付。

7. 面向求职和技术进阶的实践建议

智能体开发工程师是当前热门方向，但招聘方真正关心的核心能力很少是“会用某个平台”，而是理解原理、会落地、能排查、有工程素养。

7.1 智能体开发岗位的常见考察点

能力维度	考察方式	准备建议
工具调用原理	手写 ReAct 循环或解释 Function Calling 流程	能画清模型、函数、消息三者的数据流
系统设计	设计一个客服智能体，包含知识库、工具、记忆	重点讲清数据流、失败恢复、权限隔离
评测能力	如何判断一个智能体改好了	需要有测试数据集设计和指标对比经验
工程能力	API 超时、速率限制、日志、部署	用真实项目说明问题排查过程
框架理解	LangGraph、Dify 等框架的适用边界	对比框架时会说“不选什么”更加分

很多面试者能讲清框架用法，但回答不了“为什么这样设计”“失败时怎么办”。学习时要刻意练习从原理层面解释现象。

7.2 面试高频问题可以按这四条线准备

第一类是概念题，比如“Agent 和大模型应用的区别”“什么是 ReAct”“Function Calling 的实现原理”。第二类是设计题，比如“设计一个多智能体系统，如何避免两个 Agent 互相冲突”。第三类是排错题，比如“Agent 反复调用工具不收敛，怎么排查”。第四类是评测题，比如“如何设计测试集和评估指标”。

每类题都可以结合自己写过的代码举例。不要背理论，要准备一条完整链路：从任务、方案、代码、结果、踩坑、改进讲下来。

7.3 从 Demo 到可交付项目的检查清单

准备上线的智能体项目，建议逐项检查：

• 用户目标是否被明确拆解，不是所有输入都适合走完整 Agent 循环。
• 每个工具都有参数校验、超时、错误返回。
• 模型无需工具时能正常结束，不会死循环。
• 上下文有长度上限，超限有摘要或裁剪策略。
• 有测试集和评测指标，改代码前不靠“感觉变好了”。
• 线上日志可回放，能还原每一步模型输出和工具结果。
• 高权限工具禁止模型直接调用，需要用户确认。
• 有费用监控，单任务 token 消耗异常时能告警。

学习路径上，入门阶段最值得投入的一件事是：不依赖任何平台，手写一个像第 3 节那样的最小智能体循环。做过一次之后，再去看 Dify、Coze、LangGraph，会发现它们的节点、边、工具封装，其实都是在解决你已经亲手踩过的那些问题。

智能体背后没有神秘原理，它的工程部分才是真正的门槛。如果你能把一个最小循环做到稳定、可测、可回滚，再迁移到任何框架和平台上都会顺利很多。下一步的方向，可以从给这个最小 Demo 增加长期记忆、接入真实业务 API、完成一套回归测试开始，这三件事做完，智能体学习才算真正进入正轨。