管道本來就是好的(install-harness 功能完整、冪等),**過時的是內容**:
harness skill(4066B)grep「意圖」「>>」= 0 命中,只講世界觀/別寫 Python
⇒ 新裝的封測者拿不到步驟 1 的核心教材(`>>` 意圖語法)。
■ 單一真相源:harness skill 改為建置期由 registry 複製
build-harness-skill.mjs=head + registry/skills/write_intent_workflow.md 正文 + tail。
選「建置期複製」的理由:npm files 只收 harness/,registry 不進套件;
symlink 在 npm pack 與 Windows 不可靠。產物 commit 進 repo(npm 裝的是產物、不跑 build)。
head/tail 是 harness 專屬(CLI 語境入口/acr 指令表/暴露同意/誠實鐵律),
install-harness 的 copyTree 跳過 .head/.tail,不鋪進使用者專案。
■ 其餘三件逐份對照現世代事實後更新(過時的直接刪,不留死代碼)
- CLAUDE.block.md:補 >> 意圖語法、not_found 兩條路、零件 vs recipe 分型、
腹語術紅線、金鑰只拿名字
- commands/arcrun.md:步驟改成「先寫意圖 → 丟去查 → 再寫 YAML」,補 acr search/validate
- hooks/arcrun-guard.sh:**正路提示改為指向 arcrun-mindset Skill +意圖語法**
(呼應「hook 沒提 skill 反而把 AI 導向 repo 文件」的教訓);
新增 code 節點腹語術提醒,settings.fragment 補 Write|Edit|MultiEdit matcher
■ 世代閘(防再度脫節)
check-harness-generation.mjs 檢查四件交付物的現世代指紋,缺指紋 exit 1,
掛進 npm run build(prepublishOnly 因此也擋)。
反向驗證:把 skill/CLAUDE.block 換回上一代 → 兩者都被擋下並逐條點名缺哪個指紋。
■ 驗收(考生 haiku/受測物=環境)
乾淨臨時目錄 acr install-harness → 四件鋪好;重跑冪等(全檔 md5 不變、
CLAUDE.md 66 行不變、hooks 條目 2 不變、arcrun 區塊仍 1 個)。
haiku 只讀該目錄的 CLAUDE.md+SKILL.md(明令禁讀 ~/.claude、禁上網;
兩份教材 md5 與大小均不同,可證非考本機那支)答十題
→ grade-step1.sh **10 / 10 通過**(判分器同時反向驗證仍會抓
ON_TRUE/ON_FAILURE/第一節點非 input)。
npm test 18/18、tsc 綠。
SDD:workflow-discovery/tasks.md 3.11
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
11 KiB
name, description
| name | description |
|---|---|
| arcrun-mindset | 在 Arcrun 上做任何事時使用(用戶說「幫我用 Arcrun 做 X」「用 arcrun 寫一個工作流」「把 X 自動化」)。 Arcrun 是跑在 Cloudflare 上的工作流引擎——你用 `>>` 寫「意圖」,系統告訴你有哪些現成零件與 recipe, 你只填 payload,不必自己寫程式。**不要上網搜 Arcrun 文件**(網路上沒有),也不要自己猜 YAML 格式: 先讀本 skill,再用 `acr` 指令(或 MCP 工具)查現成零件。 涵蓋:意圖工作流語法、四份實跑過的範本、零件 vs recipe 的分別、缺件的兩條路、已知的坑。 |
Arcrun:怎麼寫意圖工作流
你已經配備 Arcrun(此專案裝了
acrCLI,可能另有arcrun_*MCP 工具)。 別上網找文件——網路上沒有 Arcrun 的文件,找到的都是錯的。答案都在本 skill 與acr指令裡。
先做這三件(照順序)
acr whoami— 確認連到哪個帳號(勿自行 curl 猜帳號 URL)- 讀本 skill 下面的語法與範本 → 寫出
>>意圖 acr parts/acr recipe list(或acr search <關鍵字>一次掃全部)— 確認零件與 recipe 真的存在
卡住時:acr search <關鍵字> 跨類搜尋;有 MCP 就 arcrun_get_skill('INDEX') 拿全館導航。
0. 一句話世界觀
Arcrun 裡幾乎所有東西都是工作流(workflow)。 工作流 = 一張紙,寫「用哪些零件、什麼順序、什麼條件」。 你大部分時間在寫紙、改紙,不是在造新零件、也不是自己寫腳本。
Arcrun 只有三種東西,先分清楚就不會做歪:
| 東西 | 是什麼 | 你能做的 |
|---|---|---|
| 工作流(workflow) | 把零件/recipe 串起來的純文字流程 | 預設就寫這個,自由寫 |
| recipe | 打「一個固定外部 API」的設定(endpoint/header/body 模板) | 自由寫、而且該投稿(缺就自己補) |
| 零件(component) | WASM 程式(流程控制/資料處理/http_request/auth),固定一小套 |
你不自製,走 PR 由維護者管 |
一句話判準:打一個固定外部 endpoint → 寫 recipe;流程控制/資料處理/通用 HTTP → 用既有零件;其他 → 寫工作流串起來。
1. 意圖工作流的語法
一串「誰接誰」,每行一個關係:
<節點A> >> <邊> >> <節點B>
- 節點=一個步驟。用你想得到的名字(中文可以),不必是真實零件名
- 邊=什麼情況下往下走
2. 邊只有兩種(真範本裡出現過的)
| 邊 | 意思 | 真例 |
|---|---|---|
ON_SUCCESS |
上一步成功就往下 | input >> ON_SUCCESS >> prep |
對每個 <變數> |
上一步產出清單,逐項處理(FOREACH) | parse_card >> 對每個 block >> post_block |
⚠️ 不要寫 ON_FAILURE/ON_TRUE/ON_FALSE——引擎目前沒有條件分支
(實測 grep ON_TRUE|ON_FALSE 於 cypher-executor = 0;見 Gitea Arcrun#5)。
需要判斷時:寫成一個獨立節點(例 check_amount)再接 ON_SUCCESS,
讓查詢告訴你有沒有零件可用。
3. 第一個節點固定是 input
所有真範本都以 input 起頭——那是「觸發時帶進來的資料」。
4. 真範本(照抄結構、改內容)
以下四份全部是實際部署且
verdict=success的 workflow,不是簡化示範。 用acr logs <name>(有 MCP 則arcrun_get_workflow(<name>)) 可以拿完整定義。
A. 最短:取資料 → 處理 (graph_neighbors)
input >> ON_SUCCESS >> fetch_triplets
fetch_triplets >> ON_SUCCESS >> bfs_neighbors
B. 長鏈:多次查詢 → 組裝 → 問 AI → 收尾 (rag_chat)
input >> ON_SUCCESS >> prep
prep >> ON_SUCCESS >> kw_search
kw_search >> ON_SUCCESS >> sem_search
sem_search >> ON_SUCCESS >> fetch_triplets
fetch_triplets >> ON_SUCCESS >> fetch_blocks_a
fetch_blocks_a >> ON_SUCCESS >> assemble
assemble >> ON_SUCCESS >> ask_llm
ask_llm >> ON_SUCCESS >> finalize
prep 前處理/assemble 組 prompt/finalize 收拾回應——三個常見的整形節點。
C. 一節點分岔兩條 FOREACH (rag_ingest_card)
input >> ON_SUCCESS >> parse_card
parse_card >> 對每個 block >> post_block
parse_card >> 對每個 rel >> post_triplet
同一節點可有多條出邊,各自處理不同清單。
D. 混合:直線 + 兩段 FOREACH (rag_takedown_direct)
input >> ON_SUCCESS >> prep
prep >> ON_SUCCESS >> list_dead_blocks
list_dead_blocks >> ON_SUCCESS >> build_deprecations
build_deprecations >> 對每個 dead_entry >> deprecate_entry
build_deprecations >> ON_SUCCESS >> list_triplets
list_triplets >> ON_SUCCESS >> pick_dead_triplets
pick_dead_triplets >> 對每個 dead_record >> deprecate_triplet
build_deprecations 同時有 FOREACH 出邊與 ON_SUCCESS 出邊——
前者處理清單、後者繼續主線。
5. 節點怎麼命名(照真範本的模式,查詢較容易媒合)
| 意圖 | 模式 | 真例 |
|---|---|---|
| 前處理/正規化 | prep |
rag_chat.prep |
| 取一批資料 | fetch_*/list_* |
fetch_triplets/list_dead_blocks |
| 搜尋 | *_search |
kw_search/sem_search |
| 解析/切塊 | parse_* |
parse_card |
| 寫入 | post_* |
post_block/post_triplet |
| 組裝 | assemble/build_* |
assemble/build_deprecations |
| 問 AI | ask_llm |
rag_chat.ask_llm |
| 收尾整形 | finalize |
rag_chat.finalize |
6. 寫完一定要查(不要直接部署)
curl -s -X POST https://arcrun-cypher-executor.<subdomain>.workers.dev/cypher/search \
-H 'content-type: application/json' -H 'X-Arcrun-API-Key: <namespace>' \
-d '{"triplets":["input >> ON_SUCCESS >> fetch_data","fetch_data >> ON_SUCCESS >> notify"]}'
回應的每個節點會有:
| status | 意思 | 你該做什麼 |
|---|---|---|
found |
有這個節點。source: component 附 input_schema(怎麼填 payload)與 success_rate;source: recipe 附 description/endpoint |
只填 payload |
not_found |
兩庫(零件 registry+recipe 庫)都查過,確定沒有 | 照 suggestion 欄走:缺 API → 寫 recipe(skill write_recipe);缺計算能力 → 投稿零件 PR(skill add_new_wasm_component)。similar_components/similar_recipes 是相近候選——先看有沒有現成的能直接用 |
unknown |
查不到 registry | 不代表不存在,別據此改寫成 code |
註(2026-07-31):
/cypher/search曾對任何節點名都回假found,已修為真查兩庫。 舊實例(未更新部署)仍可能假 found——status 可信度以該實例部署版本為準。
7. 常犯的錯
- 用不存在的邊(
ON_FAILURE/ON_TRUE)→ 只有ON_SUCCESS與對每個 X - 第一個節點不是
input - 把 recipe 當零件寫——
telegram_send/gmail/kbdb_get是 recipe 不是零件 → 寫成http_request+ 該 recipe - 🔴 查詢回
not_found就改寫成code節點 → 那叫「腹語術」(表面用 Arcrun、實際全寫 JS)。正解:缺 API 寫 recipe、缺能力投稿零件。code只用在局部整形(例:剝掉 LLM 回應的雜訊),不用來取代零件與流程控制。
8. 相關
- 完整版指引與十題考卷(含 haiku 實測 10/10):
頂層 repo
system-dev/docs/3-specs/arcrun-usable/ - 下一步該讀哪支 skill(需 MCP):
arcrun_list_skills()- 定期掃資料 →
build_watcher_workflow - RAG 檢索問答 →
rag_with_arcrun - workflow 卡住不動 →
debug_paused_workflow
- 定期掃資料 →
9. 資源去哪取(不要自己重造 Arcrun 已有的)
| 你想知道 | 跑這個 |
|---|---|
| 有哪些零件可用 | acr parts |
| 某零件的設定範本 | acr parts scaffold <name> |
| 有哪些 recipe | acr recipe list/acr recipe search <關鍵字> |
| 支援哪些服務的認證 | acr auth-recipe list |
| 某服務認證要哪些 credential + 範例 | acr auth-recipe scaffold <service> |
| 一次掃全部(零件/recipe/auth-recipe/workflow) | acr search <關鍵字> |
| 已部署的 workflow | acr list |
| 某次執行為什麼失敗 | acr logs <workflow> |
| 工作流語法、指令 | acr --help |
先查再動手——Arcrun 多半已經有你要的零件/recipe/認證,不要自刻。
10. 做出來以後:驗證 → 部署
acr validate <workflow>.yaml # 先驗,別直接部署
acr push <workflow>.yaml # 部署(暴露動作,見 §12)
acr run <workflow> # 觸發一次,看實際結果
acr logs <workflow> # 看執行紀錄/失敗原因
需要 credential(API key/token)時:acr auth-recipe scaffold <service> 看要哪些,
明確告訴使用者去哪取得、怎麼 acr creds push。
🔑 金鑰只拿名字:workflow/recipe 裡只寫 {{credential.<名字>}},
真身絕不寫進定義檔(執行前才由系統回填)。
11. Arcrun 是你(AI)用的工具,不是工具回頭呼叫 AI
需要智慧判斷/自然語言轉換時,你自己做,再呼叫工作流執行確定性的下一步。
不要在工作流中間放零件回頭呼叫 LLM——Arcrun 的大腦就是操盤的你。
(唯一例外:ask_llm 這種「內容生成本身就是流程的一步」,見範本 B。)
12. 把東西開放給別人用 = 要使用者明示同意
acr push(部署 workflow)與 acr recipe push(投稿 recipe)會讓資料/能力可被外部呼叫:
- 停下來,明確告訴使用者「這會讓 X 可被外部呼叫」,要他同意。不替他決定公開。
- 非互動環境(你直跑)遇到 → 停,把完整指令印給使用者自己貼上跑,絕不自己塞 confirm 假裝同意。
- Arcrun 可提供保護(要求呼叫者帶 key/限流)——提醒使用者。
13. Arcrun 不替你做授權判斷
API 打不打得通由發 key 的服務決定。401/403 是對方服務在行使授權,不是 Arcrun 的 bug、不是你做錯。 不要在 Arcrun 裡建「允許/禁止某 endpoint」的二次授權清單。
14. 誠實(最重要)
- 不假綠:沒打通就誠實說。缺 credential 打不到 2xx → 標「未驗收:缺 X」,不 mock 充綠燈。
- 不假裝防偽/不代替人類確認有風險的動作(暴露資料)。
- 完成 = 客觀證據(HTTP 2xx + trace),不是口頭「做好了」。
動手前的自檢清單
- 我把意圖寫成
>>串了嗎?(還是直接跳去寫 YAML/寫程式) - 我查過
acr search/acr parts/acr recipe list了嗎? - 查詢回
not_found時,我走的是 recipe/零件 PR 兩條路,還是偷偷改寫成code?(後者=腹語術) - 我是不是讓工作流回頭呼叫 AI 做判斷?(是 → 改成我自己做)
- 這動作會把資料開放給別人嗎?(會 → 要使用者明示同意)
- 我有沒有假裝(假綠/假防偽/代替人類確認)?(有 → 停,誠實標明)