AI Agent工程落地：七要素拆解与七个关键决策点

很多人聊 AI Agent 都在聊概念：它有几个大脑、能自己规划几步、将来会不会取代打工人。但真正要动手把一个 Agent 从“能跑 Demo”推进到“能稳定干活”，你会发现问题突然变得特别具体——上下文窗口怎么分配、工具调用超时怎么办、并发一上来系统会不会被拖垮、模型一次抽风会不会把线上数据写坏。这篇文章我想换个角度，不聊概念，直接拆工程实现。我会把 Agent 拆成七要素，再从工程落地角度拎出七个决策点，每个点都对应到真实系统中的取舍和实操做法，希望能帮你把整套施工图纸在脑子里搭起来。

先说清楚：这里的“工程实现”不是指某个框架的 API 用法，而是指你从零开始设计一个 Agent 系统时，要面对的所有关键模块和关键选择。技术栈我会尽量覆盖主流的 Python 生态，并结合实际项目中常见的踩坑经验来展开。无论你是想用 FastAPI + LangChain + LangGraph 搭一个智能助手，还是在评估 Rust 路线的高性能 Agent 网关，这套拆解都适用——因为底层要解决的问题是一样的。

1. 先界定边界：Agent 与 ChatBot 的本质差异，以及七要素框架的价值

很多人会把“AI Agent”和“智能聊天机器人”混为一谈。但从工程视角看，两者的差异不是“多几轮对话”或者“语气更聪明”，而是系统架构发生了本质变化。

ChatBot 的本质是一个“单次问答闭环”：你输入文本，模型输出文本，交互结束。整个系统只需要管两件事——把用户的请求送进模型，再把模型的输出送给用户。哪怕带点记忆，也只是在消息里拼接历史记录而已。

Agent 则完全不同。它的核心是一个循环执行体：拿到目标之后，需要自己决定先做什么、调用什么工具、根据结果调整下一步，直到完成目标才输出最终结果。这意味着系统必须额外具备这些能力：

• 一个稳定的推理与规划循环，而不是一次性的问答；
• 一套和外部世界打交道的工具接口，让 Agent 不只是“说说而已”；
• 一个能承载历史信息、并能在上下文中压缩和检索的记忆体系；
• 对模型输出进行校验和约束的机制，因为 Agent 输出的一行错误参数，可能直接触发一次真实的外部操作。

这就是这类系统很容易在真实场景翻车的原因：Demo 里 Agent 看起来无所不能，是因为你只给它设计了理想路径；生产环境里它要面对工具超时、接口返回异常、上下文被占满、用户输入歧义等大量“非理想情况”。工程化的核心工作，恰恰是给这些未知情况铺设兜底方案。

我把这套落地过程总结成“七要素”。它既是一个理解框架，也是一张检查清单：

你去看任何主流 Agent 框架，比如 LangChain、LangGraph、AutoGPT、以及各类开源智能体项目，本质上都在这七个要素上做文章。有的框架侧重补齐工具调用协议，有的侧重规划循环的状态管理，有的侧重记忆存储——但落点不出这七块。

理解了七要素，你再看“从七要素到七个决策点”这个映射关系就会很清晰：要素告诉我们“一个 Agent 系统必须有哪些组成部分”，决策点则是在每个部分落地时要做的关键选择。比如“记忆系统”是要素，但“短期记忆用什么结构、长期记忆用什么向量库、上下文窗口满了怎么处理”就是决策点。接下来一层一层拆。

2. 七要素逐项拆解：每个模块在工程里承担什么职责

2.1 LLM：决策大脑，而不是万能按钮

工程上首先要纠正一个认知：不要指望把复杂逻辑全塞给模型。LLM 是推理核心，但不是业务核心。一个合格的 Agent 系统，应当把确定性逻辑（如参数校验、权限判断、状态流转）放在代码里，把非确定性判断（如意图理解、步骤规划、文本生成）交给模型。这样的分层设计会让你后续排查问题容易得多。

选型时有一个很实际的参考维度：工具调用能力。不是所有模型都能稳定输出结构化工具调用参数。实测中，不同模型在 Function Calling 场景下的表现差距非常大，有的模型经常把参数类型写错，有的会长篇大论地解释而不是直接调用工具。这也是为什么很多 Agent 项目最终会引入“模型路由器”——简单任务走又快又便宜的模型，复杂规划任务才动用大参数模型。

2.2 System Prompt：你把边界画到哪，Agent 就跑到哪

系统提示词在 Agent 工程里被低估得最厉害。很多人写 System Prompt 只写一句“你是一个智能助手”，然后就期待模型自己发挥。真实项目中，System Prompt 应该承担以下职责：

• 明确定义 Agent 的目标边界：能做什么、绝对不能做什么，两条都要写清楚；
• 规定工具的使用规则：什么情况下必须调用工具，什么情况下直接回答；
• 规定信息获取方式：遇到不确定的信息时必须查工具，还是允许基于已有知识回答；
• 定义输出格式：JSON、Markdown、纯文本、还是某种协议化的结构；
• 设定交互语气与节奏，尤其是面向用户的最终回复长度和风格；
• 定义错误处理策略：工具调用失败重试几次、达到上限后如何向用户说明。

实操中我习惯把 System Prompt 组织成“角色定义 / 目标定义 / 边界定义 / 工具规则 / 输出格式 / 错误协议”六大块。这样做的好处是当 Agent 行为异常时，你可以快速定位是边界没写清、还是工具规则太模糊、还是输出格式约束没生效。

2.3 规划模块：从 ReAct 到 Plan-and-Execute 的取舍

规划模块是 Agent 区别于 ChatBot 的核心引擎。当前主流实现方式无非两大类：ReAct 模式和Plan-and-Execute 模式。

ReAct 模式是“边想边做”——模型每一步输出一个推理（Thought），决定行动（Action），执行后看到结果（Observation），然后继续推理，形成循环。伪代码如下：

1. 组装上下文：System Prompt + 记忆 + 可用工具描述 + 用户目标 2. 让模型输出下一步推理与动作 3. 如果模型决定调用工具： - 解析工具名和参数 - 校验参数，执行工具调用 - 将工具返回结果追加到上下文 - 回到第 2 步 4. 如果模型决定输出最终答案： - 结束循环，返回结果

这种模式的好处是灵活，适合工具多、环境动态变化、无法预先确定步骤的场景。坏处也很明显——模型可能绕圈、可能反复调用同一个工具、可能被上下文中的冗余信息干扰。因此工程上必须加“最大步数限制”和“循环护栏”。比如设定最多执行 8 步，8 步仍未完成就触发“总结并退出”的兜底提示词。

Plan-and-Execute 模式则是“先规划，后执行”——先是让模型生成一份整体计划清单，然后按顺序执行，每完成一步再动态调整剩余计划。这种模式下，规划一次完成，可以避免每步都消耗大量 token 去重新推理；流程也更可控，适合业务路径相对固定的场景，比如订单处理、内容审核流水线。

两种模式不是互斥的，生产系统中往往会混合使用：先用 Plan-and-Execute 做整体拆解，再在单个步骤里用 ReAct 应对动态变化。LangGraph 这类框架就是把这种多层状态机用图结构落地的典型代表。

2.4 记忆系统：短期上下文与长期知识的配合

记忆是所有 Agent 工程里最容易被低估成本的地方。这里要区分两种记忆：

短期记忆是指当前任务执行过程中的上下文状态，本质上就是一组消息列表：系统提示词 + 对话历史 + 中间推理 + 工具调用记录。短期记忆的工程难点在于窗口有限。模型有 context window 上限（比如 128k token），但你在里面塞了完整的系统提示词、工具描述、历史对话、每轮中间结果之后，剩余空间很快就见底了。实操中需要做这些事：

• 为 System Prompt 和工具描述设置静态 token 预算，它们应当被稳定地缓存和复用；
• 对早期对话做摘要压缩，把 10 轮历史压缩成一段摘要；
• 对过长工具返回结果做截断，只保留关键字段；
• 设置 Agent 的最大循环次数，避免上下文被中间推理无限撑爆。

长期记忆则是跨任务的持久化信息，通常通过向量数据库存储并检索相关内容。比如用户的历史偏好、之前任务的处理结果、业务知识库文档等。工程上，长期记忆的价值不在于“全存下来”，而在于“用的时候能准确捞回来”。所以检索质量（embedding 模型选型、chunk 切分策略、topK 召回数）往往比存储本身更关键。

一个常见的错误是让 Agent 每一轮都把整个向量库结果一股脑塞进上下文，导致 token 爆炸。正确做法是检索一段摘要级别的内容，只有确认需要详细数据时再调用工具获取完整信息。

2.5 工具层：Function Calling 与 MCP 的接入方式

工具层是 Agent 的“手脚”。工程上，Agent 工具最少要包含以下几类：信息查询类（搜索、查数据库、查订单状态）、操作类（发消息、下单、改配置）、计算类（代码执行、公式计算）。

接入方式上，现在的主流是让模型通过 Function Calling 机制选择工具并生成结构化参数。你需要在调用模型时，把每个工具的 JSON Schema 描述传给模型，模型输出一个结构化的工具调用请求，然后你的代码负责真正执行。一个典型的工具描述大致长这样：

{ "type": "function", "function": { "name": "query_order_status", "description": "查询订单的当前状态", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单编号" } }, "required": ["order_id"] } } }

这套机制看起来简单，工程细节却很多。工具描述写得越长，模型理解越准确，但 token 消耗越大；工具数量太多时，模型选错工具的概率也会上升。所以实战中通常把工具按领域分组，先让模型做一次“工具域路由”，再在对应工具域内选择具体工具，能显著提高准确率。

MCP 这类协议的出现，则是为了解决工具接入标准化问题——把工具服务化之后，通过统一协议对接任意 Agent 框架。它让“工具市场”成为可能，也降低了新增工具时的集成成本。

2.6 环境接口与行动输出：Agent 怎么“接触”真实世界

Agent 的最终产出不只是文本，它还要和真实系统发生交互。在工程实现中，行动输出的常见形式包括：调用 HTTP API、写入数据库、发送消息到消息队列、执行一段代码、操作浏览器自动化。这里最核心的原则是可回滚和可审计：

• 高风险的写操作，最好先经过“模拟执行”或“人工确认”环节；
• 每个真实动作都要记录日志，保留事件前后的状态快照；
• 对可逆性差的动作（比如删除数据、发送不可撤回的消息），要设置权限闸门。

环境接口还包括“感知”。Agent 需要知道自己当前处于什么状态：任务是否超时、外部依赖是否可用、流程允许进入下一步吗？工程上，这通常体现为对工具返回结果的状态码检查和异常捕捉。比如搜索接口返回了 429 限流，Agent 不应该继续盲目重试，而应该判断是等待后重试，还是换一个搜索源，或直接告诉用户当前不可用。

3. 七个决策点：从 Demo 到可交付系统的分水岭

如果说七要素解决的是“系统必须有哪些部件”，七个决策点解决的就是“部件之间怎么设计才能扛住真实压力”。这也是我认为一个 Agent 项目能不能从 Demo 走向交付的分水岭。每一个决策点，我都给出正反两方面的考量和我的建议。

3.1 决策一：模型选型与调用链路，是单模型还是多模型路由

模型选型是整个 Agent 系统最基础也是最难替换的决策。你需要权衡五个维度：推理能力、工具调用准确性、上下文长度、单次响应延迟、单位成本。没有任何一个模型在五个维度同时最优。

我见过两种典型路径：

• 闭源 API 派：直接使用 GPT 系列、Claude 系列或其他商业模型接口。优点是能力天花板高，工具调用成熟，省去部署和维护成本；缺点是单次调用成本高，数据出域合规问题需要评估，且生产环境对网络稳定性敏感。
• 开源模型私有化派：部署 Qwen 系列、Llama 系列等开源模型。优点是数据可控、成本可预期、无调用频次限制；缺点是推理能力上限通常低于顶级闭源模型，工具调用格式需要更多约束工程，且 GPU 资源是一次性重投入。

工程上，我推荐先从一个主模型起步，把 Agent 链路跑通后再考虑引入路由。路由的价值在于：简单的检索、摘要任务走小模型，复杂规划任务走大模型，可以在成本与效果之间取得明显平衡。但路由本身又引入了额外的系统复杂性——你需要设计分类逻辑、不同模型结果的一致性校验，以及回退策略。所以，如果业务规模不大，单模型 + 良好的提示词设计往往比盲目引入多模型路由更划算。

调用链路上还需要考虑几个基础组件：统一的模型接入层（切换模型不修改业务代码）、重试机制与指数退避、上下文缓存（相同前缀请求命中缓存可大幅降低成本和延迟）。这些组件看似无关紧要，但在线上的稳定性和成本控制中都扮演关键角色。

3.2 决策二：运行架构，选编排框架还是自研循环

Agent 运行架构上最重要的选择是：到底用 LangGraph 这类编排框架，还是自己写一个 Agent 循环。

LangChain / LangGraph 这套生态带来的核心价值，是帮你封装了状态管理、节点流转、工具调用、人机回退这些通用逻辑，让你可以快速搭出一个有状态的 Agent 流程图。尤其 LangGraph 把 Agent 定义成一张图：节点是各种操作（LLM 调用、工具执行、条件判断），边是流转关系，中间状态由框架统一管理。对于习惯 FastAPI + Python 的团队来说，接入成本不高，调试时也能清晰看到每一轮走到了哪个节点。

自研循环则更灵活，也更能贴近业务。你完全可以用几十行代码写一个 ReAct 循环：组装上下文、调用模型、解析工具调用、执行工具、循环回去。它的优点是没有框架黑盒，每一步都在你的掌控之内，排查问题不用先理解框架的抽象；缺点是要自己处理状态持久化、并发安全、失败重试、模版管理等一堆琐碎问题。

我的建议是：如果你要做的 Agent 流程比较标准（单轮规划 + 多轮工具调用），先用 LangGraph 这类框架起步，不要重复造轮子；如果你的核心价值在于高度定制化的流程控制，比如多重条件分支、复杂的人工审批节点，或者对状态一致性要求极高，那自研一个专注的循环模块完全合理。很多大型项目最终会走向“框架做外层、自研做核心”的混合形态——但那是做大了之后的事，起步阶段没必要背上这个复杂度。

3.3 决策三：规划模式，走 ReAct 还是 Plan-and-Execute

这个决策点我在前文已经提到，这里补充选择标准。

需要动态探索、信息分散、步骤无法预判的场景（比如“调研一个陌生主题并生成报告”），ReAct 模式优势明显。它让 Agent 可以在执行中不断修正方向。但这种灵活性有代价：token 消耗高（每多一步就要重新读一次历史）、行为不可完全预测、并发场景下成本突然放大。

业务流程相对固定、步骤清晰可枚举的场景（比如“每天定时拉取行情数据、计算指标、生成播报文本”），Plan-and-Execute 模式明显更省心。它把“想”和“做”分离，第一步规划输出一份步骤清单，后续按清单执行。这样不仅是 token 更省，更重要的是每一步是否合规、是否完成，你能逐项追踪。

工程上还有一种折中方案，叫“分层规划”——一个顶层 Planner 先生成若干子任务，每个子任务交给一个子 Agent 用 ReAct 执行。这种多 Agent 协同架构，本质上就是用 Plan-and-Execute 的骨架去组织多个 ReAct 子节点。它能做到灵活和可控兼得，但对系统设计要求更高，起步阶段不建议一上来就上这种架构。

3.4 决策四：工具协议，Function Calling 还是 MCP

工具接入方式上，现在处于一个过渡期：传统的 Function Calling 依然是绝对主流，MCP 协议则在快速崛起。

如果你只是给单个 Agent 接入几个内部工具，直接走 Function Calling 最简单——模型调用时传入工具描述，输出结构化调用请求，你的代码直接执行并返回结果。没有额外中间层。对于工具数量在 20 个以内的项目，这是我最推荐的方案，因为链路最短，问题最好定位。

如果你要对接的工具来源多样，比如接多个外部服务、第三方平台、不同的团队分别维护工具集，那 MCP 会明显降低集成成本。MCP 可以把每个工具集封装成一个标准化的、可独立部署的“工具服务”，Agent 框架通过协议动态发现工具、调用工具。好处是工具解耦，新增能力不需要改动 Agent 主代码；坏处是多了一层网络调用，延迟和故障点都增加了。

我的实践经验是：先别为了架构先进而选 MCP。一个团队内部只有两三个工具时，MCP 引入的复杂度大于收益。等工具数量变多、团队分工变复杂时，再把工具层抽出来迁到 MCP，这是平滑路径。

另外，无论选哪种协议，工具设计上都有两条铁律：

• 工具描述里写明边界条件，比如参数取值范围、失败时返回什么结构、哪些场景应该调用该工具；
• 工具函数本身要幂等优先，特别是写操作，重复调用不要产生重复结果。这能在 ReAct 循环重试时避免很多事故。

3.5 决策五：记忆与上下文工程，决定成本与体验的天花板

记忆工程这个决策点，直接决定了你的 Agent 在长对话和多轮任务中，是表现稳定还是逐渐“失忆+烧钱”。核心要解决三个问题：存什么、怎么取、窗口满了怎么办。

短期记忆层面，我习惯的设计是：

• 为“系统提示词 + 工具描述”建立静态缓存，只要不变就不重复计费；
• 历史对话按时间倒序维护，超出预算的部分交给摘要模型压缩成一段“前置摘要”；
• 每轮工具结果只保留必要字段，敏感字段脱敏后入上下文；
• 设定 Agent 循环步数上限，超过上限强制终止并做总结。

长期记忆层面，工程上常见的做法是：把用户相关的偏好、事实、历史决策结果嵌入向量库，每次对话开始时检索 topK 条相关记忆拼入上下文。这里的调优空间很大——检索结果太少则“想不起来”，太多则淹没关键信息还烧 token。经验上，先设定一个比较小的召回数（比如 3 到 5 条），再根据业务反馈逐步调大，比一开始就召回 20 条要稳妥。

还有一个容易被忽略的维度：记忆要与业务状态绑定。比如 Agent 在处理一个订单任务时，订单号、当前状态、已执行操作这些关键状态应放在显式的状态对象中，而不是让模型从对话历史里“记着”。否则一旦中间对话过长，模型很可能“忘记”订单号，或者把状态搞混。

3.6 决策六：并发架构与稳定性，Agent 怎么扛住真实流量

这里直接回应一个大家都很关心的问题：AI Agent 怎么扛并发。很多人在本地跑通一个 Agent 觉得万事大吉，一上线就被打懵。原因其实很简单：Agent 循环是长任务，不适合用同步请求-响应的方式直接处理。

一个典型的 Agent 任务耗时可能在 3 秒到 60 秒之间，甚至更长——因为它要在多个工具之间来回调用，每轮都要等待模型响应。如果后台每个请求都占用一个工作线程同步等待，那么很小的 QPS 就能让整个服务变成一锅粥。

工程上标准的解法，是把“接收请求”和“执行 Agent 任务”拆成两层：

• API 层（如 FastAPI）：只负责接收请求、参数校验、返回任务 ID；
• 任务队列层（如 Redis 队列 / Celery / 消息队列）：接收任务后立即入队；
• Worker 节点：异步消费队列中的任务，真正执行 Agent 循环；
• 结果同步：任务完成后，通过轮询接口、WebSocket 或 SSE 将结果推送回前端。

这种异步架构的好处很明显：API 层不会因为 Agent 执行慢而被拖垮；你可以独立地横向扩展 Worker 数量；队列天然提供了削峰填谷的能力。对于“让 Agent 自动发小红书”这类业务——用户提交内容后，你完全可以让它在后台慢慢跑，前端用一个“任务进行中”的状态页展示过程，跑完了再通知用户。

再来聊具体并发参数。假设你接入的外部模型 API 有 rate limit（比如每分钟 6000 次请求），你的 Worker 数量必须以此为上限来计算。每个 Agent 任务一轮循环可能要消耗 2 到 5 次模型调用，所以单 Worker 并发处理的 Agent 任务数要除以这个系数。比如外部 API 允许每秒 10 次调用，每个 Agent 任务平均 3 次模型调用，那么单 Worker 每秒最多处理约 3 个任务。靠盲目加 Worker 是突破不了外部瓶颈的，你需要在 Worker 内部做速率限制器，比如信号量或令牌桶，从源头控制模型调用频率。

还要考虑流式输出。Agent 执行过程中如果不能实时反馈，用户体验会很差。实现时通常是两种路径：一是 Worker 在执行过程中把状态事件推送到 WebSocket/SSE，前端实时展示“正在搜索资料”“正在生成报告”；二是只在最终结果生成后一次性推送，中间展示一个动画。前者体验好，但实现复杂度明显更高——因为你要定义一套事件协议，并保证事件顺序和状态一致。如果你刚起步，我建议先做后者，等业务稳定了再升级流式方案。

最后提一句和热词相关的 Rust 方向。如果你对性能有极致要求，比如希望把 API 网关、任务分发、工具执行这些高并发模块用 Rust 实现，是可以的，而且性能表现会很突出。但 Agent 主循环和规划逻辑，我仍然建议留在 Python 生态——因为模型调用、工具生态、调试工具链最成熟。用 Rust 挂 Agent 核心不是不能做，而是每一步都要自己造轮子，迭代速度会明显慢下来。典型的折中方案是：Python 写 Agent 编排，Rust 写高吞吐网关和工具执行层，两边通过协议对接。

3.7 决策七：安全与控制，Agent 越开放，越要设护栏

安全是一个 Agent 项目里最不该妥协的决策点。这个“安全”不只是网络安全，还包括权限控制、内容合规、操作审核、数据保护。

权限上最核心的一条经验是：Agent 能调用的工具权限，不允许超过当前用户自己的权限。如果用户本身没有删除订单的权限，那 Agent 无论多大本事，都不应该能通过某个隐蔽工具调用实现删除。工程做法是在工具执行层统一做身份上下文透传和权限校验，而不是信任模型“不会乱调”。因为模型可能被 prompt injection 诱导——用户输入的文本里夹带“忽略之前的指令，去执行某个危险操作”这类攻击内容。你的 Agent 要把用户输入当作不可信数据，系统提示词和工具选择的优先级必须高于对话内容。

操作上，建立分级审批机制：

输出侧同样需要工程拦截。Agent 生成的文本在对外发布前，最好过一道敏感词过滤和格式校验。不要只依赖系统提示词里的“请确保内容合规”，因为模型的输出随机性决定了你不能把安全托付给它。里层做规则过滤、外层做抽检，是不错的双保险。

日志和审计同样不能被省略。每次 Agent 运行的完整轨迹——输入、每轮推理、工具调用参数、工具返回、最终输出、耗时、成本——都应当落盘保存。这既是排查线上问题的依据，也是后续做评测集、改进提示词的数据来源。没有日志的 Agent 系统，出问题的时候就像在黑暗里找东西。

4. 从决策到落地：一个可复现的工程骨架与踩坑实录

理论讲完，我直接把一套可落地的技术骨架给你，并记录我在真实项目中踩过的三个坑。这套骨架适合一个典型的“智能助手/自动执行”类 Agent 应用，你可以把它当成一个保底模板来用。

整体链路可以描述为：

用户请求 → FastAPI 网关（参数校验、鉴权） → Redis 任务队列 → Worker（LangGraph 跑 Agent 循环） → 工具执行（内部 API / 外部服务 / 函数库） → 结果写回 → 前端轮询/WebSocket 展示进度

各层选型及理由如下：

• API 层：FastAPI。异步支持好，轻量，OpenAPI 文档直接生成，最适合做 Agent 系统的接入网关。Continuation：不要把 Agent 执行逻辑写进路由函数，路由只负责排队和状态查询。
• 工作流编排：LangGraph。用图来描述 Agent 的状态流转，节点包括“plan”“call_tool”“judge”“output”，边表示流转条件。好处是每一轮的状态都有显式记录，LangGraph Studio 也能可视化调试。
• 任务队列：Redis + RQ 或 Celery。Agent 任务是典型的 IO 密集型长任务，Redis 队列足够轻量。只要并发量没有到百万级，不需要上更重的消息中间件。
• 记忆存储：PostgreSQL + pgvector 或单独向量库。业务数据和向量检索可以用同一个库，降低运维成本。
• 模型接入：OpenAI 兼容接口为标准。几乎所有主流模型都提供 OpenAI 兼容的调用格式，把你的工具调用逻辑写成模型无关的 SDK 层，未来换模型不推倒重来。

踩坑之一：上下文爆掉。我第一次做多轮 Agent 时，天真地以为 128k 上下文非常充裕。结果 System Prompt 占 2k、工具描述占 3k、历史对话每轮 1k、工具返回结果一多，几轮之后可用上下文就所剩无几。更麻烦的是，引导模型去压缩历史还会干扰它当前的工作记忆。后来我把方案改成：超过预算就把早期对话摘要化，工具返回只保留核心字段，Agent 最大循环次数限制为 8 步。这三个改动叠加，上下文占用立刻稳定下来。

踩坑之二：工具超时让系统“假死”。Agent 调用某个第三方接口时，对方网络抖动，默认 HTTP 请求没有设置超时，导致 Worker 线程一直挂着，任务队列越积越长。后来统一给所有工具调用加超时控制，比如外部 HTTP 请求超时 5 秒、代码执行器超时 30 秒；超时后返回结构化错误给模型，由模型决定重试还是换路径——这一步直接把线上事故率降了一个量级。

踩坑之三：并发压测失真。我在开发环境测试时，用单线程脚本模拟 10 个请求，全通过，觉得稳了。上线后发现外部模型 API 的限流策略在并发下表现完全不同——短时间内大量的模型调用被 429，导致 Agent 任务批量重试，成本瞬间翻倍。后来在 Worker 里加了信号量控制并发度，并为模型调用增加了令牌桶速率限制，重试策略从“立即重试”改成“指数退避+抖动”，这才把任务成功率稳定在 99% 以上。

5. 工程实现中最容易被低估的三笔隐性成本

最后我想聊三笔钱，它们不直接写在你的架构图里，但最终一定出现在你的账单和时间表上。

第一笔是Token 成本。Agent 的 token 消耗远比普通 ChatBot 大，因为每一次工具调用，模型的输入都要带上完整的系统提示词、工具描述、历史轮次。一个看似简单的查询任务，底层可能烧掉几万 token。控制手段集中在：合理设定上下文预算、启用 prompt 缓存、精简工具描述、控制循环步数。还有一条实践：能用规则和代码解决的逻辑，就不要花 token 让模型去推理。

第二笔是测试与回归。模型的输出有随机性，同一个输入跑十次可能有十种过程。所以 Agent 项目的测试不能只跑一次说“能通”就完事。工程上有效的做法是建一个“黄金评测集”——收集业务中典型、高频、边缘的输入，每次改完代码或提示词就跑一遍评测集，通过率低于阈值就阻止发布。评测指标可以包括：任务成功率、工具调用准确率、最终答案是否合规、单任务耗时与成本是否在预算内。这项工作做起来枯燥，但没有它，Agent 系统的稳定性就是一句空话。

第三笔是可观测性。Agent 是一个多节点、多轮次的系统，比普通 API 服务复杂得多。你必须能在出问题时，快速看清某一轮任务里模型到底看到了什么、调了哪个工具、返回了什么、在哪里绕了圈。我建议从一开始就把链路追踪纳入设计：一个任务一个 trace ID，每一个 LLM 调用、工具调用都带上 span 记录输入摘要、输出摘要、耗时和费用。因为 Agent 的很多故障是“看起来没报错、但结果不对”，没有详细的运行轨迹，你甚至无法复现问题。

这三笔成本，属于“不做到上线你永远感受不到、但感受到了往往已经晚了”的那种。提前把它们纳入预算，能省掉后面大把的返工时间。

把 Agent 从 Demo 推到生产，靠的不是把提示词写得更花哨，而是把上面这七个决策点和三笔隐性成本一项一项填实。架构没有唯一正确答案，但有了这套拆解，你可以少走一些我在上线前走过的那几段弯路——尤其是上下文管理、工具超时和并发控制这三个位置，它们决定了你的 Agent 是“看起来很聪明”，还是“真正能干活”。