Agent 多了以后，目录不维护就会变成新的混乱源
Agent 工作流目录治理，是团队定期维护 Axon Agents 和 Workflows 清单的做法：每个条目要有 owner、运行状态、Schedule、输入来源、产物位置、依赖关系和最近复查。它解决的痛点很现实：早期每个人都知道哪个 Agent 做什么；三个月后，名字相似的流程越来越多，旧产物没人敢删，定时任务不知道还在不在用，新同事只好重复造一个。自动化本该减少低效，目录失控却把低效换成了查找和猜测。
OWASP Top 10 for Large Language Model Applications 提醒团队关注权限、供应链、敏感信息和不安全输出等风险；NIST AI Risk Management Framework 也强调治理需要可管理的系统记录。Axon 的运营观点是：Agent 和 Workflow 的目录不是展示柜，而是团队的工作地图。地图不更新，自动化越多，迷路越快。
这篇文章连接 Agent 产物保留规则、Agent 下游依赖检查、定时 Agent 冲突控制 和 workspace artifact continuation。目录治理的重点不是把所有 Agent 写得漂亮，而是让团队知道哪些还在服务真实工作。
目录条目应该像维护记录，不像产品卡片
很多目录失败，是因为它被写成对外展示页：名字、描述、标签、创建者。看起来整齐，但不能回答运营问题。
真正有用的条目至少应该能回答：
- 谁对这个 Agent 的用途和结果负责？
- 它现在是 active、paused、testing 还是 retired？
- 它是否有 Schedule，运行时间是否和其他 Agent 冲突？
- 它读取哪些来源，输出到哪个 workspace artifact？
- 它被哪些下游 Workflows 依赖？
- 上一次复查是什么时候，结果是什么？
目录不是让团队证明“我们有很多自动化”，而是帮助团队决定“这个自动化现在该不该继续存在”。
这就是 Agent 工作流目录治理和普通资产清单的区别。
一个实用目录条目
name: weekly account summary
owner: customer success lead
status: active
schedule: workdays 08:30
source_boundary: workspace/sources/accounts/weekly/
artifact_path: workspace/artifacts/account-summary/current.md
downstream_use: Monday pipeline review, manager digest
trust_mode: confirm before external send
last_review: 2026-06-29 output drift review passed
next_review: 2026-07-13
retire_if: downstream review no longer uses artifact for 30 days
这不是为了让目录字段完美，而是让任何接手的人能判断：这个 Agent 是否还在跑、结果在哪里、谁负责、什么时候该检查。
目录变脏的四个信号
Agent 工作流目录治理最重要的不是一次整理，而是识别脏目录。
| 信号 | 说明 | 处理方式 |
|---|---|---|
| 同名或近似名很多 | 团队重复造流程 | 合并用途，保留 accepted artifact |
| 状态长期不变 | paused 或 testing 没人复查 | 要么恢复，要么退役 |
| Schedule 信息缺失 | 不知道是否仍定时运行 | 核对运行状态和冲突 |
| artifact 路径失效 | 产物移动或被替换 | 更新路径或记录保留规则 |
这些问题不一定立刻造成错误，但会让团队每次使用前都多花几分钟确认。长期看，它们会降低对 Agents 的信任。
清理时先处理风险，不要先改命名
目录维护很容易变成命名工程。团队花半天统一标题，却没有解决旧 Schedule 仍在跑、旧 artifact 被下游引用、权限边界不清的问题。
Step 1: 先找 active 但没有 owner 的条目。
Step 2: 再找有 Schedule 但没有最近复查的条目。
Step 3: 然后处理 artifact 路径失效和下游依赖不明。
Step 4: 最后再统一命名、标签和描述。
这样的顺序更适合 Axon，因为 Agent 的价值来自可执行 workflow，而不是目录字段本身。
目录应该支持下线
一个健康目录不只告诉你什么在用，也告诉你什么可以下线。很多团队害怕删除旧 Agent，因为不确定还有没有人依赖。结果是目录越来越长，真正有用的流程反而被埋住。
下线前可以问三个问题：
- 最近 30 天是否有人打开或接受过它的 artifact？
- 是否有下游 Workflow、会议或报告仍引用它？
- 是否存在保留规则要求保留最后版本或运行证据？
如果答案都是否，目录应该把它标记为 retired，并指向最终 artifact 或替代 Agent。这样团队不会重复启动旧流程，也不会把下线误解成丢失知识。
FAQ
Q1：Agent 工作流目录治理需要专门系统吗？
早期不需要。一个 Markdown、表格或 workspace artifact 都可以。关键是字段能回答 owner、状态、Schedule、来源、产物、依赖和复查。
Q2：目录多久维护一次？
新团队可以每两周维护一次；稳定后跟随质量抽检或月度运营节奏。Schedule 频繁变化时应更快复查。
Q3：谁负责目录？
可以由运营或 Agent owner 维护，但每个条目必须有业务 owner。目录管理员不能替业务团队决定产物是否可接受。
Q4：目录和产物保留规则有什么关系？
目录告诉团队 artifact 在哪里、是否仍被依赖；保留规则决定它应该保留、替换、归档还是删除。
Q5：目录是否应该包含失败运行？
不需要包含所有失败细节，但应指向重要失败、漂移、权限变更或下线交接记录，方便后续复查。
下一步
开始使用 Axon 管理多个 Agents 时，先建立一个轻量目录，并用 Agent 工作流目录治理检查四类条目：无 owner、无复查、有 Schedule 但状态不明、artifact 路径失效。了解更多时，不要问团队创建了多少 Agent，先问哪些 Agent 仍然被真实工作依赖。