[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-agent-complexity-is-not-ability":3,"article-neighbors-agent-complexity-is-not-ability":17,"article-related-agent-complexity-is-not-ability":37},{"id":4,"slug":5,"title":6,"excerpt":7,"category":8,"tags":9,"content":13,"publishedAt":14,"readingMinutes":15,"published":16},36,"agent-complexity-is-not-ability","Agent 智能体工程落地：为什么复杂链路反而不稳定","工具越多、链路越长，Agent 反而越不稳定。我踩坑总结：Workflow 优先，Agent 兜底。","AI 学习",[10,11,12],"Agent","AI 工程","系统设计","刚接触 Agent 的时候，我也有个错觉：工具挂得越多、推理链路越长、自主决策权限给得越大，这个 Agent 就越\"聪明\"。后来真在项目里做了几个，被现实狠狠教育了一顿——复杂度跟稳定性，往往是反着来的。\n\n### 为什么复杂度反而带来不稳定\n\n原因其实不复杂。大模型做推理本质上是有随机性的，它每次生成都带概率，不是确定性程序。你把它放进一条很长的链路里，一环出错，错误就会像滚雪球一样往下传：第一步参数解析错了，后面的每一步都基于错误继续跑，最后整个流程报废。而且模型推理是个黑盒，出了问题你想定位是哪一步的 bug，难度非常大。\n\n这里有个概率上的残酷事实：假设每一步的失败率只有 1%，一条 20 步的链路，整体失败率就会逼近 18%。步骤越多，出错率不是线性叠加，而是指数累积。所以\"链路越复杂越不稳定\"不是玄学，是数学。这也是为什么业界对 Agent 的态度越来越谨慎——\"看起来聪明\"和\"真正可靠\"之间，隔着一整条工程线。\n\n还有成本问题。多轮推理、多工具嵌套调用，上下文会不断累加，Token 消耗呈指数级往上涨，推理延迟也越来越高。一个商业系统如果跑这么一条链路，光是 Token 费用和响应超时就能把你愁死。我见过一个 Agent 任务，跑了 30 多轮工具调用，单次任务 Token 成本就顶得上普通用户一个月的量。\n\n### 四类最常见的失控场景\n\n我在落地过程中总结了四类最常见的失控场景，写下来供你对照排查：\n\n第一，链式错误传导。模型第一次解析工具参数就错了，后续所有步骤都基于错参数执行，一路错到底。这种错最坑的地方在于——它不会立刻暴露，而是等到最后一步才报错，你根本不知道问题出在源头。\n\n第二，上下文溢出。对话轮数太多，超过模型上下文上限，后面的步骤直接\"失忆\"，不再参考前面的信息。很多模型有上下文长度限制，Agent 一旦跑长了，前面的关键信息就被挤掉了。这个问题的解法是\"上下文管理\"——把早期对话压缩成摘要，只保留关键状态。\n\n第三，死循环。工具调用失败后，模型反复用同样的参数重试，直到触发轮次上限才停下。这个既烧钱又卡流程。常见于\"工具返回了错误，模型没看懂，又原样重试\"的场景，本质上还是工具描述写得不清楚。\n\n第四，高危操作失控。Agent 握着删除、修改这类高权限工具，误操作了数据，等发现的时候已经晚了。这是最严重的一种，因为它不只是\"任务失败\"，而是\"事故\"。\n\n### 核心原则：Workflow 优先，Agent 兜底\n\n所以我的核心原则就一句话：Workflow 优先，Agent 兜底。\n\n步骤固定、逻辑明确、流程标准化的业务，一律用静态工作流（Workflow）把流程固化死——它 100% 可控、低延迟、零偏差，完全不需要模型的\"智能\"掺和。只有当任务真的步骤不确定、需要自主探索、需要动态决策的时候，才启用 Agent。\n\n这背后的判断标准是\"任务的可确定性\"：如果任务的步骤在写代码的时候就能列清楚，那就用 Workflow；如果步骤要等运行时才知道，才考虑 Agent。大多数业务其实是\"看似不确定，其实可以结构化\"的——把它们切成固定步骤，能省掉 90% 的 Agent 问题。\n\n就算要用 Agent，也必须给它套上缰绳：轮次上限、工具职责单一化、高危操作人工鉴权、全链路降级容错。这几点我在另一篇文章《Agent 工具调用工程规范》里详细展开过。\n\n### 可观测性和测试不能省\n\n最后补两个工程细节。一个是可观测性：Agent 的每次推理、每步工具调用，都要记录入参、出参、中间推理，方便出问题时复盘定位。另一个是测试：要专门构造失败场景——工具返回异常、参数边界、用户中途取消、并发调用、权限不足——每个场景都要有明确的兜底行为。没有这些测试，你的 Agent 只能算演示，不能算可上线。\n\n评估一个 AI 系统的好坏，看的是稳定性、可控性、可复盘性，而不是它演示的时候有多\"聪明\"。先把成功路径固化下来，再谈开放动态路径，这是我踩坑换来的经验。记住一句话：Agent 的价值不在\"能自主\"，而在\"自主的同时可控\"。\n","2026-07-24T02:00:00Z",6,true,{"prev":18,"next":27},{"id":19,"slug":20,"title":21,"excerpt":22,"category":8,"tags":23,"publishedAt":25,"readingMinutes":26},29,"agent-tool-call-design","Agent 工具调用工程规范：边界、拦截、容错、防失控","Agent 能不能可靠干活，一半看工具设计。轮次上限、高危拦截、容错兜底，一样都不能少。",[10,24,11],"工具调用","2026-07-10T02:00:00Z",5,{"id":28,"slug":29,"title":30,"excerpt":31,"category":8,"tags":32,"publishedAt":36,"readingMinutes":15},2,"notes-on-ai-learning","AI 应用开发完整学习路线","AI 这行分三条赛道，应用开发是普通开发者最该走的那条。学习顺序和判断标准，这篇说清。",[33,34,35],"AI","学习方法","知识管理","2026-08-08T02:00:00Z",[38,40,42],{"id":28,"slug":29,"title":30,"excerpt":31,"category":8,"tags":39,"publishedAt":36,"readingMinutes":15},[33,34,35],{"id":19,"slug":20,"title":21,"excerpt":22,"category":8,"tags":41,"publishedAt":25,"readingMinutes":26},[10,24,11],{"id":43,"slug":44,"title":45,"excerpt":46,"category":8,"tags":47,"publishedAt":50,"readingMinutes":15},35,"rag-not-vector-demo","RAG 检索增强生成：完整流水线拆解（不止向量入库）","RAG 不是把文档丢进向量库就完事，预处理、分块、混合检索、重排、生成约束，缺一环都白搭。",[48,49,11],"RAG","检索","2026-06-26T02:00:00Z"]