AI 学习路线 09：Agent 智能体是什么？从工具调用到企业级场景验证

AI 学习路线 09Agent 智能体是什么从工具调用到企业级场景验证前言前面两篇我们学了 Prompt Engineering 和 RAG。Prompt Engineering 解决的是怎么把任务说清楚让模型更稳定地输出。RAG 解决的是怎么让模型先查资料再基于资料回答。到了真实业务里你很快会遇到更进一步的问题很多任务不只是“回答”而是要“办事”。比如帮我排查推理服务为什么延迟升高。 帮我处理一个客户重复扣费工单。 帮我根据日志定位项目构建失败原因。 帮我生成一份告警处理建议并标出需要人工确认的动作。这类任务通常需要多步骤、工具调用、结果观察、风险判断和人工审批。这就是 Agent 智能体要讨论的问题。这篇文章重点讲 8 件事Agent 和普通聊天机器人的区别。Agent 的行动闭环目标、计划、行动、观察、调整。工具调用为什么是 Agent 的核心能力。规划、记忆、观察、反思分别解决什么问题。企业场景里哪些任务适合 Agent。工作流 Agent 和自主 Agent 怎么取舍。多 Agent、安全边界和评估方法。用 Python 写一个最小企业级 Agent demo。一、Agent 到底是什么Agent 可以先用一句话理解Agent 是一个能围绕目标进行计划、调用工具、观察结果并继续行动的 AI 系统。普通聊天机器人更像“顾问”。你问它一个问题它给你一个答案。Agent 更像“会办事的助手”。你给它一个目标它会尝试拆步骤、用工具、看结果、继续推进。例如你说这个项目启动报错了帮我处理一下。普通聊天机器人可能会解释报错含义。Agent 可以进一步做1. 读取启动日志。 2. 搜索相关配置文件。 3. 判断是依赖问题、配置问题还是代码问题。 4. 修改配置或代码。 5. 重新启动或运行测试。 6. 总结问题原因、改动内容和剩余风险。所以 Agent 的关键不是“更会聊天”而是能围绕目标采取行动。二、Agent 的行动闭环Agent 不是一次回答结束而是一个循环目标 - 计划 - 行动 - 观察 - 调整 - 继续行动举个运维场景目标排查推理服务延迟升高。Agent 可以这样工作阶段行动目标用户要求排查推理服务延迟升高计划先查监控再查发布再查日志行动调用监控接口、发布记录接口、日志接口观察发现 GPU 使用率 94%近期模型路由变更调整不直接重启服务而是建议限流和人工确认回滚交付输出证据、结论、建议和风险边界这里有两个重点。第一Agent 需要工具。没有工具它只能“猜”。第二Agent 需要观察结果。否则它不知道工具有没有成功、数据是否足够、下一步该继续还是停止。三、工具调用Agent 能办事的关键大模型本身擅长理解、生成和推理但它不能天然做到查数据库。读文件。跑代码。发邮件。查监控。创建工单。调用业务接口。要让 Agent 真的办事就要给它工具。工具调用的基本流程是用户目标 - 模型判断要用哪个工具 - 模型填写工具参数 - 程序校验权限和参数 - 程序执行工具 - 工具返回结果 - 模型基于结果继续回答或继续行动例如用户说帮我查一下昨天 GPU 使用率最高的任务。模型可能生成一个工具调用意图{tool:query_metrics,arguments:{metric:gpu_utilization,time_range:yesterday,group_by:job_id,order:desc,limit:5}}注意模型输出调用意图不代表工具已经执行成功。真正执行工具的是外部程序。这就是为什么企业 Agent 必须做工具白名单。参数 schema 校验。用户权限校验。工具调用日志。调用次数限制。高风险动作审批。失败重试和兜底。只靠 Prompt 写一句“不要越权调用工具”是不够的。Prompt 是软约束接口权限才是硬约束。四、规划、记忆、观察和反思一个 Agent 要稳定完成复杂任务通常需要四类能力规划先把目标拆成步骤。 记忆记住当前任务需要的信息。 观察读取工具执行结果。 反思检查目标是否完成。例如研发 Agent 接到任务帮我修复登录接口偶发 500 的问题。它不能一上来就乱改代码而应该先规划1. 查看最近错误日志。 2. 找到登录接口代码。 3. 查看最近相关提交。 4. 判断 500 原因。 5. 修改代码。 6. 运行测试。 7. 总结原因和修复内容。短期记忆用于保存当前任务上下文目标是修复登录 500。 日志里出现 token 为空。 登录接口文件是 AuthController.cs。 刚才测试失败在 TokenValidator。观察用于判断工具结果测试通过可以总结。 测试失败继续定位。 权限不足停止并说明需要授权。 工具超时重试或请求人工介入。反思用于检查目标是否完成 证据是否充分 测试是否跑过 风险是否说明 是否还有未完成项这四个词可以这样记规划 先想怎么做 记忆 记住做到哪 观察 看做成没有 反思 检查够不够五、企业里哪些场景适合 Agent不是所有 AI 应用都要做成 Agent。判断一个场景是否适合 Agent可以看四个条件目标是否清楚 工具是否可靠 结果是否可验证 风险是否可控场景一运维排查 Agent适合先做成只读分析型 Agent。它可以自动查监控。查日志。查最近发布记录。查异常任务。生成排查结论。给处理建议。但不应该默认自动重启生产服务。回滚版本。删除任务。修改线上配置。扩容大量资源。原因很简单查询是低风险动作生产变更是高风险动作。场景二研发辅助 Agent研发 Agent 适合读取日志。搜索代码。修改小范围问题。运行测试。总结修复内容。但不适合一上来就全自动重构核心架构。场景三客服工单 Agent客服 Agent 可以总结用户问题。查询订单和历史工单。匹配处理规则。生成回复草稿。判断是否需要升级人工。但退款、改订单、对外承诺这类真实业务动作需要严格审批。场景四知识库办事助手RAG 可以回答这个制度怎么说Agent 可以进一步处理根据制度、用户信息和申请内容判断这个申请是否符合规则并生成审批意见。RAG 偏“查资料并回答”Agent 偏“结合资料、工具和流程去办事”。六、工作流 Agent 与自主 AgentAgent 不只有一种形态。最常见的区分是工作流 Agent流程相对固定模型在关键节点做判断。 自主 Agent目标给定后模型有更大自由度动态规划和行动。以运维排查为例。工作流 Agent 的流程可能是固定的1. 收到告警。 2. 查询监控指标。 3. 查询最近发布记录。 4. 查询错误日志。 5. 判断问题类型。 6. 生成处理建议。 7. 高风险动作转人工确认。自主 Agent 则可能只收到一个目标帮我调查为什么推理服务延迟升高。然后它自己决定先查 GPU 先查请求量 先查日志 先查最近发布 要不要查模型路由自主 Agent 更灵活但也更不可控。企业里更推荐的方式通常是外层固定流程局部自主探索。比如固定流程 收到告警 - 拉取基础信息 - 分析原因 - 生成建议 - 人工确认 自主探索 在“分析原因”阶段允许 Agent 自己决定查哪些日志、指标和发布记录。一句话企业 Agent 不一定要完全自主最稳的是流程可控局部智能。七、多 Agent、安全边界和评估复杂任务可以让多个 Agent 分工合作。例如生成技术方案Agent职责规划 Agent拆结构和任务步骤调研 Agent查资料、找依据架构 Agent设计系统模块和接口风险 Agent检查安全、成本、性能风险写作 Agent汇总成正式文档多 Agent 很像一个项目团队。每个角色各司其职但有分歧时需要一个负责人拍板。所以多 Agent 需要职责清楚 协调清楚 决策清楚否则就会出现任务重复。意见冲突。成本上升。延迟变长。最终责任不清楚。Agent 一旦能调用工具还必须考虑安全边界。安全边界包括用户权限。工具权限。数据权限。参数校验。人工审批。日志审计。回滚兜底。成本限制。停止条件。注意完全取消权限控制不是安全边界而是风险来源。评估 Agent 也不能只看最终回答。还要看过程维度要看什么工具选择是否选对工具参数质量参数是否完整、准确、合法权限控制是否越权读取或执行过程安全是否触发高风险动作成本延迟是否重复调用、是否失控失败兜底工具失败时是否停止或转人工最终结果目标是否完成证据是否充分八、Python Demo企业 Agent 最小验证为了把概念落到代码里我写了一个最小化 Agent demo。目录结构agent_demo/ agent_common.py # 公共 LLM、JSON 解析、工具轨迹 main_agent.py # 主 Agent任务路由和结果汇总 ops_workflow_agent.py # 运维工作流 Agent ops_autonomous_agent.py # 自主运维 Agent customer_ticket_agent.py # 客服工单 Agent .env.example # OpenAI-compatible 模型配置架构图这个 demo 的重点不是做一个生产级框架而是验证模型负责决策和总结。程序负责执行工具。工具结果要进入观察。高风险动作要标记人工确认。主 Agent 可以路由多个场景 Agent。1. 公共 LLM 调用agent_common.py里封装了 OpenAI-compatible 调用defcall_chat_model(prompt:str,temperature:float0.1)-str:baseos.getenv(LLM_API_BASE)api_keyos.getenv(LLM_API_KEY)modelos.getenv(LLM_MODEL)payload{model:model,messages:[{role:user,content:prompt}],temperature:temperature,}datapost_json(api_url(base,/chat/completions),api_key,payload)returndata[choices][0][message][content]为了本地能跑通也提供了离线开关AGENT_DEMO_OFFLINE_LLM1有线上模型时把.env.example复制成.env.local配置LLM_API_BASE LLM_API_KEY LLM_MODEL AGENT_DEMO_OFFLINE_LLM02. 运维工作流 Agentops_workflow_agent.py模拟固定流程告警 - 监控指标 - 发布记录 - 错误日志 - 候选动作 - 大模型总结它写死了几个模拟接口defget_metrics(service:str)-dict:return{p95_latency_ms:2860,error_rate:2.8%,gpu_utilization:94%,request_qps:1380,}还会把高风险动作标出来defpropose_actions()-list[dict]:return[{action:limit_large_requests,risk:medium,approval:False},{action:rollback_model_route,risk:high,approval:True},{action:restart_production_service,risk:high,approval:True},]这体现了企业 Agent 的基本原则低风险查询自动做高风险变更要确认。3. 自主运维 Agentops_autonomous_agent.py用的是企业里更常见的混合模式用户任务 可用工具列表 - LLM 生成排查计划 程序按计划批量调用工具 工具结果 - LLM 总结也就是说可用工具会一次性给到大模型get_metrics(service)查询服务指标 get_recent_deployments()查询近期发布和配置变更 get_error_logs(service)查询错误日志大模型先生成类似这样的计划{steps:[{tool:get_metrics,args:{service:inference-api},reason:先查看延迟、GPU、队列和错误率},{tool:get_recent_deployments,args:{},reason:再查看近期发布和配置变更},{tool:get_error_logs,args:{service:inference-api},reason:最后查看错误日志补齐证据链}]}程序再按计划执行工具。这种方式比“每一步都让模型重新决策”更快也更容易讲清楚工具链。如果要演示 ReAct 风格逐步决策也保留了参数python ops_autonomous_agent.py--planner-mode react--task自主调查推理服务延迟升高根因这对应 Agent 的停止条件和成本控制默认用计划式工具调用减少模型请求次数 需要更强动态性时再打开 ReAct 模式。4. 客服工单 Agentcustomer_ticket_agent.py模拟客服场景获取工单 - 查询订单 - 查询退款规则 - 生成回复草稿 - 人工审核例如退款规则写死为疑似重复扣费可生成退款建议但金额超过 5000 元必须人工审核。所以 Agent 可以生成回复草稿但不能自动退款。5. 主 Agent 路由多个场景main_agent.py作为主 Agent根据任务内容路由运维告警 - ops_workflow 自主调查 - ops_autonomous 客服退款 - customer_ticket主 Agent 的职责是判断该交给哪个场景 Agent。汇总子 Agent 的工具轨迹。标记风险等级。输出最终建议。6. 验证步骤从配置检查到线上大模型运行如果你只是想理解工具链可以用离线模式。如果你已经配置好大模型就可以走线上模式让模型真实参与路由、工具选择和总结。第一步进入 demo 目录cd F:\桌面\code\JD\aistudy\agent_demo第二步配置线上大模型复制.env.example为.env.local填入你的模型网关配置LLM_API_BASEhttps://your-model-api.example.com/v1 LLM_API_KEYyour_api_key LLM_MODELyour_chat_model AGENT_DEMO_OFFLINE_LLM0接口使用 OpenAI-compatible/chat/completions。第三步检查配置先检查配置是否被脚本读取到python check_config.py期望看到 Agent Demo 配置检查 LLM 模式online LLM_API_BASEhttps://... LLM_API_KEY******...****** LLM_MODELyour_chat_model AGENT_DEMO_OFFLINE_LLM0 线上配置是否完整是这个脚本不会打印完整 API Key只会做遮蔽显示。如果想确认模型接口真的能调用可以做一次最小请求python check_config.py--smoke-test如果成功会看到模型返回类似模型返回 Agent demo online ok第四步运行主 Agent主 Agent 会先判断任务类型再路由到对应场景 Agent。python main_agent.py--task推理服务延迟升高请帮我排查原因并给处理建议默认使用快速稳定模式--routing-mode rule主 Agent 用本地规则路由避免每次路由都请求大模型。 --planner-mode plan自主 Agent 一次性把工具列表给大模型让大模型生成排查计划程序再按计划批量调用工具。也就是说默认执行时不是每一步都重新问大模型而是用户任务 可用工具列表 - LLM 生成工具计划 程序按计划批量调用工具 工具结果 - LLM 总结这更接近企业里常用的混合模式既让大模型参与工具规划又避免 ReAct 式每一步都请求模型导致很慢。如果线上模型超时脚本会自动降级为离线总结不会让整个 Agent 流程中断。如果你想专门演示 ReAct 风格“每一步都让大模型根据上一轮工具结果重新决策”可以显式开启python main_agent.py--routing-mode llm--planner-mode react--task自主调查推理服务延迟升高根因如果模型响应慢可以调大超时时间$env:AGENT_DEMO_LLM_TIMEOUT30python main_agent.py--task推理服务延迟升高请帮我排查原因并给处理建议期望输出是步骤级流式工具链流程而不是一大段 JSON。执行时会边跑边输出“大模型决策、工具调用、工具返回、观察、风险结论” Agent 流式执行 任务推理服务延迟升高请帮我排查原因并给处理建议 LLM 模式online 执行 Agentmain_agent [1] 主 Agent 路由规则快速模式 路由结果ops_workflow 调用工具 - get_alert({alert_id: ALERT-1001}) 工具返回 - get_alert | 风险low 调用工具 - get_metrics({service: inference-api}) 工具返回 - get_metrics | 风险low 调用工具 - propose_actions({}) 工具返回 - propose_actions | 风险high需要人工确认 风险结论 风险等级high 是否需要人工确认是这里要注意LLM 模式online表示这次路由和总结已经真实调用大模型。如果显示LLM 模式offline-simulated说明还在本地模拟模式没有真实请求线上模型。第五步分别验证三个企业场景验证运维工作流 Agentpython ops_workflow_agent.py它会按固定流程执行告警 - 指标 - 发布记录 - 错误日志 - 候选动作 - 总结验证自主运维 Agentpython ops_autonomous_agent.py--task自主调查推理服务延迟升高根因它会让模型动态选择下一步工具正常会看到类似决策get_recent_deployments 决策get_metrics 决策get_error_logs 决策finish验证客服工单 Agentpython customer_ticket_agent.py--task处理客户重复扣费工单 T-9001它会模拟获取工单 - 查询订单 - 查询退款规则 - 生成回复草稿 - 标记人工审核第六步验证主 Agent 路由可以连续跑三条任务观察主 Agent 是否路由到不同场景python main_agent.py--task推理服务延迟升高请帮我排查原因并给处理建议python main_agent.py--task自主调查推理服务延迟升高根因python main_agent.py--task处理客户重复扣费工单 T-9001期望结果任务期望路由推理服务延迟升高ops_workflow自主调查根因ops_autonomous客户重复扣费工单customer_ticket如果想看完整结构化调试信息可以加--jsonpython main_agent.py--json--task推理服务延迟升高请帮我排查原因并给处理建议如果不想流式输出只想等执行结束后打印一份文字版流程可以加--no-streampython main_agent.py--no-stream--task推理服务延迟升高请帮我排查原因并给处理建议7. 离线模式验证如果没有模型密钥也可以用离线模式理解流程cd F:\桌面\code\JD\aistudy\agent_demo$env:AGENT_DEMO_OFFLINE_LLM1python main_agent.py--task推理服务延迟升高请帮我排查原因并给处理建议离线模式不会请求线上大模型而是用本地规则模拟模型输出。默认输出不是一大段 JSON而是更适合学习的流式工具链流程 Agent 流式执行 任务推理服务延迟升高请帮我排查原因并给处理建议 LLM 模式offline-simulated 执行 Agentmain_agent [1] 主 Agent 路由规则快速模式 路由结果ops_workflow 调用工具 - get_alert({alert_id: ALERT-1001}) 工具返回 - get_alert | 风险low 调用工具 - get_metrics({service: inference-api}) 工具返回 - get_metrics | 风险low 调用工具 - propose_actions({}) 工具返回 - propose_actions | 风险high需要人工确认 风险结论 风险等级high 是否需要人工确认是其中offline-simulated本地规则模拟大模型输出适合没有密钥时学习流程。 online真实调用 LLM_API_BASE /chat/completions由大模型做路由、工具选择和总结。最终输出会包含路由原因。工具调用记录。观察结果。风险等级。是否需要人工确认。大模型总结。九、常见误区误区正确理解Agent 就是更会聊天的模型Agent 更强调行动和任务完成工具给得越多越好工具太多会增加误调用概率Prompt 里写不要越权就安全了权限必须在系统层强制执行自主 Agent 一定比工作流 Agent 高级企业生产更看重可控、可审计多 Agent 一定更强多 Agent 会增加成本、延迟和协调复杂度只看最终答案就能评估 Agent还要看工具选择、参数、权限和过程安全十、本篇小结这篇文章我们学习了 Agent 智能体。重点可以压缩成 8 句话Agent 的核心不是聊天而是围绕目标推进任务。Agent 的基本闭环是目标、计划、行动、观察、调整。工具调用让 Agent 能连接外部系统但也带来权限和安全风险。模型通常只生成工具调用意图真正执行要由程序完成。规划、记忆、观察、反思能让 Agent 更稳定地完成复杂任务。企业更适合“外层固定流程局部自主探索”的混合 Agent。多 Agent 像项目团队需要协调者负责分工、冲突和最终决策。Agent 评估不能只看最终答案还要看过程、权限、成本和兜底。最终记住一句话企业 Agent 的价值不是全自动而是在可控边界内把多步骤任务更高效地推进。源码https://github.com/xgysigned/DayanAILab-/tree/main/agent_demo下一篇预告下一篇进入第 10 章模型微调。我们会继续回答一个很实际的问题什么时候用 Prompt 什么时候用 RAG 什么时候真的需要微调 LoRA、QLoRA、SFT 又分别是什么