Agent 这个词现在被用得很乱。有人把它理解成“会自己思考的 AI”有人把它理解成“多个角色互相讨论”也有人认为只要给大模型接几个工具就已经是在做 Agent。但从工程角度看Agent 最重要的不是“看起来多自主”而是它能不能在明确边界内稳定完成一个多步骤任务。这才更接近真实 AI 应用开发。一、普通大模型调用解决的是“回答”Agent 解决的是“任务”普通 LLM 调用一般是这样的用户输入一个问题模型返回一段文本。比如用户问帮我写一段求职信。模型直接生成一段求职信。这个过程没有问题但它本质上还是一次文本生成。模型并不知道用户的真实简历细节有没有支撑这段求职信也不知道目标 JD 的关键要求是什么更不知道哪些内容不能夸大。RAG 往前走了一步它会先检索知识库、文档或数据库再让模型基于材料回答。它主要解决的是“回答有没有依据”。但 Agent 要解决的不是单次回答而是任务推进。它不只是“查资料再回答”而是要根据任务目标在多个步骤之间做选择它可能需要先判断用户意图再决定要不要查询订单它可能需要先检索售后政策再判断是否能退款它可能需要生成一个草稿但不能直接提交它可能需要发现证据不足然后暂停要求用户补充信息。也就是说Agent 面向的不是单次回答而是一个可执行的任务过程。所以我更愿意把 Agent 看成一个系统问题Agent 不是把 prompt 写得更像人而是把模型放进一个可以行动、可以观察、可以被约束的系统里。二、Agent 和 Workflow 的区别我不太建议一上来就从“自主规划”理解 Agent。Anthropic 在《Building effective agents》里把 agentic systems 分成 workflow 和 agent。Workflow 是 LLM 和工具按照预设代码路径被编排Agent 则是 LLM 可以动态决定自己的流程和工具使用方式。它们都属于 agentic system但工程含义不同。这个区分很重要。如果你的任务路径本来就很清楚比如解析 JD解析简历匹配能力项找出缺口生成定制简历做证据检查输出风险提示那它更适合先做成 workflow而不是一上来就交给 Agent 自己规划。Workflow 的好处是可控、可测、可复盘。Agent 的价值在于处理那些路径不固定、步骤数量不确定、需要根据中间结果不断调整的任务。比如客服场景里用户可能问的是物流、退款、发票、商品参数、投诉、优惠券、售后政策也可能把多个问题混在一起。系统很难提前写死所有路径这时 Agent 才有更明确的价值。换成代码视角区别更明显Workflow 的下一步主要由开发者写死。Agent 的下一步主要由模型根据当前状态决定。这不是说 Agent 没有代码控制而是说代码负责提供工具、状态和边界模型负责在这些边界里选择下一步。但这不代表 Agent 可以无限自由。恰恰相反Agent 越能行动越需要边界。三、用代码理解 Agent从代码角度看Agent 不是一个神秘概念。它可以先理解成Agent 一个由 LLM 驱动下一步决策的任务循环。这里的“循环”不是说所有框架源码都必须写成 while而是说 Agent 的运行语义大致相同模型决定下一步应用执行工具工具结果写回状态模型再基于新状态继续判断。while(!state.isFinished()){AgentDecisiondecisionllm.decideNextStep(state,availableTools);if(decision.isFinalAnswer()){returndecision.answer();}if(decision.isToolCall()){policyGate.check(user,decision.toolName(),decision.arguments());ToolResultresulttoolExecutor.execute(decision.toolName(),decision.arguments());state.addToolResult(result);traceLog.record(decision,result);}if(decision.needHumanApproval()){returnpauseForHumanReview(state);}}这不是某个 Agent 框架的完整源码而是 Agent 的核心运行语义。普通 LLM 是Stringanswerllm.chat(userQuestion);returnanswer;RAG 是ListDocumentdocsretriever.search(userQuestion);Stringanswerllm.chat(userQuestion,docs);returnanswer;Workflow 是JdInfojdparseJd(input);ResumeInforesumeparseResume(input);MatchResultmatchmatchResumeToJd(jd,resume);RewriteResultrewriterewriteResume(match);RiskReportriskcheckEvidence(rewrite);returnresult;Agent 是AgentStatestatenewAgentState(userGoal);while(state.canContinue()){AgentDecisiondecisionmodel.decide(state,tools);switch(decision.type()){caseCALL_TOOL-{ToolResultresultexecuteTool(decision);state.observe(result);}caseASK_USER-{returnaskUserForMoreInfo(decision.question());}caseNEED_APPROVAL-{returnwaitForHumanApproval(decision.action());}caseFINAL-{returndecision.finalAnswer();}}}区别就在这里Workflow 的下一步是代码写死的。Agent 的下一步是模型根据当前状态决定的。这也对应了 Anthropic 对 workflow 和 agent 的区分前者按预设路径执行后者由模型动态决定流程和工具使用。代码上一个 Agent 至少有 5 个对象不要先想 LangGraph、CrewAI、AutoGen。先想这 5 个类。1AgentState任务状态publicclassAgentState{privateStringgoal;privateintstep;privateListMessagemessages;privateListToolCallRecordtoolCalls;privateMapString,Objectfacts;privatebooleanfinished;privatebooleanneedHumanApproval;}它回答一个问题任务现在进行到哪一步了没有AgentState就不是连续任务只是一次问答。2AgentTool工具publicinterfaceAgentTool{Stringname();Stringdescription();ToolResultexecute(MapString,Objectarguments);}比如电商客服 Agent 里可以有publicclassGetOrderToolimplementsAgentTool{publicStringname(){returnget_order;}publicStringdescription(){return根据 orderId 查询当前用户的订单状态;}publicToolResultexecute(MapString,Objectargs){StringorderId(String)args.get(orderId);// 查数据库 / 调接口returnorderService.getOrder(orderId);}}Spring AI 的 Tool Calling 也是类似思想模型提出工具调用请求应用程序负责解析、执行工具、再把结果返回给模型。模型不是直接操作你的数据库。3AgentDecision模型决定下一步publicsealedinterfaceAgentDecisionpermitsCallTool,FinalAnswer,NeedHumanApproval{}publicrecordCallTool(StringtoolName,MapString,Objectarguments)implementsAgentDecision{}publicrecordFinalAnswer(Stringanswer)implementsAgentDecision{}publicrecordNeedHumanApproval(Stringaction,Stringreason)implementsAgentDecision{}这里就是 Agent 和普通程序最大的区别。普通程序是你写先查订单再查政策再生成回复。Agent 是模型返回{ type: CALL_TOOL, toolName: get_order, arguments: { orderId: 123456 } }然后你的后端决定这个工具存不存在这个用户有没有权限这个 orderId 是不是他的这个动作需不需要人工确认4PolicyGate权限边界publicclassPolicyGate{publicvoidcheck(Useruser,StringtoolName,MapString,Objectargs){if(toolName.equals(submit_refund)){thrownewNeedHumanApprovalException(退款提交必须人工确认);}if(toolName.equals(get_order)){StringorderId(String)args.get(orderId);if(!orderService.belongsToUser(orderId,user.id())){thrownewAccessDeniedException(不能查询他人订单);}}}}边界不是 prompt 里写一句“不要越权”而是代码里真的拦住。OWASP 的 Excessive Agency 风险本质就是 LLM 系统被授予过多功能、权限或自主性后可能造成破坏性动作所以工具权限、人工确认、最小授权必须在系统层实现。5AgentRunner核心循环publicclassAgentRunner{privatefinalLlmClientllm;privatefinalToolRegistrytoolRegistry;privatefinalToolExecutortoolExecutor;privatefinalPolicyGatepolicyGate;privatefinalTraceLogtraceLog;publicAgentResultrun(Useruser,Stringgoal){AgentStatestatenewAgentState(goal);while(!state.isFinished()state.getStep()10){AgentDecisiondecisionllm.decideNextStep(state,toolRegistry.availableTools());if(decisioninstanceofFinalAnswerfinalAnswer){state.finish();returnAgentResult.success(finalAnswer.answer());}if(decisioninstanceofNeedHumanApprovalapproval){returnAgentResult.waitingForApproval(approval.action(),approval.reason());}if(decisioninstanceofCallToolcallTool){policyGate.check(user,callTool.toolName(),callTool.arguments());ToolResultresulttoolExecutor.execute(callTool.toolName(),callTool.arguments());state.addToolCall(callTool,result);traceLog.record(state,callTool,result);state.nextStep();}}returnAgentResult.failed(Agent stopped: max steps reached.);}}OpenAI Agents SDK 里所谓 agent loop本质也是处理工具调用把结果送回 LLM然后继续运行直到任务完成同时配套 guardrails、sessions、tracing 等工程能力。用电商客服理解一次完整执行用户问我的订单签收三天了商品破损可以退吗Agent 第一次判断{type:CALL_TOOL,toolName:get_order,arguments:{orderId:A1001}}后端执行policyGate.check(user,get_order,args);ToolResultordergetOrderTool.execute(args);state.addToolResult(order);工具返回{orderId:A1001,status:SIGNED,signedDaysAgo:3,productCategory:electronics}Agent 第二次判断{type:CALL_TOOL,toolName:get_refund_policy,arguments:{category:electronics}}工具返回{category:electronics,returnWindowDays:7,needDamagePhoto:true,autoRefundAllowed:false}Agent 第三次判断{type:FINAL,answer:你的订单签收 3 天仍在 7 天售后窗口内。但商品破损需要上传图片凭证我可以先帮你生成退款申请说明提交退款前需要你确认。}这就是一个最小 Agent 的运行过程。它不是一次性回答而是看当前状态 → 决定查订单 → 得到订单结果 → 决定查政策 → 得到政策结果 → 判断不能直接退款 → 给出受边界约束的答案所以从代码视角看Agent 不是让模型直接控制系统而是让模型提出下一步动作再由应用程序判断、执行、记录和约束。四、Agent 的核心不是“自主”而是工具、状态和边界一个更工程化的 Agent 定义可以是Agent LLM Tools State Control Loop Guardrails拆开看LLM 负责理解任务和选择下一步。Tools 负责连接数据库、订单系统、知识库、搜索服务等外部能力。State 负责记录任务进展、工具调用历史和中间结果。Control Loop 负责把模型决策、工具执行和结果反馈串起来。Guardrails 负责限制模型不能越权、不能乱调用工具、不能直接执行高风险动作。这里最容易被忽略的是工具调用的安全边界。Spring AI 官方文档对 tool calling 的说明很清楚虽然通常说 tool calling 是模型能力但实际执行工具调用逻辑的是客户端应用。模型只能请求工具调用并提供参数真正执行工具、返回结果的是应用程序本身模型并不会直接获得工具背后的 API 权限。这句话非常关键。因为它说明 Agent 不是让模型直接控制系统而是让模型提出行动意图再由应用层判断是否执行。比如电商客服 Agent 面对“我的订单能退吗”这个问题时它不应该直接回答“可以退”。更合理的方式是先查询订单再查询售后政策再结合订单状态、商品类目和平台规则生成回复。如果涉及退款提交就只能生成草稿不能直接执行。这才是可上线的 Agent。五、Agent 的真正风险从“回答错误”变成“行动越界”普通大模型回答错风险主要在内容层。Agent 一旦接入工具风险就进入系统层。它可能查错数据调用错工具传错参数泄露敏感信息执行不该执行的操作或者在错误前提下连续行动。OWASP LLM Top 10 里专门列出了 Prompt Injection、Insecure Plugin Design、Excessive Agency 等风险。其中 Excessive Agency 指的是给 LLM 过多、未受约束的行动自主权可能破坏可靠性、隐私和信任。这也是为什么我不赞成一开始就做“全自动 Agent”。Agent 安全不能只靠 prompt而必须靠工具权限、参数校验、人工确认和审计日志这些系统层设计。真正的工程顺序应该是先让模型会读。再让模型会查。再让模型会生成草稿。再让模型在低风险场景自动执行。最后才考虑高风险动作的半自动化或自动化。对于工具权限我更倾向于分四层READ只读查询可以自动执行。例如查询订单状态、查询物流、检索政策文档。DRAFT只生成草稿不真正提交。例如生成退款说明、工单回复、邮件草稿。WRITE_REVIEW会改变系统状态必须人工确认。例如提交退款申请、修改用户资料、发送正式邮件。DANGEROUS默认禁止。例如删除数据、批量修改权限、执行任意命令。如果一个 Agent 系统没有这个权限分层那它本质上还不能算生产级 Agent只是一个接了工具的聊天机器人。六、一个更接近真实项目的 Agent 示例假设我们要做一个跨境电商客服 Agent。用户问我这个订单已经签收三天了商品有破损能不能退一个不可靠的 AI 可能会直接回答一般情况下签收七天内可以退货。这句话听起来合理但它不一定正确。因为真实判断至少需要几个条件订单是否真实存在订单是不是当前用户的商品类目是什么是否支持无理由退货破损是否需要上传凭证当前是否超过售后时间平台政策和商家政策是否冲突是否需要人工客服介入所以更合理的 Agent 流程应该是用户问题 → 意图识别售后 / 退款 / 商品破损 → 查询订单状态 → 检索售后政策RAG 在这里是证据工具 → 检查商品类目 → 判断是否需要图片凭证 → 生成客服回复 → 标注证据来源 → 如果涉及退款提交进入人工确认 → 记录整次 Agent Run在这个流程里模型不是凭常识回答而是在工具和证据的约束下完成任务。这就是 Agent 相比普通聊天机器人的真正区别它不是凭常识直接回答而是在工具、证据和权限边界内推进任务。七、为什么不要一开始做多 Agent很多 Agent 教程喜欢从多 Agent 开始一个产品经理 Agent一个架构师 Agent一个开发者 Agent一个测试 Agent大家互相讨论最后输出结果。这种演示很容易吸引眼球但工程价值未必高。多数真实业务问题不是靠“多几个角色说话”解决的而是靠更清楚的任务边界、更可靠的工具、更稳定的状态记录和更严格的输出校验解决的。多 Agent 只有在这些场景下才更有必要不同角色确实需要不同职责不同 Agent 拥有不同工具权限需要一个 Agent 审查另一个 Agent 的输出任务路径复杂到单一 workflow 难以维护系统需要长期运行和异步协作。否则多 Agent 很可能只是增加延迟、成本和调试难度。所以第一篇不应该从多 Agent 开始而应该先讲清楚单个 Agent 如何完成任务、如何调用工具、如何记录状态、如何控制边界。八、我对 Agent 的第一性原则如果让我用一句话定义 Agent我不会说它是“自主智能体”。我更愿意说Agent 是一个让大模型在工具、状态和权限边界内完成任务的工程系统。这个定义不够炫但更适合真实开发。因为 Agent 的难点从来不只是“让模型更聪明”而是它能调用什么工具它不能调用什么工具它每一步是否有依据它的工具调用是否可追踪它在证据不足时能不能停下来它在高风险动作前能不能交给人它失败后能不能复盘。所以 Agent 专题不应该从框架开始不应该从多 Agent 开始也不应该从“让 AI 自己干活”开始。它应该先回答一个更基础的问题当我们说要做 Agent 时我们到底是在做一个聊天机器人还是在做一个可控的任务执行系统如果只是聊天普通 LLM 就够了。如果只是查资料RAG 就够了。如果路径固定Workflow 就够了。如果任务路径不确定需要工具、状态、反馈和权限边界才真正进入 Agent。下一篇我会解释 Agent 核心术语ReAct、Tool Calling、State、Memory、Workflow 到底是什么参考资料AnthropicBuilding effective agentsOpenAI Agents SDKAgent loop、Tools、Sessions、Tracing、GuardrailsSpring AI ReferenceTool CallingOWASP LLM Top 10Excessive AgencyReActSynergizing Reasoning and Acting in Language ModelsToolformerLanguage Models Can Teach Themselves to Use Tools我是 Ryan一个专注于可信 AI 应用工程的开发者我的个人技术博客研究如何让 AI 生成从“看起来对”走向“有证据、可追溯、可验证”。