1. 为什么让 Agent 自己挑模型、自己挑工具1.1 写死配置的痛做真实业务才会懂做 Agent 开发的朋友应该都有过这种体验跑 demo 的时候特别爽模型写死用最强的工具列表一股脑塞进系统提示词任务基本能跑通感觉天空才是极限。一旦把 Agent 搬进真实业务问题全冒出来了——简单查询任务在烧大模型的算力复杂任务又因为工具没配全而直接卡死我每天都在改配置、救流程像个全职保姆。后来我换了个思路与其我替 Agent 选好模型和工具不如让 Agent 自己挑模型、自己挑工具。模型按任务复杂度来挑工具按当前意图来挑。围绕这个目标我在项目里先后自研了五件自制件分别是模型路由器、工具选择器、上下文压缩器、结果评估器和失败重试器。这五个件不算什么高深技术但每一件都经历过真实场景下的取舍和翻车值得拿出来聊聊。如果你也正在做 Agent 落地或者准备从 demo 往生产环境推进这篇内容应该能给你省下不少试错的时间。文中所有的方案、参数、坑位都来自我的实际项目日志行业不同、业务不同但做技术选型和方案取舍的思路是可以复用的。1.2 五件自制件的基本盘与协作关系先给一套全局视角。整个 Agent 运行链路可以简化成五步任务进来先过模型路由器决定这一路用哪个模型来推理。Agent 进入主循环推理时通过工具选择器动态挑出当前步骤要用的工具。工具调用结果回填对话历史上下文压缩器负责控制历史长度防止会话被 token 淹没。任务收尾结果评估器判断用户目标是否真的全部完成。任何一个环节失败失败重试器决定是重试、降级、还是上报人工。这五个件不是五个孤立脚本而是一条决策链上的齿轮。模型路由器管用什么脑子想工具选择器管用什么手做上下文压缩器管脑子不缺氧结果评估器管做到什么程度算完失败重试器管出了问题怎么续命。用一个生活化的类比帮没接触过的朋友理解模型路由器像公司前台的接待员先判断你来办什么事、该进哪个部门工具选择器像工具房管理员根据工单帮你拿合适的工具而不是把整个工具箱倒在地上让你自己翻上下文压缩器像会议纪要员把漫长讨论提炼成要点不让会议室被纸张堆满结果评估器像质检员核对交付成果是不是客户真正要的失败重试器像应急预案出岔子时不慌按预案一步步走。在做这五件之前我先给自己定了几条设计原则踩过不少坑才愈发觉得这些原则重要决策可观测所有自制件的每次决策都要落日志出问题能回溯是哪一步选错了。降级优先系统宁可降级完成任务也不要因为单点失败直接中止。人工可介入任何决策层都留一个人工覆盖开关线上紧急情况能直接接管。先跑通再优化初期先写死配置跑真实数据攒够日志再上路由和自选否则连规则都拍不出来。1.3 为什么不直接套框架非得自己造每次跟朋友聊起自制件对方第一个问题基本都是LangChain、LlamaIndex 之类的不都有现成的工具调用机制吗你这不是重复造轮子吗我的回答是框架给的是机制骨架业务决策策略得自己填。框架能帮你管理调用编排但它不知道你业务的成本模型、延迟指标、工具边界是什么样的。比如框架里也有 router但多数只做固定映射框架里也有 tool 机制但工具描述怎么写、召回怎么做、选错了怎么纠正这些都是业务侧的问题。还有一些框架把智能体包装成 harness 的形式说白了就是一套固定的执行外壳。harness 能保证调用顺序和异常处理但决策逻辑依然落在你手里。我的选择是底层调用交给框架能力决策层全部自持。这不算偏执而是生产环境里对成本和可靠性的一种必要掌控。2. 模型路由器让任务匹配门槛合适的模型2.1 为什么不能最强模型一把梭最省事的方案当然是所有请求都打给能力最强的模型省心、效果上限高。我初期就这么干过后来被成本账单和线上延迟教育了。先说成本。按 token 计费的大模型简单查询和复杂推理的单价是一样的但实际消耗差距很大。一个查一下当前库存的请求可能只需要几十个 token 的输出强模型在背后做的长篇思考却是实打实扣费的。再说延迟。强模型在复杂任务上确实强但在简单任务上反而容易想太多输出冗长、格式漂移、偶尔还自我怀疑来回改口。终端用户等一个查询结果多出两三秒的等待体验就很明显了。最后是稳定性。能力越强的模型在简单任务上的行为可预测性反而可能更差——它倾向于补充背景、给出额外建议这些对严格结构化的业务输出是干扰。所以在模型选型上不是越强越好而是门槛合适就好。这正是模型路由器存在的理由。2.2 三层路由规则快路、小模型分类、执行中升级我的模型路由器不是单个算法而是三层递进。第一层是规则快路径。基于历史任务日志把那些语义明确、边界清晰的任务类型直接映射到固定模型。比如意图识别为天气查询、库存查询、汇率计算的任务我会统计它们在小模型上的通过率超过 90% 的高频任务直接写进规则表走最小最便宜的模型。这一层的好处是快、可预测、零额外调用成本。第二层是小模型分类。规则覆盖不到的任务先用一个小模型做分类让它输出任务类型和置信度。这个分类模型只负责分诊不负责治病本身又便宜又快。分类结果按置信度三档处理置信度高于 0.85按分类结果路由到对应模型。置信度 0.6 到 0.85路由到中杯模型但保留后续升级入口。置信度低于 0.6直接路由到强模型因为分类模型都不确定的任务大概率不简单。第三层是执行中升级。前两层都是任务开始前的路由但最难的场景是任务走到一半才发现不对劲。比如 Agent 已经调用了三个工具还要做代码计算中杯模型的推理链明显跟不上了。这时我会中断当前执行链把已经收集到的上下文直接转交给强模型而不是从头再来。关键升级条件我调过很久一开始是推理超过 3 步就升级太激进大量任务全被升级成本等于没降后来改成推理超过 3 步且任务涉及代码生成或数值计算才升级效果才正常。核心伪代码大概是这样的def route_task(task, logs): rule match_rule(task) if rule: return rule[model] cls small_model.classify(task) if cls.confidence 0.6: return BIG_MODEL if cls.confidence 0.85: return MID_MODEL return SMALL_MODEL def should_escalate(ctx): return ( ctx.tool_calls_used 3 and (ctx.need_code_generation or ctx.need_calculation) )2.3 路由前后的实测对比这里放一组我内部项目的实测数据数据口径是自己的日志统计只做参考指标路由前全部强模型路由后变化平均单次请求耗时4.2s2.3s缩短约 45%平均单次请求成本1x0.6x下降约 40%端到端任务成功率91%89%下降 2%单位成本产出任务数1x1.3x提升约 30%成功率降了 2%看起来是坏消息但我做了个权衡这 2% 的失败任务往往集中在分类模型也没把握的边界情况上而这些任务本来就有较高的降级和重试冗余。用 2% 的一次性失败率换来 40% 的成本下降和将近一半的延迟缩短对大多数业务场景是划算的。如果你的业务不允许任何一点成功率下降那一定要在路由器前加一层强模型兜底开关比如对高价值客户或核心交易的请求强制走最强模型。3. 工具选择器让 Agent 在运行时动态挑工具3.1 全量注入工具列表规模一大必崩工具选择是我最早想偷懒的环节。最初我把所有工具的 name、description、参数 JSON Schema 全塞进系统提示词让 Agent 自己看自己选。工具少的时候这么干没问题8 个工具一切正常到 15 个工具开始出现选错工具的案例超过 30 个工具后选择准确率肉眼可见地下降每次请求的 token 消耗也高得离谱。原因不难理解工具描述挤占了大量上下文模型在长列表里做选择的注意力被稀释了工具之间描述如果相似边界会互相干扰工具数量越多幻觉调用不存在工具的频率也越高。最离谱的一次Agent 调用了一个我根本没定义的工具名模型硬生生编了一个 schema 出来。还有一个工程问题工具的增删改如果都要进系统提示词意味着发布新工具要重新发版这在一周迭代好几次的团队里是不可接受的。3.2 两段式选择向量召回 LLM 精挑把全量改成两段式之后问题基本解决。第一段是提前召回。我把每个工具的 name 和一句话摘要做向量化入库用户请求进来后先用向量相似度召回 top10 候选工具。这个召回只看语义相关性速度快、成本低。第二段是 LLM 精挑。只把候选工具的完整 JSON Schema 交给 Agent让它在推理过程中基于当前对话和任务的完整上下文决定调用哪个工具、传什么参数。这个设计的核心取舍是不需要让 Agent 看到全部工具再选提前召回已经把候选集从全部缩小到相关既省 token又减少干扰。我也试验过两步 LLM方案——先让 LLM 从摘要里选再让 LLM 填参数——实测延迟翻倍第二段还容易丢失第一段的上下文整体收益反而不如向量召回加单段精挑。召回逻辑大概长这样def select_tools(query, top_k10): q_vec embed(query current_context_snippet) candidates vector_store.search(q_vec, top_ktop_k) # 把 candidates 的完整 schema 注入给 Agent return build_tool_prompt(candidates)这里有个细节召回时的 query 不能只传用户最新一句我会拼上当前会话的摘要和最近一次工具调用结果不然纯按用户原话召回经常召不回用户其实已经改口的情况。3.3 工具描述怎么写Agent 才不会挑错工具选择器再准也扛不住工具描述写得烂。我把工具描述的规范总结成四个要素用途说明这个工具是干什么的。避免抽象名词要写清使用场景。反例获取天气信息模块正例根据城市名查询实时天气用于行程安排、户外活动决策。入参说清每个参数的格式、单位、取值范围。比如城市编码要写六位行政区划编码不是拼音否则 Agent 会传beijing而不是110000。返回值说明返回的核心字段。Agent 需要判断调完之后我能不能拿到我要的东西比如天气接口返回温度、湿度、风力而不是一张图片链接。边界说明什么情况下不要用这个工具。比如该接口仅覆盖一线城市其他城市请调用 intentcity_weather_v2。写清楚这四要素之后选错工具的概率下降非常明显。一个容易忽视的细节是工具名字。我踩过一个很实际的坑把一个汇总生成最终答案的工具命名为 final_answer结果 Agent 在任务中期就频繁调用它因为它叫最终答案模型觉得调它就能收尾。改名成 summary_output 之后调用时机才恢复理性。工具名越中性越好别带情绪、别带暗示、别让它看起来像终结点。3.4 给工具选择器加护栏工具选择能力再强也不能完全信任。我做了三层护栏第一层是危险工具二次确认。删除、覆盖、批量发送这类工具必须在提示词和代码层双重加确认标志没有用户明确的同意表示Agent 不能调用。这个我在测试期吃过亏Agent 把模拟删除测试数据理解成了真的删除历史数据之后所有危险工具都改了逻辑。第二层是单工具调用次数限制。同一个工具在同一轮任务里最多调用 3 次连续调用后如果依然返回无效结果强制换路。第三层是工具路径记忆。把已经尝试过的工具和结果记录在上下文中告诉 Agent哪些方案已经失效避免它在同一个死胡同打转。这个机制在踩坑章节里我会展开讲。4. 上下文压缩器别让历史把 Agent 拖垮4.1 上下文爆炸的两个典型症状Agent 任务的上下文消耗远比普通对话要快。一个任务里多次推理加上多次工具调用中途再来几轮用户确认很快就到几万 token。上下文变长之后模型开始犯两类错误。第一类是遗忘前置约束。我遇到过一个很典型的案例用户第一句说最后输出用中文中间经过了几轮讨论和工具调用最后模型生成了长英文报告它真的忘了最初的语言约束。第二类是重复和幻觉。模型忘了自己已经查过某个数据又查一次或者查不到数据干脆编一个。这两类错误的根因都在于上下文里塞了太多过程性噪音真正关键的约束被淹没了。压缩器的目标不是单纯减少 token而是保持关键约束密度。4.2 分层混合压缩方案我没有用单一的滑动窗口也没有用全量摘要而是把上下文拆成三层关键事实层用户需求、硬性约束、常量数值。比如邮箱、日期、金额、语言偏好、输出格式。这一层由规则模板加小模型标注共同抽取单独保存不参与滑动窗口清理。过程层工具调用记录和模型中间推理。只保留最近 K 轮完整记录更早的记录压缩成一句摘要。闲聊层寒暄、确认、与当前任务无关的内容直接丢弃。这里要特别说明滑动窗口。滑动窗口本身是个好机制但纯滑动窗口有个致命弱点它只保最近不保重要。用户最核心的需求往往在最早几轮就提出来了如果只用最近 N 条记录关键事实很容易被滑出去。所以我用的是关键事实层永不参与窗口清理的做法这本质上是一种带滤波的滑动窗口——把文本质量看作信号把关键事实看作需要保留的信号分量把过程噪音看作要被过滤掉的干扰窗口滑动时按重要性而不是按新旧来取舍。压缩触发时机我也调过。最初简单粗暴地设了个 token 阈值超过就压结果发现压得太晚模型已经在犯低级错误了。后来改成信号监测跟踪模型输出的质量指标如果连续 2 轮出现输出明显变短、字段缺失、重复同一句话就提前触发压缩。先清闲聊层再压缩过程层关键事实层永远不动。大致的触发逻辑def should_compress(meta): if quality_degraded(meta.signal, last_n2): return True if token_estimate(meta.history) MAX_TOKENS: return True return False4.3 压缩一致性校验关键信息不丢压缩过程最容易翻车的就是丢关键信息。我开始做压缩器的时候跑了一轮任务用户最早说的结果发到 xxxexample.com摘要一压邮箱没了。后面掉链子的地方不是模型的推理而是收件人压根不存在。我的解决办法是压缩一致性校验。压缩前从原始文本里抽 3 到 5 个关键实体包括人名、ID、金额、日期、邮箱、手机号、URL。压缩后再在摘要文本里检查这些实体是否还在。不在了就从原始日志里捞回来重新拼装。格式模板强制保留是另一个必须。邮箱、手机号、URL 这类形式化信息单靠语义抽取不一定抓得住我会在压缩器里维护一组正则模板只要原文出现这类模式即使句子被判定为闲聊层也不能整句丢弃。这一步做扎实之后压缩器带来的收益才真正稳定。我的内部统计里启用压缩器之后长任务的平均 token 消耗下降了约 35%而因为历史关键事实丢失导致的任务失败率几乎没有新增。5. 结果评估器别让 Agent 自己宣布完成5.1 大模型天然爱提前交卷如果你让 Agent 自己判断任务完成了吗它大概率会高估自己的完成度。现象我见过很多次工具调用成功它就宣布已完成用户提了一个半句话需求它自行脑补了剩下的条件它说已完成请查收实际上根本没有生成订单号、没有附件、没有邮件发送记录。大模型生成文本的底层目标是让对话合理结束而不是让业务目标真实达成。所以用户目标真的完成了这件事必须由一个独立于 Agent 主流程的结果评估器来裁决。5.2 三层评估体系我的评估器分三层逐层递进。第一层是规则校验便宜、快速、覆盖大多数场景。检查工具调用返回值里有没有 error 字段最终答案是否存在且长度超过阈值以及用户明确提过的必要条件有没有出现在最终结果里。比如用户说要发到邮箱最终结果里一定要有邮箱地址。第二层是目标清单比对。任务开始时先把用户原需求解析成目标清单比如查酒店、比价格、订房间对应三个目标。任务结束时逐项核对是否有对应的工具调用记录和中间产出物。这一步能抓住很多第一层拦不住的假完成。比如 Agent 只完成了查酒店和比价格没有订房间但已经宣布完成。目标清单比对会直接判它未完成触发补执行。第三层是模型评审只在开放创作类任务里启用。所谓开放创作就是写方案、写代码、做分析这类很难用规则穷举的任务。这时我会引入另一个评审模型从完整性、准确性、约束满足度三个维度打分低于 0.75 分判未完成。评审模型和主 Agent 用的模型建议分开选型带独立角色否则会有我的兄弟都理解我的问题评估基本失效。5.3 目标清单解析的边界问题目标清单比对依赖解析出来的目标是对的。我自己踩过反例用户说查一下周日天气解析器给理解成了预订周日出行评估器反而对后续工具调用判了异常。目标解析这件事有两个解决思路。如果交互场景允许在任务开始时把解析出的目标清单展示给用户确认一眼你需要的这几件事对吗成本很低效果很好。如果不允许确认那就必须把解析日志完整落盘方便事后排查。评估器判定任务未完成的时候日志里能看到它认为缺了哪个目标这是排查假完成问题的第一手材料。另外任何评估器都会误判所以要给评估结果留人工复核通道。我在系统里预设了一个规则评估器连续 2 次判定未完成且补执行后仍然失败任务状态自动标记为需人工介入不再让 Agent 硬扛。6. 失败重试器把不可靠的模型调用变成可控流程6.1 模型服务失败的三种典型形态模型调用没有百分百可用。我总结下来失败主要分三种限流或繁忙返回 429或直接提示模型繁忙常见于高峰时段。超时请求发出后没有在预期时间内返回可能服务端卡住也可能网络中间环节出了问题。内容异常返回了空内容、乱码、或者结构完全不对的内容这种最隐蔽因为从协议层面看是成功的。三种失败形态的应对策略不一样不能都用一个固定重试循环糊弄过去。限流适合退避后重试超时更适合快速失败然后切换备用通道内容异常则要先把这次调用标记为失败再做重试决定。6.2 指数退避与抖动参数重试的经典做法是指数退避加抖动公式我调成了这样def retry_delay(attempt, base1.0, cap30.0, jitter0.5): delay min(cap, base * (2 ** attempt)) return delay random.uniform(0, jitter)基础延迟 1 秒、上限 30 秒、抖动 0 到 0.5 秒。这里有个细节抖动不是装饰品是必需品。没有抖动的全局退避在并发场景下会变成重试风暴我在踩坑章节里专门写了这次事故。重试次数也要按任务类型区分不能一刀切。我的策略是读任务最多重试 3 次写任务最多重试 1 次。原因很简单读任务重复执行没有副作用多试几次无所谓写任务涉及下单、发消息、改状态重复执行的风险远大于任务失败的风险。如果一次重试后仍然不确定是否成功宁可把任务标记为需人工确认也不要盲目再试。6.3 降级链路三条退路重试次数用完之后进入降级链路。我备了三条退路按优先级依次尝试第一退路是切到同能力的备用模型。同一个任务换一个模型服务再跑适合解决某个服务的暂时性故障。第二退路是降级模型加任务拆解。备用模型也失败时把复杂任务拆成更小的子任务用轻量模型逐个完成再汇总结果。这个退路的核心价值是把复杂度降下来让弱模型也能扛住。第三退路是延后队列。把任务放回延迟队列等系统负载降下来再执行。适用于低延迟要求不高的场景比如定时汇总、报表生成。这条降级链路其实就是模型路由器能力的延伸。路由器负责正常情况下的模型选择失败重试器负责异常情况下的再选择。两件自制件配合才能让系统在模型服务不稳定的情况下尽量完成任务。6.4 幂等所有重试的前提所有重试机制的前提都是幂等。没有幂等重试就是制造事故。我的实现方式是任务进入执行器时生成一个全局唯一的 request_id所有工具调用都携带这个 request_id。重试时先查一下这个 request_id 有没有已经成功处理过的记录有就直接返回第一次的结果不再执行。实现上需要两层保障。第一层是结果缓存用一个 KV 存储记录 request_id 到执行结果的映射读请求直接命中缓存。第二层是写入锁写工具在真正落库前先检查这个 request_id 是否已经处理过处理过就直接返回没处理过才继续执行。这层保障专门防重复下单这类事故。幂等设计有一个容易被忽略的点缓存不能只存成功的状态也要存处理中的状态。这样并发重试到来时第二个请求看到一个处理中的锁就不会贸然再执行一遍而是等待第一个执行完成。这套处理中即锁存在的逻辑在并发高的场景里尤其重要。7. 踩坑实录与排查技巧7.1 模型路由误判复杂任务被小模型搞砸现象是一个本来该走强模型的复杂分析任务被小模型分类器误判成了简单查询结果分析结果一塌糊涂。我翻路由日志发现分类置信度 0.82按规则走了中杯模型。但实际任务是一个多条件筛选加数值计算的任务中杯模型在中间步骤就开始漏条件。修复方法是给路由规则加意图黑名单凡是任务描述里包含代码、计算、比较、多条件筛选这些信号直接强制走强模型不做置信度下放。这个黑名单不是凭空拍的是从失败日志里统计出来的哪种任务在低档模型上的失败率显著偏高就把它拉进黑名单。这个坑给我的教训是路由决策的自动化必须留人工干预的口子规则表和黑名单就是那个口子运营同学可以直接改配置。7.2 工具死循环Agent 执着于一个失效工具现象是 Agent 反复调用同一个返回空结果的工具不换工具、不结束任务、也不向用户求助。排查日志时只看到同一个 tool_call 被无限重复。修复做了两件事。第一是单工具调用次数上限同一轮任务里最多调用 3 次。第二是工具路径记忆把已经尝试过的工具和失败原因写回上下文让 Agent 知道这条方案已经试过且无效。路径记忆要放在模型能看到的位置我放在系统提示词末尾起了个名字叫已尝试方案列表。这个坑说明一个道理Agent 的探索必须有边界。没有边界的探索就是死循环用户体验和 token 消耗都会被拖垮。7.3 压缩器把邮箱压丢了故事我前面讲过用户最早说结果发到 xxxexample.com这句话夹在一句闲聊里压缩一致性校验居然没拦下来因为规则抽取没把邮箱识别进关键事实层。任务走到后期发邮件工具被调用收件人却是空的。修复方法有两个方向。一是把邮箱、手机号、URL 等格式模板做成强制保留规则原文一旦出现这类模式所在句子不进入闲聊层清理。二是在一致性校验里增加格式实体强制复核每次压缩后专门扫描这些模式丢了就从原始日志里捞。压缩器这个功能很多人只关注省了多少 token忽略了省掉 token 的代价是可能丢掉关键信息。我现在的原则是压缩器保守优先宁可少压一点也不能把关键信息压丢。7.4 评估器误把中间步骤当最终结果现象是查询工具成功返回后Agent 直接输出已完成但用户要的后续动作根本没做。我在目标清单比对时发现目标里只有查询酒店和比价格Agent 把查询成功当成了整个任务的完成标准。修复方法是给每个目标显式配置完成标志。对于查询酒店完成标志是返回酒店列表对于订房间完成标志是返回订单号。目标的完成标志不能靠模型自由发挥必须由任务模板在开始时指定好。如果目标只有查询类任务评估器还会追加一条硬规则必须有最终交付物比如下载链接、订单号、保存确认否则一律判未完成。这个坑的教训是完成定义的背后是产品逻辑不是技术逻辑。评估器的规则必须跟业务方对齐而不是让模型自说自话。7.5 重试风暴全局退避变全局雪崩现象是某次模型服务抖动所有 Agent 实例同时进入指数退避退避窗口结束时又同时发起重试下游服务的告警瞬间拉满。原因很清晰所有实例用的是同一套退避参数同一时刻退避结束同一时刻重试。修复方法有两处。第一是抖动从固定宽度改成随机区间每个实例的延迟不再一致。第二是加一个全局信号量限制同一时刻并发的重试请求数超过上限的请求直接进延后队列。这个坑让我把抖动从可选项改成了必选项。分布式场景下任何大家都会同时做同一件事的设计本质上都是把单点故障放大成群体故障。7.6 踩坑清单速查表把上面这些整理成一张表方便对号入座坑位现象根因预防手段路由误判复杂任务被小模型执行分类置信度下放过松意图黑名单强制走强模型工具死循环重复调用同一失效工具缺少尝试路径记忆单工具 3 次上限加路径记忆关键信息丢失邮箱、订单号被压缩掉关键事实抽取失效格式模板强制保留加复核假完成中间步骤被当成最终结果完成定义不明确目标清单加显式完成标志重试风暴下游被瞬时打爆退避无抖动、无全局限流随机抖动加全局信号量7.7 调试 Agent 系统的三个通用习惯除了具体坑位我再分享三个做 Agent 系统养成的好习惯都来自实战。第一个是决策日志。不只是记录做了什么事还要记录为什么做这个选择。模型路由器的路由结果、工具选择器的候选集、压缩器的触发原因、评估器的目标比对结果这些都要结构化落日志。没有决策日志线上出问题只能盲猜。第二个是影子模式。新加一个自制件或者改一套决策策略时先在影子模式下观察一段时间照常运行老逻辑同时并行记录新逻辑的决策结果对比差异。相当于先让新方案在旁边跑一段实习期实习期过了再转正。第三个是人工覆盖开关。任何自动化决策都要有手动接管的手段。线上出问题的时候最糟糕的是没法即刻介入只能等 Agent 自己挣扎完。我在每个关键节点都留了开关比如强制所有请求走强模型禁用某个工具暂停重试进入人工队列这几个开关已经救过我很多次。8. 最后一件事自制件是造轮子还是必经之路做完这五件自制件我自己的感受是一开始觉得在造轮子后面发现这个轮子非造不可。框架会给你机制但不会替你背业务指标。成本和延迟的压力、工具边界的复杂度、模型服务的不稳定性这些必须自己接住。如果你看完能少踩几个坑我希望你记住两个原则。第一个是决策层要自持能给业务带来确定性收益的核心决策不要全部交给黑盒。第二个是所有的自动化都要留人工出口Agent 会犯错系统会抖动模型会繁忙这时候由人来接管不是失败而是负责任的设计。最后再分享一个小细节。不管自制件做得多完善我都给 Agent 留了一个我不知道该怎么做的出口。当它判断自己确实搞不定时允许它把问题原样抛回给我而不是硬编一个答案。这个出口帮我挡掉了不少线上事故也让我更清楚地知道哪些环节还需要继续打磨。Agent 的自主能力从来不是让它一直硬撑的能力而是知道什么时候该求助的能力。