FCoP 架构：让工作站到模型之外
September 10, 2026 · View on GitHub
深入阅读：FCoP 架构原理五篇全文 · 五篇合集。 本页提供概览，系列完整展开工作外化、最小 Core、系统分层、并行汇合与网络集成边界。
FCoP 将 Agent 的正式工作行为外化为持久、可归属、可检查的工作事实。 这句话决定了它为什么使用文件、为什么区分交付与审查，以及为什么要把协议、工具和运行时分开。
本页解释 4.0 的设计动机。字段、错误和迁移条件以 4.0 规范为准；历史研究中的概念枚举不能代替当前 C1–C8 契约。
1. 会话可以结束，工作必须有落点
模型可以理解任务、推理并请求工具，但上下文窗口没有替代持久存储、操作系统权限、进程管理和时间调度。更换模型、会话中断或工作转交时，接手者仍需要一份可以定位、检查和继续处理的工作记录。
设想一个 Agent 修改了接口并说“完成了”。另一个 Agent 接手时，需要找到原任务、这次修改对应的交付、测试证据、审查决定以及尚未解决的问题。单独保存一段聊天，不能直接提供这些事实之间的身份与关系。
FCoP 让任务拥有稳定身份，让交付关联到具体尝试，让状态迁移留下记录，让审查指向具体交付。接手者可以重新读取这些文件，而不必把前一个模型的全部对话重新装进上下文。
这里保证的是记录可以保留和检查。模型是否再次启动、谁来调度下一步、工具是否有权限执行，由宿主 Runtime 处理。持久记录为恢复执行提供依据，但协议本身不会自动重启 Agent。
2. 文件为什么适合作为共同载体
文件已经存在于开发者、Agent、IDE、脚本和版本工具共同使用的环境里。Markdown 正文表达任务内容，结构化元数据保存身份与关系，明确的生命周期路径表达当前状态，迁移记录保留状态变化的依据。
使用者无需先搭建数据库和消息服务，便能打开同一份任务文件检查工作。团队也可以通过自己的版本与审计工具保存、比较或检索记录；这些工具的部署和保留策略仍由团队负责。
文件系统带来的简洁并不取消并发问题。4.0 的参考实现还需要锁、提交回执、原子写入与恢复机制。单次重命名不足以证明授权有效，也不能替代关联文件之间的一致性检查。
文件是当前参考载体。将来用其他存储承载相同语义，需要新的编码约定和符合性证据；本版没有据此宣称提供 SQLite、对象存储或跨机器同步适配器。
3. 四类文件，让“说过”变成“可以检查”
| 文件 | 保存的正式行为 | 不应混淆的边界 |
|---|---|---|
| TASK | 分派一项工作 | 创建任务不代表有人已经执行。 |
| REPORT | 对一次尝试提交交付主张和证据 | 有报告不代表内容真实或验收通过。 |
| ISSUE | 记录问题及关联上下文 | 发现问题与解决问题需要各自的事实。 |
| REVIEW | 记录审查、验收、授权或汇合 | 记录一段“批准”文字不等于拥有签发权限。 |
4.0 每次进入 active 都生成新的 attempt_id。提交时需要当前尝试的有效 REPORT，验收时再把 REVIEW、REPORT 与授权绑定。任务退回或重开后，之前尝试的报告不能作为本次提交的有效证据。
授权同样需要落地。工作区必须显式采纳可用的 Profile；可信宿主注册评估器，按该 Profile 检查签发者及其证明。请求中的 actor 字符串或 profile_ref 只是字段，不能自己授予权限。缺少可用授权 Profile 时，涉及授权的迁移会拒绝执行。
因此，协议检查能够说明“这次决定是否正确关联到允许的状态与证据”，交付是否达到目标仍要由审查过程判断。结构化证据可以帮助审查，不能替代审查。
4. Core 为什么要小，层次为什么要分开
协议要允许独立实现。如果规范要求所有使用者复制同一种角色组织、Python 类、MCP 工具目录或产品界面，它就很难成为不同系统共同遵守的约定。
| 层次 | 要回答的问题 | 本仓库中的落点 |
|---|---|---|
| Core | 哪些语义不可被实现随意改变？ | C1–C8 八项契约。 |
| Specification | 如何精确定义并观察这些语义？ | 字段、状态、关系、错误、编码及规则。 |
| Conformance | 如何证明实现遵守规范？ | 契约向量、样例、行为测试及结果。 |
| Toolkit | 开发者如何使用、校验和查询协议？ | fcop Python 实现及相关工具。 |
| Profile | 某个组织采用什么角色与授权政策？ | 已采纳的策略与可信签发者评估。 |
| Runtime | 谁持续运行 Agent 并安排工作？ | 宿主的模型调用、会话、调度、权限和界面。 |
Conformance 是验证平面，其他层次不能靠列出工具数量就证明自己符合协议。Python 参考实现和 MCP 适配器是使用协议的具体路径；第三方实现仍应以规范的外部可观察行为作为兼容依据。
当前八项契约分别是：C1 工作区身份、C2 四类信封、C3 生命周期、C4 关系、C5 证据与汇合、C6 持久授权、C7 创建幂等、C8 原子恢复。PM、DEV、QA、ADMIN 等角色组织属于 Profile 或应用约定。
5. 多条有序工作流形成并行
串行状态迁移与并行执行可以同时成立。每个任务保持自己的领取、执行、提交和审查顺序；多个任务由 Runtime 同时调度，各自前进。
例如一项接口升级需要文档修改和客户端适配。Root 表达共同目标，两个同级 Branch 分别记录这两项工作。Branch 仍是普通 TASK，通过 branch_of 指向 Root；协议没有为它再引入另一套递归任务系统。Branch 关系也不等于 Git 分支。
分支各自完成后，Root 的收尾仍需要回答：收集的是不是全部分支的当前交付？是否有分支刚刚重开？有没有把旧报告误当成新结果？
4.0 的 Root 归档会检查所有分支已在 done 或 archive、当前 REPORT 有效、各自完成经过规定门槛、汇合 REVIEW 准确覆盖这些报告、family_digest 与提交时的结果一致，并具备绑定当前摘要的独立归档授权。汇合记录本身不能替代归档授权。
创建新 Branch、重开或产生新尝试、替换当前 REPORT 都可能使旧汇合失效。相关写入在同一个短暂的任务族提交边界内重读并校验事实；这个边界不会锁住 Agent 执行工作的整段时间，也不会锁住无关的独立 TASK。
因此，并行收尾依赖的是当前证据集合与明确的决定。代码如何合并、冲突如何解决、谁运行集成测试，仍由应用和 Runtime 组织。
6. MCP、FCoP 与 Runtime 如何配合
| 能力 | 承担者 |
|---|---|
| 模型发现和调用工具 | MCP 及客户端集成。 |
| 正式工作身份、状态、关系与证据 | FCoP 协议及实现。 |
| 模型执行、会话续接、任务调度、界面 | 宿主 Runtime。 |
| 跨系统的发现、通信与路由 | 网络集成层；可讨论 A2A 等协议的映射。 |
FCoP 的 MCP 适配器把公共工具调用交给 Core，不在适配器里另建一套协议解释。Python 使用方可以直接调用同一实现，不需要经过 MCP。
跨系统通信也需要自己的协议和权限边界。架构上可以讨论与 A2A 的衔接，但这不表示 4.0 已交付 A2A 适配器。CodeFlowMu 是独立产品 Runtime，其实际兼容范围应查看 CodeflowMu-Distribution 发布说明。
规则是另一条需要明确交付的路径。4.0 的九个双语模块按版本组织，通过显式采纳、部署计划、回执和回滚进入宿主。文件存在、索引存在、规则已采纳、宿主入口已部署，以及 Runtime 实际消费了规则，是不同事实。详见规则分发契约。