建议：提升 Bot 的目标理解、任务交付和自主恢复能力

[Liyuk]

背景

使用体验上，Grok Bot 在目标性、交付完成度、理解问题以及遇到问题后自行调整和修复方面，似乎明显强于目前的 DS Bot。例如使用 GPT 作为 Bot 模型时，有时会停在发现问题或分析阶段，没有继续完成用户希望它做的事。这是使用体验，尚未经过同任务、跨模型的系统评测；差距可能涉及模型、提示词、工具、上下文和运行机制。

参考材料

• 第三方整理的疑似 Grok Bot 系统提示词：可以作为研究自主推进、交付和异常处理的线索，但来源、完整性及是否为当前线上版本均未经验证。请勿将其视为官方实现，也不要直接复制其文本。
• Grok Bot 官方产品说明 和 Skills and routines：描述了持续工作环境、工具、协作以及可复用流程；这些能力不一定仅靠提示词实现。
• 相关讨论：#197 任务和进度展示。

希望讨论的问题

1. 目标理解：如何让 Bot 区分问答、只分析与要求执行的任务，结合上下文判断用户真正需要的成果、约束和完成标准？如何减少可以自行查明的问题上的反复追问，同时避免擅自扩大授权？
2. 交付完成度：当用户要求修复或制作成果时，Bot 能否在授权范围内继续行动，而不是停在发现问题、列计划或承诺下一步？结束前如何核对实际结果、验证依据、未完成部分与阻碍？
3. 自我修复：工具失败、验证失败、依赖缺失或实现走不通时，如何让 Bot 根据错误调整、尝试合理替代方案，保留已完成工作，并在真正受阻时给出具体原因？如何防止无限重试、重复有副作用的操作或绕过权限？
4. 团队协作：派活时明确目标、交付物和验证要求；结果返回后由发起 Bot 对照原目标综合验收，避免只转发一段报告。现有派活树和恢复机制能否支撑这些行为？

自动规划和目标推进

使用体验上，Grok Bot 似乎会持续规划、执行、检查并调整，像是在自动切换 plan 和 goal 模式。这只是观察和猜测，尚无证据证明它内部实际存在这两个模式、一直开启或自动切换。 能否先通过同任务实验确认其行为，再讨论 DS Bot 的等价体验？

可以探讨几个层次：

• 对简单任务直接执行；任务复杂或不确定时按需形成并更新简短计划，不强制每次展示计划。
• 在当前回合持续对照用户目标，遇到验证失败时修正，完成或确有阻碍时才交付；分析和只读请求仍遵守用户范围。
• 对确需长时间运行的任务，研究是否需要 Bot 自己持久保存目标、完成标准、进度、等待和阻碍，以支持中断、重启和跨会话分段恢复；应有可见状态、用户停止入口、有限重试和防重复执行机制。

DS Bot 当前在 Bot 会话中禁用了 DSH goal；DSH 让步总账 C2 记录了限制，并提出长任务自主推进需要 Bot 自己的功能且跨段保留。任何方案应先核实 DSH 的公开插件接口，不修改 DSH；如果需要改变已定设计，交由维护者决定。

建议先验证

建立一组真实任务，对相同请求比较 Grok Bot 与不同模型的 DS Bot：修复并验证、研究并交付、模糊需求、工具失败、只分析不修改、跨 Bot 派活。记录是否理解目标、是否过早停止、实际交付与验证、失败后的恢复、无必要的追问，以及耗时和成本。先建立基线，再分别评估提示词和运行机制的改动。

欢迎讨论：哪些失败场景最常见？哪些能靠基础指令改善，哪些需要持久任务状态或 DSH 新接口？如何设计完成标准与停止条件，既提升交付能力又尊重用户意图？

[Liyuk]

补一个现象和一个可落地的判定点，供讨论。

现象（单次观察）：在需要多角色协作的分析任务中，曾出现连续两条"分工说明"消息，写明了谁负责哪一块，但消息中没有任何 @ 或派发调用，成员因此未被唤醒；直到用户追问进度，工作才实际开始。随后正式派发时，参与人数少于先前计划，界面上也没有对应的核对提示。

这与本帖问题 2（交付完成度）和问题 4（派活时明确目标、交付物和验证要求）相关。两点观察：

1. "计划要派"和"实际已派"在界面呈现上难以区分，仅靠提示词要求"不要停在计划阶段"，长会话中仍可能遗漏。
2. 派发信息只存在于自然语言时，计划人数与实际执行人数之间缺少可核对的依据。

一个成本较低的判定点：在模型输出结束后做一次确定性检查——若本轮文本声称已委派/已安排，但同一轮没有任何派发类工具调用，则注入一次纠正重试（仅一次，避免循环）。它不判断业务对错，只校验"声称的动作是否真的发生"。

需要注意的风险：触发词判断可能误报（例如模型只是转述第三方的话），建议用真实会话回放校准，宁可漏判也不要误重试。以上为单次会话观察，属待验证假设，不是评测结论。

[Liyuk]

承接本帖的问题 1（目标理解）、问题 2（交付完成度）和问题 4（团队协作派活），提一个结构化的改进方向。以下来自一段时间的实际使用观察，样本有限，属待验证假设，不是评测结论。

一、改进方向：三个结构性环节

环节	现状与影响
通道	模型输出的文字本身即为交付，没有"内部草稿 → 显式发送"的分离；未验证的中间结论与最终结果走同一通道，因此输出形态偏向对话。
状态	没有跨轮持久的"目标 / 计划 / 哪一步由谁领取"对象。上下文压缩、重启或跨群接力后，目标与进度需要依赖聊天记录重建；同一任务可能被重复创建，计划中的参与人数与实际执行人数缺少可见核对。
判定	是否完成由模型自行说明，没有可执行检查，也没有人工确认闸门。

这三者叠加时，"任务是否真正完成"缺少可核验的依据，因此改进重点放在状态与判定两个环节。

二、四个原语

1. 任务状态（Goal / Plan / Claim）
持久化在插件自己的存储中（不依赖提示词）。字段包括：目标、分步计划（每步带检查）、领取租约、验收项、状态、证据、尝试次数。

其中 Claim（租约） 是当前缺失的一环：领取产生带期限的租约，有效期内其他执行者不重复领取；到期未续则回到可领取状态。它可用于处理重复执行与"已派发但未开始"两类情况。

2. 可执行验收
验收项分为两类：

• check：可执行断言，例如文件存在且结构符合预期、脚本退出码为 0、数据覆盖到目标日期。由系统执行，模型不能覆盖结果。
• human：需要用户明确确认的项（涉及价值判断或后果较大的决策）。

若某项既无法写成检查、也不属于人工确认，建议先回到交付物定义阶段，而不是直接作为验收项。

3. 事件循环
唤醒源从"收到消息 / 定时触发"扩展为：后台任务完成、租约到期、检查失败。每次唤醒执行同一套对账流程——读取未关单任务、检查停滞、选择下一步、执行或派发、运行检查、通过后再宣布完成。

4. 送达通道分离（产品级，需讨论）
若内部思考默认不可见、仅显式发送进入用户视野，交付形态会更接近"成品"。代价是模型若忘记发送会出现无回复，需要兜底：回合结束无发送时强制送达并标记为降级路径。

三、落地顺序

• 第一阶段（改动较小、可独立验证）：回合结束时核对"声称已派发"与"实际存在派发调用"是否一致，不一致则纠正一次；引入任务队列并在每轮注入当前状态；派发时写入租约。
• 第二阶段：验收检查执行器；停滞检测（动作停止或重复时标记为停滞）；群接力条件由"次数"改为"任务状态"。
• 第三阶段：送达通道分离、事件驱动唤醒、同一 Bot 多条并行流。

四、需要考虑的风险

• 检查可能失效：断言若由执行者自行编写，容易写成恒真条件。建议断言由用户或模板提供，关键任务至少一次独立复核。
• 粒度问题：仅对有明确产出物的请求建立任务，问答类不建。
• 过度工程：第一阶段的几项可单独验证效果，宜先观测边际收益再推进后续。
• 协作范围：多 Bot 协作更适合可并行拆分或需要独立复核的任务；对于单一交付物，由一名负责人端到端完成通常信息损失更小，可作为默认策略的对比项。

衡量方式见 #657 的指标建议。