写这篇东西的起因，是我发现身边很多团队对 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 Calling，Agent 只是高级聊天框

工具是 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 一张表看懂要素与决策点的对应关系

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 的工程化没有银弹，有的只是在每个决策点上，基于业务特点做取舍的耐心。