尧图网站建设 
1. AI Agent 到底是什么别被概念绕晕这两年“AI Agent”这个词出现的频率高得就像当年“区块链”一样几乎每个技术群、每场分享会都在聊。但坦白讲市面上大部分讨论都停留在“Agent 是能自主决策的 AI”这种层面真正落到工程实现能讲清楚该做什么、不该做什么、每步怎么选的文章其实很少。我从 2023 年开始做 Agent 相关的落地项目从简单的意图路由、文档问答到后来带工具调用、多轮规划、多 Agent 协作的复杂系统踩过不少坑也推倒重来过好几次。回过头看Agent 工程化这件事本质上就两句话搞清楚一个 Agent 系统由哪些部分组成要素以及每个部分你怎么做选择决策点。这篇文章我想把自己在实操中沉淀的一套框架分享出来不搞虚的。你学完能直接拿着这套思路去设计自己的 Agent知道哪些环节容易翻车、哪些地方值得花力气、哪些坑可以提前避开。无论你是想用 Python 快速搭原型还是准备上 Rust 做高性能服务这套框架都适用。注意我讲的 Agent 是工程实现层面的不是学术论文里那种通用人工智能的定义。咱聊的是能跑、能维护、能上生产的系统。2. 为什么是七要素一个 Agent 系统的完整拼图先聊个我自己的经历。第一次做 Agent 项目时我满脑子都是“让它自己思考、自己调工具”结果做出来一个什么都想干、什么都干不好的四不像。反思之后发现问题出在我压根没把 Agent 系统的组成拆清楚——哪些部分是必需品哪些是选配哪些是核心难点心里没数。后来参考了几家大厂公开的 Agent 架构设计再结合自己的实践我总结出七个核心要素。这七个东西是一个 Agent 系统能跑起来的完整拼图缺一个就会有明显的短板。2.1 Agent Core决策与控制中枢Agent Core 是整个系统的大脑负责安排 Agent 怎么思考、怎么行动。业界最常见的实现方式是基于 ReAct 模式——也就是交替进行推理和行动模型先看当前状态决定下一步做什么调用工具拿到结果再继续推理直到完成目标。工程上怎么落地这个 Core两种主流路线第一种是直接依赖模型本身的指令跟随能力把推理过程全部压在一次模型调用里。这种方案简单但不可控模型可能跳过必要的检查直接给你答案。第二种是自己写状态机把一个复杂任务拆成多个状态比如“理解需求”“选工具”“查参数”“生成结果”每个状态里做什么、下一步去哪由代码控制。模型只负责状态内的小决策。控制力强但要写的代码多。我在生产项目里几乎都用第二种理由很简单——可控性。模型这东西是概率性的你不能把关键业务逻辑全压在概率上。状态机稳出问题也好排查。2.2 记忆系统短期与长期分开管理记忆是所有 Agent 系统里最容易被低估的部分。没有记忆Agent 就是个失忆的对话机器每轮都从零开始。记忆必须分两层短期记忆工作记忆管当前任务的上下文——用户在做什么、已经拿到什么结果、还差什么信息长期记忆管跨会话的持久化信息——用户的偏好、历史偏好、特定领域知识。工程实现上短期记忆常见方案是维护一个消息数组按长度或时间截断长期记忆基本就是上向量数据库按语义相似度检索相关内容回填到上下文里。这两种方案组合起来才有“越用越懂你”的效果。这里有一个项目里容易踩的坑短期记忆无脑把全部历史塞给模型。token 爆掉不说无关的旧信息还会干扰模型决策。正确做法是定期对历史做总结提炼保留关键结论丢掉过程噪音。2.3 规划能力把大任务拆成小步骤规划能力决定 Agent 面对复杂任务时是“拆解后逐一击破”还是“一锅乱炖”。主流的规划方式有三种第一种是模型自主规划让模型自己列出步骤清单好处是灵活坏处是模型经常会漏步骤或编造不存在的执行路径。第二种是模板规划针对高频任务写死执行流程稳定可靠但场景一变就得改代码。第三种是我个人比较推荐的混合模式预定义流程作为骨架模型在节点内做动态细化。比如做“市场调研”这个任务流程骨架固定是“搜信息、读页面、提炼要点、写报告”但具体搜什么关键词、看哪些页面由模型自己决定。2.4 工具调用Agent 的“手脚”怎么设计工具是 Agent 跟外部世界交互的唯一途径。一个只会聊天不会干活的 Agent 叫聊天机器人接了工具才叫 Agent。工具设计的核心不只是写个函数然后注册给模型而是要考虑三件事工具描述写得清不清楚、参数定义得好不好、返回结果规不规范。模型靠工具描述来决定“什么时候该用这个工具”描述写得太泛它会在不该用的时候用参数约束不严格它就会乱传值。返回结果我是统一封装成结构化格式包含状态码和数据方便 Agent 判断下一步。另外工具数量超过十几个模型的选择准确率会明显下降。解决办法是给工具分组先让 Agent 决定去哪个组找再在组内选具体工具相当于做两次检索能够显著提升准确率。2.5 上下文管理信息的筛选与组织上下文管理是我做 Agent 项目里投入时间最多的部分之一。因为大模型的上下文窗口再怎么大也有限而 Agent 执行任务过程中会大量产生中间信息怎么筛选和编排这些信息直接影响回答质量。我的做法是建立一个简短的上下文框架里面分区域用户目标区、进度区、关键事实区、输出区。每个区域有规定的最大长度超出就做摘要压缩。这有点像记笔记你不会把课堂录音全记下来你记的是重点、结论、待办。上下文管理做不好Agent 就会出现很典型的“中途失忆”现象——前面已经确定的信息后面又重复问用户体验极差。2.6 反思与纠错让 Agent 能自己发现问题很多 Agent 看起来“傻”不是模型不行是系统压根没有容错机制。模型生成结果不可能百分百正确所以你必须预设“错了怎么办”。纠错有两个层级。低层级是工具调用失败重试比如请求超时、参数非法捕获异常后重新调用或让模型修正参数。高层级是结果质量校验比如让 Agent 自己检查生成内容是否满足最初的目标、是否有遗漏需求不满足就重新执行。反思机制我建议做成显式的步骤。比如在完成初稿后固定加一步“质量审查”由模型扮演审查者角色挑毛病、列问题再回到执行环节修改。这一步能明显提升最终输出质量代价就是多花一些 token但你做的是正经产品别省这个钱。2.7 安全与权限上线前必须想清楚的事安全是七要素里最不性感但最重要的一项。Agent 是要调用工具、操作资源的权限把控不好轻则出乱子重则出事故。我见过不少团队在做 Agent 原型时把所有用户请求都当成可信输入让 Agent 自由调用所有工具结果就是糟糕的 prompt injection 就能让 Agent 去执行敏感操作比如删数据、发消息、改配置。工程上必须做三件事一是工具分级执行类工具要走审批流或者加二次确认二是数据隔离每个会话只能访问自己的数据团队项目要做租户隔离三是加入审计日志把 Agent 的每个行动都记录下来既能追溯也能当调试素材。七要素这套框架最大的价值是让团队在动手之前就能把所有该考虑的点摆上桌面——不会做了三个月突然发现少了记忆模块要回炉重造。这个教训我是实打实付出过代价的。3. 七个决策点从设计到上线的关键选择要素回答的是“系统里该有什么”决策点回答的是“每件事具体怎么做选择”。我总结了七个在实操中绕不开的决策点基本覆盖了从设计到上线的全链路。3.1 决策一用什么方式驱动 Agent 的思考循环这是最底层的一个决策决定了你的 Agent 是偏“拟人化推理”还是偏“工程化流程”。目前常见的方式有 ReAct推理加行动交替、Plan-and-Execute先计划后执行、以及纯粹的 Workflow 编排。我之前负责过一个智能客服项目最初用纯 ReAct 让模型自由发挥结果就是十分钟的任务模型绕来绕去用了二十分钟还经常跑偏。后来改成 Plan-and-Execute让模型先输出整个计划然后逐条执行效果立刻改善响应时间几乎减半。我的建议任务链条短、步骤不确定性强选 ReAct任务链条长、但步骤相对标准选 Plan-and-Execute如果你的业务步骤完全固定那其实不需要 Agent纯 workflow 就够了别为了追概念给自己加复杂度。3.2 决策二选大模型 API 还是本地部署模型这个决策关系到成本、性能和数据安全。我自己两种模式都深度用过谈不上谁绝对好纯粹看场景。调 API 的优势是省事、模型能力强、迭代快。劣势是数据要出网、单次调用的延迟和费用不可控。本地部署的优势是数据安全、可定制、长期成本低劣势是初期硬件投入高、运维复杂。坦白说如果团队没有专门的推理优化工程师本地部署很容易变成灾难现场。我的建议初创阶段或验证期无脑用 API把精力花在 Agent 逻辑本身到了规模化阶段算算账如果调用量真的很大再用本地部署做成本优化。有个折中方案我也想提一下就是混合部署核心决策用强模型 API一些简单的、高频的辅助环节用本地小模型。比如工具选择的分类判断用小模型做真正需要复杂推理时才调用大模型成本能降不少。3.3 决策三采用单 Agent 还是多 Agent 架构多 Agent 架构这几年被炒得很热好像不搞几个角色分工协作就不高级。但我的真实感受是90% 的项目用单 Agent 就够了硬上多 Agent 反而是自找麻烦。多 Agent 的复杂度是成倍增加的。Agent 之间的通信协议、任务分配策略、死锁与循环处理每一个都是新的工程难题。我做过一个尝试用三个 Agent 协作处理数据分析任务的系统最后发现光协调它们不乱抢任务就写了上千行代码效果还不比单 Agent 好多少。我的建议能用单 Agent 解决的事别硬拆。只有当你遇到真正需要并行处理多个独立子任务、且各子任务领域差异极大时才考虑多 Agent。而且要尽量设计成“主从模式”——一个主 Agent 负责任务分解和结果汇总从 Agent 只干最单一的活别搞对等协作否则你会被各种边界情况折磨疯。3.4 决策四Prompt 工程还是微调这个决策卡住了很多人。我想先给一个比较反直觉的结论很多问题根本不需要微调是你的 prompt 写得不够好。Prompt 能解决的问题角色设定、输出格式、工具使用方式、少数示例。微调能解决的问题特定的语气风格、专业的领域知识、固定的输出结构。如果你的需求集中在“让模型更听话”这个层面先优化 prompt别急着微调。我做知识库问答时发现有段时间回答质量下降一查原因是用户提问带口语化表达模型理解偏了。后来在 prompt 里加了一步“意图改写”让模型先把用户口语转成标准查询语句再做检索准确率立刻回升。这种优化靠 prompt 就能解决根本不需要动模型。我的建议把微调当成最后一招。先试 prompt 优化、再加示例few-shot、再考虑加检索增强RAG、最后才轮到微调。因为微调成本高、周期长而且微调后的模型在某些通用能力上会退化。这个顺序是我用真金白银换来的经验。3.5 决策五要不要上 RAG以及怎么上RAG检索增强生成是 Agent 系统里最常用也最容易被滥用的模块。说最常用是因为 Agent 做事实性回答时必须得有外部知识支撑说容易被滥用是因为很多场景根本不需要 RAG硬加一个检索环节反而拉胯效果。我一个朋友的客服项目就是这样历史对话数据质量很差他们硬是搭了个向量知识库结果召回的内容全是噪音回答效果还不如直接让模型基于有限历史做总结。后来把数据清理好、做结构化RAG 才真正发挥价值。我的建议上不上 RAG先问自己一个问题——“模型本身的参数知识够不够回答这个问题”如果不够再考虑 RAG。而且 RAG 不是一个 API 调一下就完事你要处理数据清洗、切分策略、向量化模型选择、检索排序、相关性重排每一环都需要单独优化。切分策略我多说一句。现在很多人用固定长度切分文本省事但效果差。段落切分或按语义切分召回率明显更高。我实测过同一批文档单纯改切分方式答案准确率能提升十个百分点以上。3.6 决策六Agent 的确定性怎么控制模型天生是概率性的同一个问题输入两次可能得到不同答案。但在很多真实业务场景里你希望 Agent 的行为是可预测的——尤其涉及操作类、交易类动作时同一个按钮不能让 Agent 这次点了下次不点。确定性控制有几种做法。温度参数调低甚至设为 0只影响模型的随机性不影响模型的“策略选择”限定工具选择范围用规则给 Agent 指定这一步只能选哪个工具决策和生成分离选择类动作用小策略模型或规则生成类内容才用大模型关键路径做代码兜底不把核心业务逻辑交给模型自由发挥。我之前在处理结算流程的 Agent 中把“判断能否结账”这一环节直接写成规则代码只有当规则判断不明确时才让模型介入。效果就是在关键节点上实现百分之百确定性这个思路大家可以参考。3.7 决策七效果评估怎么做最后这个决策是很多团队最容易忽略的。Agent 系统上线后怎么科学评估效果如果不做评估你根本不知道改一个 prompt 是变好了还是变坏了。传统问答的评估方式是准确率但 Agent 是多步骤系统评估要分层拆开。单步评估每个步骤的输出是否符合预期工具调用评估是否在正确时机调用了正确工具参数有没有传对最终结果评估整体目标达成的质量。具体做法上我建议建立评估集至少有五十到一百条覆盖典型场景的测试用例每条用例标注正确答案和关键步骤。每次改动后跑一遍完整评估对比得分变化。还可以引入第二个人工用“AI 评估 AI”——让 GPT-4 当裁判给 Agent 的输出质量打分和人工标注做交叉验证能极大节省评估精力。我团队里的节奏是每个迭代必须跑评估集跑不过不允许上线。你有这个习惯后优化才有方向不然每次都是玄学调参、盲人摸象。4. 实战参考一个 Agent 系统的完整搭建过程理论说再多不如直接来一个能落地的最小案例。这里我用“智能周报生成助手”这个例子走一遍完整的搭建流程。这个场景特别适合入门练手因为它同时涉及信息收集、工具调用、文本生成三类核心能力但流程又不复杂。4.1 需求拆解与流程设计目标是做一个能自动收集项目动态、生成周报的 Agent。信息来自两个地方代码仓库的提交记录和团队内部的项目管理系统任务更新。流程设计为四步第一步收集信息拉取仓库和项目系统的数据第二步信息整理对原始记录去重、归类第三步撰写周报按模板输出结构化内容第四步质量校验检查内容完整性和数据准确性。流程骨架是固定的所以这个场景对应我前面说的“Plan-and-Execute 模板流程”的组合。模型在每一步内做细节决策大方向由代码控制。4.2 工具层实现代码仓库与令牌管理工具层要写两个工具函数。第一个是获取代码提交记录调用 Git 相关接口按日期筛选返回提交信息列表封装成统一结构提交人、时间、标题、描述、涉及文件。第二个是获取项目任务动态调用项目管理平台的 API同样封装成统一的返回结构。这里有个细节要注意鉴权和令牌的有效期管理。我第一次做的时候直接把令牌写死在环境变量里结果到期后 Agent 调工具一直报错排查了半天才发现是令牌过期了。之后我做了令牌自动刷新机制在工具封装层统一处理每次调用前检查令牌有效期接近过期就提前刷新。这算是一个比较典型的工程化坑。另外工具返回值的大小也要控制。Git 仓库的提交记录可能一次拉回来几百条全塞进上下文模型会很吃力。我的做法是只要提交标题和文件列表详细描述先不要等 Agent 判断需要看某条提交的细节时再单独调用扩展接口。这种“按需获取”的思路在 Agent 工具设计中非常重要。4.3 核心逻辑编排状态机与控制流核心编排层我用一个简单的状态机来控制流程。状态包括 INIT、COLLECTING、PROCESSING、WRITING、VALIDATING、DONE、FAILED。每个状态对应一个处理函数一个状态处理完根据结果决定迁移到哪个状态。以 COLLECTING 状态为例它的处理逻辑是并行调用两个工具函数获取原始数据数据拿回来之后预处理压缩成信息摘要然后迁移到 PROCESSING 状态。如果工具调用失败重试两次仍然失败则迁移到 FAILED 状态并记录错误原因。PROCESSING 阶段模型的作用是对摘要做分类整理把任务更新按“开发、测试、运营、产品”等标签归类。这里提示词的设计很关键我附加了严格的输出格式要求规定只输出 JSON 数组且每个条目必须包含类别字段这样下一步 WRITING 阶段拿到的就是干净的结构化数据。WRITING 阶段把整理后的数据填入周报模板。模板定了四个板块本周进展、风险与问题、下周计划、需要协调事项。模型只需要填充具体内容不要自己创新结构。VALIDATING 阶段用另一个模型实例扮演校对者检查周报里有没有信息缺失、日期错误、前后矛盾等问题。有问题就打回 WRITING 阶段重写没问题就输出最终结果。这套状态机整体写下来大概是三四百行代码但逻辑非常清晰每一步出了问题都知道去哪里排查。这也是我为什么强调状态机优于自由推理的原因——可观测性和可调优性完全不在一个量级。4.4 运行验证与踩坑记录第一次整体跑的时候暴露了几个问题。信息收集阶段速度很慢分析日志发现是工具调用串行执行改成并行调用后耗时少了近一半。这是很容易被忽略的性能问题值得大家在做工具调用封装时就把并发支持设计进去。另一个问题是周报生成阶段模型偶尔会漏掉某个项目的内容但整体框架看起来又很完整不仔细核对发现不了。后来在校验阶段加了一条硬规则必须列出原始信息中的项目清单然后逐项比对周报中是否都已覆盖。模型给出的“周报已完整”结论是靠不住的规则化的交叉验证才能兜底。运行调优后整个流程完整跑下来稳定多了输出质量也达到了可以直接使用的程度。这个案例虽然简单但已经把 Agent 系统该有的核心模块都过了一遍。5. 主流技术栈方案Python、Rust 与全栈框架聊完设计再聊聊实现层面的技术选型。不同语言和框架做 Agent体验差别很大。我分别说一下 Python 和 Rust 生态的情况以及全栈框架的取舍。5.1 Python 生态快速迭代首选Python 做 Agent 原型和业务落地核心优势是生态成熟、库多、人好招。目前我做 Agent 的主力语言至今还是 Python原因就是效率高。在 Agent 框架选择上LangChain 和 LlamaIndex 是最常被提起的两个。但我的真实使用体验是可以用它们做项目前期验证但真正上生产项目时我倾向于只用框架里的基础组件核心编排还是自己写。LangChain 这类框架的问题在于抽象层级太多出了问题不好排查。一个简单的链式调用底层帮你做了大量隐式处理一旦结果不对你很难判断是模型的问题、提示词的问题、还是框架内部的某个组件行为异常。相比之下自己写个几十行的状态机逻辑一目了然。但是纯手写也有代价。工具函数的输入输出封装、模型调用的重试机制、上下文的压缩逻辑这些都自己写的话工作量不小。我的建议是自己实现编排层和控制层用现成库处理工具解析和模型调用这类相对标准的部分。5.2 Rust 生态高性能与高可靠性的选择最近“基于 Rust 的 AI Agent”热度高涨我理解这个趋势背后的逻辑。Rust 的优势在于高性能真的需要极低延迟的场景、强类型安全编译期间就能发现一批问题和资源占用低做大规模部署时成本优势明显。Rust 生态里做 Agent 目前比较活跃的方向一是基于类型的工具定义宏用过程宏自动生成模型的工具描述在编译期完成工具接口的类型检查这比 Python 的运行时解析要安全得多二是内嵌模型推理库比如用 candle 或 llama.cpp 的绑定实现本地推理和 Rust 的应用代码无缝集成三是 Actor 模型并发Rust 的 Actor 模型天然适合多 Agent 通信的场景在语言层面保证消息传递的安全性。但 Rust 做 Agent 的缺点是显而易见的开发效率比 Python 低生态不够成熟很多功能要自己从零造轮子。我的判断是Rust 适合大型的、对性能和稳定性要求极高的生产系统或者需要深度嵌入到已有 Rust 基础设施里的场景。如果你是在做应用层产品原型Python 依然是更务实的起点。5.3 全栈框架对比LangChain、AutoGen、CrewAI 等现在市面上的 Agent 全栈框架我按使用场景分成三类研发框架型LangChain、LlamaIndex 等适合做 RAG、链式调用等相对标准的能力组合灵活但复杂度在你自己掌控多 Agent 协作型AutoGen、CrewAI 等适合做多角色协作场景能用但千万别默认多 Agent 就比单 Agent 好企业级平台型阿里云百炼、Dify 等最省心可视化拖拽适合不懂代码的业务团队做流程编排但要警惕被平台绑定。给一个判断标准如果你的团队有 AI 工程师想深度定制自研核心加开源组件是上策如果完全是业务团队要快速出效果直接上企业级平台更快别自己在底层折腾。6. Agent 实战中的典型问题与排查思路工程类文章最有价值的其实是“踩坑记录”。我把自己和身边朋友做 Agent 时遇到的问题整理成一张速查表按场景、表现、排查思路三个维度展开帮大家少走弯路。6.1 工具调用类问题Agent 该调工具不调、不该调乱调、或者参数传错这些是最高频的问题。我遇到过一个典型情况Agent 在回答“昨天项目进展如何”时不先查数据直接靠模型幻觉编了一份进展出来问题是编得还挺像那么回事。排查思路分三步第一步检查工具描述是否清晰描述要写清楚工具的适用场景、输入参数的含义和边界让模型有足够依据做判断第二步检查工具返回格式如果返回的是非结构化文本模型解析很容易失败统一改成 JSON 结构第三步加一层显式的“是否需要查询”判断让模型在回答前先向自己发问“当前问题我是否确定答案”不确定就调用工具。参数传错的问题典型是模型把时间范围格式搞错把“2024-01-01”传成“01/01/2024”。解决办法是在工具参数定义里加格式约束描述同时在工具函数里做防御性解析解析失败就自动尝试常见格式变体再失败就带着错误信息返回给模型让它修正重试。6.2 上下文与记忆类问题中途失忆、前后矛盾、越来越慢这类问题的根源几乎都在上下文管理。失忆就是上下文被截断或压缩过度关键信息丢了前后矛盾是早期的结论没保留到后期越来越慢是历史消息无限累加导致 token 开销越来越大、响应时间越来越长。我的排查思路是检查上下文各区域的长度分配。如果“历史对话区”占比过高说明缺少总结机制如果“用户目标区”为空说明系统根本没把目标持久化。这里我的标准做法是维护一个结构化的记忆对象包含用户目标、关键事实、当前进度、已得结论四个字段每轮对话结束后更新。模型回答时优先参考这个结构化记忆而不是去翻原始历史。6.3 规划与执行类问题Agent 规划出来的步骤做一半就停、说要做三件事只做了两件、或者在某个步骤里反复循环出不来。这些问题的共性原因是规划和执行脱节了——模型规划时没有考虑实际可用工具和已知约束。排查分两层。在规划层检查模型是否知道当前有哪些工具、每个工具的能力边界。我建议在系统提示词里给工具清单并写明每个工具能干什么不能干什么同时要求模型在规划时明确标注“此步骤使用哪个工具”。在执行层加一个步骤计数器超过预设最大步骤数就强制终止触发了就说明规划有严重问题需要回溯分析。循环问题除了加最大步数限制还要监控相同状态的重复进入次数。比如某个状态连续被进入三次且结果相同就该让 Agent 停下来重新规划而不是硬着头皮继续转。6.4 质量与成本类问题Agent 回答质量不稳定、token 消耗过高这两个问题通常同时出现且互相影响。质量不稳最常见的原因是校验缺失生成完直接输出没有自查。成本过高的原因是规划粒度过细、无效调用过多以及上下文膨胀。解决办法是建立输出质量评分机制每次生成后让评估模型打分低于阈值就重新生成或走人工兜底。在成本侧把模型的调用记录全部日志化按步骤分析每次调用的 token 消耗找出大头针对性地做压缩或跳过优化。这里分享一个我验证过有效的手段对每步调用设置 token 上限超出就拦截并转为小模型处理或规则兜底。这能直接砍掉一批异常调用同时让问题暴露得更早。7. 写在最后的实操体会做 Agent 工程化这些年我最大的感受是Agent 不是一个神秘的“人工智能黑盒”它本质上就是一个精心编排的工程系统。模型的推理能力是基础但决定系统上限的是你对流程的控制、对上下文的组织、对工具的设计、对异常的兜底。如果你想入这个方向我的建议是先找一个具体的小场景比如周报生成、信息检索、客服接待用最简单的方式完整跑通然后在迭代中逐步加入记忆、规划、反思、评估这些模块。别一上来就搞多 Agent、搞复杂编排先做好一个再扩展。另外一个想提醒的是Agent 的评估和运维一定要从第一天就做起来。没有评估就没有优化方向没有日志就没有排查线索。这两个是 Agent 工程质量的生命线比任何花哨的功能都重要。最后如果你在动手过程中遇到什么有意思的坑或者有更好的工程实践欢迎多交流。Agent 这个方向还在快速发展工具的迭代、模型能力的提升、架构的演进都很快保持学习、保持动手才不会被抛下。 AI Agent 工程化落地：七要素与核心决策点实战指南
1. AI Agent 到底是什么别被概念绕晕这两年“AI Agent”这个词出现的频率高得就像当年“区块链”一样几乎每个技术群、每场分享会都在聊。但坦白讲市面上大部分讨论都停留在“Agent 是能自主决策的 AI”这种层面真正落到工程实现能讲清楚该做什么、不该做什么、每步怎么选的文章其实很少。我从 2023 年开始做 Agent 相关的落地项目从简单的意图路由、文档问答到后来带工具调用、多轮规划、多 Agent 协作的复杂系统踩过不少坑也推倒重来过好几次。回过头看Agent 工程化这件事本质上就两句话搞清楚一个 Agent 系统由哪些部分组成要素以及每个部分你怎么做选择决策点。这篇文章我想把自己在实操中沉淀的一套框架分享出来不搞虚的。你学完能直接拿着这套思路去设计自己的 Agent知道哪些环节容易翻车、哪些地方值得花力气、哪些坑可以提前避开。无论你是想用 Python 快速搭原型还是准备上 Rust 做高性能服务这套框架都适用。注意我讲的 Agent 是工程实现层面的不是学术论文里那种通用人工智能的定义。咱聊的是能跑、能维护、能上生产的系统。2. 为什么是七要素一个 Agent 系统的完整拼图先聊个我自己的经历。第一次做 Agent 项目时我满脑子都是“让它自己思考、自己调工具”结果做出来一个什么都想干、什么都干不好的四不像。反思之后发现问题出在我压根没把 Agent 系统的组成拆清楚——哪些部分是必需品哪些是选配哪些是核心难点心里没数。后来参考了几家大厂公开的 Agent 架构设计再结合自己的实践我总结出七个核心要素。这七个东西是一个 Agent 系统能跑起来的完整拼图缺一个就会有明显的短板。2.1 Agent Core决策与控制中枢Agent Core 是整个系统的大脑负责安排 Agent 怎么思考、怎么行动。业界最常见的实现方式是基于 ReAct 模式——也就是交替进行推理和行动模型先看当前状态决定下一步做什么调用工具拿到结果再继续推理直到完成目标。工程上怎么落地这个 Core两种主流路线第一种是直接依赖模型本身的指令跟随能力把推理过程全部压在一次模型调用里。这种方案简单但不可控模型可能跳过必要的检查直接给你答案。第二种是自己写状态机把一个复杂任务拆成多个状态比如“理解需求”“选工具”“查参数”“生成结果”每个状态里做什么、下一步去哪由代码控制。模型只负责状态内的小决策。控制力强但要写的代码多。我在生产项目里几乎都用第二种理由很简单——可控性。模型这东西是概率性的你不能把关键业务逻辑全压在概率上。状态机稳出问题也好排查。2.2 记忆系统短期与长期分开管理记忆是所有 Agent 系统里最容易被低估的部分。没有记忆Agent 就是个失忆的对话机器每轮都从零开始。记忆必须分两层短期记忆工作记忆管当前任务的上下文——用户在做什么、已经拿到什么结果、还差什么信息长期记忆管跨会话的持久化信息——用户的偏好、历史偏好、特定领域知识。工程实现上短期记忆常见方案是维护一个消息数组按长度或时间截断长期记忆基本就是上向量数据库按语义相似度检索相关内容回填到上下文里。这两种方案组合起来才有“越用越懂你”的效果。这里有一个项目里容易踩的坑短期记忆无脑把全部历史塞给模型。token 爆掉不说无关的旧信息还会干扰模型决策。正确做法是定期对历史做总结提炼保留关键结论丢掉过程噪音。2.3 规划能力把大任务拆成小步骤规划能力决定 Agent 面对复杂任务时是“拆解后逐一击破”还是“一锅乱炖”。主流的规划方式有三种第一种是模型自主规划让模型自己列出步骤清单好处是灵活坏处是模型经常会漏步骤或编造不存在的执行路径。第二种是模板规划针对高频任务写死执行流程稳定可靠但场景一变就得改代码。第三种是我个人比较推荐的混合模式预定义流程作为骨架模型在节点内做动态细化。比如做“市场调研”这个任务流程骨架固定是“搜信息、读页面、提炼要点、写报告”但具体搜什么关键词、看哪些页面由模型自己决定。2.4 工具调用Agent 的“手脚”怎么设计工具是 Agent 跟外部世界交互的唯一途径。一个只会聊天不会干活的 Agent 叫聊天机器人接了工具才叫 Agent。工具设计的核心不只是写个函数然后注册给模型而是要考虑三件事工具描述写得清不清楚、参数定义得好不好、返回结果规不规范。模型靠工具描述来决定“什么时候该用这个工具”描述写得太泛它会在不该用的时候用参数约束不严格它就会乱传值。返回结果我是统一封装成结构化格式包含状态码和数据方便 Agent 判断下一步。另外工具数量超过十几个模型的选择准确率会明显下降。解决办法是给工具分组先让 Agent 决定去哪个组找再在组内选具体工具相当于做两次检索能够显著提升准确率。2.5 上下文管理信息的筛选与组织上下文管理是我做 Agent 项目里投入时间最多的部分之一。因为大模型的上下文窗口再怎么大也有限而 Agent 执行任务过程中会大量产生中间信息怎么筛选和编排这些信息直接影响回答质量。我的做法是建立一个简短的上下文框架里面分区域用户目标区、进度区、关键事实区、输出区。每个区域有规定的最大长度超出就做摘要压缩。这有点像记笔记你不会把课堂录音全记下来你记的是重点、结论、待办。上下文管理做不好Agent 就会出现很典型的“中途失忆”现象——前面已经确定的信息后面又重复问用户体验极差。2.6 反思与纠错让 Agent 能自己发现问题很多 Agent 看起来“傻”不是模型不行是系统压根没有容错机制。模型生成结果不可能百分百正确所以你必须预设“错了怎么办”。纠错有两个层级。低层级是工具调用失败重试比如请求超时、参数非法捕获异常后重新调用或让模型修正参数。高层级是结果质量校验比如让 Agent 自己检查生成内容是否满足最初的目标、是否有遗漏需求不满足就重新执行。反思机制我建议做成显式的步骤。比如在完成初稿后固定加一步“质量审查”由模型扮演审查者角色挑毛病、列问题再回到执行环节修改。这一步能明显提升最终输出质量代价就是多花一些 token但你做的是正经产品别省这个钱。2.7 安全与权限上线前必须想清楚的事安全是七要素里最不性感但最重要的一项。Agent 是要调用工具、操作资源的权限把控不好轻则出乱子重则出事故。我见过不少团队在做 Agent 原型时把所有用户请求都当成可信输入让 Agent 自由调用所有工具结果就是糟糕的 prompt injection 就能让 Agent 去执行敏感操作比如删数据、发消息、改配置。工程上必须做三件事一是工具分级执行类工具要走审批流或者加二次确认二是数据隔离每个会话只能访问自己的数据团队项目要做租户隔离三是加入审计日志把 Agent 的每个行动都记录下来既能追溯也能当调试素材。七要素这套框架最大的价值是让团队在动手之前就能把所有该考虑的点摆上桌面——不会做了三个月突然发现少了记忆模块要回炉重造。这个教训我是实打实付出过代价的。3. 七个决策点从设计到上线的关键选择要素回答的是“系统里该有什么”决策点回答的是“每件事具体怎么做选择”。我总结了七个在实操中绕不开的决策点基本覆盖了从设计到上线的全链路。3.1 决策一用什么方式驱动 Agent 的思考循环这是最底层的一个决策决定了你的 Agent 是偏“拟人化推理”还是偏“工程化流程”。目前常见的方式有 ReAct推理加行动交替、Plan-and-Execute先计划后执行、以及纯粹的 Workflow 编排。我之前负责过一个智能客服项目最初用纯 ReAct 让模型自由发挥结果就是十分钟的任务模型绕来绕去用了二十分钟还经常跑偏。后来改成 Plan-and-Execute让模型先输出整个计划然后逐条执行效果立刻改善响应时间几乎减半。我的建议任务链条短、步骤不确定性强选 ReAct任务链条长、但步骤相对标准选 Plan-and-Execute如果你的业务步骤完全固定那其实不需要 Agent纯 workflow 就够了别为了追概念给自己加复杂度。3.2 决策二选大模型 API 还是本地部署模型这个决策关系到成本、性能和数据安全。我自己两种模式都深度用过谈不上谁绝对好纯粹看场景。调 API 的优势是省事、模型能力强、迭代快。劣势是数据要出网、单次调用的延迟和费用不可控。本地部署的优势是数据安全、可定制、长期成本低劣势是初期硬件投入高、运维复杂。坦白说如果团队没有专门的推理优化工程师本地部署很容易变成灾难现场。我的建议初创阶段或验证期无脑用 API把精力花在 Agent 逻辑本身到了规模化阶段算算账如果调用量真的很大再用本地部署做成本优化。有个折中方案我也想提一下就是混合部署核心决策用强模型 API一些简单的、高频的辅助环节用本地小模型。比如工具选择的分类判断用小模型做真正需要复杂推理时才调用大模型成本能降不少。3.3 决策三采用单 Agent 还是多 Agent 架构多 Agent 架构这几年被炒得很热好像不搞几个角色分工协作就不高级。但我的真实感受是90% 的项目用单 Agent 就够了硬上多 Agent 反而是自找麻烦。多 Agent 的复杂度是成倍增加的。Agent 之间的通信协议、任务分配策略、死锁与循环处理每一个都是新的工程难题。我做过一个尝试用三个 Agent 协作处理数据分析任务的系统最后发现光协调它们不乱抢任务就写了上千行代码效果还不比单 Agent 好多少。我的建议能用单 Agent 解决的事别硬拆。只有当你遇到真正需要并行处理多个独立子任务、且各子任务领域差异极大时才考虑多 Agent。而且要尽量设计成“主从模式”——一个主 Agent 负责任务分解和结果汇总从 Agent 只干最单一的活别搞对等协作否则你会被各种边界情况折磨疯。3.4 决策四Prompt 工程还是微调这个决策卡住了很多人。我想先给一个比较反直觉的结论很多问题根本不需要微调是你的 prompt 写得不够好。Prompt 能解决的问题角色设定、输出格式、工具使用方式、少数示例。微调能解决的问题特定的语气风格、专业的领域知识、固定的输出结构。如果你的需求集中在“让模型更听话”这个层面先优化 prompt别急着微调。我做知识库问答时发现有段时间回答质量下降一查原因是用户提问带口语化表达模型理解偏了。后来在 prompt 里加了一步“意图改写”让模型先把用户口语转成标准查询语句再做检索准确率立刻回升。这种优化靠 prompt 就能解决根本不需要动模型。我的建议把微调当成最后一招。先试 prompt 优化、再加示例few-shot、再考虑加检索增强RAG、最后才轮到微调。因为微调成本高、周期长而且微调后的模型在某些通用能力上会退化。这个顺序是我用真金白银换来的经验。3.5 决策五要不要上 RAG以及怎么上RAG检索增强生成是 Agent 系统里最常用也最容易被滥用的模块。说最常用是因为 Agent 做事实性回答时必须得有外部知识支撑说容易被滥用是因为很多场景根本不需要 RAG硬加一个检索环节反而拉胯效果。我一个朋友的客服项目就是这样历史对话数据质量很差他们硬是搭了个向量知识库结果召回的内容全是噪音回答效果还不如直接让模型基于有限历史做总结。后来把数据清理好、做结构化RAG 才真正发挥价值。我的建议上不上 RAG先问自己一个问题——“模型本身的参数知识够不够回答这个问题”如果不够再考虑 RAG。而且 RAG 不是一个 API 调一下就完事你要处理数据清洗、切分策略、向量化模型选择、检索排序、相关性重排每一环都需要单独优化。切分策略我多说一句。现在很多人用固定长度切分文本省事但效果差。段落切分或按语义切分召回率明显更高。我实测过同一批文档单纯改切分方式答案准确率能提升十个百分点以上。3.6 决策六Agent 的确定性怎么控制模型天生是概率性的同一个问题输入两次可能得到不同答案。但在很多真实业务场景里你希望 Agent 的行为是可预测的——尤其涉及操作类、交易类动作时同一个按钮不能让 Agent 这次点了下次不点。确定性控制有几种做法。温度参数调低甚至设为 0只影响模型的随机性不影响模型的“策略选择”限定工具选择范围用规则给 Agent 指定这一步只能选哪个工具决策和生成分离选择类动作用小策略模型或规则生成类内容才用大模型关键路径做代码兜底不把核心业务逻辑交给模型自由发挥。我之前在处理结算流程的 Agent 中把“判断能否结账”这一环节直接写成规则代码只有当规则判断不明确时才让模型介入。效果就是在关键节点上实现百分之百确定性这个思路大家可以参考。3.7 决策七效果评估怎么做最后这个决策是很多团队最容易忽略的。Agent 系统上线后怎么科学评估效果如果不做评估你根本不知道改一个 prompt 是变好了还是变坏了。传统问答的评估方式是准确率但 Agent 是多步骤系统评估要分层拆开。单步评估每个步骤的输出是否符合预期工具调用评估是否在正确时机调用了正确工具参数有没有传对最终结果评估整体目标达成的质量。具体做法上我建议建立评估集至少有五十到一百条覆盖典型场景的测试用例每条用例标注正确答案和关键步骤。每次改动后跑一遍完整评估对比得分变化。还可以引入第二个人工用“AI 评估 AI”——让 GPT-4 当裁判给 Agent 的输出质量打分和人工标注做交叉验证能极大节省评估精力。我团队里的节奏是每个迭代必须跑评估集跑不过不允许上线。你有这个习惯后优化才有方向不然每次都是玄学调参、盲人摸象。4. 实战参考一个 Agent 系统的完整搭建过程理论说再多不如直接来一个能落地的最小案例。这里我用“智能周报生成助手”这个例子走一遍完整的搭建流程。这个场景特别适合入门练手因为它同时涉及信息收集、工具调用、文本生成三类核心能力但流程又不复杂。4.1 需求拆解与流程设计目标是做一个能自动收集项目动态、生成周报的 Agent。信息来自两个地方代码仓库的提交记录和团队内部的项目管理系统任务更新。流程设计为四步第一步收集信息拉取仓库和项目系统的数据第二步信息整理对原始记录去重、归类第三步撰写周报按模板输出结构化内容第四步质量校验检查内容完整性和数据准确性。流程骨架是固定的所以这个场景对应我前面说的“Plan-and-Execute 模板流程”的组合。模型在每一步内做细节决策大方向由代码控制。4.2 工具层实现代码仓库与令牌管理工具层要写两个工具函数。第一个是获取代码提交记录调用 Git 相关接口按日期筛选返回提交信息列表封装成统一结构提交人、时间、标题、描述、涉及文件。第二个是获取项目任务动态调用项目管理平台的 API同样封装成统一的返回结构。这里有个细节要注意鉴权和令牌的有效期管理。我第一次做的时候直接把令牌写死在环境变量里结果到期后 Agent 调工具一直报错排查了半天才发现是令牌过期了。之后我做了令牌自动刷新机制在工具封装层统一处理每次调用前检查令牌有效期接近过期就提前刷新。这算是一个比较典型的工程化坑。另外工具返回值的大小也要控制。Git 仓库的提交记录可能一次拉回来几百条全塞进上下文模型会很吃力。我的做法是只要提交标题和文件列表详细描述先不要等 Agent 判断需要看某条提交的细节时再单独调用扩展接口。这种“按需获取”的思路在 Agent 工具设计中非常重要。4.3 核心逻辑编排状态机与控制流核心编排层我用一个简单的状态机来控制流程。状态包括 INIT、COLLECTING、PROCESSING、WRITING、VALIDATING、DONE、FAILED。每个状态对应一个处理函数一个状态处理完根据结果决定迁移到哪个状态。以 COLLECTING 状态为例它的处理逻辑是并行调用两个工具函数获取原始数据数据拿回来之后预处理压缩成信息摘要然后迁移到 PROCESSING 状态。如果工具调用失败重试两次仍然失败则迁移到 FAILED 状态并记录错误原因。PROCESSING 阶段模型的作用是对摘要做分类整理把任务更新按“开发、测试、运营、产品”等标签归类。这里提示词的设计很关键我附加了严格的输出格式要求规定只输出 JSON 数组且每个条目必须包含类别字段这样下一步 WRITING 阶段拿到的就是干净的结构化数据。WRITING 阶段把整理后的数据填入周报模板。模板定了四个板块本周进展、风险与问题、下周计划、需要协调事项。模型只需要填充具体内容不要自己创新结构。VALIDATING 阶段用另一个模型实例扮演校对者检查周报里有没有信息缺失、日期错误、前后矛盾等问题。有问题就打回 WRITING 阶段重写没问题就输出最终结果。这套状态机整体写下来大概是三四百行代码但逻辑非常清晰每一步出了问题都知道去哪里排查。这也是我为什么强调状态机优于自由推理的原因——可观测性和可调优性完全不在一个量级。4.4 运行验证与踩坑记录第一次整体跑的时候暴露了几个问题。信息收集阶段速度很慢分析日志发现是工具调用串行执行改成并行调用后耗时少了近一半。这是很容易被忽略的性能问题值得大家在做工具调用封装时就把并发支持设计进去。另一个问题是周报生成阶段模型偶尔会漏掉某个项目的内容但整体框架看起来又很完整不仔细核对发现不了。后来在校验阶段加了一条硬规则必须列出原始信息中的项目清单然后逐项比对周报中是否都已覆盖。模型给出的“周报已完整”结论是靠不住的规则化的交叉验证才能兜底。运行调优后整个流程完整跑下来稳定多了输出质量也达到了可以直接使用的程度。这个案例虽然简单但已经把 Agent 系统该有的核心模块都过了一遍。5. 主流技术栈方案Python、Rust 与全栈框架聊完设计再聊聊实现层面的技术选型。不同语言和框架做 Agent体验差别很大。我分别说一下 Python 和 Rust 生态的情况以及全栈框架的取舍。5.1 Python 生态快速迭代首选Python 做 Agent 原型和业务落地核心优势是生态成熟、库多、人好招。目前我做 Agent 的主力语言至今还是 Python原因就是效率高。在 Agent 框架选择上LangChain 和 LlamaIndex 是最常被提起的两个。但我的真实使用体验是可以用它们做项目前期验证但真正上生产项目时我倾向于只用框架里的基础组件核心编排还是自己写。LangChain 这类框架的问题在于抽象层级太多出了问题不好排查。一个简单的链式调用底层帮你做了大量隐式处理一旦结果不对你很难判断是模型的问题、提示词的问题、还是框架内部的某个组件行为异常。相比之下自己写个几十行的状态机逻辑一目了然。但是纯手写也有代价。工具函数的输入输出封装、模型调用的重试机制、上下文的压缩逻辑这些都自己写的话工作量不小。我的建议是自己实现编排层和控制层用现成库处理工具解析和模型调用这类相对标准的部分。5.2 Rust 生态高性能与高可靠性的选择最近“基于 Rust 的 AI Agent”热度高涨我理解这个趋势背后的逻辑。Rust 的优势在于高性能真的需要极低延迟的场景、强类型安全编译期间就能发现一批问题和资源占用低做大规模部署时成本优势明显。Rust 生态里做 Agent 目前比较活跃的方向一是基于类型的工具定义宏用过程宏自动生成模型的工具描述在编译期完成工具接口的类型检查这比 Python 的运行时解析要安全得多二是内嵌模型推理库比如用 candle 或 llama.cpp 的绑定实现本地推理和 Rust 的应用代码无缝集成三是 Actor 模型并发Rust 的 Actor 模型天然适合多 Agent 通信的场景在语言层面保证消息传递的安全性。但 Rust 做 Agent 的缺点是显而易见的开发效率比 Python 低生态不够成熟很多功能要自己从零造轮子。我的判断是Rust 适合大型的、对性能和稳定性要求极高的生产系统或者需要深度嵌入到已有 Rust 基础设施里的场景。如果你是在做应用层产品原型Python 依然是更务实的起点。5.3 全栈框架对比LangChain、AutoGen、CrewAI 等现在市面上的 Agent 全栈框架我按使用场景分成三类研发框架型LangChain、LlamaIndex 等适合做 RAG、链式调用等相对标准的能力组合灵活但复杂度在你自己掌控多 Agent 协作型AutoGen、CrewAI 等适合做多角色协作场景能用但千万别默认多 Agent 就比单 Agent 好企业级平台型阿里云百炼、Dify 等最省心可视化拖拽适合不懂代码的业务团队做流程编排但要警惕被平台绑定。给一个判断标准如果你的团队有 AI 工程师想深度定制自研核心加开源组件是上策如果完全是业务团队要快速出效果直接上企业级平台更快别自己在底层折腾。6. Agent 实战中的典型问题与排查思路工程类文章最有价值的其实是“踩坑记录”。我把自己和身边朋友做 Agent 时遇到的问题整理成一张速查表按场景、表现、排查思路三个维度展开帮大家少走弯路。6.1 工具调用类问题Agent 该调工具不调、不该调乱调、或者参数传错这些是最高频的问题。我遇到过一个典型情况Agent 在回答“昨天项目进展如何”时不先查数据直接靠模型幻觉编了一份进展出来问题是编得还挺像那么回事。排查思路分三步第一步检查工具描述是否清晰描述要写清楚工具的适用场景、输入参数的含义和边界让模型有足够依据做判断第二步检查工具返回格式如果返回的是非结构化文本模型解析很容易失败统一改成 JSON 结构第三步加一层显式的“是否需要查询”判断让模型在回答前先向自己发问“当前问题我是否确定答案”不确定就调用工具。参数传错的问题典型是模型把时间范围格式搞错把“2024-01-01”传成“01/01/2024”。解决办法是在工具参数定义里加格式约束描述同时在工具函数里做防御性解析解析失败就自动尝试常见格式变体再失败就带着错误信息返回给模型让它修正重试。6.2 上下文与记忆类问题中途失忆、前后矛盾、越来越慢这类问题的根源几乎都在上下文管理。失忆就是上下文被截断或压缩过度关键信息丢了前后矛盾是早期的结论没保留到后期越来越慢是历史消息无限累加导致 token 开销越来越大、响应时间越来越长。我的排查思路是检查上下文各区域的长度分配。如果“历史对话区”占比过高说明缺少总结机制如果“用户目标区”为空说明系统根本没把目标持久化。这里我的标准做法是维护一个结构化的记忆对象包含用户目标、关键事实、当前进度、已得结论四个字段每轮对话结束后更新。模型回答时优先参考这个结构化记忆而不是去翻原始历史。6.3 规划与执行类问题Agent 规划出来的步骤做一半就停、说要做三件事只做了两件、或者在某个步骤里反复循环出不来。这些问题的共性原因是规划和执行脱节了——模型规划时没有考虑实际可用工具和已知约束。排查分两层。在规划层检查模型是否知道当前有哪些工具、每个工具的能力边界。我建议在系统提示词里给工具清单并写明每个工具能干什么不能干什么同时要求模型在规划时明确标注“此步骤使用哪个工具”。在执行层加一个步骤计数器超过预设最大步骤数就强制终止触发了就说明规划有严重问题需要回溯分析。循环问题除了加最大步数限制还要监控相同状态的重复进入次数。比如某个状态连续被进入三次且结果相同就该让 Agent 停下来重新规划而不是硬着头皮继续转。6.4 质量与成本类问题Agent 回答质量不稳定、token 消耗过高这两个问题通常同时出现且互相影响。质量不稳最常见的原因是校验缺失生成完直接输出没有自查。成本过高的原因是规划粒度过细、无效调用过多以及上下文膨胀。解决办法是建立输出质量评分机制每次生成后让评估模型打分低于阈值就重新生成或走人工兜底。在成本侧把模型的调用记录全部日志化按步骤分析每次调用的 token 消耗找出大头针对性地做压缩或跳过优化。这里分享一个我验证过有效的手段对每步调用设置 token 上限超出就拦截并转为小模型处理或规则兜底。这能直接砍掉一批异常调用同时让问题暴露得更早。7. 写在最后的实操体会做 Agent 工程化这些年我最大的感受是Agent 不是一个神秘的“人工智能黑盒”它本质上就是一个精心编排的工程系统。模型的推理能力是基础但决定系统上限的是你对流程的控制、对上下文的组织、对工具的设计、对异常的兜底。如果你想入这个方向我的建议是先找一个具体的小场景比如周报生成、信息检索、客服接待用最简单的方式完整跑通然后在迭代中逐步加入记忆、规划、反思、评估这些模块。别一上来就搞多 Agent、搞复杂编排先做好一个再扩展。另外一个想提醒的是Agent 的评估和运维一定要从第一天就做起来。没有评估就没有优化方向没有日志就没有排查线索。这两个是 Agent 工程质量的生命线比任何花哨的功能都重要。最后如果你在动手过程中遇到什么有意思的坑或者有更好的工程实践欢迎多交流。Agent 这个方向还在快速发展工具的迭代、模型能力的提升、架构的演进都很快保持学习、保持动手才不会被抛下。