From 04e2b5b8a721581cbc94bc3d08a1aad291b3c418 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E5=A2=A8?= Date: Sun, 7 Jun 2026 11:43:36 +0000 Subject: [PATCH] =?UTF-8?q?docs:=20expand=20.cards=20=E2=80=94=20vision,?= =?UTF-8?q?=20comparisons,=20business=20rationale,=20open=20questions?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 26 cards covering: - Project philosophy (session isolation, process discipline, dissipative structure) - Comparisons (vs skill, vs dynamic workflow) - Business rationale (FTE vs vendor, OPC, switching cost) - Learning model (memory + skill + workflow) - Self-improvement (reflective workflow, eval) - Open questions (workflow granularity, human-in-the-loop) --- .cards/agency-over-content-not-process.md | 19 ++++++++++ .cards/agent-as-graduate.md | 30 ++++++++++++++++ ...tion-isolation-breaks-cognitive-inertia.md | 21 +++++++++++ .cards/cognitive-process-orchestration.md | 18 ++++++++++ .../cold-start-same-entry-different-exit.md | 20 +++++++++++ .cards/domain-experts-own-the-process.md | 20 +++++++++++ .cards/eval-closes-the-trust-chain.md | 21 +++++++++++ ...feedback-loops-convergent-and-divergent.md | 21 +++++++++++ .cards/four-advantages-over-single-session.md | 27 ++++++++++++++ .cards/opc-why-fte-agents-matter-most.md | 33 +++++++++++++++++ .cards/open-question-human-as-role.md | 22 ++++++++++++ .cards/open-question-workflow-granularity.md | 20 +++++++++++ ...ocess-authorship-human-ai-vs-delegation.md | 23 ++++++++++++ .../reflective-workflow-self-improvement.md | 35 +++++++++++++++++++ .cards/skill-vs-workflow-different-layers.md | 19 ++++++++++ ...witching-cost-process-knowledge-as-moat.md | 20 +++++++++++ .cards/three-learning-carriers.md | 22 ++++++++++++ .cards/trust-chain-audit-evaluate-reuse.md | 23 ++++++++++++ .cards/uwf-vs-dynamic-workflow.md | 27 ++++++++++++++ .cards/when-skill-is-not-enough.md | 24 +++++++++++++ .cards/workflow-as-improvable-system.md | 20 +++++++++++ 21 files changed, 485 insertions(+) create mode 100644 .cards/agency-over-content-not-process.md create mode 100644 .cards/agent-as-graduate.md create mode 100644 .cards/attention-isolation-breaks-cognitive-inertia.md create mode 100644 .cards/cognitive-process-orchestration.md create mode 100644 .cards/cold-start-same-entry-different-exit.md create mode 100644 .cards/domain-experts-own-the-process.md create mode 100644 .cards/eval-closes-the-trust-chain.md create mode 100644 .cards/feedback-loops-convergent-and-divergent.md create mode 100644 .cards/four-advantages-over-single-session.md create mode 100644 .cards/opc-why-fte-agents-matter-most.md create mode 100644 .cards/open-question-human-as-role.md create mode 100644 .cards/open-question-workflow-granularity.md create mode 100644 .cards/process-authorship-human-ai-vs-delegation.md create mode 100644 .cards/reflective-workflow-self-improvement.md create mode 100644 .cards/skill-vs-workflow-different-layers.md create mode 100644 .cards/switching-cost-process-knowledge-as-moat.md create mode 100644 .cards/three-learning-carriers.md create mode 100644 .cards/trust-chain-audit-evaluate-reuse.md create mode 100644 .cards/uwf-vs-dynamic-workflow.md create mode 100644 .cards/when-skill-is-not-enough.md create mode 100644 .cards/workflow-as-improvable-system.md diff --git a/.cards/agency-over-content-not-process.md b/.cards/agency-over-content-not-process.md new file mode 100644 index 0000000..93eb32d --- /dev/null +++ b/.cards/agency-over-content-not-process.md @@ -0,0 +1,19 @@ +--- +title: "Agency over Content, Not Process" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision] +category: "architecture" +links: + - skill-vs-workflow-different-layers + - deterministic-engine-uncertain-agent + - feedback-loops-convergent-and-divergent + - cognitive-process-orchestration + - uwf-vs-dynamic-workflow +--- + +uwf 与"agent 自治"方案的核心区别：**agent 对内容有自主权，但对流程没有**。 + +流程是声明式的、引擎执行的、agent 无法绕过的。agent 不能决定跳过 review，就像程序员不能绕过 CI。自由度被有意限制在"内容"维度，"过程"维度是刚性的。这跟人类组织的逻辑一致——你可以自由发挥怎么写代码，但必须走 PR review。 + +参见 [[uwf-vs-dynamic-workflow]] 了解与 Claude Code dynamic workflow 的具体对比。 diff --git a/.cards/agent-as-graduate.md b/.cards/agent-as-graduate.md new file mode 100644 index 0000000..7ea048f --- /dev/null +++ b/.cards/agent-as-graduate.md @@ -0,0 +1,30 @@ +--- +title: "Agent as Graduate — Not Outsource, Not Genius Intern" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision, pattern] +category: "architecture" +links: + - process-authorship-human-ai-vs-delegation + - domain-experts-own-the-process + - workflow-as-improvable-system + - trust-chain-audit-evaluate-reuse +--- + +交付给用户的 agent buddy 不应该只是装备了行业 know-how 的特定任务执行者，而应该是可以和用户共同讨论、适应到客户实际业务流程中的**"毕业生"**。 + +毕业生有专业知识、有执行能力、学东西快，但不了解公司的具体流程——不知道哪个环节是因为三年前出过事故才加上的，不知道这个审批为什么要过两道。好的毕业生跟着老师傅一边干一边学，理解流程背后的原因，逐渐能独立执行甚至提出改进建议。 + +Workflow 就是这个**带教结构**。行业专家把经验编码到 workflow 里，agent 在这个框架下执行。随着磨合，workflow 本身也在迭代——某个环节发现不需要了，某个地方需要加一道校验。 + +定位的核心差异：我们交付的是 **new graduates as FTEs**，而非 **professional vendors**。 + +Vendor 交付结果——你不关心他内部怎么运作，合同到期换一家也行。FTE 毕业生交付的是融入——你花时间带他、把流程教给他、他理解你的业务逻辑，这个投入随时间产生复利。 + +三种模式的对比： + +- **Skill 模式（外包）** — 丢任务过去不管怎么做只看结果。能用，但不成长，不适应业务。 +- **dw 模式（天才实习生）** — 每次自己想一套做法，可能很惊艳，但不积累、不传承、不跟团队形成默契。 +- **uwf 模式（FTE 毕业生）** — 在团队流程中工作，流程和人相互适应，共同成长。 + +uwf 所有设计选择都在支撑 FTE 模式：可审查（看得懂他在做什么）、可评估（衡量做得好不好）、可迭代（持续改进工作方式）、session 隔离（流程纪律靠结构而非自觉）。 diff --git a/.cards/attention-isolation-breaks-cognitive-inertia.md b/.cards/attention-isolation-breaks-cognitive-inertia.md new file mode 100644 index 0000000..574134f --- /dev/null +++ b/.cards/attention-isolation-breaks-cognitive-inertia.md @@ -0,0 +1,21 @@ +--- +title: "Attention Isolation Breaks Cognitive Inertia" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - session-isolation-as-cognitive-reset + - skill-vs-workflow-different-layers + - role-is-not-agent +--- + +"知识都在一个 session 内不是更好吗？"——这个直觉混淆了**信息量**和**认知模式**。 + +Session 隔离去掉的不是信息，而是**不该影响当前判断的信息**。reviewer 通过 CAS 链拿到 developer 的全部产出物（代码、变更说明），它缺的是 developer 的内心独白——为什么选方案 A、哪里犹豫过、哪里偷了懒。 + +这恰恰是关键。知道"为什么"的 reviewer 会顺着作者的逻辑走；不知道"为什么"的 reviewer 只能看产出物本身是否站得住——就像真实用户或未来维护者的视角。与学术双盲评审同理：去掉不该影响判断的信息，让注意力聚焦在工作本身。 + +每个认知任务需要的信息集合不同。developer 需要 issue 上下文、代码库知识、技术约束；reviewer 需要 diff、规范、测试结果。混在一起不是多了信息，是多了噪声。 + +**关注点的隔离是打破惯性和线性思维的关键。** 一个 session 做所有事，不是"知识都在"，是关注点混在一起，确认偏误无法靠 prompt 消除，只能靠结构隔离。 diff --git a/.cards/cognitive-process-orchestration.md b/.cards/cognitive-process-orchestration.md new file mode 100644 index 0000000..0f5c0b3 --- /dev/null +++ b/.cards/cognitive-process-orchestration.md @@ -0,0 +1,18 @@ +--- +title: "Cognitive Process Orchestration" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision] +category: "architecture" +links: + - feedback-loops-convergent-and-divergent + - session-isolation-as-cognitive-reset + - role-is-not-agent + - process-discipline-from-software-engineering +--- + +uwf 的抽象层次高于"质量保障工具"或"任务编排引擎"——它是一个**认知过程的编排引擎**。 + +收敛和发散都是认知过程。负反馈环（code review 循环）和正反馈环（苏格拉底式追问、头脑风暴）是同一套机制的不同配置。workflow author 通过设计 role 的 goal 和 graph 的环路结构，编排的是**思维方式**，不仅仅是任务步骤。 + +这意味着 uwf 的应用范围不限于软件开发流程，而是任何需要多视角、多轮次认知协作的场景。 diff --git a/.cards/cold-start-same-entry-different-exit.md b/.cards/cold-start-same-entry-different-exit.md new file mode 100644 index 0000000..5d372e6 --- /dev/null +++ b/.cards/cold-start-same-entry-different-exit.md @@ -0,0 +1,20 @@ +--- +title: "Cold Start — Same Entry Point, Different Exit" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - uwf-vs-dynamic-workflow + - process-authorship-human-ai-vs-delegation + - workflow-as-improvable-system + - agent-as-graduate +--- + +uwf 的冷启动不比 dw 更复杂——起点完全一样：用户描述任务，agent 执行。 + +区别在出口：dw 跑完即丢，uwf 跑完后沉淀成 workflow YAML，用户可以审查、调优、复用。workflow 不一定要用户写，往往也是 agent 写的——跟 dw 一样的模式。uwf 和 dw 的差异不在"谁写流程"，而在"流程跑完后去哪"。 + +冷启动路径：agent 先跑一次临时流程 → 用户觉得好就固化成 workflow → 下次同类任务直接复用 → 用过几次后根据经验调优。从零门槛的即兴执行，渐进演化为成熟的可复用流程。 + +入口像 dw 一样低，出口比 dw 多了一个沉淀层。 diff --git a/.cards/domain-experts-own-the-process.md b/.cards/domain-experts-own-the-process.md new file mode 100644 index 0000000..634564a --- /dev/null +++ b/.cards/domain-experts-own-the-process.md @@ -0,0 +1,20 @@ +--- +title: "Domain Experts Own the Process" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision, pattern] +category: "architecture" +links: + - trust-chain-audit-evaluate-reuse + - uwf-vs-dynamic-workflow + - cognitive-process-orchestration + - process-discipline-from-software-engineering +--- + +现实中各行各业有大量由反馈回路构成的流程正在实际运行，掌握和优化这些流程的是行业专家，不是 AI 工程师。 + +一个资深 QA 负责人知道测试应该怎么分层、失败后应该回到哪一步。一个风控经理知道审批要经过几道关、驳回后应该回到哪个环节补材料。这些人掌握流程的核心知识，但你让他们写 JS 编排脚本，他们做不到也不应该做。 + +YAML 声明式 workflow 让行业专家能直接参与——看得懂 roles 和 graph，能判断"这个环节是不是多余的"、"这两个角色之间应该加一个校验步骤"。审查门槛低不是为了技术简洁，是为了**让对的人参与对的决策**。 + +这是可审查 → 可评估 → 可复用信任链能真正转动的前提——转动它的人是行业专家，不是 AI 工程师。也是 uwf 选择声明式 YAML 而非 JS 的根本原因：**流程的设计权应该属于懂流程的人**。 diff --git a/.cards/eval-closes-the-trust-chain.md b/.cards/eval-closes-the-trust-chain.md new file mode 100644 index 0000000..d93b257 --- /dev/null +++ b/.cards/eval-closes-the-trust-chain.md @@ -0,0 +1,21 @@ +--- +title: "Eval Closes the Trust Chain" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - trust-chain-audit-evaluate-reuse + - workflow-as-improvable-system + - feedback-loops-convergent-and-divergent +--- + +信任链（可审查 → 可评估 → 可复用 → 可迭代）的"可评估"环节需要工程落地。 + +uwf 的 eval 包（`@united-workforce/eval`，已在 repo 开发中）的目标是让 agent 能自我评估执行质量——一次 thread 跑完后，度量"做得好不好"、"workflow v2 比 v1 好还是差"。 + +这形成了两层反馈闭环： +1. **workflow 内的反馈环** — developer → reviewer → rejected → developer（已实现，负反馈驱动执行质量收敛） +2. **workflow 级的反馈环** — 执行 → eval → workflow 迭代 → 再执行（在建，驱动流程本身的持续改进） + +第二层闭环接通后，uwf 就不只是一个执行引擎，而是一个**自我改进的流程系统**。 diff --git a/.cards/feedback-loops-convergent-and-divergent.md b/.cards/feedback-loops-convergent-and-divergent.md new file mode 100644 index 0000000..0b533cd --- /dev/null +++ b/.cards/feedback-loops-convergent-and-divergent.md @@ -0,0 +1,21 @@ +--- +title: "Feedback Loops — Convergent and Divergent" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - dissipative-structure-token-for-entropy + - process-discipline-from-software-engineering + - cognitive-process-orchestration +--- + +uwf 的 graph 环路不限于负反馈（收敛），也可以是正反馈（发散）。引擎本身不带倾向——流转方向由 `$status` 和 graph 决定，反馈性质由 role 的设计意图决定。 + +**负反馈环（收敛）**：developer → reviewer → rejected → developer。reviewer 的 goal 是"找问题"，产生修正力。稳定点是 `approved`，系统自然收敛到那里。特性：偏差越大修正越强，对扰动鲁棒。 + +**正反馈环（发散）**：proposer → challenger → "interesting" → proposer。challenger 的 goal 是"追问更深层的假设"，每轮发散，一个想法激发更多想法。 + +终止条件不同：负反馈靠收敛自然到达稳定点；正反馈不会自己停，需要外部约束（轮次上限，或额外 role 判断"够了"）。 + +每个 role 的 `$status` 就是误差信号（负反馈）或激励信号（正反馈），驱动系统向不同方向演化。Workflow author 真正在设计的是**在哪里放什么样的环**。 diff --git a/.cards/four-advantages-over-single-session.md b/.cards/four-advantages-over-single-session.md new file mode 100644 index 0000000..1238150 --- /dev/null +++ b/.cards/four-advantages-over-single-session.md @@ -0,0 +1,27 @@ +--- +title: "Four Advantages over Single Session + Skill" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - session-isolation-as-cognitive-reset + - attention-isolation-breaks-cognitive-inertia + - skill-vs-workflow-different-layers + - when-skill-is-not-enough +--- + +Session 隔离除了认知层面的好处（打破确认偏误、聚焦注意力），还解决一个更物理性的问题：**长 session 的上下文压缩导致降智和行为不稳定**。 + +Context window 是有限资源。一个 session 从头做到尾，前期的 tool output、中间的思考过程不断堆积，要么触发 compaction（信息丢失），要么挤占后期推理的有效空间。越到后面 agent 越"笨"——不是能力变了，是可用的认知空间被历史占满了。表现为：忘记约束、重复错误、输出不稳定。 + +Session 隔离直接解决这个问题：每个 role 进入时拿到的是**精炼过的前序产出**（CAS 里经 schema 过滤的结构化 output），不是前面所有 session 的原始 token 流。信息经过 schema 过滤，只有产出物，没有过程噪声。 + +uwf 相对单 session + skill 的四个优势，前三个来自 session 隔离，第四个来自程序化流程： + +1. **认知隔离** — 打破确认偏误和线性思维惯性 +2. **注意力聚焦** — 每个 role 只看该看的信息 +3. **上下文保鲜** — 避免长 session 的压缩降智和行为漂移 +4. **流程可靠性** — 引擎强制执行每一步，agent 无法跳过或篡改流程 + +前三点回答"为什么拆成多个 session 更好"，第四点回答"为什么流程要由引擎控制而不是 agent 自觉"。Skill 里写"先编码再测试再 review"，agent 可能做着做着就跳过——不是故意的，是 context 压力下行为漂移，或者觉得"改动太小不需要测试"。程序化流程不存在这个问题：graph 说要走 tester，就必须走 tester。 diff --git a/.cards/opc-why-fte-agents-matter-most.md b/.cards/opc-why-fte-agents-matter-most.md new file mode 100644 index 0000000..fb6e1e9 --- /dev/null +++ b/.cards/opc-why-fte-agents-matter-most.md @@ -0,0 +1,33 @@ +--- +title: "OPC — Why One Person Companies Need FTE Agents Most" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern, decision] +category: "architecture" +links: + - agent-as-graduate + - process-authorship-human-ai-vs-delegation + - workflow-as-improvable-system + - domain-experts-own-the-process +--- + +One Person Company (OPC) 是 FTE 型 agent 价值主张最清晰的场景。 + +OPC 的核心矛盾：一个人要覆盖所有职能（产品、开发、测试、运营、客服、财务），不可能精通所有领域，但每个领域都需要靠谱的流程保证质量。 + +Vendor 型 agent 适合偶发性、标准化任务——生成图片、翻译文档，用完即走。FTE 型 agent 适合核心业务流程——反复执行、有领域特殊性、出错成本高的环节。 + +OPC 不是"一个人用很多工具"，而是"一个 CEO 管一个全 agent 团队"。全用 vendor 型 agent，CEO 是人肉编排器——每个任务都要自己拆、分配、检查、决定下一步，agent 越多协调开销越大，CEO 本人成为系统瓶颈。 + +FTE agent 解决的是 **delegation 的深度**。vendor 只能委托一个任务，FTE 可以委托一个职能——"你负责所有 PR 的 code review，按这个流程做"。Workflow 是这个委托的载体，编码了做事方法，agent 在流程里自主运转。 + +CEO 从操作者变为流程的设计者和监督者，关注"流程对不对"而不是"这一步做得对不对"。带宽从 O(任务数) 降到 O(流程数)。任务无限多，但流程是有限的、收敛的。 + +OPC 比大公司更需要 FTE 型 agent，因为： + +1. **没有团队兜底** — 没有同事补漏，流程可靠性是生命线 +2. **流程就是竞争力** — OPC 的护城河往往是创始人多年积累的做事方法，需要被编码、复用、持续优化 +3. **规模化靠流程不靠人** — 增长不能靠招人，只能靠让 agent 承担更多职能，而承担职能需要真正融入业务流程 +4. **CEO 不能是瓶颈** — FTE agent 独当一面，CEO 才能从协调者变成决策者 + +uwf 在 OPC 场景的价值：把创始人脑子里的流程变成可执行、可迭代的资产，让 FTE agent 成为 CEO 的左膀右臂，而不是需要时刻看管的外包。 diff --git a/.cards/open-question-human-as-role.md b/.cards/open-question-human-as-role.md new file mode 100644 index 0000000..0a19364 --- /dev/null +++ b/.cards/open-question-human-as-role.md @@ -0,0 +1,22 @@ +--- +title: "Open Question — Human as Role Participant" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, open-question] +category: "architecture" +links: + - agent-as-graduate + - opc-why-fte-agents-matter-most + - role-is-not-agent + - process-authorship-human-ai-vs-delegation +--- + +**待讨论。** + +目前讨论主要围绕 OPC（一个人 + N 个 agent）。但小团队场景下——几个人各自有 FTE agent，共享 workflow 库和记忆——workflow 的某些 role 可能需要人来执行而不是 agent。 + +问题： +- uwf 是否需要支持人作为 role 的参与者（比如"人工审批"作为 graph 中的一个 role）？ +- 还是人永远在 workflow 之外，只做设计者和监督者？ +- 如果支持，$SUSPEND 机制是否已经覆盖了这个需求（暂停等人介入）？ +- 多人 + 多 agent 的协作场景下，workflow 的共享和权限模型是什么样的？ diff --git a/.cards/open-question-workflow-granularity.md b/.cards/open-question-workflow-granularity.md new file mode 100644 index 0000000..3353680 --- /dev/null +++ b/.cards/open-question-workflow-granularity.md @@ -0,0 +1,20 @@ +--- +title: "Open Question — Workflow Granularity and Composition" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, open-question] +category: "architecture" +links: + - cognitive-process-orchestration + - skill-vs-workflow-different-layers + - domain-experts-own-the-process +--- + +**待讨论。** + +Workflow 的粒度问题：solve-issue 是端到端的大 workflow（planner → developer → reviewer → tester → committer），但现实中有些场景只需要管一个环节（比如只用 uwf 管 code review，其他部分用 skill 或手动）。 + +问题： +- Workflow 是否应该支持嵌套或组合——小 workflow 作为大 workflow 的一个 role？ +- 还是粒度完全由用户自己决定，引擎不需要管？ +- 组合式 workflow 和单体 workflow 各自的 trade-off 是什么？ diff --git a/.cards/process-authorship-human-ai-vs-delegation.md b/.cards/process-authorship-human-ai-vs-delegation.md new file mode 100644 index 0000000..918db9f --- /dev/null +++ b/.cards/process-authorship-human-ai-vs-delegation.md @@ -0,0 +1,23 @@ +--- +title: "Process Authorship — Human-AI Collaboration vs Full Delegation" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision] +category: "architecture" +links: + - domain-experts-own-the-process + - uwf-vs-dynamic-workflow + - trust-chain-audit-evaluate-reuse + - workflow-as-improvable-system +--- + +dw 和 uwf 都面向 agent，用户都不需要会写代码。区别在于**流程的创作权**： + +- **dw**：流程由 AI 全权负责。用户描述任务，agent 决定怎么拆步骤、怎么编排。用户参与度最低，门槛最低。 +- **uwf**：流程创作是人和 AI 协作的。行业专家参与设计、审查、调优流程，agent 参与起草和执行。 + +这是主动权的取舍。dw 把流程交给 AI 是为了降低使用门槛；uwf 有意保留人对流程的参与权，代价是门槛稍高，收益是流程能融入人的领域知识。 + +背后的认知：**AI 擅长执行，但流程设计需要领域知识。** AI 不知道行业里哪个环节容易出错、哪个审批不能跳过、哪个反馈回路是血的教训换来的。这些知识在行业专家脑子里，需要一个他们能参与的载体来表达。 + +dw 赌的是 AI 能自己发现好的流程，uwf 赌的是好的流程需要人的知识参与。两个赌注没有对错，适用于不同的场景：临时任务用 dw 的零门槛更高效，反复执行的核心业务流程用 uwf 的人机协作更可靠。 diff --git a/.cards/reflective-workflow-self-improvement.md b/.cards/reflective-workflow-self-improvement.md new file mode 100644 index 0000000..d65d9f7 --- /dev/null +++ b/.cards/reflective-workflow-self-improvement.md @@ -0,0 +1,35 @@ +--- +title: "Reflective Workflow — Self-Improvement as Discipline" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern, decision] +category: "architecture" +links: + - eval-closes-the-trust-chain + - three-learning-carriers + - workflow-as-improvable-system + - feedback-loops-convergent-and-divergent + - trust-chain-audit-evaluate-reuse +--- + +FTE agent 的"成长"不靠自发顿悟，靠纪律性的反思。反思本身是纪律性的（定期跑、不能跳过、有固定步骤），所以应该用 workflow 承载——不能靠 agent "有空想想"。 + +反思 workflow 定期拉取最近执行过的任务，分析流程中出现的问题，找可优化的点，迭代，eval，对比。反思的对象覆盖三层载体： + +- 发现某个 role 反复在同一类问题上出错 → **迭代 skill** +- 发现某类任务的上下文总是缺少关键信息 → **补充记忆** +- 发现某个审批环节通过率 100% 从未驳回 → **简化 workflow** + +这形成了双层 workflow 架构： + +``` +执行层：workflow 驱动日常任务 + ↓ 产出执行记录（CAS 链） +反思层：反思 workflow 定期分析执行记录 + ↓ 产出改进建议 +改进层：迭代 memory / skill / workflow + ↓ 提升下一轮执行质量 +执行层：... +``` + +两层都是 workflow，职责不同——执行层做事，反思层改进做事的方式。用 workflow 来优化 workflow——工具改进自身的递归。 diff --git a/.cards/skill-vs-workflow-different-layers.md b/.cards/skill-vs-workflow-different-layers.md new file mode 100644 index 0000000..430e53b --- /dev/null +++ b/.cards/skill-vs-workflow-different-layers.md @@ -0,0 +1,19 @@ +--- +title: "Skill vs Workflow — Different Layers" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision] +category: "architecture" +links: + - session-isolation-as-cognitive-reset + - cognitive-process-orchestration + - agency-over-content-not-process +--- + +Skill 和 workflow 不是替代关系，是不同层次。 + +**Skill** 管的是一个 session 内怎么做——给 agent 的指令和方法论。你可以在 skill 里写"先规划再编码再 review"，但 agent 始终在同一个 session 里，review 自己刚写的代码时带着全部决策记忆。确认偏误无法靠 prompt 消除。 + +**Workflow** 管的是 session 之间怎么协作——强制 session 断裂，reviewer 进来时不知道 developer 当时为什么做那个选择，只看到产出物。这个隔离不是靠自律，是靠结构。 + +两者正交：workflow 的每个 role 里面完全可以加载 skill。Skill 提升单个 session 的能力，workflow 编排多个 session 的协作关系。 diff --git a/.cards/switching-cost-process-knowledge-as-moat.md b/.cards/switching-cost-process-knowledge-as-moat.md new file mode 100644 index 0000000..6f323f5 --- /dev/null +++ b/.cards/switching-cost-process-knowledge-as-moat.md @@ -0,0 +1,20 @@ +--- +title: "Switching Cost — Process Knowledge as Moat" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [decision, pattern] +category: "architecture" +links: + - agent-as-graduate + - opc-why-fte-agents-matter-most + - workflow-as-improvable-system + - trust-chain-audit-evaluate-reuse +--- + +Vendor 型 agent 的竞争维度是能力和价格——能做的事别人也能做，API 调用没有忠诚度。有更强更便宜的替代品，用户立刻迁移。 + +FTE 型 agent 的竞争维度多了**关系深度**。用户为了让 agent 融入业务，投入了大量沉没成本：创建、磨合、迭代各种运营流程。这些 workflow 编码了创始人反复试错优化出来的做事方法，不只是配置文件，是流程知识资产。 + +换平台意味着这些流程要重新适配，而适配过程中的试错成本才是真正的痛。传统 SaaS 的迁移成本主要是数据（导出导入），FTE agent 的迁移成本是**知识**——更高维度、更难迁移。 + +用得越久，workflow 越贴合业务，迁移成本越高，用户粘性越强。这意味着 uwf 的商业模式天然不同：不是卖 API 调用量，而是成为用户**流程资产的承载平台**。Workflow 库就是用户在平台上积累的资产。 diff --git a/.cards/three-learning-carriers.md b/.cards/three-learning-carriers.md new file mode 100644 index 0000000..da1dcc0 --- /dev/null +++ b/.cards/three-learning-carriers.md @@ -0,0 +1,22 @@ +--- +title: "Three Learning Carriers — Memory, Skill, Workflow" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - agent-as-graduate + - skill-vs-workflow-different-layers + - when-skill-is-not-enough + - opc-why-fte-agents-matter-most +--- + +完整的 FTE agent 需要三层能力载体，缺一不可： + +- **记忆强化知识** — 事实性积累。"这个客户偏好什么"、"上次这个 API 出过什么问题"。让 agent 越来越懂你的业务上下文。 +- **Skill 强化技能** — 单个 session 内的方法论。"怎么做 code review"、"怎么写测试"。提升每个环节的执行质量。 +- **Workflow 强化纪律** — session 之间的协作结构。"做一个 feature 必须经过哪些步骤"。保证流程可靠性和多视角制衡。 + +三者互补：光有 workflow 没有 skill，每个环节执行质量差；光有 skill 没有 workflow，能力强但不守规矩；光有记忆没有前两者，知道很多但不会做事。 + +出厂能力同样重要——底座模型 + 技能包决定毕业生的起点。名校博士和高中毕业，出厂就不同。但出厂能力是必要不充分的，FTE 的长期价值靠三层载体的持续积累。 diff --git a/.cards/trust-chain-audit-evaluate-reuse.md b/.cards/trust-chain-audit-evaluate-reuse.md new file mode 100644 index 0000000..681c005 --- /dev/null +++ b/.cards/trust-chain-audit-evaluate-reuse.md @@ -0,0 +1,23 @@ +--- +title: "Trust Chain — Auditable → Evaluable → Reusable → Improvable" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern, decision] +category: "architecture" +links: + - workflow-as-improvable-system + - uwf-vs-dynamic-workflow + - process-discipline-from-software-engineering +--- + +可审查、可评估、可复用不是并列的好处，而是一条因果链： + +**可审查 → 可评估 → 可复用 → 可迭代** + +不能审查的东西不敢复用——不知道它为什么 work，换个场景可能就 break。不能评估的东西不知道该不该复用——也许它其实没用，只是恰好那次任务简单。 + +这是一条信任链，每一环是下一环的前提。uwf 选择声明式 YAML 而不是 JS/TS 定义 workflow，不是技术限制，是有意降低审查门槛，让这条链的摩擦力最低。 + +dw 不是不能做这些，而是它的默认路径不鼓励这条链——即兴生成的脚本，审查成本高、评估缺乏对照、复用需要额外抽象。差异在摩擦力，不在能力边界。 + +这也是耗散结构的递归应用——不只是用流程对 agent 做负反馈（提升执行质量），还在对流程本身做负反馈（提升流程质量）。Workflow 和代码一样，需要 review、测试、度量、迭代。 diff --git a/.cards/uwf-vs-dynamic-workflow.md b/.cards/uwf-vs-dynamic-workflow.md new file mode 100644 index 0000000..a51b22b --- /dev/null +++ b/.cards/uwf-vs-dynamic-workflow.md @@ -0,0 +1,27 @@ +--- +title: "uwf vs Dynamic Workflow — Structural Differences" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision] +category: "architecture" +links: + - agency-over-content-not-process + - deterministic-engine-uncertain-agent + - session-isolation-as-cognitive-reset + - cognitive-process-orchestration + - workflow-as-improvable-system +--- + +Claude Code 的 dynamic workflow (dw) 和 uwf 都有 session 隔离——dw spawn 独立 subagent（最多 16 并发、1000 总量），每个 subagent 是独立 context，也能做对抗性 review。四个优势（认知隔离、注意力聚焦、上下文保鲜、流程可靠性）两者都具备。 + +差异不在能不能做 session 隔离和程序化流程，而在**流程和执行的解耦程度**： + +dw 的流程生成和执行是一体的——同一个 agent 既决定怎么做又开始做。流程嵌在执行里。uwf 的 workflow 是独立的持久制品，不管是人写的还是 agent 写的，一旦存在就和任何一次执行无关，可以被单独审查、讨论、迭代。 + +这个解耦在三个维度上拉开差距： + +**审查**：dw 的 JS 脚本是代码，审查门槛高，逻辑和业务细节混在一起。uwf 的 YAML 是声明式的，roles 定义关注点，graph 定义流转，一眼能看出流程结构，非工程师也能参与讨论。 + +**评估**：dw 每次生成不同脚本，难以控制变量——跑得好是流程好还是脚本碰巧写得好？uwf 的 workflow 固定，跑 N 次可以统计成功率，增减 role 后效果差异可以归因到流程变更。 + +**复用**：dw 脚本为特定任务生成，复用需要手动泛化。uwf 的 workflow 天然是通用模板——solve-issue 就是 solve-issue，换个 repo 换个 issue 直接跑。 diff --git a/.cards/when-skill-is-not-enough.md b/.cards/when-skill-is-not-enough.md new file mode 100644 index 0000000..8ef0f61 --- /dev/null +++ b/.cards/when-skill-is-not-enough.md @@ -0,0 +1,24 @@ +--- +title: "When Skill Is Not Enough — Workflow Judgment Call" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, decision, pattern] +category: "architecture" +links: + - skill-vs-workflow-different-layers + - attention-isolation-breaks-cognitive-inertia + - feedback-loops-convergent-and-divergent + - agency-over-content-not-process +--- + +**Skill 够用的场景：** 任务在单一认知模式下可以完成好。查资料、写文档、跑部署脚本、按规范格式化——不需要自我对抗，一个 session 带着清晰指令一路执行到底就行。 + +**Workflow 更好的场景：** 任务需要在不同认知模式之间切换，且这些模式之间存在张力。典型标志： + +1. **产出需要被"不知道过程"的眼睛审视** — 写代码+review、写方案+挑战、翻译+校对。一个 session 做不到真正的自我审视，确认偏误是自回归结构决定的，不是 prompt 能修的。 + +2. **出错成本高到需要结构性保证** — 不是"建议你 review 一下"，而是"你不可能跳过 review"。Skill 是建议，workflow 是制度。 + +3. **需要收敛到明确的质量标准** — 负反馈环驱动修正直到通过，而不是 agent 自己觉得"差不多了"。 + +**判词：当任务复杂到 agent 可能说服自己"错的是对的"时，你需要 workflow 的结构隔离，而不是 skill 的行为指导。** diff --git a/.cards/workflow-as-improvable-system.md b/.cards/workflow-as-improvable-system.md new file mode 100644 index 0000000..9bc7f71 --- /dev/null +++ b/.cards/workflow-as-improvable-system.md @@ -0,0 +1,20 @@ +--- +title: "Workflow as an Improvable System" +created: "2026-06-07" +source: "openclaw-xiaomo" +tags: [architecture, pattern] +category: "architecture" +links: + - uwf-vs-dynamic-workflow + - process-discipline-from-software-engineering + - feedback-loops-convergent-and-divergent + - cognitive-process-orchestration +--- + +uwf 把 workflow 定位为**可持续改进的系统**，而不是一次性的任务完成工具。 + +LLM 能力在快速提升，但单次执行的可靠性永远有上限。真正的杠杆不在于某一次跑得好不好，而在于流程本身能不能从每次执行中学到东西、越来越好。这需要流程是可审查的（看得懂才能改）、可评估的（量化才能知道改对没有）、可复用的（积累才有复利）。 + +dw 每次重新生成脚本，某种意义上是在放弃之前执行的经验——每次从零开始发明流程。uwf 把流程固化为独立制品，每次迭代都在前一版基础上改进。v1 没有 tester 角色，加上 tester 变成 v2，效果可量化对比。 + +这是一个有记忆的系统——记忆不在 agent 的 context 里，而在 workflow 的版本历史里。