交付结果不理想

[XiaozhongFang]

感觉这两天用的效果非常不好，转codex效果明显提升，模型问题是一方面，但是这个reasonix的工作流绝对是不如codex

[1WYUSE]

确实是这样，我觉得不如两级分化两个模式，一个极省token的模式使用现在的工作流等，另一种就是效率模式不会过多关注token消耗和命中率，但是把解决项目的能力提上来例如编码和解决bug等，目前国内部分企业还是因为数据安全和性价比在公司内部给予了一定的deep额度，作为员工偶尔考虑的是效率没有过多在意token消耗

[SauronSkywalker]

不追求极致省钱的话其实字节换软件就写好了，重做能力这块难度很大，个人开发者搞起来挺费劲的

[1WYUSE]

不在乎token的前提是公司仅提供了deep额度，所以项目大部分会使用deep进行开发

[SivanCola]

我来思考下

[SivanCola]

这个反馈我认，先不把它简单归因于模型，也不拿已有的省 token 开关来搪塞。

现在关闭省 token 主要是恢复完整工具和技能面，并不等于“交付优先”工作流；默认仍更偏轻量、缓存友好。接下来我会先做两件事：

1. 用真实历史修复任务做同模型 A/B，对比当前 full 与强调“复现 → 根因 → 实现 → 测试 → 复审”的 delivery contract。
2. 增加可公开分享的质量诊断摘要，避免要求大家贴完整会话。

为了定位这次“这两天明显变差”，方便的话请补充：

• Reasonix 版本、模型和 effort
• 是否开启省 token、Plan、Goal 或 planner
• 一个脱敏任务示例：预期结果、实际问题、最后一次测试结果

请不要在公开 Discussion 上传完整 session bundle，其中可能包含未脱敏的对话和源码。拿到可复现样本后，我会优先判断是模型/网关、缓存或 compaction，还是 agent workflow 回归。

[SivanCola]

跟进之前的承诺：这条线的第一批改动已经通过 #6322 合入 main-v2（merge commit 11d97723），将随下一个版本发布。

针对这里讨论的问题，现在是显式的三档运行档，而不是一个省 token 开关：

• 经济（Economy）：极致省 token，收窄工具与上下文面——对应楼上说的第一种模式。
• 均衡（Balanced）：即现有默认行为，系统提示与工具 schema 字节级不变，缓存命中不受影响。
• 交付优先（Delivery）：完整工具面 + 一个稳定的 use_capability 代理（按需接入 MCP，不破坏缓存前缀），并由宿主运行时强制交付门禁：改动前要有可验证的验收标准，改动后必须有复查、验证和带证据的签收才能收尾；中高风险改动强制结构化 review / security_review，而且报告里声称"已评审"的文件必须有宿主观测到的真实读取/差异证据，模型口头声称不算数。这是对"交付结果不理想"的直接回应——约束是运行时验证的，不是提示词恳求。

桌面端可以在输入框直接切换工作模式（经济/均衡/交付）和执行方式（标准/计划/目标）。另一个显式的行为变更：新建会话的工具审批默认从 Ask 改为 Auto（仍遵守 allow/ask/deny 规则和 plan mode，不是 Yolo；可在 设置 → 新会话默认审批 改回 Ask，已有会话不受影响）。

细节见 PR #6322 的说明与 docs/TOOL_CONTRACT.md、docs/GUIDE.md 的运行档章节。发布后欢迎拿同样的任务再对比一轮，继续把反馈丢过来。

[jm18919]

想建议下专门弄几个版本来修bug，目前issue太多了