致 TRAE 产品管理团队反馈邮件
主题：一线重度开发者真实反馈 —— Agent 逻辑暗改、积分消耗失控带来的用户信任危机
收件：TRAE 产品管理层、策略团队、工程 Agent 模块负责人 抄送：豆包 Work 产品线相关负责人
您好： 我是一名长期深度使用 TRAE 的开发者用户，日常会使用产品完成工程代码重构、BI 页面开发、本地知识库 Agent 搭建、行业数据处理等真实业务开发工作，同时也在对比使用竞品 CodeBuddy / WorkBuddy，现将一线实际使用痛点客观反馈给团队。
在 2026 年 8 月，TRAE 的积分消耗、Agent 执行逻辑处于可接受水平：常规代码修改任务仅消耗 3‑5 积分，BI 页面中等规模重构消耗约 20 积分，Agent 执行收敛克制，不会无限制触发工具调用，签到获取的积分可以覆盖日常开发，整体性价比可以接受。
自 2026 年 9 月版本调整之后，在用户输入完全不变、开发任务规模不变的前提下，出现明显体验滑坡：
- Agent 后台逻辑无公示变更，积分消耗暴涨 同类简单代码修改任务消耗飙升至 30‑50 积分，中等重构任务动辄上百积分。根源并非模型推理单价上调，而是 Agent 默认策略改动：后台自动增加前置检索、多轮自检、自动重试、多方案对比逻辑，会无节制反复读取工程文件、循环试错，大量产生工具调用与 token 消耗。 整个策略调整没有任何版本公告、没有消耗变更提示、没有风险预警，用户只能事后翻阅积分消耗明细，才发现同等任务成本成倍上涨，属于典型的黑盒改动。
- 自动化能力的代价全部转嫁到用户身上，使用体验严重扭曲 TRAE 主打全自动工程 Agent 定位，但现在想要控制积分，用户必须手动限制 Agent 迭代轮次、强制拆分大任务、每一步人为干预终止会话。本该由产品框架完成的「任务收敛、开销管控」工作，全部变成使用者的负担。 反观竞品 WorkBuddy/CodeBuddy：同样支持 Agent 自动多轮执行、批量读写工程文件、自动化后台任务，框架内部自带开销管控；搭配混元模型还有免费额度兜底，把任务提交之后无需用户盯守、无需手动拆任务，不用担心算力消耗雪崩。同样的自动化能力，竞品做到用户无感，而 TRAE 需要用户时刻提防积分被大量消耗。
- 签到积分持续下调叠加消耗暴涨，彻底摧毁免费重度用户的付费意愿 每日签到积分额度持续压缩，叠加 Agent 改动后的高消耗，签到获取的积分已经完全不足以支撑正常开发工作。 目前我以及身边一部分重度开发者的现实选择：放弃 TRAE 内置 Seed 模型 + 积分体系，仅保留 TRAE 的 Agent 外壳，全部外接第三方 API Key 进行开发。 外接 API 消费完全透明，不受产品后台策略调整影响。这足以说明：用户认可 TRAE 的 IDE 外壳、Agent 调度框架能力，但已经不信任内置模型与积分计费这套体系。
- 风险提示：持续现状会造成开发者群体流失 程序员属于小众但高传播力的用户群体，虽然整体盘子不如多模态 C 端大，但开发者口碑会间接影响豆包 Work 整体品牌。如果继续维持当前模式：后台悄悄调整 Agent 行为、缺少消耗预估与变更公示、免费签到额度不断收紧，会持续流失现有核心用户。即便工具外壳做的再好，如果内置使用成本不可预期，用户只会选择绕开内置能力，产品内置模型的设计目标就完全落空。
一线用户的诉求（可落地，不需要巨额投入）
- 策略变更必须公开公示：任何会改变 Agent 行为、影响积分消耗的后台逻辑调整，必须写进版本更新日志，明确告知用户改动点、对消耗的影响，杜绝暗改。
- 增加开销保护机制：给 Agent 增加可配置最大工具调用轮次阈值；执行大型任务前提供预估消耗弹窗，允许用户确认 / 拒绝执行；增加全局安全熔断，避免陷入无限循环读文件、疯狂扣积分。
- 区分两套使用体验：提供两种 Agent 模式可选：
- 激进全自动模式：保持现有多轮自检重试逻辑，告知高消耗风险；
- 克制高效模式：回归 8 月前后收敛的执行策略，减少不必要的循环、多余文件读取，匹配原来的积分消耗水平。
- 积分策略重新评估：重新评估签到积分与 Agent 消耗的匹配关系，至少保障普通开发用户，签到所得积分能够覆盖日常常规开发，不要让签到沦为象征性福利。
客观看待竞品差距：WorkBuddy 可以做到的 “提交任务即可放手，不用盯着开销”，这是 TRAE 完全有能力做到的，不是技术不可行，是产品策略、管控逻辑的取舍问题。
我非常认可 TRAE 这套工程 Agent 外壳的潜力，也不希望只能被迫全部外接第三方 API 来使用。希望管理层能够重视真实一线开发者的反馈，解决 Agent 黑盒消耗的核心痛点，挽回用户信任感。
期待产品侧的评估与回复。 反馈人：TRAE 重度开发者 日期：2026‑10‑04