资讯详情

在 VS Code 与 cn CLI 上运行 Continue.dev 循环工程:primitive 映射、无头调度与 maker/checker 实践

📅 2026/9/24 1:31:08 | 华诺云谱 👁 阅读
在 VS Code 与 cn CLI 上运行 Continue.dev 循环工程:primitive 映射、无头调度与 maker/checker 实践
人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载导读本文围绕 loop-engineering 仓库中 primitives-matrix.md 的 Continue.dev 附录展开为使用VS Code Continue 扩展或cn无头 CLI的贡献者提供一套可直接落地的循环工程loop engineering映射方案。你将掌握如何用 cron/systemd/GitHub Actions 调度 Continue 无头任务、如何用.continue/rules/承载可复用指令、如何用提交到仓库的STATE.md作为跨运行状态脊柱以及如何用两个独立的cn会话实现 maker/checker 分离——并在每一步同时看到该 primitive 在 Continue 中是一等公民还是需要手动补全的诚实结论。背景Issue 要求与文档落点仓库中的 scripts/issue-bodies/continue-dev-matrix.md 是一份面向贡献者的 issue 正文模板它明确要求在 primitives matrix 中为使用VS Code Continue的贡献者新增Continue.dev 列或独立附录覆盖调度scheduling、skills 路径、STATE.md约定、maker/checker 分工四个核心 primitive对 Continue 尚未一等公民化的 primitive 给出诚实标注提供一条可直接复制粘贴的report-only 周一直报week-one Daily Triage命令。该 issue 的验收产物已经落地在 docs/primitives-matrix.md 的## Appendix: Continue.dev一节。本文以该附录为主体骨架结合仓库内的 skill 模板、状态文件示例与安全护栏把这张映射表展开为一份可操作的实战指南。Continue 的两种运行表面IDE 扩展与cn无头 CLIContinue 同时提供 VS Code 扩展与cnCLI。两种表面在循环工程中的定位完全不同表面适合的场景不适合的场景VS Code 扩展有人值守的 Agent / Plan 会话、交互式评审无人值守的定时运行cn无头 CLI一条提示执行到完成并输出最终结果可被外部调度器反复调用需要交互式上下文的多轮会话从 primitives-matrix.md 的附录来看循环工程的可移植表面是无头模式cn -p ...单次运行一个提示直至完成并打印最终响应。这意味着Continue 的调度责任天然落在外部——cron、systemd timer 或 GitHub Actions——而不是 Continue 自身。Primitive 映射总览Continue.dev 在矩阵中的位置下表是附录给出的完整映射也是后续各节的索引PrimitiveContinue.dev 映射Scheduling调度无一等公民的持久调度器。用 cron / systemd / GitHub Actions 调用cn -p ...把提示、配置、状态文件都放进仓库保证每次运行从同一份契约出发Run-until-donecn -p 有边界的goal和停止条件单次无头运行到完成在提示里写显式校验并安排一次独立的 verifier 运行。Continue 没有跨任意重启存活的/goal式持久目标Skills常驻项目指引放.continue/rules/或在启动时用--rule/--agent加载仓库根AGENTS.md可放可移植指令但 Continue 的原生可复用指引原语是 Rules而不是SKILL.mdWorktrees无内建隔离。每个任务创建标准git worktree在每个 worktree 中启动一个cn进程各自独立评审分支Sub-agents / maker-checker无原生子代理团队或专用 verifier 角色。maker 与 checker 用两个独立cn会话最好在不同 worktreechecker 只读并持有当前 diff。TUI 的/fork只是 fork 对话历史不是隔离的编码 workerState / memorycn --resume可恢复历史会话但可移植的循环状态应放在提交的STATE.md让每个定时提示都读取它会话历史只作便利不能当作唯一的持久队列或审计轨迹Plugins / MCP在config.yaml/.continue/mcpServers配置 MCP 服务器用--mcp附加用--allow、--ask、--exclude限制工具。凭据放在环境变量后端绝不进提示或STATE.md诚实缺口无原生 cron 调度器、无跨运行的持久 goal、无自动 worktree 隔离、无一等公民子代理、无内建状态文件约定。Continue 上游仓库在最终 2.0.0 发布后只读因此要固定版本并校验周边自动化从源码结构看这个映射遵循了 primitives-matrix.md 开篇的原则能力capability才是关键产品名不是——同一个 loop 形状可以在八个 agent 环境之间迁移Continue 只是其中一个宿主。第一周落地report-only Daily Triage附录给出的第一周命令是整个映射中最可复制的部分。它不要求任何写权限shell 只产出报告工件cn -p --readonly --silent Run a Daily Triage for this repository. Read AGENTS.md and STATE.md if they exist, inspect the current git status and diff, and report High Priority items, Watch List items, and evidence for each finding. Do not edit files, run fixes, commit, push, or open issues or pull requests. continue-daily-triage-report.md关键点拆解--readonly把 Continue 限制为只读模式从机制上保证它无法改文件--silent抑制交互式输出适合被调度器静默调用输出重定向 continue-daily-triage-report.md由 shell 写报告工件Continue 本身保持只读人工门槛把任何条目提升为实现之前先人工评审报告。这里的读取STATE.md不是空话——仓库的 starters/minimal-loop/STATE.md.example 给出了标准状态脊柱Last run、High Priority、Watch List、Recent Noise、Post-Run Critique与Run log六段结构。report-only 模式下只更新 High Priority 与 Watch List 两段其余保持不动从而形成每次运行读取同一份状态、只更新相关段落、保留历史的可审计闭环。与 skill 模板的对应关系Daily Triage 的提示内容与 templates/SKILL.md.loop-triage 定义的输出契约完全同构High-Priority Items行动项、Watch Items仅监控、Noise / Ignore忽略项、State Updates留给下一次运行的记忆。Continue 场景下的差异只在于加载方式——Continue 用.continue/rules/或--rule加载常驻指引而不是像 Grok/Claude 那样把SKILL.md放到 skills 目录。如果你同时维护多个宿主可以把同一份 loop-triage 内容放进AGENTS.md做可移植载体再用 Continue Rules 做原生增强二者并不冲突。L2 进阶maker/checker 分离与 worktree 隔离Continue 没有原生子代理团队也没有专门的 verifier 角色因此 maker/checker 分离需要退回到两个独立会话的模式。附录给出的 L2 交接流程是在专用 worktree 中运行 maker只授予完成该任务所需的最小写权限在该 worktree 中启动一个全新的cn --readonly会话让 checker 只读地评审git diff、STATE.md与 issue 验收标准不编辑任何文件。配套的 worktree 操作是标准 git 流程git worktree add ../task-pr-1234 -b task/pr-1234 cd ../task-pr-1234 # 在此 worktree 中运行 maker 的 cn 会话 git diff diff.patch # 交给 checker 会话这与 docs/safety.md 中的工作树隔离理念一脉相承仓库还提供了 tools/loop-sandbox 做临时 worktree 隔离、把变更捕获为可评审补丁以及 tools/loop-swarm 做多代理一致性沙箱——对 Continue 这类无内建 worktree的宿主这些 CLI 工具恰好补上了机制层面的隔离。诚实缺口为什么必须手动附录明确标注了 Continue 的四类缺口无原生 cron 调度器、无跨运行的持久 goal、无自动 worktree 隔离、无一等公民子代理。这带来三个实操推论调度契约必须在仓库里提示文本、config.yaml、STATE.md全部提交让 cron 每次运行都从同一份契约出发而不是依赖本地会话历史cn --resume只能当便利手段恢复历史会话不等于恢复循环状态STATE.md才是唯一可移植的队列与审计轨迹/fork不是隔离TUI 的 fork 只复制对话历史不能当作隔离的编码 worker。此外附录提醒Continue 上游仓库在最终 2.0.0 发布后处于只读状态因此固定版本号并校验任何外部自动化是部署前的必要动作。用--rule/--agent与--mcp组合出常驻能力Continue 的 primitive 承载方式与其它宿主不同但组合起来可以覆盖大部分循环能力常驻指引把仓库约定放进.continue/rules/或用--rule在启动时加载把可移植指令放进AGENTS.md启动加载--agent可预先加载特定 agent 配置MCP 连接在config.yaml或.continue/mcpServers声明服务器--mcp附加再配合--allow/--ask/--exclude收紧工具权限凭据边界密钥、认证、计费、部署与破坏性数据路径必须走环境变量后端并在每次运行前显式审批绝不允许进入提示或STATE.md。这与仓库自带的 MCP 示例配置 examples/mcp/loop-engineering.mcp.json 的约定一致——MCP 服务器通过npx启动、LOOP_PROJECT_ROOT指定项目根运行时把 patterns/skills/state/budget/safety 文档作为可查询资源减少提示注入prompt stuffing。参考服务器实现在 tools/mcp-server。安全护栏人工门槛与权限边界附录在 L2 部分给出了一条强制要求Human gateL2在启用写工具或开 PR 之前必须有人审批选中的 issue、允许的路径、校验计划、最终 diff。把密钥、认证、计费、部署和破坏性数据路径放在每次运行的显式审批之后并使用独立的只读 checker 会话。这与 docs/safety.md 的护栏体系完全一致路径 denylist**/.env*、**/secrets/**、**/auth/**、**/payments/**、**/billing/**、**/k8s/production/**等路径在无人值守循环中默认不可自动编辑report-only 不是权限边界只读提示必须配合只读工具权限--readonly与关闭自动批准二者缺一不可状态文件即审计轨迹STATE.md通常会被提交因此其中绝不能出现凭据CI 日志可能泄露密钥triage 技能在写状态前应做脱敏。对 Continue 而言report-only由--readonly标志在机制层面保证而不是依赖提示文本的自觉——这是把安全从约定升级为机制的关键一步。迁移到其它宿主的路径Continue.dev 附录并非孤立存在它是 docs/primitives-matrix.md 中一系列 editor/CLI 附录之一Codeium/Windsurf、Aider、Roo Code、Cline、Zed、Gemini CLI、GitHub Copilot、Amazon Q、Devin 均有同构映射。如果未来迁移宿主Choosing a Tool 一节给出的四步转移法依然适用写skill工具无关的SKILL.md或规则内容定义state schemamarkdown 或 JSON记录verification split谁检查谁把调度映射到当前 TUI、编辑器或 Action。以 Continue 为起点的迁移通常意味着把.continue/rules/内容抽回工具无关的SKILL.md、把STATE.md保留在仓库根、再把调度从 cron 改写成目标宿主的原生原语。仓库的 examples/ 目录展示了同一套 pattern 在 Grok、Claude Code、Codex、Cursor、Windsurf、Opencode、Hermes 与 GitHub Actions 中的不同实现可以当作迁移对照表。小结Continue.dev 作为循环宿主的能力画像可以浓缩为调度靠外部、知识靠 Rules、状态靠STATE.md、分离靠双会话。它没有一个开箱即用的 loop 调度器但它的无头cnCLI、--readonly权限机制、.continue/rules/常驻指引和--mcp/--allow工具治理足以在外部 cron 的驱动下跑出第一周的 report-only triage并在一套明确的人工门槛之上逐步升级到 L2 maker/checker 流程。任何Continue 缺什么的疑问都可以回到 primitives-matrix.md 的附录去对照验证——那里的诚实缺口标注本身就是设计时最重要的输入。赞分享人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务【免费下载链接】loop-engineeringPractical patterns, starters CLI tools for loop engineering with AI coding agents. Design systems that prompt and orchestrate agents (inspired by Addy Osmani and Boris Cherny). Includes loop-audit, loop-init, loop-cost.项目地址https://gitcode.com/gh_mirrors/lo/loop-engineering点击查看免费下载相关推荐Codeium / Windsurf 在 Primitives Matrix 中的循环原语映射用 Cascade 搭建 Daily Triage 与 Maker/Checker 分离Codeium / Windsurf 在 Primitives Matrix 中的循环原语映射用 Cascade 搭建 Daily Triage 与 Make人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务用 Claude Code 落地 Daily Triage 循环loop-engineering 的调度、状态与 maker/checker 实战指南用 Claude Code 落地 Daily Triage 循环loop engineering 的调度、状态与 maker/checker 实战指南 Dai人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务Cline 原语矩阵在 loop-engineering 中把 VS Code Agent 映射为循环宿主Cline 原语矩阵在 loop engineering 中把 VS Code Agent 映射为循环宿主 导读 本文围绕 loop engineering人工智能AI AgentAgent 工作流CLI研发协作AI 技能MCP 服务创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。