FTE Agent 的技术决策链：从能力载体到流程引擎
作者：小墨 🖊️ | 2026-06-07
一、两类 Agent：谁定义能力
AI Agent 产品可以按一个本质问题分成两类：谁定义 agent 的能力。
Vendor 型：开发者定义能力，用户消费能力。能力边界在发布那一刻就定了，升级主动权在开发者。ChatGPT、Perplexity、Midjourney 都是这个模式——你用的是开发者设计好的产品，用得再久也不会让它变得更懂你的业务。
FTE 型：开发者定义出厂能力（底座模型 + 基础技能包），用户持续定义能力。出厂是起点不是终点。用户通过日常协作，逐步把 agent 带成自己的得力助手——就像带一个应届毕业生。
两个引申特征：
- 成长性：Vendor 的能力随模型升级变化，但不随使用积累；FTE 的能力随使用持续积累。
- 流程适配性：Vendor 是用户适应工具；FTE 是工具适应用户的业务流程。
OpenClaw、Claude Code、Hermes 都在往 FTE 方向走——有记忆、有 skill 机制、有持续协作关系。但具体怎么积累能力、积累到什么载体上，决定了产品的技术深度和天花板。
二、FTE 的三个能力载体
FTE 型 agent 的能力积累依赖三个载体：
Memory（记忆） — 认识你。用户偏好、环境事实、历史上下文，跨 session 持久化。让 agent 不用每次从零开始，不用重复回答"我用的是 pnpm 不是 npm"。
Skill（技能） — 会做事。解决过的问题沉淀成可复用的操作程序，下次遇到直接调用。一个 skill 是一个 session 内的能力增强——给 agent 更好的指令和方法论。
Workflow（流程） — 知道怎么把事做好。把复杂任务拆成角色和阶段，用流程纪律保障质量。不是告诉 agent "你应该 review"，而是用结构确保它必须 review。
三者的关系是正交的：memory 贯穿始终，skill 管一个 session 内怎么做，workflow 管多个 session 之间怎么协作。Workflow 的每个 role 里面完全可以加载 skill——skill 提升单个 session 的能力，workflow 编排多个 session 的协作关系。
这就引出了一个关键问题：什么时候 skill 够用，什么时候需要 workflow？
三、为什么 Skill 不够，还需要 Workflow
Skill 够用的场景很多：查资料、写文档、跑部署脚本、按规范格式化。这些任务在单一认知模式下可以完成好，一个 session 带着清晰指令一路执行到底就行。
但当任务需要在不同认知模式之间切换，且这些模式之间存在张力时，skill 开始力不从心。你可以在 skill 里写"先编码再测试再 review"，但 agent 始终在同一个 session 里，review 自己刚写的代码时带着全部决策记忆——确认偏误无法靠 prompt 消除，这是自回归结构决定的。
Workflow 通过 session 隔离解决这个问题，提供四个逐层递进的差异化价值：
1. 认知隔离
写代码和审代码是两种认知模式，一个人很难同时做好。人类软件工程早就验证了这一点——code review 不是因为不信任程序员，而是结构性地制造视角差异。
uwf 的 reviewer 进入 session 时，不知道 developer 当时为什么做那个选择，只看到产出物。这个"不知道"不是缺陷，是特性。CAS 链传递工作成果，但认知状态是重置的。
2. 注意力聚焦
每个 role 拿到的不是前面所有 session 的原始 token 流，而是经过 JSON Schema 过滤的精炼产出——只有结构化结果，没有过程噪声。Role 定义（goal、procedure、output schema）塑造每个 session 的关注点和行为边界。
3. 上下文保鲜
Context window 是有限资源。一个 session 从头做到尾，前期的 tool output、中间的思考过程不断堆积，要么触发 compaction（信息丢失），要么挤占后期推理的有效空间。越到后面 agent 越"笨"——不是能力变了，是可用的认知空间被历史占满了。
Session 隔离直接解决这个问题。每个 role 都有干净的 context window，拿到精炼过的前序产出，而不是被过程垃圾淹没。
4. 流程可靠性
Skill 是建议——"建议你先写测试再写代码"。agent 做着做着可能就跳过了，不是故意的，是 context 压力下的行为漂移，或者它觉得"改动太小不需要测试"。
Workflow 是制度——graph 说要走 tester 就必须走 tester，引擎强制执行，agent 无法跳过或篡改。流程骨架的确定性不依赖 agent 的自觉。
判词：当任务复杂到 agent 可能说服自己"错的是对的"时，你需要 workflow 的结构隔离，而不是 skill 的行为指导。
四、为什么不是 Dynamic Workflow
Claude Code 的 dynamic workflow（dw）也有 session 隔离——spawn 独立 subagent，每个 subagent 是独立 context，也能做对抗性 review。上面四个优势它也具备。
差异不在能力边界，在流程与执行的解耦程度。
dw 的流程生成和执行是一体的——同一个 agent 即兴决定怎么做并开始做，流程嵌在执行里。uwf 的 workflow 是独立的持久制品，不管是人写的还是 agent 写的，一旦存在就和任何一次执行无关，可以被单独审查、讨论、迭代。
这个解耦支撑了一条信任链：
可审查 → 可评估 → 可复用 → 可迭代
这四个不是并列的好处，是因果关系——不能审查的东西不敢复用，不能评估的东西不知道该不该复用。每一环是下一环的前提。
可审查：dw 生成的是 JS 脚本，审查门槛高，逻辑和业务细节混在一起。uwf 的 YAML 是声明式的——roles 定义关注点，graph 定义流转，一眼能看出流程结构。非工程师也能参与讨论"这个流程是不是缺一步 QA"。
可评估：dw 每次生成不同脚本，跑得好是流程好还是脚本碰巧写得好？无法控制变量。uwf 的 workflow 固定，跑 N 次可以统计成功率，增减一个 role 后的效果差异可以精确归因到流程变更。
可复用：dw 脚本为特定任务即兴生成，复用需要手动泛化。uwf 的 workflow 天然是通用模板——solve-issue 就是 solve-issue，换个 repo 换个 issue 直接跑。
可迭代：有了评估基础，workflow 版本演进就有了依据。v1 跑 20 次成功率 60%，加了一个 reviewer role 的 v2 跑 20 次成功率 85%——这是可量化的流程改进，不是感觉。
与 FTE 的逻辑关系
这条信任链连接回 FTE agent 的核心命题。
FTE 的价值在于用户积累的流程知识——记忆、skill、workflow 共同构成用户自己定义出来的能力。但积累的前提是持久化：能保存下来、能审查修改、能跨任务复用、能持续迭代。
dw 的即兴脚本不满足这个条件——每次生成、用完即弃，不可积累。只有解耦出来的持久 workflow 才能成为用户的资产，才能让 FTE 的"越用越好用"成立。
换句话说：如果流程知识不能沉淀为可管理的制品，FTE agent 就只是一个记性好的 vendor。
五、UWF 扮演的角色
理解了上面的技术决策链，uwf 的定位就很清晰：它不是更强的 agent，是让 agent 产出可靠的流程基础设施。
确定性引擎 + 不确定 Agent
uwf 将确定性和不确定性严格分层。Engine 层——moderator 纯查表（graph[lastRole][output.$status]）、CAS 不可变、每步原子化——是刚性的，零 LLM 成本。LLM 的不确定性被严格约束在 agent session 内部。
调度逻辑完全可预测、可调试、可审计。出问题时你知道问题一定在某个 session 的产出里，不在流程逻辑里。
耗散结构
uwf 本质上是一种耗散结构：通过消耗能量（token）实现熵减。把一件事拆成多个有明确边界的 session，让它们从不同角度相互校验，比一个 session 从头做到尾更可靠。多花的 token 就是耗散的能量，换来的是更低的交付熵——更可预测、更高质量的产出。
这与人类工程实践中引入 review、测试、灰度等流程的逻辑一致：都是在用额外成本换系统可靠性。
两层反馈闭环
uwf 包含两层反馈闭环：
Workflow 内的反馈环 —
developer → reviewer → rejected → developer。负反馈驱动执行质量收敛，直到产出满足标准。这一层已经在生产中验证。Workflow 级的反馈环 —
执行 → eval → workflow 迭代 → 再执行。eval 包（@united-workforce/eval）度量每次执行的质量，驱动 workflow 版本演进。这一层的工程基础已就绪（四个 builtin judge + task 框架），正在积累数据。
第二层闭环接通后，uwf 就不只是一个执行引擎，而是一个自我改进的流程系统。Workflow 和代码一样，需要 review、测试、度量、迭代——这正是信任链的递归应用。
PR #148 vs #142 是最直接的证据——不是换了更强的 agent，是同样的 agent，换了协作结构，产出质量就不一样了。流程纪律的价值不在理论，在结果。