团队给 Coding Agent 装了一堆 slash commands、skills、rules，换一个模型或换一个会话，行为就漂。问题通常不在「少一条提示词」，而在于：这些资产没有挂在稳定的流程骨架上，也没有明确的入口、自主度与停止条件。

散落的插件包不是 User Harness。Harness Engineering 说的是控制系统；本文讲的是把控制系统落成可扩展工具框架——ai4se-harness。

一句话主旨：入口 = 四类工作项 Command × 三类 Profile；执行 = 三道 Gate Agent 挂在 P0–P5 上。方法与门禁不变，变的是资产包与人机协作深度。

Core 骨架：P0–P5 与三道质量门

ai4se-harness 的 Core 不是另起一套方法论，而是承接 SDD 端到端实践指导手册中的阶段流。用户态资产都挂在这条骨架上：

阶段名称关键产出相关门禁
P0基线与初始化Specs 库、Rules 载体、知识目录就位—
P1意图发现与提案proposal.md（范围/非范围/假设）—
P2Spec 定义与对齐Delta Spec、验收场景G1 Align
P3设计与任务分解design、tasks、验收设计—
P4实现与验证实现、测试、验证报告G2 Verify
P5沉淀与演进Living Spec 合并、归档、资产改进G3 Merge & Archive

三道门的拦截目标不同，也对应不同的重做成本：

Gate问什么拦截什么
G1 Align「正确」长什么样？方向性错误（改文字，成本最低）
G2 Verify是否按 Spec 做对？执行性错误（改代码，成本中等）
G3 Merge & Archive学到的是否留下来、真相源是否自洽？一致性与沉淀缺失（伤长期）

Profile 可以改变确认频率，不能放宽 Gate 的 DoV（Definition of Verified）。Spec 作为真相源的原则见 Spec 作为真相源。

零层架构：User 资产包挂在 Core 流上

零层把系统切成上下两层：上方 User（用户态） 持有可扩展资产包；下方 Core（核心态） 提供 SDD 流程能力，并向上支撑对应资产。

零层架构：User Assets 与 Core Workflow

读法：

  1. 分层：User 管定制面；Core 管流程引擎与缺省能力。
  2. 一一对应：一类 Core 流对应一组 User Assets（缺省流 ↔ 标准资产包；定制流 ↔ 精益/敏捷/混态等模态包）。
  3. 可扩展：Assets 与 Workflow 都可横向追加，而不必改核心引擎。

站内 项目知识层 谈的是 Guides 里「知道什么」；本文谈的是整包资产如何与阶段流绑定。

用户态：五大资产与调用 / 治理边界

要对齐 Claude Code / Cursor / Codex 一类 Coding Agent 的常见分层：

用户态结构：Command、Agent、Skill、Tools 与 Rules

资产角色业界对应
Command薄入口：把工作项规整成可流动的 Change Requestslash command / 命令入口
Agent目标驱动循环：规划 → 选 Skill/工具 → 执行 → 观察Agent / sub-agent loop
Skill可复用能力包（提示、步骤、上下文与工具用法）Skills / prompt+tool bundles
MCP / CLI / API具体执行面MCP servers、shell、HTTP
Rules横切治理：约束决策、边界与工具权限CLAUDE.md / .cursor/rules / AGENTS.md

关系约束：

  1. 主路径是 Command → Agent；Command 直触 Skill 只适合轻量场景。
  2. Agent 是编排者：可调 Skill，也可直调 MCP / CLI / API。
  3. Skill 不是必经中间层；需要执行时仍落到工具面。
  4. Rules 不在调用链上，而是横切约束执行栈——对应 Harness 里的 Guides / Permissions 面。

目标不是锁死单一调用链，而是 三者各自可独立存在，又能按需组合。

三层 Flow：薄入口、厚执行、平台骨架

系统里有三层可配置工作流，厚度与归属不同：

三层 Flow：Command / Agent / Core

层级Flow厚度说明
CommandCommand Flow薄入口编排：触发 Agent / Skill，选定 Profile
AgentAgent Flow厚目标驱动：规划、调 Skill/工具、循环至 Gate
CoreAI4SE Workflow平台级P0 ~ Ps 缺省流 / 模态定制流

Command 决定「从哪类工作项进场」；Agent 决定「如何冲向某个 Gate」；Core 决定「阶段骨架与门禁标准」。三者各自的 workflow 可独立配置——这与 Loop Engineering 的「跨轮契约」互补：Loop 管值得循环什么，Harness 管单次如何可靠地跑。

解耦类比：Command ≈ Controller

用程序员熟悉的分层表达解耦意图（点到为止）：

参照 Spring MVC：Command / Agent / Skill

ai4se-harness类比Spring
Command→Controller
Agent→Service
Skill→Method

设计初衷：

  1. Skill 是原子能力，可单独执行，也可被 Agent 编排。
  2. Agent 目标驱动，可单独跑，也可再被编排。
  3. Command 可触 Skill、可触单个 Agent，也可编排 Agents + Skills。

一旦三者粘死成一条硬编码流水线，扩展成本会立刻回到「再写一个巨型 prompt」。

Command 设计：四类工作项

Command 面向常见工作项，提供少量、稳定、可记忆的经典入口。职责不是直接「写代码」，而是把输入规整成可进 P0–P5 的 Change Request，并帮助选择执行 Profile。

工作项Command典型输入目标
需求/ai4se:requirement一句话需求、链接、产品文档、Issue形成 Proposal / Delta Spec 起点，进入澄清与 G1
缺陷/ai4se:defect复现步骤、日志、截图、Bug 链接缺陷型变更：先定影响范围，再验证驱动修复
Hotfix/ai4se:hotfix事故、告警、回滚约束收敛版流程：控风险、验证修复、保留归档
技术债/ai4se:tech-debt模块路径、重构目标、质量指标改进型变更：明确收益、边界与回归要求

示例：

/ai4se:requirement "支持用户通过手机号登录"
/ai4se:requirement https://example.com/product/req-123
/ai4se:requirement --profile strict "支持用户通过手机号登录"
/ai4se:defect --profile yolo ISSUE-456
/ai4se:hotfix --profile strict "线上支付回调偶发超时，需要限域修复"
/ai4se:tech-debt "重构订单模块的状态机，降低分支复杂度"

用户可以只给 Command + 工作项内容；AI 根据复杂度、影响范围、风险、上下文充分度、验证可得性等推荐 Profile，并说明可选项。推荐不是强制——人类可接受，也可显式覆盖。

三类 Profile：控自主度，不改门禁

三类 Profile 类似驾驶辅助等级，用来调节 AI 自主度与人工确认点，也对应 HITL / HOTL 谱系上的深度选择：

Profile类比自主度适用场景人类介入
strictL1 辅助驾驶低高风险、边界不清、生产 Hotfix关键决策均需确认，默认不越权
copilotL2 共同驾驶中常规需求、缺陷、技术债AI 推进主流程，Gate/风险点请求确认
yoloL3 条件自动驾驶高低风险、边界清晰、验证充分Rules 内自主推进，到 Gate 或异常停下

无论推荐还是覆盖，最终仍须满足对应 Gate 的通过标准。加快推进 ≠ 跳过 G1/G2/G3。

Gate Agent：目标驱动，而不是跑完步骤

Agent 采用 Goal Driven 设计：理解上下文 → 规划 → 调 Skill/工具 → 观察 → 在达到 Gate 标准前持续迭代。Done 条件是 Gate 通过，不是「步骤清单勾完」。

结合端到端流程，核心是三类 Gate Agent：

Agent职责区间目标 Gate目标典型产出
AlignGateAgentP1 → P2（G1）G1 Align模糊需求 → 完整、精确、可验证、无冲突的 Delta Specproposal、Delta Spec、验收场景、G1 报告
VerifyGateAgentG1 → P4（G2）G2 VerifySpec → 设计/任务/实现验证，忠实于 Specdesign、tasks、测试与验证报告、G2 结论
ArchiveGateAgentG2 → G3G3 Merge & Archive合并 Delta、归档历史、沉淀可复用资产更新后的 specs/、归档、经验与资产建议

边界原则：

  1. 职责区间不同：不要让一个 Agent 既写 Spec 又自裁 G2。
  2. 目标不同：G1 拦方向；G2 拦执行；G3 拦一致性与沉淀。
  3. 输入不同：意图/提案 vs 已对齐 Spec/代码 vs Delta/验证报告/全局 Specs。
  4. 停止条件不同：各自以对应 Gate 的 DoV 为 Done。
  5. Profile 可叠加：同一 Gate Agent 可在三种 Profile 下跑，只改自主度。

这与手册里「按阶段切六个 Agent」的直觉不同：过细切分会带来高昂的跨阶段交接成本。按 Gate 目标 聚合编排，更符合「冲关」而不是「报步骤」。

落盘形态：可扩展、可配置

Commands

Commands/
├── requirement/
│   ├── workflow.yml    # /ai4se:requirement 的入口编排
│   ├── command.md
│   ├── profiles.yml    # strict / copilot / yolo
│   └── res.yml         # 资产引用
├── defect/
├── hotfix/
└── tech-debt/

Agents

Agents/
├── AlignGateAgent/
│   ├── workflow.yml    # P1 → P2（G1）目标驱动循环
│   ├── agent.md
│   ├── goal.yml        # Gate 目标、停止条件、DoV
│   └── res.yml         # Skills / Rules / Tools 引用
├── VerifyGateAgent/
└── ArchiveGateAgent/

Skills

Skills/
├── SkillA/
│   ├── References/
│   └── skill.md
└── ...

约定：Command / Agent 可扩展，workflow 可配置；Skill 保持原子、少互依——互相纠缠的 Skill 图会把调试成本推回巨型 prompt。

迷你走读：一条 requirement 到 G3

以 /ai4se:requirement "支持用户通过手机号登录" 为例：

  1. Command Flow：规整为 Change Request；AI 推荐 copilot（常规需求、边界尚可澄清）；用户接受或 --profile strict 覆盖。
  2. AlignGateAgent（→ G1）：澄清范围/非范围，产出 proposal 与 Delta Spec；未过 G1 不得进入实现。
  3. P3 + VerifyGateAgent（→ G2）：设计与任务分解后实现与验证；本地/流水线证据不足则停在 G2，而不是「代码写完就算」。
  4. ArchiveGateAgent（→ G3）：合并 Living Spec、归档变更、提出 Skills/Rules 改进建议——把本轮学到的写回 User Harness。

全程 Core 的阶段骨架不变；变的是 Profile 下的确认密度，以及本团队 Assets Pack 里挂了哪些 Skill / Rules。

反模式

  • 只有 Skills，没有入口与 Gate：能力很多，但不知道从哪进、何时停。
  • 用 Profile 跳过门禁：yolo 变成「免检通道」。
  • 一个超级 Agent 包办 P1–P5：职责混杂，无法审计，也无法按 Gate 替换。
  • Skill 互相强依赖：原子性丢失，复用与测试成本飙升。
  • Core 与 User 搅在一起：改一个业务命令却要动流程引擎。
  • User Harness 只增不治理：规则与技能堆叠冲突——外环 Review 同样要覆盖 Harness 本身。

可执行清单

  1. 先固定 Core：团队是否认同 P0–P5 与 G1/G2/G3 的通过标准。
  2. 只提供四类经典 Command；其他入口证明高频后再加。
  3. 为每个 Command 配置 profiles.yml，默认推荐 + 允许覆盖。
  4. 按 Gate 落地三个 Agent，写清 goal.yml 中的 Done / DoV。
  5. Skills 按原子能力拆分，用 res.yml 引用，而不是复制粘贴进 Agent。
  6. 每次 G3 回顾：哪些 Rules/Skills 该升级、退役或新建——Steering Loop 改的是 Harness，不只是代码。

参考