AI Agent 这两年热度高但真正把它做成线上可用服务的人几乎都经历过同一个阶段Demo 跑得欢一上并发就垮。原因很简单Agent 不是一段提示词加一个模型接口它是一套工程系统。把它拆开看就是七块积木加上七个决策点。七块积木决定它能做什么七个决策点决定它能不能稳定地做。这篇我完全按工程实现的视角来写——不铺概念只讲模块、选型和坑从模型选型到编排框架、从工具暴露到并发兜底照着这套思路你能把一个只会聊天的 Agent 变成“真能下地干活”的服务。这套内容适合谁适合已经把 Agent demo 跑通、准备上线的开发者也适合刚接触 Agent 但不想走弯路的新手。我会尽量用大白话拆掉黑盒同时保留必要的技术细节让你读完能直接对着做。1. 七个要素Agent 的“积木清单”任何 Agent无论包装成什么样底层都跑不掉七样东西。我把它们列成清单大模型、提示词、工具、记忆、规划、执行、反馈。前四个是“静态积木”决定了 Agent 的能力边界后三个是“动态流程”决定了 Agent 的智商表现。拆开理解比死记架构图有用得多。1.1 模型层Agent 的“大脑皮层”模型是整个 Agent 唯一产生“智能”的地方其他所有模块都是围绕它做输入输出管理。工程上选模型核心看三件事推理能力、上下文长度、单位成本。推理能力决定了 Agent 能不能正确拆解任务。很多人以为参数越大越好实际做工程会发现70B 模型并不是全场景碾压 7B 模型关键是任务复杂度。简单工具调用、查数据库、写邮件13B 级别模型完全够用需要多步推理、代码生成、复杂规划才需要大参数模型。上下文长度直接影响 Agent 的记忆策略。128K 上下文听着美好但真正喂进去 50K token 之后模型注意力会明显下降延迟和成本一起飙升。工程上一般把上下文长度当作“缓冲池”而不是“无限记忆”。单位成本更现实。一次任务可能调用模型 3 到 8 次如果每次消耗 4K token一个用户一天用 20 次任务成本就非常可观。所以模型选型不是一锤子买卖很多时候需要大小模型混用简单分好用 8B复杂推理切 70B这是 Agent 工程里的常见玩法。1.2 提示词与上下文Agent 的“工作台”提示词在 Agent 里的作用比在普通 Chatbot 里更结构化。Chatbot 只需要一段 system prompt 告诉模型“你是谁”Agent 的提示词要承担更多工具使用规则、输出格式约束、任务边界声明、安全限制。我习惯把 Agent 提示词拆成四段来写角色与目标定义 Agent 是什么、要完成什么目标。工具说明每个工具是干什么的、参数怎么填、什么情况下用。输出格式必须输出 JSON 还是 Markdown字段有哪些。限制与兜底哪些事不能做、遇到不确定性怎么处理。这四段不是随便拼接每段都对应一个工程问题。工具说明写得不清模型就会乱调用工具输出格式不写死解析层就要处理各种意外结构。提示词是 Agent 的“工作台”模型在这个台面上思考台面乱思考就乱。另外上下文不是只包含用户输入。你还要把历史消息、工具返回结果、中间推理过程、当前状态都拼进去。这里有个度的问题——拼得太多模型抓不住重点拼得太少模型缺乏背景信息。工程实践中我会对上下文做分级管理核心指令永远保留历史消息做摘要压缩工具结果只保留最近几轮。1.3 工具层Agent 的“手和脚”没有工具的 Agent 只是个聊天机器人。工具是 Agent 和外部世界交互的接口可以是 HTTP API、数据库查询、代码解释器、文件读写甚至另一个 Agent。工程实现上工具暴露有两种主流方式。第一种是 Function Calling模型在对话中输出一个结构化的调用意图比如{name: search_user, arguments: {id: 123}}你的代码再执行对应函数。第二种是 MCPModel Context Protocol把工具封装成标准协议让不同模型和不同工具之间能即插即用。我的经验是内部系统的小工具直接用 Function Calling 最简单少一层抽象就少一层故障需要对外开放工具生态、或者工具数量多了之后MCP 的收益才体现出来。工具层设计要特别注意三件事参数校验、错误返回、执行超时。工具报错不能直接抛给模型要把错误信息整理成模型能理解的文本否则模型会因为一个异常直接陷入死循环。工具执行要有超时控制一个数据库查询把整个 Agent 卡住 30 秒这种体验谁用谁跑。1.4 记忆层Agent 的“草稿本”记忆是 Agent 和普通 API 调用的关键差异。模型不具备真正的记忆每次对话都是独立的所以你必须把“记忆”做成外部存储。记忆分三种短期记忆、长期记忆、工作记忆。短期记忆是当前会话的上下文一般放进程里长期记忆是跨会话的用户偏好和历史事实放向量数据库工作记忆是当前任务步骤的执行状态放状态机或 Redis。工程实现里短期记忆最容易处理直接拼到 prompt 里长期记忆涉及 recall 和 update需要一个检索策略——不是所有历史都塞进去而是根据当前 query 做相似度检索选出相关的记忆片段工作记忆最容易被忽略却最影响稳定性。比如一个“写邮件并发送”的任务模型已经写好邮件了但用户中断这时候工作记忆如果丢了下次会话就不知道邮件草稿放哪。我建议所有做 Agent 的朋友第一版就把记忆分层设计好哪怕先不做向量检索也要在数据结构上留出位置。不要等用户量起来了再重构那会比重新写还痛苦。1.5 规划层Agent 的“任务拆解”规划是 Agent 看起来“聪明”的关键。它让 Agent 不是一步到位地完成复杂任务而是拆成多步逐步执行、逐步检查。实现规划有三条路线。第一条是 prompt 式规划让模型直接输出一个 JSON 数组表示子任务列表然后循环执行。第二条是流程编排用 LangGraph 或自研状态机把步骤写成有向无环图每一步是一个节点。第三条是反思式规划模型在执行完一步后根据观察结果决定下一步类似 ReAct 模式。我的建议是任务路径明确时用流程编排让每一步可追踪、可回滚任务路径不明时用 ReAct 式规划给模型更大的自由空间。工程上最怕的是把两条路线混在一起用既想要流程确定性又想要模型灵活性结果状态机逻辑越写越复杂最后谁也救不了。1.6 执行层与反馈层Agent 的“闭环”执行层负责真正调用工具、运行代码、把模型决策变成动作。它的特点是“脏活累活”要处理超时、重试、限流、并发控制。反馈层则把执行结果变成模型能理解的信号让 Agent 决定继续还是结束。一句话总结闭环Agent 的每一次循环都遵循“观察-思考-行动-观察结果”的节奏。没有反馈层的 Agent工具调完就结束了遇到中途失败也不会自己修正有反馈层的 Agent至少能多挣扎一次这在用户看来就是“聪明”和“傻”的差距。执行层我要提醒一个细节不要把执行逻辑写死在业务代码里要抽象成通用的“工具执行器”。这样后续加新工具时你只需要定义工具描述和调用函数不用改 Agent 主循环。业务逻辑和 Agent 框架隔离后期维护会轻松很多。1.7 七要素的配合关系七要素不是七选一而是层层依赖。模型是底座提示词是模型输入工具是模型触角记忆是外部状态规划是决策逻辑执行是动作载体反馈是修正机制。工程上我会这样理解模型、提示词、工具、记忆属于“静态配置”在 Agent 启动前就要准备好规划、执行、反馈属于“运行时行为”在每次任务中动态循环。调一个 Agent先看静态配置对不对再看运行时循环是否顺畅。大部分“Agent 行为诡异”的问题排查路径都是这条。2. 七个决策点从“能跑”到“能扛”的工程分岔路拆完七要素你已经知道 Agent 由什么组成。但真正做工程你还需要在每个要素上做决策。这七个决策点决定了你的 Agent 是玩具还是生产系统。2.1 决策一模型选型能力、成本与延迟的三角取舍模型选型的本质是在“能力、成本、延迟”三件事里做取舍没有全都要的方案。你需要先定义你的场景最不能牺牲什么。做客服 Agent延迟一定要低综合体验比单次推理的智商更重要可能一个大模型快响应比一个超大模型慢响应更合适。做代码生成 Agent推理能力更重要等 5 秒换一个能正确做事的模型是值得的。做内部数据分析 Agent成本更敏感非核心场景用便宜模型只有复杂报表才上重模型。实操时我会维护一个“模型路由表”维护多个模型配置每个配置标注用途、优先级、成本权重。一个 Agent 里可以同时配置三个模型快速模型负责意图识别、简单问答1K token 以内的轻量任务。主力模型负责主任务执行、工具调用、多步推理。兜底模型主力模型失败或超时时用更稳的模型重跑。这样既不牺牲质量也把成本压在一个能接受的区间。另外提醒一件事模型走 API 和模型推理服务对接延迟差异很大。API 客户端需要做连接池复用否则频繁握手光连接开销就能占掉一半延迟。2.2 决策二编排框架LangGraph、AutoGen 还是自研编排框架是 Agent 的主干决定你怎么组织规划、执行、反馈的循环。现在主流选择有三个方向LangGraph、AutoGen、自研状态机。LangGraph 的优势是图结构清晰节点和边都显式定义状态流转看得见适合生产级场景。它的并发控制、checkpointer 机制都是为真实服务设计的能省很多事。AutoGen 更强调多个 Agent 之间对话协作适合研究原型和多智能体辩论类场景但工程上要处理的东西更多对话式协作的不可控因素也更多。自研状态机适合团队对代码有强控制力、业务状态极其复杂的情况。自研可控性最强但需要自己处理并发、持久化、恢复、分支流转开发成本高。我个人给团队的建议是没有足够理由不要自研。先用 LangGraph 把业务跑通等真正发现框架瓶颈再局部替换而不是整体推翻。无论选哪个框架都要关注一个核心能力状态持久化。Agent 任务可能执行几秒也可能执行几分钟进程一重启状态就没了这在生产上是不可接受的。LangGraph 里有 checkpointer可以在每个节点间把状态存下来自研的话至少要把状态序列化到 Redis。2.3 决策三工具协议Function Calling、MCP 还是裸 HTTP工具是 Agent 和外部系统之间的桥而“桥”的接口协议直接影响开发效率和扩展性。我建议把工具分成两类来决策。内部工具、工具数量少于 20 个的直接用 Function Calling 模式最顺手。你只需要写一个 functions 数组描述工具名、参数、说明模型就会输出结构化调用意图。这种方式没有额外中间件解析简单调试也直接。外部生态工具、或者工具数量会持续增长的用 MCP。MCP 把工具封装成标准 server模型客户端通过统一协议发现工具、调用工具。它的核心价值是“一次开发处处可用”但代价是你需要多运行一套 MCP server 进程排查链路变长。裸 HTTP 的方式即模型直接生成 URL 去访问看起来灵活但实际工程上我强烈不推荐。模型生成的 URL 可能有拼写错误、缺少参数、安全风险难控制。你写的是 Agent不是爬虫不要让模型直接裸奔到外部服务。不论哪种协议工具的注册表管理都要做好。每加一个工具必须写清楚工具名、用途描述、参数 schema、示例、超时配置、错误语义。工具文档不完整模型就会在调用时“自由发挥”而自由发挥是线上事故的温床。2.4 决策四记忆策略窗口、向量库还是混合记忆策略是整个 Agent 设计里最容易被低估的一环。做不好要么模型上下文被无用的历史塞满要么用户换个设备Agent 就“失忆”。第一档纯窗口记忆。只保留最近 N 轮对话。实现最简单但不能回答任何跨会话的问题。第二档摘要记忆。在窗口耗尽前把之前的内容做一轮 summarize保留摘要作为长期记忆清除原始明细。适合对话场景但摘要会丢失细节不适合精确回忆。第三档向量库记忆。把所有记忆片段向量化存储每次任务开始时检索与当前问题最相关的片段。适合做“知识型 Agent”比如企业内部知识问答、用户偏好记忆。第四档混合记忆。短期用窗口中期用摘要长期用向量库工作状态用 Redis。这是大部分生产级 Agent 的最终形态但复杂度也最高。我建议从第二档开始做即摘要记忆。因为它能立刻解决上下文膨胀问题实现成本又不高。等确实需要“记住用户上一次的偏好”这类场景时再引入向量库不要一开始就上全套。2.5 决策五并发模型同步串行、异步并发还是队列削峰“ai agent 怎么扛并发”是热搜问题也是工程化最关键的决策。Agent 的一个任务会反复调用模型和工具单次任务耗时可能 5 到 60 秒比普通 HTTP 接口长得多所以并发模型直接决定服务能不能撑住。同步串行的方式一个请求占住一个 worker 直到任务结束。想要提高吞吐只能靠横向加副本。这种方式实现最简单但资源浪费明显——一个模型调用等待网络响应的空档worker 闲着也是闲着。异步并发的思路是在等待模型响应时让出 CPU让同一个 worker 能同时处理多个任务。FastAPI 的 async 接口天生适合这种场景LangGraph 的节点函数如果都写成 async整个 Agent 可以在一个事件循环里跑。队列削峰的思路更稳前端请求进来后不直接执行 Agent而是把任务丢进队列比如 Celery、Redis Stream由固定数量的 worker 消费。用户这边立刻收到“任务已受理”做完后通过轮询或回调获取结果。这种方式牺牲了一点实时性但换来的是系统上限高不会因为突发流量把模型 API 打爆。我的决策建议是内部工具或低并发场景用 async 连接池就够了外部 API 成本和速率限制严格的场景一定要上队列削峰。还有一条铁律任何 Agent 服务都必须有并发上限保护防止一个团队的手滑脚本把模型 API 打到限流。2.6 决策六可靠性设计重试、超时、幂等与降级Agent 比普通 API 更容易出故障因为它同时依赖模型、工具、外部服务三条链路。可靠性设计必须贯穿始终。超时是基础。模型调用要超时工具调用要超时整轮 Agent 循环也要超时。任何一个环节无限等待都会拖垮整个服务。重试要讲究策略。模型返回格式错误可以带修正提示重试一次工具调用超时直接标记失败不要让模型重试一个必然超时的工具外部 API 5xx可以做指数退避重试但最多三次。幂等是很多人忽略的。你的工具如果涉及扣费、发消息、写订单一定要设计幂等键。Agent 可能因为超时重试而重复调用同一个工具没有幂等键用户会被扣两次钱消息会发两遍。降级是最后的保险。主力模型挂了自动切到备用模型工具挂了给用户返回“当前暂时无法使用 XX 功能”。不要追求 Agent 永远正确要追求 Agent 挂了之后还有一条能走的路。2.7 决策七可观测性Trace、评估与成本监控最后一个决策点是可观测性。说实话这是我见过最多团队跳过但其实最救命的决策。Agent 的可观测性要比普通服务复杂得多因为你无法得知某个错误是模型的问题还是工具的问题还是状态机的问题。Trace 要记的东西包括每次模型请求的输入输出、token 数、耗时每个工具的入参出参、错误信息每个状态节点的流转路径整轮对话的耗时和成本。实现方案可以用 LangSmith、Langfuse或者自研打日志。关键不是选工具而是把 Agent 执行过程当成一条完整链路来观测而不是只看最终的 HTTP 响应。评估是另一个常被忽略的环节。不要用“凭感觉”来判断 Agent 改得好不好要建立回归测试集。收集 50 到 100 条真实任务写清楚每条的预期结果每次修改提示词或模型时跑一遍测试集看通过率变化。成本监控最后说是因为它最容易拖垮项目。Agent 的 token 消耗不是线性的一个任务可能反复循坏 N 次token 消耗是普通 API 的 5 到 20 倍。每周拉一次 token 消耗报表看到异常飙升立刻定位是哪个环节多调用了。3. 实操用 FastAPI 加 LangGraph 搭一个能并发的 Agent 服务决策点讲完我直接分享一套真实可跑的方案。用 FastAPI 做 HTTP 层、LangGraph 做编排、Redis 做状态存储这个组合是我在多个项目中验证过的能扛住中等规模并发关键组件少排错容易。3.1 为什么选这三个组件FastAPI 的 async 机制和 Agent 的执行模型完美契合。Agent 的大部分时间都花在等待模型 API 返回上用 async 可以最大限度提升单机吞吐。LangGraph 的图模型适合显式表达 Agent 的规划、执行、反馈循环尤其是多工具场景图的每个分支都清晰可控。Redis 负责状态持久化和轻量级任务队列进程重启、多副本部署都能保证状态不丢。我之前试过用纯 Django 做 Agent 后端遇到的问题是异步支持比较别扭而且 Django 的重型会话管理对 Agent 用户态没什么用。换成 FastAPI 之后整个 Agent 服务的代码量至少减少三分之一。做 Agent 服务轻量是很大优势。3.2 核心代码Agent 节点、工作流和 HTTP 入口先定义一个简单的智能体状态包含消息列表和当前步骤from typing import Annotated, TypedDict import operator from fastapi import FastAPI from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): messages: Annotated[list, operator.add] step: str tool_results: dictoperator.add表示消息列表是累加而不是覆盖。LangGraph 的状态更新默认是覆盖整个字段但消息是增量写入的所以要指定这个 reducer否则前几轮的对话会被冲掉。这个细节我见过很多人踩坑。接下来定义模型调用节点和工具调用节点async def call_model(state: AgentState): prompt build_prompt(state[messages]) response await llm_acall(prompt, toolsTOOL_SCHEMAS) if response.tool_calls: return {messages: [response], step: tools} return {messages: [response], step: end} async def call_tools(state: AgentState): tool_calls state[messages][-1].tool_calls results [] for tc in tool_calls: res await execute_tool(tc[name], tc[arguments]) results.append({ role: tool, tool_call_id: tc[id], content: res, }) return {messages: results, step: model}节点的职责要单一call_model只负责推理根据模型输出决定下一步call_tools只负责执行工具并返回结果然后回到模型节点进行下一轮推理。这种二元循环是 Agent 的基本盘。然后构建状态图builder StateGraph(AgentState) builder.add_node(model, call_model) builder.add_node(tools, call_tools) builder.add_edge(START, model) builder.add_conditional_edge(model, lambda state: state[step], {tools: tools, end: END}) builder.add_edge(tools, model) graph builder.compile()条件边就是决策逻辑模型输出工具调用意图就去工具节点模型认为任务完成了就结束。这样整个 Agent 的循环路径是显式的出问题看状态图就能定位。HTTP 入口用一个异步接口app FastAPI() app.post(/agent/run) async def run_agent(req: AgentRequest): state { messages: [{role: user, content: req.query}], step: model, } result await graph.ainvoke(state, config{recursion_limit: 20}) return assemble_response(result)注意recursion_limit要设置一个上限防止 Agent 陷入无限循环。模型一旦反复调用工具、工具结果又让模型继续调用没有这个限制一个请求能跑到地老天荒。一般 10 到 20 次循环就够了超过直接截断并返回错误提示。3.3 并发配置异步、连接池和状态隔离上面这套代码本身已经支持并发——graph.ainvoke是异步执行的FastAPI 也能并发处理请求。但真正的并发瓶颈在模型客户端和工具客户端。模型客户端必须做连接池。OpenAI 兼容 SDK 默认会复用连接但如果你用了自定义的 HTTP 客户端一定要设置连接池数量和超时import httpx client httpx.AsyncClient( timeouthttpx.Timeout(10.0, connect5.0), limitshttpx.Limits(max_connections200, max_keepalive_connections50), )连接池不够高并发下会出现大量Connection reset by peer到时候你分不清是模型 API 的问题还是自己服务的问题。状态隔离也要小心。LangGraph 的ainvoke每次创建独立的 state 实例所以并发安全没问题。但如果你把 state 存在模块级变量里或者用全局变量存记忆那并发下一定会串数据。记忆存储要放到 Redis并且每个用户或者会话用独立的 keyawait redis.set(fagent:memory:{session_id}, json.dumps(memory_data), ex86400)还有一个容易被忽略的并发坑工具函数如果是同步阻塞的直接放在 async 节点里会卡住整个事件循环。比如requests.get或者 pandas 大表计算我遇到过一次Agent 服务 QPS 直接掉到个位数。解决方法是把同步工具丢进线程池import asyncio import run_in_executor result await loop.run_in_executor(None, sync_tool_call, tool_args)3.4 部署与压测从单机到多副本单机部署时一个 Uvicorn 进程就够了但建议起多个 worker。注意LangGraph 的状态放在本机内存里时多 worker 无法共享状态所以生产环境要把 checkpointer 配置到 Redisfrom langgraph.checkpoint.postgres import PostgresSaver checkpointer PostgresSaver.from_conn_string(postgresql://...) graph builder.compile(checkpointercheckpointer)用 Postgres 或 Redis 做状态持久化整个服务才能横向扩展。多副本部署时每个请求落在哪个副本都可能不同没有统一的状态存储用户会感觉 Agent “每次聊的都不一样”。压测时不要只压 HTTP 接口要看模型 API 的实际吞吐。先用 k6 或者 Locust 打 100 个并发请求观察三个指标模型 API 是否开始返回 429 限流。平均任务完成时间是否线性上涨。token 消耗量是否随并发飙升。这三个指标里429 是最常见的瓶颈。一旦出现不要想着加机器先把任务改成队列削峰或者给模型 API 做本地缓存同样的任务问题直接命中缓存不再重复调用模型。4. 常见问题与排坑实录这一部分是我在各个 Agent 项目里踩过的坑和排查思路整理成速查形式每个问题都有实际参考价值。4.1 模型输出的 JSON 就是不合法怎么解这是最频繁的问题。模型告诉你“我要调用工具”但输出的 arguments 是个残缺 JSON或者参数名和 schema 对不上。第一道防线是让模型用严格的 JSON Schema 输出。提示词里写清楚某些模型还支持响应格式参数比如 OpenAI 的response_format{type: json_object}。第二道防线是解析做成容错式。不要用json.loads一把梭先试解析失败后尝试给模型发一条“你的上次输出 JSON 解析失败请纠正后重新输出”把失败信息拼回消息列表让模型自己修复。这招成功率很高。第三道防线才是规则修正。写一个小的 JSON 修复器自动补全缺少的引号、括号但只作为兜底不要让这层逻辑承担主要职责。4.2 工具调用产生幻觉参数凭空捏造模型没有真正“看到”用户数据它可能根据上下文猜一个用户 ID然后拿去调用工具。这个坑在生产环境特别危险因为你可能因为一个虚构的 user_id 查到别人的数据。我的处理办法是所有工具调用参数先做强校验。user_id、order_id 这类必须是当前会话上下文里出现过的实体不能接受模型凭空生成的 ID。校验失败直接返回错误让模型换一种处理方式。另一个办法是把工具参数设计成“引用式”。不为用户提供明文 ID而是提供引用列表比如user_options[{label: 张三, ref: u_001}]模型只能从 list 里选不能自己编。这样虽然增加了调用的轮次但安全性大幅提升。4.3 上下文越用越长Agent 越来越“傻”这是记忆策略没做好的典型症状。前几轮任务完成得好好的聊到第十轮模型开始答非所问因为上下文被大量工具结果和过程信息塞满。解决方式就是我之前提到的摘要记忆。当消息列表长度超过预设阈值比如 30 条就触发一次压缩async def compress_messages(messages: list) - list: summary await llm_acall([ {role: system, content: 把如下对话压缩成一份摘要保留关键用户偏好和已确定的事实。}, {role: user, content: json.dumps(messages, ensure_asciiFalse)} ]) return [{role: system, content: f对话摘要{summary}}]压缩后的摘要替换原始明细模型重新获得“清醒”的上下文。我实测下来摘要记忆能让同等任务的成功率提升 20% 以上绝对值得做。4.4 并发一高状态就串了症状是两个用户的对话内容互相混A 用户的工具结果出现在 B 用户的上下文里。排查方向先看状态存储。如果你把 state 存在全局变量或者类变量里那必串无疑。每个请求必须用独立的状态实例持久化用 Redis 或数据库并给每个会话绑定独立的thread_id或者session_id。另一个排查方向是 Redis key 设计。如果你用messages:{session_id}这种粒度没问题但如果你用了不带 session 的全局 key那就一定会串。写代码时把 key 设计当作数据库 schema 来对待前缀 业务字段 唯一ID缺一不可。4.5 成本每个月都在翻倍怎么控Agent 的 token 消耗是比服务器费用还大的隐性成本。我在项目里见过一次一个月 token 账单比机器成本贵五倍原因是一个死循环的 Agent 任务循环了 20 次才被 limit 切断。首先给每个 Agent 任务设置单次消耗上限。用一个计数器记录每轮模型调用的 token 数超过上限直接终止任务。其次做工具结果缓存。同一个工具、同样的入参返回结果在短时间内不变化就缓存起来下次直接复用不用再进 Agent 循环。最后每周做一个 token 消耗 TOP 报表。找到消耗最高的任务类型和用户针对性优化。比如某个高频任务用了主力模型但实际简单换成快速模型成本可能直接下降 80%而体验几乎不受影响。5. 一点更上头的体会这些年我过手的 Agent 项目最深的体会是Agent 工程化拼的不是大招而是每个环节都别犯蠢。模型选型、工具暴露、记忆管理、并发控制、可观测性每个决策点单独看都不难难的是把它们串成一个稳定系统。Demo 阶段可以靠灵感生产阶段只能靠纪律。如果你现在正准备启动一个 Agent 项目我的建议是从决策点先做表格把模型、框架、记忆、并发方案写清楚再动手。另一个提醒是不要陷入“框架迷信”LangGraph 也好自研也罢只是工具真正决定系统质量的是你对模型、上下文、工具交互这些底层机制的理解。还有一个小技巧分享给 Agent 加一层“最后一个动作解释”——在任务结束时让模型用一句话总结它做了什么、为什么这么做。这个解释既给用户看也给开发者看排查问题的时候比看一百行日志都直接。