历史模块与遗留代码

平台经历过多次架构演进。理解哪些代码是"当前路径"、哪些是"历史包袱"，能避免读错代码。

当前主链路

chat-execute → demand-translation → agent-matching
            → workflow → task → agent-gateway / a2a
            → reporter → verification
            → fulfillment → escrow → state

这些模块是生产在用、有测试覆盖的路径。

已废弃 / 遗留

位置	内容	状态
`agent/schemas/agent.schema.ts`	`agents` 集合	⚠️ 当前无使用
`agent/schemas/agent-template.schema.ts`	`agent_templates` 集合	⚠️ 当前无使用
`agent/interfaces/agent.interface.ts`	13 种 `AgentType` 枚举	⚠️ 已迁移到 Skill Catalog
`agent/implementations/*.agent.ts`	3 个桩实现	⚠️ 废弃
`agent/agent.factory.ts`	硬编码 Agent 工厂	⚠️ 废弃
`agent/consumers/agent-training.consumer.ts`	训练队列消费者	⚠️ 无真实训练逻辑

为什么保留：删除会影响历史数据引用与部分旧测试；新代码不应再依赖它们。

早期产品路线的痕迹

平台最初的方向是"构建内部 Agent"，后来转为"能力市场 + 编排"。以下概念属于旧路线：

旧概念	新概念
`AgentType` 枚举	`skillIds` + Skill Catalog
平台内运行 Agent	外部 Agent + A2A
单 Agent 执行	DAG 多 Agent 编排
平台自建全部能力	平台只保留需求翻译与结果综合

通用后台脚手架

libs/modules/src 中有大量来自通用管理后台的模块：

system/*（用户、角色、菜单、部门、字典、公告、配置）
monitor/*（任务、日志、在线、服务器）
blog、tag、collection、market
assistant、magicbox、plugin、midjourney、replicate
identity、kyc、contract、activity、inviteuser

它们可以支撑一个完整平台，但与合规主链路的耦合度较低。阅读代码时建议先看主链路，再按需进入这些模块。

如何判断代码是否在用

bash

# 查找模块被谁导入
rg "from '@app/modules/<module>" apps libs

# 查找控制器是否被注册
rg "<Module>" apps/hushwork/src/app-client.module.ts

# 查找测试
find . -path "*<module>*" -name "*.spec.ts"

apps/hushwork/src/app-client.module.ts 是根模块，所有启用的业务模块都应在其中。

已知技术债

债务	影响	方向
Task 在 MySQL、Workflow 在 Mongo	双库状态同步	迁移 Task 到 Mongo
JWT 密钥硬编码	安全风险	改为环境变量
部分模块缺少测试	回归风险	按主链路优先级补齐
API 文档中大量 `uncategorized`	可读性差	补 `@ApiTags`
事件日志无归档	存储增长	设计归档策略
无统一租户隔离	越权风险	新接口显式校验

历史模块与遗留代码 ​

当前主链路 ​

已废弃 / 遗留 ​

早期产品路线的痕迹 ​

通用后台脚手架 ​

如何判断代码是否在用 ​

已知技术债 ​

相关页面 ​