Skills 托管执行导读
托管执行适合把原来散落在客户端的执行循环收回服务端，便于统一限制、计费和观察。
托管执行解决的重点不是“模型能不能多跑几步”，而是 谁来控制执行循环、谁来承担可观测性和费用解释。 如果你的客户端已经在重复写 tool loop、step 限制和安全中止逻辑，那说明你已经接近托管执行的使用时机。
它真正接管了什么
| Name | Type | Required | Description |
|---|---|---|---|
execution.mode = "managed" | string | Required | 显式开启托管执行，告诉系统由平台接管执行循环。 |
max_steps | integer | 最多允许执行多少步。防止 agent loop 无限延长。 | |
max_duration_ms | integer | 最长执行时间。你不该让托管执行无限吃掉延迟预算。 | |
max_tool_calls | integer | 最多允许调多少次 tool。避免外部 API 和账单失控。 |
最小请求
json
{
"model": "openai/gpt-4.1",
"messages": [{ "role": "user", "content": "帮我查一下今天的发布回归，再给出修复建议。" }],
"skills": [{ "id": "web-search" }],
"execution": {
"mode": "managed",
"max_steps": 6,
"max_duration_ms": 15000,
"max_tool_calls": 3
}
}托管执行不是无限代理
平台托管的是循环，不是替你承担所有产品边界。你仍然要决定哪些 skills 可用、外部 API 费用是否值得、 最大 step / duration 应该多少，以及哪些请求根本不该进入托管执行。
什么时候该启用
- 你已经在多个客户端里重复写相同的 tool loop。
- 你需要统一的 request-level 账本，而不是每个工具自己记一份成本。
- 你需要统一的 step / duration / tool-call 限制。
- 你准备把联网搜索、响应修复、schema 修复放进一条更稳定的执行链。
最容易犯的错
text
1. 开了 managed，却不设 max_steps / max_duration_ms。
2. 以为托管执行会替你自动解决权限和费用治理。
3. 把不需要多步执行的简单请求也塞进 managed。
4. 只看最终回答，不看执行过程中用了哪些 skills 和 tool calls。