Agent 即文件管理者

在 AIDC 中，Agent 的价值不是回答孤立问题，而是维护它负责的上下文、结构和输出质量。每个 Agent 都是某些文件或目录的管理者——这是把 Agent 从聊天窗口变成组织资产的关键设定。

// 核心命题

如果公司是一台计算机，文件系统是内存，那么 Agent 就是围绕文件工作的进程。一个没有负责目录的 Agent，就像一个没有内存空间的进程——它可以运行，但不会在组织中留下任何可累积的状态。

从"回答问题"到"维护上下文"

大多数组织对 Agent 的默认想象是聊天助手：人提问，AI 回答，对话结束，一切归零。这种模式下，Agent 每次都从空白上下文开始，产出散落在聊天记录里，质量无法验收，经验无法沉淀。无论模型多强，组织获得的只是一次性的回答，而不是持续累积的能力。

AIDC 的设定相反：Agent 被定义为特定文件和目录的管理者(File Manager)。它的日常工作不是等待提问，而是：

这个转变让 Agent 的工作变得可验收：检查它负责的目录，就是检查它的工作质量。Agent 与 Company Harness 因此互为前提——Harness 提供可授权的文件结构，Agent 让这个结构保持鲜活。

四条规则

AIDC 用四条规则约束每一个进入组织的 Agent。它们来自 AIDC 自己的 Agent Registry 实践，适用于从单目录小 Agent 到 C-suite 级 Agent 的所有粒度：

必有负责目录Owned Directory

每个 Agent 必须有明确负责的目录。没有负责目录的 Agent 不允许进入组织——职责必须落到文件系统上，才能被授权、被验收、被移交。

声明读写边界Read / Write Scope

每个 Agent 必须说明可以读取和修改哪些文件。读边界决定它能看到的上下文，写边界决定它能改变的状态，二者通常不对称：读宽于写。未声明的路径默认不可访问，详见 权限模型。

留决策记录Decision Record

Agent 修改战略或定位类文档时，应留下决策记录或变更说明：改了什么、为什么改、基于什么输入。这是 Action Log 在文件层的雏形——没有记录的修改，等于不可审计的修改。

产出可被人继续使用Human-Continuable Output

Agent 产出的内容应能被人类员工继续使用：格式清晰、来源可查、不依赖与该 Agent 的对话历史。人和 Agent 在同一个文件系统上接力工作，任何一方都可以接管另一方的产出。

// 治理规则

四条规则是准入条件，不是优化建议。一个不满足全部四条的 Agent，无论能力多强，都不应获得组织目录的写权限。

聊天助手 vs 文件管理者

两种 Agent 范式的差异，体现在组织最关心的每一个维度上：

维度聊天助手文件管理者
职责回答当前提问维护负责目录的上下文、结构和输出质量
上下文每次对话从零开始，或一次性全库检索长期维护负责目录，上下文随工作持续累积
权限无边界，或"看到所有内容"声明式读写边界，按目录授权
产出去向留在聊天记录里，随对话流失写回文件系统，成为组织资产
可审计性无法回答"改了什么、为什么改"修改伴随决策记录，可追溯、可复盘
可验收性只能逐条评价回答好坏检查目录状态即可验收工作质量
可移交性依赖对话历史，不可移交人或另一个 Agent 可随时接管目录
失败影响影响不明，错误回答可能扩散限制在负责目录内，边界即爆炸半径

Agent 定义模板

每个 Agent 由一份结构化的定义文件描述，放在它负责的目录下(通常命名为 AGENT.md)。AIDC 的通用模板包含六个区块：Identity、Scope、Responsibilities、Operating Rules、Output Formats、Review Cadence。下面是一个基于真实模板的完整示例(示例场景，角色取自 AIDC Agent Registry 中的 Input Curator):

# AGENT.md — 02_information/inputs/

## Identity

- Name: Input Curator
- Purpose: 保存、标注、初步归类进入公司的外部输入。
- Owner: Human Research Owner
- Status: launch

## Scope

- Can read: 02_information/, 01_executive/strategy/
- Can write: 02_information/inputs/
- Should not access: 03_finance/, 未授权客户数据、员工个人隐私

## Responsibilities

- 为每条外部输入建立来源、日期、可信度标注。
- 按主题归类输入，维护目录结构清晰。
- 标记与现行战略假设冲突的信息，提请人工复核。

## Operating Rules

- 所有外部信息必须保留来源。
- 必须区分一手材料、二手材料和推断。
- 不直接修改战略文档，只提供输入与归类。

## Output Formats

- Input Brief(单条输入摘要)
- Source Map(来源地图)

## Review Cadence

- Weekly: 新输入摘要
- Monthly: 归类结构复盘

模板的六个区块各自回答一个治理问题：

区块回答的问题
Identity这个 Agent 是谁，为什么存在，谁对它负责
Scope它能读什么、写什么、明确不能碰什么
Responsibilities它对负责目录承担哪些持续性义务
Operating Rules它工作时必须遵守的硬约束
Output Formats它的产出长什么样，下游如何使用
Review Cadence人类按什么节奏验收它的工作

公司级 Agent 同样遵循这个模板：AIDC 的首发 10 个 C-suite Agent，每一个都对应一个根目录与一份这样的定义文件，详见 C-suite Agents 与 C-suite 文件系统。

架构后果

"Agent 即文件管理者"看起来只是一条管理约定，但它会自然推导出 AIDC 的整个分布式架构：

  1. 有边界的 Agent 自然聚合成节点。当每个 Agent 都绑定目录与读写边界，把一组相关目录和 Agent 打包为一个自治单元就是顺理成章的下一步——这就是 Service Node 与 Agent Cell:Agent 在节点内自治工作，节点对外只暴露声明的接口。
  2. 协作通过结构发生，而不是通过对话。Agent 之间不靠互相聊天协作，而是通过文件、Action Log、Ontology link 和事件：上游写入文件，下游读取文件;状态变更走 Action Type，留下完整审计链。
  3. 不需要中央超级 Agent。当每个目录都有负责的 Agent、每个修改都有记录，组织就不再需要一个"什么都知道、什么都能改"的中央大脑——后者恰恰是上下文过载、权限失控和单点故障的来源。这个推论展开为 去中心化 Agent 组织 与完整的 分布式 Agent 架构。
// 一句话总结

先把 Agent 定义为文件管理者，组织才能安全地授权它;先有可授权的 Agent，才有可去中心化的 Agent 组织。

相关阅读