v4.0 自适应工作流策略：Harness CLI 如何选择合适的工程流程¶
快速答案： Harness CLI v4.0 会先判断任务，再决定需要多少流程。问题和只读检查可以走
noop或direct；小而明确的本地修改走guarded；多步骤、风险较高、需要委派或需要恢复的目标走planned。计划状态另行判断为none、reuse或create，因此一句“继续”不会被误判成新任务。
当每个请求都触发同样的工程仪式时，AI 编程工具很快就会变得笨重。一行查询不应该生成工作项，而涉及文档、测试和交付证据的变更也不应该只依赖上下文记忆。v4.0 把这条边界变成了可解释、可检查的策略。
四种工作流路由¶
| 路由 | 适用场景 | 典型结果 |
|---|---|---|
noop |
空输入、确认语或没有可执行请求 | 不操作仓库 |
direct |
提问、只读分析、状态查询 | 基于证据的回答 |
guarded |
一个小而明确的本地变更 | 编辑门禁加定向验证 |
planned |
多步骤、不明确、高风险、委派或可恢复目标 | 持久化工作项和对应 playbook |
关键点是：路由是自适应的。“内容很长”不等于一定要 planned，“要改文件”也不等于一定要启动团队。应该根据范围和风险选择流程。
计划持久化是第二个判断¶
对于实质性请求，v4.0 会分别回答两个问题：
- 这次请求应该使用哪条路由？
- 计划状态应该怎么处理？
计划状态包括：
none：不创建，也不复用持久化计划。reuse：用户明确说“继续”或“恢复”时，继续一个符合条件的活动计划。create：为新的 planned 目标创建一个工作项。
这样可以避免一个常见错误：把“好的”“继续”或简短确认误当作全新的目标。同一会话中的确认可以留在当前工作项里；跨客户端继续则需要明确的恢复信号，并且只加载当前任务和必要的交接上下文。
planned 路由多了什么？¶
计划型工作流为任务增加了清晰的持久边界：
- 先分类目标并记录范围。
- 只选择相关 playbook，例如头脑风暴、编写计划、TDD 或系统化调试。
- 修改文件前先通过
pre-edit-safety-gate。 - 在宣称完成前保存可复核的验证证据。
planned 并不意味着每次都要组队。需要跨中断恢复的目标可以使用 solo harness；只有真正独立的领域才适合并行团队。存在共享状态或前后依赖的变更仍应顺序执行。
Dry run 不等于线上依赖可用¶
dry-run 可以检查配置、路由和任务输入是否合理，但不能证明外部模型供应商、浏览器会话、MCP 服务或登录账号已经可用。可靠的状态页应该明确区分：
- 配置已接受；
- 本地检查已通过；
- provider 或浏览器依赖可用；
- 仍需要人工批准。
这种区分既方便排障，也更容易让搜索引擎和答案引擎准确引用。
推荐的起步顺序¶
新检出仓库后，先使用统一初始化和诊断命令：
aios init --all
aios doctor --native --verbose
然后阅读工作流策略文档，按快速开始完成客户端设置；如果任务需要跨中断恢复，再看Solo Harness 指南。
常见问题¶
每次代码修改都需要创建计划吗？¶
不需要。小而明确的修改可以走 guarded 路由。只有存在多个依赖步骤、设计不清晰、风险明显、需要委派或需要稍后恢复时，才应该创建计划。
planned 是否等于必须组队？¶
不等于。planned 是工作流分类，实际可以在单个客户端、solo harness 或团队中执行，具体取决于依赖关系。
终止状态的计划还能继续吗？¶
不能。终止计划已经完成或被阻塞，不能被静默当成活动计划继续。应创建新目标，或明确恢复符合条件的非终止工作项。
去哪里看实现边界？¶
架构文档说明 CLI、ContextDB、客户端投影和运行时状态的关系；故障排查把常见路由和验证失败映射到下一步动作。
这套策略有意保持简单：小任务少一点流程，真正需要可靠性的任务多一点持久证据。