1. 从本周趋势榜看智能体的阶段切换
这周的 GitHub Trending 榜单我翻了两遍，最大的感受是：智能体这个赛道正在经历一次明显的阶段切换。前几个月大家还在比谁的 Demo 更惊艳、谁的框架支持的工具更多、谁的多智能体协作演示更花哨，而这周冲上榜单的项目，几乎清一色在解决同一个问题——怎么让智能体在真实业务里稳定跑起来，而不是在演示视频里跑一遍就完事。
这个信号其实挺关键的。智能体从"能跑通"到"能交付"，中间隔着的不是模型能力，而是一整套工程化的东西：状态管理、错误恢复、可观测性、成本控制、权限边界。本周上榜的几个代表性项目，基本都在这几个方向上做文章。有的在做智能体的行为审计和轨迹回放，有的在做多智能体之间的容错协调，有的把重点放在把智能体接入现有业务系统（比如客服、销售、代码审查）的最后一公里上。
我自己的判断是，2026 年智能体领域的主战场已经从"框架之争"转向"落地之争"。框架层面该有的抽象基本都有了，ReAct、Plan-and-Execute、多智能体协作这些模式已经成了标配，真正拉开差距的是谁能把智能体塞进一个真实的、有脏数据、有异常、有并发、有成本约束的生产环境里，还能让它稳定输出。这篇文章我就围绕本周趋势榜反映出的这个转向，把智能体工程化和业务落地的几个核心问题拆开讲，包括架构选型、容错设计、可观测性建设、平台方案与自研方案的取舍，以及我在实际项目里踩过的坑。适合正在做智能体项目、或者准备把智能体往业务里推的开发者参考，刚入门的朋友也能从中看到"玩具"和"产品"之间的差距在哪。
2. 智能体工程化的核心命题拆解
2.1 为什么"能跑通"和"能交付"是两回事
先把这个阶段切换的本质说清楚。一个智能体 Demo 通常长这样：用户输入一个问题，模型思考一下，调用一两个工具，返回一个看起来不错的答案。整个过程是线性的、无状态的、单次的。这种 Demo 在演示时成功率很高，因为演示者会挑那些模型擅长的、工具覆盖的、数据干净的问题。
但真实业务场景完全是另一回事。我拿客服智能体举例。真实客服场景里，用户的问题可能是模糊的、带情绪的、前后矛盾的；工具调用可能超时、可能返回格式错误的数据、可能因为权限问题被拒绝；同一个用户可能在多轮对话里反复改需求；系统可能同时有几百个会话在跑，每个会话都有自己的上下文和状态。这时候你会发现，Demo 里那套"思考-调用-返回"的简单循环根本撑不住。
工程化要解决的就是这些"撑不住"的问题。具体来说，它至少包含这么几层：状态与上下文管理（多轮对话、跨会话记忆、上下文压缩）、错误处理与容错（工具失败重试、降级策略、死循环检测）、可观测性（每一步的输入输出、耗时、token 消耗、决策轨迹都要能追溯）、成本与性能控制（缓存、并发限制、模型分级调用）、安全与权限（工具调用的边界、敏感操作的人工确认）。本周趋势榜上那些项目，基本都能对应到这几层里的某一层或某几层。
2.2 本周趋势榜反映的三个技术方向
把本周上榜项目归类一下，大致能看出三个方向。
第一个方向是智能体的可观测性与行为审计。这类项目解决的是"智能体到底做了什么、为什么这么做"的问题。在业务落地场景里，这一点极其重要——出了问题时，你不能只说"模型就是这么决定的"，你需要一条完整的决策轨迹：它在第几步调用了什么工具、拿到了什么返回、基于什么信息做了下一步判断。有些项目专门做轨迹记录和回放，把智能体的每一步都结构化存储下来，支持事后审计和问题复现。
第二个方向是多智能体系统的容错与协调。单个智能体已经不够用了，很多业务需要多个智能体分工协作，比如一个负责理解需求、一个负责检索、一个负责生成、一个负责校验。多智能体一上来，协调和容错的问题就指数级放大：某个智能体挂了怎么办、两个智能体互相等待怎么办、协作过程中状态不一致怎么办。本周有几个项目专门在做这方面的工程实践，包括超时控制、失败隔离、状态同步。
第三个方向是智能体与现有业务系统的接入。这是最接地气的一层，也是最能体现"业务落地"的。比如把智能体接入客服系统、接入代码审查流程、接入销售 CRM。这类项目的难点不在智能体本身，而在"最后一公里"：怎么处理业务系统的鉴权、怎么把业务数据结构化喂给智能体、怎么把智能体的输出转成业务系统能消费的格式、怎么在业务系统里做灰度发布。
2.3 工程化能力决定智能体的商业价值上限
我想强调一个观点：在模型能力趋于同质化的当下，工程化能力直接决定了智能体的商业价值上限。同一个基座模型，套上不同的工程化外壳，落地效果可能差出好几倍。我见过两个团队做几乎一样的合同审查智能体，用的模型一样、prompt 思路也差不多，但一个能稳定交付、客户愿意付费，另一个天天被投诉"结果不稳定"。差距全在工程化上：前者做了严格的输出格式校验、做了失败重试和降级、做了完整的轨迹记录、做了人工兜底入口；后者就是裸调模型，出了问题连日志都查不到。
所以看本周趋势榜，我特别关注那些"不性感"的项目——没有炫酷的 Demo 视频，没有多智能体协作的动画，就是老老实实做状态管理、做错误处理、做日志追踪。这些项目才是智能体真正走向业务的基石。下面几节我会把这些工程化要点逐个拆开，讲清楚怎么做、为什么这么做、以及实际做的时候容易踩什么坑。
3. 智能体架构选型：平台方案与自研方案的取舍
3.1 平台搭建和代码搭建的本质差异
这是最近被问得最多的问题之一：用扣子、Dify 这类平台搭智能体，和用 Python 自己写，到底有什么不一样？我的回答通常是一句话：平台给你的是"约束下的效率"，代码给你的是"自由下的成本"。
平台方案的本质是把智能体的常见模式（对话、工具调用、知识库检索、工作流编排）封装成可视化配置。你拖拖拽拽就能搭出一个能跑的智能体，开发效率极高，非技术人员也能上手。但代价是你被限制在平台提供的抽象里。平台没提供的功能，你基本做不了；平台提供的功能，你想改底层行为也很难。比如你想自定义一个特殊的上下文压缩策略，或者想在某一步插入一个非常规的校验逻辑，平台往往不给你这个口子。
代码方案则相反。你可以完全控制每一步的行为，可以接入任何工具、任何模型、任何存储，可以实现任意复杂的控制流。但代价是所有东西都要自己写：状态管理、错误处理、日志、并发控制，一个都不能少。一个能上生产的代码智能体，光基础设施代码可能就比业务逻辑多好几倍。
3.2 什么场景该选平台，什么场景该自研
我的经验判断标准是这样的：
| 场景特征 | 推荐方案 | 理由 |
|---|---|---|
| 需求标准、快速验证 | 平台方案 | 几天就能出原型，验证想法成本低 |
| 非技术团队主导 | 平台方案 | 不需要工程能力，运营也能维护 |
| 业务流程固定、变化少 | 平台方案 | 配置一次长期用，维护成本低 |
| 需要深度定制控制流 | 自研方案 | 平台抽象不够用，必须自己控制 |
| 高并发、有性能要求 | 自研方案 | 平台方案的性能和并发往往受限 |
| 需要接入内部系统 | 自研方案 | 鉴权、数据格式、网络环境都要自己处理 |
| 对成本和延迟敏感 | 自研方案 | 可以精细控制模型调用和缓存策略 |
实际项目里，我见过最务实的做法是混合：用平台快速搭出原型验证业务价值，验证通过后，把核心链路用代码重写，平台只保留一些边缘的、变化频繁的配置型智能体。这样既拿到了验证速度，又保住了核心链路的可控性。
3.3 自研智能体的最小可用架构
如果你决定自研，我建议从一个最小可用架构起步，不要一上来就搞多智能体、搞复杂编排。这个最小架构包含四个部分：
第一是 Agent Loop，也就是智能体的主循环。最经典的是 ReAct 模式：思考（Reason）→ 行动（Act）→ 观察（Observe）→ 再思考，直到得出最终答案或达到最大步数。这个循环看起来简单，但工程上要处理的东西不少：最大步数限制（防止死循环）、每步的超时控制、工具调用的异常捕获。
第二是工具层。每个工具是一个独立的函数，有明确的输入输出 schema。工具层要做的事情包括：参数校验（模型生成的参数经常不合规）、超时控制、失败重试、结果格式化。我强烈建议每个工具都做幂等设计，因为重试是常态。
第三是状态管理。智能体的状态包括对话历史、工具调用记录、中间结果、当前步数等。这些状态要能序列化、能持久化、能恢复。为什么强调持久化？因为生产环境里智能体可能跑很久，进程可能重启，你需要能从上次的状态继续。
第四是可观测层。每一步的输入、输出、耗时、token 消耗、决策理由都要记录下来。这一层在 Demo 阶段可以省，但在生产阶段绝对不能省。
# 一个极简的 Agent Loop 骨架，展示核心控制流 class AgentLoop: def __init__(self, llm, tools, max_steps=10, step_timeout=30): self.llm = llm self.tools = tools self.max_steps = max_steps self.step_timeout = step_timeout def run(self, user_input, state=None): state = state or {"history": [], "steps": 0} state["history"].append({"role": "user", "content": user_input}) while state["steps"] < self.max_steps: # 1. 让模型决定下一步 decision = self.llm.decide(state["history"], self.tools.schemas()) self._trace("decision", decision) # 2. 如果是最终答案，返回 if decision["type"] == "final": return decision["content"] # 3. 否则执行工具，带超时和异常处理 try: result = self.tools.call( decision["tool"], decision["args"], timeout=self.step_timeout ) except ToolError as e: result = {"error": str(e), "retryable": e.retryable} self._trace("tool_result", result) state["history"].append({"role": "tool", "content": result}) state["steps"] += 1 return "达到最大步数限制，未能完成任务"这段代码省略了很多细节，但核心控制流就是这样。注意里面的_trace调用和异常处理，这两块是 Demo 和产品之间的分水岭。
4. 容错设计：让智能体在异常中活下来
4.1 智能体失败的几种典型模式
智能体在生产环境里的失败方式，比传统软件要"丰富"得多。我总结了几种最常见的：
工具调用失败。这是最高频的。工具超时、返回格式错误、返回空结果、因为权限被拒绝，都算。模型拿到一个错误的结果，如果 prompt 没设计好，它可能会基于错误信息继续瞎编，把错误放大。
死循环。模型在两个工具之间反复横跳，或者反复调用同一个工具但参数几乎不变。这在 ReAct 模式里特别常见，因为模型可能陷入"我觉得还不对，再查一次"的循环。
上下文溢出。多轮对话加上工具返回结果，上下文很快就能撑爆模型的窗口。如果不做压缩，要么报错，要么被迫截断导致信息丢失。
幻觉性工具调用。模型调用了一个根本不存在的工具，或者给工具传了 schema 里没有的参数。这在工具数量多、schema 复杂的时候特别容易发生。
级联失败。多智能体场景里，一个智能体失败导致依赖它的智能体全部失败，最后整个任务崩掉。
4.2 分层容错策略的设计
针对这些失败模式，我建议用分层容错，从内到外分四层：
第一层是工具级容错。每个工具自己处理可预期的异常，做重试、做降级。比如检索工具超时了，重试两次，还不行就返回一个"检索暂时不可用"的明确信号，而不是抛异常。工具级容错的关键是给模型一个可理解的错误信号，让模型知道"这条路走不通，换一条"，而不是让它拿到一个模糊的异常然后瞎猜。
第二层是循环级容错。在 Agent Loop 里做死循环检测。最简单的做法是记录最近 N 步的工具调用签名（工具名+参数哈希），如果发现重复，就强制中断或者注入一个提示让模型换策略。更精细的做法是检测"状态是否在推进"——如果连续几步的中间结果没有实质变化，就判定为卡住。
第三层是任务级容错。整个任务失败后，要有重试机制。但重试不能简单重跑，因为智能体的执行可能有副作用（比如已经发了邮件、已经改了数据库）。所以任务级重试要配合幂等设计和检查点机制：把任务拆成若干阶段，每个阶段完成后存检查点，重试时从最后一个检查点继续。
第四层是系统级容错。多智能体场景下，要有失败隔离和降级。一个智能体挂了，不能拖垮整个系统。做法包括：给每个智能体独立的超时和资源配额、用消息队列解耦、设计降级路径（比如校验智能体挂了，就跳过校验直接输出，但标记为"未校验"）。
4.3 一个可复用的重试与降级实现
下面这个重试装饰器是我在多个项目里复用过的，核心思路是区分"可重试错误"和"不可重试错误"，并对可重试错误做指数退避。
import time import functools class RetryableError(Exception): """标记为可重试的错误""" pass class FatalError(Exception): """不可重试的错误，直接向上抛""" pass def with_retry(max_attempts=3, base_delay=1.0, backoff=2.0): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): last_error = None for attempt in range(max_attempts): try: return func(*args, **kwargs) except FatalError: raise # 不可重试，直接抛 except RetryableError as e: last_error = e if attempt < max_attempts - 1: delay = base_delay * (backoff ** attempt) time.sleep(delay) except Exception as e: # 未分类的异常，保守起见当作可重试 last_error = e if attempt < max_attempts - 1: time.sleep(base_delay * (backoff ** attempt)) raise last_error return wrapper return decorator用的时候，工具内部把网络超时、限流这类错误抛成RetryableError，把参数错误、权限错误抛成FatalError。这样重试逻辑就清晰了：该重试的重试，不该重试的快速失败。
注意：重试一定要配合幂等。如果一个工具有副作用（比如写数据、发消息），重试前必须确认这个操作是幂等的，否则会重复执行。我踩过这个坑——一个"创建工单"的工具因为超时被重试，结果创建了两个工单。
4.4 死循环检测的实操技巧
死循环检测这块，我分享一个实际用下来比较有效的做法。不要只看工具调用是否重复，还要看模型的思考内容是否在原地打转。具体做法是：把最近几步的模型思考文本做 embedding，计算相似度，如果连续几步相似度超过阈值，就判定为卡住。
另一个技巧是给模型一个"退出信号"。在 prompt 里明确告诉模型："如果你已经尝试了 3 种不同的方法都无法解决，请直接返回'无法完成'并说明原因，不要继续尝试。" 这个简单的提示能显著降低死循环率，因为模型很多时候是"不甘心"，你不给它台阶下，它就一直试。
5. 可观测性建设：让智能体的每一步都可追溯
5.1 为什么智能体比传统系统更需要可观测性
传统软件出问题，你可以打断点、看堆栈、复现。智能体出问题，你面对的是一个概率性的、非确定性的系统，同样的输入两次可能得到不同输出。这时候如果没有完整的轨迹记录，你根本无从下手。
我遇到过最头疼的一次，是一个销售智能体在某个客户那里给出了错误的报价。查了两天才发现，是因为检索工具返回了一条过期的价格数据，模型基于这条数据做了计算。如果没有轨迹记录，我永远不知道它是从哪拿到这个价格的。有了轨迹，我一眼就看到第 3 步检索返回的内容有问题，问题定位从两天缩短到两分钟。
所以我的观点很明确：智能体项目从第一天起就要建可观测性，不要等到出问题才补。补的成本远高于一开始就建。
5.2 需要记录哪些关键信息
一条完整的智能体轨迹，至少要包含这些字段：
| 字段 | 说明 | 用途 |
|---|---|---|
| trace_id | 整个任务的唯一标识 | 串联所有步骤 |
| step_index | 当前是第几步 | 定位问题步骤 |
| timestamp | 时间戳 | 分析耗时和时序 |
| input | 这一步的输入 | 复现问题 |
| decision | 模型的决策（思考+行动） | 理解模型意图 |
| tool_name | 调用的工具名 | 统计工具使用 |
| tool_args | 工具参数 | 复现调用 |
| tool_result | 工具返回 | 检查数据质量 |
| error | 错误信息（如有） | 排查失败 |
| tokens | 消耗的 token 数 | 成本分析 |
| latency | 耗时 | 性能分析 |
这些字段结构化存储后，你能做的事情就多了：按 trace_id 回放整个任务、统计每个工具的成功率和平均耗时、分析 token 消耗的分布、找出最常失败的工具、对比不同 prompt 版本的效果。
5.3 轨迹回放与问题复现
光记录还不够，还要能回放。回放的价值在于：当用户投诉"这个智能体昨天给我的答案不对"时，你能把当时的完整轨迹调出来，一步步看它做了什么。
实现回放的关键是记录足够的信息以支持确定性重放。这里有个坑：如果你记录的是模型的原始输出，回放时直接重放这些输出，那回放是确定性的；但如果你想在回放时重新调用模型，那就不是确定性的了。我的建议是两者都支持：默认重放记录的输出（用于问题复现），需要时可以选择重新调用模型（用于测试新 prompt）。
# 轨迹记录的核心结构 class Trace: def __init__(self, trace_id): self.trace_id = trace_id self.steps = [] def record(self, step_index, input_data, decision, tool_call=None, result=None, error=None): self.steps.append({ "step_index": step_index, "timestamp": time.time(), "input": input_data, "decision": decision, "tool_call": tool_call, "result": result, "error": error, "tokens": decision.get("tokens"), "latency": decision.get("latency"), }) def replay(self, from_step=0): """回放轨迹，用于问题复现""" for step in self.steps[from_step:]: print(f"[Step {step['step_index']}]") print(f" Decision: {step['decision']}") if step['tool_call']: print(f" Tool: {step['tool_call']['name']}({step['tool_call']['args']})") if step['error']: print(f" ERROR: {step['error']}")5.4 行为审计在业务场景中的价值
行为审计这个词听起来有点重，但在业务场景里它其实是刚需。特别是金融、医疗、法律这些强监管行业，智能体的每一个决策都要能解释、能追溯、能审计。
我参与过一个金融问答智能体的项目，监管要求是：智能体给出的每一个涉及数字的答案，都必须能追溯到数据来源。这就要求轨迹记录不仅要记"模型说了什么"，还要记"模型是基于哪条数据说的"。实现方式是在工具返回结果时给每条数据打上来源标记，模型生成答案时要求它引用来源标记，最后审计时就能把答案和数据源对应起来。
即使不在强监管行业，行为审计也有实际价值。比如你想优化智能体的表现，你需要知道它在哪些环节容易出错；你想控制成本，你需要知道 token 都花在哪了；你想评估新模型，你需要有历史轨迹做对比基准。这些都是审计数据的用武之地。
6. 业务落地的最后一公里
6.1 智能体接入现有系统的典型障碍
智能体本身跑通了，不代表业务能落地。最后一公里往往是最难走的。我总结了几类典型障碍：
鉴权与权限。业务系统有自己的用户体系和权限模型，智能体调用业务系统时，用谁的身份？如果用一个超级账号，权限过大有安全风险；如果用用户身份，怎么把用户身份透传给智能体？这块通常需要专门设计一套服务账号+用户上下文透传的机制。
数据格式。业务系统的数据格式往往是为人类设计的，不是为模型设计的。比如一个订单系统返回的 JSON 嵌套很深、字段名是缩写、还有一堆模型不需要的元数据。直接喂给模型既浪费 token 又容易让模型困惑。通常需要写一层适配，把业务数据转成模型友好的格式。
同步与异步。很多业务操作是异步的（比如提交工单后要等审批），但智能体的交互是同步的（用户等着回复）。这中间的等待怎么处理？常见做法是智能体先返回"已提交，正在处理"，然后通过回调或轮询更新状态。
灰度与回滚。智能体上线不能一刀切，要能灰度。比如先对 5% 的流量启用，观察效果，再逐步放量。同时要能一键回滚到人工或旧版本。这要求智能体的接入层支持流量切换。
6.2 客服场景的接入实践
客服是智能体落地最成熟的场景之一，我拿它举例讲讲接入实践。把智能体接入客服系统（比如接入千牛这类电商客服客户端），核心要解决几个问题：
会话路由。用户消息进来后，先判断是转人工还是给智能体。判断逻辑可以是规则（关键词命中转人工）、可以是模型（意图分类）、也可以是混合。我的经验是初期用规则+模型混合，规则兜底，模型处理模糊情况。
上下文同步。客服场景里，用户可能先跟智能体聊，然后转人工，人工客服需要看到之前的对话。所以智能体的对话历史要能同步到客服系统。反过来，人工客服处理完转回智能体，智能体也要知道人工说了什么。
知识库对接。客服智能体的回答要基于企业知识库，不能瞎编。这要求智能体的检索工具对接企业现有的知识库系统，并且要处理知识库更新后的同步问题。
人工兜底。智能体搞不定的，要能顺畅转人工。转人工的触发条件包括：用户明确要求、智能体连续 N 次没解决、检测到用户情绪激动、涉及敏感操作（退款、投诉）。
质量监控。上线后要持续监控智能体的表现：解决率、转人工率、用户满意度、平均对话轮数。这些指标要能按天、按场景、按智能体版本维度看。
6.3 代码审查场景的落地要点
代码审查是另一个本周趋势榜上出现的方向。智能体做代码审查，落地要点和客服很不一样：
召回率优先于精确率。代码审查智能体的目标是"尽量别漏掉问题"，宁可多报一些误报，也不能漏掉真问题。因为漏掉一个严重 bug 的代价，远高于让开发者多看几条误报。所以 prompt 和阈值的设计要偏向召回。
与 CI/CD 集成。代码审查智能体不能是独立的工具，要集成到开发者的工作流里。通常是作为 CI 的一个环节，在 PR 提交时自动触发，把审查结果作为评论贴到 PR 上。
分级输出。审查结果要分级：严重问题（必须改）、建议改进（可选）、风格问题（仅供参考）。分级能让开发者快速抓住重点，而不是被一堆琐碎建议淹没。
误报反馈闭环。开发者标记为误报的，要能反馈回系统，用于优化 prompt 或微调模型。这个闭环是持续提升审查质量的关键。
6.4 从试点到规模化的推进节奏
最后讲讲推进节奏。我见过太多项目死在"一上来就想做大而全"。正确的节奏应该是：
第一阶段：单点试点。选一个边界清晰、价值明确的场景，做深做透。比如就做"退款咨询"这一个意图，把它做到 90% 以上的解决率。这个阶段的目标是验证技术可行性和业务价值。
第二阶段：横向扩展。试点跑通后，把能力扩展到相邻场景。比如从退款咨询扩展到退换货咨询、物流咨询。这个阶段要开始建可复用的基础设施：统一的工具层、统一的轨迹记录、统一的评估体系。
第三阶段：规模化与优化。场景铺开后，重点转向优化：降成本、提效果、扩容量。这个阶段要建精细化的监控和 A/B 测试能力，用数据驱动优化。
每个阶段之间要有明确的验收标准，达不到就不进入下一阶段。这样能避免"摊子铺太大、每个都做不好"的常见问题。
7. 常见问题与排查技巧实录
7.1 智能体输出不稳定的排查思路
输出不稳定是最高频的投诉。排查思路我通常按这个顺序走：
先看是不是模型温度的问题。如果 temperature 设得高，输出自然不稳定。业务场景通常建议 temperature 设低（0.1-0.3），除非是需要创意的场景。
再看是不是上下文污染。多轮对话里，早期的错误信息可能一直留在上下文里影响后续判断。检查方法是看轨迹，看模型每一步是基于什么上下文做决策的。
然后看工具返回是否稳定。如果工具返回的数据本身就不稳定（比如检索结果每次不一样），那输出不稳定是必然的。这时候要优化检索的确定性。
最后看 prompt 是否有歧义。有些 prompt 写得模棱两可，模型每次理解都不一样。这种情况要把 prompt 写得更明确，给出具体的输出格式和判断标准。
7.2 工具调用失败的速查表
| 现象 | 可能原因 | 排查方法 | 解决方向 |
|---|---|---|---|
| 工具从不被调用 | schema 描述不清 | 看模型思考内容 | 优化工具描述 |
| 工具参数错误 | schema 太复杂 | 看错误日志 | 简化参数结构 |
| 工具超时 | 下游慢 | 看耗时分布 | 加超时+重试 |
| 工具返回空 | 查询条件问题 | 看实际查询 | 优化参数生成 |
| 调用不存在的工具 | 工具太多 | 看幻觉调用 | 减少工具数或分组 |
| 反复调用同一工具 | 结果不满足 | 看循环模式 | 加死循环检测 |
7.3 成本失控的常见原因
智能体的成本失控，通常不是单一原因，而是几个因素叠加：
上下文太长。每轮都把完整历史喂给模型，token 消耗随轮数线性增长。解决方法是做上下文压缩，只保留关键信息。
工具返回太啰嗦。工具返回一大堆模型不需要的数据，白白消耗 token。解决方法是在工具层做裁剪，只返回模型需要的信息。
模型选型过重。所有步骤都用最贵的模型。解决方法是分级调用：简单判断用小模型，复杂推理用大模型。
没有缓存。相同的查询反复调用。解决方法是加缓存，特别是检索类工具。
重试过多。失败重试消耗额外 token。解决方法是在重试前先判断是否值得重试。
7.4 几个我踩过的坑
坑一：以为 prompt 能解决一切。早期我总想通过优化 prompt 来解决所有问题，后来发现很多问题是工程问题，prompt 解决不了。比如工具超时，你 prompt 写得再好，工具该超时还是超时。
坑二：忽视并发下的状态隔离。单会话测试没问题，一上并发就出乱子。原因是状态没做好隔离，多个会话共享了同一个状态对象。这个坑很隐蔽，因为单测发现不了。
坑三：日志记了但没人看。建了可观测性，但没建告警和定期review机制，日志堆在那里没人看，等于没建。后来我加了关键指标的告警，以及每周的轨迹抽样review，才真正发挥价值。
坑四：低估了数据质量的影响。智能体效果不好，很多时候不是模型问题，是喂给它的数据质量差。花时间清洗和结构化数据，收益往往比换模型大。
坑五：没有人工兜底。上线初期没做人工兜底，智能体答错了用户直接流失。后来加了"转人工"入口，用户体验立刻好转。人工兜底不是失败，是负责任的设计。
8. 我对智能体工程化落地的一点个人体会
做智能体项目这两年多，我最大的体会是：这个领域的难点正在从"AI 能力"转移到"软件工程"。模型能力每年都在涨，很多以前需要精心设计 prompt 才能做到的事情，现在模型自己就能做好。但工程上的问题——状态管理、容错、可观测性、成本控制——这些不会因为模型变强而消失，反而因为智能体承担的任务越来越重而变得更加关键。
我见过太多团队把 90% 的精力花在调 prompt 和选模型上，只留 10% 给工程化，结果做出来的东西始终停留在 Demo 水平。反过来，那些工程化做得扎实的团队，即使模型不是最新的，也能做出稳定可用的产品。这个规律在本周的趋势榜上体现得特别明显——上榜的项目大多不是模型层面的创新，而是工程层面的打磨。
如果你正在做智能体项目，我的建议是：把工程化的投入前置，不要等到出问题才补。从第一天起就建轨迹记录，从第一个工具起就做容错设计，从第一个场景起就考虑人工兜底。这些投入在早期看起来"没必要"，但在项目真正要交付的时候，它们就是你能不能按时上线的决定性因素。
最后分享一个我最近在用的评估方法：每周从生产轨迹里随机抽 50 条，人工标注智能体的表现，算出准确率、解决率、平均轮数这几个核心指标，画成趋势图。这个简单的机制能让你对智能体的真实表现有持续的感知，而不是等到用户投诉才知道出了问题。坚持做了几个月，我发现它比任何复杂的自动化评估都更能反映真实情况。
