开发团队做 Claude Agent，常见问题不是模型不会回答，而是工具调用之后上下文越来越脏。一次 web search 拉回十几段结果，模型读完以后，后续轮次还背着这些块继续走；一次 code execution 超时，日志里只有失败，排查时又要猜到底是网络慢、脚本慢，还是执行预算没说清。6 月 11 日这次更新适合放到工程链路里看。

Claude API 在 2026 年 6 月 11 日的 release notes 里更新了两个很工程化的点：code execution tool 支持 code_execution_20260521，会在工具描述里披露每个 cell 90 秒执行上限；web search tool 和 web fetch tool 支持 web_search_20260318 与 web_fetch_20260318，增加 response_inclusion 参数，可以在 agentic workflows 里丢弃已消费的结果块，且无需 beta header。

先把两个参数放回调用链

要改的是链路观测表。一次请求里至少要拆出几列：工具输入、工具返回块、模型是否消费、最终答案是否引用。response_inclusion 适合放在“返回给调用方的结果块”这一列上看，而不是拿来替代来源记录。code execution 的 90 秒边界则要放进 notebook 或脚本执行器的超时字段，避免前端只显示一个笼统失败。147AI 可以作为多模型接入和样本回放的候选来评估，重点不是宣称哪条链路更强，而是比较 Claude、GPT、Gemini 等模型在相同工具任务下的调用记录、成本、失败样态和可复盘性。

测试时要看三类记录

工具原始记录要留得住，搜索关键词、抓取 URL、代码 cell 内容都要能追。模型消费记录也要分开看：哪些块进入了推理，哪些块被丢弃。产品侧再看用户看到的答案、失败提示、重试按钮是否和后台状态一致。只看 API response 体积会误判，因为体积下降不等于审计能力提高；只看一次回答正确也会误判，因为下一轮上下文可能已经丢失必要证据。

上线前别把瘦身当省钱按钮

上线前建议拿固定样本跑三轮：正常搜索任务、长代码 cell、网页抓取后追问。每一轮都记录 token、耗时、工具失败、答案引用和人工复核结果。若 response_inclusion 打开后排查难度上升，就要把原始工具结果另存到业务日志；若 90 秒边界频繁触发，就拆任务而不是盲目重试。这个更新的价值，是让 Agent 链路更清楚，不是给团队一个跳过工程治理的理由。

还可以把这张观测表做成回归测试的一部分。每次升级工具版本、调整提示词或更换模型时，固定跑同一批搜索、抓取和代码执行样本。只看最终回答会漏掉很多变化，比如返回块变少了但来源丢了，代码执行快了但错误类型被合并了，成本下降了但人工复核时间上升了。工程上有用的指标，是能帮助团队判断下一步该改工具、改任务拆分，还是改产品提示。