转载说明：本文翻译并转载自 Give Claude a computer，原文发布时间为 2026-02-27（以 X 帖子时间为准）。给 Claude 一台“计算机”：在 Anthropic API 中用程序化工具调用 TL;DR： Programmatic tool calling（PTC）是 Claude Opus/Sonnet 4.6 的一项关键能力。传统工具调用每一步都要把结果回传到 Claude 上下文；而在 PTC 中，Claude 会写代码，在容器里直接编排工具调用。中间结果回到代码执行环境，而不是模型上下文窗口。这可以显著降低 token 消耗，并提升多步任务（如搜索）的性能。Opus 4.6 + PTC 最近在 LMArena 搜索基准拿到第一。你可以通过文档进一步了解 PTC 以及默认启用 PTC 的 web search 工具。 “Computer use（计算机使用）”是 Claude 最核心的能力之一。只给 Claude 一个 bash 工具，就能打开很大的动作空间。随之而来的常见问题是：只靠 bash 够不够？ 以及如何决定还要给 Agent 哪些工具。 动作（actions）是 Claude 与外部世界交互的方式。工具（tools）则是对这些动作的声明式定义。你在 API 里给出工具名、描述和输入参数后，Claude 就能调用这些 工具。 当 Claude 想调用工具时，它会先返回一个包含工具参数的 JSON。然后由工具处理器（例如 MCP server 或你自己写的代码）去执行，并把结果回传。如果你把这个过程放进循环里，就构成了一个 Agent。例如 bash 工具就是先生成 JSON 形式的命令，再交给 bash handler 执行：{"command": "pip install requests"} 什么时候该把动作做成工具 “Claude + bash 工具 + 循环”就是一个 computer-use agent，这是 Claude Code 的核心。但 Claude Code 并不 只 用 bash。它会把部分动作提升为工具，作为可控的 控制面（control surface）。@trq212 在这方面有一篇很好的 拆解。通常在以下场景中，把动作抽成工具很有价值：UX。 @trq212 在这条 帖子里提到 AskUserQuestion 工具：当某类动作需要被“捕获”并以特定方式呈现给用户时，工具非常有用。Guardrails（护栏）。 某些动作需要额外保护。例如文件编辑工具可以先做 staleness check，确认文件在模型上次读取后没有被外部修改。并发控制。 有时按并发安全性分组动作更合理（例如只读工具允许并行）。可观测性。 将特定动作隔离成工具，便于独立记录日志与指标（如延迟、token 用量）。自治级别。 你可能希望按“可自动批准程度”分组动作：如果框架能够回滚某个动作，就可以更积极地自动批准它。 工具机制的问题 工具在“可控性”和“可组合性”之间存在权衡。假设把三个动作都做成工具调用：每一步返回结果都要回到 Claude，上下文里会串行堆积中间数据。每次往返都增加延迟，也会把可能很大的结果序列化进上下文（例如下一步只用 5 条数据，却塞回了 5000 条），并引入一次额外推理。动作越多，这种组合税（composition tax）越重。 Programmatic tool calling（程序化工具调用） Claude 正在形成一种能力：把“代码的可组合性”与“工具的控制面”结合起来。通过 programmatic tool calling（PTC，见 文档），你仍然像以往一样定义工具；但 Claude 不再逐个调用，而是把它们当函数进行组合，在代码执行容器中运行。每次函数输出都会返回容器，而不是回传到 Claude 的上下文窗口。 当代码调用工具（例如 await web_search(query)）时，容器会暂停。该调用作为一个带类型的 tool-use 事件跨越沙箱边界，执行方式与模型直接调用工具一致（handler、MCP server 等都可复用）。关键差异在于：结果回到 正在运行的代码，而不是 Claude 上下文。随后代码按 Claude 设定的控制流继续执行（继续调工具、过滤数据、累积结果等），只有最终输出再交回 Claude。 基于 Opus 4.6，我们在非编程评测中观察到 PTC 带来的 token 效率和性能提升（例如用于 web search 的 BrowseComp 与 DeepsearchQA）。一个典型例子是：不再把 50 条原始搜索结果全部塞回上下文让 Claude 再筛选，而是先在代码里做解析、过滤和交叉验证，仅保留相关信息（例如…