前言Chatbot 只会聊天Agent 会调用工具、拆解任务、自己纠错。这一波 AI 应用落地的核心就是 Agent。这篇不讲虚的讲清楚Agent 的循环结构、Function Calling 的机制和工程上必须处理的问题。一、Agent 的组成一个 Agent 通常包含四部分表格组件作用LLM大脑理解任务、决策下一步Tools工具搜索、执行代码、查数据库、发请求Memory记忆短期上下文 长期知识Planning规划任务拆解、反思、调整策略和普通 workflow 的区别workflow 是固定流程Agent 是模型自己决定下一步做什么。二、核心循环ReActReAct Reason推理 Act行动是绝大多数 Agent 的基础模式循环Thought模型思考当前该做什么Action调用某个工具给出参数Observation拿到工具返回结果重复以上直到模型认为任务完成伪代码def run_agent(task, tools, max_steps10): messages [{role: user, content: task}] for _ in range(max_steps): resp llm.chat(messages, toolstools) # 模型决定行动 if not resp.tool_calls: # 不再调工具 给答案了 return resp.content for call in resp.tool_calls: result execute(call.name, call.arguments) # 宿主执行 messages.append({role: tool, content: result, tool_call_id: call.id}) return 达到最大步数任务未完成三、Function Calling模型不执行只「申请」这是最容易误解的一点你在请求里提供工具列表名称、描述、JSON Schema 参数模型判断需要工具时返回结构化的 tool_calls—— 只是申请不执行你的代码真正执行工具把结果以 role: tool 的消息回填给模型模型基于结果继续工具定义示例{ name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名如 杭州} }, required: [city] } }安全边界在于执行权始终在宿主程序手里模型只能提请求。这决定了权限控制、沙箱、人工确认都放在宿主侧。四、工具设计原则决定 Agent 成功率工具写得好不好比模型选哪个更影响效果单一职责一个工具只做一件事别搞「万能执行器」描述写清楚模型靠 description 选工具写清什么场景用、参数含义、返回什么参数少而必填明确参数越多模型越容易传错错误信息对模型友好返回「city 不能为空请提供城市名」而不是 KeyError工具幂等模型可能重复调用删除 / 支付类操作必须防重控制返回体积工具返回几千行内容会撑爆上下文只回摘要五、记忆机制表格类型实现用途短期记忆对话 messages 列表受上下文窗口限制当前任务状态长期记忆向量库检索历史 / 知识跨会话记住用户偏好上下文压缩让 LLM 总结旧对话替换原文长任务防止超窗口工程重点上下文不是越多越好塞满后模型注意力会稀释主动摘要比无脑拼接更有效。六、规划与反思Plan-and-Execute先让模型出完整计划再逐步执行 —— 适合步骤明确的长任务ReAct边想边做 —— 适合探索型任务Reflection反思执行失败后让模型检查「哪里错了、怎么改」再重试一次能明显提升成功率成本是 token 翻倍七、可靠性工程面试加分项Agent 最大的问题是不稳定工程上必须兜底最大步数限制防止死循环烧钱设 max_steps超时与重试每次工具调用设 timeout失败有限次重试人工确认Human-in-the-loop高风险操作转账、删数据必须人工确认权限最小化工具只开必要权限代码执行放沙箱全链路 trace记录每步的 thought/action/observation否则出问题无法排查成本控制统计 token 消耗长任务考虑换小模型做简单判断八、怎么评估一个 Agent表格指标含义任务成功率端到端完成比例最重要平均步数步数越多越慢越贵工具调用准确率选对工具、传对参数的比例单任务成本token 消耗没有评测集就没法优化 —— 和 RAG 一样先量化。九、常见坑工具描述含糊模型乱选工具工具返回超长文本几轮后上下文爆掉没有最大步数陷入「调工具→失败→再调」死循环让模型直接执行危险操作没有人工确认只测「正常路径」异常分支工具报错、返回空没兜底模型说「已完成」但实际没完成缺少结果校验十、总结与学习路线记住三层循环ReAct→ 工具Function Calling 好的 Schema→ 兜底步数、超时、确认、日志。建议路线用任意 LLM API 实现一个 3 工具的小 Agent计算器 搜索 文件读写加最大步数和 trace 日志用 20 条任务建一个评测集统计成功率再尝试加反思机制对比前后成功率如果这篇对你有帮助点个赞支持一下。后续更新「手把手用 Python 写一个最小可用 Agent」。
前言Chatbot 只会聊天Agent 会调用工具、拆解任务、自己纠错。这一波 AI 应用落地的核心就是 Agent。这篇不讲虚的讲清楚Agent 的循环结构、Function Calling 的机制和工程上必须处理的问题。一、Agent 的组成一个 Agent 通常包含四部分表格组件作用LLM大脑理解任务、决策下一步Tools工具搜索、执行代码、查数据库、发请求Memory记忆短期上下文 长期知识Planning规划任务拆解、反思、调整策略和普通 workflow 的区别workflow 是固定流程Agent 是模型自己决定下一步做什么。二、核心循环ReActReAct Reason推理 Act行动是绝大多数 Agent 的基础模式循环Thought模型思考当前该做什么Action调用某个工具给出参数Observation拿到工具返回结果重复以上直到模型认为任务完成伪代码def run_agent(task, tools, max_steps10): messages [{role: user, content: task}] for _ in range(max_steps): resp llm.chat(messages, toolstools) # 模型决定行动 if not resp.tool_calls: # 不再调工具 给答案了 return resp.content for call in resp.tool_calls: result execute(call.name, call.arguments) # 宿主执行 messages.append({role: tool, content: result, tool_call_id: call.id}) return 达到最大步数任务未完成三、Function Calling模型不执行只「申请」这是最容易误解的一点你在请求里提供工具列表名称、描述、JSON Schema 参数模型判断需要工具时返回结构化的 tool_calls—— 只是申请不执行你的代码真正执行工具把结果以 role: tool 的消息回填给模型模型基于结果继续工具定义示例{ name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名如 杭州} }, required: [city] } }安全边界在于执行权始终在宿主程序手里模型只能提请求。这决定了权限控制、沙箱、人工确认都放在宿主侧。四、工具设计原则决定 Agent 成功率工具写得好不好比模型选哪个更影响效果单一职责一个工具只做一件事别搞「万能执行器」描述写清楚模型靠 description 选工具写清什么场景用、参数含义、返回什么参数少而必填明确参数越多模型越容易传错错误信息对模型友好返回「city 不能为空请提供城市名」而不是 KeyError工具幂等模型可能重复调用删除 / 支付类操作必须防重控制返回体积工具返回几千行内容会撑爆上下文只回摘要五、记忆机制表格类型实现用途短期记忆对话 messages 列表受上下文窗口限制当前任务状态长期记忆向量库检索历史 / 知识跨会话记住用户偏好上下文压缩让 LLM 总结旧对话替换原文长任务防止超窗口工程重点上下文不是越多越好塞满后模型注意力会稀释主动摘要比无脑拼接更有效。六、规划与反思Plan-and-Execute先让模型出完整计划再逐步执行 —— 适合步骤明确的长任务ReAct边想边做 —— 适合探索型任务Reflection反思执行失败后让模型检查「哪里错了、怎么改」再重试一次能明显提升成功率成本是 token 翻倍七、可靠性工程面试加分项Agent 最大的问题是不稳定工程上必须兜底最大步数限制防止死循环烧钱设 max_steps超时与重试每次工具调用设 timeout失败有限次重试人工确认Human-in-the-loop高风险操作转账、删数据必须人工确认权限最小化工具只开必要权限代码执行放沙箱全链路 trace记录每步的 thought/action/observation否则出问题无法排查成本控制统计 token 消耗长任务考虑换小模型做简单判断八、怎么评估一个 Agent表格指标含义任务成功率端到端完成比例最重要平均步数步数越多越慢越贵工具调用准确率选对工具、传对参数的比例单任务成本token 消耗没有评测集就没法优化 —— 和 RAG 一样先量化。九、常见坑工具描述含糊模型乱选工具工具返回超长文本几轮后上下文爆掉没有最大步数陷入「调工具→失败→再调」死循环让模型直接执行危险操作没有人工确认只测「正常路径」异常分支工具报错、返回空没兜底模型说「已完成」但实际没完成缺少结果校验十、总结与学习路线记住三层循环ReAct→ 工具Function Calling 好的 Schema→ 兜底步数、超时、确认、日志。建议路线用任意 LLM API 实现一个 3 工具的小 Agent计算器 搜索 文件读写加最大步数和 trace 日志用 20 条任务建一个评测集统计成功率再尝试加反思机制对比前后成功率如果这篇对你有帮助点个赞支持一下。后续更新「手把手用 Python 写一个最小可用 Agent」。
