核心导读一句话看懂这不是单纯挑毛病而是从复杂 AI 编码 Agent 的真实短板里提炼出可复用的架构治理方法稳定缓存、保留关键上下文、补足语义搜索、避免大结果误判、治理灰度开关并建立可恢复、可补偿、可追踪的容错体系。一、开场成熟的 Agent不只看能力更要看短板很多人看 AI 编码工具只盯着它能不能写代码、能不能改文件、能不能一次性完成复杂任务。但站在工程视角一个真正成熟的 AI Agent更关键的是它在长时间运行、上下文膨胀、工具结果巨大、权限状态变化、灰度配置切换时是否还能保持稳定。Claude Code 的设计里有大量值得借鉴的能力比如提示词分层、工具编排、缓存优化、权限控制、子 Agent 协作、记忆系统等。但任何复杂系统都有代价。越是强大的系统越容易在边界处暴露出隐藏问题。这份技术分析最有价值的地方不是简单指出“不足”而是把这些不足放回工程权衡里看为了灵活组合提示词缓存可能变脆为了长会话不断片摘要可能丢细节为了跨语言通用Grep 可能缺少语义理解为了保护上下文预算大结果可能被截断为了快速灰度Feature Flag 组合可能变复杂。所以这不是一篇“吐槽清单”而是一份 AI Agent 架构补强指南。看懂这些问题你做自己的 AI 编码系统、企业内部 Agent 平台、自动化研发助手时就能少踩很多坑。二、整体框架5 个短板背后是 5 类系统性工程问题把所有问题归类后可以发现它们并不是零散 bug而是 5 类典型工程矛盾。第一类是缓存稳定性问题系统想复用稳定前缀但运行时又有很多动态注入点。第二类是上下文压缩问题系统想让长会话继续跑但压缩必然会丢掉一部分细节。第三类是代码理解问题文本搜索足够快却不能理解抽象语法树、符号引用和类型推断。第四类是大结果预算问题工具输出太大会吞掉上下文所以必须截断但截断之后模型未必主动追完整内容。第五类是灰度开关复杂性问题Feature Flag 能加快迭代但多个开关叠加后组合行为会变得难预测。这 5 个问题对应 5 个补救方向集中构建提示词、分层压缩上下文、引入 LSP 语义能力、做智能预览和分页、建立 Feature Flag 依赖图与互斥规则。换句话说真正的 AI Agent 工程不是“把模型接上工具”这么简单而是要围绕成本、稳定性、可恢复性和可观测性建立完整控制面。三、缓存脆弱性分散注入点越多缓存越容易失效提示词缓存的核心假设很简单把稳定内容放在前面让系统后续复用这部分内容从而降低成本和延迟。Anthropic 的 Prompt Caching 机制也强调缓存适合大量背景信息、稳定指令和长多轮会话并且缓存前缀会包含 tools、system、messages 等部分。问题在于AI 编码 Agent 的“稳定前缀”并不总是稳定。比如 Feature Flag 可能改变工具行为MCP 连接状态可能改变可用工具工具 Schema 可能因为插件、子 Agent 或远程能力变化而改变。只要这些变化进入缓存段缓存命中率就会被破坏。更麻烦的是如果系统里有多个分散注入点每个位置都能往提示词里塞内容就很难判断“到底是谁破坏了缓存”。这也是为什么需要复杂的缓存中断检测系统去追踪大量字段。检测系统越复杂往往说明前面的架构边界越脆。更稳的做法是中心化构建所有提示词段落先进入统一注册表每段都标记为静态、动态、易变或会话级稳定。系统在一个中心函数里排序、合成、计算哈希并且强制把易变内容放到缓存边界之后。这样才能把“靠约定不乱改”升级为“靠架构保证不污染”。四、压缩信息丢失摘要能保留主线却很难保留失败路径长会话一定会遇到上下文窗口限制。自动压缩的价值很明显把前面的对话、文件操作、命令结果、技术决策压成摘要让 Agent 能继续工作。但压缩天然是有损的尤其是用自然语言摘要时。最容易丢的不是“最后做了什么”而是“为什么这样做”。比如模型尝试过方案 A失败后改用方案 B。压缩后可能只剩“采用方案 B 解决问题”失败方案 A 和当时的判断过程就消失了。下一轮模型可能又重新尝试 A造成重复踩坑。还会丢失精确引用。原本可能是某个文件、某个函数、某个范围的问题压缩后变成“修改认证模块”“优化工具逻辑”这样的泛化描述。对于人类阅读还行但对于下一轮自动化修复来说泛化就是定位成本。更稳的方案是分层压缩。事实层保留文件清单、修改记录、命令结果、关键路径推理层保留方案选择原因、权衡关系和风险判断失败层单独记录已经试过但失败的方法恢复层根据最近访问文件和任务计划按预算重新注入必要内容。这样摘要不再是一段自然语言而是可恢复上下文资产。五、Grep 不是 AST文本搜索快但语义理解不够Grep 和 Glob 的优势非常明显速度快、依赖少、跨语言通用、适合找关键字、文件名、字符串模式。对于很多日常任务来说它们已经足够好。但 AI 编码 Agent 要做复杂改造时仅靠文本搜索就会遇到语义盲区。比如动态导入、重导出、类型别名、函数调用链、变量类型推断、接口实现关系这些不是简单搜字符串就能稳定得到的。LSP 的价值正在这里。LSP 定义了编辑器或 IDE 与语言服务器之间的通信协议可以提供自动补全、跳转定义、查找引用等语言能力。微软官方说明也强调它让语言能力可以被多个开发工具复用。所以更好的架构不是用 LSP 替代 Grep而是组合使用。Grep 负责快速粗召回先把候选范围缩小LSP 负责精确语义查询确认定义、引用、类型和调用层次。对 AI Agent 来说这相当于把“眼睛”从普通全文搜索升级为“既能扫街也能看地图”。六、截断告知不足告诉模型“被截断”不代表模型会行动工具结果太大时系统通常会截断输出只展示前面一部分把完整结果保存到文件中。这种设计本身有道理因为一个超大结果可能瞬间吞掉上下文预算影响后续推理。问题是告知模型“结果被截断”并不等于确保模型一定会去读完整内容。模型每一步都要做成本判断如果前 50K 字符看起来已经包含一些有用线索它可能会认为“够了”然后基于预览继续推理。但关键证据可能刚好在后面。比如搜索结果前面全是相似但无关的匹配真正的核心文件排在后面或者日志前半段只是铺垫真正错误栈在后面。这种情况下单纯截取前段内容会制造一种“看起来信息充分”的错觉。更稳的做法是智能预览。不要只展示前 N 个字符而是给模型结构化信息总共多少条匹配、分布在哪些文件、每组结果的摘要、当前预览覆盖了多少比例、是否建议继续查看。更进一步可以自动分页让模型按文件、按匹配分组、按相关性继续读取。七、Feature Flag 复杂性灰度越灵活组合越难治理Feature Flag 是现代软件快速迭代的重要手段。GrowthBook 官方文档也强调Feature Flag 可以让应用行为在不重新部署代码的情况下被控制并支持定向用户、渐进发布和 A/B 测试。但当一个 AI Agent 系统拥有大量开关时问题就来了。单个开关很好理解两个开关也能测试几十个开关叠加后组合空间会急剧膨胀。哪怕只有少量开关彼此影响系统行为也会变得难预测。典型冲突包括后台助手模式和主动工作模式都想唤醒 Agent团队协作和协调器模式都涉及多 Agent 消息通信远程执行和守护进程生命周期互相依赖快速模式和深度思考模式在成本与质量之间可能拉扯。治理方式不能停留在“出了问题再修”。应该为每个开关声明依赖关系、互斥组合、适用环境和默认回退策略。关键开关至少做两两组合测试。调试模式下要能输出所有开关当前值、来源、锁存状态和最近变更。只有这样Feature Flag 才是工程能力而不是隐藏炸弹。八、三层视角提示词层、工具层、基础设施层把这 5 个问题放进分层架构里会更清楚。提示词层的问题包括压缩信息丢失和截断告知不足主要影响模型拿到的信息质量。工具层的问题是 Grep 无法理解语义关系影响代码定位和证据链构建。基础设施层的问题是缓存脆弱性和 Feature Flag 复杂性影响成本、性能和整体稳定性。越靠底层修复成本越高影响范围越大。缓存和开关属于基础设施层一旦设计不稳可能影响每一次请求、每一次工具注册、每一次上下文合成。提示词层的问题相对更容易通过模板、摘要策略和预览格式缓解。工具层介于两者之间需要引入新能力但不一定要推翻核心架构。这也给团队一个排序原则先把基础设施边界收稳再补工具语义能力最后优化提示词层体验。否则上层写再多提示词底层缓存和配置仍然抖动系统还是会不稳定。九、普通使用者能做什么不是只能等待官方修复有些问题是系统内部架构问题普通使用者确实无法直接修。但仍然可以通过使用策略降低踩坑概率。第一保持项目指令稳定不要频繁修改核心说明稳定的长期指令更利于缓存复用也更利于模型形成一致行为。第二关注缓存成本。如果 API 账单或平台日志里能看到 cache_creation 和 cache_read 相关字段就要观察它们的比例。创建缓存很多、读取缓存很少往往意味着稳定前缀没有被很好复用。第三遇到大结果截断时主动要求查看完整内容。尤其是搜索、日志、测试结果、依赖扫描这类输出关键信息未必在前面。可以在项目指令里加入稳定规则当工具结果被截断时先查看完整结果或分页结果再做结论。第四通过 MCP 或外部工具补语义能力。如果项目很依赖 TypeScript、Python、Java 等语言单纯文本搜索不够可以引入 LSP、索引服务或代码图谱能力。第五把关键技术决策、失败经验、项目约束写入稳定记忆避免压缩后丢掉。十、三层容错架构成熟系统不是不出错而是能恢复这一部分非常关键。任何 AI Agent 都会出错尤其是能读写文件、运行命令、跨工具协作的 Agent。真正的工程化能力不是承诺“永远不出错”而是把检查点、可恢复执行、补偿事务做扎实。第一层是检查点。每条消息、每次文件变更、每个关键状态都应该能被持久化。不要等任务结束才保存因为 Agent 的每一步都可能改变文件系统。按消息粒度保存比定期保存更适合自动化工作流。第二层是可恢复执行。当用户中断、终端关闭、进程退出或网络异常时系统要能优雅关闭刷新必要状态并在重新启动后恢复历史、文件快照和任务状态。恢复不是重新开始而是从断点接上。第三层是补偿事务。文件写错了怎么办不是简单“再改回来”而是要有清晰的回退目标、可预览的差异和可执行的恢复动作。尤其是涉及删除、覆盖、批量修改时必须允许先 dry-run 式预览再执行真正回退。十一、工程启示不要盲目照搬要看清权衡缓存脆弱性对应的另一面是提示词灵活组合能力压缩信息丢失对应的另一面是系统可以在长会话里持续工作Grep 语义不足对应的另一面是零外部依赖和跨语言通用截断风险对应的另一面是保护上下文不被单个大结果淹没Flag 复杂性对应的另一面是快速迭代与实验能力。这就是工程的真实世界没有免费的能力。每一个“强能力”背后都有代价。好的架构不是回避代价而是把代价显性化、可观测化、可补偿化。如果你在做自己的 AI Agent可以直接套用这套检查清单缓存段是否稳定压缩后是否保留失败经验搜索是否有语义能力截断结果是否有分页导航Feature Flag 是否有依赖和互斥每一步是否落盘能否恢复能否回退当这些问题都有答案时你做的就不再是一个“会调用模型的脚本”而是一套真正有工程生命力的 Agent 系统。十二、总结AI Agent 的终局是可控、可恢复、可治理AI 编码工具的竞争表面看是模型能力深层看是上下文工程、工具工程、安全工程、缓存工程和容错工程。能写代码只是起点能长时间稳定协作才是护城河。这次拆解的 5 个不足分别击中了 AI Agent 系统最容易被忽略的 5 个地方稳定前缀、长会话压缩、语义搜索、结果预算、功能开关治理。再加上检查点、恢复执行、补偿事务三层防护基本构成了生产级 AI Agent 的关键能力图谱。真正值得学习的不是某个具体实现而是背后的思维方式先承认复杂性再设计边界先承认会出错再设计恢复先承认模型会漏看再设计结构化提示先承认开关会相互影响再设计依赖图。未来优秀的 AI Agent不会只是“更聪明”还会更稳、更透明、更容易被团队治理。谁能把这些工程细节打磨好谁才可能把 AI 从演示能力推进到真正的生产力系统。附5 个短板与补救方案速查表问题类型典型表现根因改进方向缓存脆弱性稳定前缀被动态内容扰动注入点分散边界不清集中构建、哈希审计、不可变约束压缩丢失失败路径和选择理由被摘要吞掉自然语言摘要有损事实层、推理层、失败层分开保留搜索盲区能搜字符串难找语义关系Grep 不理解符号与类型Grep 粗召回 LSP 精定位截断风险预览看似够用关键证据在后面告知不等于行动智能预览、相关性提示、自动分页开关复杂多个 Flag 组合导致行为不可预测依赖关系与互斥关系隐形依赖图、互斥约束、组合测试、状态可视化参考资料https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd6fkr
Claude Code 不足复盘与容错架构全解析：AI Agent 架构优化、上下文工程、缓存稳定性、LSP 语义搜索、Feature Flag 治理
核心导读一句话看懂这不是单纯挑毛病而是从复杂 AI 编码 Agent 的真实短板里提炼出可复用的架构治理方法稳定缓存、保留关键上下文、补足语义搜索、避免大结果误判、治理灰度开关并建立可恢复、可补偿、可追踪的容错体系。一、开场成熟的 Agent不只看能力更要看短板很多人看 AI 编码工具只盯着它能不能写代码、能不能改文件、能不能一次性完成复杂任务。但站在工程视角一个真正成熟的 AI Agent更关键的是它在长时间运行、上下文膨胀、工具结果巨大、权限状态变化、灰度配置切换时是否还能保持稳定。Claude Code 的设计里有大量值得借鉴的能力比如提示词分层、工具编排、缓存优化、权限控制、子 Agent 协作、记忆系统等。但任何复杂系统都有代价。越是强大的系统越容易在边界处暴露出隐藏问题。这份技术分析最有价值的地方不是简单指出“不足”而是把这些不足放回工程权衡里看为了灵活组合提示词缓存可能变脆为了长会话不断片摘要可能丢细节为了跨语言通用Grep 可能缺少语义理解为了保护上下文预算大结果可能被截断为了快速灰度Feature Flag 组合可能变复杂。所以这不是一篇“吐槽清单”而是一份 AI Agent 架构补强指南。看懂这些问题你做自己的 AI 编码系统、企业内部 Agent 平台、自动化研发助手时就能少踩很多坑。二、整体框架5 个短板背后是 5 类系统性工程问题把所有问题归类后可以发现它们并不是零散 bug而是 5 类典型工程矛盾。第一类是缓存稳定性问题系统想复用稳定前缀但运行时又有很多动态注入点。第二类是上下文压缩问题系统想让长会话继续跑但压缩必然会丢掉一部分细节。第三类是代码理解问题文本搜索足够快却不能理解抽象语法树、符号引用和类型推断。第四类是大结果预算问题工具输出太大会吞掉上下文所以必须截断但截断之后模型未必主动追完整内容。第五类是灰度开关复杂性问题Feature Flag 能加快迭代但多个开关叠加后组合行为会变得难预测。这 5 个问题对应 5 个补救方向集中构建提示词、分层压缩上下文、引入 LSP 语义能力、做智能预览和分页、建立 Feature Flag 依赖图与互斥规则。换句话说真正的 AI Agent 工程不是“把模型接上工具”这么简单而是要围绕成本、稳定性、可恢复性和可观测性建立完整控制面。三、缓存脆弱性分散注入点越多缓存越容易失效提示词缓存的核心假设很简单把稳定内容放在前面让系统后续复用这部分内容从而降低成本和延迟。Anthropic 的 Prompt Caching 机制也强调缓存适合大量背景信息、稳定指令和长多轮会话并且缓存前缀会包含 tools、system、messages 等部分。问题在于AI 编码 Agent 的“稳定前缀”并不总是稳定。比如 Feature Flag 可能改变工具行为MCP 连接状态可能改变可用工具工具 Schema 可能因为插件、子 Agent 或远程能力变化而改变。只要这些变化进入缓存段缓存命中率就会被破坏。更麻烦的是如果系统里有多个分散注入点每个位置都能往提示词里塞内容就很难判断“到底是谁破坏了缓存”。这也是为什么需要复杂的缓存中断检测系统去追踪大量字段。检测系统越复杂往往说明前面的架构边界越脆。更稳的做法是中心化构建所有提示词段落先进入统一注册表每段都标记为静态、动态、易变或会话级稳定。系统在一个中心函数里排序、合成、计算哈希并且强制把易变内容放到缓存边界之后。这样才能把“靠约定不乱改”升级为“靠架构保证不污染”。四、压缩信息丢失摘要能保留主线却很难保留失败路径长会话一定会遇到上下文窗口限制。自动压缩的价值很明显把前面的对话、文件操作、命令结果、技术决策压成摘要让 Agent 能继续工作。但压缩天然是有损的尤其是用自然语言摘要时。最容易丢的不是“最后做了什么”而是“为什么这样做”。比如模型尝试过方案 A失败后改用方案 B。压缩后可能只剩“采用方案 B 解决问题”失败方案 A 和当时的判断过程就消失了。下一轮模型可能又重新尝试 A造成重复踩坑。还会丢失精确引用。原本可能是某个文件、某个函数、某个范围的问题压缩后变成“修改认证模块”“优化工具逻辑”这样的泛化描述。对于人类阅读还行但对于下一轮自动化修复来说泛化就是定位成本。更稳的方案是分层压缩。事实层保留文件清单、修改记录、命令结果、关键路径推理层保留方案选择原因、权衡关系和风险判断失败层单独记录已经试过但失败的方法恢复层根据最近访问文件和任务计划按预算重新注入必要内容。这样摘要不再是一段自然语言而是可恢复上下文资产。五、Grep 不是 AST文本搜索快但语义理解不够Grep 和 Glob 的优势非常明显速度快、依赖少、跨语言通用、适合找关键字、文件名、字符串模式。对于很多日常任务来说它们已经足够好。但 AI 编码 Agent 要做复杂改造时仅靠文本搜索就会遇到语义盲区。比如动态导入、重导出、类型别名、函数调用链、变量类型推断、接口实现关系这些不是简单搜字符串就能稳定得到的。LSP 的价值正在这里。LSP 定义了编辑器或 IDE 与语言服务器之间的通信协议可以提供自动补全、跳转定义、查找引用等语言能力。微软官方说明也强调它让语言能力可以被多个开发工具复用。所以更好的架构不是用 LSP 替代 Grep而是组合使用。Grep 负责快速粗召回先把候选范围缩小LSP 负责精确语义查询确认定义、引用、类型和调用层次。对 AI Agent 来说这相当于把“眼睛”从普通全文搜索升级为“既能扫街也能看地图”。六、截断告知不足告诉模型“被截断”不代表模型会行动工具结果太大时系统通常会截断输出只展示前面一部分把完整结果保存到文件中。这种设计本身有道理因为一个超大结果可能瞬间吞掉上下文预算影响后续推理。问题是告知模型“结果被截断”并不等于确保模型一定会去读完整内容。模型每一步都要做成本判断如果前 50K 字符看起来已经包含一些有用线索它可能会认为“够了”然后基于预览继续推理。但关键证据可能刚好在后面。比如搜索结果前面全是相似但无关的匹配真正的核心文件排在后面或者日志前半段只是铺垫真正错误栈在后面。这种情况下单纯截取前段内容会制造一种“看起来信息充分”的错觉。更稳的做法是智能预览。不要只展示前 N 个字符而是给模型结构化信息总共多少条匹配、分布在哪些文件、每组结果的摘要、当前预览覆盖了多少比例、是否建议继续查看。更进一步可以自动分页让模型按文件、按匹配分组、按相关性继续读取。七、Feature Flag 复杂性灰度越灵活组合越难治理Feature Flag 是现代软件快速迭代的重要手段。GrowthBook 官方文档也强调Feature Flag 可以让应用行为在不重新部署代码的情况下被控制并支持定向用户、渐进发布和 A/B 测试。但当一个 AI Agent 系统拥有大量开关时问题就来了。单个开关很好理解两个开关也能测试几十个开关叠加后组合空间会急剧膨胀。哪怕只有少量开关彼此影响系统行为也会变得难预测。典型冲突包括后台助手模式和主动工作模式都想唤醒 Agent团队协作和协调器模式都涉及多 Agent 消息通信远程执行和守护进程生命周期互相依赖快速模式和深度思考模式在成本与质量之间可能拉扯。治理方式不能停留在“出了问题再修”。应该为每个开关声明依赖关系、互斥组合、适用环境和默认回退策略。关键开关至少做两两组合测试。调试模式下要能输出所有开关当前值、来源、锁存状态和最近变更。只有这样Feature Flag 才是工程能力而不是隐藏炸弹。八、三层视角提示词层、工具层、基础设施层把这 5 个问题放进分层架构里会更清楚。提示词层的问题包括压缩信息丢失和截断告知不足主要影响模型拿到的信息质量。工具层的问题是 Grep 无法理解语义关系影响代码定位和证据链构建。基础设施层的问题是缓存脆弱性和 Feature Flag 复杂性影响成本、性能和整体稳定性。越靠底层修复成本越高影响范围越大。缓存和开关属于基础设施层一旦设计不稳可能影响每一次请求、每一次工具注册、每一次上下文合成。提示词层的问题相对更容易通过模板、摘要策略和预览格式缓解。工具层介于两者之间需要引入新能力但不一定要推翻核心架构。这也给团队一个排序原则先把基础设施边界收稳再补工具语义能力最后优化提示词层体验。否则上层写再多提示词底层缓存和配置仍然抖动系统还是会不稳定。九、普通使用者能做什么不是只能等待官方修复有些问题是系统内部架构问题普通使用者确实无法直接修。但仍然可以通过使用策略降低踩坑概率。第一保持项目指令稳定不要频繁修改核心说明稳定的长期指令更利于缓存复用也更利于模型形成一致行为。第二关注缓存成本。如果 API 账单或平台日志里能看到 cache_creation 和 cache_read 相关字段就要观察它们的比例。创建缓存很多、读取缓存很少往往意味着稳定前缀没有被很好复用。第三遇到大结果截断时主动要求查看完整内容。尤其是搜索、日志、测试结果、依赖扫描这类输出关键信息未必在前面。可以在项目指令里加入稳定规则当工具结果被截断时先查看完整结果或分页结果再做结论。第四通过 MCP 或外部工具补语义能力。如果项目很依赖 TypeScript、Python、Java 等语言单纯文本搜索不够可以引入 LSP、索引服务或代码图谱能力。第五把关键技术决策、失败经验、项目约束写入稳定记忆避免压缩后丢掉。十、三层容错架构成熟系统不是不出错而是能恢复这一部分非常关键。任何 AI Agent 都会出错尤其是能读写文件、运行命令、跨工具协作的 Agent。真正的工程化能力不是承诺“永远不出错”而是把检查点、可恢复执行、补偿事务做扎实。第一层是检查点。每条消息、每次文件变更、每个关键状态都应该能被持久化。不要等任务结束才保存因为 Agent 的每一步都可能改变文件系统。按消息粒度保存比定期保存更适合自动化工作流。第二层是可恢复执行。当用户中断、终端关闭、进程退出或网络异常时系统要能优雅关闭刷新必要状态并在重新启动后恢复历史、文件快照和任务状态。恢复不是重新开始而是从断点接上。第三层是补偿事务。文件写错了怎么办不是简单“再改回来”而是要有清晰的回退目标、可预览的差异和可执行的恢复动作。尤其是涉及删除、覆盖、批量修改时必须允许先 dry-run 式预览再执行真正回退。十一、工程启示不要盲目照搬要看清权衡缓存脆弱性对应的另一面是提示词灵活组合能力压缩信息丢失对应的另一面是系统可以在长会话里持续工作Grep 语义不足对应的另一面是零外部依赖和跨语言通用截断风险对应的另一面是保护上下文不被单个大结果淹没Flag 复杂性对应的另一面是快速迭代与实验能力。这就是工程的真实世界没有免费的能力。每一个“强能力”背后都有代价。好的架构不是回避代价而是把代价显性化、可观测化、可补偿化。如果你在做自己的 AI Agent可以直接套用这套检查清单缓存段是否稳定压缩后是否保留失败经验搜索是否有语义能力截断结果是否有分页导航Feature Flag 是否有依赖和互斥每一步是否落盘能否恢复能否回退当这些问题都有答案时你做的就不再是一个“会调用模型的脚本”而是一套真正有工程生命力的 Agent 系统。十二、总结AI Agent 的终局是可控、可恢复、可治理AI 编码工具的竞争表面看是模型能力深层看是上下文工程、工具工程、安全工程、缓存工程和容错工程。能写代码只是起点能长时间稳定协作才是护城河。这次拆解的 5 个不足分别击中了 AI Agent 系统最容易被忽略的 5 个地方稳定前缀、长会话压缩、语义搜索、结果预算、功能开关治理。再加上检查点、恢复执行、补偿事务三层防护基本构成了生产级 AI Agent 的关键能力图谱。真正值得学习的不是某个具体实现而是背后的思维方式先承认复杂性再设计边界先承认会出错再设计恢复先承认模型会漏看再设计结构化提示先承认开关会相互影响再设计依赖图。未来优秀的 AI Agent不会只是“更聪明”还会更稳、更透明、更容易被团队治理。谁能把这些工程细节打磨好谁才可能把 AI 从演示能力推进到真正的生产力系统。附5 个短板与补救方案速查表问题类型典型表现根因改进方向缓存脆弱性稳定前缀被动态内容扰动注入点分散边界不清集中构建、哈希审计、不可变约束压缩丢失失败路径和选择理由被摘要吞掉自然语言摘要有损事实层、推理层、失败层分开保留搜索盲区能搜字符串难找语义关系Grep 不理解符号与类型Grep 粗召回 LSP 精定位截断风险预览看似够用关键证据在后面告知不等于行动智能预览、相关性提示、自动分页开关复杂多个 Flag 组合导致行为不可预测依赖关系与互斥关系隐形依赖图、互斥约束、组合测试、状态可视化参考资料https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd6fkr
