Merge pull request 'docs: add 6 FTE concept cards' (#160) from cards/fte-concepts into main

.cards/agent-as-graduate.md

@@ -1,30 +1,19 @@
 ---
-title: "Agent as Graduate — Not Outsource, Not Genius Intern"
+title: "Agent as Graduate — The Onboarding Metaphor"
 created: "2026-06-07"
 source: "openclaw-xiaomo"
-tags: [architecture, decision, pattern]
+tags: [concept, analogy]
-category: "architecture"
+category: "product"
 links:
-  - process-authorship-human-ai-vs-delegation
+  - vendor-vs-fte-who-defines-capability
-  - domain-experts-own-the-process
+  - three-learning-carriers
-  - workflow-as-improvable-system
+  - fte-maturity-threshold
-  - trust-chain-audit-evaluate-reuse
 ---
 
-交付给用户的 agent buddy 不应该只是装备了行业 know-how 的特定任务执行者，而应该是可以和用户共同讨论、适应到客户实际业务流程中的**"毕业生"**。
+FTE 型 agent 最贴切的类比：**应届毕业生**。
 
-毕业生有专业知识、有执行能力、学东西快，但不了解公司的具体流程——不知道哪个环节是因为三年前出过事故才加上的，不知道这个审批为什么要过两道。好的毕业生跟着老师傅一边干一边学，理解流程背后的原因，逐渐能独立执行甚至提出改进建议。
+出厂时有通用能力（底座模型 = 学历），但不懂你的业务、不知道你的偏好、没有你的流程经验。用户的角色是"带教老师"——通过日常协作，逐步把 agent 带成自己的得力助手。
 
-Workflow 就是这个**带教结构**。行业专家把经验编码到 workflow 里，agent 在这个框架下执行。随着磨合，workflow 本身也在迭代——某个环节发现不需要了，某个地方需要加一道校验。
+这个类比揭示了当前 FTE 产品的核心瓶颈：**带教门槛太高**。现在只有技术背景深厚的用户才能"带"——能写 skill、能调 workflow、能 debug agent 行为。行业专家（不懂代码的人）被挡在门外。
 
-定位的核心差异：我们交付的是 **new graduates as FTEs**，而非 **professional vendors**。
+真正成熟的 FTE 型产品 = 降低带教门槛，让非技术用户也能教会 agent 自己的业务。
-
-Vendor 交付结果——你不关心他内部怎么运作，合同到期换一家也行。FTE 毕业生交付的是融入——你花时间带他、把流程教给他、他理解你的业务逻辑，这个投入随时间产生复利。
-
-三种模式的对比：
-
-- **Skill 模式（外包）** — 丢任务过去不管怎么做只看结果。能用，但不成长，不适应业务。
-- **dw 模式（天才实习生）** — 每次自己想一套做法，可能很惊艳，但不积累、不传承、不跟团队形成默契。
-- **uwf 模式（FTE 毕业生）** — 在团队流程中工作，流程和人相互适应，共同成长。
-
-uwf 所有设计选择都在支撑 FTE 模式：可审查（看得懂他在做什么）、可评估（衡量做得好不好）、可迭代（持续改进工作方式）、session 隔离（流程纪律靠结构而非自觉）。

.cards/fte-maturity-threshold.md

@@ -0,0 +1,25 @@
+---
+title: "FTE Maturity Threshold — Who Can Onboard an Agent"
+created: "2026-06-07"
+source: "openclaw-xiaomo"
+tags: [concept, decision]
+category: "product"
+links:
+  - agent-as-graduate
+  - vendor-vs-fte-who-defines-capability
+  - three-learning-carriers
+---
+
+FTE 型 agent 的成熟度，归根结底看一个问题：**谁能带教它？**
+
+当前阶段（2026）：OpenClaw、Claude Code、Hermes 都是 FTE 型产品的雏形，三者都具备 memory/skill/workflow 三个载体。但它们的用户画像高度重叠——有较深技术能力的开发者。
+
+这意味着 FTE agent 现在更像"只有技术 lead 才能带的毕业生"。要跨越鸿沟，需要降低带教门槛到**行业专家（不懂代码的人）也能带、也能教、也能调优**。
+
+谁先把这个门槛降下来，谁就定义了 FTE agent 品类的分水岭。
+
+可能的降低路径：
+- **自然语言 skill 定义**（不需要写代码/YAML）
+- **可视化 workflow 编辑**（拖拽而非配置）
+- **Agent 主动学习**（从用户行为中推断偏好，而非等用户显式配置）
+- **带教过程本身被 agent 化**（用 agent 辅助用户定义 skill 和 workflow）

.cards/fte-product-landscape.md

@@ -0,0 +1,23 @@
+---
+title: "FTE Product Landscape — OpenClaw, Claude Code, Hermes"
+created: "2026-06-07"
+source: "openclaw-xiaomo"
+tags: [concept, comparison]
+category: "product"
+links:
+  - vendor-vs-fte-who-defines-capability
+  - three-learning-carriers
+  - fte-maturity-threshold
+  - agent-as-graduate
+---
+
+2026 年中，FTE 型 agent 的代表产品对比：
+
+**共性**：都有 memory、skill、workflow/多步协作机制，都面向技术用户。
+
+**差异点**：
+- **OpenClaw** — uwf 引擎驱动，用 YAML 定义多角色 workflow，强调流程纪律和 session 隔离。面向团队级 agent 协作。
+- **Claude Code** — Anthropic 官方 CLI agent，CLAUDE.md 作为 memory，skill 通过项目约定积累。单 agent 深度协作，开发者体验好。
+- **Hermes** — 跨平台 agent 协调者，memory/skill/cron 体系完善，支持多 agent 调度。偏个人效率工具。
+
+三者都谈不上成熟。成熟的标志不是技术完备度，而是**非技术用户能否用起来**。

.cards/opc-why-fte-agents-matter-most.md

@@ -1,33 +1,22 @@
 ---
-title: "OPC — Why One Person Companies Need FTE Agents Most"
+title: "OPC — Why FTE Agents Matter Most"
 created: "2026-06-07"
 source: "openclaw-xiaomo"
-tags: [architecture, pattern, decision]
+tags: [vision, decision]
-category: "architecture"
+category: "product"
 links:
+  - vendor-vs-fte-who-defines-capability
   - agent-as-graduate
-  - process-authorship-human-ai-vs-delegation
+  - fte-maturity-threshold
-  - workflow-as-improvable-system
-  - domain-experts-own-the-process
 ---
 
-One Person Company (OPC) 是 FTE 型 agent 价值主张最清晰的场景。
+OpenClaw 押注 FTE 型 agent 的核心判断：**AI 的终极形态不是工具，是同事。**
 
-OPC 的核心矛盾：一个人要覆盖所有职能（产品、开发、测试、运营、客服、财务），不可能精通所有领域，但每个领域都需要靠谱的流程保证质量。
+工具被使用，同事被培养。工具的价值在出厂那一刻确定，同事的价值随协作持续增长。
 
-Vendor 型 agent 适合偶发性、标准化任务——生成图片、翻译文档，用完即走。FTE 型 agent 适合核心业务流程——反复执行、有领域特殊性、出错成本高的环节。
+这个判断决定了产品方向：
+- 不做"最强的单次对话"，做"最能被带教的长期协作者"
+- 不做"开箱即用的成品"，做"越用越好用的底座"
+- 核心指标不是 benchmark 分数，是用户留存和 skill 积累量
 
-OPC 不是"一个人用很多工具"，而是"一个 CEO 管一个全 agent 团队"。全用 vendor 型 agent，CEO 是人肉编排器——每个任务都要自己拆、分配、检查、决定下一步，agent 越多协调开销越大，CEO 本人成为系统瓶颈。
+uwf 是这个判断的工程实现——用流程纪律让 agent 的产出可靠，让用户敢把真正的业务交给它。
-
-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 的左膀右臂，而不是需要时刻看管的外包。

.cards/switching-cost-process-knowledge-as-moat.md

@@ -2,19 +2,20 @@
 title: "Switching Cost — Process Knowledge as Moat"
 created: "2026-06-07"
 source: "openclaw-xiaomo"
-tags: [decision, pattern]
+tags: [concept, decision]
-category: "architecture"
+category: "product"
 links:
+  - vendor-vs-fte-who-defines-capability
+  - three-learning-carriers
   - agent-as-graduate
-  - opc-why-fte-agents-matter-most
-  - workflow-as-improvable-system
-  - trust-chain-audit-evaluate-reuse
 ---
 
-Vendor 型 agent 的竞争维度是能力和价格——能做的事别人也能做，API 调用没有忠诚度。有更强更便宜的替代品，用户立刻迁移。
+FTE 型 agent 的护城河不是技术壁垒，是**用户自己积累的流程知识**。
 
-FTE 型 agent 的竞争维度多了**关系深度**。用户为了让 agent 融入业务，投入了大量沉没成本：创建、磨合、迭代各种运营流程。这些 workflow 编码了创始人反复试错优化出来的做事方法，不只是配置文件，是流程知识资产。
+用得越久，agent 越懂你的业务——记忆里有你的偏好，skill 里有你验证过的做法，workflow 里有你打磨过的流程。换一个 agent = 重新带一个毕业生，之前的积累全部作废。
 
-换平台意味着这些流程要重新适配，而适配过程中的试错成本才是真正的痛。传统 SaaS 的迁移成本主要是数据（导出导入），FTE agent 的迁移成本是**知识**——更高维度、更难迁移。
+这解释了为什么 FTE 型产品的竞争逻辑和 vendor 型完全不同：
+- **Vendor 型**竞争模型能力（谁的基座更强），switching cost 低，用户随时换
+- **FTE 型**竞争生态粘性（谁让用户积累得更深），switching cost 随使用时长增长
 
-用得越久，workflow 越贴合业务，迁移成本越高，用户粘性越强。这意味着 uwf 的商业模式天然不同：不是卖 API 调用量，而是成为用户**流程资产的承载平台**。Workflow 库就是用户在平台上积累的资产。
+风险面：如果用户的流程知识被锁死在一个平台，就变成了 vendor lock-in。开放的知识格式（如 markdown skill、YAML workflow）是对冲手段。

.cards/three-learning-carriers.md

@@ -2,21 +2,20 @@
 title: "Three Learning Carriers — Memory, Skill, Workflow"
 created: "2026-06-07"
 source: "openclaw-xiaomo"
-tags: [architecture, pattern]
+tags: [architecture, concept]
-category: "architecture"
+category: "product"
 links:
+  - vendor-vs-fte-who-defines-capability
   - agent-as-graduate
-  - skill-vs-workflow-different-layers
+  - switching-cost-process-knowledge-as-moat
-  - when-skill-is-not-enough
-  - opc-why-fte-agents-matter-most
 ---
 
-完整的 FTE agent 需要三层能力载体，缺一不可：
+FTE 型 agent 的能力积累依赖三个载体：
 
-- **记忆强化知识** — 事实性积累。"这个客户偏好什么"、"上次这个 API 出过什么问题"。让 agent 越来越懂你的业务上下文。
+1. **Memory（记忆）**— 用户偏好、环境事实、历史上下文。跨 session 持久化，让 agent 不用每次从零开始。
-- **Skill 强化技能** — 单个 session 内的方法论。"怎么做 code review"、"怎么写测试"。提升每个环节的执行质量。
+2. **Skill（技能）**— 可复用的操作程序。解决过的问题沉淀成步骤，下次直接调用。
-- **Workflow 强化纪律** — session 之间的协作结构。"做一个 feature 必须经过哪些步骤"。保证流程可靠性和多视角制衡。
+3. **Workflow / DW（流程）**— 多步骤协作模式。把复杂任务拆成角色和阶段，用流程纪律保障质量。
 
-三者互补：光有 workflow 没有 skill，每个环节执行质量差；光有 skill 没有 workflow，能力强但不守规矩；光有记忆没有前两者，知道很多但不会做事。
+三者的关系：memory 是"认识你"，skill 是"会做事"，workflow 是"知道怎么把事做好"。
 
-出厂能力同样重要——底座模型 + 技能包决定毕业生的起点。名校博士和高中毕业，出厂就不同。但出厂能力是必要不充分的，FTE 的长期价值靠三层载体的持续积累。
+OpenClaw、Claude Code、Hermes 都已具备这三个载体，但成熟度各异。差异在于：用户能多容易地往这三个载体里"灌"自己的知识。

.cards/vendor-vs-fte-who-defines-capability.md

@@ -0,0 +1,29 @@
+---
+title: "Vendor vs FTE — Who Defines the Agent's Capability"
+created: "2026-06-07"
+source: "openclaw-xiaomo"
+tags: [architecture, decision]
+category: "architecture"
+links:
+  - agent-as-graduate
+  - three-learning-carriers
+  - switching-cost-process-knowledge-as-moat
+  - opc-why-fte-agents-matter-most
+---
+
+区分 vendor 型和 FTE 型 agent 最本质的一条：**谁定义 agent 的能力。**
+
+- **Vendor 型**：开发者定义能力，用户消费能力。能力边界在发布那一刻就定了，升级主动权在开发者。
+- **FTE 型**：开发者定义出厂能力（底座模型 + 基础技能包），用户持续定义能力（记忆、skill、workflow）。
+
+出厂是起点不是终点。用户通过积累记忆、训练 skill、设计 workflow，持续塑造 agent 的能力。用得越久，越贴合自己的业务，越不像别人的 agent。
+
+引申的两个特征：
+- **成长性** — vendor 的能力随模型升级变化，不随使用积累；FTE 的能力随使用持续积累
+- **流程适配性** — vendor 是用户适应工具；FTE 是工具适应用户的业务流程
+
+这也解释了 switching cost 的来源——换掉的不是一个产品，是用户自己定义出来的能力。
+
+代表产品：
+- **Vendor 型**：ChatGPT、Claude（对话式）、Midjourney（图像生成）、Perplexity（搜索问答）、各种 GPTs
+- **FTE 型**：OpenClaw、Claude Code、Hermes 都在往这个方向走——有记忆、有 skill/workflow 机制、有持续协作关系。但尚未成熟，目前都面向有较深技术能力的用户。真正成熟的 FTE 型产品，应该是行业专家（不懂代码的人）也能带、也能教、也能调优的。这个门槛什么时候降下来，谁先降下来，可能就是这个品类的分水岭。