AI Digest 日报 · 2026/05/07

Agent 的竞争，开始拼容量、验收和长期状态。

从单次对话，走向可调度、可评估、可复盘的工作系统。

今天的主线很清楚：Agent 能力不再只看模型聪不聪明，还要看算力供给是否稳定、任务完成后有没有独立验收、跨会话经验能否沉淀，以及团队是否把 AI 当成可调度的生产容量。

今日关键词

算力容量 Agent 验收多 Agent 模型成本工作流资产

Anthropic + SpaceX：算力正在变成 Agent 产品体验的一部分

Anthropic 宣布获得 SpaceX 计算资源支持，并同步提高 Claude Code 和 Opus API 使用额度：Claude Code 的五小时窗口限额翻倍，Pro/Max 的高峰期限制取消，Opus API 限额也上调。源材料提到 Colossus 1 的 300MW+ 与 22 万块 GPU 量级，公开报道可确认这条算力合作和额度调整，估值数字则不宜作为硬结论写入正文。

为什么值得看

01 · 限额就是产品能力的一部分 当开发者把 Claude Code 当成持续执行的工程 Agent，五小时窗口、峰值限制和 API 配额会直接影响任务能否跑完。AI 工具采购不能只看模型效果，也要看稳定额度、并发能力和故障时的替代方案。

02 · 关键供应商依赖要提前管理 如果内部研发、客服知识库、测试脚本和售前材料都绑定单一模型或平台，限额变化会变成组织级风险。更稳妥的路线是按任务重要性分层，保留可切换的模型和队列策略。

03 · 算力扩张会反推更多并发用法 额度放宽后，团队会更自然地同时跑代码审查、缺陷复盘、文档生成和测试补全。真正要补的是任务编排、优先级、日志和验收，而不只是给每个人多开几个窗口。

可落地动作

建议把常用 AI 工具按“个人效率、团队流程、生产依赖”分级，分别设定额度监控、替代模型、排队规则和成本上限。

Claude Managed Agents：验收、复盘和多 Agent 成为标配能力

Anthropic 在 Claude Managed Agents 中推出 dreaming、outcomes、multiagent orchestration 和 webhooks。Dreaming 仍是研究预览，用于跨历史会话复盘模式；Outcomes 让独立 grader Agent 按 rubric 判断任务是否完成；Multiagent 让主 Agent 拆分任务并调度多个专门 Agent。官方材料称 outcomes 在内部测试中最高带来 10 个百分点的任务成功率提升。

Agent 工程启发

01 · 结果验收要独立出来 客服总结、销售资料、测试报告和需求文档都适合引入 grader 模式：先定义好成功标准，再让执行 Agent 和验收 Agent 分工，减少“看起来完成了”的假阳性。

02 · 复盘机制比提示词更持久 单次 prompt 优化解决的是眼前任务，跨会话复盘解决的是重复错误。设备售后、渠道问答、安装指导这类场景，应记录失败模式、用户追问和人工修正，让下一轮流程变聪明。

03 · 多 Agent 适合复杂排查，不适合所有任务 日志、版本、工单、监控和代码历史需要并行排查时，多 Agent 很有价值；简单问答强行拆分反而增加成本。关键是按任务复杂度决定是否委派。

可落地动作

挑一个内部高频流程试点 outcomes：例如安装问题诊断、售后工单摘要或 PR 评审，先把 rubric 写出来，再让 Agent 按标准交付。

GPT-5.5：模型选择开始进入“性能 / 成本 / 任务类型”组合题

OpenAI 官方发布 GPT-5.5，强调它在 Codex 和 ChatGPT 中面向复杂软件工程、计算机使用和知识工作任务增强。公开基准显示，GPT-5.5 在 Terminal-Bench 2.0 为 82.7%，GDPval 为 84.9%，并且 OpenAI 称其在 Codex 中通常能用更少 token 完成更好结果。源材料里的 ARC-AGI-2 与“低于 Claude Opus 4.7 30%”未在官方页直接对应，适合作为待观察口径处理。

采购和使用启发

01 · 不要用一个模型回答所有问题 代码修改、需求分析、表格整理、客服话术、知识库检索对模型要求不同。按任务建立模型路由，比固定押注“最强模型”更容易控制成本和稳定性。

02 · token 效率要纳入真实账本 企业看成本不能只看百万 token 单价。一次任务需要几轮、是否返工、能否自动调用工具、上下文是否被重复塞入，都会决定最终成本。

03 · 工程生产力更需要横向对比 如果用于代码库修改、测试生成和发布说明，评测应覆盖本公司真实仓库、真实约束和真实失败样本。公开榜单只能做初筛，不能替代内部试跑。

可落地动作

建议建立一张内部模型任务矩阵：列出代码、文档、客服、数据分析、知识库五类任务，记录准确率、返工率、耗时、token 和人工验收成本。

从 Claude Code 到 Harness：Agent 要像容量资源一样被调度

源材料把 Boris Cherny 的手机 Claude Code 用法、Claude Code 2.1.132 版本更新，以及 Inner Loop / Outer Loop 的 Harness 框架放在同一条线上。可确认的是 Claude Code 2.1.132 增加了会话 ID 和 alternate screen 控制等工程细节；更大的信号是，Agent 正从“开一个聊天窗口”走向并发任务、可恢复状态、工具超时处理和跨会话学习。

工程化重点

01 · Inner Loop 决定单次任务可靠性 模型、工具、上下文和错误恢复构成一次任务的执行闭环。只要工具超时、权限缺失或上下文溢出没有处理好，Agent 就会在关键节点卡住。

02 · Outer Loop 决定组织是否真的变聪明 售后故障、安装问题、渠道话术、代码审查都需要把经验沉淀下来。没有跨会话状态，Agent 每次都像第一次上班，只是速度更快。

03 · 并发任务需要队列和人类验收 同时跑 10 个任务很诱人，但产出最终会挤到人类这里。要提前定义优先级、失败提示、人工确认点和结果归档方式。

可落地动作

为内部 Agent 试点补齐四个字段：任务状态、失败原因、恢复路径、验收人。先把任务跑完的路径看清，再追求更复杂的自治。

3DGenStudio 与 llm_wiki：工作流资产开始被 AI 接管

3DGenStudio 把 ComfyUI、外部 API、图像生成、网格生成、UV、贴图和资产库整合进可视化工作区；llm_wiki 则把 Karpathy 的 LLM Wiki 方法落成开源个人知识库工具。两者虽然一个偏 3D 资产、一个偏知识管理，但共同点是把“零散生成”变成可追踪、可复用、可迭代的工作流资产。

对产品和组织的提醒

01 · 3D 内容流水线会影响产品表达效率 智能家居的 App 引导、安装说明、营销物料和空间方案都需要大量设备与场景资产。AI 3D 工具短期更适合概念图、方案预览和素材打样，生产级资产仍要经过设计与工程清理。

02 · 企业知识库要从检索变成维护 LLM Wiki 的价值不只是问答，而是让 AI 帮忙整理、更新、去重和连接知识。安装手册、FAQ、培训材料和故障案例都适合先做小范围 wiki 化。

03 · 资产系统要留下版本和来源 不管是 3D 模型还是知识条目，AI 生成后都要能追踪来源、版本和审核状态。否则素材越多，后续复用和合规确认越麻烦。

可落地动作

建议选择一个窄场景试点：例如“安装培训素材库”或“售后故障知识 wiki”，先把来源、版本、审核人和复用入口设计清楚。