压缩彻底取消json格式

[ranxianglei]

压缩彻底取消json格式

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到。确认理解：compress 工具的 content 参数目前是一个 union —— 既接受数组，也接受「JSON 编码的字符串」（当初为兼容非 strict-tool 的 provider 把数组参数字符串化而加的兜底，见 session 01a00a38 / #253）。

本 issue 要求彻底取消 json 格式，我的方案：

1. CompressParams.content 改为仅 Type.Array(RangeSpec)，移除 Type.String 分支；
2. 删除所有配套的字符串兜底逻辑：tailRepair / repairContentTail / jsonParseError / describeDiagnostics 里的 JSON 分支，normalizeRanges 改为纯数组校验；
3. 移除 tests/compress-tail-repair.test.ts，并更新 compress-retry.test.ts（删掉「接受 JSON 字符串」的用例，保留「非数组 → 抛错」用例）。

⚠️ 一个权衡想跟你确认：移除后，非 strict-tool provider（如 vLLM openai-completions）如果仍把数组参数字符串化，pi 的 typebox 校验会在 schema 层直接拒绝（content 必须是 array），不再进兜底解析。按「彻底取消」的字面要求我默认就这么做。如果这个 tradeoff 你接受，我就直接实现并开 PR。

先按此推进，实现完会附 PR 链接。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 已完成，PR：#274

改动（content 参数彻底取消 JSON 字符串形式，仅保留数组）：

• src/compress-tool.ts
  • CompressParams.content：Type.Union([Array, String]) → Type.Array(RangeSpec)
  • normalizeRanges：纯数组校验；非数组 content（含 JSON 编码的数组字符串）现在直接抛错（pi 标 isError:true，计入失败上限）
  • 删除 tailRepair / repairContentTail / jsonParseError / describeDiagnostics，以及不再使用的 parseCompressArgs + CompressParseDiagnostics 导入
• tests/compress-tail-repair.test.ts：整体删除
• tests/compress-retry.test.ts：删掉「接受 JSON 字符串」用例；保留并改写「非数组 → 抛错」用例，现在喂一个合法的 JSON 数组字符串以证明它同样被拒
• CHANGELOG.md：Unreleased 段记录本次移除

验证：npm run typecheck ✅ · npm test ✅ 450 pass / 0 fail / 3 skipped · npm run build ✅（dist 无残留）

一个权衡再确认：移除后，会把数组参数字符串化的非严格工具 provider（如 vLLM openai-completions）会在 pi 的 schema 校验层被拒（content 必须是 array），不再进兜底解析。如果你希望这类 provider 仍能工作，告诉我，我可以保留 schema 的字符串分支但去掉 tail-repair 那套；否则按现状合并即可。

[ranxianglei]

难道不可以让compress工具,模型输入的时候不再输入json吗?因为json很严格 稍微不注意模型就输入错误.

比如总结的内容里面有引号 需要转义 有时候要转义的转义 不一定模型可以转义对

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 好问题，这里有个根本约束需要先说清楚：

工具调用的参数在所有主流 LLM API（OpenAI / Anthropic / vLLM…）里都是 JSON。 模型调用 compress 时输出的必然是一个 JSON 对象，summary 是其中的一个字符串字段。字符串里的引号 / 换行按 JSON 规则必须转义——这是 JSON 本身的性质，不是 compress 工具特有的。所以"让模型不再输入 JSON"在协议层面做不到，否则整个工具调用机制就废了（所有工具都受影响，不只是 compress）。

实际分两种情况：

• 严格模式（strict tool calling）：模型按 schema 填字段、框架负责序列化。现代模型训练时就包含"为工具调用产出合法 JSON"的能力，转义一般能处理对；万一转义错了，API 校验失败并让模型重试——这是标准行为，不会卡死。
• 非严格模式（如 vLLM openai-completions，supportsStrictTools:false）：模型可能把参数输出成一个 JSON 字符串。这时转义错误才真正可见、易错——这正是当初 fix(compress): repair missing closing brace on last content entry #254 加"接受 JSON 字符串 + tail-repair"兜底的起因。

我那个 PR 移除的是"接受 JSON 字符串"这条兜底（针对非严格模式）。严格模式不受影响——模型输出的是结构化数组，不是字符串，转义由模型/框架正确处理。

能做的：

1. schema 保持简单（现在就是纯字符串字段，转义面已经最小）。
2. 报错信息清晰，让模型能自我纠正、重试。
3. 如果你担心的是非严格 provider，我可以把"接受 JSON 字符串"的兜底加回来——但去掉 tail-repair 那套，只保留 JSON.parse + 字段校验。这样非严格 provider 仍能工作，复杂度也降了。（注：这与"彻底取消 json 格式"字面方向相反，所以先跟你确认。）

想确认你的意图，三选一：

• (a) 维持现状（严格 JSON、无字符串兜底）——非严格 provider 的字符串化参数会被 schema 拒掉；
• (b) 加回字符串兜底（兼容非严格 provider，去掉 tail-repair，只留 JSON.parse+校验）；
• (c) 你其实想要的是别的（比如换一种更简单的入参结构）——告诉我具体想法，我评估可行性。

[ranxianglei]

所以模型的输出必须是json
压缩内容也是json
如果压缩内容需要转义怎么办
是框架纠错还是模型自己搞

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 直接回答：转义是模型自己生成的；框架只负责"校验/检测"，不会替你自动改。

先澄清一个点： summary（压缩内容）本身不是 JSON，它是一段纯文本字符串。但因为它是 JSON 对象里的一个字符串字段（{"content":[{"summary":"..."}]}），JSON 规则要求字符串里的引号 "、换行、反斜杠必须转义——转义是"把这段文本塞进 JSON 字符串"的代价，不是"压缩内容本身是 JSON"。

流程：

1. 模型生成：模型逐 token 输出工具参数（一个 JSON 对象）。写到 summary 时，模型自己负责把里面的引号/换行写成 \"、\n 等合法 JSON。这一步是模型干的。
2. 框架校验：pi / LLM API 拿到模型输出的文本后解析 JSON。解析失败 = 模型转义错了。
3. 出错后：
   • 严格模式：框架校验不通过 → 拒绝这次调用 → 模型看到错误重试（自己纠正）。所以严格模式下是"框架报错、模型自己改"，能自愈、不会卡死。
   • 非严格模式：框架尝试解析字符串化的 JSON，失败就报错。（我那个 PR 去掉的 tail-repair 兜底，原本就是在这一步"猜着修"常见转义错误。）

为什么框架不直接"自动纠错"： 畸形 JSON 没法可靠地自动修——一个没转义的引号，可能意味着"这里该转义"，也可能意味着"字符串在这里结束"，框架无从判断。所以业界标准做法就是：模型负责产出合法 JSON，框架负责校验，错了让模型重试。 现代模型（GPT / Claude 这类）对工具调用的 JSON 转义训练得比较到位，出错率很低；真正容易翻车的是非严格 provider 把参数整个字符串化的场景。