Agent 没有操作系统：为什么 FCoP 选择把工作行为外化到文件系统
原稿：2026-09-01 · 发布修订：2026-09-10 · 对齐 FCoP 4.0.0
本文解释架构取舍；字段、迁移与错误以 4.0 契约为准，版本状态见 4.0.0 发布说明。原始设计建议已按当前版本修订；示意流程不等于可直接执行的 API 示例。
今天的大模型可以写代码、查资料、调用工具、分析数据，甚至连续执行很长的任务。
但有一个很容易被忽略的问题：
Agent 并不拥有自己的操作系统。
这里说“没有操作系统”，不是说 Agent 脱离 Windows、Linux 或其他 Host 运行。恰恰相反，Agent 的文件、进程、网络、时钟、权限和持久化能力，都来自 Host、Runtime 和操作系统。模型本身并不天然拥有这些能力。
Agent 可以说：
“我接下这个任务。”
也可以说：
“我已经完成。”
甚至可以说：
“问题已经修复并通过验证。”
但如果这些行为只存在于模型上下文或聊天记录里，它们不会天然成为持续存在的工作事实。会话关闭、上下文压缩、Host 重启、模型切换，甚至一次响应丢失，都可能让“刚才到底发生了什么”重新变得模糊。
FCoP 最初真正要解决的，就是这个问题。
它没有选择给 Agent 再造一个操作系统，也没有首先建立数据库、消息队列或分布式控制平面，而是采取了一条更直接的路线：
把 Agent 的正式工作行为外化。
在单机系统里，最自然的外化界面就是文件系统。
一、Agent 很强，但它没有天然持久的“工作世界”
一个 Agent 最基础的工作条件通常只有：
模型
+
当前上下文
+
Host 暴露的工具
它自己并不天然拥有：
持久文件系统
进程系统
系统时钟
事务机制
可靠状态机
用户权限系统
长期任务账本
这些能力属于操作系统和 Runtime。
因此：
Agent:
“我已经接手 TASK-12”
首先只是一个语言行为。
如果没有外部状态承载：
Agent Context
×
这项“接手”就可能和上下文一起消失。
这就是“Agent 能做事”与“Agent 能持续承担工作”之间的差别。
数字员工如果要真正承担岗位责任，工作状态不能依赖模型记得住。
二、为什么保存聊天还不够？
最简单的办法似乎是：把所有聊天记录保存下来。
但这仍然没有解决问题。
因为：
“我准备开始。”
“应该快完成了。”
“我觉得这个版本没问题。”
这些都是语言表达，不等于正式工作行为。
FCoP 因此把少数具有明确工作意义的行为外化成正式对象：
TASK
REPORT
ISSUE
REVIEW
例如：
“请把 Windows 安装流程补齐”
只有被外化为 TASK，才成为正式委派。
执行者说：
“我完成了。”
不会自动把任务变成成功，而是形成一个 REPORT：执行者正式提交了结果。
发现故障：
ISSUE
独立检查：
REVIEW
这一步的意义不是“把聊天换成 Markdown”。
真正发生的是：
Agent 内部行为
↓
外化
↓
操作系统中的持久工作对象
也就是说：
工作不再只活在模型上下文里。
三、为什么是文件，而不是数据库？
FCoP 完全可以从一开始就选择数据库：
tasks
reports
issues
reviews
也可以选择消息队列：
Kafka
RabbitMQ
Redis Streams
甚至建立完整中心服务：
Agent
↓
SDK
↓
API
↓
Workflow Service
↓
Database
这些方案可以针对高并发、事务和跨机器通信提供不同的工程能力；具体取舍仍要看负载与实现。本文没有进行吞吐量基准比较。
但 FCoP 面对的第一目标并不是高并发，而是：
怎样用最低复杂度，让单机里的多个 Agent 拥有一个脱离模型上下文的共同工作世界？
文件在这个问题上有几个特殊优势。
第一，Agent 天然会读写文件。
第二，人也能直接阅读。
第三，IDE、脚本、Git、备份工具都能直接处理文件。
因此同一个工作对象可以同时服务于：
Agent
人
IDE
脚本
Git
审计程序
这使文件成为一个非常低摩擦的共同表面。
FCoP 并不是在证明：
“文件比数据库先进。”
它真正利用的是：
在单机 Agent 场景里，文件是行为外化成本最低、可观察性最高的公共界面之一。
四、Filesystem as Behavioral Externalization Surface
过去常用一句话描述 FCoP：
Filename as Protocol.
这仍然有意义。
但如果继续往底层追，FCoP 更核心的思想其实是：
Filesystem as Behavioral Externalization Surface.
也就是：
文件系统是 Agent 正式工作行为的外化界面。
以下路径省略了共同前缀 fcop/_lifecycle/，用于说明状态；它们不是手动搬动文件的操作教程。
例如：
inbox/TASK-001.md
经过合法领取以后进入：
active/TASK-001.md
这不是简单的文件整理。
它表达一个正式状态变化：
TASK-001 已经从待领取进入执行状态。
提交以后进入：
review/TASK-001.md
又表达：
执行者已经形成正式交付，现在等待审查。
目录不是装饰。
文件也不只是数据容器。
它们共同构成 Agent 工作行为在操作系统中的持续投影。
五、单机并不意味着“没有并行”
FCoP 的单机设计经常会引出一个问题：
Windows 或普通文件系统又不是高并发任务平台，多 Agent 怎么并行？
答案不是让多个 Agent 同时竞争修改一个共享文件。
而是：
让多个独立工作串并行。
例如：
TASK-001 → DEV-01
TASK-002 → DEV-02
TASK-003 → QA
TASK-004 → OPS
这些工作可以同时进行。
这是：
工作级并行。
但对于同一个正式对象：
TASK-001
FCoP 并不追求：
DEV-01 ─┐
DEV-02 ─┼→ 同时修改同一权威状态
PM ─┤
QA ─┘
更合理的模式是：
一个正式对象
↓
明确工作归属
↓
经过校验的状态迁移
因此：
FCoP 支持多任务并行，但不以同一治理对象的多写者高并发为设计目标。
六、一致性比 TPS 更重要
数据库和消息系统经常问：
每秒能处理多少请求？
数字员工面对的关键问题往往不同：
任务有没有重复领取？
REPORT 是谁提交的？
失败之后有没有被误写成成功？
系统重启以后还能不能恢复？
当前状态为什么是合法的？
谁审查过这项交付？
这些问题的核心不是吞吐量，而是：
工作事实是否稳定。
因此 FCoP 的设计优先级更接近：
一致性
>
可恢复性
>
可检查性
>
可审计性
>
吞吐量
这不是说性能不重要。
而是明确：
FCoP 优化的不是数据中心级高并发，而是单机多 Agent 正式工作的稳定性。
七、状态落到路径，正确提交还需要原子恢复
例如：
inbox/TASK-001.md
↓
active/TASK-001.md
FCoP 使用操作系统文件语义，并不是为了构建一个高速消息队列。
它要获得的是一个非常简单但强的性质：
成功提交后，同一个工作对象应具有唯一可检查的正式生命周期位置。
4.0 不承诺跨目录迁移永远没有中间状态。参考实现还使用持久操作回执、摘要校验和恢复分类。若同一个 TASK 同时出现在多个权威阶段，读取必须拒绝歧义，不能按修改时间猜测。单次 rename 不能替代这套协议提交与恢复条件（规范 §9）。
这能让人和 Agent 直接检查：
它现在在哪里？
而不必先向一个隐藏状态服务发起复杂查询。
对于单机工作系统，这是一种非常实用的取舍。
八、FCoP 不应该承担联网
当 FCoP 被理解为“单机 Agent 行为外化”，另一个边界也自然清楚了。
它没有必要继续扩张去承担：
Agent discovery
OAuth
mTLS
跨机器路由
streaming
webhook
remote task
跨云互操作
这些问题属于网络互操作层。
A2A 更适合处理：
Agent System A
↕
A2A
↕
Agent System B
FCoP 则处理：
一个 Agent 系统内部
Agent 行为
↓
正式工作对象
因此：
在本文提出的组合方式中，FCoP 保存本地工作事实，A2A 承担跨 Agent 系统交互。
这是一种架构分工，不是已交付集成声明。A2A 本身也定义任务与产物语义；认证和通信策略仍需由实现者部署。第五篇具体讨论两者的映射边界。
九、FCoP 也不等于 Runtime
把行为写入文件还不等于数字员工已经可靠运行。
真正的 Runtime 还需要解决：
Session
Attempt
Lease
Timer
Retry
Recovery
Host
Model
Tool execution
Crash recovery
这些是 CodeFlowMu 一类 Runtime 要处理的运行问题。这里的 Runtime attempt 与 FCoP 4.0 用来绑定交付证据的 attempt_id 是不同层次的身份，不应混用；协议文件提交的崩溃恢复仍属于 C8。
CodeFlowMu 的具体已实现功能和兼容版本以 CodeflowMu-Distribution 发布说明为准。
所以可以分开理解：
Agent
↓
FCoP
工作行为外化
CodeFlowMu Runtime
↓
持续执行与恢复
FCoP 不应该因为 Runtime 很重要，就把 Runtime 全部吸收到自己里面。
十、文件是载体，行为外化才是核心
如果未来 FCoP 出现：
SQLite adapter
Object-store adapter
Database-backed implementation
它是否还可以被视为 FCoP？
这是一种未来的抽象方向，不是 4.0 已提供的存储适配能力。当前 Base 明确限定受支持、具有可靠本地语义的 NTFS/POSIX 文件系统。
将来讨论新的兼容编码时，判断不应只看 .md。
更重要的是它是否仍然保留：
TASK 是正式委派
REPORT 是正式交付
ISSUE 是正式问题
REVIEW 是正式审查
状态迁移有明确含义
工作事实不依赖模型记忆存在
所以：
文件系统是 FCoP 今天的 reference carrier。
而：
Agent 工作行为外化，是更底层的设计原则。
但设计原则本身不足以授予 4.0 兼容性。其他存储需要明确编码、C1–C8 全部契约和相应符合性证据；仅保存四类对象还不够。
十一、单机不是落后，而是边界清楚
云原生时代很容易形成一种误解：
只有分布式才先进。
但一个软件开发数字员工一天可能只处理：
- 几个正式开发任务；
- 若干审查；
- 一轮测试；
- 几次故障恢复；
- 几份正式交付。
它真正需要的不是每秒十万次状态变更。
更重要的是：
明天重新打开系统以后，它还知不知道昨天做到哪里？
另一个 Agent 接手以后，能不能看懂之前发生了什么？
系统能不能区分“执行者说完成”和“真正被接受”？
出错以后，能不能根据外部事实恢复，而不是依赖模型回忆？
在这样的负载下：
低并发、强状态、强可观察、强恢复
可以是一种非常合理的工程选择。
结语：即使模型离开了，工作依然在那里
FCoP 表面上看，是用文件组织多个 Agent。
继续往下推，它真正面对的是一个更基础的问题：
当 Agent 不拥有自己的操作系统、没有天然持久的工作事实时，工作怎样才能持续存在？
FCoP 的回答很朴素：
借用单机操作系统最成熟的持久化界面，把 Agent 的正式工作行为外化出来。
它接受自己的边界：
单机优先
受控并行
不承担联网
不承担完整 Runtime
不追求数据库级吞吐
换来的则是：
可见
可读
可恢复
可追踪
可审查
可持续
因此，FCoP 不应该只被描述成“文件通信协议”。
更准确的理解是：
FCoP 是面向单机多 Agent 系统的工作行为外化机制：它把任务、交付、问题和审查从易失的模型上下文转化为持久、可检查的工作对象。
数字员工真正成熟的标志，也许并不是模型能够完成越来越复杂的任务。
而是：
即使模型离开了，工作依然在那里。
实现与延伸阅读
正文与仓库版本保持同步 · 查看 Markdown 源文件 ↗