1. 从“调模型”到“搭系统”前端视角下的Agent开发认知纠偏很多前端同行第一次听到“Agent开发”这个词脑子里蹦出来的第一反应往往是这玩意儿是不是得先学PyTorch、搞个显卡、跑个微调我当初也是这么想的。直到真正动手做了几个Agent项目之后才发现这个认知偏差大得离谱。Agent开发的核心根本不是模型训练它更像是在做一套“有大脑的自动化工作流系统”而前端工程师在这个领域里其实有着天然的优势。先把结论摆在前面Agent开发中模型是现成的你不需要训练它你需要的是编排它。这个认知转变非常关键。打个比方模型就像是一台性能很好的发动机而Agent开发是造一辆车——你需要设计传动系统、控制系统、仪表盘、安全机制让发动机的动力能真正转化为可用的行驶能力。前端工程师擅长什么擅长处理状态管理、事件驱动、组件编排、用户交互这些能力在Agent开发中几乎是一比一复用的。那为什么会有“Agent开发等于模型训练”这个误解我观察下来主要来自三个信息源的混淆。第一学术论文里讨论Agent时经常涉及强化学习、策略优化那是研究层面的东西第二一些大模型公司的宣传材料把“模型能力”和“Agent能力”混在一起讲第三市面上不少课程为了显得高深故意把门槛往模型训练上引。实际上你打开任何一个主流的大模型API文档看到的都是messages数组、tools参数、function_call返回——这些东西的本质就是接口调用和状态管理跟前端调RESTful API没有本质区别。我刚开始接触这块的时候花了两周时间试图去理解Transformer的注意力机制后来发现完全走错了方向。真正让我入门的是动手写了一个最简单的Agent循环用户输入→调用模型→模型返回工具调用请求→执行工具→把结果塞回对话→再次调用模型→直到模型给出最终回答。这个循环用JavaScript写出来不到一百行但它就是Agent最核心的骨架。理解了这一点之后后面所有的复杂Agent系统无非是在这个骨架上加记忆、加规划、加多Agent协作、加安全护栏。所以这篇文章我想做的事情很明确把Agent开发从“模型训练”的迷雾里拉出来用前端工程师熟悉的语言和思维模型讲清楚Agent开发到底在开发什么、需要哪些核心能力、怎么从零搭出一个能跑的Agent、以及在实际项目中会踩哪些坑。如果你是一个有前端基础、对Agent感兴趣但不知道从哪下手的人这篇内容应该能帮你省下至少两周的弯路。2. Agent开发的真实技术栈前端能力如何映射到Agent系统2.1 前端技能树与Agent开发的能力对应关系先来看一张对照表这张表是我自己在转型过程中总结出来的它把前端工程师已有的能力和Agent开发中需要的能力做了一一映射。你会发现重合度比想象中高得多。前端能力Agent开发中的对应能力具体体现状态管理Redux/Zustand对话状态与上下文管理维护messages数组、工具调用历史、会话变量事件驱动与异步编程Agent循环与工具调用编排处理模型返回的异步工具请求、超时重试组件化思维工具Tool的模块化设计每个工具独立定义schema、独立执行、独立测试API调用与数据转换模型API调用与响应解析构造请求体、解析function_call、格式化返回结果路由与中间件Agent的规划与分发逻辑根据意图路由到不同工具链或子Agent错误边界与降级Agent的容错与兜底策略工具失败重试、模型输出异常处理、人工接管性能优化防抖/节流Token消耗控制与调用频率管理上下文裁剪、缓存策略、批量处理这张表不是硬凑的是我在实际项目中一个个验证过的。举个例子前端做表单验证的时候你会定义一套schema来描述字段类型、必填项、校验规则。Agent开发中定义工具Tool的时候做的事情几乎一模一样——你需要用JSON Schema描述这个工具接受什么参数、每个参数是什么类型、哪些是必填的。如果你之前用过Zod或者Yup做表单校验看OpenAI的function calling文档会有一种莫名的熟悉感。再比如状态管理。前端应用里你用一个store维护全局状态组件通过dispatch action来修改状态。Agent系统里你用一个messages数组维护对话历史每次模型调用返回的tool_calls就是需要dispatch的action执行完工具之后把结果push回messages再触发下一次模型调用。这个模式跟Redux的“action→reducer→new state→re-render”循环在结构上高度同构。2.2 为什么不需要训练模型Agent的“智能”来自编排而非参数这里需要把“模型能力”和“Agent能力”彻底拆开讲清楚。模型能力指的是模型本身的知识储备、推理能力、语言理解能力这些是训练阶段决定的你改不了也不需要改。Agent能力指的是系统层面的能力——能不能记住上下文、能不能调用外部工具、能不能分解复杂任务、能不能在出错时自我纠正。这些能力全部来自你的代码编排跟模型参数没有半毛钱关系。我举个具体的例子来说明这个区别。假设你要做一个“帮用户查天气并给出穿衣建议”的Agent。模型本身知道“下雨要带伞”这个常识这是模型能力。但模型不知道今天你所在城市的具体天气这需要调用天气API这是Agent能力。模型不知道用户之前问过什么、偏好什么这需要你维护对话历史也是Agent能力。模型可能会在回答时编造一个不存在的天气数据你需要通过工具调用来约束它这还是Agent能力。所以Agent开发的核心工作可以概括为三件事给模型提供它不知道的信息通过工具调用、帮模型记住它记不住的东西通过上下文管理、约束模型不要乱来通过输出校验和护栏。这三件事没有一件需要你训练模型全部是工程问题。我见过一些团队在Agent项目初期花大量时间做模型微调试图让模型“学会”调用某个内部API。这个方向不能说完全错但性价比极低。更合理的做法是用prompt engineering把工具的使用说明写清楚用few-shot示例告诉模型什么时候该调用什么工具用输出解析来校验模型返回的格式。这些手段加起来效果通常比微调好而且迭代速度快一个数量级。2.3 一个最小Agent循环的代码骨架说了这么多理论直接上代码。下面这个例子用JavaScript写展示Agent最核心的循环逻辑。你不需要任何模型训练知识只需要会调API、会写异步函数就能看懂。async function runAgent(userInput, tools, maxTurns 10) { const messages [ { role: system, content: 你是一个助手可以使用工具来帮助用户。 }, { role: user, content: userInput } ]; for (let turn 0; turn maxTurns; turn) { // 1. 调用模型 const response await callModel({ messages, tools: tools.map(t t.schema), tool_choice: auto }); const assistantMessage response.choices[0].message; messages.push(assistantMessage); // 2. 检查是否有工具调用 if (!assistantMessage.tool_calls || assistantMessage.tool_calls.length 0) { // 没有工具调用说明模型给出了最终回答 return assistantMessage.content; } // 3. 执行所有工具调用 for (const toolCall of assistantMessage.tool_calls) { const toolName toolCall.function.name; const toolArgs JSON.parse(toolCall.function.arguments); const tool tools.find(t t.name toolName); let result; try { result await tool.execute(toolArgs); } catch (err) { result { error: err.message }; } // 4. 把工具结果塞回对话 messages.push({ role: tool, tool_call_id: toolCall.id, content: JSON.stringify(result) }); } } throw new Error(Agent循环超过最大轮次限制); }这段代码就是Agent的心脏。maxTurns是安全阀防止模型陷入无限循环。tools数组里每个工具包含两部分schema告诉模型这个工具怎么用和execute实际执行逻辑。整个循环的逻辑非常直白调模型→看它要不要用工具→要用就执行→把结果告诉它→再调模型→直到它不再要工具为止。我第一次写出这个循环并跑通的时候最大的感受是这不就是前端处理异步action的流程吗模型返回的tool_calls就像是dispatch出来的actionexecute就是reducer里处理action的逻辑把结果push回messages就是更新store。唯一的区别是这里的“reducer”是模型本身它会根据新的state决定下一步做什么。3. 工具设计Agent开发中最像前端组件开发的部分3.1 工具Schema的定义逻辑与前端Props设计的相似性Agent的工具Tool定义本质上就是在做接口设计。你需要告诉模型这个工具叫什么名字、接受什么参数、每个参数是什么类型、有什么限制、返回什么。这跟前端设计一个React组件的Props类型定义几乎是一回事。来看一个具体的工具定义示例。假设你要做一个“查询订单状态”的工具const queryOrderTool { name: query_order, schema: { type: function, function: { name: query_order, description: 根据订单号查询订单的当前状态和物流信息。当用户询问订单进度、物流状态时使用此工具。, parameters: { type: object, properties: { order_id: { type: string, description: 订单号通常是12位数字例如202312150001 }, include_logistics: { type: boolean, description: 是否包含物流轨迹详情默认为false, default: false } }, required: [order_id] } } }, execute: async ({ order_id, include_logistics false }) { // 实际调用内部订单服务 const order await orderService.getOrder(order_id); if (!order) { return { found: false, message: 未找到该订单 }; } return { found: true, status: order.status, estimated_delivery: order.estimatedDelivery, logistics: include_logistics ? order.logisticsTrail : undefined }; } };这个定义里description字段的写法非常关键。它不仅是给开发者看的注释更是给模型看的“使用说明书”。模型会根据这个描述来判断什么时候该调用这个工具。我踩过的坑是一开始把description写得太简略比如只写“查询订单”结果模型经常在用户问“退货政策”的时候也调用这个工具。后来把description改成“根据订单号查询订单的当前状态和物流信息。当用户询问订单进度、物流状态时使用此工具”误调用的概率大幅下降。这跟前端写组件文档是一个道理。你写一个DatePicker组件如果文档只写“日期选择器”使用者可能不知道它支持范围选择、快捷选项、禁用日期。但如果你写清楚“支持单选和范围选择可通过disabledDate禁用特定日期内置今天、本周、本月快捷选项”使用者就能准确判断什么时候该用它。3.2 工具粒度的取舍原子化还是聚合化设计工具时面临的第一个决策是粒度应该多细是把每个API都封装成一个工具还是把一组相关操作合并成一个工具我的经验是面向模型的工具粒度应该比面向开发者的API粒度更粗但比面向用户的业务操作更细。这句话听起来有点绕我用例子解释。假设你有一个电商后台内部API包括getOrderBasic、getOrderItems、getOrderPayment、getOrderLogistics。如果你把这四个API原封不动地暴露给模型模型需要连续调用四次才能回答“我的订单到哪了”这个问题。这不仅浪费token还增加了出错概率。更好的做法是封装一个get_order_detail工具内部并行调用这四个API返回一个聚合结果。模型只需要调用一次就能拿到所有信息。但也不要过度聚合比如搞一个handle_everything工具参数里塞几十个字段模型根本不知道该传什么。这里有一个实用的判断标准如果一个工具的参数超过7个或者description超过三句话还说不清楚就应该考虑拆分。反过来如果两个工具在80%的场景下都会被一起调用就应该考虑合并。3.3 工具执行的安全边界与错误处理工具执行是Agent系统里唯一真正“做事”的环节也是最容易出问题的环节。模型可能会传入格式错误的参数、可能会在不该调用的时候调用、可能会传入超出预期的值。你需要在工具执行层做好防御。第一层防御是参数校验。不要相信模型传进来的参数一定符合schema。我遇到过模型把order_id传成数字类型的情况虽然schema里写的是string。所以在execute函数开头应该做一次运行时校验execute: async (args) { if (typeof args.order_id ! string || !/^\d{12}$/.test(args.order_id)) { return { error: 订单号格式不正确应为12位数字 }; } // ... 继续执行 }第二层防御是权限控制。不是所有用户都能调用所有工具。比如“取消订单”这个工具应该只对订单所有者开放。你需要在工具执行前检查当前用户的权限execute: async (args, context) { const order await orderService.getOrder(args.order_id); if (order.userId ! context.userId) { return { error: 无权操作此订单 }; } // ... 继续执行 }第三层防御是副作用控制。对于有副作用的工具比如发邮件、扣款、删除数据应该增加确认机制。我的做法是把这类工具标记为requiresConfirmation: trueAgent在执行前会先向用户确认用户同意后才真正执行。这个机制在prompt层面和代码层面都要实现——prompt里告诉模型“调用此类工具前必须先征求用户同意”代码里做二次校验。注意工具的错误信息不要直接抛给用户看也不要原样塞回给模型。应该把错误信息标准化比如{ error: ORDER_NOT_FOUND, message: 未找到该订单 }这样模型能理解错误类型并决定下一步动作用户也能看到友好的提示。4. 上下文管理Agent的“记忆”到底该怎么设计4.1 对话历史膨胀问题与Token预算控制Agent跑多轮对话时messages数组会越来越长。每一轮工具调用的请求和结果都会追加进去token消耗线性增长。如果不加控制很快就会撞上模型的上下文窗口上限而且成本会高得离谱。我做过一个统计一个中等复杂度的客服Agent平均每轮对话会产生约800-1200个token的上下文增量包括用户输入、模型输出、工具调用参数、工具返回结果。如果对话进行到20轮上下文就接近2万token。按主流模型的定价单次调用的成本会从最初的几分钱涨到几毛钱。控制token预算有几个常用策略我按推荐程度排序策略一滑动窗口。只保留最近N轮对话更早的对话直接丢弃。这是最简单的做法但会丢失早期的重要信息。适合那些“每个问题独立”的场景比如查天气、查快递。策略二摘要压缩。当对话超过一定轮次时调用模型对早期对话做摘要用摘要替换原始对话。比如把前10轮对话压缩成一段200字的摘要。这样既保留了关键信息又大幅减少了token。缺点是摘要本身也要消耗token而且可能丢失细节。策略三结构化记忆。把对话中的关键信息抽取出来存到一个结构化的“记忆对象”里而不是保留原始对话。比如用户说“我上周买了一个蓝色的XL号T恤”你把它抽取成{ product: T恤, color: 蓝色, size: XL, purchaseDate: 上周 }存起来。后续对话中只把相关的记忆片段注入上下文而不是全部历史。我在实际项目中用的是策略二和策略三的组合短期对话用滑动窗口中期对话做摘要长期信息抽取成结构化记忆。这样能把20轮对话的上下文控制在4000 token以内。4.2 系统提示词的动态组装系统提示词System Prompt是Agent的“人格”和“行为准则”但它不应该是静态的。不同的用户、不同的场景、不同的工具集需要不同的系统提示词。我的做法是把系统提示词拆成几个模块运行时动态组装function buildSystemPrompt(context) { const modules [ // 基础人格模块固定 你是一个专业的客服助手语气友好、专业、简洁。, // 用户信息模块动态 context.user ? 当前用户是${context.user.name}会员等级${context.user.level}。 : , // 工具说明模块动态根据可用工具生成 你可以使用以下工具\n${context.tools.map(t - ${t.name}: ${t.description}).join(\n)}, // 场景规则模块动态 context.scenario after_sales ? 当前处于售后场景优先引导用户使用自助退货工具。 : , // 安全护栏模块固定 不要编造任何订单信息、物流信息。所有数据必须通过工具查询获得。 ]; return modules.filter(Boolean).join(\n\n); }这种模块化组装的好处是每个模块可以独立维护、独立测试、独立迭代。当业务规则变化时只需要修改对应的模块不会影响其他部分。4.3 工具返回结果的格式化与裁剪工具返回的结果往往包含大量模型不需要的字段。比如你调用订单API返回了50个字段但模型只需要知道订单状态和预计送达时间。如果把整个响应都塞进上下文既浪费token又可能干扰模型判断。我的做法是在工具执行层做一次“面向模型的裁剪”execute: async (args) { const raw await orderService.getOrder(args.order_id); // 只返回模型需要的信息 return { order_id: raw.id, status: raw.status, status_text: STATUS_MAP[raw.status], // 把状态码转成自然语言 estimated_delivery: raw.estimatedDelivery, items_count: raw.items.length, total_amount: raw.totalAmount }; }注意status_text这个字段。模型对状态码比如STATUS_3的理解能力远不如自然语言比如“已发货”。在工具层做一次映射能显著提升模型后续推理的准确性。另外对于列表类数据一定要做分页或截断。比如查询订单列表返回了100条不要全部塞给模型只返回前5条并告诉模型“还有95条未显示如需查看更多请调用分页工具”。这样既控制了token又给了模型继续探索的路径。5. 从Demo到生产Agent开发中那些文档不会告诉你的坑5.1 模型“幻觉调用”的识别与拦截模型有时候会“幻觉调用”——它会在回复里声称自己调用了某个工具但实际上并没有发起真正的tool_call。这种情况在模型能力不够强或者prompt写得不够清晰时特别容易出现。我遇到过一个典型案例用户问“帮我查一下订单12345的状态”模型回复“我已经帮您查询了您的订单正在配送中预计明天送达。”但实际上模型根本没有发起query_order的tool_call那个“正在配送中”是它编的。识别这种问题的方法很简单在Agent循环里加一个检查——如果模型的回复里包含“已查询”“已为您”“查询结果显示”等关键词但当前轮次并没有tool_call记录就判定为幻觉调用。拦截方式有两种一是直接把回复替换成“抱歉我需要重新查询一下”然后强制模型调用工具二是把模型的回复和工具调用记录一起送给一个校验模型让校验模型判断是否存在幻觉。更根本的解决方案是在系统提示词里明确写“你没有任何订单数据所有订单信息必须通过query_order工具获取。在调用工具之前不要对订单状态做任何猜测。”这句话能大幅降低幻觉调用的概率。5.2 多轮工具调用的顺序依赖与并行优化有些任务需要按顺序调用多个工具。比如“帮我取消订单12345并退款”需要先调用query_order确认订单状态再调用cancel_order最后调用refund。模型通常能理解这个顺序但偶尔会乱序调用。我的做法是在工具定义里增加depends_on字段然后在Agent循环里做一次拓扑排序const toolCalls assistantMessage.tool_calls; const sortedCalls topologicalSort(toolCalls, tools); for (const call of sortedCalls) { // 按依赖顺序执行 }对于没有依赖关系的工具调用可以并行执行。比如用户问“帮我查一下订单状态和账户余额”这两个工具可以同时调用。并行执行能把响应时间从两次API调用的总和降低到最大值。const results await Promise.all( independentCalls.map(call executeTool(call)) );但要注意并行执行时如果其中一个工具失败了需要决定是全部回滚还是部分成功。对于只读工具部分成功没问题对于有副作用的工具需要谨慎处理。5.3 流式输出与工具调用的冲突处理前端做Agent时流式输出streaming几乎是标配需求。用户希望看到模型“打字”的过程而不是等好几秒才一次性出现全部内容。但流式输出和工具调用之间存在天然的冲突模型可能在流式输出的过程中突然决定调用工具这时候已经输出了一部分文本你该怎么处理我的处理策略是在流式输出阶段先缓冲文本不直接渲染。当检测到tool_call时丢弃已缓冲的文本或者保留作为“思考过程”展示执行工具然后开始新一轮的流式输出。当流式输出结束且没有tool_call时再把缓冲的文本一次性渲染出来。let buffer ; let hasToolCall false; for await (const chunk of stream) { if (chunk.type text) { buffer chunk.text; } else if (chunk.type tool_call) { hasToolCall true; // 处理工具调用 } } if (!hasToolCall) { // 没有工具调用渲染缓冲的文本 renderToUser(buffer); }这个策略的缺点是用户会感觉“卡了一下”。优化方案是在等待工具执行时显示一个“正在查询...”的loading状态让用户知道系统在工作。5.4 成本控制Token消耗的监控与优化Agent项目的成本很容易失控。我见过一个团队上线第一周就烧掉了几千块的API费用原因是Agent陷入了无限循环——模型反复调用同一个工具每次都返回相同的结果但模型就是不给出最终回答。防止无限循环的第一道防线是maxTurns限制。第二道防线是检测重复调用如果连续三轮调用了相同的工具且参数相同就强制中断并返回错误。成本监控方面我建议在每次模型调用后记录以下指标指标说明优化方向prompt_tokens输入token数裁剪上下文、压缩系统提示词completion_tokens输出token数限制max_tokens、优化prompttotal_tokens总token数综合优化tool_call_count工具调用次数合并工具、优化工具描述turn_count对话轮次优化prompt让模型更快给出最终答案latency_ms响应延迟并行工具调用、缓存把这些指标打到日志里每天看一眼就能发现异常。比如某天平均turn_count从3涨到了8说明prompt可能出了问题模型需要更多轮次才能完成任务。6. 前端工程师做Agent的独特优势与转型建议6.1 交互设计能力在Agent体验优化中的价值前端工程师最大的优势之一是对交互体验的敏感度。Agent产品本质上是一个对话式交互系统而对话式交互的设计原则和传统GUI设计有大量相通之处。举个例子Agent在调用工具时会有延迟用户需要知道“系统正在工作”。前端工程师会自然地想到加loading状态、骨架屏、进度提示。而很多后端背景的开发者做Agent时往往忽略这些细节导致用户体验很差。再比如错误处理。前端工程师习惯了处理各种边界情况——网络超时、接口报错、数据格式异常。这些经验在Agent开发中直接复用。当工具调用失败时前端工程师会想到给用户一个友好的错误提示而不是直接把堆栈信息抛出来。还有一个容易被忽略的点Agent的回复格式。模型返回的是Markdown文本但直接渲染Markdown可能会有安全问题比如XSS。前端工程师对这类问题有天然的警觉性知道要用安全的Markdown渲染库要对链接做白名单过滤。这些安全意识在Agent产品中同样重要。6.2 从“写页面”到“写Agent”的思维转换要点虽然能力高度重合但思维模式还是需要做一些调整。我总结下来主要有三个转换从“确定性流程”到“概率性流程”。前端写页面时代码逻辑是确定的点击按钮→触发事件→更新状态→重新渲染。但Agent的行为是概率性的同样的输入模型可能给出不同的输出可能调用不同的工具可能走不同的路径。你需要接受这种不确定性并设计相应的容错机制。从“同步思维”到“异步编排思维”。前端虽然也有异步但大部分逻辑还是同步的。Agent开发中几乎每一步都是异步的调模型是异步的、执行工具是异步的、流式输出是异步的。你需要习惯用async/await来编排整个流程并且要考虑超时、重试、并发控制。从“UI状态”到“对话状态”。前端的状态管理主要关注UI状态弹窗开没开、表单填了什么、列表滚动到哪里。Agent的状态管理关注的是对话状态用户说了什么、模型回复了什么、调用了哪些工具、工具返回了什么。虽然都是状态管理但状态的维度和生命周期完全不同。6.3 学习路径建议先跑通再优化如果你是一个前端工程师想入门Agent开发我建议的学习路径是这样的第一周跑通最小循环。不要看太多理论直接找一个模型API用我前面给的那个循环代码写一个最简单的Agent。工具就做一个“查询当前时间”或者“计算器”目的是理解整个流程。第二周加工具、加记忆。尝试定义3-5个工具让Agent能完成一个稍微复杂的任务。同时加入对话历史管理体验一下上下文膨胀的问题。第三周处理边界情况。故意制造工具失败、模型幻觉、无限循环等情况看看你的Agent怎么反应。然后针对性地加防御机制。第四周做一个完整的小项目。比如一个“个人助理Agent”能查天气、查快递、记笔记、设提醒。把它部署起来自己用一周收集问题并迭代。这个路径的核心逻辑是先跑通再优化先做加法再做减法。不要一开始就追求完美的架构Agent开发是一个高度实践驱动的领域很多坑只有踩过才知道。提示不要花时间在模型微调上。除非你有非常特殊的领域需求比如医疗、法律等专业领域否则prompt engineering 工具编排能解决95%的问题。把省下来的时间花在工具设计和上下文管理上回报率高得多。7. 一个完整Agent项目的代码结构参考7.1 项目目录组织与模块划分一个可维护的Agent项目代码结构应该清晰地区分“模型交互层”“工具层”“状态管理层”“业务逻辑层”。下面是我在一个实际项目中使用的目录结构agent-project/ ├── src/ │ ├── core/ │ │ ├── agent-loop.js # Agent主循环 │ │ ├── model-client.js # 模型API封装 │ │ └── context-manager.js # 上下文管理 │ ├── tools/ │ │ ├── index.js # 工具注册中心 │ │ ├── query-order.js # 订单查询工具 │ │ ├── cancel-order.js # 取消订单工具 │ │ └── refund.js # 退款工具 │ ├── prompts/ │ │ ├── system-base.js # 基础系统提示词 │ │ └── scenarios/ # 场景化提示词 │ ├── memory/ │ │ ├── short-term.js # 短期记忆滑动窗口 │ │ └── long-term.js # 长期记忆结构化存储 │ └── utils/ │ ├── token-counter.js # Token计数 │ └── retry.js # 重试逻辑 ├── config/ │ └── agent.config.js # Agent配置 └── tests/ └── agent.test.js # 测试用例这个结构的核心思想是每个模块只做一件事模块之间通过明确的接口通信。比如agent-loop.js只负责循环逻辑不关心具体工具怎么执行tools/目录下每个工具独立文件独立测试context-manager.js只负责上下文的裁剪和组装。7.2 配置驱动的Agent初始化Agent的行为应该通过配置来驱动而不是硬编码在代码里。这样可以在不同环境、不同场景下快速切换行为。// config/agent.config.js export const agentConfig { model: gpt-4-turbo, maxTurns: 10, maxTokens: 4096, temperature: 0.3, tools: [query_order, cancel_order, refund], memory: { strategy: sliding_window, windowSize: 10, summaryThreshold: 15 }, safety: { requireConfirmation: [cancel_order, refund], blockedPatterns: [密码, 身份证] } };这个配置文件定义了Agent的所有可调参数。当需要调整行为时改配置就行不需要改代码。比如测试环境下把maxTurns调小、把temperature调低生产环境下再调回来。7.3 测试策略如何验证Agent行为的正确性Agent的测试比传统前端测试要复杂因为输出是不确定的。你不能简单地断言“输入A一定得到输出B”。我的测试策略分三层第一层工具单元测试。每个工具的execute函数是纯函数或接近纯函数可以像测试普通函数一样测试。输入参数、断言输出格式和内容。第二层循环逻辑测试。用mock模型替换真实模型模拟各种返回情况有tool_call、无tool_call、多个tool_call、tool_call失败等。验证Agent循环在各种情况下的行为是否符合预期。第三层端到端评估。准备一组标准问题让Agent实际运行人工评估回答质量。这一层无法自动化但可以半自动化——用另一个模型来打分人工抽查。// tests/agent.test.js describe(Agent Loop, () { it(should execute tool and return final answer, async () { const mockModel createMockModel([ { tool_calls: [{ function: { name: query_order, arguments: {order_id:123} } }] }, { content: 您的订单已发货 } ]); const result await runAgent(查订单123, [queryOrderTool], mockModel); expect(result).toBe(您的订单已发货); }); });这种测试方式能覆盖大部分逻辑分支而且运行速度快不需要真实调用模型API。8. 关于Agent开发我踩过的最值钱的三个坑第一个坑是过度依赖模型能力。项目初期我试图通过精心设计的prompt让模型自己完成所有推理结果发现模型在复杂场景下经常跑偏。后来我把大量逻辑从prompt里移到了代码里——用代码做路由、用代码做校验、用代码做状态机。模型只负责它最擅长的事情理解自然语言、生成自然语言、决定调用哪个工具。这个转变让系统的稳定性提升了一个档次。第二个坑是忽略工具描述的重要性。我一开始觉得工具描述随便写写就行反正模型能理解。结果发现工具描述的质量直接决定了模型调用工具的准确率。一个模糊的描述会导致模型在错误的场景调用工具或者在正确的场景不调用工具。后来我花了一整天时间专门打磨每个工具的description把调用时机、参数含义、返回值格式都写清楚误调用率从30%降到了5%以下。第三个坑是没有做成本监控。项目上线第一周我没有加任何token监控直到收到账单才发现费用远超预期。排查后发现Agent在处理某些边缘case时会陷入循环反复调用同一个工具。加上maxTurns限制和重复调用检测之后成本降到了原来的三分之一。这件事给我的教训是Agent项目的成本监控不是可选项是必选项从第一天就要做。这三个坑的共同点是它们都不是模型层面的问题全部是工程层面的问题。这也再次印证了这篇文章的核心观点——Agent开发不是模型训练而是系统编排。你的工程能力越强Agent的表现就越好。模型只是系统中的一个组件虽然重要但远不是全部。
