这两年“Agent智能体”几乎成了 AI 圈和开发社区最热的关键词。但很多同学在实际学习时往往会遇到三种尴尬刷了一堆视频、收藏了几十个教程真到自己动手却不知道从哪写起照着别人的 demo 敲了一遍换一个业务场景就不知道怎么改项目明明能跑但一问 Token 成本、稳定性、权限控制当场哑火。这篇文章想解决的就是这三个问题。我会尽量不堆概念、不念 PPT而是把 Agent 智能体从原理、环境、开发框架到企业级落地拆成一条可以照着走的路径并且给出可直接运行的代码案例。不管你是刚开始接触 AI 应用开发还是已经写过不少 Prompt、准备深入 Agent 方向这篇文章都应该能帮你少踩几个坑。1. Agent智能体它到底是什么为什么突然火了1.1 从一个最简单的场景理解 Agent先抛开教科书定义从一个日常场景入手。假设你有一个助手你可以对它说“帮我查一下这周北京有哪些适合周末参加的技术沙龙顺便把其中评分最高的三个活动的报名链接整理成表格。”传统的聊天机器人会怎么做它只会生成一段文字告诉你“建议你去活动行、豆瓣同城上搜一搜”。至于到底有哪些活动、评分如何、链接是什么它一概不知道。Agent 智能体的做法是先把这个大任务拆成多个小步骤——先去搜索“北京 技术沙龙 周末”然后打开几个活动页面筛选评分信息再调用表格生成工具把结果整理出来。如果中间发现某个链接打不开它还能换一个渠道重新查。整个过程不需要你每一步都手动指令。说白了Agent 就是一个能自己规划、自己调用工具、自己根据结果调整行动的大模型应用形态。1.2 Agent 与传统程序、普通大模型的区别理解 Agent 的边界最好的方式是把它和另外两个概念放在一起对比。类型执行方式能否使用外部工具能否自主调整计划典型例子传统程序预定义逻辑可以直接调用 API不能代码写死分支订单管理系统、爬虫脚本普通大模型对话一次生成不能只能回复文本不能问一句答一句ChatGPT 网页版纯聊天Agent 智能体循环决策可以通过函数调用可以根据中间结果改变策略AutoGPT、Manus、企业客服 Agent这里的关键差异在于“循环决策”。传统程序是程序员预先走通了所有流程代码只是按照流程执行。Agent 则是大模型在运行时动态决定下一步要调用哪个工具、怎么调整输入参数具有一定的不可预测性。这种不可预测性既是亮点也是工程上的挑战。1.3 Agent 的典型应用场景从目前已经落地的项目来看Agent 智能体主要集中在以下几类场景企业知识库问答用户用自然语言提问Agent 从内部文档中检索资料、汇总答案并标注信息来源。自动化办公读取邮件、整理会议纪要、生成周报、操作 Excel这类任务很适合 Agent 串联多个办公工具。代码辅助开发根据 Issue 描述定位代码文件、修改代码、运行测试多步骤完成一个小需求。个人生活助理查天气、订机票、规划行程、比价购物。数据分析Agent 连接数据库把“帮我分析一下这个月各区域的销售额趋势”转换成 SQL查询后生成图表。这些场景的共同特点是步骤多、涉及外部工具、需要根据中间结果动态修正。这正是 Agent 的用武之地。2. 学习 Agent 前必须掌握的知识体系如果你之前没有接触过大模型开发不建议一上来就啃 Agent 框架。先花一点时间把下面几个基础概念弄明白学 Agent 会轻松很多。2.1 大模型 API 的基本调用Agent 的所有决策能力来自于大模型所以至少要知道怎么调用一个模型接口。目前主流的方式是调用 OpenAI 兼容格式的 API无论用什么模型请求结构都大同小异。# 核心示例调用 OpenAI 兼容接口 from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 也可以使用兼容服务 ) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: user, content: 用一句话解释什么是 Agent} ] ) print(resp.choices[0].message.content)这段代码里messages是对话历史model是模型名称api_key和base_url需要根据你使用的模型服务商修改。很多国产模型平台也提供 OpenAI 兼容接口所以这套代码可以复用。2.2 提示词工程Agent 的行为风格、边界约束、输出格式很大程度是靠提示词控制的。比如你要写一个客服 Agent提示词里至少应该明确三件事1. 你的身份XX公司智能客服 2. 任务边界只能回答公司产品相关问题其他问题请引导用户联系人工 3. 输出格式回答必须简洁不超过200字无法回答时统一回复“请联系人工客服”提示词不需要花哨但一定要把边界写清楚。很多 Agent 表现不稳定不是模型能力问题而是提示词里的约束不够明确。2.3 函数调用Function Calling / Tool Calling这是 Agent 技术里最关键的一块。所谓函数调用就是让大模型在生成回答时不只是输出文本而是输出一个“我决定调用某个工具”的结构化指令。你可以把模型理解成一个“决策者”把工具理解成它的“手脚”。例如模型可能会输出这样的 JSON{ name: search_web, arguments: {\query\: \2026年AI发展趋势\} }你的程序解析这个 JSON真正执行搜索然后把结果返回给模型模型再生成最终答案。整个流程组成一个循环。2.4 工作流与状态管理Agent 的每一次决策都会产生新状态调用了什么工具、拿到了什么结果、接下来该做什么。开发时你需要有“状态机”的思维当前处于什么阶段、下一步的输入是什么、异常时回退到哪里。很多同学写 Agent 失败就是因为只关注了单次对话没有考虑多轮循环状态的一致性。3. 环境准备与开发框架选择3.1 运行环境与开发语言Agent 开发目前使用最多的语言是 Python因为 AI 生态最成熟大模型 SDK、向量数据库、数据处理工具基本都是 Python 优先。建议环境如下Python 3.10 或更高版本pip 包管理器一个支持 OpenAI 兼容接口的大模型 API Key或者本地部署的模型服务终端工具用于安装依赖和调试如果你本地还没有 Python建议直接安装 Anaconda它会自带常见的科学计算库之后安装依赖会比较省心。3.2 主流 Agent 开发框架对比目前市面上框架很多但真正适合企业级开发的大家讨论最多的还是下面几个框架特点适合人群LangChain生态全、概念多、文档更新快想快速搭建原型不怕学概念的开发者LangGraph专注于状态图和可控流程适合复杂 Agent需要精确编排多步骤任务的团队MetaGPT / AutoGPT多角色协作、自动规划研究型项目、实验性质较多自研循环只用 OpenAI SDK 手写工具调用循环生产环境希望轻量可控的团队很多新手会在“选什么框架”上纠结很久。我的建议是如果你的目标是理解原理先从自研循环开始代码量不大但能让你彻底明白 Agent 每一步在干什么。等理解了原理再去看 LangChain 或 LangGraph会发现它们只是把你这套手写逻辑封装成了现成组件。3.3 一个最小项目结构无论用什么框架Agent 项目的目录大体可以这样组织agent-demo/ ├── agent/ │ ├── __init__.py │ ├── core.py # Agent 主循环 │ ├── tools.py # 工具定义 │ └── prompts.py # 提示词 ├── data/ # 知识库或测试数据 ├── tests/ # 测试用例 ├── requirements.txt └── .env # 环境变量存 API Key不要提交到仓库目录结构不需要很复杂但要职责分明。工具、提示词、主循环分开放后面排查问题时你会轻松很多。4. Agent 核心原理拆解4.1 ReAct 模式推理 行动ReAct 是目前 Agent 领域最经典的思维模式。它的全称是 Reasoning Acting意思是模型在每一步都先思考Reasoning再行动Acting观察结果后继续思考如此循环。思考用户想问北京天气我需要调用天气查询工具 行动调用 get_weather(city北京) 观察北京 晴25度 思考拿到了天气数据可以回答用户了 回答北京今天天气晴朗气温25度。在提示词层面你可以要求模型按照“思考 - 行动 - 观察”的结构来组织中间过程。在代码层面这个循环表现为把用户问题发送给模型模型返回文本内容或工具调用指令如果是工具调用执行对应函数把执行结果附加到对话历史中再次发送给模型重复直到模型不再调用工具4.2 任务拆解与规划复杂任务必须拆解。拆解的方式有两种一种是让模型一次性输出一个计划例如“步骤1搜索相关资料步骤2提取核心观点步骤3生成报告”。这种方式叫 Plan-then-Execute适合流程比较固定的任务。另一种是让模型每走一步才决定下一步这种方式就是前面说的 ReAct更灵活适合结果不确定的场景。在实际项目中建议在 Agent 的提示词里加入一段“任务拆解规则”比如如果用户请求涉及多个子任务请先输出完整的执行计划标明先后顺序。 预测到某一步可能失败时同时准备一个备选方案。这能显著降低 Agent 中途“卡死”的概率。4.3 记忆短期与长期Agent 的记忆分为两块短期记忆指当前会话中的上下文。模型能记住多少取决于上下文窗口大小也取决于你传了多少历史消息给他。企业级项目中通常还需要做“上下文压缩”把太长的历史改写成摘要节省 Token。长期记忆指持久化存储的业务知识和用户偏好。实现长期记忆的常见做法是把信息存入向量数据库当用户提问时检索最相关的片段堵在 Prompt 里。用户A偏好回复风格简洁喜欢看结论再看细节。这种长期记忆如果做得好Agent 的体验会非常个性化但也要注意隐私边界敏感信息需要脱敏存储。4.4 工具调用的工程细节工具调用是整个 Agent 里最容易出问题的地方有几个细节值得单独拿出来说。给工具写清晰描述。模型是靠工具的名字和描述来决定什么场景调用哪个工具的描述写得越清楚调用准确率越高。例如get_weather工具的描述可以写成根据城市名称查询实时天气情况输入参数为城市中文名例如“北京”。参数要校验。模型生成的参数不一定合法例如城市名可能传了 null日期格式可能不对。工具在执行前必须做参数校验避免把异常抛给用户。超时和限流。工具可能调用外部 API外部服务可能很慢。每一项工具调用都建议设置超时时间防止 Agent 因为一个工具卡死整个循环。4.5 多 Agent 协作当业务足够复杂时单一 Agent 会变得难以维护。这时候可以采用多 Agent 协作架构。常见的方式是“老板 员工”模式一个 Supervisor Agent 负责理解用户需求、分配任务下面挂多个子 Agent分别负责搜索、数据分析、内容生成、图片处理等最后再由 Supervisor 汇总结果。用户需求 Supervisor Agent |-- 搜索 Agent |-- 数据分析 Agent |-- 内容生成 Agent |-- 汇总结果 用户多 Agent 架构的好处是职责单一、便于独立优化和测试。代价是 Token 消耗会成倍上升管理复杂度也会明显增加。建议只在单 Agent 确实搞不定的场景下使用。5. 实战案例从零构建一个知识库问答 Agent下面进入动手环节。我们会用 Python 手写一个支持工具调用的 Agent它能根据用户的问题从内部知识库检索资料并且能查询城市天气最后整理成回答。5.1 需求分析这个 Agent 需要满足三个核心功能知识库检索给定一个知识库文档列表返回与用户问题最相关的片段。天气查询根据城市名称返回模拟天气数据。对话回答综合检索结果和工具返回结果生成最终回答。为了让代码尽量独立可运行知识库我用一个字典模拟不引入向量数据库重点展示 Agent 主循环的编写思路。5.2 安装依赖只需要两个依赖pip install openai python-dotenv5.3 配置环境变量在项目根目录创建.env文件OPENAI_API_KEYyour-api-key OPENAI_BASE_URLhttps://api.example.com/v1 MODEL_NAMEgpt-4o-mini注意.env文件千万不要提交到 Git 仓库。正确的做法是在.gitignore中加入.env。5.4 定义 Agent 工具集创建agent/tools.py实现知识库检索和天气查询两个工具# 文件路径agent/tools.py import json # 模拟知识库数据 KNOWLEDGE_BASE { Agent: Agent是能够感知环境、自主决策并执行动作的智能实体它借助大模型的推理能力完成复杂任务。, ReAct: ReAct是一种结合推理和行动的Agent设计模式模型先思考再行动观察结果后继续推理。, Function Calling: 函数调用允许大模型输出结构化指令以便外部程序执行API、数据库查询或代码操作。, RAG: RAG即检索增强生成先从外部知识库检索相关内容再交给大模型生成答案能有效减少幻觉。 } def search_knowledge(query: str) - str: 从知识库中检索与query相关的文档片段 results [] for key, value in KNOWLEDGE_BASE.items(): if key in query or query in value: results.append(f{key}: {value}) if not results: return 没有找到相关知识库内容 return \n.join(results) def get_weather(city: str) - str: 根据城市名称返回模拟天气信息 weather_data { 北京: 晴气温25℃东北风2级, 上海: 阴天气温23℃东南风3级, 广州: 雷阵雨气温27℃南风2级, } if city in weather_data: return f{city}今日天气{weather_data[city]} return f暂时没有城市{city}的天气数据请检查城市名称是否正确这里需要说明search_knowledge目前是一个简单的关键词匹配版本目的只是为了演示工具调用的流程。生产环境中这一步应该替换为向量数据库的相似度检索例如使用 Chroma、Milvus 或 Elasticsearch。5.5 定义模型可识别的工具 Schema接下来需要把工具信息转换为大模型能识别的格式也就是 Tools 列表。在agent/tools.py中新增# 文件路径agent/tools.py TOOLS [ { type: function, function: { name: search_knowledge, description: 在内部知识库中搜索与用户问题相关的资料回答知识类问题时必须调用这个工具, parameters: { type: object, properties: { query: { type: string, description: 用户问题中的核心关键词或完整问题 } }, required: [query] } } }, { type: function, function: { name: get_weather, description: 查询某个城市实时天气信息用于回答天气类问题, parameters: { type: object, properties: { city: { type: string, description: 城市中文名例如北京、上海 } }, required: [city] } } } ]这段 JSON 看起来长但结构非常规律就是告诉模型有什么工具、工具的用途是什么、参数怎么传。5.6 实现 Agent 主循环创建agent/core.py这是整个 Agent 的大脑# 文件路径agent/core.py import os import json from openai import OpenAI from dotenv import load_dotenv from agent.tools import TOOLS, search_knowledge, get_weather load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) ) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) # 工具路由表把模型返回的函数名映射到本地 Python 函数 TOOL_ROUTE { search_knowledge: search_knowledge, get_weather: get_weather, } def run_agent(user_input: str, max_rounds: int 5) - str: Agent 主循环 1. 将用户输入发送给模型 2. 如果模型调用了工具则执行工具并返回结果继续循环 3. 直到模型不再调用工具直接返回最终回答 messages [ { role: system, content: 你是一个智能助手能够调用工具解答用户问题。 如果用户的问题需要知识库或天气信息请先调用相关工具 再根据工具返回结果回答。回答要简洁、准确。 }, {role: user, content: user_input} ] for _ in range(max_rounds): response client.chat.completions.create( modelMODEL_NAME, messagesmessages, toolsTOOLS, ) message response.choices[0].message # 如果模型没有生成工具调用说明可以给出最终回答了 if not message.tool_calls: return message.content or 抱歉我暂时无法回答这个问题。 # 如果模型决定调用工具则把它变成一条 assistant 消息记录到上下文 messages.append({ role: assistant, content: message.content, tool_calls: [ { id: tool_call.id, type: function, function: { name: tool_call.function.name, arguments: tool_call.function.arguments } } for tool_call in message.tool_calls ] }) # 逐个执行工具调用 for tool_call in message.tool_calls: fn_name tool_call.function.name fn_route TOOL_ROUTE.get(fn_name) if fn_route is None: result json.dumps({error: f未知工具: {fn_name}}, ensure_asciiFalse) else: try: args json.loads(tool_call.function.arguments) result fn_route(**args) except Exception as e: result json.dumps({error: f工具执行出错: {str(e)}}, ensure_asciiFalse) # 把工具执行结果回传给模型 messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) return 运行轮数已达上限暂时无法完成你的请求。这个主循环有几个关键点需要理解assistant消息必须包含tool_calls信息否则模型不知道它之前调用过什么工具。每个工具调用结果通过role: tool和tool_call_id关联到具体的调用。max_rounds用来防止 Agent 无限循环这是一个非常实用的保护机制。5.7 编写启动入口创建main.py# 文件路径main.py from agent.core import run_agent if __name__ __main__: while True: user_input input(请输入你的问题输入 q 退出) if user_input.lower() q: break answer run_agent(user_input) print(\nAgent, answer, \n)5.8 运行与验证在项目根目录执行python main.py然后可以依次输入下面几个问题请输入你的问题什么是Agent 请输入你的问题北京今天天气如何 请输入你的问题帮我总结下什么是RAG预期结果大致是输入“什么是Agent”时Agent 会调用search_knowledge然后基于检索结果生成回答。输入“北京今天天气如何”时Agent 会调用get_weather然后返回天气信息。如果输入的问题不需要任何工具Agent 会直接回答。这个例子虽然简单但已经把 Agent 的核心循环跑通了。你后续要做的所有复杂功能本质上都是在这个循环里增加更多更强大的工具。6. 企业级 Agent 落地难点与进阶方案从 demo 到线上中间的距离往往比想象中大得多。下面这几点是我在实际工程中认为最值得关注的。6.1 从同步循环升级为异步任务本地 demo 用同步循环没有任何问题但放到线上一个 Agent 任务可能要运行几十秒甚至几分钟。如果用同步接口用户必须一直等待体验会很差。企业级方案通常分为两步把 Agent 任务封装成异步任务发布到消息队列或任务平台例如 Redis Queues、Celery、Temporal 等。前端通过轮询或 WebSocket 获取执行进度。任务状态的流转可以简化为用户提交任务 - 任务排队 - Agent 执行 - 结果生成 - 回调通知用户6.2 可观测性不要把 Agent 当黑盒Agent 最大的问题是不可预测。模型可能调用了一个不合适的工具可能陷入死循环也可能生成错误结论。如果整个执行过程没有任何日志出问题后根本无法排查。建议每次运行都记录以下信息用户原始输入模型每次回复的完整内容模型决定调用哪些工具参数是什么工具执行的原始返回值每一轮的耗时和 Token 消耗最终结果和运行轮数日志格式建议使用 JSON方便后续接入日志平台。可能的话还可以使用 LangSmith 或者 OpenTelemetry 这类工具做链路追踪。6.3 安全边界与权限控制Agent 能调用工具意味着它能执行搜索、发邮件、改数据库、调用支付接口。权限给得太大风险是灾难性的。工程上有几条必须遵守的底线最小权限原则每个 Agent 只分配完成当前任务最低限度的工具权限而不是把所有工具暴露给所有用户。敏感操作二次确认涉及支付、删除、批量修改、发送外部信息等操作应当由人工在界面上点击确认后才能真正执行。工具参数白名单外部传入的参数必须进行合法性校验例如邮箱格式、金额范围、城市名称列表不能盲目信任模型生成的参数。内容安全过滤对 Agent 生成的内容做合规过滤尤其是面向 C 端用户的产品。数据脱敏长期记忆里不能直接存储明文密码、身份证号等敏感信息。6.4 成本控制与性能优化Agent 的 Token 消耗比普通聊天要高得多尤其是多轮循环、长上下文、多 Agent 协作场景。成本优化可以从这几个角度入手模型降级先让便宜的小模型做意图识别和工具选择必要时再切换到大模型。上下文压缩当对话历史超过一定长度时使用摘要模型把历史压缩成短摘要。缓存用户问题相似度较高时可以命中缓存结果避免重复调用模型。限制轮数不要无限制让 Agent 循环通常超过 8 轮还解决不了的问题应该转人工。工具结果裁剪工具返回的数据可能非常长只保留关键字段节省后续轮次的 Token。6.5 Prompt 版本管理企业级开发中提示词和代码一样需要版本管理。改了一版 Prompt 导致线上效果异常是很常见的事。建议把提示词模板独立存放并加入 Git 管理。有条件的团队可以使用提示词管理平台对每个版本的 Prompt 做 A/B 测试。7. 常见问题与排查思路7.1 Agent 不调用工具问题现象可能原因解决思路用户问了需要工具的问题模型却直接回答工具描述不清楚在工具 description 中写明“必须调用”并举例说明触发条件模型只调用部分工具上下文历史缺少系统指令约束在 system prompt 中强制要求先调用工具再回答工具调用不生效API 版本或 messages 格式不对检查 assistant 消息中是否携带 tool_callstool 消息是否携带 tool_call_id这里最容易被忽略的是消息格式。很多同学打印出的 messages 结构不完整导致模型不知道上下文里发生过工具调用。7.2 Agent 陷入死循环问题现象可能原因解决思路Agent 反复调用同一个工具参数不变工具返回结果没有增加新信息检查工具返回值确保返回值足够丰富让模型能做下一步决策Agent 在多个工具之间来回跳目标不明确在提示词中规定任务的结束条件“当拿到XX信息后停止调用工具”整体运行时间过长单轮 Token 太大或模型响应慢限制最大轮数、缩短工具返回内容建议把max_rounds设置为 3 到 8不要给太长。7.3 模型生成的工具参数格式错误问题现象可能原因解决思路json.loads(tool_call.function.arguments)报错模型偶尔会返回非法 JSON用try/except捕获并加入参数解析失败后的自动重试逻辑参数类型不对例如城市传成数字工具 schema 没有写清楚参数描述在 parameters 的 description 中说明示例值并在执行前做类型校验参数多传或漏传schema 的 required 字段不完整明确 required 字段同时代码中对可选参数做默认值处理7.4 Token 消耗过高问题现象可能原因解决思路任务还没结束Token 就花完了没有做上下文压缩增加历史摘要机制工具返回了大量无关内容工具设计不合理对工具返回值做截断只保留摘要同一问题被反复处理缺少缓存对相似用户问题做缓存设置合理的相似度阈值7.5 知识库检索效果差问题现象可能原因解决思路检索不到相关知识关键词匹配太弱切换为向量检索并增加同义词改写检索到了但回答用不上上下文里塞了太多无关片段只保留 top K 片段K 一般取 3 到 5回答出现幻觉知识库没有该问题的答案在提示词中要求“未找到相关内容时明确告知”8. 最佳实践与学习路线8.1 工程规范结合前面几节的内容这里把 Agent 开发的关键规范汇总成一份清单方便你保存对照。工具职责单一。每个工具只做一件事不要写一个“超级工具”包含所有逻辑。工具描述写清楚触发场景。模型靠 description 决定是否调用描述质量直接决定准确率。所有外部 API 调用设置超时。不要让 Agent 因为一次超时卡住整个流程。对模型生成参数做二次校验。模型不可 100% 信任参数必须校验。主流程必须有最大轮数限制。防止死循环和恶意消耗。日志记录执行链路。保证每个决策可追溯。敏感操作必须人工确认。线上业务不要自动执行高风险动作。API Key 必须放环境变量或密钥管理平台。严禁写死在代码里并提交到仓库。上线前准备测试集。准备 20 到 50 条典型用户问题每次改动提示词后跑一遍回归测试。8.2 学习路线建议Agent 是一个实践性非常强的方向单纯看视频效果有限。如果你已经看完了这篇教程下一步建议按下面的路线推进。第一步把本文案例跑通并尝试增加一个新的工具例如查询快递、计算器或者数据库查询体会工具调用的完整流程。第二步给 Agent 加一个简单的召回功能把知识库替换成向量数据库了解 Embedding、相似度检索这些概念。第三步尝试用 LangGraph 把同样的案例实现一遍对比手写循环和框架实现各自的优劣。你会发现手写代码时理解的所有概念在框架里都能找到对应组件。第四步找一个小需求完整落地例如“公司内部的周报汇总 Agent”“自动读取邮件并归档的 Agent”。项目不需要大但要走完整流程需求分析、开发、测试、部署、日志监控。第五步深入研究一个领域例如多 Agent 协作、计划与反思机制、评估体系往专家方向发展。8.3 Agent 学习中的三个心态建议最后分享三点个人的真实感受。第一不要迷信“最强教程”。Agent 领域变化太快现在有效的方案可能三个月后就被更好的框架替代。真正保值的能力是理解底层原理也就是“模型如何决策、工具如何执行、状态如何流转”这三件事。第二不要盲目追新框架。框架层出不穷但核心思想大同小异。把手写循环吃透之后你学任何框架都会很快。第三把安全放在第一位。Agent 能调工具的属性决定了它的破坏力比普通聊天机器人高得多。做企业级项目时权限控制、人工确认、日志审计这些环节一步都不能省。希望这篇文章能帮你建立 Agent 智能体的系统认知也欢迎你在评论区分享自己开发 Agent 时遇到的坑一起把弯路走直。 Agent智能体开发实战：从核心原理到企业级落地
这两年“Agent智能体”几乎成了 AI 圈和开发社区最热的关键词。但很多同学在实际学习时往往会遇到三种尴尬刷了一堆视频、收藏了几十个教程真到自己动手却不知道从哪写起照着别人的 demo 敲了一遍换一个业务场景就不知道怎么改项目明明能跑但一问 Token 成本、稳定性、权限控制当场哑火。这篇文章想解决的就是这三个问题。我会尽量不堆概念、不念 PPT而是把 Agent 智能体从原理、环境、开发框架到企业级落地拆成一条可以照着走的路径并且给出可直接运行的代码案例。不管你是刚开始接触 AI 应用开发还是已经写过不少 Prompt、准备深入 Agent 方向这篇文章都应该能帮你少踩几个坑。1. Agent智能体它到底是什么为什么突然火了1.1 从一个最简单的场景理解 Agent先抛开教科书定义从一个日常场景入手。假设你有一个助手你可以对它说“帮我查一下这周北京有哪些适合周末参加的技术沙龙顺便把其中评分最高的三个活动的报名链接整理成表格。”传统的聊天机器人会怎么做它只会生成一段文字告诉你“建议你去活动行、豆瓣同城上搜一搜”。至于到底有哪些活动、评分如何、链接是什么它一概不知道。Agent 智能体的做法是先把这个大任务拆成多个小步骤——先去搜索“北京 技术沙龙 周末”然后打开几个活动页面筛选评分信息再调用表格生成工具把结果整理出来。如果中间发现某个链接打不开它还能换一个渠道重新查。整个过程不需要你每一步都手动指令。说白了Agent 就是一个能自己规划、自己调用工具、自己根据结果调整行动的大模型应用形态。1.2 Agent 与传统程序、普通大模型的区别理解 Agent 的边界最好的方式是把它和另外两个概念放在一起对比。类型执行方式能否使用外部工具能否自主调整计划典型例子传统程序预定义逻辑可以直接调用 API不能代码写死分支订单管理系统、爬虫脚本普通大模型对话一次生成不能只能回复文本不能问一句答一句ChatGPT 网页版纯聊天Agent 智能体循环决策可以通过函数调用可以根据中间结果改变策略AutoGPT、Manus、企业客服 Agent这里的关键差异在于“循环决策”。传统程序是程序员预先走通了所有流程代码只是按照流程执行。Agent 则是大模型在运行时动态决定下一步要调用哪个工具、怎么调整输入参数具有一定的不可预测性。这种不可预测性既是亮点也是工程上的挑战。1.3 Agent 的典型应用场景从目前已经落地的项目来看Agent 智能体主要集中在以下几类场景企业知识库问答用户用自然语言提问Agent 从内部文档中检索资料、汇总答案并标注信息来源。自动化办公读取邮件、整理会议纪要、生成周报、操作 Excel这类任务很适合 Agent 串联多个办公工具。代码辅助开发根据 Issue 描述定位代码文件、修改代码、运行测试多步骤完成一个小需求。个人生活助理查天气、订机票、规划行程、比价购物。数据分析Agent 连接数据库把“帮我分析一下这个月各区域的销售额趋势”转换成 SQL查询后生成图表。这些场景的共同特点是步骤多、涉及外部工具、需要根据中间结果动态修正。这正是 Agent 的用武之地。2. 学习 Agent 前必须掌握的知识体系如果你之前没有接触过大模型开发不建议一上来就啃 Agent 框架。先花一点时间把下面几个基础概念弄明白学 Agent 会轻松很多。2.1 大模型 API 的基本调用Agent 的所有决策能力来自于大模型所以至少要知道怎么调用一个模型接口。目前主流的方式是调用 OpenAI 兼容格式的 API无论用什么模型请求结构都大同小异。# 核心示例调用 OpenAI 兼容接口 from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.example.com/v1 # 也可以使用兼容服务 ) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: user, content: 用一句话解释什么是 Agent} ] ) print(resp.choices[0].message.content)这段代码里messages是对话历史model是模型名称api_key和base_url需要根据你使用的模型服务商修改。很多国产模型平台也提供 OpenAI 兼容接口所以这套代码可以复用。2.2 提示词工程Agent 的行为风格、边界约束、输出格式很大程度是靠提示词控制的。比如你要写一个客服 Agent提示词里至少应该明确三件事1. 你的身份XX公司智能客服 2. 任务边界只能回答公司产品相关问题其他问题请引导用户联系人工 3. 输出格式回答必须简洁不超过200字无法回答时统一回复“请联系人工客服”提示词不需要花哨但一定要把边界写清楚。很多 Agent 表现不稳定不是模型能力问题而是提示词里的约束不够明确。2.3 函数调用Function Calling / Tool Calling这是 Agent 技术里最关键的一块。所谓函数调用就是让大模型在生成回答时不只是输出文本而是输出一个“我决定调用某个工具”的结构化指令。你可以把模型理解成一个“决策者”把工具理解成它的“手脚”。例如模型可能会输出这样的 JSON{ name: search_web, arguments: {\query\: \2026年AI发展趋势\} }你的程序解析这个 JSON真正执行搜索然后把结果返回给模型模型再生成最终答案。整个流程组成一个循环。2.4 工作流与状态管理Agent 的每一次决策都会产生新状态调用了什么工具、拿到了什么结果、接下来该做什么。开发时你需要有“状态机”的思维当前处于什么阶段、下一步的输入是什么、异常时回退到哪里。很多同学写 Agent 失败就是因为只关注了单次对话没有考虑多轮循环状态的一致性。3. 环境准备与开发框架选择3.1 运行环境与开发语言Agent 开发目前使用最多的语言是 Python因为 AI 生态最成熟大模型 SDK、向量数据库、数据处理工具基本都是 Python 优先。建议环境如下Python 3.10 或更高版本pip 包管理器一个支持 OpenAI 兼容接口的大模型 API Key或者本地部署的模型服务终端工具用于安装依赖和调试如果你本地还没有 Python建议直接安装 Anaconda它会自带常见的科学计算库之后安装依赖会比较省心。3.2 主流 Agent 开发框架对比目前市面上框架很多但真正适合企业级开发的大家讨论最多的还是下面几个框架特点适合人群LangChain生态全、概念多、文档更新快想快速搭建原型不怕学概念的开发者LangGraph专注于状态图和可控流程适合复杂 Agent需要精确编排多步骤任务的团队MetaGPT / AutoGPT多角色协作、自动规划研究型项目、实验性质较多自研循环只用 OpenAI SDK 手写工具调用循环生产环境希望轻量可控的团队很多新手会在“选什么框架”上纠结很久。我的建议是如果你的目标是理解原理先从自研循环开始代码量不大但能让你彻底明白 Agent 每一步在干什么。等理解了原理再去看 LangChain 或 LangGraph会发现它们只是把你这套手写逻辑封装成了现成组件。3.3 一个最小项目结构无论用什么框架Agent 项目的目录大体可以这样组织agent-demo/ ├── agent/ │ ├── __init__.py │ ├── core.py # Agent 主循环 │ ├── tools.py # 工具定义 │ └── prompts.py # 提示词 ├── data/ # 知识库或测试数据 ├── tests/ # 测试用例 ├── requirements.txt └── .env # 环境变量存 API Key不要提交到仓库目录结构不需要很复杂但要职责分明。工具、提示词、主循环分开放后面排查问题时你会轻松很多。4. Agent 核心原理拆解4.1 ReAct 模式推理 行动ReAct 是目前 Agent 领域最经典的思维模式。它的全称是 Reasoning Acting意思是模型在每一步都先思考Reasoning再行动Acting观察结果后继续思考如此循环。思考用户想问北京天气我需要调用天气查询工具 行动调用 get_weather(city北京) 观察北京 晴25度 思考拿到了天气数据可以回答用户了 回答北京今天天气晴朗气温25度。在提示词层面你可以要求模型按照“思考 - 行动 - 观察”的结构来组织中间过程。在代码层面这个循环表现为把用户问题发送给模型模型返回文本内容或工具调用指令如果是工具调用执行对应函数把执行结果附加到对话历史中再次发送给模型重复直到模型不再调用工具4.2 任务拆解与规划复杂任务必须拆解。拆解的方式有两种一种是让模型一次性输出一个计划例如“步骤1搜索相关资料步骤2提取核心观点步骤3生成报告”。这种方式叫 Plan-then-Execute适合流程比较固定的任务。另一种是让模型每走一步才决定下一步这种方式就是前面说的 ReAct更灵活适合结果不确定的场景。在实际项目中建议在 Agent 的提示词里加入一段“任务拆解规则”比如如果用户请求涉及多个子任务请先输出完整的执行计划标明先后顺序。 预测到某一步可能失败时同时准备一个备选方案。这能显著降低 Agent 中途“卡死”的概率。4.3 记忆短期与长期Agent 的记忆分为两块短期记忆指当前会话中的上下文。模型能记住多少取决于上下文窗口大小也取决于你传了多少历史消息给他。企业级项目中通常还需要做“上下文压缩”把太长的历史改写成摘要节省 Token。长期记忆指持久化存储的业务知识和用户偏好。实现长期记忆的常见做法是把信息存入向量数据库当用户提问时检索最相关的片段堵在 Prompt 里。用户A偏好回复风格简洁喜欢看结论再看细节。这种长期记忆如果做得好Agent 的体验会非常个性化但也要注意隐私边界敏感信息需要脱敏存储。4.4 工具调用的工程细节工具调用是整个 Agent 里最容易出问题的地方有几个细节值得单独拿出来说。给工具写清晰描述。模型是靠工具的名字和描述来决定什么场景调用哪个工具的描述写得越清楚调用准确率越高。例如get_weather工具的描述可以写成根据城市名称查询实时天气情况输入参数为城市中文名例如“北京”。参数要校验。模型生成的参数不一定合法例如城市名可能传了 null日期格式可能不对。工具在执行前必须做参数校验避免把异常抛给用户。超时和限流。工具可能调用外部 API外部服务可能很慢。每一项工具调用都建议设置超时时间防止 Agent 因为一个工具卡死整个循环。4.5 多 Agent 协作当业务足够复杂时单一 Agent 会变得难以维护。这时候可以采用多 Agent 协作架构。常见的方式是“老板 员工”模式一个 Supervisor Agent 负责理解用户需求、分配任务下面挂多个子 Agent分别负责搜索、数据分析、内容生成、图片处理等最后再由 Supervisor 汇总结果。用户需求 Supervisor Agent |-- 搜索 Agent |-- 数据分析 Agent |-- 内容生成 Agent |-- 汇总结果 用户多 Agent 架构的好处是职责单一、便于独立优化和测试。代价是 Token 消耗会成倍上升管理复杂度也会明显增加。建议只在单 Agent 确实搞不定的场景下使用。5. 实战案例从零构建一个知识库问答 Agent下面进入动手环节。我们会用 Python 手写一个支持工具调用的 Agent它能根据用户的问题从内部知识库检索资料并且能查询城市天气最后整理成回答。5.1 需求分析这个 Agent 需要满足三个核心功能知识库检索给定一个知识库文档列表返回与用户问题最相关的片段。天气查询根据城市名称返回模拟天气数据。对话回答综合检索结果和工具返回结果生成最终回答。为了让代码尽量独立可运行知识库我用一个字典模拟不引入向量数据库重点展示 Agent 主循环的编写思路。5.2 安装依赖只需要两个依赖pip install openai python-dotenv5.3 配置环境变量在项目根目录创建.env文件OPENAI_API_KEYyour-api-key OPENAI_BASE_URLhttps://api.example.com/v1 MODEL_NAMEgpt-4o-mini注意.env文件千万不要提交到 Git 仓库。正确的做法是在.gitignore中加入.env。5.4 定义 Agent 工具集创建agent/tools.py实现知识库检索和天气查询两个工具# 文件路径agent/tools.py import json # 模拟知识库数据 KNOWLEDGE_BASE { Agent: Agent是能够感知环境、自主决策并执行动作的智能实体它借助大模型的推理能力完成复杂任务。, ReAct: ReAct是一种结合推理和行动的Agent设计模式模型先思考再行动观察结果后继续推理。, Function Calling: 函数调用允许大模型输出结构化指令以便外部程序执行API、数据库查询或代码操作。, RAG: RAG即检索增强生成先从外部知识库检索相关内容再交给大模型生成答案能有效减少幻觉。 } def search_knowledge(query: str) - str: 从知识库中检索与query相关的文档片段 results [] for key, value in KNOWLEDGE_BASE.items(): if key in query or query in value: results.append(f{key}: {value}) if not results: return 没有找到相关知识库内容 return \n.join(results) def get_weather(city: str) - str: 根据城市名称返回模拟天气信息 weather_data { 北京: 晴气温25℃东北风2级, 上海: 阴天气温23℃东南风3级, 广州: 雷阵雨气温27℃南风2级, } if city in weather_data: return f{city}今日天气{weather_data[city]} return f暂时没有城市{city}的天气数据请检查城市名称是否正确这里需要说明search_knowledge目前是一个简单的关键词匹配版本目的只是为了演示工具调用的流程。生产环境中这一步应该替换为向量数据库的相似度检索例如使用 Chroma、Milvus 或 Elasticsearch。5.5 定义模型可识别的工具 Schema接下来需要把工具信息转换为大模型能识别的格式也就是 Tools 列表。在agent/tools.py中新增# 文件路径agent/tools.py TOOLS [ { type: function, function: { name: search_knowledge, description: 在内部知识库中搜索与用户问题相关的资料回答知识类问题时必须调用这个工具, parameters: { type: object, properties: { query: { type: string, description: 用户问题中的核心关键词或完整问题 } }, required: [query] } } }, { type: function, function: { name: get_weather, description: 查询某个城市实时天气信息用于回答天气类问题, parameters: { type: object, properties: { city: { type: string, description: 城市中文名例如北京、上海 } }, required: [city] } } } ]这段 JSON 看起来长但结构非常规律就是告诉模型有什么工具、工具的用途是什么、参数怎么传。5.6 实现 Agent 主循环创建agent/core.py这是整个 Agent 的大脑# 文件路径agent/core.py import os import json from openai import OpenAI from dotenv import load_dotenv from agent.tools import TOOLS, search_knowledge, get_weather load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) ) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) # 工具路由表把模型返回的函数名映射到本地 Python 函数 TOOL_ROUTE { search_knowledge: search_knowledge, get_weather: get_weather, } def run_agent(user_input: str, max_rounds: int 5) - str: Agent 主循环 1. 将用户输入发送给模型 2. 如果模型调用了工具则执行工具并返回结果继续循环 3. 直到模型不再调用工具直接返回最终回答 messages [ { role: system, content: 你是一个智能助手能够调用工具解答用户问题。 如果用户的问题需要知识库或天气信息请先调用相关工具 再根据工具返回结果回答。回答要简洁、准确。 }, {role: user, content: user_input} ] for _ in range(max_rounds): response client.chat.completions.create( modelMODEL_NAME, messagesmessages, toolsTOOLS, ) message response.choices[0].message # 如果模型没有生成工具调用说明可以给出最终回答了 if not message.tool_calls: return message.content or 抱歉我暂时无法回答这个问题。 # 如果模型决定调用工具则把它变成一条 assistant 消息记录到上下文 messages.append({ role: assistant, content: message.content, tool_calls: [ { id: tool_call.id, type: function, function: { name: tool_call.function.name, arguments: tool_call.function.arguments } } for tool_call in message.tool_calls ] }) # 逐个执行工具调用 for tool_call in message.tool_calls: fn_name tool_call.function.name fn_route TOOL_ROUTE.get(fn_name) if fn_route is None: result json.dumps({error: f未知工具: {fn_name}}, ensure_asciiFalse) else: try: args json.loads(tool_call.function.arguments) result fn_route(**args) except Exception as e: result json.dumps({error: f工具执行出错: {str(e)}}, ensure_asciiFalse) # 把工具执行结果回传给模型 messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) return 运行轮数已达上限暂时无法完成你的请求。这个主循环有几个关键点需要理解assistant消息必须包含tool_calls信息否则模型不知道它之前调用过什么工具。每个工具调用结果通过role: tool和tool_call_id关联到具体的调用。max_rounds用来防止 Agent 无限循环这是一个非常实用的保护机制。5.7 编写启动入口创建main.py# 文件路径main.py from agent.core import run_agent if __name__ __main__: while True: user_input input(请输入你的问题输入 q 退出) if user_input.lower() q: break answer run_agent(user_input) print(\nAgent, answer, \n)5.8 运行与验证在项目根目录执行python main.py然后可以依次输入下面几个问题请输入你的问题什么是Agent 请输入你的问题北京今天天气如何 请输入你的问题帮我总结下什么是RAG预期结果大致是输入“什么是Agent”时Agent 会调用search_knowledge然后基于检索结果生成回答。输入“北京今天天气如何”时Agent 会调用get_weather然后返回天气信息。如果输入的问题不需要任何工具Agent 会直接回答。这个例子虽然简单但已经把 Agent 的核心循环跑通了。你后续要做的所有复杂功能本质上都是在这个循环里增加更多更强大的工具。6. 企业级 Agent 落地难点与进阶方案从 demo 到线上中间的距离往往比想象中大得多。下面这几点是我在实际工程中认为最值得关注的。6.1 从同步循环升级为异步任务本地 demo 用同步循环没有任何问题但放到线上一个 Agent 任务可能要运行几十秒甚至几分钟。如果用同步接口用户必须一直等待体验会很差。企业级方案通常分为两步把 Agent 任务封装成异步任务发布到消息队列或任务平台例如 Redis Queues、Celery、Temporal 等。前端通过轮询或 WebSocket 获取执行进度。任务状态的流转可以简化为用户提交任务 - 任务排队 - Agent 执行 - 结果生成 - 回调通知用户6.2 可观测性不要把 Agent 当黑盒Agent 最大的问题是不可预测。模型可能调用了一个不合适的工具可能陷入死循环也可能生成错误结论。如果整个执行过程没有任何日志出问题后根本无法排查。建议每次运行都记录以下信息用户原始输入模型每次回复的完整内容模型决定调用哪些工具参数是什么工具执行的原始返回值每一轮的耗时和 Token 消耗最终结果和运行轮数日志格式建议使用 JSON方便后续接入日志平台。可能的话还可以使用 LangSmith 或者 OpenTelemetry 这类工具做链路追踪。6.3 安全边界与权限控制Agent 能调用工具意味着它能执行搜索、发邮件、改数据库、调用支付接口。权限给得太大风险是灾难性的。工程上有几条必须遵守的底线最小权限原则每个 Agent 只分配完成当前任务最低限度的工具权限而不是把所有工具暴露给所有用户。敏感操作二次确认涉及支付、删除、批量修改、发送外部信息等操作应当由人工在界面上点击确认后才能真正执行。工具参数白名单外部传入的参数必须进行合法性校验例如邮箱格式、金额范围、城市名称列表不能盲目信任模型生成的参数。内容安全过滤对 Agent 生成的内容做合规过滤尤其是面向 C 端用户的产品。数据脱敏长期记忆里不能直接存储明文密码、身份证号等敏感信息。6.4 成本控制与性能优化Agent 的 Token 消耗比普通聊天要高得多尤其是多轮循环、长上下文、多 Agent 协作场景。成本优化可以从这几个角度入手模型降级先让便宜的小模型做意图识别和工具选择必要时再切换到大模型。上下文压缩当对话历史超过一定长度时使用摘要模型把历史压缩成短摘要。缓存用户问题相似度较高时可以命中缓存结果避免重复调用模型。限制轮数不要无限制让 Agent 循环通常超过 8 轮还解决不了的问题应该转人工。工具结果裁剪工具返回的数据可能非常长只保留关键字段节省后续轮次的 Token。6.5 Prompt 版本管理企业级开发中提示词和代码一样需要版本管理。改了一版 Prompt 导致线上效果异常是很常见的事。建议把提示词模板独立存放并加入 Git 管理。有条件的团队可以使用提示词管理平台对每个版本的 Prompt 做 A/B 测试。7. 常见问题与排查思路7.1 Agent 不调用工具问题现象可能原因解决思路用户问了需要工具的问题模型却直接回答工具描述不清楚在工具 description 中写明“必须调用”并举例说明触发条件模型只调用部分工具上下文历史缺少系统指令约束在 system prompt 中强制要求先调用工具再回答工具调用不生效API 版本或 messages 格式不对检查 assistant 消息中是否携带 tool_callstool 消息是否携带 tool_call_id这里最容易被忽略的是消息格式。很多同学打印出的 messages 结构不完整导致模型不知道上下文里发生过工具调用。7.2 Agent 陷入死循环问题现象可能原因解决思路Agent 反复调用同一个工具参数不变工具返回结果没有增加新信息检查工具返回值确保返回值足够丰富让模型能做下一步决策Agent 在多个工具之间来回跳目标不明确在提示词中规定任务的结束条件“当拿到XX信息后停止调用工具”整体运行时间过长单轮 Token 太大或模型响应慢限制最大轮数、缩短工具返回内容建议把max_rounds设置为 3 到 8不要给太长。7.3 模型生成的工具参数格式错误问题现象可能原因解决思路json.loads(tool_call.function.arguments)报错模型偶尔会返回非法 JSON用try/except捕获并加入参数解析失败后的自动重试逻辑参数类型不对例如城市传成数字工具 schema 没有写清楚参数描述在 parameters 的 description 中说明示例值并在执行前做类型校验参数多传或漏传schema 的 required 字段不完整明确 required 字段同时代码中对可选参数做默认值处理7.4 Token 消耗过高问题现象可能原因解决思路任务还没结束Token 就花完了没有做上下文压缩增加历史摘要机制工具返回了大量无关内容工具设计不合理对工具返回值做截断只保留摘要同一问题被反复处理缺少缓存对相似用户问题做缓存设置合理的相似度阈值7.5 知识库检索效果差问题现象可能原因解决思路检索不到相关知识关键词匹配太弱切换为向量检索并增加同义词改写检索到了但回答用不上上下文里塞了太多无关片段只保留 top K 片段K 一般取 3 到 5回答出现幻觉知识库没有该问题的答案在提示词中要求“未找到相关内容时明确告知”8. 最佳实践与学习路线8.1 工程规范结合前面几节的内容这里把 Agent 开发的关键规范汇总成一份清单方便你保存对照。工具职责单一。每个工具只做一件事不要写一个“超级工具”包含所有逻辑。工具描述写清楚触发场景。模型靠 description 决定是否调用描述质量直接决定准确率。所有外部 API 调用设置超时。不要让 Agent 因为一次超时卡住整个流程。对模型生成参数做二次校验。模型不可 100% 信任参数必须校验。主流程必须有最大轮数限制。防止死循环和恶意消耗。日志记录执行链路。保证每个决策可追溯。敏感操作必须人工确认。线上业务不要自动执行高风险动作。API Key 必须放环境变量或密钥管理平台。严禁写死在代码里并提交到仓库。上线前准备测试集。准备 20 到 50 条典型用户问题每次改动提示词后跑一遍回归测试。8.2 学习路线建议Agent 是一个实践性非常强的方向单纯看视频效果有限。如果你已经看完了这篇教程下一步建议按下面的路线推进。第一步把本文案例跑通并尝试增加一个新的工具例如查询快递、计算器或者数据库查询体会工具调用的完整流程。第二步给 Agent 加一个简单的召回功能把知识库替换成向量数据库了解 Embedding、相似度检索这些概念。第三步尝试用 LangGraph 把同样的案例实现一遍对比手写循环和框架实现各自的优劣。你会发现手写代码时理解的所有概念在框架里都能找到对应组件。第四步找一个小需求完整落地例如“公司内部的周报汇总 Agent”“自动读取邮件并归档的 Agent”。项目不需要大但要走完整流程需求分析、开发、测试、部署、日志监控。第五步深入研究一个领域例如多 Agent 协作、计划与反思机制、评估体系往专家方向发展。8.3 Agent 学习中的三个心态建议最后分享三点个人的真实感受。第一不要迷信“最强教程”。Agent 领域变化太快现在有效的方案可能三个月后就被更好的框架替代。真正保值的能力是理解底层原理也就是“模型如何决策、工具如何执行、状态如何流转”这三件事。第二不要盲目追新框架。框架层出不穷但核心思想大同小异。把手写循环吃透之后你学任何框架都会很快。第三把安全放在第一位。Agent 能调工具的属性决定了它的破坏力比普通聊天机器人高得多。做企业级项目时权限控制、人工确认、日志审计这些环节一步都不能省。希望这篇文章能帮你建立 Agent 智能体的系统认知也欢迎你在评论区分享自己开发 Agent 时遇到的坑一起把弯路走直。