Qoder 发布首个自进化智能体 Quest，实现真正的自主编程

上周，Qoder 旗下的智能体 Quest 完成了一项颇具象征意义的任务：它重构了自身的长程任务执行逻辑。这并非一次简单的功能迭代，因为重构过程涉及交互层流程优化、中间层状态管理以及 Agent Loop 逻辑调整等多个层面。

在整个从需求定义到代码合入主干的过程中，Quest 的开发团队只做了三件事：描述需求、审查最终生成的代码、验证实验结果。这清晰地诠释了“自主编程”的定义：AI 不再仅仅是辅助或结对，而是能够自主地完成任务。

Token 产出的不是代码，而是可交付的产物

Copilot 能补全代码，但你需要逐行确认。Cursor 或 Claude Code 可以重构逻辑，但调试和处理报错仍然是你的工作。这些工具虽然提升了效率，但人依然是执行主体。

Quest 致力于解决一个核心问题：Token 产出的必须是可交付的产物。如果 AI 编写了代码，最终仍需要人工来调试、测试和兜底，那么这些 Token 的价值就大打折扣。只有当 AI 能够稳定地产出完整、可运行、可直接交付的成果时，才算真正实现了自主编程。

Agent 效果 = 模型能力 × 架构设计

从工程实践出发，可以总结出一个公式：Agent 效果 = 模型能力 × Agent 架构（上下文 + 工具 + Agent Loop）。

模型能力是基础，但同一个模型在不同的架构下，其表现可能天差地别。Quest 通过优化上下文管理、工具选择和 Agent Loop 这三个维度的架构，来充分释放底层模型的能力。

上下文管理：Agentic 而非机械

随着任务推进，对话历史会不断膨胀。如果全部保留，会淹没模型的注意力；如果机械地截断，又可能丢失关键信息。Quest 采用了“Agentic 上下文管理”策略：让模型自主判断何时进行压缩和总结。

模型自主压缩

在长程任务中，Quest 会让模型在合适的时机总结已完成的工作。这并非简单地“保留最近 N 轮对话”，而是让模型理解哪些信息对后续任务至关重要，哪些可以被压缩。

压缩的触发时机基于多个因素：

• 对话轮数达到阈值
• 上下文长度接近限制
• 任务阶段切换（例如从调研阶段进入实现阶段）
• 模型检测到上下文冗余

模型根据当前任务状态进行自主决策，而非机械地执行固定规则。

动态 Reminder 机制

传统做法是将所有注意事项都写进系统提示词。但这会导致提示词臃肿、模型注意力分散，并降低缓存命中率。

以语言偏好为例：

• 传统方案：在系统提示词中硬编码“请用中文回复”。每次用户切换语言，整个提示词的缓存就失效，推理成本成倍增加。
• Quest 方案：通过 Reminder 机制动态注入需要关注的上下文。语言偏好、项目规范、临时约束等信息按需添加到对话中，既保证了信息的及时传递，又避免了系统提示词无限膨胀。

这样做的好处显而易见：

• 提高缓存命中率，降低推理成本
• 保持系统提示词简洁，提升模型注意力
• 灵活适配不同场景的特定需求

工具选择：为什么 Bash 是最佳拍档

如果只能保留一个工具，Quest 的选择一定是 Bash。这个决定可能有些反直觉。市面上多数 Agent 会提供丰富的专用工具：文件读写、代码搜索、Git 操作等等。但工具数量的增加会提高模型的选择复杂度和出错概率。

Bash 的三个优势

1. 大而全。Bash 几乎能完成所有系统级操作：文件管理、进程控制、网络请求、文本处理、Git 操作。一个工具覆盖了大部分场景，模型无需在众多工具中做选择。
2. 可编程、可组合。管道、重定向和脚本机制让简单的命令能组合成复杂的工作流。这与 Agent 的任务拆解思路高度契合：将大任务拆成小步骤，每个步骤用一行或几行命令完成。
3. 模型天生熟悉。大模型在预训练时已经见过海量的 Unix 命令和 Shell 脚本。因此，当遇到问题时，模型往往能自行找到解决路径，无需在 Prompt 中进行详细教学。

Less is More

Quest 仍然保留了少量固定工具，主要用于安全隔离和 IDE 协同。但始终坚持一个原则：能用 Bash 解决的，绝不创造新工具。

每增加一个工具，就增加了模型的选择负担和出错的可能性。简洁的工具集反而让 Agent 的表现更加稳定和可预测。

Agent Loop：Spec -> Coding -> Verify

一个能够自主编程的 Coding Agent 需要一个完整的执行闭环：收集上下文 → 制定计划 → 执行编码 → 验证结果 → 迭代优化。

观察市面上的 Coding Agent，用户最常说的话是“跑起来...”、“能运行就行”、“帮我调这个报错”。这恰恰暴露了它们的能力短板：在验证环节偷懒了。AI 写代码，却需要人来测试，这还算不上自主编程。

Spec 驱动的开发流程

• Spec 阶段：动手编码前先澄清需求，明确验收标准。对于复杂任务，Quest 会生成一份详细的技术规格书，确保 AI 和用户对“完成”的定义达成共识。
  Spec 包含的要素：功能描述、验收标准、技术约束、测试要求。
• Coding 阶段：根据 Spec 实现功能。这个阶段 Quest 自主推进，无需用户持续监督。
• Verify 阶段：自动运行测试，验证实现是否符合 Spec。验证类型包括语法检查、单元测试、集成测试等。如果不符合，则自动进入下一轮迭代，而不是把问题抛给用户。

整个流程可以抽象为以下伪代码：

while not task_complete:
    spec = clarify_requirements(task)
    code = implement(spec)
    result = verify(code, spec)

    if result.success:
        deliver(code)
        break
    else:
        task = refine_based_on_feedback(result.issues)

通过 Hook 机制，这三个阶段可以灵活地扩展和组合。例如，在 Verify 阶段接入自定义的测试框架或 lint 规则，确保每次交付都符合团队的工程标准。

对抗模型的“退缩”倾向

当前多数大模型是为 ChatBot 场景训练的。在面对长上下文或复杂任务时，它们倾向于“退缩”，给出模糊的回答或询问更多信息来拖延执行。

Quest 通过架构设计帮助模型克服这种倾向：在合适的时机注入必要的上下文和指令，推动模型完成完整的任务链路，而不是中途放弃或将问题甩回给用户。

自动适配复杂度，而非堆砌功能

Quest 面对的不只是代码补全，而是完整的工程任务。这些任务可能涉及多个模块、多种技术栈，需要长时间持续推进。

设计原则是：根据任务复杂度自动适配策略，用户无需关心背后是如何调度的。

动态加载 Skills

当任务涉及特定框架或工具时，Quest 会动态加载对应的 Skills。Skills 封装了经过验证的工程实践，例如：TypeScript 配置最佳实践、React 状态管理模式、数据库索引常见陷阱、API 设计规范。

这不是让模型每次都从零开始推理，而是直接复用沉淀下来的工程经验。团队也可以将自身的工程规范封装成 Skills，让 Quest 按照团队的方式工作，例如：代码风格指南、Git 提交规范、测试覆盖率要求、安全审查清单。

智能模型路由

当单一模型的能力不足以覆盖任务需求时，Quest 会自动调度多个模型协同工作。有的模型擅长推理，有的擅长写作，有的擅长处理长上下文。

智能路由会根据子任务的特性选择最合适的模型，对用户而言，面对的始终是一个统一的 Quest。

多 Agent 架构

当任务复杂到需要并行推进、分模块处理时，Quest 会启动多 Agent 架构：主 Agent 负责规划和协调，子 Agent 执行具体任务。但这个能力被克制地使用。因为多 Agent 并非银弹，上下文传递存在损耗，任务拆分的门槛也较高。只在确实必要时才启用。

为未来模型而设计

Quest 从第一天起就是为最先进的（SOTA）模型而设计的。其架构不是为了给过去的模型打补丁，而是确保随着底层模型能力的提升，Agent 的能力也能水涨船高。

这就是为什么 Quest 没有提供模型选择器。用户不需要在不同模型间纠结，这个决策由系统自动完成。用户只需描述任务，Quest 负责调度最合适的能力来完成它。

换句话说，Quest 不是适配今天模型的 Agent，而是为 6 个月后的模型准备的 Agent。

为什么不暴露文件编辑过程

Quest 没有文件树，也不支持用户直接修改文件。这是一个反直觉的产品决策。

许多 Coding Agent 会实时展示每次文件修改，让用户随时可以介入编辑。Quest 选择不这样做，原因有三：

1. 不打断 Agent 的执行心流。用户介入会打断任务的连贯执行，也容易引入不一致性。
2. 让用户从“盯代码”转向“关注问题本身”。既然目标是自主编程，就应该让用户将注意力放在需求定义和结果审查上。
3. 这是自主编程的发展方向。未来的用户关心的是“任务完成了没有”，而不是“这行代码改了什么”。Quest 的界面围绕最终产物设计，而非围绕执行过程。

自进化：越用越强

Quest 的一项技术突破在于其自主进化能力。它能深度分析项目的代码结构、架构演进、团队规范，并将这些信息内化为“项目理解”。

具体表现为：

• 理解项目模块划分和依赖关系
• 识别代码风格和命名习惯
• 学习项目特定的架构模式
• 掌握团队的工程实践

面对陌生的 API 或新框架，Quest 会通过探索和实践进行自我学习：阅读文档、尝试调用、分析错误、调整方案。使用时间越长，它对项目的理解就越深，表现也越好。

Skills 系统进一步扩展了这种能力。团队可以将工程规范、常用模式封装成 Skills，让 Quest 持续习得新技能。Quest 不仅执行任务，还会在执行过程中不断学习。

我们用 Quest 构建 Quest

Quest 团队自身就是 Quest 的深度用户。文章开头提到的“用 Quest 重构 Quest”并非案例包装，而是日常工作的真实写照。

在产品邀请测试阶段，用户就曾通过 Quest 处理过 80 万镜像的构建、验证与校验，也用它画过原型图、做过设计稿，还完成过长达 26 小时的长程任务构建。Quest 正在改变我们自己的工作方式。

在工程架构上，我们保持了足够的容错和泛化能力。一个常见的诱惑是：为了某个产品效果而在工程上做妥协，把 Agent 做成固化的 Workflow。Quest 的选择是：产品展示从用户视角出发，工程实践则坚定地采用 Agentic 架构。这样不会限制模型能力的发挥，也为未来的模型升级做好了准备。

从结对到自主

AI 辅助编程大致经历了三个阶段：代码补全、结对编程、自主编程。Quest 正在探索第三阶段的可能性。

当开发者的角色从“代码编写者”转变为“意图定义者”，软件开发的范式将发生根本性的改变。开发者将从繁琐的编码细节中解放出来，专注于更高层次的问题定义和架构设计。

这就是 Quest 正在构建的未来：一个能够自进化、真正实现自主编程的 Coding Agent。