指出 Agent 执行轨迹(Trace)仅证明操作发生,不代表任务合法完成Governance,需从权威、责任、交付物等维度重建工作状态,剖析 TMPA/FCoP/CodeFlowMu/Self-Morphing 架构演进。
一个 Agent 调用了工具、修改了文件,最后返回完成。
这证明了什么?
这只能证明一次执行发生了。
它不能自动证明任务已被合法完成、测试已被确认、交付出已通过审查、冲突已被解决,或者任何角色有权将任务推进到下一状态。
这正是长期运行的 Agent 系统最常忽视的架构边界:
Trace 不是 Governance。

图 1. Trace 记录事件。Governance 从持久的事实、规则、责任和授权中重建合法的工作状态。
Trace 可以回答:模型调用了哪个工具、何时发生操作、以及工具返回了什么。
真实工作需要另一组答案:
谁授权了这项任务?
谁正式接受了责任?
哪个产物代表了正式交付物?
测试结果能否被独立验证?
谁执行了审查?
当前生命周期状态是否合法?
是否存在未解决的冲突、缺失的证据或悬空的引用?
进程重启后谁继续?
添加更多日志行并不能解决这些问题。日志始终是系统事件。Governance 关注的是工作事实、责任和决策的法律效力。
因此,迈向数字员工的第一步不是给 Agent 更多工具,而是让工作事实独立于 Agent 会话。
TMPA(Textual Multi-Agent Process Architecture)是一种基于文本消息的异步多 Agent 流程架构,专为 SME 优先、最小基础设施环境设计。
它不是 Agent 调度器或中央运行时。TMPA 解决的是:当 Agent 和人类跨时间异步协作时,任务、责任、证据、冲突和审计状态如何变得有效。
其核心由四条关联规则组成:
文本携带持久消息和状态;每个写者维护自己的本地序列化流;多个序列化流异步推进形成并行协作;读者聚合可用证据以重建流程、责任、生命周期、冲突和审计状态。

图 2. 每个参与者追加自己的事实。跨流引用形成偏序。读者聚合证据而不覆盖冲突。
重要的一点不仅仅是"用文本代替数据库"。两个更深层的原则至关重要。
首先,责任需要一个明确的来源。PM、DEV、QA 和人类决策者保留自己的本地事实流,而不是重写另一个参与者的历史。
其次,状态不仅仅是字段的最后一个值。读者从 Task、Acceptance、Report、Review、Decision、Issue 和 Correction 等对象重新计算当前状态。
模型可能会变化,进程可能会重启,但已建立的工作事实不会随着会话消失。
理论和规范需要一种可执行的协调形式。
FCoP(File-based Coordination Protocol)是一种多 Agent 行为治理协议,以文件系统作为唯一的同步原语。
其项目可见的 Profile 可以概括如下:
目录即状态:inbox → active → review → done → archive。
文件名即路由:发送者、接收者、对象类型和序列号表达身份。
内容即负载:Markdown 和 frontmatter 携带任务、报告、引用和证据。
原子移动即同步:生命周期转换使用 os.rename()。

图 3. 生命周期变更移动一个项目可见的工作对象,而不是覆盖中央状态字段。人类、Agent、读者和操作工具检查相同的事实平面。
FCoP 不仅仅是"用文件发送消息"的方式。它使交接、报告、审查、决策、问题和恢复路径变得可观察、可引用和可审计。
其边界同样重要:FCoP 治理协作行为。它不提供模型推理、进程调度、身份认证或资源分配,也不是完整的 Agent 运行时。
如果 TMPA 定义了工作事实和治理语义,FCoP 提供了项目可见的文件驱动协调协议,那么 CodeFlowMu 解决的则是这些语义和协议如何进入真实的 Agent 运行时世界。
其工程起点不是一个巨大的中央 Agent。
推理保留在成熟的模型生态系统中。浏览器、API、CLI、MCP 和业务系统执行实际操作。CodeFlowMu 专注于角色编排、责任边界、Skill 路由、生命周期、FCoP 集成、报告、审查、恢复和人类决策。

图 4. 模型推理,工具行动。CodeFlowMu 组织工作,FCoP 承载事实,TMPA 指导治理语义。
因此,这三者不是三个相似的产品:
只有有了这些边界,系统才能避免将"Agent 返回完成"当作"组织接受了交付"。
CodeFlowMu 最重要的一点不仅仅是多个 Agent 可以一起开发软件。
更重要的是,这种开发能力本身可以成为下一代数字员工的生产能力。
我们称这种形式为 Meta-Development Runtime。
PM、DEV、QA、OPS 等角色不仅可以构建传统软件。他们可以将岗位职责、工作流程、Skill、权限、治理策略、验证规则、运行时配置、恢复规则和人类决策门禁组合成一个:
Digital Employee Package:将数字员工转化为工程产品。
一个岗位能力因此可以像软件一样被定义、开发、测试、版本管理、部署、升级和回滚。
Self-Morphing 不意味着允许正在运行的 Agent 任意重写自己,也不意味着 Agents 创建 Agents 的无限递归。
它描述的是一个严格隔离和可恢复的改进循环。生产工作发出证据。证据暴露能力差距。Meta-Development Runtime 设计改进并生成新的 Digital Employee Package。只有经过隔离验证和明确授权,该版本才能进入下一个工作周期。

图 5. 证据可以进入元开发,但元开发不能重写实时生产运行时。验证和授权控制部署,且回滚路径始终可用。
完整循环是:
Work → Evidence → Gap → Improvement → Isolated Validation → Human or Governance Authorization → Deployment → New Work Cycle
如果变更来源不可追溯、测试不可重现、部署未经授权、运行版本无法识别、或失败无法回滚,那么"自我进化"只是不可审计的自动重写。
SaaW 不会将人类从系统中移除。
低风险、可逆、符合策略的工作,如检索、组织、验证、报告和同步,可以越来越多地由数字员工执行。外部发布、不可逆修改、金钱、凭证、隐私和策略例外必须停在人类权威边界。
人类不再需要执行每一次点击和数据传输。他们的责任向以下方向转移:
定义目标 和授权边界;
处理冲突和异常;
审查有影响的证据;
批准、拒绝或要求返工;
对高影响结果承担最终责任。
在 SaaS 中,人类通常保留在软件操作层。在 SaaW 中,人类越来越多地进入治理和最终权威层。
SaaW(Software as an Agent Worker)是这一过渡的更高层次名称。软件不再是仅由人操作的能力集合,而是开始在明确的工作职责、授权边界和治理规则下持续承担工作。
它不是新的聊天窗口,也不是简单地添加一个 Agent 就能创建的。真正的数字工作主体需要角色、环境、Skill、权限、状态、治理、证据、恢复和人类权威边界。
经验证的能力必须与研究前沿保持分离。
目前可用的公共工程基础包括:TMPA V1.0 架构论文、核心规范和实现案例;FCoP 协议和实现;以及开放的 CodeFlowMu 工程运行时环境。实现案例固定了 CodeFlowMu v1.8.0,并记录了针对 TMPA S1.0 的 14/14 验证结果。
标准化的 Digital Employee Package、标准化的 Agent PC、领域 Work Runtime 和更广泛的 Self-Morphing 验证仍是研究和未来工程工作。
从 Agent 系统到数字员工的决定性变革,不是模型变得更像人,而是工作获得了独立于模型会话而存在的事实、责任、证据、恢复和权威结构。
TMPA 使工作事实有效。FCoP 使协调事实可见。CodeFlowMu 将它们带入真实执行。Meta-Development Runtime 然后将运行时证据转化为 Digital Employee Package,并通过受治理的 Self-Morphing 进行改进,最终指向 SaaW。
软件曾经是工具。后来它成了服务。现在,它开始工作了。
从软件市场到数字劳动力市场。
完整宣言:From SaaS to SaaW: When a Codebase Starts "Developing Itself"
TMPA V1.0 DOI: 10.5281/zenodo.21888488
FCoP: GitHub Repository
CodeFlowMu: Open Engineering Runtime
Version status: V1.0 · Published
Version status: V1.0 · Published
Research Center: Digital Employee Works
Research Center: Digital Employee Works