1. 从能跑通到能交付智能体这半年到底变了什么如果你最近半年一直在跟智能体打交道应该能明显感觉到一个变化去年大家聊的还是我用某某框架搭了一个能自动查天气、能写周报的助手今年聊的已经变成我们那条业务线的智能体上线之后人工介入率降了多少。这个转变不是某一篇论文或者某一个模型带来的而是整个生态在工程化这件事上集体往前挪了一大步。我自己的体感是智能体真正开始像回事是从大家不再把它当成一个聊天框的延伸而是当成一个有输入、有状态、有工具、有输出契约的软件系统开始的。以前我们评价一个智能体好不好看的是它回答得聪不聪明现在我们评价一个智能体能不能用看的是它在异常输入下会不会崩、工具调用失败会不会重试、多轮之后上下文会不会污染、跑一百次的结果方差有多大。这些指标听起来很工程但恰恰是它们决定了一个智能体能不能从演示视频走进真实业务。这篇周报式的总结我想围绕 GitHub Trending 上这段时间反复出现的那批智能体项目聊聊它们共同指向的几个方向工程化、业务落地、多智能体协作、以及评估与可观测性。不管你是刚准备搭第一个智能体的新手还是已经在做平台架构的老手应该都能从这些项目的演进路径里找到对自己有用的东西。我会尽量把为什么这么设计讲清楚而不是只列一堆仓库名让你自己去翻。2. 工程化不是加个日志那么简单智能体项目正在补齐的四块短板2.1 状态管理从塞进 prompt到独立的状态层早期搭智能体最省事的做法就是把所有历史对话一股脑塞进 prompt反正上下文窗口够大。但真到了业务场景你会发现这条路走不通上下文越长模型越容易忘掉关键约束多轮工具调用之后中间结果和用户意图混在一起模型开始胡编更麻烦的是你根本没法复现某一次失败——因为状态是隐式的藏在那一长串文本里。GitHub 上这段时间热度很高的几个智能体框架几乎都在做同一件事把状态从 prompt 里抽出来变成一个显式的、可序列化的对象。这个状态对象通常包含几类东西——对话历史、当前任务的目标、已经调用过的工具及其返回值、以及一个待办清单式的计划。这么做的直接好处是你可以在任意一步把状态 dump 出来存进数据库出问题的时候直接回放。我实测下来光是能回放这一条就能把排查一个诡异 bug 的时间从半天压缩到十几分钟。提示如果你现在还在用纯 prompt 管理状态建议至少先把工具调用记录单独存一份。这一步改动很小但收益极大。2.2 工具调用的容错失败重试、超时、幂等工具调用是智能体和外部世界交互的接口也是最容易出问题的地方。网络抖动、接口限流、参数格式不对、返回结构变了——任何一种都能让整个流程卡死。我见过太多 demo 里的智能体工具一失败就直接把错误信息原样吐给用户体验非常糟糕。工程化做得好的项目会在工具层做几件事。第一是超时控制每个工具调用都有明确的超时时间超了就当作失败处理而不是无限等待。第二是重试策略对于幂等的读操作可以自动重试对于写操作则要谨慎通常需要配合幂等键。第三是错误归一化把各种五花八门的底层错误转换成智能体能理解的统一格式让它有机会自己决定是重试、换工具还是向用户求助。这里有个容易被忽略的点重试次数不是越多越好。我踩过的坑是某个查询接口在限流时返回的是 200 但内容为空智能体以为是查到了空结果于是基于空结果继续往下推理最后给出一个完全错误的结论。后来我们在工具层加了一层校验空结果和真正的无数据要区分开问题才解决。2.3 可观测性没有 trace 的智能体等于黑盒传统后端服务有日志、有链路追踪出问题能顺着 trace 一路查下去。智能体如果只有最终输出那排查起来就是纯靠猜。现在主流的做法是给智能体也加上 span 级别的追踪一次用户请求是一个 trace里面包含若干 span每个 span 对应一次模型调用或一次工具调用记录输入、输出、耗时、token 消耗。这套东西的价值在业务落地阶段会成倍放大。比如你发现某个智能体最近响应变慢了通过 trace 一看是某个工具的平均耗时从 200ms 涨到了 2s又比如你发现成本超预算了一看是某个环节的 prompt 被撑得特别大。没有这些数据你只能拍脑袋优化。2.4 评估从我觉得还行到跑分说话评估是智能体工程化里最容易被跳过、但最重要的一环。很多人搭完智能体自己试几个 case 觉得没问题就上线了结果真实用户一用各种边界情况全冒出来。工程化的做法是建立一套离线评估集把典型任务、边界任务、对抗性输入都整理成测试用例每次改动之后自动跑一遍看通过率、看回归。评估集的构建本身也有讲究。我建议至少分三层基础能力层工具能不能正确调用、任务完成层端到端能不能把事办成、鲁棒性层遇到异常输入会不会崩。这三层的通过率要分开看因为它们的优化手段完全不同。基础能力不行多半是工具描述或参数 schema 的问题任务完成不行往往是规划逻辑的问题鲁棒性不行则要在 prompt 和状态管理上找原因。3. 业务落地阶段智能体架构里那些反直觉的设计选择3.1 为什么很多生产级智能体反而不智能这是个很有意思的现象。你看那些真正在业务里跑起来的智能体往往没有 demo 里那么自由。它们的工作流被约束得很死先做什么、再做什么、什么情况下必须转人工全都是写死的。这不是倒退而是工程上的必然。原因很简单业务要的是稳定和可预期。一个能自由发挥、偶尔给你惊喜的智能体在演示时很酷但在生产环境里就是风险。用户问我的订单到哪了你希望它每次都走同一条查询路径而不是这次查订单表、下次查物流接口、再下次自己编一个答案。所以生产级智能体普遍采用有限自主的设计在明确的边界内让模型做决策边界之外全部走确定性流程。具体到实现上常见做法是把整个任务拆成若干阶段每个阶段有明确的输入输出契约模型只负责阶段内的决策阶段之间的流转由代码控制。这样既保留了模型处理非结构化输入的灵活性又保证了整体流程的可控性。3.2 多智能体不是越多越好关键在职责边界多智能体是这两年的热词但我在实际项目里看到的情况是很多人把多智能体用错了地方。他们把一个本来单智能体就能搞定的任务硬拆成五六个角色互相对话结果 token 消耗翻了好几倍效果反而更差——因为智能体之间的沟通成本被低估了。多智能体真正有价值的场景是职责边界天然清晰、且需要不同能力或不同权限的时候。比如一个销售智能体系统线索筛选、需求分析、方案生成、报价计算这几个环节需要的知识库不同、工具权限不同拆成独立智能体就合理。但如果只是一个负责思考、一个负责执行这种模糊分工那还不如单智能体加个工具调用。判断要不要上多智能体我一般会问三个问题各角色的工具集是否真的不重叠各角色的知识库是否真的需要隔离合并成一个智能体之后prompt 是否会大到影响效果三个问题里有两个答案是是才考虑拆分。3.3 知识库与 RAG检索质量决定智能体上限业务智能体几乎都绕不开知识库。不管是制度条例学习助手、还是销售话术助手背后都要靠检索来提供事实依据。这里我想强调一个经常被忽视的点检索质量决定了智能体的能力上限模型再强也救不了检索出来的垃圾。我见过不少项目花大量时间调 prompt却对切分策略、embedding 模型、召回数量这些检索环节的参数随手一设。结果就是智能体经常答非所问然后大家以为是模型不行。实际上把文档切分从固定长度改成按语义切分、把召回数量从 3 调到 8 再加重排效果往往立竿见影。注意RAG 不是检索到就万事大吉检索结果和用户问题的相关性、以及检索结果之间的冗余度都需要在评估环节专门测。3.4 人机协同转人工的时机设计业务落地绕不开的一个问题是什么时候该让智能体自己处理什么时候该转人工。这个边界设计得好不好直接决定了用户体验和运营成本。我的经验是转人工的触发条件要分几类。置信度类模型对自己的回答明显不确定时转人工。敏感类涉及金额、权限、合规的操作必须人工确认。情绪类用户明显不满或反复追问时转人工能避免矛盾升级。能力类超出智能体知识范围的问题与其硬答不如转人工。这几类条件要在系统里显式配置而不是指望模型自己判断。因为模型在该不该转人工这件事上的判断往往不如一套明确的规则可靠。4. 从 Trending 项目里能抄到的具体作业4.1 智能体框架选型别只看 star 数GitHub Trending 上的智能体框架很多选型的时候容易被 star 数带偏。我的建议是选框架要看四个维度抽象层次是给你一堆原语自己拼还是给你现成的工作流、可观测性支持有没有内置 trace、工具生态常用工具是否现成、社区活跃度issue 响应速度。抽象层次低的框架灵活但上手慢适合有明确定制需求的团队抽象层次高的框架开箱即用但遇到框架没覆盖的场景会比较难受。我一般建议新手从抽象层次高的框架入手先把一个完整流程跑通理解智能体的基本构成再逐步往底层走。4.2 一个最小可用的智能体工程骨架如果你要自己搭一套我建议至少包含这几个模块模块职责关键点状态层管理对话、任务、工具记录可序列化、可回放工具层封装外部能力超时、重试、错误归一化规划层决定下一步做什么有限自主边界清晰执行层调用模型和工具统一 trace评估层离线跑分分层评估集这个骨架不复杂但每一块都别省。我见过太多项目为了赶进度跳过评估层结果上线之后每次改动都是盲改越改越乱。4.3 工具描述怎么写模型才用得对工具调用出问题十有八九是工具描述没写好。模型判断该不该调这个工具、该传什么参数全靠你给的描述。描述写得太简略模型不知道什么时候用写得太啰嗦又浪费 token 还容易干扰。我的写法是一句话说清楚这个工具做什么然后列出每个参数的含义、类型、是否必填、以及取值范围最后给一两个调用示例。特别是参数取值范围一定要写清楚否则模型很容易传一个格式对但语义错的参数进来。比如日期参数你要明确告诉它是YYYY-MM-DD还是时间戳是本地时间还是 UTC。4.4 评估集怎么攒从真实日志里挖评估集不用一开始就追求大而全。最实用的做法是上线一个最小版本把真实用户的请求日志收集起来人工标注一批期望输出然后把这些整理成测试用例。这样攒出来的评估集天然贴近真实分布比你自己拍脑袋想的 case 有用得多。我一般会维护一个回归集专门放那些曾经出过问题、修好之后不能再犯的 case。每次改动之后先跑回归集通过了再跑全量。这样能保证不会修一个坏一个。5. 那些只有踩过才知道的坑5.1 上下文污染多轮之后模型开始记错多轮对话里模型很容易把前面轮次的信息和当前轮次混淆。比如用户先问了一个关于 A 产品的问题又问了 B 产品模型在回答 B 的时候可能把 A 的信息带进来。这个问题在长对话里尤其明显。我的应对办法是在状态层做话题切分当检测到用户意图发生明显变化时把之前的历史做一次摘要压缩只保留关键结论而不是原样保留所有对话。这样既控制了上下文长度又减少了污染。5.2 工具返回结果太长把上下文撑爆有些工具返回的数据特别大比如一次查询返回几百条记录。如果原样塞进上下文不仅浪费 token还会稀释真正重要的信息。做法是在工具层做结果裁剪只返回和当前任务相关的字段或者先做一次摘要再返回。5.3 模型假装调用了工具这是个很隐蔽的坑。有时候模型会在输出里写我已经查询了订单系统结果是……但实际上它根本没调用工具结果是编的。这种情况在工具调用失败但模型没意识到的时候特别容易发生。解决办法是在执行层做校验如果模型声称调用了某个工具但 trace 里没有对应的调用记录就要拦截并重新引导。更根本的办法是让模型的输出格式强制包含工具调用结果而不是让它用自然语言描述。5.4 成本失控token 消耗比预期高一个数量级智能体的 token 消耗往往比单纯对话高得多因为每一轮都要带上完整的状态和工具描述。如果不加控制成本很容易失控。我一般会做几件事精简工具描述、压缩历史上下文、对简单任务走轻量模型、设置单次请求的 token 上限。提示上线前一定要做一次成本估算按最坏情况算别按平均值算。因为智能体的 token 消耗方差很大。6. 智能体面试里那些真正区分水平的问题最近智能体相关的岗位多了起来面试题也从什么是 ReAct这种概念题转向了更工程化的场景题。我整理了几个我觉得特别能区分候选人水平的问题也顺便说说我期待的答案方向。第一个问题是你的智能体工具调用失败了怎么办。初级回答是重试中级会提到超时和幂等高级会区分读操作和写操作、会提到错误归一化和让模型参与决策。这个问题能直接看出候选人有没有真正在生产环境跑过。第二个问题是你怎么评估一个智能体的好坏。如果只回答看回答质量那基本没做过正经项目。好的回答会提到分层评估集、通过率、回归测试、以及线上指标和离线指标的结合。第三个问题是多轮对话里上下文怎么管理。这个问题考的是对状态层的理解。能说出摘要压缩话题切分关键信息提取这些手段的说明踩过坑。第四个问题是怎么控制成本。这个问题很实际能答出精简 prompt、分级用模型、设置上限的说明有成本意识。7. 接下来值得盯的几个方向智能体这个领域变化很快但有几个方向我觉得会持续热下去。一个是评估的标准化现在各家评估方法五花八门未来应该会出现更统一的评估框架和基准。一个是智能体之间的协作协议多智能体要真正规模化通信和协商的规范得先定下来。还有一个是智能体与现有业务系统的深度集成现在很多智能体还是外挂式的未来应该会更深入地嵌进业务流程里。我个人的做法是保持对 Trending 的关注但不过度追新。每看到一个有意思的项目先问自己它解决的是我当前遇到的问题吗如果是就花时间研究如果不是就记个笔记等真遇到了再回头看。这样既能跟上节奏又不会被信息淹没。最后分享一个我自己的习惯每搭一个新智能体我都会先写一份失败清单——列出我能想到的所有可能出错的地方然后在开发过程中逐条验证。这份清单后来往往就成了评估集的雏形。这个习惯帮我省了很多上线后的救火时间推荐你也试试。
智能体工程化实战：从状态管理到评估，生产级架构的避坑指南
1. 从能跑通到能交付智能体这半年到底变了什么如果你最近半年一直在跟智能体打交道应该能明显感觉到一个变化去年大家聊的还是我用某某框架搭了一个能自动查天气、能写周报的助手今年聊的已经变成我们那条业务线的智能体上线之后人工介入率降了多少。这个转变不是某一篇论文或者某一个模型带来的而是整个生态在工程化这件事上集体往前挪了一大步。我自己的体感是智能体真正开始像回事是从大家不再把它当成一个聊天框的延伸而是当成一个有输入、有状态、有工具、有输出契约的软件系统开始的。以前我们评价一个智能体好不好看的是它回答得聪不聪明现在我们评价一个智能体能不能用看的是它在异常输入下会不会崩、工具调用失败会不会重试、多轮之后上下文会不会污染、跑一百次的结果方差有多大。这些指标听起来很工程但恰恰是它们决定了一个智能体能不能从演示视频走进真实业务。这篇周报式的总结我想围绕 GitHub Trending 上这段时间反复出现的那批智能体项目聊聊它们共同指向的几个方向工程化、业务落地、多智能体协作、以及评估与可观测性。不管你是刚准备搭第一个智能体的新手还是已经在做平台架构的老手应该都能从这些项目的演进路径里找到对自己有用的东西。我会尽量把为什么这么设计讲清楚而不是只列一堆仓库名让你自己去翻。2. 工程化不是加个日志那么简单智能体项目正在补齐的四块短板2.1 状态管理从塞进 prompt到独立的状态层早期搭智能体最省事的做法就是把所有历史对话一股脑塞进 prompt反正上下文窗口够大。但真到了业务场景你会发现这条路走不通上下文越长模型越容易忘掉关键约束多轮工具调用之后中间结果和用户意图混在一起模型开始胡编更麻烦的是你根本没法复现某一次失败——因为状态是隐式的藏在那一长串文本里。GitHub 上这段时间热度很高的几个智能体框架几乎都在做同一件事把状态从 prompt 里抽出来变成一个显式的、可序列化的对象。这个状态对象通常包含几类东西——对话历史、当前任务的目标、已经调用过的工具及其返回值、以及一个待办清单式的计划。这么做的直接好处是你可以在任意一步把状态 dump 出来存进数据库出问题的时候直接回放。我实测下来光是能回放这一条就能把排查一个诡异 bug 的时间从半天压缩到十几分钟。提示如果你现在还在用纯 prompt 管理状态建议至少先把工具调用记录单独存一份。这一步改动很小但收益极大。2.2 工具调用的容错失败重试、超时、幂等工具调用是智能体和外部世界交互的接口也是最容易出问题的地方。网络抖动、接口限流、参数格式不对、返回结构变了——任何一种都能让整个流程卡死。我见过太多 demo 里的智能体工具一失败就直接把错误信息原样吐给用户体验非常糟糕。工程化做得好的项目会在工具层做几件事。第一是超时控制每个工具调用都有明确的超时时间超了就当作失败处理而不是无限等待。第二是重试策略对于幂等的读操作可以自动重试对于写操作则要谨慎通常需要配合幂等键。第三是错误归一化把各种五花八门的底层错误转换成智能体能理解的统一格式让它有机会自己决定是重试、换工具还是向用户求助。这里有个容易被忽略的点重试次数不是越多越好。我踩过的坑是某个查询接口在限流时返回的是 200 但内容为空智能体以为是查到了空结果于是基于空结果继续往下推理最后给出一个完全错误的结论。后来我们在工具层加了一层校验空结果和真正的无数据要区分开问题才解决。2.3 可观测性没有 trace 的智能体等于黑盒传统后端服务有日志、有链路追踪出问题能顺着 trace 一路查下去。智能体如果只有最终输出那排查起来就是纯靠猜。现在主流的做法是给智能体也加上 span 级别的追踪一次用户请求是一个 trace里面包含若干 span每个 span 对应一次模型调用或一次工具调用记录输入、输出、耗时、token 消耗。这套东西的价值在业务落地阶段会成倍放大。比如你发现某个智能体最近响应变慢了通过 trace 一看是某个工具的平均耗时从 200ms 涨到了 2s又比如你发现成本超预算了一看是某个环节的 prompt 被撑得特别大。没有这些数据你只能拍脑袋优化。2.4 评估从我觉得还行到跑分说话评估是智能体工程化里最容易被跳过、但最重要的一环。很多人搭完智能体自己试几个 case 觉得没问题就上线了结果真实用户一用各种边界情况全冒出来。工程化的做法是建立一套离线评估集把典型任务、边界任务、对抗性输入都整理成测试用例每次改动之后自动跑一遍看通过率、看回归。评估集的构建本身也有讲究。我建议至少分三层基础能力层工具能不能正确调用、任务完成层端到端能不能把事办成、鲁棒性层遇到异常输入会不会崩。这三层的通过率要分开看因为它们的优化手段完全不同。基础能力不行多半是工具描述或参数 schema 的问题任务完成不行往往是规划逻辑的问题鲁棒性不行则要在 prompt 和状态管理上找原因。3. 业务落地阶段智能体架构里那些反直觉的设计选择3.1 为什么很多生产级智能体反而不智能这是个很有意思的现象。你看那些真正在业务里跑起来的智能体往往没有 demo 里那么自由。它们的工作流被约束得很死先做什么、再做什么、什么情况下必须转人工全都是写死的。这不是倒退而是工程上的必然。原因很简单业务要的是稳定和可预期。一个能自由发挥、偶尔给你惊喜的智能体在演示时很酷但在生产环境里就是风险。用户问我的订单到哪了你希望它每次都走同一条查询路径而不是这次查订单表、下次查物流接口、再下次自己编一个答案。所以生产级智能体普遍采用有限自主的设计在明确的边界内让模型做决策边界之外全部走确定性流程。具体到实现上常见做法是把整个任务拆成若干阶段每个阶段有明确的输入输出契约模型只负责阶段内的决策阶段之间的流转由代码控制。这样既保留了模型处理非结构化输入的灵活性又保证了整体流程的可控性。3.2 多智能体不是越多越好关键在职责边界多智能体是这两年的热词但我在实际项目里看到的情况是很多人把多智能体用错了地方。他们把一个本来单智能体就能搞定的任务硬拆成五六个角色互相对话结果 token 消耗翻了好几倍效果反而更差——因为智能体之间的沟通成本被低估了。多智能体真正有价值的场景是职责边界天然清晰、且需要不同能力或不同权限的时候。比如一个销售智能体系统线索筛选、需求分析、方案生成、报价计算这几个环节需要的知识库不同、工具权限不同拆成独立智能体就合理。但如果只是一个负责思考、一个负责执行这种模糊分工那还不如单智能体加个工具调用。判断要不要上多智能体我一般会问三个问题各角色的工具集是否真的不重叠各角色的知识库是否真的需要隔离合并成一个智能体之后prompt 是否会大到影响效果三个问题里有两个答案是是才考虑拆分。3.3 知识库与 RAG检索质量决定智能体上限业务智能体几乎都绕不开知识库。不管是制度条例学习助手、还是销售话术助手背后都要靠检索来提供事实依据。这里我想强调一个经常被忽视的点检索质量决定了智能体的能力上限模型再强也救不了检索出来的垃圾。我见过不少项目花大量时间调 prompt却对切分策略、embedding 模型、召回数量这些检索环节的参数随手一设。结果就是智能体经常答非所问然后大家以为是模型不行。实际上把文档切分从固定长度改成按语义切分、把召回数量从 3 调到 8 再加重排效果往往立竿见影。注意RAG 不是检索到就万事大吉检索结果和用户问题的相关性、以及检索结果之间的冗余度都需要在评估环节专门测。3.4 人机协同转人工的时机设计业务落地绕不开的一个问题是什么时候该让智能体自己处理什么时候该转人工。这个边界设计得好不好直接决定了用户体验和运营成本。我的经验是转人工的触发条件要分几类。置信度类模型对自己的回答明显不确定时转人工。敏感类涉及金额、权限、合规的操作必须人工确认。情绪类用户明显不满或反复追问时转人工能避免矛盾升级。能力类超出智能体知识范围的问题与其硬答不如转人工。这几类条件要在系统里显式配置而不是指望模型自己判断。因为模型在该不该转人工这件事上的判断往往不如一套明确的规则可靠。4. 从 Trending 项目里能抄到的具体作业4.1 智能体框架选型别只看 star 数GitHub Trending 上的智能体框架很多选型的时候容易被 star 数带偏。我的建议是选框架要看四个维度抽象层次是给你一堆原语自己拼还是给你现成的工作流、可观测性支持有没有内置 trace、工具生态常用工具是否现成、社区活跃度issue 响应速度。抽象层次低的框架灵活但上手慢适合有明确定制需求的团队抽象层次高的框架开箱即用但遇到框架没覆盖的场景会比较难受。我一般建议新手从抽象层次高的框架入手先把一个完整流程跑通理解智能体的基本构成再逐步往底层走。4.2 一个最小可用的智能体工程骨架如果你要自己搭一套我建议至少包含这几个模块模块职责关键点状态层管理对话、任务、工具记录可序列化、可回放工具层封装外部能力超时、重试、错误归一化规划层决定下一步做什么有限自主边界清晰执行层调用模型和工具统一 trace评估层离线跑分分层评估集这个骨架不复杂但每一块都别省。我见过太多项目为了赶进度跳过评估层结果上线之后每次改动都是盲改越改越乱。4.3 工具描述怎么写模型才用得对工具调用出问题十有八九是工具描述没写好。模型判断该不该调这个工具、该传什么参数全靠你给的描述。描述写得太简略模型不知道什么时候用写得太啰嗦又浪费 token 还容易干扰。我的写法是一句话说清楚这个工具做什么然后列出每个参数的含义、类型、是否必填、以及取值范围最后给一两个调用示例。特别是参数取值范围一定要写清楚否则模型很容易传一个格式对但语义错的参数进来。比如日期参数你要明确告诉它是YYYY-MM-DD还是时间戳是本地时间还是 UTC。4.4 评估集怎么攒从真实日志里挖评估集不用一开始就追求大而全。最实用的做法是上线一个最小版本把真实用户的请求日志收集起来人工标注一批期望输出然后把这些整理成测试用例。这样攒出来的评估集天然贴近真实分布比你自己拍脑袋想的 case 有用得多。我一般会维护一个回归集专门放那些曾经出过问题、修好之后不能再犯的 case。每次改动之后先跑回归集通过了再跑全量。这样能保证不会修一个坏一个。5. 那些只有踩过才知道的坑5.1 上下文污染多轮之后模型开始记错多轮对话里模型很容易把前面轮次的信息和当前轮次混淆。比如用户先问了一个关于 A 产品的问题又问了 B 产品模型在回答 B 的时候可能把 A 的信息带进来。这个问题在长对话里尤其明显。我的应对办法是在状态层做话题切分当检测到用户意图发生明显变化时把之前的历史做一次摘要压缩只保留关键结论而不是原样保留所有对话。这样既控制了上下文长度又减少了污染。5.2 工具返回结果太长把上下文撑爆有些工具返回的数据特别大比如一次查询返回几百条记录。如果原样塞进上下文不仅浪费 token还会稀释真正重要的信息。做法是在工具层做结果裁剪只返回和当前任务相关的字段或者先做一次摘要再返回。5.3 模型假装调用了工具这是个很隐蔽的坑。有时候模型会在输出里写我已经查询了订单系统结果是……但实际上它根本没调用工具结果是编的。这种情况在工具调用失败但模型没意识到的时候特别容易发生。解决办法是在执行层做校验如果模型声称调用了某个工具但 trace 里没有对应的调用记录就要拦截并重新引导。更根本的办法是让模型的输出格式强制包含工具调用结果而不是让它用自然语言描述。5.4 成本失控token 消耗比预期高一个数量级智能体的 token 消耗往往比单纯对话高得多因为每一轮都要带上完整的状态和工具描述。如果不加控制成本很容易失控。我一般会做几件事精简工具描述、压缩历史上下文、对简单任务走轻量模型、设置单次请求的 token 上限。提示上线前一定要做一次成本估算按最坏情况算别按平均值算。因为智能体的 token 消耗方差很大。6. 智能体面试里那些真正区分水平的问题最近智能体相关的岗位多了起来面试题也从什么是 ReAct这种概念题转向了更工程化的场景题。我整理了几个我觉得特别能区分候选人水平的问题也顺便说说我期待的答案方向。第一个问题是你的智能体工具调用失败了怎么办。初级回答是重试中级会提到超时和幂等高级会区分读操作和写操作、会提到错误归一化和让模型参与决策。这个问题能直接看出候选人有没有真正在生产环境跑过。第二个问题是你怎么评估一个智能体的好坏。如果只回答看回答质量那基本没做过正经项目。好的回答会提到分层评估集、通过率、回归测试、以及线上指标和离线指标的结合。第三个问题是多轮对话里上下文怎么管理。这个问题考的是对状态层的理解。能说出摘要压缩话题切分关键信息提取这些手段的说明踩过坑。第四个问题是怎么控制成本。这个问题很实际能答出精简 prompt、分级用模型、设置上限的说明有成本意识。7. 接下来值得盯的几个方向智能体这个领域变化很快但有几个方向我觉得会持续热下去。一个是评估的标准化现在各家评估方法五花八门未来应该会出现更统一的评估框架和基准。一个是智能体之间的协作协议多智能体要真正规模化通信和协商的规范得先定下来。还有一个是智能体与现有业务系统的深度集成现在很多智能体还是外挂式的未来应该会更深入地嵌进业务流程里。我个人的做法是保持对 Trending 的关注但不过度追新。每看到一个有意思的项目先问自己它解决的是我当前遇到的问题吗如果是就花时间研究如果不是就记个笔记等真遇到了再回头看。这样既能跟上节奏又不会被信息淹没。最后分享一个我自己的习惯每搭一个新智能体我都会先写一份失败清单——列出我能想到的所有可能出错的地方然后在开发过程中逐条验证。这份清单后来往往就成了评估集的雏形。这个习惯帮我省了很多上线后的救火时间推荐你也试试。