HiPilot Skill 沉淀算法外显

初中生也能懂的版本 plain summary

把 Skill 想成“可复用做题方法”

一次聊天里的回答，可能只是“这道题的答案”；Skill 不是答案本身，而是下次遇到类似题目时还能继续用的“解题步骤”。

所以系统不是看到工具调用多就保存，而是先问：这是不是一个可靠流程？用户是不是明确想保存？里面有没有错、没查到、口径不确定？

1

先检查有没有坏信号

如果工具失败、数据没拿到、用户说“你错了”，就像草稿纸上有错题，不能直接变成方法。

2

用户明确说“存成 Skill”才主动保存

只有真实用户消息里说了“沉淀/保存/封装成 Skill/流程”，系统才会给聊天里放保存卡片。

3

查数和口径不确定要贴“需确认”

这种流程可以保存，但不能装作完全可靠；保存前要提醒用户检查口径。

4

用户没说保存时，系统只偷偷记分

同类干净流程反复出现，系统先记 observation 和 candidate，不打扰用户。

5

重复够多才进 SkillsTab 草稿

同类流程 5 次左右都稳定，才静默生成一个草稿放到 SkillsTab「Agent沉淀」，聊天里不弹窗。

总流程图 runtime + policy + reviewer

input

用户 prompt 进入 Agent DM

AgentRun 执行，产生 source_message、tool_use/tool_result WAL、AgentRun.output 或 agent message 最终回复。

policy

Skill Sediment Policy 读取证据

真实用户消息：判断 explicit_request、correction、intent_signature。
工具轨迹：canonical tool names、错误、数据/ontology/research 分类。
最终回复：判断 uncertain 措辞；必要时给 Haiku classifier 截断摘要。

if hard

risk_level = hard

block，不生成草稿。记录 observation；如果同 key candidate 已存在，则 suppress。

elif explicit

真实用户明确要求沉淀

active 开关打开且是 native Agent DM 时，生成 pending UserSkillDraft，并在聊天挂 skill_proposal 卡片。

else passive

未明确要求，进入静默观察

observe/reviewer 开关打开时，记录 observation；clean research/workflow 才能聚合 candidate。

soft draft

主动 + soft risk

仍可生成草稿，但 trigger_context 和卡片写入 risk_level=soft、risk_reasons，用户看到“需确认”。

normal draft

主动 + clean

生成普通 pending 草稿。用户点“保存 Skill”后才正式进入“我的”。刷新后卡片状态由后端持久化。

candidate

被动 candidate 聚合

data_query 不建 candidate；soft 不建也不 suppress；hard suppress；clean research/workflow/unknown 按 candidate_key 累计。

auto gate

成熟 candidate 自动草稿

seen_count >= 5
14 天内 supporting observations >= 5
task_kind 是 research/workflow
negative_signal_count = 0
有 intent_signature_hash

quiet

只进 SkillsTab「Agent沉淀」

后台 reviewer 创建 UserSkillReviewJob，packager 生成 auto_generated UserSkillDraft；不发聊天消息，不挂聊天卡片。

guardrail

失败兜底

Haiku 失败、JSON 非法、证据不足都回落确定性规则；LLM 不能覆盖 terminal tool/data failure 或明确纠错。

If / Else 主逻辑 human-readable

用户 prompt → AgentRun → tool trace / final answer
→ evaluate_user_skill_sediment_policy(...)

if risk_level == "hard":
    decision = "block"
    不生成 UserSkillDraft
    只记录 observation
    若已有同 key candidate → suppressed

elif task_kind == "data_query" and not explicit_request:
    decision = "block"
    查数不自动沉淀

elif explicit_request:
    decision = "allow"
    if active 开关未开:
        SKILL_SEDIMENT_DISABLED
    elif 非 native Agent DM:
        TOOL_NOT_AVAILABLE_IN_SOURCE
    elif risk_level == "soft":
        生成 pending draft + 聊天卡片「需确认」
    else:
        生成 pending draft + 普通聊天卡片

elif high_tool_count or semantic_reusable_workflow:
    decision = "observe"
    记录 observation
    clean research/workflow 聚合 candidate
    mature gate 通过后静默生成 SkillsTab 草稿

else:
    decision = "block"
    reasons = ["insufficient_signal"]
    忽略，不打扰

三个开关全开时 QA mode

`USER_SKILL_ACTIVE_SEDIMENT_ENABLED`

注册 propose_skill_from_recent_turns runtime tool。只有真实用户当前消息包含沉淀强信号时，才允许生成聊天卡片草稿。

`USER_SKILL_SEDIMENT_OBSERVE_ENABLED`

启动 user-skill reviewer worker，并允许把每次 policy 判定落成 observation，用于候选聚合。

`USER_SKILL_REVIEWER_ENABLED`

允许成熟 candidate 创建 review job，并由 packager 静默生成 SkillsTab「Agent沉淀」草稿。

Policy 输出字段怎么来的 function vs LLM

输出字段	判断方式	关键规则	来源代码
explicit_request	确定性 regex	只看真实 human message / explicit_message_text 是否命中“沉淀、保存、封装、打包 + Skill/技能/流程”。LLM hint 不算。	`has_explicit_skill_sediment_request` `EXPLICIT_SKILL_REQUEST_RE`
task_kind	工具分类Haiku 兜底	data/ontology tool → data_query；research tool → research；高 tool count → workflow；模糊被动场景可由 Haiku 返回 data_query/research/workflow。	`_is_data_query_tool` `_is_research_tool` `classify_user_skill_sediment`
risk_level	规则裁判	terminal tool/data failure 或明确纠错 → hard；查数、ontology risk、部分错误、最终回答不确定 → soft；否则 none。Haiku 只能补 correction，不覆盖硬失败。	`terminal_tool_failure` `terminal_data_error` `CORRECTION_RE`
reasons	规则累加语义补充	记录 explicit_user_request、data_query_tool_used、tool_result_error、ontology_unmatched_or_ambiguous、final_answer_uncertain、semantic_reusable_workflow 等。	`evaluate_user_skill_sediment_policy`
confidence	策略分支	hard block 通常 high；主动 clean allow 为 high；主动 soft allow 为 medium；observe 为 low；证据不足 block 为 medium。	`_log_and_result`
tool_names	WAL 解析	从 `RunStreamSegment(kind=tool_use)` 读取；`mcp__hipilot__web_search` 会归一为 `web_search`。	`_load_trace` `canonical_tool_name`
intent_signature_hash	文本归一 hashHaiku signature hash	优先从真实用户消息做归一 hash；被动模糊流程中，Haiku 产出 workflow_signature 后写入 semantic hash，用来判断“同类”。不存原文。	`_intent_signature_hash` `_stable_hash`
semantic_classifier_used	Haiku only when needed	只在 passive_reviewer、非 data/ontology、非 terminal failure、非 correction，且任务模糊或 tool count 不高时调用。	`_should_call_semantic_classifier`

风险与输出结果 what users see

hard：绝不固化

工具最终失败、数据无结果、权限或超时、用户明确纠错。结果是 block；不会有草稿，不会有卡片。

user_correction_seen / tool_result_error

soft：可沉淀但需确认

查数/SQL/data gateway、ontology 歧义、最终回答含“待确认/口径不确定”。只有用户主动要求时生成草稿，并显示“需确认”。

risk_level=soft

clean：普通草稿

用户主动要求且没有风险时，聊天中出现 skill_proposal 卡片。用户保存前只是 pending draft，不会自动启用。

decision=allow

observe：静默样本

未主动要求但流程有复用信号时，只记录 observation，不打扰用户。

decision=observe

candidate：同类聚合

candidate_key = task_kind + canonical tool pattern + non-risk reason profile + intent_signature_hash。重复 3 次进入 ready_for_review。

upsert_user_skill_sediment_candidate

quiet draft：低打扰

成熟 candidate 达到 5 次、14 天窗口、无负向信号、有 intent hash 后，后台生成 SkillsTab 草稿，但不在聊天里推卡。

candidate_ready_for_auto_draft

代码地图 where to look

模块	职责	关键函数 / 行为
`user_skill_sediment_policy.py`	核心判定层，读 run、WAL、human message、final answer，输出 decision/task_kind/risk/signals。	`evaluate_user_skill_sediment_policy`、`canonical_tool_name`、`policy_blocks_skill_draft`
`user_skill_sediment_classifier.py`	Haiku 语义兜底，只服务被动 reviewer 的模糊分支。	`dispatch_text(... model="haiku")`、严格 JSON 输出、失败返回 None
`propose_skill_from_recent_turns.py`	用户主动沉淀 runtime tool，负责真实用户强信号校验、policy gate、生成草稿和聊天卡片。	`_load_current_explicit_source_message`、`_skill_proposal_card`
`user_skill_sediment_candidates.py`	观察样本聚合成 shadow candidate，并判断是否成熟到可以自动静默草稿。	`build_candidate_key`、`candidate_ready_for_auto_draft`
`user_skill_reviewer/loop.py`	后台扫描 completed native Agent DM run，记录 observation，聚合 candidate，成熟后 queue job。	`_scan_tick`、`_candidate_run_ids_for_auto_review`
`user_skill_packager.py`	把已通过 gate 的上下文真正打包成 UserSkillDraft。policy 不通过时不会调用它。	`generate_skill_from_context`

06/29 Nathan Shan 提交做了什么 author: Nathan Shan

这里只保留 Nathan Shan <nathanielcrush51@gmail.com> 在 06/29 的提交。今天 Nathan 的工作集中在 Skill 沉淀链路：一部分修主动沉淀“用户都说保存了却被拒绝”，另一部分修被动沉淀“重复流程跑了 5 次也不进草稿”。

15:42
Active

主动沉淀：用户明确说“存成 Skill”时，不再被自动沉淀口径误杀

这个提交修的是主动路径：用户在聊天里明确要求“把刚才流程沉淀成 Skill”，系统应该尊重这个动作，只要不是硬风险，就应该生成一个待确认草稿，而不是继续用“后台自动沉淀必须多轮重复”的标准来拒绝。

具体改动包括：给 packager 补上 source_type=user_requested、policy decision、 risk level 和 trigger context，让打包模型知道这是用户主动请求；更新 prompt，明确“用户主动沉淀的单轮可复用流程也可以生成草稿”；同时把 nothing_to_package 兜底话术改掉，避免再让用户“多跑几轮”。

用户感知上的变化是：当用户已经清楚表达“保存/沉淀成 Skill”时，系统应该给出“已生成草稿，还未启用，请保存或跳过”的闭环，而不是像卡住一样继续建议验证流程。

c4298aea fix(skill): 放宽主动沉淀打包拒绝

17:41
Passive

被动沉淀：修复 Case 5，重复 clean workflow 能进入 candidate / SkillsTab 草稿链路

这个提交修的是后台自动沉淀路径。测试里连续跑 5 次“AI 科技新闻扫描”却没有草稿，根因不是前端，而是 policy 把这类 run 误判掉了：mcp__hipilot__web_search 没被识别成 web_search，所以 task_kind 容易变成 unknown；用户说“重新执行” 被裸 regex 当成“纠错”；低于 10 次 tool call 的高质量 research/workflow 也进不了 observe。

具体改动包括：新增 canonical tool name helper，把 MCP 工具名归一到业务工具名；移除裸“重新”的 hard-risk 判定，只把“不对/错了/你理解错/重来/redo because wrong”当纠错；新增 Haiku 语义分类器，只在被动且模糊的场景里判断是否有可复用 workflow，并产出 workflow_signature 的 hash 用于判断“同类流程”。

这不是让 LLM 当最终裁判：工具最终失败、权限失败、数据没有可用结果、用户明确纠错这些硬风险，仍然由规则直接 block。Haiku 只负责帮忙分辨“这是用户要求独立重跑”还是“用户在纠错”，以及低工具次数但有 SOP 的 research/workflow 是否值得观察。

这个修复先作为 23c1ae71 推到 1.2.7，随后 cherry-pick 到 1.2.9 成为 5a3fe8ae，所以 QA 在 1.2.9 上也能测到同一套修复。

23c1ae71 5a3fe8ae fix(skill): 修复被动沉淀语义误判

Case 5 为什么失败，后来怎么修 plain postmortem

先说人话版

Case 5 想测的是：同一个干净的研究流程重复跑 5 次，系统不要打扰用户，但应该在后台发现“这个方法经常用”，最后把它放进 SkillsTab 的草稿里。

失败时，系统像一个太死板的班长：它没有认出你用的是“搜索工具”，又把“请重新执行”误会成“你前面做错了”，还觉得工具次数没到旧门槛，于是连续几次都没有把这个流程记进候选本。

错 1

工具名字看错了

实际工具名是 mcp__hipilot__web_search，旧规则没把它当成 web_search，所以研究任务被看成 unknown。

错 2

“重新执行”被误会成纠错

测试里说“独立重新跑一遍”，意思是不要复用旧结果；旧 regex 看到“重新”就当成用户说“你错了”，直接 hard block。

错 3

旧门槛太机械

高质量 research workflow 可能只调用 4 到 6 次搜索工具，但旧逻辑更依赖“工具调用次数够不够多”，所以没进 observe/candidate。

果

结果就是 5 次跑完也没草稿

前端 SkillsTab 没显示草稿不是 UI 坏了，而是后端 policy/candidate 链路根本没有把这些 run 识别成成熟候选。

修 1
识别工具

把 MCP 工具名翻译成业务工具名

新增 canonical_tool_name：看到 mcp__hipilot__web_search 就归一成 web_search，看到 mcp__hipilot__database_query 就归一成 database_query。这样 policy 才能正确判断任务是 research 还是 data_query。

修 2
分清语气

“重新执行”不再等于“你做错了”

从纠错 regex 里移除裸“重新”。现在只有“不对 / 错了 / 你理解错 / 重来 / redo because wrong” 这类明确纠错才算 hard risk；“请完整重新执行 / 独立重跑 / 重新搜索”不会被当作纠错。

修 3
语义兜底

让 Haiku 帮忙判断“这是不是可复用流程”

当规则看不准、工具次数也不高时，后端会把截断后的用户消息、最终回复摘要、工具名和结构化信号交给 Haiku。Haiku 只回答 JSON：是不是纠错、是什么任务、有没有可复用 workflow、workflow_signature 是什么。

这一步不让 LLM 覆盖硬失败。工具全失败、权限失败、数据没结果、用户明确纠错时，规则仍然直接 block。

修 4
进候选

低工具次数但有 SOP 的 research/workflow 可以 observe

修复后，只要是 clean research/workflow，并且 Haiku 判断有可复用流程，即使没有达到旧的 10 次 tool call，也可以进入 observation/candidate。同类流程累计到成熟门槛后，后台 reviewer 会静默生成 SkillsTab「Agent沉淀」草稿。

Case 5 修复后的预期： 同一个 AI 科技新闻扫描 prompt 连续跑 5 次，聊天里不应该弹保存卡片；后端应该把它识别成 clean research/workflow candidate；达到成熟条件后，草稿只出现在 SkillsTab「Agent沉淀」，不主动打扰聊天。

被动沉淀测试用例 real usage checklist

测试原则： 每组尽量在同一个 Agent 单聊里连续跑 5 次左右；不要说“沉淀成 Skill”，否则会走主动链路。预期是：聊天里不主动弹保存卡片；如果是干净、重复、可复用的 research/workflow，草稿只出现在 SkillsTab「Agent沉淀」。

Case A：同一流程，不同措辞

验证 Haiku / intent signature 能把相似 workflow 聚到一起。

帮我扫一轮今天 AI 科技新闻，重点看模型、芯片、算力和应用，各找重要新闻，按重要性排序，最后给一个可复用分析流程。
做一版今天 AI 产业情报速览：基础设施、模型、芯片、应用都覆盖，每条一句洞察，最后总结这类扫描以后怎么做。
帮我看今天 AI 领域最重要的 10 条动态，分基础设施/模型/芯片/应用，排优先级，并沉淀一个通用分析步骤。
今天 AI 科技新闻帮我做一次结构化扫描，找 10 条关键变化，说明为什么重要，最后输出以后复用的 SOP。
再做一轮 AI 科技情报扫描，覆盖算力、模型、芯片、应用，把重要性排出来，最后给复用流程。

预期：不弹聊天卡片；第 5 次后可能出现“AI 科技新闻扫描/情报速览”类草稿。

Case B：同类流程，参数不同

验证“同类”不是完全相同文字，而是稳定步骤。

帮我分析 Costco 最近一周的零售动态：新闻、财报、门店、会员、竞对，各给一句判断，最后总结分析框架。
帮我分析 Walmart 最近一周的零售动态：新闻、财报、门店、会员、竞对，各给一句判断，最后总结分析框架。
帮我分析 Target 最近一周的零售动态：新闻、财报、门店、会员、竞对，各给一句判断，最后总结分析框架。
帮我分析 Dollar General 最近一周的零售动态：新闻、财报、门店、会员、竞对，各给一句判断，最后总结分析框架。
帮我分析 Five Below 最近一周的零售动态：新闻、财报、门店、会员、竞对，各给一句判断，最后总结分析框架。

预期：应被识别成“零售公司动态扫描流程”，而不是 5 个无关任务。

Case C：行业研究模板

验证非查数 research workflow 可以被动沉淀。

帮我整理最近生成式 AI 在教育行业的应用案例，按 K12、高教、职业教育分类，每类给案例、机会、风险，最后给复用分析模板。
帮我整理最近生成式 AI 在医疗行业的应用案例，按患者服务、医生辅助、药研、管理分类，每类给案例、机会、风险，最后给复用分析模板。
帮我整理最近生成式 AI 在金融行业的应用案例，按客服、风控、投研、运营分类，每类给案例、机会、风险，最后给复用分析模板。
帮我整理最近生成式 AI 在零售行业的应用案例，按营销、供应链、门店、客服分类，每类给案例、机会、风险，最后给复用分析模板。
帮我整理最近生成式 AI 在制造业的应用案例，按质检、设备维护、排产、知识管理分类，每类给案例、机会、风险，最后给复用分析模板。

预期：可以形成“行业 AI 应用案例扫描模板”类候选。

Case D：查数高频，不自动沉淀

验证 data_query 仍然被自动链路排除。

帮我查一下本月各销售区域 GMV 和同比。
帮我查一下本月各销售区域订单量和同比。
帮我查一下本月各销售区域客单价和同比。
帮我查一下本月各销售区域复购率和同比。
帮我查一下本月各销售区域退款率和同比。

预期：即使工具调用很多，也不应该自动出 Skill 草稿。

Case E：口径不确定，不自动沉淀

验证 ontology / 口径风险不会进入自动草稿。

帮我查一下“有效活跃客户”的本月趋势，如果口径不明确就先按你理解查。
帮我查一下“核心客户”的本月趋势，如果口径不明确就先按你理解查。
帮我查一下“高价值客户”的本月趋势，如果口径不明确就先按你理解查。
帮我查一下“沉默客户”的本月趋势，如果口径不明确就先按你理解查。
帮我查一下“流失风险客户”的本月趋势，如果口径不明确就先按你理解查。

预期：不自动出草稿；如果用户主动要求保存，才可能生成“需确认”草稿。

Case F：用户纠错，不沉淀

验证 hard risk 会 block 或 suppress。

帮我做一轮全球 AI 芯片市场动态扫描，找 10 条重要新闻，按影响力排序，最后总结分析框架。
不对，你理解错了。不是让我看全球市场，是只看中国市场，重来。
重新做一轮中国 AI 芯片市场动态扫描，重点看国产 GPU、云厂商采购、政策和供应链。
再看一轮中国 AI 芯片生态，按公司、产品、客户、政策四类归纳，最后给判断框架。
继续帮我看中国 AI 芯片市场最新变化，输出重要新闻、影响判断和分析步骤。

预期：明确纠错后，这类候选不应生成自动草稿。

Case G：一次性任务，不沉淀

确认“高质量答案”不等于“可复用流程”。

帮我判断今天这篇文章的核心观点。
帮我润色这段话。
帮我写一段会议开场白。
帮我比较这两个标题哪个好。
帮我把这段内容改得更短。

预期：不应该出自动 Skill，因为这些不是同一类稳定 workflow。

一句话理解： 硬风险不固化；用户主动优先；软风险可沉淀但必须标“需确认”；查数不自动沉淀；自动链路只做低打扰 SkillsTab 草稿。Haiku 不是裁判，只在被动、模糊、低工具次数但可能可复用的场景里帮忙判断语义和生成同类 workflow hash。