夜雨聆风支柱 | 覆盖挑战 | 对应框架考核能力 | 本章展开位置 |
Ⅰ 确定性控制：让Agent 按计划收敛、不跑偏、不卡死 | 挑战1（上下文漂移）、2（规划坍塌）、3（粒度失当）、7（工具幻觉）、8（并发失控）、10（死循环） | 确定性流程编排与状态管理；可观测性与审计追踪 | 4.2.1 |
Ⅱ 持久化状态：让Agent 有记忆、能续跑 | 挑战4（记忆失控）、6（跨会话断裂）、11（环境漂移） | 持久化与故障恢复；长程记忆与跨会话状态延续 | 4.2.2 |
Ⅲ 闭环自学习：让Agent 自己发现错、沉淀经验、下次不犯同一个错 | 挑战5（经验缺失）、9（自验证缺失）、12（归因差） | 自我改进与技能积累 | 4.2.3 |
横切关注点：HITL 与安全资源 | 挑战13（HITL）、14（安全）、15（资源） | 跨支柱共性要求，涉及所有考核能力 | 4.2.4 |
框架 | GitHub Stars | 架构模式 | 状态管理 | 持久化 | HITL | 可观测性 | 生产就绪度 | 代表客户 |
LangGraph | 24.8k | 有向图(DAG)+显式状态对象 | 显式typed state | 原生Postgres/Redis checkpoint | 原生checkpoint 暂停/恢复 | LangSmith全链路 | 高 | Uber, LinkedIn, Klarna, BlackRock |
AutoGen(AG2) | 18.5k | 对话式多Agent | 对话历史(非结构化) | 需自建 | 非原生 | 需自定义日志 | 中 | 学术/研究场景为主 |
CrewAI | 18.2k | 角色式团队 | YAML+内部opaque | 需自建 | interrupt hook(部分) | v2 改进中 | 中高(原型)/低(企业) | Shopify(快速原型) |
OpenAI Agents SDK | 19k | 轻量多Agent | 轻量 | 需自建 | 内置guardrails | 内置tracing | 高(GPT 生态内) | OpenAI 生态项目 |
Dify | 129.8k | 可视化工作流 | 可视化画布 | 需自建 | 人工节点 | 基础 | 高(低代码场景) | 非开发者为主 |
AgentScope | 6.2k | 消息驱动多Agent(阿里) | 显式消息总线 | 需自建 | 部分 | 基础 | 中 | 阿里内部项目 |
BISHENG | 8.1k | 企业流程编排(毕昇) | 显式流程节点 | MySQL checkpoint | 审批节点 | 内置 | 中高 | 金融/央企 |
框架 | GitHub Stars | 创建者 | 核心差异化 | 记忆架构 | 自我改进 | 定时调度 | 部署模式 |
OpenClaw | 约280k | Peter Steinberger(奥地利) | 自主执行+持久状态+生态最大 | Dinobase(ACID, 12ms 写入) | 无闭环学习 | 有限 | 本地/Docker/K8s/Apple Watch |
Hermes Agent | 约35.7k | Nous Research(Teknium) | 闭环自学习+三层记忆+多模型 | 三层：短期+技能+长期 | 自动技能创建+自优化 | 自然语言cron | 本地/Docker/SSH/Modal/Daytona |
Letta(原MemGPT) | 16.4k | UC Berkeley | 分层记忆范式奠基者 | 工作记忆+归档记忆 | 无 | 无 | 本地/Docker |
Manus 类(灵思等) | 封闭 | 国内团队 | 浏览器自主执行 | 任务级状态 | 部分技能复用 | 有限 | SaaS |
4.2.1.2 工具调用与并发空白（挑战7、8）
现象：工具池> 30 时，Agent 调错工具、参数填错、甚至捏造不存在的工具（METR 2025 实测function-calling 在30+ 工具池下错配率达18%）；多Agent 并行时三个子Agent 同时写同一个文件、重复调用同一个付费API，或本该并行的任务被串行化。
机制：Function Call 本质是概率采样，tool_name 与arguments 是token-by-token 生成，schema 约束靠prompt 描述与训练阶段对齐，工具池越大错配概率越高；MCP/Function Call 协议在调用层有JSON Schema 校验，但对"语义错误"（路径填到query 字段）无能为力。并发层面，AutoGen/CrewAI 的parallelism 主要指同时调多个LLM 实例，依赖Python asyncio，对外部副作用（文件、API、DB）没有分布式锁、事务、幂等键等基础设施；LangGraph 虽支持图，但节点间数据依赖靠state 字段共享，没引入显式资源依赖建模。
4.2.1.3 熔断与可观测空白（挑战10，挑战12）
现象：同一命令反复执行10+ 次、每次都失败但Agent 不换策略；或在两个状态间反复横跳（A→B→A→B）。这是长程任务中最浪费token 和时间的一类失败，与场景三通用推理中BrowseComp 失败样本里13% 的"循环点击同几个链接"直接对应。
机制：自回归生成的高概率重复偏置在温度低时尤其明显，上下文中"action X 失败"累积几次后，下一步最高概率token 仍可能落在X，与beam search 的mode collapse 是同一类问题；框架层缺状态指纹（visited-state hash）+ cycle detector，主流Agent loop（while not done: think→act）默认不带；重试预算与策略切换阈值未标准化，靠prompt 写"如果失败请尝试其他方法"过于软性。
现有框架为什么解不好：LangGraph 有recursion_limit 但默认25，是硬截断不是"n 次失败后换策略"；AutoGen、CrewAI 没有内置循环检测；OpenClaw 的三副本共识只防止幻觉输出，不防循环本身。归因（挑战12）在本小节先点到：要熔断得"有理由"，熔断策略的准确率直接依赖决策日志的完整度，这把线索我们在4.2.3 闭环自学习里接着讲。<mark style="background:#FFEB3B">死循环不是模型"笨"，而是框架没给Agent 装上"我是不是又回到了刚才那个状态"的元认知基础设施。</mark>
Ⅰ确定性控制小结：当前框架在确定性控制上的结构性空白有三点，一是plan 仍是prompt-as-state 不是first-class state，二是工具与并发缺乏schema + 资源DAG 的硬约束，三是死循环检测未做成默认节点。LangGraph 在前两点做得最深，国内外所有框架在第三点都欠账。
4.2.2 Ⅱ 持久化状态：让Agent 有记忆、能续跑
LLM调用是stateless API，所有"状态"都靠客户端在messages 数组里重放。长程任务跨越8 到10 步就会吃满上下文窗口，跨天跨会话则完全失忆。持久化状态支柱要回答两个问题：上下文内如何管理记忆（分层），上下文外如何延续任务（跨会话）。
4.2.2.1 分层记忆管理空白（挑战4、11）
现象：超长任务中工具返回（网页全文、代码文件、MCP 输出）全部堆进上下文，跑到一半token 爆仓；关键信息（用户早期偏好、中间结论）被挤出窗口，Agent 失忆重复询问；执行时默认文件路径存在、API 返回 JSON、网页结构不变，实际环境已变更却继续按旧假设往下走。
机制：Transformer 注意力计算复杂度O(n²)，Claude/Gemini 扩展到200k 至1M 窗口后KV-cache 显存与推理延迟仍随n 二次/线性增长，工程上必须截断或压缩；工具返回是raw blob 不是structured memory，MCP 协议返回字符串/JSON 原文，框架默认全文塞回messages 数组；MemGPT (Packer et al. 2023) / Letta 提出working memory + archival memory 分层范式，但CrewAI、AutoGen 仍以扁平message list 为主存；环境漂移（挑战11）则是训练数据时间冻结+ 缺precondition 断言原语的综合结果，ReAct 范式没把"执行前检查环境前置条件"做成标准节点。
现有框架为什么解不好：LangGraph 支持自定义reducer 做summarize-on-write，但需开发者手写，不是默认行为；OpenClaw 的Dinobase 解决了"存"的问题（12ms ACID 写入），但没解决"分层召回"，没有把"短期工作记忆/中期摘要/长期向量库"做成三档可路由；Hermes Agent 的三层记忆（短期+技能+长期）是目前最接近MemGPT 工业化的方案，但FTS5 全文搜索的召回精度受限于关键词匹配，不如稠密向量的语义匹配；环境漂移在所有框架里都是"工具返回空值就继续往下走"，没有"空结果合理性嗅探"。分层记忆在学术界已形成共识（MemGPT/Letta/Reflexion），但工业框架把它做成一等原语的只有Hermes Agent 一家，且召回精度仍是痛点；环境漂移检测则是全行业空白。
4.2.2.2 跨会话衔接空白（挑战6）
现象：任务跨天执行，重启会话后Agent 不知道昨天进度走到哪一步，产出物版本对不上；用户下一次提新需求，Agent 无法感知这是上一个长程任务的延续。
机制：LLM API 无状态决定了"状态"全靠客户端重放；主流框架以session/thread 为上下文边界，但长程任务生命周期可能跨多个session（用户重启客户端、跨设备、跨天），框架未把task 抽离成独立持久化实体（带task_id、checkpoint、产物版本指针）；checkpoint 序列化的是变量字典，不包含LLM 的隐式上下文理解，重启后"形似神不似"，需要构造一段reconstruction prompt 才能复活语义。
现有框架为什么解不好：LangGraph 的checkpointer 是当前最完整的方案，Postgres/Redis 持久化+ thread_id 恢复，但thread 仍绑定在LangGraph 的StateGraph 运行时里，跨框架迁移困难；OpenAI Assistants API 的thread 是闭源托管，迁移锁死；Hermes Agent 的FTS5 跨会话召回解决了"能查到"但没解决"怎么恢复语义上下文"；国内BISHENG 支持MySQL 流程恢复，但同样在"恢复后Agent 怎么续跑"上依赖开发者写恢复prompt。跨会话衔接的真正痛点不是"存不存得下"，而是"恢复后LLM 的语义连续性如何保证"，这需要框架层提供标准化的reconstruction prompt 模板+ task_id 优于session_id 的一等实体地位，目前没有框架完整做到。
Ⅱ持久化状态小结：分层记忆有学术范式但工业落地只有Hermes Agent 一家像样；跨会话衔接LangGraph 做到了"存得下"但没做到"接得上"；环境漂移在全行业是空白。持久化状态这根支柱整体比确定性控制更薄，也是新一代框架相对传统框架唯一的真正优势面。
4.2.3 Ⅲ 闭环自学习：让Agent 自己发现错、沉淀经验
LLM推理时参数冻结，"学习"无法通过梯度回流沉淀，只能靠框架在外部搭一套"执行→反思→归因→沉淀→复用"的闭环。这一支柱包含三环：中途自验证（挑战9）、事后归因（挑战12）、经验沉淀（挑战5）。
4.2.3.1 自验证缺失（挑战9）
现象：Agent 执行过程中出错（脚本报错、网页弹错、数据不合理）但继续往下走，最终拿着错误中间结果产出看似完整实则错误的报告；用户验收时才暴雷。场景一编码中SWE-bench Pro 失败样本里34% 属于此类。
机制：RLHF 阶段奖励模型偏好"看起来完成"的回答，模型对自己输出的置信度普遍高估（calibration error）；生成与判别能力不对称，让同一模型既执行又验证等于让作家给自己批改作业；ReAct 范式只给统一Thought-Action-Observation 循环，没有按任务类型（编码→跑测试、GUI→截图回读、研究→交叉源核对）挂载验证器；即便外接evaluator，多数框架默认continue 不做熔断。
现有框架为什么解不好：LangGraph 的verify 节点需开发者手写，非默认；CrewAI 的validation_hook 覆盖粒度是任务级不是步骤级；OpenClaw 的三副本共识是"三个我互相对答案"，无法引入独立critic；Hermes Agent 的自优化依赖任务完成后的成败信号，不做步骤内熔断。自验证的关键是"类型化验证契约+ 独立critic + 分数阈值绑定熔断"三件事，目前没有框架把这三件事做成默认挂载项。
4.2.3.2 归因与可解释缺失（挑战12）
现象：任务失败后用户问"为什么失败在第8 步"，Agent 只能给出最后一步的错误，不能回溯是哪一步的前置决策导致了后续连锁失败；复盘30 步日志靠人工。
机制：Transformer 的每步action 选择是数十亿参数的非线性映射结果，事后无法精确归因到"哪个token、哪个工具返回值"主导了决策，attention weights 可视化只是相关性不是因果性；主流框架默认记录messages 与tool_calls 原文，不强制记录"当时考虑的可选分支+ 选择理由"；CoT 是后验合理化（post-hoc rationalization，Anthropic 2023 实证），与实际决策路径未必一致；要做归因需把所有步骤构成因果DAG，框架虽有执行trace 但少做因果建模。
现有框架为什么解不好：LangSmith 是目前trace 最深的工具，但它记录IO 不记录"当时的备选方案与选择理由"；OpenTelemetry（OpenClaw、BISHENG 都用）是通用可观测协议，对LLM 决策过程的语义注释有限；Hermes Agent 的集中日志可查但不是因果DAG。归因差不仅让复盘难，还进一步恶化自验证（没有归因就没法针对性加verify 节点）和经验沉淀（沉淀什么都不知道）。归因是闭环自学习的中枢，归因链路断了，verify 和经验沉淀都成了无根之木；目前业界的执行trace 都是"事实日志"，不是"决策日志"，全行业欠债。
4.2.3.3 经验沉淀缺失（挑战5）
现象：同一个错误本轮犯第3 次；跨会话、跨任务完全独立，上次解决过的问题下次从零摸索；用户纠正过的偏好下次又忘。
机制：参数冻结让经验无法梯度回流；in-context learning 是瞬时学习不是持久学习；Reflexion (Shinn et al. 2023) 提出reflection-as-a-node 范式，但LangGraph/CrewAI 未将"任务结束后的post-mortem → 经验库写入"做成默认节点；经验抽象层级缺失，把"具体错误"抽象为"可复用方法论"需要更高层归纳能力，无监督下LLM 做抽象稳定性差。
现有框架为什么解不好：Hermes Agent 是唯一内置闭环学习的框架，任务完成后自动提炼技能、技能使用后自动优化，但受限于FTS5 召回精度和抽象层级的不稳定性，有"把错误也固化成技能"的风险（正面信号不足时，技能库会积累伪经验）；OpenClaw 明确放弃闭环学习主攻执行稳健性；LangGraph、CrewAI、AutoGen 全部需要开发者自己编排Reflexion 节点，实际部署中几乎缺席；国内框架在经验沉淀上全部是空白。Hermes Agent 证明了经验沉淀可工业化，但它的"伪经验堆积"风险提醒我们：没有Ⅲ 的前两环（自验证+ 归因），经验沉淀就是错误的固化。闭环自学习必须三环同做，不能只做末端。
Ⅲ闭环自学习小结：自验证、归因、经验沉淀是三位一体，任何一环缺失其余两环都失效。目前自验证靠开发者手写、归因全行业是"事实日志非决策日志"、经验沉淀只有Hermes Agent 一家做成默认项且有伪经验风险。这根支柱是三项里最薄的，也是国内外差距最小（大家都没做好）但天花板最高的。
4.2.4 横切关注点：HITL 与安全资源
前三项支柱在"让Agent 跑下去"的维度展开，但长程任务还有两类跨支柱的横切需求必须照看：人在什么时候介入、什么操作不许Agent 自己做主、钱和时间什么时候必须熔断。这两类不构成独立支柱，但在Ⅰ/Ⅱ/Ⅲ 任一支柱上都得考虑。
4.2.4.1 HITL断点分级（挑战13）
现象：要么完全不打断Agent 自己闷头跑2 小时跑偏，要么每一步都问"确认吗"用户疲于点按；关键决策（删库、发邮件、下单）却没卡点。
机制：LLM 无可信的置信度自报机制，softmax 概率与真实正确率弱相关；风险评估需要预先定义工具风险等级表（rm/DROP/push --force = 高危），框架默认不带这套元数据；流式中断协议（pause/edit/resume）需要双向通信，OpenAI Assistants API、LangGraph Server 虽支持interrupt 但UI/UX 模式没有事实标准，多数产品落地为"全YOLO 或全确认"两个极端；RLHF 训练目标偏向自闭环，模型被奖励"完整完成任务"，主动求助反而被视为"没完成"。
现有框架为什么解不好：LangGraph 的 interrupt_before/interrupt_after 是目前最细粒度的原生HITL，但仍需开发者指定哪些节点要断点；OpenAI Assistants API 的require_action 是任务级不是节点级；OpenClaw 无原生HITL；Hermes Agent 有审批按钮但粒度粗；国内BISHENG 的审批节点是流程预设不是基于置信度的动态触发。HITL 的正解是"风险等级× 置信度× 不可逆性"三维打分路由，目前所有框架都停留在"开发者手动指定断点"的一维决策。
4.2.4.2 安全与资源熔断（挑战14、15）
现象：Agent 执行`rm -rf`、`DROP TABLE`、`git push --force`、调用付费API、发送外部邮件时与执行`ls`、`grep` 采用同一套流程，没有额外确认；或一旦开YOLO 模式全面放权；或一个长程任务跑完烧了$50 Token 或4 小时还没完，跑到一半用户想终止不知道进度和已花费。
机制：MCP/Function Call 协议无 capability 分级字段，tool schema 只描述功能与参数，没有标准的risk_level / reversibility / side_effect_scope 元字段，框架无法据此自动套用差异化策略；沙箱化代价高，多数Agent 产品在效率压力下选择"全开沙箱"或"全限制只读"；LLM 推理成本与token 数线性相关、与思考深度指数相关，长上下文+ 多轮ReAct + CoT 叠加单任务token 消耗很容易突破百万级；框架普遍只做事后计费日志，不做事前预估与事中熔断（达到 80% 预算时强制压缩或降级）；递归调用中主Agent 调子Agent 调孙Agent 呈树形爆炸；缺少模型路由，多数项目全程用旗舰模型。
现有框架为什么解不好：LangGraph 的config.recursion_limit 是硬截断不是预算；OpenAI Agents SDK 的guardrails 主要做内容合规不做成本控制；OpenClaw 的agent.yaml 可声明白名单但执行时行为仍由模型决定；Hermes Agent 有子Agent 隔离但无三维预算；行业普遍缺"两阶段提交"（先dry-run 预览再commit），不可逆操作的回滚困难。基于SWE-bench Pro 实测成本，Claude 每成功任务$20.5、GPT $36.4，这个数字在没有成本熔断的前提下随长度线性放大。安全与资源熔断的正解是capability 分级元字段+ 三维预算原语+ 两阶段提交+ 模型路由四件套，目前没有任何框架同时提供其中两件以上。
4.3 结构性空白总览
4.3.1 三项空白诊断矩阵
支柱\ 框架 | LangGraph | AutoGen | CrewAI | OpenAI Agents | OpenClaw | Hermes Agent | BISHENG | AgentScope |
Ⅰ 确定性控制 | ✓(DAG+state) | △(对话式弱) | △(YAML 粗) | △(轻量) | ✓(三副本) | △(自主式) | ✓(流程节点) | △(消息驱动) |
Ⅰ.1 规划稳定性 | ✓ | ✗ | △ | △ | △ | △ | ✓(预设流程) | △ |
Ⅰ.2 工具/并发 | △(无资源DAG) | △ | △ | ✓(guardrails) | △ | △ | △ | △ |
Ⅰ.3 熔断/归因 | △(recursion_limit) | ✗ | ✗ | △ | △ | △ | △ | ✗ |
Ⅱ 持久化状态 | ✓(checkpointer) | ✗ | ✗ | ✗ | ✓(Dinobase) | ✓(三层) | ✓(MySQL) | ✗ |
Ⅱ.1 分层记忆 | △(需手写) | ✗ | ✗ | ✗ | △(单层) | ✓(三层) | ✗ | ✗ |
Ⅱ.2 跨会话衔接 | ✓(thread_id) | ✗ | ✗ | △(thread 闭源) | ✓ | ✓(FTS5) | △ | ✗ |
Ⅱ.3 环境漂移检测 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
Ⅲ 闭环自学习 | ✗ | ✗ | ✗ | ✗ | ✗ | △(有伪经验风险) | ✗ | ✗ |
Ⅲ.1 自验证 | △(需手写) | ✗ | △(任务级) | △(guardrails) | △(三副本) | △ | △ | ✗ |
Ⅲ.2 归因 | △(LangSmith IO) | ✗ | ✗ | △(tracing IO) | △(OTel IO) | △(集中日志) | △ | ✗ |
Ⅲ.3 经验沉淀 | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✗ |
横切HITL | ✓(interrupt) | △ | △(hook) | △(require_action) | ✗ | △(审批) | ✓(审批节点) | △ |
横切 安全/资源 | △(recursion) | ✗ | ✗ | △(guardrails) | △(沙箱) | △(子Agent 隔离) | △ | ✗ |
场景 | 典型失败现象 | 主要映射支柱 | 次要映射支柱 |
场景一 编码 | SWE-bench Pro 34% 失败是"测试没跑就交" | Ⅲ.1 自验证 | Ⅰ.1 规划稳定性 |
场景一 编码 | METR Time Horizon 8 到10 步崩溃 | Ⅰ.1 规划稳定性 | Ⅱ.1 分层记忆 |
场景二GUI | Online-Mind2Web 10 步后衰减加剧 | Ⅰ.1 规划稳定性 | Ⅰ.3 熔断 |
场景二GUI | 同一按钮反复点击不换策略 | Ⅰ.3 熔断(死循环) | Ⅲ.2 归因 |
场景三 通用推理 | BrowseComp 循环访问同几个链接 | Ⅰ.3 熔断 | Ⅲ.3 经验沉淀 |
场景三 通用推理 | 研究任务跨天重启完全从头 | Ⅱ.2 跨会话衔接 | Ⅲ.3 经验沉淀 |
跨场景 | 同一错误反复犯 | Ⅲ.3 经验沉淀 | Ⅲ.1+Ⅲ.2 |
跨场景 | 成本失控 | 横切 安全/资源 | Ⅰ.3 熔断 |
4.3.3 为什么单点改进不足，必须三项一起补
三项支柱的依赖关系是闭环而非并列：
1、没有Ⅰ 确定性控制：Agent 的执行轨迹就是混乱的，Ⅱ 记住的是错误的状态，Ⅲ 学到的是错误的经验。场景一的"测试没跑就交"沉淀进技能库，下次还照做，这就是典型的"错误固化"。
2、没有Ⅱ 持久化状态：Ⅰ 的熔断检测没有跨会话的状态指纹，Ⅲ 的归因没有历史轨迹可回溯，闭环学习的数据基础就是空的。
3、没有Ⅲ 闭环自学习：Ⅰ 的规则永远靠人写死（每增加一个工具都要手写validation），Ⅱ 的记忆也只能"原封不动地记"不能"提炼性地记"，框架的边际效用递减到零。
LangGraph在Ⅰ+Ⅱ 上做得最深但丢Ⅲ，Hermes Agent 在Ⅱ+Ⅲ 上做得最深但丢Ⅰ，OpenClaw 只做Ⅱ。整个框架生态没有一个产品同时在三项上做到一等原生。下一阶段框架竞争的主战场，不是"谁的工具集成更多"，而是"谁能同时做到确定+ 持久+ 自学习"。
4.4 场景小结
1、框架生态的核心结构性空白是三项：确定性控制、持久化状态、闭环自学习。前三场景所有失败现象（编码8 步崩溃、GUI 10 步衰减、通用推理循环点击）归并后收敛到这三项+ 两类横切（HITL、安全/资源），没有任何一个框架同时覆盖这三项。
2、传统框架与新一代框架呈互补而非替代。LangGraph 在Ⅰ+Ⅱ 最扎实，Hermes Agent 在Ⅱ+Ⅲ 最前沿，OpenClaw 只做Ⅱ，其余框架都是偏科生。企业生产部署目前最稳妥的组合仍是LangGraph + 自建经验库，而不是押注任何单一新一代框架。
3、Ⅲ 闭环自学习是短板中的短板，也是天花板。自验证、归因、经验沉淀三环缺一不可，目前自验证靠开发者手写、归因全行业是"事实日志非决策日志"、经验沉淀只有Hermes Agent 一家像样且有伪经验风险。谁能在Ⅲ 上做出可工程化、可审计、不产生伪经验的闭环，谁就占下一代框架生态的入口。
4、国内框架主要补位在Ⅰ 的预设流程上。BISHENG 用企业流程编排切金融央企场景，AgentScope 走消息驱动学术路线，但两者在Ⅱ 的分层记忆、Ⅲ 的闭环自学习上与国外差距明显。Manus 类产品封闭生态难以评估。
5、横切关注点（HITL + 安全资源）全行业欠债最严重。LangGraph 的interrupt 是节点级断点但不是置信度路由；capability 分级元字段、三维预算原语、两阶段提交、模型路由这套成本与安全基础设施没有任何框架完整提供。这是89% 企业Agent 项目失败里"不敢上生产"那部分的直接原因。
6、框架层不补齐，模型再强也白搭。Claude Opus 4.7 的SWE-bench Verified 已做到87.6%，但SWE-bench Pro 仍只有49.8%，中间丢失的38 个百分点一半来自模型能力，一半来自框架没能把模型的不足兜住。这是本章想传达的核心判断：模型是组件，框架是系统，长程任务的天花板在系统。
