上周，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 是最佳拍档

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

Bash 的三个优势

大而全。Bash 几乎能完成所有系统级操作：文件管理、进程控制、网络请求、文本处理、Git 操作。一个工具覆盖大部分场景，模型无需在众多工具中选择。

可编程、可组合。管道、重定向和脚本机制让简单命令组合成复杂工作流。这与 Agent 的任务拆解高度契合：将大任务拆成小步骤，每个步骤用一行或几行命令完成。

模型天生熟悉。大模型预训练时已见过大量 Unix 命令和 Shell 脚本。遇到问题时，模型往往能自行找到解决路径，无需在 Prompt 中详细教学。

Less is More

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

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

Agent Loop：Spec > Coding > Verify

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

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

Spec 驱动的开发流程

Spec 阶段：动手前先澄清需求，明确验收标准。对于复杂任务，Quest 生成详细技术规格书，确保双方对"完成"的定义达成共识。

Spec 包含的要素：

• 功能描述：实现什么功能
• 验收标准：如何判断完成
• 技术约束：使用哪些技术栈、遵循哪些规范
• 测试要求：需要通过哪些测试

Coding 阶段：根据 Spec 实现功能。这个阶段 Quest 自主推进，无需用户持续监督。

Verify 阶段：自动运行测试，验证实现是否符合 Spec。验证类型包括语法检查、单元测试、集成测试等。如果不符合，自动进入下一轮迭代，而非把问题抛给用户。

整个流程可以抽象为：

whilenot 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 选择不这样做，原因有三：

不打断 Agent 的执行心流。用户介入会打断任务连贯执行，也容易引入不一致。

让用户从"盯代码"转向"关注问题本身"。既然目标是自主编程，就应该让用户将注意力放在需求定义和结果审查上。

这是自主编程的发展方向。未来用户关心的是"任务完成了没有"，而不是"这行代码改了什么"。Quest 的界面围绕最终产物设计，而非围绕执行过程。

自进化：越用越强

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

具体表现为：

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

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

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

我们用 Quest 构建 Quest

Quest 团队自己是 Quest 的深度用户。文章开头提到的"用 Quest 重构 Quest"不是案例包装，而是日常工作的真实写照。

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

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

从结对到自主

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

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

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

来源  |  阿里云开发者公众号