把 Chat 升级为任务运行时，让每个 Quest 都有清晰的工作区边界、执行边界和知识边界
返回
在 Qoder 1.0 中，我们最重要的方向，是构建一个更适合 Agent 执行任务、也更适合开发者管理 Agent 的任务环境。Qoder 1.0 正是这一方向下的核心能力：它把 Chat 升级为智能体任务运行时，让每个任务都有清晰的工作区边界、执行边界、产物边界、交付边界，以及持续生效的知识边界。
在传统 IDE 里，Workspace 基本等于窗口打开的目录。文件树、终端、Git 面板、编辑器都围绕它工作。这个设计的前提是：窗口状态、执行状态和交付状态通常是一致的。
但在 Qoder 1.0 中，一个任务可能跨越多种工作区状态：
在 Agent 模式下，这几层大多重合。当前目录就是执行目录，执行目录也是产物目录，Review 和 Commit 也作用在同一个 Git 根目录。
但一旦进入 Worktree，这些边界就会分开：任务从源仓库创建，Agent 在隔离 worktree 中执行，文件和 Review 应该跟随 worktree，而用户新建下一个 Quest 时，又应该回到源仓库。
本地 Worktree 的价值，是让多个 Quest 可以并行推进。Agent 可以在隔离目录里修改文件，用户可以在右侧产物区查看变更，再决定 Review、Apply 或 Commit。这个模型看起来像"多建一个分支目录"，实际更像给每个任务分配一个独立执行边界。
这个边界如果不稳定，后续所有动作都会抖。
Apply 可能写错目录，Reject 可能回退错文件，Review 可能比较错 diff，Commit 可能统计错 Git 根目录。更糟的是，这些错误往往不会在 Agent 写代码时暴露，而是在用户准备交付时才出现。
所以，Qoder 1.0 真正要稳定的是一条完整链路：任务从源工程创建，在绑定的执行环境里运行，产物从当前任务解析，Review 消费当前任务的 diff，Commit 落到当前任务的交付目标。
只有这条链路稳定，多任务并行才不是多个目录的堆叠，而是多个任务运行时的并行。
Quest 模式视窗的左中右三栏，在回答一个更工程化的问题：一个 Agent 任务如何从会话，变成可查看、可审查、可提交的结果。
放在 Qoder 1.0 的故事里，记忆和项目知识并非另一个并列功能，而是归属于任务执行环境的一部分。它们决定 Agent 在执行任务时，能不能理解用户意图、项目约束和团队规范。但知识不能作为一个全局 prompt 池直接注入 Agent。
对于 Coding Agent 来说，知识必须带有范围：
在这里，知识引擎的价值不只是让 Agent "知道更多背景"，而是让它在执行任务时更准确地判断：用户真正想要什么，系统应该怎么接入，代码应该怎么写，结果是否符合团队交付要求。
为了验证记忆和项目知识是否真正生效，我们在内部项目同时做了线上业务评估和离线任务评测。
线上评估对比"记忆生效"和"记忆无效"的结果，观察不满意度、代码保留率、输入 Token 和对话轮次等指标。三天线上数据 A/B Test、Top 5 类目统计显示：记忆系统让不满意度降低 22.09%，代码保留率提升 11.10%，输入 Token 降低 40.13%，对话轮次降低 32.60%。
离线评测则围绕架构理解、规范遵循和技术栈适配构建任务集。结果显示：架构知识增强后，任务完成度评分提升约 25%，Token 消耗下降约 30%；技术栈知识增强后，端到端评分提升约 25%，Token 消耗降低约 15%；编码规范知识也显著提升了代码的规范符合度。
这说明，知识增强不是泛化提示词，而是可评估的工程能力。它会直接影响 Agent 的关键决策：知道该改哪里、该怎么写、要遵守什么规范，以及如何贴近项目真实运行环境。
Qoder 1.0 要做的，不是把 Chat 做得更大，而是把 Chat 升级为任务运行时。
Chat 负责对话，但真实交付还需要更稳定的任务边界：任务属于哪个工程，Agent 在哪里执行，产物在哪里展示，Review 审哪份 diff，Commit 落到哪个 Git 根目录，知识来自哪个用户、团队和仓库。
只有这些边界稳定，Agent 才能真正并行执行；只有依据可追溯，Review 才能判断结果；只有交付路径明确，任务才可以被放心托付出去。
Workspace：把一次对话变成可交付任务
在传统 IDE 里，Workspace 基本等于窗口打开的目录。文件树、终端、Git 面板、编辑器都围绕它工作。这个设计的前提是：窗口状态、执行状态和交付状态通常是一致的。
但在 Qoder 1.0 中，一个任务可能跨越多种工作区状态：
Worktree：如何更好的管理任务生命周期
本地 Worktree 的价值，是让多个 Quest 可以并行推进。Agent 可以在隔离目录里修改文件，用户可以在右侧产物区查看变更，再决定 Review、Apply 或 Commit。这个模型看起来像"多建一个分支目录"，实际更像给每个任务分配一个独立执行边界。
Artifacts：从会话事件到可审查产物
Quest 模式视窗的左中右三栏，在回答一个更工程化的问题：一个 Agent 任务如何从会话，变成可查看、可审查、可提交的结果。
- 左侧任务 / Workspace 负责归属：当前有哪些工程，每个工程下有哪些 Quest，历史任务恢复时应该回到哪个 workspace。
- 中间任务会话流负责执行连续性：计划、工具调用、专家协作、用户确认、错误恢复，都要落在当前任务和会话上。
- 右侧产物工作区负责交付可见性：文件告诉用户改了什么，概要解释任务做了什么，查看变更决定哪些变更进入交付。
知识 Scope：构建带边界的上下文索引
放在 Qoder 1.0 的故事里，记忆和项目知识并非另一个并列功能，而是归属于任务执行环境的一部分。它们决定 Agent 在执行任务时，能不能理解用户意图、项目约束和团队规范。但知识不能作为一个全局 prompt 池直接注入 Agent。
对于 Coding Agent 来说，知识必须带有范围：
- 用户级记忆回答"这个用户通常怎么表达和协作"。
- 团队级记忆回答"这个团队有什么技术偏好和协作规范"。
- 仓库级知识回答"这个工程的架构、技术栈、模块边界和接入点是什么"。
- 任务级引用则回答"这次执行实际依赖了哪些上下文"。