Agent 实践
Claude 4 与 Claude Code GA：Coding Agent 交付的不是一次补全
以 2025 年 5 月 22 日至 24 日的公告与 API 快照为边界，区分 Claude 4 模型、Claude Code GA、IDE 与 GitHub beta、工具和 MCP connector，并给出长任务 Coding Agent 的工程验收方法。
时间与证据
本文采用的事件日是 2025 年 5 月 22 日。Anthropic 当天发布 Claude Opus 4 与 Claude Sonnet 4，并宣布 Claude Code 核心产品 generally available。同期信息截止日是 5 月 24 日；固定证据包括发布日公告、发布日存档、API Release Notes 的 5 月 22 日条目和 5 月 23 日页面快照。文章发布日期与更新日期见页首。
这个事件包含两个不同交付对象：模型通过 Anthropic API、Amazon Bedrock 和 Google Cloud Vertex AI 提供；Claude Code 则从 2 月 24 日的 limited research preview 进入核心产品 GA。公告同时把 VS Code 与 JetBrains 扩展、Claude Code on GitHub 标为 beta。不能把一句 “Claude Code GA”扩写成所有入口、集成和 API 工具都正式稳定。
API Release Notes 进一步记录：interleaved thinking、Files API、code execution tool 与 MCP connector 均在 public beta；Claude 4 的 extended thinking 默认返回摘要，完整 thinking 以加密形式进入签名字段。上述 beta 功能可以实验，不能在 T+2 被写成无条件生产承诺。
本文证据等级为 sourced。SWE-bench、Terminal-bench、数小时运行与客户评价均来自 Anthropic 公告或其引用，未在本站相同 scaffold 下复测。本文讨论的是如何验收 Coding Agent，不声称已让 Claude Code 在真实仓库持续运行。
当时发生了什么
两个模型、两种预算、多个渠道
Claude Opus 4 与 Sonnet 4 都被定义为 hybrid models，可选择近即时响应或 extended thinking。公告给出的首发价格保持在 Opus 4 每百万输入/输出 Token 15/75 美元、Sonnet 4 为 3/15 美元，并说明两者通过 Anthropic API、Bedrock 与 Vertex AI 可用。Claude 的 Pro、Max、Team、Enterprise 计划包含两种模型和 extended thinking，Sonnet 4 也向免费用户提供。
这意味着企业选型至少有两个维度：模型档位决定能力与 Token 单价，thinking 预算决定同一模型在复杂任务上的时延与输出。不能用“Opus 更强”替代任务路由，也不能只比较每百万 Token 单价。长任务还会调用搜索、编辑、测试和外部服务，最终成本是整条轨迹的模型调用、工具资源、失败重试与人工复核。
工具间思考改变了 Agent 循环
公告称两种模型可在 extended thinking 期间使用工具，并支持并行工具调用。API Notes 把 interleaved thinking 标为 public beta，需要 interleaved-thinking-2025-05-14 beta header。其工程含义是模型可以在工具结果返回后继续推理，而不是先生成完整计划再机械执行全部步骤。
这更适合代码任务：读取文件后发现依赖、运行测试后得到错误、再修改下一步。但每增加一轮就增加状态、费用与失败点。模型是否“会在工具之间思考”不等于它知道哪些命令有权执行；工具许可、工作目录、网络、秘密和超时必须由外部控制面决定。
API Notes 还把 code execution tool 描述为安全沙箱中的 Python 执行，并把 MCP connector 描述为从 Messages API 连接远程 MCP server 的 beta 功能。它们是厂商提供的执行与连接组件，不会自动继承企业 RBAC、租户隔离和变更审批。
Claude Code GA 的核心是任务循环，周边仍分阶段
Claude Code 从命令行研究预览进入 GA，公告把 terminal、IDE 与后台 SDK 工作流放在同一开发体验中。不过边界必须逐项写：VS Code 与 JetBrains 是新 beta 扩展；Claude Code on GitHub 也是 beta；SDK 被发布用于构建使用同一核心 Agent 的应用。核心 GA 不等于代码开源，也不等于 GitHub App 可以无人值守合并。
从工程角度，Coding Agent 与传统补全最大的差异是它维护任务状态并反复执行：理解目标、读取仓库、编辑多个文件、运行命令、观察失败、修正方案、提交证据。最终产品不是一段代码，而是一条可检查的变更轨迹。
官方 Benchmark 不能脱离 scaffold
Anthropic 公告报告 Opus 4 在 SWE-bench Verified 为 72.5%、Terminal-bench 为 43.2%，Sonnet 4 在 SWE-bench 为 72.7%。这些是 vendor-reported。附录说明 SWE-bench 使用 bash 与基于字符串替换的文件编辑工具，并对 full 500 problems 报告；高计算结果又加入多次并行尝试、可见回归测试过滤和内部评分模型选优。
因此裸数字不能回答企业仓库任务。模型、工具、最大步数、并行采样、测试过滤和选择器共同决定结果。把高计算分数与一次普通 API 调用比较，或者把官方 scaffold 成绩写成本站 Agent 成绩，都会错误归因。
公告还引用客户对长时间任务的评价，并称 Opus 4 可持续工作数小时。这是值得验证的方向信号，不是 SLA。长时间不退出既可能代表持续推进，也可能代表循环、误修改或等待；生产指标必须关注有效进展和可恢复性。
任务判断
假设一家 SaaS 公司要把 12 个服务从旧鉴权 SDK 迁移到新版本。Agent 可以建立分支、修改代码、运行测试和生成 PR 描述，但禁止访问生产秘密、修改 CI 权限或直接合并。任务成功标准是全部目标服务完成编译与测试、行为契约不变、每项关键修改有证据，最终由代码所有者审批。
一个可信评测集应选取 30 个已经由工程师完成的历史迁移，保留任务描述、基线 commit、隐藏测试和真实 diff。比较 Sonnet 4、Opus 4 与当前工具的结果时，至少记录：
- 完整任务通过率，而不是生成片段是否可读。
- 首次测试通过率、最终隐藏测试通过率与新增回归数。
- 无效工具调用、超时、重复编辑、回滚和人工接管次数。
- 修改文件精确率，是否触碰任务之外的配置或秘密。
- 总完成时间、P95、输入/输出 Token、工具成本和每个正确 PR 的总成本。
- 审查者接受、要求修改或完全重做的比例。
评测必须固定基线 commit、容器、依赖缓存、网络策略、系统提示、工具版本和最大步数。否则同一模型在不同环境下的差异会被误判为模型能力。本文没有执行该实验，所以不提供虚构通过率。
路由上，常规迁移可以先用 Sonnet 4；只有在依赖复杂、连续失败或高价值任务中，才升级到 Opus 4 或更高 thinking 预算。升级条件由任务状态与测试信号触发，不由模型一句“这个问题很难”触发。
工程影响
把 Agent 建模为可恢复状态机
长任务不应存在于一个不可恢复的聊天进程。状态至少包含任务 ID、基线 commit、计划、已授权工具、每步输入输出、工作树 diff、测试结果、预算和审批状态。每次高影响动作前生成 checkpoint；进程退出后能够从确定状态恢复，而不是重新让模型猜测进度。
推荐的状态转换是：planned -> approved -> executing -> verifying -> review_ready，并允许进入 needs_input、budget_exhausted、policy_denied、failed 和 rolled_back。模型提出动作，策略层决定是否允许，执行器在隔离环境中运行，验证器读取真实结果。把这四个角色放在一个 Prompt 中，会让自然语言同时承担计划、权限和事实判断，难以审计。
工具层采用最小权限与显式审批
代码读取、搜索和测试可以默认授予任务工作区；依赖安装、网络访问、修改 CI、删除文件、访问秘密和发布制品需要更高权限。审批令牌应绑定任务、用户、工具、参数摘要、仓库、基线版本和有效期，不能把一次“允许”变成永久通配符。
并行工具调用也要受资源与冲突控制。两个测试可以并行，两个同时修改同一工作树的命令则可能互相覆盖。执行器需要声明读写集合、工作目录与超时；冲突动作串行化。模型的并行能力只是调度建议，不是事务隔离。
证据链比推理文本更重要
Claude 4 的 thinking 默认可能返回摘要，完整内容以签名字段形式存在，这本身提醒系统：不要依赖完整 chain-of-thought 作为产品功能。审查者真正需要的是任务目标、修改 diff、工具命令、测试输出、静态检查、未解决风险和模型版本。
每条 Agent 结论应链接到可复现对象。例如“鉴权行为保持不变”必须对应契约测试；“旧 API 已清除”对应搜索命令和结果；“所有服务通过”对应每个 job 的退出码。推理摘要可以帮助理解，不能取代这些证据。
GA 仍需要企业自己的发布门禁
厂商 GA 表示产品成熟度迈过一个阶段，不代表它自动符合每家公司的安全、合规和可靠性标准。企业上线仍要经过离线回放、只读 shadow、沙箱写入、人工审批 PR 与有限仓库灰度。IDE、GitHub、MCP 和代码执行处于 beta 时，尤其应分别建立开关和回退，不把整条工作流绑定在一个 beta 组件上。
传统全栈能力在这里重新组合：Git 分支和 CI 成为 Agent 事务边界；RBAC 变成工具策略；数据库保存长期任务与幂等状态；队列处理长任务和重试；前端展示执行轨迹与审批；可观测性聚合模型、工具和测试三类事件。
商业价值
最可能付费的是拥有大量重复维护、测试基础较好、代码所有权清晰的软件团队。Coding Agent 能增强依赖升级、重复迁移、测试补齐、故障定位和 PR 准备。价值不是“少写几行代码”，而是缩短从 issue 到可审查变更的等待时间，并让工程师把注意力放在架构、风险与最终决策上。
收益应以 每个被合并且未引入回归的任务成本衡量。模型 Token 只是一个分项；还包括沙箱计算、CI、工具服务、失败重跑、审查时间和事故成本。Opus 4 单价高于 Sonnet 4，但若在少量复杂任务上显著减少重试和人工接管，单位成功成本仍可能更低；反之，全量用最高档模型会浪费预算。
90 天 MVP 应选重复、可回滚、有隐藏测试的仓库维护任务。第一阶段只生成计划与 diff；第二阶段允许沙箱执行测试；第三阶段让少量团队通过 PR 审批使用。成立条件是合并周期缩短、审查返工不增加、回归率不升高，且单位成功成本可接受。失效条件包括测试覆盖不足、秘密与权限无法隔离、Agent 经常修改范围外文件，或维护评测与工具的成本高于节省的人力。
不适合优先自动化的是生产应急操作、缺少测试的核心账务、跨组织权限变更和无法回滚的数据迁移。Agent 可以收集证据和生成方案，但最终动作仍需更严格的双人审批。
商业壁垒来自组织自己的任务基线、隐藏测试、代码知识、审批反馈与安全控制。所有竞争者都可能调用 Claude 4，只有持续积累“什么变更在本公司算成功”的系统才能形成复利。
局限与风险
第一，本文仅描述 5 月 22 至 24 日。后续 Claude 模型、Claude Code 功能、价格和 beta 状态不进入同期事实。
第二，官方 Benchmark 与客户案例没有在本站复现。并行采样、测试过滤和内部评分模型会影响高计算结果，不能把数字直接移植到企业 ROI。
第三，Agent 可执行命令会扩大秘密泄露、供应链、提示注入和破坏性修改风险。仓库文本、issue 和工具输出都应视为不可信输入，模型不能提升自己的权限。
第四，长任务存在费用失控、死循环和状态漂移。系统需要硬预算、最大步数、进展检测、checkpoint、幂等重试和人工停止。
第五，Claude Code GA 不等于开源。企业仍受产品条款、数据处理、区域、服务可用性和供应商变更影响，需要导出任务证据和保留替代执行路线。
第六，thinking summary 不是完整因果说明，也不是安全证明。生产审计应保存外部可验证的操作与结果，而不是要求模型暴露思考链。
面试表达
30 秒结论： 2025 年 5 月 22 日，Claude 4 模型多渠道可用，Claude Code 核心产品 GA；但 IDE、GitHub、interleaved thinking、Files API、代码执行与 MCP connector 仍有 beta 边界。我把 Coding Agent 当成可恢复的变更状态机，用最小权限工具、真实测试和人工审批证明任务完成，而不是把模型会持续运行当成可靠性。
3 分钟架构： 任务服务固定基线 commit 并生成计划，策略层按仓库、工具和参数授权；执行器在隔离工作树中运行，所有写操作 checkpoint。验证层执行编译、测试、静态检查和范围审计，只有证据齐全才生成 PR。队列负责长任务、幂等与恢复，观测记录 Token、工具错误、进展、接管和单位成功成本。常规任务走 Sonnet，复杂或连续失败才升级 Opus/更高预算。
面对“Claude Code 已 GA，为什么还要这么多门禁”的追问，答案是 GA 描述供应商产品阶段，而企业责任涵盖自己的数据、权限、代码和事故成本。两者不是同一层合同。
复盘
站在 2026 年看，Claude 4 与 Claude Code GA 的关键转折不是又一次代码 Benchmark 提升，而是模型、终端 Agent、IDE、后台任务、SDK 与工具 API 开始组成完整交付面。评价单位从“一次回答”转向“一条经过验证的仓库任务轨迹”。
当时最应该警惕的是 GA 标签扩散：核心产品 GA 很容易在传播中变成“所有集成都生产就绪”。下一次评估 Agent 发布，我会逐项记录模型、核心产品、扩展、SDK、远程集成、执行工具和协议连接器的状态，并为每个 beta 组件准备独立开关。只有最终业务状态改变且证据可回放，才算 Agent 完成任务。
方法披露
本文由 AI 辅助梳理产品层次、生成状态机清单和原创 SVG 草图；日期、发布状态、价格、API beta 项、Benchmark 方法边界和最终判断由作者对照发布日存档与 API Release Notes 复核。本站未运行 Claude 4 或 Claude Code，所有性能描述均明确归因 Anthropic，工程内容为实验与上线方案。
修订记录
2025-05-25：初版发布；固定 2025-05-22 至 2025-05-24 证据边界，区分模型发布、Claude Code GA 与周边 beta。
Reusable projects
关联可复用项目
本文已经进入以下工程项目；项目页提供固定版本、运行命令和结果工件。
- 已独立复现
本文强调仓库上下文、权限、独立测试和人工合并边界，对应本项目的路径控制与 scorer 隔离设计。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论