Agent 用着用着就坏了：双重底层不可控的踩坑复盘

　　我这两年踩 Agent 的坑，最深的体会不是"工具不够强"，而是**“工具昨天还行，今天就坏了”**。同一套流程、同一份配置，上周跑得稳稳当当，这周就开始频繁报错、执行异常、结果完全随机。一开始我以为是自己的问题，翻日志、调参数、改 prompt，折腾到深夜。直到把几轮"坏掉—修好—再坏掉"的循环摊开看，才明白根源根本不在我这边。

一、我先看到的"摇奖式"现象

　　先说说最直观的感受。我有一套相对固定的 Agent 工作流，跑固定类型的任务。最开始那段时间，它稳定得让人放心——结果一致、路径一致、连报错都一致（当然，最好是不报错）。

　　然后坏就坏在一个"某个时间点"之后。具体表现是：

同样的输入，结果时好时坏：昨天能正常生成的答案，今天偶尔正常、偶尔偏题、偶尔直接失败；
报错信息越来越"抽象"：不再是配置写错那种明确提示，而是"上下文失效"“工具调用超时"“结果不符合预期"这类模糊问题；
修好只能管一阵：这次调整完恢复了，过几天又冒出新问题，像是永远在打地鼠。

　　这种体验，说白了一句话：结果完全随机，好用与否靠运气，体验如同摇奖。 中奖了是"这工具真香”，没中奖就是"我又改坏了什么”。

二、把变量摊开：两个我根本管不了的层

　　靠"再调一调"解决不了问题，是因为问题不在我的配置里，而在下面两层——它们都在静悄悄地变，而我完全没有感知。

第一个变量：Agent 框架在后台静默更新。

　　很多框架为了体验"省心"，默认自动升级，版本号、依赖、内部逻辑说换就换。表面上我用的还是"同一个框架"，实际上底层早就不一样了。今天能用的函数，明天签名变了；今天兼容的插件，明天加载方式变了。关键是它不告诉你——升级是静默的，变更日志藏在 release note 里，你不主动扒根本看不到。

第二个变量：大模型底座在无感知灰度迭代。

　　这层更隐蔽。模型供应商做版本迭代、效果调优、安全对齐，基本都是灰度放量、边跑边改。我不可能知道今天这个请求命中的是哪个版本、哪条推理路径。模型底座稍微偏一点，我的 prompt、我的 few-shot 示例、我的工具调用约定，可能就全部"失配"。

　　这两个变量叠加在一起，就构成了一种最糟糕的组合：框架和模型都在动，而且都瞒着我动。 我把上层配置调得再精确，也追不上下面两层的漂移速度。

三、这笔账，越算越亏

　　一开始我还想跟它较劲，结果就是反复调试、反复修复：

出了问题，先怀疑自己：改 prompt、调参数、换格式，把能试的都试一遍；
修好之后满怀信心，结果过几天又犯，新一轮排查从头开始；
更难受的是，同一个问题这次修好了，下次未必是同一个原因——因为底层又变了，经验常常作废。

　　反复几轮下来，我发现一个残酷的事实：我花在"维护它能跑"上的时间，远多于"让它替我干活"省下的时间。 我原本想让 Agent 自动化省事，结果它成了最需要维护的"宠物"，而不是干活的"工具"。

　　更深一层想，这是双重底层持续变动带来的极强不确定性：你永远不知道它为什么好、为什么坏，也因此永远无法建立稳定的复现和信任。对没有真实落地业务需求、没有团队兜底的个人来说，这种不确定性就是纯消耗。

四、我的结论：别在没有真实需求时深耕 Agent 框架

　　复盘到这，我的结论很朴素：当个人没有实际落地的业务需求时，深耕 Agent 框架，精力的付出远大于实际收益。

　　不是说 Agent 没有价值——它确实在改变很多人干活的方式。但前提是，你有一个真实、稳定、值得托付的需求在等它产出，且你有持续排查、跟进、兜底的精力预算。如果这两条都不占，那你大概率会陷入我这种循环：被两个不可控的变量牵着走，把时间花在追逐一个不断漂移的"稳定性"上。

　　现在的我，心态变了：把 Agent 当能力去"用"，而不是当研究对象去"养"。 能用它解决眼前明确的一两个任务，就用；一旦发现它开始频繁变脸、需要我反复伺候，果断退回手工或更简单的方案，不跟它较劲。

　　写这篇复盘，是想给同样在坑里的人一个提醒：当你发现自己的 Agent 流程"用着用着就坏了"，先别急着怀疑自己。先看看框架是不是又静默升级了，模型底座是不是又悄悄迭代了——那才是大概率的问题根源。