OrgForge 场景实战：用合成企业数据集科学评估 AI Agent 的 RAG 检索能力
场景：当”企业级 AI Agent”没有企业数据可测
最近做了一轮 AI Agent 的 RAG 检索评测，很快就被一个问题卡住了——手上没有合适的企业数据集。公开可用的企业语料库——最著名的莫过于 25 年前的 Enron 邮件集——要么太老，要么涉及法律合规问题，要么只覆盖单一场景。而在评测一个「能理解企业知识」的 Agent 时，你真正需要的是一个包含 Confluence、JIRA、Slack、Git PR、Zoom 会议、Zendesk、Salesforce 甚至 Datadog 指标的完整企业生态系统。
这就是 OrgForge 要解决的问题。
OrgForge 是一个开源的确定性企业模拟器（15 GitHub Stars, MIT 协议），能生成完整的合成企业数据集——包含 10 多种企业软件产出的各类文档、工单、对话记录——并且所有内容都受一个事件驱动状态机约束，LLM 无法幻觉出时间线上不存在的事实。
OrgForge 的核心设计：状态机而非 LLM 包装器
OrgForge 与市面上那些”让 LLM 生成一堆文档”的工具最大的区别，在于它的确定性事件总线（SimEvent Bus）。
我们来看看它怎么工作。每一次有意义的事件——开了一个 P1 工单、合并了一个 PR、一个工程师离职——都会发出一个 SimEvent：
SimEvent(
type="incident_opened",
day=8,
date="2026-03-10",
actors=["Jax", "Sarah"],
artifact_ids={"jira": "IT-108"},
facts={
"title": "TitanDB: latency spike",
"root_cause": "connection pool exhaustion under load",
"involves_gap": True
},
summary="P1 incident IT-108: connection pool exhaustion",
tags=["incident", "P1"]
)
然后，每一个下游产物（Confluence 页面、Slack 消息、Datadog 指标）都必须从这个事件日志中读取事实，而不是让 LLM 凭空创造。这意味着：
- 当 Slack 频道里 PagerDuty 机器人说”TitanDB 连接池耗尽”时，JIRA 工单、事后复盘文档、客户账单里的 SLA 信用额度都能追溯到同一个根源
- 当某位工程师离职时，工单自动分配、知识缺口传播、社交网络压力的再计算都会被依次触发
这种设计让生成的数据集对 RAG 评测尤其有价值——你手里有 ground truth（”什么事件在什么时候发生、涉及谁、状态是什么”），所以你可以精确测量 Agent 的检索系统是否真的找到了正确的上下文，而不仅仅是”听起来合理”的上下文。
生成的产物清单
一次默认的 22 天模拟产生以下输出：
| 产物类型 | 覆盖内容 |
|---|---|
confluence/ | 种子文档、事后复盘、即兴 Wiki 页面 |
jira/ | Sprint 工单、P1 事故工单（含关联 PR） |
slack/channels/ | 站会记录、事故告警、工程讨论 |
git/prs/ | PR 含审查人、合并状态、关联工单 |
zoom/ | 会议录文稿——捕获未文档化的口头决策 |
salesforce/ | CRM 账户和商机（含风险标记） |
zendesk/ | 客户支持工单（系统宕机时自动升级） |
emails/ | 客户投诉、供应商消息、HR 沟通、销售更新 |
datadog/ | 时间序列系统指标（metrics.jsonl）和告警载荷 |
nps/ | 客户满意度调查（根据 SLA 违规得分） |
invoices/ | 含 SLA 信用额度的月度发票 |
simulation_snapshot.json | 完整状态快照 |
simulation.log | 完整日志 |
每个产物都精确反映组织在该时刻的状态——没有时间错乱，没有幻觉。
离职级联：OrgForge 最复杂的行为
这也是 OrgForge 最值得一提的设计——离职级联（Departure Cascade）。当一名工程师在模拟中途离开团队时，以下流程会按顺序触发：
- 事故交接——活跃的 P1 工单通过 Dijkstra 路由重新分配
- 工单和 CRM 重分配——孤儿工单转给部门主管
- 社交图重算——中介中心性（betweenness centrality）在缩小的社交图上重新计算
- 知识缺口传播——如果离职工程师拥有未文档化的知识领域，这些缺口会被记录到 SimEvent 中，在后续事故中作为贡献因素出现
employee_departed事件——发出完整的状态快照
这意味着如果 Jordan 在第 12 天离开团队，那么第 9 天的事故复盘不会提到她，但第 15 天的复盘可能会写：”auth-service 的知识缺口——源于最近的离职——导致了诊断延迟。” 这句话扎根于真实的 SimEvent，而非 LLM 的推断。
快速上手
部署方式灵活，支持 Docker、本地 Ollama、云端 Bedrock 三种模式。
Docker 一键启动（推荐）
git clone https://github.com/aeriesec/orgforge cd orgforge docker compose up
首次运行会自动拉取模型（约 5-8 分钟），后续启动秒级完成。模拟结束后运行：
python email_gen.py python post_sim_artifacts.py
输出在 ./export/ 目录下。
云端预设（最佳输出质量）
在 config.yaml 中设置 quality_preset: "cloud"，并在 .env 中配置 AWS Bedrock 和 OpenAI 凭据：
AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_DEFAULT_REGION=us-east-1 OPENAI_API_KEY=...
pip install boto3 langchain-aws openai docker compose up mongodb orgforge
这套方案用 Claude Sonnet 生成文档、Llama 3.1 8B 处理高频调用、OpenAI text-embedding-3-large 做嵌入，只需 t3.small 级别的实例。
本地 GPU 模式
如果你有 48GB+ VRAM（如 A100 或 2× A10G），可用 quality_preset: "local_gpu" 配合 Llama 3.3 70B 全部在本地运行。
可选模块：内部威胁模拟
OrgForge 还内置了一个可选的内部威胁模拟模块——它可以在正常的企业模拟之上叠加对抗性行为（如异常 git 活动、非工作时间访问、Slack 情绪漂移、数据 staging）：
- 威胁遥测写到独立的
security_telemetry/目录（JSONL / CEF / ECS / LEEF 格式） - ground truth 始终作为 JSONL 保留
- 默认关闭时完全无害——无性能开销、无附加输出
这个模块的设计目标是一套检测系统需要的”干净”训练数据——你既知道谁做了坏事、做了什么，又能让检测 Agent 自己去发现。
配置亮点
OrgForge 的所有配置集中在 config/config.yaml——无需修改 Python 代码即可完成大部分定制。关键的配置项包括：
company_name— 注入所有生成文本的公司名simulation_days— 模拟时长（默认 22 天）legacy_system— 事故、工单、文档中引用的不稳定系统crm— 启用/禁用 Salesforce 和 Zendesk 集成org_lifecycle— 动态离职和入职计划morale— 衰减率、恢复率、干预阈值personas— 每位员工的写作风格、压力水平和专业领域
适合谁用
- AI Agent 评测团队：如果你在做 RAG 检索系统的 Benchmark，需要一份有 ground truth 的多源企业数据集
- 企业知识管理产品团队：想测试你的 Confluence/JIRA 集成是否准确，但不想在真实生产数据上做实验
- 安全研究团队：内部威胁检测系统需要一个覆盖了正常活动与异常行为的受控环境进行训练和评估
- AI Agent 框架开发者：需要一个多维度、跨系统的测试场景来验证 Agent 的上下文理解能力
总结
OrgForge 解决了一个真实且普遍的痛点——”企业数据评测的匮乏”。它将 LLM 的生成能力与确定性的状态机结合起来，既保证了数据的丰富性和多样性，又保留了 ground truth 对评测的可验证性。对于任何在做企业级 AI Agent 检索和推理评测的团队来说，这比 25 年前的 Enron 邮件集或者随意拼接的市场调研数据都更有参考价值。
如果你正在被”评测数据从哪来”这个问题困扰，不妨试试用 OrgForge 生成一个属于你自己的企业沙箱。
链接: github.com/aeriesec/orgforge 许可证: MIT 论文: arxiv.org/abs/2603.14997 数据集: huggingface.co/datasets/aeriesec/orgforge