SemiAnalysis 指出 Agentic Coding Harness（如 Claude Code、Codex、OpenCode）本质是上下文编排工具，而非智能本身。其核心机制基于 LLM 的无状态特性，通过 REST 循环和 JSON Schema 实现：Harness 在每轮请求中组装系统提示、工具定义和消息历史，通过 HTTP POST 调用 LLM，模型返回工具调用意图后由本机执行并回填结果。不同 Harness 的差异仅在于上下文管理策略和 TUI/UX 设计，智能上限由底层模型决定。 核心观点： 1. LLM 无状态，Harness 必须在每轮请求中完整重建系统提示、工具定义和消息历史。 2. 工具执行发生在用户本机，LLM 仅返回 JSON 意图，攻击面在于本机执行环节。 3. 不同 Harness（Claude Code、Codex、OpenCode）的差异仅在于上下文管理策略和 TUI/UX，不决定智能上限。
Armin Ronacher 发现新版 Claude 模型（Opus 4.8、Sonnet 5）在调用 Pi 编辑工具时，会在嵌套的 edits[] 数组中凭空捏造 schema 中不存在的字段（如 requireUnique、oldText2、type 等），导致工具调用被拒绝。尽管实际编辑内容正确，但模型会添加多余键值。该问题在旧版模型中不存在，且与上下文相关：在智能体历史对话中复现率约 20%，去掉 thinking blocks 后减半，开启严格工具调用后消失。Ronacher 推测这是后训练阶段针对 Claude Code 生态优化的副作用——Claude Code 的客户端会容忍并修复格式错误，导致模型学会在宽松环境下产生“格式垃圾”。这对开发者意味着：若工具 schema 与 Claude Code 不一致，新版模型可能更不忠实于格式，需要更严格的约束解码或工具调用验证。 核心观点： 1. Opus 4.8 和 Sonnet 5 在 Pi 编辑工具调用中会凭空添加 schema 中不存在的键（如 requireUnique、oldText2、type、id、kind 等），而旧版模型无此问题。 2. 该问题在智能体多轮对话中复现率约 20%，去掉 thinking blocks 后减半，开启严格工具调用后完全消失。 3. Ronacher 推测后训练阶段针对 Claude Code 的宽松工具调用生态（自动修复格式错误）是导致模型产生格式垃圾的根本原因。
Anthropic 发布 Claude Sonnet 5，定位为迄今最具智能体能力的 Sonnet 模型，在推理、工具使用和编码方面显著提升，性能接近 Opus 4.8 但价格更低。该模型已全面上线，成为 Free 和 Pro 计划的默认模型，并可通过 Claude API 使用。开发者可调整 effort 级别以平衡成本与性能，对构建复杂多步任务的智能体应用具有重要价值。 核心观点： 1. Sonnet 5 在 BrowseComp 和 OSWorld-Verified 等智能体评测中，通过调整 effort 级别可在部分任务上匹配 Opus 4.8 的性能。 2. Sonnet 5 引入新 tokenizer，输入 token 数约为之前的 1.0–1.35 倍，但通过定价调整实现大致成本中性。 3. Sonnet 5 的网络安全任务能力远低于当前 Opus 模型，整体不良行为率低于 Sonnet 4.6。