写这篇东西的起因是我发现身边很多团队对 AI Agent 的理解停留在“大模型加一个 while 循环”的层面。Demo 跑起来很兴奋一上生产就原地打转工具调用不稳定、上下文越用越乱、成本账单一个月下来吓人一跳。我也经历过这个阶段所以想把这些坑系统地讲清楚。文章会先拆掉 Agent 的七个构成要素再沿着工程落地的顺序把七个关键决策点一个个摆出来。不管你是后端工程师、算法工程师还是技术负责人都能在里面找到可以直接拿去复用的取舍依据。1. 七要素拆解先搞清楚 Agent 身上到底长了哪些部件很多人一说 AI Agent第一反应是“能自己干活的大模型”。这话对了一半。模型只是其中一块真正让 Agent 跑起来的最小系统至少要包含七个部件。少一个项目就会在某个意想不到的环节翻车。1.1 模型Agent 的思维底座模型是 Agent 的大脑负责理解问题、生成回复、决定下一步动作。它决定了整个系统能力的天花板推理强不强、指令跟不跟、上下文窗口大不大、工具调用稳不稳。选模型不是越贵越好要看任务类型。比如做信息抽取小模型加速可能更划算做复杂的多步推理参数大的模型表现明显更稳。我的经验是先把一两个核心场景跑通做一个能力基线测试再决定用哪个模型做主力。不要一上来就全线接入最大的模型推理通道的选型和成本控制放在后面章节细说。1.2 指令System Prompt 就是行为边界System Prompt系统提示词是 Agent 的行为公约数用来约束模型的角色、语气、流程和边界。一个简单的 Agent 可能只写“你是客服助手”但一个生产级的 Agent指令里必须写清楚能做什么、不能做什么、遇到模糊问题怎么处理、调用工具之前要满足哪些条件。实际开发中最常见的问题不是 Prompt 写得太短而是写得太满。把几百条业务规则全塞进 System Prompt不仅浪费 Token还会让模型在冲突规则之间摇摆。我的建议是分层核心指令保持精简业务细则放到执行时动态注入例如在检索到的资料里让模型参考而不是全部写死进 Prompt。1.3 工具没有 Function CallingAgent 只是高级聊天框工具是 Agent 伸出去的“手”。一个只能对话不能执行动作的 Agent 价值有限真正的 Agent 需要通过工具查询数据库、调 API、操作文件、发消息。当前工程上最主流的协议是 Function Calling函数调用模型根据你提供的工具描述输出一个结构化的调用意图然后你的代码负责真正执行。这一步有个容易被低估的细节工具描述写不好模型就调不对。工具名要精准、参数要严格约束、描述要写明“什么时候用这个工具”和“返回值是什么格式”。我把这个环节称为 Schema 工程后面会专门展开。1.4 记忆短期上下文和长期仓库必须分开管记忆解决的是 Agent “翻旧账”的能力。短期记忆对应上下文窗口模型能看到最近几轮对话长期记忆则需要一个外部存储把历史信息、用户偏好、任务状态持久化下来在需要时检索并注入上下文。很多第一次做 Agent 的人会把全部历史永远放在上下文里结果窗口爆掉或者被老信息干扰新判断。正确的做法是区分哪些信息必须常在“工作记忆”里哪些信息只要在特定时刻被检索出来。记忆管理不是附加功能它直接决定 Agent 能不能处理长会话、多轮交互和跨天任务。1.5 规划把大任务拆成步骤比多问几次更重要规划是 Agent 从“被动应答”升级为“主动执行”的关键。面对一个复杂目标模型需要决定先做什么、再做什么以及是否需要用多个工具配合完成。常见的规划思路有 ReAct让模型边推理边行动每步先想后做和 Plan-and-Execute先整体生成步骤列表再一步步执行。实际工程里规划策略的选择要结合任务复杂度。任务步骤固定时直接把流程写死在代码里比让模型自由发挥更可靠任务开放且步骤不固定时才需要模型参与规划。这里的关键是“把确定性留给代码把不确定性留给模型”。1.6 执行与反馈循环不能空转每一步都要有校验执行就是真正调用工具、完成任务反馈则是把工具返回的结果交回给模型继续判断。这个循环要正常转起来必须有三个保障超时控制、结果校验、异常分支。工具调用可能超时、返回的数据可能是错的、API 可能直接报错Agent 必须能识别这些情况并且决定是重试、换工具还是直接告诉用户失败。我见过太多把“循环”写成“死循环”的代码一个工具返回了异常数据模型还在反复调用最终烧掉一大笔 Token 才因为超时退出。这不是模型笨是工程上缺少护栏。1.7 编排单体智能还是多体协作是架构分水岭编排处理的是复杂度分配用一个强大的单体 Agent 解决所有问题还是拆成多个专业子 Agent 协作。这个选择决定了系统的整体形态和后续维护体验。单体 Agent 简单直接、上下文共享容易但一个任务里塞了太多技能时指令会互相干扰工具选择也会变慢变乱。多 Agent 各司其职、扩展性强但要解决信息传递、任务分配和死锁问题调试成本会上一个台阶。我的观点很明确初期能单体就不要多体。多 Agent 不是能力更强的代名词而是你被迫面对高复杂度时的一种解法。2. 从七要素到七个决策点为什么清单解决不了工程问题七要素解决了“一个 Agent 由什么构成”的问题但真正干活的时候你会发现每个要素背后都有好几个互相矛盾的选择项。要素是静态的结构决策点是动态的取舍。构建一个 Agent 的过程本质上是在每个要素的实际落地路径上做一次选择。举几个例子模型要素对应的是“用哪家模型、怎么路由、要不要自部署”工具要素对应的是“怎么设计 Function Calling 的 Schema、怎么容错”记忆要素对应的是“上下文中放什么、外部存什么、什么时候检索”。这些选择不能独立决定它们是互相牵连的。2.1 一张表看懂要素与决策点的对应关系七要素对应决策点最核心的一句话模型决策点二模型与推理通道模型选型不是选最强的是选最合适的指令决策点一框架选型框架帮你管指令的生命周期但要清楚代价工具决策点三Function Calling Schema 设计工具定义得越严格调用成功率就越高记忆决策点四上下文预算与记忆分级Token 是硬成本记忆策略就是成本策略规划决策点五规划策略简单的任务用代码定流程复杂的才让模型想执行与反馈决策点六错误恢复与可观测性先想好失败路径再想成功路径编排与全部决策点相关单体优先多体是最后手段2.2 决策点的核心逻辑先选型再编码七个决策点有一个共同的思考顺序先确定项目所处阶段和失败容忍度再做具体方案。比如做一个企业内部知识库问答 Agent和做一个面向 C 端用户的自动化助手两者的模型成本策略、工具调用容错方式和记忆管理方案完全不同。前者的失败可以接受重试和人工介入后者必须在前台给出流畅的降级体验。很多项目之所以做不下去不是代码写不出来而是在动手之前没想清楚这些前提。后面五章我把这七个决策点逐个展开每个都给出明确的选型思路和操作建议。3. 决策点一与二框架选型、模型与推理通道框架和模型是所有项目开工前就要定的事但它们往往也是最容易被“随大流”决定的事。别人用什么框架你也用什么哪个模型宣传得响你就迁到哪个。这是两个成本极高的决策尽早清醒过来比较好。3.1 决策点一用框架还是自研取决于迭代速度和失败容忍度市面上的 Agent 框架很多比如 LangChain、LlamaIndex 这类成熟框架也有不少轻量级编排工具。选择框架的核心逻辑不是“哪个功能多”而是“你和团队的开发速度、对 PoC 和生产的预期分别是什么”。如果目标是快速验证业务场景比如一周内做一个能检索资料并回答问题的内部工具框架是划算的它会帮你把 Prompt 模板、工具调用循环、向量库接入这些事情都封装好你只需要写业务逻辑。但不要忽略框架的三层代价抽象层升级带来的不稳定、隐藏的 Token 消耗很多模板默认塞入大量上下文、以及出错时你需要翻框架源码才能定位问题。如果你的场景是强业务定制比如工具调用逻辑非常特殊、需要精细控制每一轮 Prompt 的拼接、或者对延迟和成本极其敏感我会建议自研一个几十行核心代码的 Agent 循环。原因很简单Agent 的骨架并不复杂最核心的就是“模型边推理、边调用工具、边拿结果继续推理”的循环关键路径掌握在自己手里后面做监控、做评估、做任何优化你都清楚改哪里。我的大致标准是验证期用框架快速证明价值业务逻辑稳定后逐步替换或改造。任何框架都只是脚手架工程后期最大的敌人反而是框架帮你隐藏掉的复杂度。3.2 决策点二模型路由不是摆设是稳定体验的后台模型选型要考虑三个维度能力、成本、延迟。能力决定能不能完成任务成本和延迟决定能不能规模化。一个很常见的模型方案是“分级路由”简单请求走参数较小的模型复杂请求走参数较大的模型。比如意图识别、关键词抽取、格式转换这类任务用轻量模型就能完成而多步推理、长文总结、复杂工具选择才需要顶级模型。模型路由的实现也不需要多复杂一个简单的分类器或者另一层较小的模型就可以做前置判断。这里的关键是设好“兜底”逻辑小模型输出置信度不足时自动升级到大模型不能让用户在体验上感觉到“突然变笨”。另一个要考虑的问题是自部署还是 API 调用。自部署可以省下长链条调用的边际成本、数据也留在内部但 GPU 资源、运维和稳定性保障都需要团队有能力兜住。API 调用省事但要盯住配额、限流和价格调整。我的建议是日调用量上来之后把高频且稳定的任务拆出来做私有化部署动态变化的复杂任务继续走 API这样成本曲线会更健康。4. 决策点三与四工具协议与上下文预算工具和记忆是 Agent 能否“干实事”和“干长活”的两块基石。很多 Agent 项目做起来之后最大的性能问题不在模型而在工具调用的失败率和上下文空间的失控。这两个决策点需要在编码前想清楚。4.1 决策点三Function Calling 的 Schema 做不好Agent 就手残当前主流模型都支持 Function Calling你给模型一份 JSON Schema 列表模型在需要时返回一个包含函数名和参数的对象。你的程序负责执行函数并把结果返回给模型继续推理。这个流程看似简单真正决定成败的是 Schema 的设计质量。我总结过三个实用原则。第一函数描述要写“触发条件”不是写“功能百科”。比如一个查询天气的工具描述里不要写“获取世界各地的天气数据”而要写“当用户询问当前天气、气温、降水或未来预报时使用此工具并传入城市名”。模型是靠描述来决定调用哪个工具的描述越贴近真实对话语境选工具越准。第二参数要严格约束。能用枚举就写枚举能用 format 限制字符串格式就写清格式能用必填就标必填。比如{ name: query_order, description: 根据订单号查询订单状态当用户询问订单进度、物流信息、发货时间时使用, parameters: { type: object, properties: { order_id: { type: string, pattern: ^[A-Z0-9]{16}$, description: 16位订单编号字母大写 } }, required: [order_id] } }这样写的好处是模型理解成本低而且你的代码不需要做太多归一化处理。我看过太多团队在代码里拼命兼容模型传出的脏参数却没有在 Schema 源头做约束这是舍本逐末。第三返回值也要规范化。所有工具返回给模型的内容尽量统一成一段格式固定的文本或 JSON并且带上“调用成功/失败”的状态。模型读了之后才能做出正确决策。返回结构混乱模型会答非所问。4.2 决策点四把 Context 当钱花记忆分级和压缩缺一不可Context上下文窗口是 Agent 最稀缺的资源。模型需要看到足够信息才能正确推理但塞满无关内容会稀释注意力还会让 Token 成本直线上升。做记忆管理我习惯分三个层级工作记忆是当前轮次必须常驻的内容比如系统指令、最近两轮对话、当前任务状态。工作记忆里每多一个与当前任务无关的字都是在浪费模型的注意力。摘要记忆是把早期对话压缩成一段摘要。当对话超过一定轮次就把早期信息交给摘要模型提炼成几十字的要点保留核心约束继续参与后续对话。检索记忆是放在外部存储里的完整历史比如向量库或数据库。只有在相关时才通过检索注入上下文比如用户问“我上次的偏好设置是什么”再去查。实际操作上我会给上下文分配一个 Token 预算。比如 8K 窗口的模型预留 2K 给系统指令和工具定义预留 3K 给当前任务和相关检索结果剩下 3K 给模型输出和工具返回值。超出预算的内容宁可截断也不要把预算撑爆因为窗口写满时模型的表现会肉眼可见地变差。5. 决策点五规划策略——ReAct 与 Plan-and-Execute 的工程分界规划是 Agent 最接近“智能”的部分也是最容易被过度设计或过度忽略的部分。很多团队一上来就要 Agent “自主规划”结果任务拆得稀碎、执行时还容易跑偏。这块要按任务的确定性程度来选策略。5.1 ReAct大多数场景下的默认选项ReAct 的思路是让模型交替进行推理和行动观察当前状态思考下一步调用工具观察结果再思考下一步。它的优点是灵活能应对意外情况非常适合交互式任务和多步工具调用。工程实现上ReAct 的循环有一个常见的伪代码结构while True: next_action agent.decide(history) # 模型基于历史决定下一步 if next_action.type finish: break result execute_tool(next_action) history.append(result)但这里有个很微妙的点每一步的思考都需要消耗 Token而且模型在一次循环里如果连续选错工具整个任务会越来越偏。我的做法是给 ReAct 循环加两个保险。一是最大步数限制。比如限制最多执行 8 步超过就强制结束并生成“任务未完成”的反馈避免无限循环。二是每步的“决策确认”。如果模型决定调用的工具与当前用户目标明显无关可以用简单的规则判断比如目标领域和工具域不匹配就打断并引导它回到正轨。这两个机制不需要多强的模型就是简单的工程护栏但能省下大量无效 Token。5.2 Plan-and-Execute任务复杂、步骤稳定时的升级路径Plan-and-Execute 的核心变化是先让模型生成一份完整计划然后逐步执行。比如“分析这份报表并生成周报摘要”这类任务先让模型写出计划“读取数据表格、统计数据趋势、生成摘要草稿、按照模板输出”之后按照计划一步步执行。相比 ReAct它的优势是减少重复推理、Token 开销更小、任务整体结构清晰。代价是灵活性差执行过程中如果出现计划外的情况或者某个步骤的前提条件变化整个计划就可能作废。所以这个策略适合流程相对固定、且可提前拆分的大任务。我的分界标准很简单如果任务步骤基本恒定只是需要反复操作优先 Plan-and-Execute如果任务是开放性应对比如客服对话、故障排查每一步都有可能分支就用 ReAct。在实际项目里很多 Agent 是混合的大方向走 Plan-and-Execute每个步骤内部可以再用 ReAct 处理意外。6. 决策点六与七错误恢复、可观测性与 Token 账单这两个决策点最容易被拖到最后才考虑但恰恰是它们决定了 Agent 能不能从 Demo 走到生产环境。一个演示用的 Agent 不需要考虑错误恢复上线之后三天两头静默失败用户很快就会失去信任。6.1 决策点六先想好失败怎么办再想成功怎么办Agent 的失败模式比传统程序丰富得多模型输出不符合预期、工具调用参数格式错误、外部 API 超时、校验结果不通过、循环步数超限。如果不提前设计失败路径Agent 就会在用户面前表演“自信地犯错”。我的实践经验是给每个工具调用都做三个防护。超时控制外部 API 设置明确超时时间比如 5 秒未响应就认为失败。重试策略区分瞬时错误和永久错误瞬时错误可以重试一两次永久错误必须直接反馈给模型换路径。降级方案核心工具不可用时是否可以用其他工具替代或者直接向用户说明能力受限。另外一个容易被漏掉的点是输出校验。模型生成的最终答案不能直接展示给用户要经过一轮规则校验包含敏感内容没有、和工具返回结果矛盾没有、格式符合要求没有。这个校验不一定要用大模型正则规则加启发式就能挡住大多数问题。可观测性上Agent 项目必须记录三样东西完整调用轨迹每步的输入输出和决策原因、Token 消耗明细每个环节各烧了多少、失败样例归档用于持续优化 Prompt 和工具定义。有了这些数据你才能在用户骂你之前自己发现问题。6.2 决策点七Token 经济学是 Agent 规模化的第一约束很多人算 Agent 的成本时只看“一次问答烧多少 Token”。但 Agent 的任务往往是多轮循环一次完整任务可能消耗几万甚至十几万 Token。这笔账不算清楚规模化就是空谈。我给大家一个真实的估算方式假设一个任务平均需要 6 次模型调用每次输入 4000 Token、输出 800 Token。如果模型单价按输入 20 元/百万 Token、输出 60 元/百万 Token 来算一次任务的成本大约是6 乘以4000/100万乘以20 加上 800/100万乘以60算下来大概 0.77 元。一天一万次任务月成本就是二十多万。而且这些数字还是保守估算工具定义、历史记忆、检索结果都会把输入 Token 进一步推高。省 Token 的几个有效手段按性价比从高到低排序是减少注入上下文的内容、用摘要替换完整历史、复用系统级中间结果比如缓存常用工具的返回结果、更精准的工具描述避免反复试错、用小模型处理简单子任务。其中最容易见效的是第一条每加一段上下文之前先问自己这段信息真的必须让模型看到吗提示Agent 的成本优化不是等账单出来再动手的最好在系统设计阶段就为每个环节设 Token 预算并把预算指标纳入上线前评审清单。最后说两句AI Agent 的工程实现本质上不是一道算法题而是一道系统设计题。模型选型、框架选择、工具协议、记忆策略、规划方案、错误恢复、成本预算每一个决策都会牵动其他环节。做完这几个决策点你的 Agent 能不能稳定服务于真实用户心里基本有数。我个人的建议是不要一上来就追求“全自主、全自动”先做一个小闭环把工具调用、记忆管理和成本监控这三件事跑通再逐步放开自由度。Agent 的工程化没有银弹有的只是在每个决策点上基于业务特点做取舍的耐心。