Skills 响应修复导读
响应修复的意义不是掩盖问题，而是把可恢复的输出格式偏差从应用层拿掉，减少你为 JSON 漂移写一堆脆弱补丁。
response healing 适合解决“模型大体做对了，但输出还差一点才能稳定被机器消费”的情况。 它不是万能方案，也不能替代结构化输出设计。通常更推荐的顺序是： 先约束，再修复，最后才是兜底重试。
它最擅长处理什么
| Name | Type | Required | Description |
|---|---|---|---|
JSON parse failure | repair | 输出接近 JSON，但还差一点，导致你的下游解析直接失败。 | |
format drift | repair | 字段顺序、包装层或轻微格式偏差导致机器消费不稳定。 | |
light retry | repair | 在安全边界内做轻量重试，尝试把结果拉回可解析状态。 |
最小请求
json
{
"model": "openai/gpt-4.1-mini",
"messages": [{ "role": "user", "content": "输出 incident 的 JSON 总结。" }],
"skills": [{ "id": "response-healing" }]
}只适合非流式修复
如果你已经在做 streaming token-by-token 输出，就不要指望 response healing 再去重组完整 JSON。 这类能力更适合非流式、完整响应落地后的修复。
什么时候值得开
- 你已经明确需要机器可解析输出，但偶发格式漂移仍在伤稳定性。
- 你不想在每个客户端重复写 try/catch + regex patch + retry。
- 你愿意接受少量额外延迟，换更高的输出成功率。
最容易犯的错
text
1. 把 response healing 当成结构化输出的替代品。
2. 在 streaming 场景里错误期待它修完整 JSON。
3. 不看 request logs，只知道“好像系统又重试了一次”。
4. schema 本身混乱，却把所有问题都寄希望于响应修复。