★ FEATURED ARTICLE 每个月总有几波朋友拿同一类需求跑来问我想做企业级智能体是不是套个现成的Agent框架就能上线我的回答往往让他们意外——能但半年后大概率要推倒重来。因为行业级智能体的瓶颈根本不在有没有Agent能力而在可规划、可观测、可控、可维护这套工程底座是否扎实。这篇文章记录了我从零搭建一套智能体全仓库的完整实战覆盖技术选型、核心模块拆解、仓库结构与关键实现、生产环境问题排查。无论你是团队技术负责人、想转Agent方向的后端还是被老板丢了一个做个AI助手需求的人都可以直接把这套思路当蓝本照着搭出属于自己的第一版行业级智能体。1. 先从需求端拆解行业级智能体和Demo级Agent差在哪1.1 为什么我不建议直接套现成的编排框架先声明一点我不否定社区里那些主流Agent编排框架的价值它们在做原型验证、黑客松Demo时效率极高。但一旦进入行业级场景问题会逐个浮出来。第一层问题是抽象层级太深。框架帮你做了规划器、记忆管理、工具调用链看起来省事可当你需要给业务方解释为什么这个Agent在第三轮没有调用库存查询工具的时候你发现根本说不清——它内部的状态迁移逻辑被封装在框架深处日志缺胳膊少腿。行业级应用的第一诉求是可控其次才是智能。一个解释不了行为的系统没法上线。第二层问题是配置驱动大于代码驱动。业务逻辑稍微复杂一点比如如果客户等级是VIP且订单金额超过阈值则走A审批流否则走B询价流你用框架的配置文件硬写也能写但可读性和可维护性会迅速恶化。到后面改一个分支要翻几百行YAML配置文档也没人维护等于给自己埋雷。第三层问题是版本升级的连带风险。开源编排框架升级大版本动辄改核心抽象。而行业系统往往被几十个业务模块依赖框架一升级所有Agent行为都要回归测试一遍代价极高。与其替框架的升级买单不如把核心编排能力掌握在自己手里。所以我的结论是核心规划、执行循环、记忆管理、工具调用规范这四件事必须自研外围的模型SDK、向量库、消息队列用成熟组件就行。自研不代表从零写模型而是把Agent的骨架捏在自己手上。1.2 动手前必须想清楚的三个设计问题很多项目翻车不是死在代码上而是死在动手前没想明白边界。我在设计这套仓库之前先逼自己回答了三个问题。第一个Agent的边界是什么。是单一Agent包打天下还是一个主Agent加多个子Agent分工对于行业级场景我强烈建议一开始就按单主Agent 多个专业子Agent来设计。主Agent负责理解意图、拆解任务、汇总结果子Agent负责具体领域动作比如订单处理Agent、售后Agent、质检Agent。这样每个子Agent的系统提示词短、工具列表少、模型注意力集中任务成功率明显更高。第二个允许Agent调用哪些工具权限怎么控制。工具不是越多越好。工具列表越多模型在选择工具时的困惑度就越高误调用的概率也越高。我会把工具按业务域分组默认只暴露当前任务相关的工具子集并在工具定义里写清楚什么时候该调用这个工具什么情况下不要调用这个工具。第三个出错了怎么办。Agent跑偏、工具调用失败、模型幻觉这些都是必然事件。我要在系统设计层面留好审计日志、任务状态快照、人工介入机制。行业级Agent不是全自动无人看守而是人在环上机器干活出了岔子人能兜底。这三件事想清楚后面所有实现都有了锚点。2. 技术选型我的六层架构和每一层的选择理由2.1 总体架构分六层每一层干什么这套智能体仓库的整体架构我按六层来切层与层之间只用标准接口通信好处是任何一层想换实现其他层不用改动。层级职责核心组件接入层接收用户请求统一鉴权、限流、会话管理FastAPI Redis语义理解层意图识别、实体抽取、路由到对应技能域大模型 提示词模板规划层任务拆解、子任务依赖编排、规划结果校验自研Planner执行层驱动子Agent或工具执行、维护循环状态自研Executor记忆层短期上下文、工作记忆、长期知识检索SQL数据库 向量库服务层Agent的对外API、管理后台、审计报表FastAPI Vue管理端选FastAPI是因为它异步性能好、类型标注干净和Python生态的模型SDK深度绑定团队招人也容易。Redis主要扛会话级缓存和分布式锁防止同一个任务被并发触发两次。SQL数据库我用了常规的关系型数据库存任务事件流、Agent状态和工具调用记录。向量库用的是常见的开源方案用来做长期记忆的语义检索。2.2 模型层选型Function Calling是必选项不是加分项很多人在模型选型上只看榜单分数这是典型的误区。行业级Agent对模型的考核维度应该按这个优先级排工具调用稳定性 指令遵循能力 上下文窗口长度 推理速度 价格。工具调用稳定性是第一位的。Agent的核心动作是根据用户意图调用正确的工具传入正确的参数。如果模型经常把参数类型搞错、工具名编造错后面所有环节都会连锁出错。我在选型时做的第一件事不是跑推理题而是准备了一套50个工具调用测试用例让候选模型逐个过统计工具名准确率、参数完整率、多余参数率。Function Calling能力必须原生支持。有些模型本身不支持函数调用靠提示词逼它输出JSON这种方案短期能用但生产环境迟早翻车——模型经常输出多余的Markdown标记、注释、解释文字解析阶段苦不堪言。现在主流模型基本都原生支持工具调用尽量选这类模型。我最后采用的策略是核心规划用强模型子Agent和轻量分类任务用性价比更高的模型。也就是重规划、轻执行的成本策略。至于具体的模型品牌我反而不太建议绑定某一家在接口层统一封装随时可以切换或并行接入多家模型做容灾。2.3 记忆层设计用事件溯源代替对话快照很多Agent项目把对话记录当成一个JSON文件或表里的一行存下来这是最省事也最坑的做法。你没法回答这几个问题用户上一个任务到底完成没有工具调用失败后重试了几次Agent当时基于什么信息做了这个判断我的做法是事件溯源。整个系统里所有发生的事都写成一条不可变的事件流存进关系型数据库。比如用户消息进来是一个事件规划器输出任务列表是一个事件某工具被调用且结果成功是一个事件Agent自我反思修正计划也是一个事件。每个事件带时间戳、会话ID、任务ID。这套设计带来的直接好处是调试问题时可以完整回放一个任务从开始到结束的每一步定位它为什么在第三步突然调用了错误工具不再是玄学。另外要做合规审计时管理员可以看到Agent看到了什么、做了什么、为什么做这也是行业级系统过等保和审计的基本要求。3. Agent核心四模块深度拆解3.1 Planner把大目标拆成可执行子任务的机器规划器是整个Agent的头脑它决定任务的执行路径。我用的是两步走规划模式先粗粒度拆解再细粒度验证。第一步主Agent拿到用户初始需求后先生成一个任务规划草案。这里提示词模板是关键我打磨过很多版目前稳定的一版长这样你是一个严谨的任务规划器。请将用户的最终目标拆解为可依次执行的子任务列表。 约束条件 1. 每个子任务必须依赖至少一个工具或可执行操作禁止输出纯查询类空任务。 2. 子任务之间如果有依赖关系必须显式标注 depends_on 字段。 3. 用户没有提到的权限边界默认遵循系统安全策略。 4. 如果任务本身模糊、歧义或缺少关键参数输出 clarification_requiredtrue并列出需要向用户询问的问题。 输出格式要求 只输出JSON数组不要任何解释性文字。第二步规划结果不是直接执行而要过一个规划校验器。这个校验器是我自研的一个规则引擎干三件事检查任务列表里有没有重复任务检查任务依赖关系是否形成环A依赖B、B依赖A这种检查任务数量是否超出阈值默认不超过8个多了强制合并。这步非常有用因为模型生成规划时经常抽风比如生成15个碎到不能再碎的任务直接执行会浪费大量Token和时间。3.2 Memory三层记忆架构各有各的存取策略行业级Agent的记忆系统我拆了三层短期记忆、工作记忆、长期记忆。短期记忆对应当前会话的上下文。这里面最大的坑是上下文窗口爆炸——模型一次性能读的Token有限如果用户连续对话太长早期内容会被挤出去或者费用剧烈上升。我采用滚动窗口策略默认保留最近20轮对话原文更早的内容交给摘要器压缩成一段结构化摘要塞到系统提示词的历史对话摘要区。压摘要这个动作可以半实时做比如每满10轮触发一次。工作记忆是Agent当前正在处理的任务状态类似CPU的寄存器。它记录当前正在执行哪个子任务已经拿到了哪些信息还缺什么数据。这个必须放在后端状态管理中不能丢给模型自己记。我用一个任务状态机类来维护每个子任务有pending、running、succeeded、failed、blocked五种状态状态变更都会落库。长期记忆负责跨会话的知识沉淀。比如用户上次明确说过报表导出用Excel格式那下次再聊到导出时Agent就该默认Excel。实现上就是把用户偏好、历史关键结论、领域知识碎片做向量化存进向量数据库每次新会话启动时按语义相似度检索Top K条注入上下文。这个模块的效果很依赖向量化模型的质量和检索阈值的调优阈值太松会注入一堆无关信息阈值太紧又什么都查不到。3.3 Tool Use工具注册的规范和调用防呆设计工具层是整个Agent的双手设计不好模型再聪明也使不出来。我在工具层定了几条硬规范靠代码结构强制执行。每条工具必须有统一的定义结构名称、描述、参数JSON Schema、所需权限、超时阈值、是否写操作。其中描述怎么写尤其关键——描述里要告诉模型这个工具是干什么的、适合在什么场景调用、绝对不要在什么场景调用。模型是靠描述来决定调用哪个工具的描述写得含糊误调用就在所难免。参数JSON Schema我用了严格的类型定义并让调用链路上加一个参数校验中间层。什么意思呢比如工具要求参数order_id是字符串类型模型最终返回了数字123456校验层会在传给工具前自动做类型转换或拒绝。这个中间层大概能拦截掉三成以上的低级参数错误是投入产出比极高的一个小设计。工具执行一定要跑在隔离环境里。外部工具可能访问网络、操作文件、写数据库如果Agent可以无限制执行任意工具安全风险直接爆炸。我在仓库里做了一个工具沙箱每条工具都在受限的子进程或容器里执行设置内存上限、CPU上限、执行超时超时直接杀掉并返回错误信息给Agent。同时所有工具调用都走审计日志记录谁调的、什么参数、什么结果、耗时多久。3.4 Executor与Reflection执行循环和自主修正机制Executor是整个Agent的心脏它驱动Agent进入规划 - 调用工具 - 观察结果 - 反思 - 再规划的循环直到任务完成或达到最大迭代上限。我给这个循环设了三个关键参数都是调参调出来的经验值最大迭代轮数默认10次单轮工具调用最多5个如果Agent连续3次做同一件没有进展的事强制触发反思节点。反思节点是一个独立的提示词模板让模型回头看我之前的方案哪一步走偏了当前结果和预期目标差距在哪下一步应该怎么调整。反思环节给模型喂的信息很讲究不是简单说你错了吗而是把当前任务目标、执行历史摘要、最近的失败结果、以及一个候选修正方向列表一起给它。有方向比没方向效果好得多模型可以从候选项里选一条也可以提出全新方案但至少给了它一个抓手避免它每次反思都是空泛的自责式表达。整个循环的状态跟踪依赖一个图状态管理类每走一步就把节点状态和边状态写进事件流。前端管理后台就是靠这些状态数据画出Agent每一步的执行路径图运营同学看得懂技术同学也好定位。4. 仓库搭建实操目录结构、配置与关键代码4.1 仓库目录结构人人都能看懂的布局仓库布局我花了很长时间调优现在这个结构团队成员上手速度最快agent-warehouse/ ├── app/ │ ├── api/ # 对外接口层 │ │ ├── v1/ │ │ │ ├── chat.py # 对话入口 │ │ │ └── task.py # 任务管理接口 │ ├── agent/ │ │ ├── core/ # 核心编排逻辑自研部分 │ │ │ ├── planner.py │ │ │ ├── executor.py │ │ │ └── reflector.py │ │ ├── memory/ # 记忆模块 │ │ │ ├── short_term.py │ │ │ ├── working_memory.py │ │ │ └── long_term.py │ │ └── agent_factory.py # Agent实例工厂 │ ├── tools/ # 工具注册与实现 │ │ ├── registry.py │ │ ├── sandbox.py │ │ └── builtin/ │ │ ├── order_query.py │ │ ├── stock_query.py │ │ └── report_export.py │ ├── models/ # 模型接入层 │ │ ├── llm.py # 统一接口封装 │ │ └── schemas.py │ ├── storage/ # 存储层 │ │ ├── db.py │ │ └── vector_store.py │ └── config/ # 配置管理 │ ├── settings.py │ └── prompts/ # 所有提示词模板 ├── tests/ # 测试目录 ├── .env.example └── docker-compose.yml这个目录的核心思想是依赖方向单向流动api层依赖agent层agent层依赖tools、memory、storage谁都不准反向依赖。规矩立好了项目变大也不容易烂。4.2 环境、配置和密钥管理行业级项目最不该马虎的就是配置管理。我把配置分成两层静态配置走config.yaml敏感配置走.env文件两者通过pydantic-settings统一加载。静态配置里放模型名称、最大迭代轮数、反思触发阈值、工具超时时间这类非敏感的工程参数。敏感信息全部进.env比如API密钥、数据库连接串、沙箱的密钥。.env文件严禁提交到Git仓库仓库里只保留一份.env.example模板新成员克隆后复制一份填上自己的值就能跑起来。密钥这东西我踩过好几次坑。最初图省事把密钥填在config.yaml里并提交到了内网仓库后来代码库要搬迁移翻日志发现有密钥明文硬是折腾了大半天去轮换所有相关账号。现在我的原则是任何环境的密钥都不落盘到配置文件统一走环境变量或密钥管理服务本地开发用本地密钥文件CI环境用注入的变量。4.3 工具注册与调度的核心代码工具注册我用了一个策略模式加装饰器的组合新工具的同学只需要写一个函数、打上装饰器、写清楚描述和参数Schema剩下的注册、校验、沙箱执行都自动完成。# tools/registry.py 核心摘录 import functools import inspect from typing import Callable, Dict, Any TOOL_REGISTRY: Dict[str, Dict[str, Any]] {} def register_tool(name: str, description: str, parameters: dict, requires_permission: str common): def decorator(func: Callable) - Callable: functools.wraps(func) def wrapper(*args, **kwargs): return func(*args, **kwargs) TOOL_REGISTRY[name] { name: name, description: description, parameters: parameters, func: wrapper, permission: requires_permission, } return wrapper return decorator具体一个内置工具的长这样# tools/builtin/order_query.py from ..registry import register_tool register_tool( namequery_order, description根据订单ID查询订单状态、金额、物流信息。 仅当用户明确提供纯数字订单号时调用 如果用户询问订单但未提供订单号不要调用先向用户索要订单号。, parameters{ type: object, properties: { order_id: {type: string, minLength: 6, maxLength: 20} }, required: [order_id] } ) def query_order(order_id: str) - dict: # 实际业务逻辑查数据库、调订单服务 return {order_id: order_id, status: shipped, amount: 399.00}这段代码看起来简单但实际生产环境中的规则远不止这些。第一参数校验中间层必须在registry的调用链路上拦截。order_id虽然定义为字符串但模型可能返回数字123456Python的JSON解析会把它当int如果直接传给函数类型不匹配的bug就会出现。我的校验器会把123456转成字符串再传。第二权限系统要挂在注册器上而不是写在每个工具函数里。requires_permission字段决定了这个工具能不能被当前会话调用以及调用前是否需要弹窗让用户确认。写操作类的工具一律要求用户点击确认后才能执行。第三沙箱执行是强制性的。我在registry.py里包了一个run_sandboxed方法所有注册工具都通过它执行在这个方法里设置超时和资源限制超时就抛异常。4.4 规划器提示词模板的设计思路提示词这玩意儿看似只要会写中文就行实际上门道很多。我踩过最大的坑是把提示词当成说明书——写了一大段功能描述模型还是我行我素。后来我总结出一句话给模型的指令要用约束条件的方式写不要用功能愿景的方式写。看一个反例你是订单助手的规划器你需要帮助用户处理订单问题包括查询、退换货等。这种提示词等于没写模型根本不知道边界在哪。我的模板强调什么不能做而不是能做什么。完整模板放在app/config/prompts/planner_cn.txt中几个核心约束摘出来供参考[角色与目标] 你是系统规划器。你的唯一目标是将用户请求拆解为可执行、可验证的子任务。 [硬性约束] - 你只能规划工具层已注册的工具能完成的任务禁止编造不存在的工具能力。 - 禁止输出操作系统的任何直接命令。 - 禁止规划超出当前会话权限范围的任务。 - 当用户请求不完整时你必须输出clarification_requiredtrue并列出最多3个待澄清问题。 - 每个子任务必须包含任务ID、任务描述、依赖任务ID列表、期望产出物。 [输入上下文] - 用户原始请求 - 历史关键摘要 - 当前会话可用工具列表 [输出格式] 只输出符合系统预先定义JSON Schema的规划结果禁止输出额外说明。这段提示词第三个区块很关键模型需要当前可用工具列表才能规划得靠谱。如果工具列表里没有生成报表这个能力它就不会规划去生成报表。这样从源头切断了模型胡编能力的路径。4.5 测试策略模拟工具和回放调试Agent项目的测试和传统后端测试完全不同传统测试是输入固定断言输出Agent是输入自然语言输出动态路径。完全靠确定性断言没法测。我搭了一套三层测试体系投入产出比很高。第一层是单元测试覆盖规划器校验、工具Schema校验、状态机转移这些纯逻辑模块。这些模块本身是确定的跑普通单测完全没问题。第二层是模拟工具测试。我给Agent配了一套模拟工具工具函数不真正连数据库而是返回预设数据外加记录每次调用的参数。这样测试场景可以完全还原用户在某种情况下Agent会调用什么工具、调用几次。断言的对象从最终答案变成工具调用序列比如I want a refund应该触发查询订单工具退款条件检查工具且两个工具有前后依赖顺序。第三层是回放调试。生产环境的每一条完整请求链路都会落盘包括规划JSON、每次工具调用的入参出参、反思节点的输入输出。我把这些数据脱敏后作为回归测试集每次改了提示词或升级模型就全量跑一遍回归集对比行为变化。这个工作挽救了我不止一次——印象最深的一次是换新模型后Agent突然在需要查库存的场景拒绝查库存直接自说自话给了答复回归测试立刻标红避免了一次生产事故。5. 生产环境踩坑实录常见问题与排查技巧5.1 现象一Agent不调用工具自己瞎编答案这个问题在项目上线后出现过好几次表现是用户明明问帮我查一下订单状态Agent却直接回复您的订单正在配送中——但它压根没有调用查询工具数据是它自己编的。排查后发现两个根因。第一个是系统提示词里关于工具调用的优先级描述不够强硬模型对无法实时获取信息这件事不自知。第二个是模型在上下文里找到了旧的订单信息误以为那还是当前订单。解决办法第一在系统提示词里写死一条所有需要实时数据的问题必须先调用工具获取数据禁止根据历史上下文臆测当前状态。工具返回结果后才能回答用户。第二在工具调用链路加了一个断言——如果Agent回答中包含订单号余额这类敏感业务实体但对应工具在本次会话中从未成功调用过则强制拦截并提示用户该信息需要重新查询确认。这条拦截逻辑粗糙但有效后来反哺了业务规则引擎的设计。5.2 现象二Function Calling参数频繁传错上线初期统计过一次工具调用参数解析失败占了所有失败事件的三成。最常见的两种错误把枚举值传成了相似但不存在的值比如把processing写成process把必填参数漏传了。这问题的根源不在Agent不聪明而在工具Schema定义不够防呆。后来我对所有工具的参数Schema做了一次集中整改加了三个约束枚举值字段全部注释说明语义必填参数在描述里用必须提供这种强约束词对外部依赖字段加format约束。整改后参数错误比例下降了六成。还有一个细节模型传入的参数经常是字符串形式的数字或日期比如2024-01-15。我在校验层加了一套自动类型收敛逻辑能安全转型的就自动转不能转的明确报错让Agent自查重试。这个机制上线后人工介入的频率肉眼可见地变少了。5.3 现象三上下文越滚越大单次成本失控有一段时间每周的模型费用居高不下查了半天发现是多轮对话场景下Agent每次交互都把全量历史记录塞进去Token消耗量随轮数线性暴涨。我先加了滚动窗口保留最近20轮全文更早的压缩成摘要压摘要的模型可以选廉价的小模型。后来发现还不够因为摘要会把关键信息丢得一干二净比如用户在第一轮说的只要电子发票这种偏好摘要里可能就没了。最终方案是两层记忆融合关键业务信息单独抽出来放入结构化记忆区包括用户ID、地址、发票偏好、订单上下文等每轮直接以JSON形式注入对话原文走滚动窗口语义知识走向量检索。三层各司其职成本降了四成对关键信息的召回率反而提升了一截。5.4 现象四并发一高模型限流和延迟抖动Agent在内部推广后日活涨得很快紧接着模型API开始频繁返回429限流高峰期响应延迟从2秒飙到15秒。模型层做成多路通道一个主力模型加两个备用模型当主力通道触发限流或连续超时请求自动切换备用通道。注意不是简单切换因为每个模型的能力和成本不一样我在路由配置里定义了每类请求的优先级和质量要求高优请求才允许走强模型通道普通请求全部压制到低成本通道。第二个改动是任务排队。Agent请求不直接同步打给模型而是进本地任务队列后台线程池消费配合分布式锁保证同一个会话内的请求严格串行。用户端体验从傻等转圈变成了任务已提交处理中体感反而更顺畅。这两个改动之后高峰期失败率从7%降到了0.5%以下。6. 上线之后观测体系与几个真实数字6.1 可观测性不只看日志要看链路Agent系统的可观测性和传统接口链路还不一样光看一次请求的耗时、状态码远远不够。我建了一套面向Agent的三维观测指标。第一维是任务维度看任务完成率、平均迭代轮数、平均耗时、反思触发率。反思触发率这个指标特别有意思正常场景应该在10%到25%之间如果超过40%大概率是规划器拆解质量有问题或者工具定义让模型理解困难。第二维是工具维度统计每个工具的调用次数、成功率、平均耗时、参数错误率。工具成功率异常偏低的要么是业务逻辑有bug要么是工具描述和实际功能不符需要回头检查提示词。第三维是成本维度按会话、按用户、按工具调用分别统计Token消耗。成本异常暴涨的会话通常是Agent陷入了某种循环比如反复调用同一个失败工具重试。这里面藏着一个优化点我后来给重复失败的工具加了冷却机制同一个工具在10分钟内连续失败3次后续调用需等冷却结束。6.2 一组跑了一个月的真实数据系统在内部稳定运行一个月后我拉过一组数据现在写出来给各位一个参考锚点。总共处理了8700多个真实任务任务整体完成率约86%剩下14%里有7%是用户主动取消或多轮澄清后放弃真正失败的是7%左右。平均每个任务迭代4.2轮平均耗时11.8秒单任务平均Token消耗约5300个。这个数据不能算惊艳但作为行业级落地的起步水平我是满意的而且改造成本优化后还能再往下压一压。这里额外说一句不要拿公开刷分数据集上的Agent准确率来对比生产数字。真实场景的请求本来就含混、缺参数、有歧义和测试集完全不是一回事。生产系统里真正重要的数字是用户愿不愿意继续用和错误是否可控不是一张漂亮的准确率指标。6.3 接下来可以往哪里扩展现在这套仓库的定位是单主Agent 专业子Agent的集群模式下一步我准备在三个方向继续投入。方向一是多Agent协作的鲁棒性。目前主Agent和子Agent的通信协议偏简单主Agent下发任务、收结果中间如果子Agent需要追问或者遇到前置条件不满足只能返回失败让主Agent兜底。更好的设计是引入交互协议让子Agent可以反问澄清但这需要设计更复杂的消息机制。方向二是引入强化学习反馈闭环。现在的反思节点依赖模型自身智力上限等于模型能力。后期想把任务是否成功作为奖励信号沉淀出高频失败模式反过来优化规划器提示词和工具描述。这本质上是让系统越用越聪明。方向三是领域知识注入的自动化。现在的长期记忆靠向量检索但知识条目的质量参差不齐检索中偶尔会混入过期信息。下一步准备给记忆写入加一道质量门禁用规则加模型双重校验低质量知识不落地。这套仓库目前还在我的开发机上持续迭代。如果让我说一路上最深的体会那就是别把Agent当魔法把它当工程系统。任务规划就是传统的流程拆解工具调用就是接口管理记忆系统就是存储架构反思机制就是异常处理。所有我们在传统后端领域积累的工程素养迁到Agent领域全部适用只是输入从确定的参数变成了充满歧义的自然语言。把这条想透了你离做出一个真正能上线、能维护的行业级Agent就不远了。最后再分享一个实用小建议动手写第一行代码之前先把一条端到端的最小业务链路跑通比如一个查询订单并答复用户的路径然后再横向扩展工具和记忆体系。先窄后宽是Agent项目最稳的起步方式。
阅读完成 · 觉得有帮助？
