文件路径与目录布局

上一页讲了一名数字员工的目录里有什么，这一页讲它在磁盘上的位置：运行时的路径规则是什么、AIDC 把部门与数字员工放在哪里、同一台机器上多名数字员工彼此是什么关系、技能能不能互相使用。所有路径都以结构占位符给出，实际部署时按客户的命名规范填入。

// 一句话理解

运行时只有两个层级：一个根目录，下面若干个平级的数字员工目录。AIDC 把根目录当作部门域，把每个数字员工目录当作一名数字员工；「公司」这一层由中枢承担，不是机器上的目录。

运行时的路径规则

Harness 运行时通过一个状态目录来定位自己的全部状态：配置、会话库、记忆、技能、日志、定时任务、网关进程号，全部在这个目录之下。运行时内部所有路径都从它推导，因此把这个目录指向哪里，运行时就在哪里工作。

创建一名数字员工，就是在根目录下建一个子目录 profiles/<标识>/，启动时把状态目录指向它。同一份运行时代码于是看到另一套完整、独立的状态。根目录本身也具备状态目录的形态，但在 AIDC 的布局里它只承担容器职责：放 profiles/ 子目录、域内共享看板与共享技能。

东西	位置
根目录	`<根目录>/`，可挂在任意一块卷上
数字员工目录	`<根目录>/profiles/<标识>/`
某数字员工的技能	`<数字员工目录>/skills/`
域内共享看板	`<根目录>/kanban.db`
域内共享技能	`<根目录>/skills/`
引擎代码	与状态目录无关的机器级安装位置

运行时判断层级的规则很简单：状态目录的上一级叫 profiles，那么再上一级就是根目录。所以任何 <某处>/profiles/<标识>/ 都是合法的数字员工目录，根目录可以放在任意一块卷上。AIDC 正是利用这一条把每个部门放到独立卷。

AIDC 的布局：部门域与数字员工

AIDC 不改运行时的规则，只决定根目录放在哪、叫什么、谁拥有。规则是：一个部门一个根目录，根目录挂在该部门的卷上，部门里每一名数字员工是根目录下的一个子目录，且每名数字员工对应一个独立的操作系统用户。

组织单位	路径	示例（某部门的应付会计岗）
引擎（机器级）	`<引擎安装目录>/<版本>/`	由 AIDC 发行与升级，客户 IT 不改
部门域根目录	`<部门域卷>/<根目录>/`	`/opt/finance/harness/`
域内共享物	`<根目录>/kanban.db`、`<根目录>/skills/`	`/opt/finance/harness/skills/`
数字员工	`<根目录>/profiles/<岗位标识>/`	`/opt/finance/harness/profiles/finance-ap/`
数字员工的工作区（在 profile 外）	`<部门域卷>/workspaces/<岗位标识>/`	`/opt/finance/workspaces/finance-ap/`
部门共用工作区	`<部门域卷>/workspaces/shared/`	`/opt/finance/workspaces/shared/`
数字员工的 HOME（只放工具状态）	`<部门域卷>/homes/<岗位标识>/`	`/opt/finance/homes/finance-ap/`
系统服务	每名数字员工一个，以岗位标识命名	`finance-ap-gateway`

两条纪律跟着这张表：第一，根目录不当数字员工用，部门的第一名数字员工也要是 profiles/ 下的子目录；第二，工作区与 HOME 放在部门卷上、根目录之外，但不出这块卷：profile 是「人」，工作区是「岗位上的桌面」，运行时刻意把两者分开，桌面可以几个人共用；出了卷就无法按部门核算容量、也无法随卷整体搬迁。

根目录、数字员工与临时子代理

同一台机器上会出现三种「像 Agent 的东西」，它们的关系是平的，不是树：

根目录是容器，不是上级。它不调度数字员工，不替它们持有状态，它的配置也不会被数字员工继承。删掉根目录里的人格文件，不影响任何一名数字员工。
数字员工之间平级。它们并排存在，各自独立启动网关、独立登录渠道、独立记忆。一名数字员工不能读另一名的会话库，也不会继承另一名的配置。
临时子代理属于某一名数字员工。数字员工处理任务时可以派生子代理：同一个目录、同一份凭证，继承当时已加载的工具与技能，带独立的对话上下文跑完一件事，只把摘要交回，然后消失。它不落盘成目录，不是组织单位。详见委派与编队。

把这三样对应到组织语言，就是下面这张表。「公司」在运行时里没有对应物，这是刻意的分工：公司级的登记、策略与技能注册表由中枢承担，它不是任何一台机器上的目录。

运行时里的东西	AIDC 组织单位	说明
（无）	公司	由中枢承担：岗位登记、策略下发、技能注册表、用量与健康投影。Company Harness 是组织制度层面的概念，不是某个目录
根目录	部门域	一块卷、一份共享看板、一组共享技能；高敏部门独占机器
数字员工目录	数字员工	一个岗位一名，独立操作系统用户，独立网关
临时子代理	数字员工的临时分身	同一目录内，任务结束即消失，不是组织单位

技能能不能跨数字员工使用

默认不能，需要显式共享。运行时为每名数字员工解析技能目录时只看它自己的 skills/，根目录下的 skills/ 对数字员工是不可见的。这与「根目录不是上级」是同一件事的两面：既然没有上级，就没有自动继承。

运行时提供了四条让技能出现在多名数字员工里的路径，性质各不相同：

路径	机制	是复制还是共享	之后会不会联动
引擎内置技能	创建数字员工时从引擎自带目录播种；引擎升级时把新增的内置技能同步给所有数字员工	复制	只同步新增，用户改过的不覆盖；可让某名数字员工退出播种
建档时克隆	以另一名数字员工为模板创建时，把它的技能目录整个拷过来	复制	不联动，之后各改各的
外部技能目录	在数字员工的配置里列出额外要扫描的目录，例如指向根目录的 `skills/`	共享	实时联动；但只要目录可写，任何一名数字员工都能改动共享技能
项目内技能	工作区里受信任的仓库自带的技能目录	共享（随仓库）	随代码更新；每次进索引前过安全扫描，危险技能被隔离

同名技能的优先级固定为：项目内技能优先，其次数字员工自己的，最后外部目录。这意味着一个部门共享的技能可以被某名数字员工在自己目录里同名覆盖，而不影响其他人。

AIDC 在这四条之上定了两条用法：

企业级技能走中枢，不走目录共享。中枢维护注册表，按岗位授权把技能物化到每名数字员工自己的 skills/，发布一次全舰队下次唤醒收敛，收回同理。技能因此是「授权到人」的，而不是「放在某个共享目录里谁都能用」。详见 Skills。
部门内共享技能用外部目录，但目录必须只读。把根目录的 skills/ 登记为每名数字员工的外部技能目录，同时用操作系统权限让它对各数字员工只读。外部目录本身不是写保护边界，写保护要靠文件系统权限，这正是 AIDC 每名数字员工一个操作系统用户的用意之一。

// 治理规则

不要为了「让大家都能用」把技能放进根目录再让所有数字员工可写地挂上它。一名数字员工改坏一个共享技能，全部门下一次会话一起坏，而且审计上分不清是谁改的。共享目录只读，授权走中枢。

路径速查

运维时最常要找的几样东西，按「先找部门域，再找数字员工」的顺序：

要找什么	在哪
这台机器上有哪些部门域	每个域一个根目录，各挂在自己的卷上；一台机器可以有多个
某部门有哪些数字员工	`<根目录>/profiles/` 下的子目录，一个子目录一名
某数字员工的人格与规则	`<数字员工目录>/SOUL.md`、`<数字员工目录>/AGENTS.md`
它连了哪些渠道、用什么模型	`<数字员工目录>/config.yaml`；凭证在 `<数字员工目录>/.env`
它的会话与消息	`<数字员工目录>/state.db`
它产出的文件	`<部门域卷>/workspaces/<岗位标识>/`，即配置里 `terminal.cwd` 指向的目录
它的网关日志	`<数字员工目录>/logs/gateway.log`
它的定时任务	`<数字员工目录>/cron/`
它有哪些技能	`<数字员工目录>/skills/`，加上配置里登记的外部目录
它是不是在跑	`<数字员工目录>/gateway.pid`，或以岗位标识命名的系统服务的状态
部门共享看板	`<根目录>/kanban.db`
中枢登记的岗位、负责人、策略	不在机器上，在 AIDC Console