Merge pull request 'docs: expand .cards — vision, comparisons, business rationale' (#157) from docs/project-cards into main

2026-06-07 11:50:48 +00:00
parent f697aec3e7 04e2b5b8a7
commit 8b01ade66a
21 changed files with 485 additions and 0 deletions
@@ -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 的具体对比。
@@ -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 隔离（流程纪律靠结构而非自觉）。
@@ -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 消除，只能靠结构隔离。
@@ -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 的应用范围不限于软件开发流程，而是任何需要多视角、多轮次认知协作的场景。
@@ -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 多了一个沉淀层。
@@ -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 的根本原因：**流程的设计权应该属于懂流程的人**。
@@ -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 就不只是一个执行引擎，而是一个**自我改进的流程系统**。
@@ -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 真正在设计的是**在哪里放什么样的环**。
@@ -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。
@@ -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 的左膀右臂，而不是需要时刻看管的外包。
@@ -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 的共享和权限模型是什么样的？
@@ -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 是什么？
@@ -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 的人机协作更可靠。
@@ -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——工具改进自身的递归。
@@ -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 的协作关系。
@@ -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 库就是用户在平台上积累的资产。
@@ -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 的长期价值靠三层载体的持续积累。
@@ -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、测试、度量、迭代。
@@ -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 直接跑。
@@ -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 的行为指导。**
@@ -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 的版本历史里。