★ FEATURED ARTICLE Agent 这个词这两年热到什么程度打开技术社区满屏都是 agent 开发、agent 框架、多 agent 协作。但说实话大部分讨论都停留在“Agent 是什么”的层面真正想动手做的人一旦要考虑“怎么实现”很快就会在两难之间纠结到底只是一个 API 调用套个 prompt还是要搞一套复杂的多 agent 编排我见过不少团队在这个问题上走了岔路。有的上来就学 LangGraph 里的各种 StateGraph结果发现业务根本接不住有的则把所有逻辑都塞进一轮 prompt 里指望大模型自己“悟”出整个流程结果一开线上就翻车。这篇理论篇我就想一次性把 Agent 的实现方式讲清楚从最简单的单轮调用到链式调用再到带工具和记忆的单 agent最后才是多 agent 协作编排。每一层我都会解释它解决什么问题、代价是什么、什么时候该升级什么时候该老老实实待在这一层。我并不打算站在“技术布道者”的高度讲概念而是想站在一个实际选型的人的角度把这套事情当一个工程问题来拆。看完你应该能回答自己一个问题我现在的业务到底属于哪一层L0 够了L1 够不够还是真的得到 L2、L31. 理解 Agent 先过一道坎它和普通 API 调用的本质区别1.1 从“一问一答”到“自主闭环”很多人对 Agent 的第一印象是“更聪明的聊天机器人”这是一个非常容易踩的误区。普通 API 调用是单次输入、单次输出你把 prompt 发给模型模型返回一段文本交互结束系统不做任何事。Agent 的差别在于它会基于模型的输出做下一步动作再观察动作的结果再决定再下一步形成闭环。举个最直白的例子。你让模型“帮我查一下这个仓库有没有这个依赖”普通调用模式下模型只能告诉你“请在你的终端里运行 pip show xxx”。而如果是一个 Agent它会自己调用终端工具执行 pip show把真实输出拿回来再做下一个判断。模型是大脑Agent 是大脑加手和眼睛。这个“手和眼睛”就是 Agent 实现分层的起点。技术上一板一眼地说一个完整的 Agent 循环包含四个环节感知拿到任务和当前状态、决策模型生成下一步动作、执行调用工具或代码、观察拿到执行结果进入下一轮。Perception-Decision-Action-Observation这个循环就是 Agent 区别于普通调用的一切。搞清楚这一点你再看市面上的各种框架就会发现它们本质上都是在帮你包装这个循环循环跑几次就是单 agent几个循环并行或串行再配合消息通道就是多 agent 协作。1.2 Agent 实现的最小骨架我把这个循环拆成代码结构来看并不复杂哪怕你不用任何框架也能手写一个最小版本。# 伪代码最小 Agent 循环 state 给你一个任务确认 target 目录下 csv 文件数量 while not done: action llm_decision(state) # 决策模型输出下一步动作 result execute_action(action) # 执行调用工具/代码/API done check_finished(result) # 检查是否完成 state 任务 task 中间结果 result这个循环的复杂度提升就是 Agent 实现方式的演进主线。单轮调用 这个循环只执行一次没有工具模型给完答案就停。多 Agent 协作 每个子 Agent 都跑各自的循环同时通过消息互相传递中间结果用一个超循环把它们的输出汇总成最终答案。所以我的建议是不用急着学框架先用这个最小骨架手写一遍你会发现后续所有问题都是往这个骨架里加约束和扩展。1.3 Agent 记忆工作记忆与长期记忆聊到实现方式绕不开记忆。热词里“agent记忆”被搜得很多但这个概念比大部分人想的更朴素。我一般把它拆成两层工作记忆就是当前循环里暂存的中间信息比如已经执行过哪些工具、拿到了哪些结果、做过哪些判断。工作记忆的实现方式很简单通常是往 context 里追加一段“当前状态”但它的代价是随着循环变长token 消耗越来越大还可能把真正重要的信息挤出去。我在实际项目中一般会对工作记忆做“压缩”只保留最近两轮完整执行记录更早的归纳成一句话摘要。长期记忆则是对接外部存储的比如把用户历史交互、知识库条目写成向量数据库在下一次任务到来时做召回。这种记忆的实现已经脱离了纯 prompt 层面需要你设计存储结构、写入策略、召回策略。很多人一上来就堆向量库其实是过度设计因为大部分业务场景根本没有那么多历史状态需要跨会话保留。2. 单轮调用最简单的实现方式也是最容易被低估的方案2.1 单轮调用到底适合什么场景如果把 Agent 实现方式排一个光谱最左端就是单轮调用。它本质上是一个无状态的 LLM 请求你把用户输入拼上系统提示词发给模型模型返回结果结束。它非常简单、成本极低、可调试性极高也是我最常用的一种实现方式。关键问题是什么场景适合我总结下来有三类信息提取与改写从文本里抽实体、改写文案、总结摘要。这类任务一次性完成不需要模型查阅外部信息不需要迭代单轮调用足够。单步结构化输出把用户问题分类、提取意图、判断正负样本。模型只需要输出一个结构化结果比如 JSON不涉及任何后续动作。格式受限的生成式任务按固定模板生成内容比如邮件正文、产品描述输入决定输出输出即终态。我见过不少团队在已经能用单轮调用解决的问题上强行引入多 agent 架构结果就是延迟从 1 秒变成 5 秒成本翻了好几倍效果却没有什么肉眼可见的提升。大多数业务里 70% 的需求用单轮调用加一个严格的输出解析就能解决根本不需要更复杂的架构。2.2 从单轮到链式调用多步推理的工程化过渡当单轮调用处理不了“需要多步骤才能得出结果”的任务时大多数人会想到链式调用。链式调用就是把一个大任务拆成多个步骤每个步骤是一次独立的 LLM 调用前一步的输出作为后一步的输入。它的价值在于把“一步到位”的模糊推理变成了“分步执行”的可控流水线。我举一个我实际做过的例子从客户反馈里生成工单分类、优先级和责任人。这个任务如果单轮做模型很容易把分类和责任人搞混输出质量不稳定。链式调用拆成三步从反馈文本中提取问题描述和关键实体输出 JSON。基于 JSON 做分类和优先级判断输出分类结果。基于分类结果映射责任人输出责任人 ID。每一步的 prompt 都极其简单调试起来也明确如果分类不对问题只出在第二步不用担心前面哪层的上下文污染了判断。链式调用的工程化意义在于可观测性这是单轮调用做不到的。但要注意链式调用不是万能药。每一跳都会引入延迟和 token 成本而且一旦前一步输出里有错误噪声后面的步骤会一并放大这就是所谓的“错误传播”。在实际落地时我强烈建议每一步之间加一个校验函数不通过的输入绝对不允许进入下一个 LLM 调用。这个习惯能帮你省掉大量线上排查时间。2.3 给 Agent 一根“手”工具调用与 Function Calling链式调用的局限是所有数据都靠模型自身知识或写在 prompt 里的内容但很多场景需要获取实时信息比如查库存、发邮件、搜数据库。这时候就该上工具调用了。工具调用的实现思路是你预先给模型声明一批可用工具每个工具包含名称、描述和参数 JSON Schema模型在决策阶段会生成一个“我要调用哪个工具、传什么参数”的结构化输出系统来执行这个工具。注意工具的真正调用者不是模型而是你的代码大模型只负责决定调用哪个工具以及给参数赋值。这个边界非常重要。热词里有一个“agent skill 教程”和“hermes agent 第三方工作台”本质上都是在工具的基础上做技能封装。skill 可以理解为一组工具加一段 prompt 模板的组合包比如“网页转 Markdown 的 skill”就是一个工具专用指令。这样设计的好处是复用性高新任务只需要挂载对应的 skill不必重新写工具调用逻辑。我个人的实践感受是在单 agent 阶段工具调用是最核心的扩展点。一个 chat agent 好不好用往往不取决于模型多强而取决于你能给它多少可靠的工具以及工具描述写得多清晰。3. 进阶单 Agent 的完整实现拆解3.1 ReAct 模式推理与行动的咬合如果你对 Agent 框架稍微研究过一定见过 ReActReasoning Acting。它就是把“思考”和“执行”交替进行的模式用自然语言将模型的推理过程与工具执行结果交织在一起。一句话说ReAct 让模型在每一步先写一小段思考再决定执行什么动作然后根据动作结果继续思考。ReAct 模式之所以成为单 agent 的主流范式是因为它极大缓解了模型直接输出答案时的“幻觉”问题。模型被要求给出推理过程并且只有基于观察结果才能进入下一步因此它不能凭空编造工具结果。实现上非常轻量不需要额外的分类器只需要在 prompt 里规定格式配合工具调用框架即可。但在实践中我要提醒一个反直觉的点ReAct 的“思考”过程并不总是让结果更可靠有时候它会让模型在简单任务上也绕圈子。比如一个“读取文件并打印内容”的任务模型可能先思考两段再决定调用工具再输出。所以我在设计时通常会给循环加一个最大步数限制一旦超过步数自动终止防止模型陷入无意义的自我对话。3.2 规划器与执行器的分隔比 ReAct 更高一层的单 agent 实现是**Planner-Executor规划器-执行器**架构。在这种架构下模型第一次调用生成一个完整的执行计划一系列步骤然后系统按照计划逐步执行每一步可以调用专门的执行器或工具执行完后回到计划上下文继续判断。规划器与执行器分离的好处是把**“做计划”和“做动作”两件事分开优化**。规划器只需要擅长拆解任务执行器只需要擅长跑具体的动作二者可以用不同的模型、不同的测评标准。比如规划用强推理模型执行动作可以用更快更便宜的模型整体成本能降不少。这个模式需要设计一个“计划维护模块”负责跟踪哪些步骤已完成、哪些待执行、哪些需要重新规划。我在项目里见过一种轻量实现把计划写成一段 Markdown 列表每次执行完一个步骤就将其标记为完成并把结果追加到状态里。模型重新审视状态后决定是按计划走还是生成新计划。这种方式不依赖图结构也能撑起中等复杂度的自动化任务。3.3 Skill 与 Harness两个被滥用也常被误解的概念热词里反复出现“agent skill”和“agent harness”这是当前社区讨论度很高的两个词。我得先把定义理清楚因为这直接影响你对架构的理解。Skill我理解为“面向模型的能力单元”一个 skill 包含工具清单、调用约束、示例和评价指标它让模型知道在某种场景下应该怎么调用哪些工具。它与普通工具库的区别在于skill 更强调“场景化组合”。比如“把网页保存成 Markdown 的 skill”它不只是给你一个保存函数它还包括了网页抓取后如何处理、如何交给模型、如何校验结果这些组合逻辑。Harness国内经常翻译成“运行时外壳”或者“执行框架”它的核心职责是托管 agent 的运行生命周期。agent 本体只是模型加 prompt真正驱动循环、安全限制、沙箱隔离、工具调用的权限控制都由 harness 完成。因此业界才会争论“harness 和 agent 区别”——Agent 是决策核心Harness 是承载决策的环境。我之前一直强调“别只盯着模型选型你真正用的是 harness”。因为模型的决策能力固然重要但决定一个 agent 在生产环境是否可用的往往是 harness 里的细节工具执行是否有超时、是否有权限校验、是否记录审计日志、沙箱环境是否能防止恶意 prompt 让模型执行危险操作。4. 多 Agent 协作从单体到大系统4.1 为什么要协作多 Agent 解决的是复杂度问题从单 agent 到多 agent 协作不是“听起来更高级”而是当你观察单 agent 的架构瓶颈时会发现自己不得不拆。单 agent 的核心瓶颈有三个上下文爆炸所有任务的历史状态、中间结果都堆在同一份 context 里很快就会塞满上下文窗口模型开始“忘事”。角色冲突一个 agent 既要懂用户意图分类又要负责具体业务执行还要做质量审查所有角色混在一个 prompt 里指令相互干扰模型行为变得不稳定。单点失败一旦模型在中间某一步决策失误整个任务就终结重跑一遍成本极高且难以定位问题源头。多 agent 协作的思路就是“专人专事”把任务拆成子空间每个 agent 在自己的上下文窗口内只处理一部分问题通过消息传递把结果拼起来。这很像软件开发里的模块化——单体难维护时就拆微服务单 agent 难维护时就拆多 agent。但是你要对“拆”有代价意识。多 agent 协作引入的最大成本是通信与协调agent 之间的消息格式、同步方式、结果仲裁都需要设计调试复杂度呈指数上升。我平时判断的依据是如果单 agent 在 3 次工具调用内能完成的任务绝不上多 agent。4.2 四种主流协作拓扑多 agent 协作的实现方式我不建议只背框架名而是要从拓扑角度去理解。市面上主流的方式大致有四类结构第一类编排式Orchestrator-Workers。一个中心调度 agentOrchestrator负责拆解任务把子任务分配给不同的 worker agent最后汇总结果。这是最容易实现、也最容易理解的拓扑。你日常看到的大部分“主 agent子 agent”架构都属此类。优点是可控制性强调度逻辑清晰缺点是中心节点会成为瓶颈而且调度 agent 一旦决策错误整体计划全乱。第二类协商式Peer-to-Peer / Swarm。多个 agent 地位平等各自承担一部分能力通过消息队列互相发布和接收任务像一群蚂蚁一样没有中心指挥。这种模式适合高度动态、需要群体智能的任务比如舆情分析里多个 agent 各带一个视角同时分析、互相纠偏。不过它的收敛性很难保证——没有中心节点意味着可能需要多轮协商才能达成一致甚至死循环。第三类层级式Hierarchical。编排式的变体但引入了多层管理。顶层 agent 拆成几个大模块每个大模块的负责人 agent 再拆成子任务往下分配。它适合超大规模任务但实现成本高层级多的时候追踪一个错误要跨越好几个 agent 的日志。第四类黑板式Blackboard。多个 agent 共享一块“黑板”公共状态区每个 agent 只负责在黑板里写入自己能力范围内能填的信息其他 agent 看到这些信息后再各取所需继续往下做。这种模式在传统 AI 里就存在适合任务可以被分解为很多相互独立但逐步逼近的片断的场景。我给一个实际的选型建议刚开始落地的团队从编排式入手别碰协商式。编排式的“1 个调度 N 个 worker”严格遵循单一控制流出错时你知道该看谁的日志协商式虽然看起来去中心化、很酷但你在没有成熟观测手段之前真的会痛苦到怀疑人生。4.3 角色设计与通信协议多 agent 协作最容易被忽略的是角色设计和通信协议。很多新手团队迫不及待搭好了框架却发现多个 agent 之间互相“抢活”或者“沉默”就是因为角色边界和消息规范没设计好。角色设计的关键是每个 agent 的职责要窄但专业度要深。比如不要把“数据分析师”和“报告撰写员”合并成一个 agent否则 prompts 会互相污染。理想情况下一个 agent 应该能在一句话里说清楚自己是干什么的、能提供什么输出、不负责什么。这听起来像是在写质量管理体系但它在 Agent 系统里确实能带来可预期的稳定输出。通信协议则指 agent 之间传递消息时的格式和约束。我一般不推荐完全自由文本交流那样会让消息内容不可解析。正确做法是约定一套固定的消息 schema比如{ from: planner, to: reviewer, type: request_review, payload: {artifact_id: task_001, status: done} }固定 schema 的好处是各个 agent 之间不需要“理解自然语言语义”就能对接而且后续做监控、审计、重放都很容易。当你准备从单 agent 升级到多 agent 协作时第一件要做的事不是选框架而是把通信协议定义出来。5. 框架与工程选型LangChain、Dify、CrewAI 怎么挑5.1 三类框架的定位差异热词里有一类高频搜索就是“agent 框架”以及“agent 框架如 LangChain、Dify、CrewAI 哪个好”。这类问题每次看完我都觉得很难直接回答因为这三个玩意的定位差异真的很大不是同一个维度上的替代品。我把它们分成三类LangChain 系LangChain / LangGraph属于底层代码库它给你提供组件比如工具调用抽象、记忆封装、链式编排的 API但你得自己写业务流程。LangGraph 更进一步把 agent 流程建模成图节点是处理函数边是转移条件适合需要精细控制流程的开发者。代价是学习曲线陡峭没有图形界面全得靠代码。Dify 这类偏产品化的平台属于低代码集成环境它把常用组件封装成可视化节点你在界面上拖拽就能搭一个 agent 工作流。适合业务方快速验证想法或者让运营团队自己搭工具。问题是灵活度受限当你需要接入私有协议或者自定义特殊逻辑时会感觉到明显的“平台墙”。CrewAI 这类框架走的是角色化多 agent路线它把“角色目标背景故事工具”封装成一个 Crew用很简洁的 API 创建多个 agent 并让它们协作。它上手的爽感很强非常适合多 agent 协作的原型验证。但它的抽象层级偏高一旦发生 agent 间死锁、上下文混乱等问题排查难度比 LangGraph 大不少。5.2 选型决策表我平时给团队做选型时会按一张表格来评估选型维度LangChain/LangGraphDify 类平台CrewAI适合人群重视自由度的开发者非技术或轻技术团队快速原型验证的多 agent 项目控制粒度细图、状态、节点都可控中节点级拖拽粗角色级封装调试难度中高但日志清晰后可定位低可视化中高中间过程不透明多 agent 能力强但需自己设计拓扑中平台内定了限制强开箱即用生产级稳定性高自己掌控全链路中受制于平台中框架迭代快需盯版本学习成本高低较低我的个人结论是如果你的团队以代码开发为主长期要维护一套生产系统优先考虑 LangGraph 这类底层可控方案如果只是想快速把 agent 流程跑起来看效果用 Dify 做原型很合适如果你的目标就是探索多个 agent 角色分工是否有效CrewAI 的体验会很顺畅。不要在选型上花太多时间“找最好的框架”而是按你的团队能力和交付场景来反推。5.3 别忽视 Agent 安全与沙箱问题热词里“agent 安全”和“agent 沙箱”被反复搜索我特别想借选型这个话题提两嘴。很多团队在实现 agent 时把重点全放在任务完成率上安全问题完全没被重视。这事的核心在于Agent 会调用工具工具意味着真实世界的副作用。如果模型被恶意 prompt 诱导让它调用“删除文件”或“发送邮件”这类危险工具你凭什么拦截此外模型输出的内容有可能包含注入型指令比方说一个外部网页里的隐藏文字诱导模型去执行非预期动作。这在大模型安全里叫做“间接提示注入”。所以我在工程上会坚持几个底线所有工具调用必须经过权限校验白名单敏感操作需要二次人工确认Agent 的执行环境要放进一个隔离的沙箱比如容器或受限子进程避免它访问不该访问的系统能力做完每一步工具调用都要写审计日志这样即使出问题也能追溯。这些设计不属于“锦上添花”而是 agent 能否落地的硬门槛。6. 从单轮到多 Agent 的决策指南6.1 判断时机哪些场景不需要多 Agent这一节可能是本文中最想和你们强调的多 Agent 不是进化的必然方向它只是一个工具箱而且很多时候你根本不该打开它。我会用一个“三问法”来判断到底要不要上多 agent 协作第一问任务是否可以线性拆解且每一步的输出能够用结构化的 schema 稳定传递如果可以链式调用就够了不需要多 agent。第二问是否真的存在多个角色视角必须同时存在且互为补充比如“策划”和“执行”必须分开因为不分开的话 prompt 互相干扰。如果是再考虑多 agent。第三问你是否有足够的监控、日志、重放机制来兜底多 agent 的不可预测性没有的话强行上多 agent 就是自己给自己挖坑。我见过一些项目之所以上多 agent 纯粹是“演示效果好看”比如让两个 agent 相互对话来体现“智能感”。这对实际业务没有任何帮助反而让成本翻倍、延迟变长。好的架构是让用户感知不到架构的存在多 agent 协作中用到的所有复杂调度最终呈现给用户的应该只是一个更快、更准、更稳的结果而不是一堆 agent 聊天的过程。6.2 演进路径先跑通再拆角色最后加协作如果你最终确定需要多 agent我建议你按下面的路径走不要一步到位。第一阶段单 agent 跑通全流程。先不管角色分工把任务用单 agent 的循环跑通拿到一个可用的端到端结果。这个阶段的目的是验证“任务本身可自动化”而不是验证架构。第二阶段分离稳定模块。观察单 agent 跑通的过程中哪些环节经常出错把出错多的环节拆成独立子过程。比如发现搜索环节经常和总结环节互相干扰就把搜索单独拆成一个 agent只负责返回结构化搜索结果。第三阶段引入协作拓扑。当子过程足够稳定后再设计协作拓扑。我最推荐从编排式开始即使最后你要调整成协商式也应该先有编排式做兜底。这个路径看起来慢但它每一步都是可验证的出现问题时你知道该回滚到哪个阶段。很多人想一口吃成胖子直接从多 agent 框架开始搭结果卡了两周连一个稳定任务都跑不出来。先跑通比架构完美重要一万倍。6.3 常被忽略的评估指标最后说说多 agent 的评估问题。单 agent 时代大家习惯用一个“准确率”来评估效果多 agent 协作时代评估变得复杂得多我至少会看四个维度任务完成率最终输出是否达成了目标。协作效率整个系统完成一个任务所需的调用次数、token 总数、时间延迟。失败恢复能力某个子 agent 出错后系统能否重试、回退或换路径。可观测性出问题时能否快速定位到是哪个 agent 的哪次决策导致整体失败。很多团队把评估重点放在“效果类指标”上忽视了“成本类指标”和“稳定性指标”。但我做过几个多 agent 项目后的体会是稳定性和可观测性才是决定项目寿命的关键。效果再好只要线上隔三差五死循环、断链、逻辑漂移架构就会被业务方推翻。所以在设计多 agent 系统的第一天就要把日志埋点、trace ID 和状态快照记录下来。7. 常见问题与排错实录7.1 Agent 执行中断热词里有一条非常具体的技术问题“agent execution terminated due to error.”这基本是每个 agent 开发者都会撞上的第一道墙。原因多种多样但最常见的是上下文窗口超出限制或者单次工具调用的输入输出格式不合法。排查这类问题的思路要按固定流程来先看是哪一步出错。是模型决策生成出错还是代码执行工具时出错还是格式校验出错。如果是模型输出格式不合法多半是 prompt 里给的 JSON Schema 不够严格或者模型生成了多余的说明文字。对策是改用强制 JSON 输出的模式或者在后处理里加容错解析。如果是上下文窗口超限说明工作记忆压缩策略没生效。需要把历史对话摘要化或者调低日志冗余度。值得记住的是Agent 的每一次工具调用结果都建议做长度截断。我见过太多临时文件内容几十 KB全塞进上下文后面模型就开始胡言乱语。给工具输出加一个最大长度限制必要时只保留首尾各 1000 字符能解决九成以上的上下文爆炸问题。7.2 上下文爆炸与记忆污染“上下文爆炸”和“记忆污染”是同一个问题的两个侧面上下文越长模型越难聚焦于真正有用的信息。在多 agent 场景下这个问题更明显因为每个 agent 都要维护自己的上下文同时还要接收其他 agent 发来的消息。我推荐的实践是分层做信息管理任务描述层固定不变的系统指令永远放在 prompt 开头。动态状态层当前任务进度、已完成步骤、待办事项用结构化数据承载。工具结果层只保留最近两轮的完整工具输出早于这个的做摘要或丢弃。消息层其他 agent 发来的消息只保留与当前任务相关的字段。把信息分层之后再控制每层在 prompt 中的长度上限。你会发现模型决策质量的提升非常明显因为模型不是在 prompt 更长的时候更聪明而是在干扰更少的时候更稳定。7.3 多 Agent 死循环与任务漂移多 agent 协作最常见的两个故障模式第一是死循环Agent A 给 B 发消息B 生成结果不满足条件A 要求 B 重做B 反复重做却始终无法通过校验整个系统卡死。第二是任务漂移各个子 agent 说着说着聊偏了最终输出和初始任务只有微弱关联。应对这两个问题我的经验是两条给所有 agent 之间的消息加“步数上限”。无论流程有多复杂每个 agent 对任一任务的处理轮次都不允许超过 N 次达到上限就强制跳到兜底分支。每个子 agent 的 prompt 里都要有“任务锚点”。把原始任务目标作为不可变字段放在每个 agent 的上下文头部让它们随时能回看自己为什么存在。任务锚点能显著降低多轮协作中的漂移概率。关于理论如何落地的一点体会最后说点我自己在项目里的感受。很多人读完这种理论总结第一反应是“我全懂了”一旦动手又开始觉得无从下手这是我特别想帮大家避开的一个坑。理论的作用不是让人一步到位而是让人在踩坑时不迷茫。你单跑一个 ReAct 循环时可能不知道为什么需要 max steps只有当你见到 agent 陷入“自我对话”后才知道步数限制是一根保命绳。你搭多 agent 协作时可能觉得通信协议多此一举只有当你被两条 agent 的对讲信息搞得头晕时才发现结构化消息才是唯一能救你的东西。所以我给你的实际行动建议是这个星期先动手写一个不带任何框架的最小 agent只需要让模型能生成“调用工具”的指令你的代码去执行然后把结果喂回去。这一步跑通之后再回头看 LangGraph 的图结构、CrewAI 的角色机制你会发现所有抽象都能对号入座。理论篇到这里只是给你画了一幅地图真正的路还是要用代码踩出来。
阅读完成 · 觉得有帮助？
