Tashan Cursor Skills

他山 Cursor Skill 体系 Tashan Cursor Skill System — Self-Evolving Agent Harness

什么是 Harness • 我们的不同 • 三大闭环 • 进化飞轮 • 场景示例 • 认知体系 • Skill自循环 • Skill 速查 • 安装 • English

---

什么是 Agent Harness

模型是马力，套具是方向。The model is commodity. The harness is moat.

2026 年，大模型能力已趋于饱和——对于代码生成、文档撰写、分析推理等大多数任务，主流模型之间的差距已非瓶颈。真正的差距在于你围绕模型构建的执行套具（Agent Harness）。

Harness 是包裹在模型外层的运行时治理层，它决定：该调用什么工具、该验证什么输出、该记住什么上下文、该在什么条件下停止。没有 harness，模型只是一匹强壮但方向不定的马；有了 harness，马力才能转化为可靠、可控、可预期的工作。

---

这套 Harness 是如何构建的

这套体系围绕一个核心机制构建：执行中涌现的经验，自动更新 Harness 本身。

每次任务完成后，session-bootstrap Rule 强制执行 D5 信号感知：踩坑变成 Skill 步骤警告，洞见变成认知碎片，流程空白变成待建的新 Skill。三层结构同步更新，下一次执行就是在更完善的 Harness 上运行。

Harness 由三层构成，六条通路把它们连接成自我进化的整体：

---

三大闭环架构

整套体系由三个相互连接的闭环构成，六条通路让它们形成自我进化的整体：

六条通路说明：

通路	方向	触发机制	效果
A	Loop2 → Loop3	任务开始，读取认知根（D0-B）	用方法论指导当次任务，而非凭感觉
B	Loop3 → Loop2	D信号（洞见）→ cognitive-capture-fragment	工作洞见沉淀为认知碎片
C	Loop1 → Loop3	Skill 版本更新后，下次读取新版	上次沉淀的经验，这次自动应用
D	Loop3 → Loop1	E信号（缺口）→ PENDING-SKILLS	工作中发现缺少某类能力 → 建新 Skill
E	Loop2 → Loop1	L1文档更新后，Grep 找依赖 Skill → 更新 D0-B	认知进化驱动 Skill 方法论同步
F	Loop1 → Loop2	B信号重复3次 → 认知层反思	持续失败模式触发方法论层面的重审

---

自我进化飞轮

每次任务完成后，session-bootstrap Rule 强制执行 D5 信号感知，将执行结果路由到对应的更新通道：

五类信号及其处置：

信号	触发条件	自动处置
A 踩坑	出现预期外失败 / 已知问题再次发生	立即追加到对应 Skill 步骤的警告区
B 意外行为	Skill 未按预期执行	记录到 PENDING-SKILLS，等 skill-system-health-check 处理
D 洞见	发现有价值的新认知	cognitive-capture-fragment → L2 碎片 → 定期整合进 L1
E 流程缺口	发现缺少某类执行能力	PENDING-SKILLS → skill-designer 建新 Skill
G 结构性根因	某问题第3次出现，根因是架构/规范缺陷	PENDING-PROPOSALS [HUMAN-REQUIRED] → 人工确认 → 规范更新

---

三个完整闭环场景

场景一：开发一个新功能

产出物：

产出物	文件	类型
产品规格	产品定义.md（含功能状态表）	K4 K-object
技术方案	技术架构.md + decision-log 追加	K4 K-object
实现代码	代码文件	实现产物
验收报告	测试报告.md	S1* 审计对象
关卡报告	关卡A/B/C审核报告.md	S1* 只读审计

完整闭环：

[开始前：通路A — 认知根激活]
role-产品经理 Step D0：
  读取「AI时代产品设计原则」（L1认知文档）
  确认认知根：「本次产品设计基于 §三：闭环完整性原则」

[执行阶段]
产品定义 → [关卡A：user-simulator 独立视角] → 技术架构
         → [关卡B：arch-destroyer 破坏者视角] → 并行开发
         → [关卡C：verifier 独立验证] → 上线

[任务完成后：D5信号自动路由]
  A信号（踩坑）→ 追加到 role-后端开发 Skill 踩坑速查
  D信号（洞见）→ L2碎片 → 整合进「AI架构参考.md」→ 更新 Skill D0-B
  E信号（缺口）→ PENDING-SKILLS → skill-designer 建新 Skill

这个场景的闭环价值：第1次做功能时踩坑的 Redis 用法，自动变成了第2次的「架构师最佳实践」，不需要人工记录和传递。

---

场景二：修复一个 Bug

产出物：

产出物	文件	类型
Bug记录	bug-log.md（追加）	S-object，只追加
修复代码	代码文件	实现产物
追踪台更新	技术问题追踪台.md	K4 K-object
工程原则（若有）	研发规范.md 或 Skill 步骤	K3 K-object 或 B-object

完整闭环：

[开始前：通路A]
fixer 子智能体 Step D0：
  读取产品定义.md → 「确认：修复必须符合产品意图，不能只图技术方便」
  [product-alignment-guard Rule 强制执行]

[执行阶段：TDD修复循环]
issue-tracker 分类 → P0/P1 技术Bug
bug-fix-loop-coordinator 读追踪台 → dispatch fixer
  循环：
    fixer → Step1: 写失败测试（先确认能复现）
           → Step2: 修复代码（让测试通过）
           → Step3: CI 验证
           → Step4: 更新追踪台状态
  → verifier 独立回归验证

[任务完成后：D5信号分流]
  A信号（踩坑）→ 追加到 role-DevOps Skill 踩坑速查
  G信号（结构性根因）→ PENDING-PROPOSALS [人工确认] → 研发规范.md 更新
                     → [通路E] 通知依赖此规范的 Skill 重新对齐

这个场景的闭环价值：同类 Bug 的第3次出现变成了架构规范的一部分，第4次在设计阶段就被拦截。

---

场景三：积累一个认知洞见

产出物：