你的代码执行完工具后，通过普通的 Messages API 把结果送回给 Claude——不是什么特殊端点，不是回调，就是对话里的又一条消息。
关联字段：tool_use_id
tool_result block 里必须包含一个 tool_use_id，和模型 tool_use 请求里的 id 严格匹配。这个配对关系让模型知道哪个结果对应哪个请求。对错了，模型就无法把它要的东西和收到的东西联系起来。
{
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": "toolu_01A09q90qw90lq917835lq9",
"content": "Current weather in San Francisco: 62°F, partly cloudy"
}]
}它是一条 user 消息
工具结果放在 role: "user" 的消息里。这和 API 的双角色模型一致：assistant 那边生成请求，user 这边提供其余一切。你的应用执行了工具，你的应用在 user 那边，所以结果就是 user 消息。
没有特殊的 “tool” 角色，没有专门的端点。就是普通的 /v1/messages 端点，普通的对话流。
传达错误
工具执行失败时，你仍然要发一个 tool_result——只是把错误信息放在 content 里。模型能读到错误、理解出了什么问题，然后决定下一步（换参数重试、换个工具、或者告诉用户）。
不要悄悄丢掉失败的工具调用。不要抛异常绕过 API。把错误作为 tool_result 送回去，让模型做出知情的决定。
为什么角色分配是合理的
角色分配遵循一个简单规则：角色反映的是谁生成了内容。模型生成了 tool_use 请求，所以它在 assistant 消息里。你的应用生成了 tool_result，所以它在 user 消息里。角色不是按内容类型分的——是按来源分的。
一句话总结： 工具结果是 user 消息，通过 tool_use_id 和原始请求关联——即使失败也要送回结果，让模型决定下一步怎么做。