1. Citadel Securities：如何构建持续更新的世界模型

[!abstract] 速览
Citadel Securities 的 João Wenzel 在 AI Engineer 演讲中分享了构建组织世界模型的实践方法。
该系统整合项目汇报、Slack、会议记录、代码变更和智能体会话，通过状态估计方法持续追踪组织真实状态。核心包括：

1. 借用机器人状态估计原理，根据证据时效性、来源可靠性和一致性修正判断；
2. 建立跨时间的纵向审计记录，追踪项目名称、范围、交付日期等变更；
3. 拆分为专门智能体工作流提升信息提取效率；
4. 通过历史快照回测验证风险预警准确性；
5. 设计反馈循环将人工纠正转化为可复用规则。

该模型帮助领导层聚焦汇报与证据不一致的关键问题，提升组织决策效率。

[!info] 演讲信息

• 演讲来源：AI Engineer
• 演讲者：João Wenzel，Citadel Securities
• 发布时间：2026-11-08 10:00，新加坡 · 狄奥尼索斯之歌
• 全文 5993 字（约 24 分钟）
• 查看原文 → · 查看该来源的更多文章

Citadel Securities 分享如何利用 AI 整合项目汇报、Slack、会议及代码记录，构建持续更新的企业世界模型。通过状态估计、历史追踪与结果回测，让 AI 识别组织的真实状态与潜在风险。

João Wenzel 在 Citadel Securities 参与构建组织记忆系统。在这场 AI Engineer 演讲中，他介绍了如何利用 AI 整合公司内部的项目汇报、Slack、会议记录、代码变更和智能体会话，建立一个能够持续更新的组织世界模型。

公司的真实状态往往分散在不同信息来源中。正式汇报可能掩盖项目风险，底层工作记录又充满噪声和过时信息。
Citadel Securities 借鉴机器人领域的状态估计方法，让智能体持续追踪项目变化、核验证据并修正判断。
演讲进一步展示了如何保留历史记录、利用后续结果回测风险预警，以及通过人工反馈不断改进系统，使分散的组织知识逐渐成为能够支持管理决策的共享上下文。

1.1. 主要内容

1.2. TL;DR：Citadel Securities 核心观点

1.3. 演讲精编

1.3.1. 公司里那个“什么都知道的人”

我想先请大家想一想，公司里是不是有这样一个人：他好像什么都知道，经历过十七次组织重组，知道所有八卦和内部政治，而且似乎总能预测重大战略调整最后会带来什么。

这个人，本质上就是公司的世界模型。问题是，他的能力无法规模化，也没有什么人真正把他说的东西写下来。

我是 Citadel Securities 的 João Wenzel。今天想介绍，我们怎样尝试用一个智能体系统，接近这种能力。

先简单介绍一下 Citadel Securities。我们的技术是自己做的，一直做到芯片层面。目前，超过三分之二的员工写代码。因此，我们自然非常投入人工智能，智能体也已经在组织内帮助我们完成很多事情。

接下来，领导层就开始问战略问题：这些智能体运行框架已经很擅长生成高质量代码，但它们能不能帮助定义和完善公司的战略？

1.3.2. 战略的三个问题，需要一层组织记忆

这是我从 Tim Urban 那里借来的一张很喜欢的图。战略归根结底涉及三个问题：我们现在在哪里？接下来会发生什么？我们又是怎样走到这里的？

要回答其中任何一个，智能体都必须对自己所在的公司有非常丰富的了解。因此，今天这个演讲，大体上是在讨论怎样构建一层组织记忆。

智能体需要了解关系。例如，两个团队过去一起工作，但重组后就不再交流；一个项目的历史，以及它为什么多次调整范围；还有内部政治：谁在场？他们说了什么？又没有说什么？

我们可以从两个方向进入：自上而下，以及自下而上。

[!warning] 西瓜项目
自上而下的材料整齐、干净，但有一个独特的人类因素：人们喜欢把自己的想法和意见融入其中，有时还是有意这样做的。
于是，就出现了我所说的“西瓜项目”：外面是绿色，里面是红色。

自下而上，则是那些噪声很大的资料。里面包含的信号可能多得出人意料，但很难挖出来。比如会议记录、Slack、代码变更，甚至你使用智能体运行框架时留下的会话记录。

模型就是上下两类信息相遇的地方，证据在这一层被综合起来。

1.3.3. 借用机器人的状态估计器

证据本身有时也有问题：它可能不完整，也可能是错的。机器人领域已经有一种处理这类问题的方法，叫作状态估计器。

你先对某个关心的事情持有一种判断。距离上次观察到支持它的证据，时间越久，你就越不信任这个判断，它也变得越来越模糊。

直到一份文稿、一段讨论或一份会议记录带来新证据，不确定性才收窄，你对当前状态更有把握，然后据此更新记录。

更新时，我关心三件事，智能体也应该关心这三件事：

这与自动驾驶有很多相通之处，后面我还会回来讨论。

1.3.4. 幻灯片的图像与 XML，要一起读

我们先从上层资料开始。一个简单例子，是业务运营人员每个月制作的项目状态汇报。

问题是，怎样从这一页幻灯片里提取数据？很多人应该都试过。这件事其实很容易误导人。

假设你试着解析文件，解包 PowerPoint，得到 XML，突然就会碰到一个有趣的概念问题：什么叫绿色？绿色的十六进制色码是什么？用这类脚本处理，事情就开始出问题。

于是，你可能说：“我直接截个图，交给视觉模型就好了。”

但即使图片分辨率很高，也可能有人先把截图复制进了演示文稿。结果就是 Claude 努力眯着眼睛，试图辨认那个数字到底是 31，还是 81。

所以，这场演讲的一个主题是：把不同信息综合起来，增加必要的信息，往往能得到简洁有效的方案。在这个很基础的例子里，把 XML 和视觉模型的输出结合起来，才能获得完整图景。

同时读取幻灯片画面和底层 XML

1.3.5. 单张快照不够，还要追踪同一个项目

这只是很基础的一步。真正的问题，是你需要建立跨时间的连续性，因为公司产生的这些资料一直在累积。

例如，一个项目在三月突然换了名字。当你构建这层关于公司组织记忆的共享上下文时，就需要建立可追溯的纵向审计记录。

更有意思的是，即使这一步做得很好，你仍然可能漏掉一半情况：你看的文稿是五天前的，而 Slack 里已经出现不同的信息。

有人在 Slack 说：“顺便说一句，我觉得这个项目还在按计划推进。”但另一个人回复了一张仪表盘图片，显示事情已经不是这样了。于是，原来的判断就开始站不住脚。

我们需要更好地整合这些东西。你的公司还没有一个关于自己的模型。

1.3.6. 更新、老化、观察、评分、纠正

我提出一个简单方案，把前面讨论的状态估计方法组织起来：更新、老化、观察，再加上评分和纠正。

在 Citadel Securities，我们构建的系统在这个循环的每个环节都有智能体参与。但关键是：模型提出变更建议，代码和人决定记录究竟怎样更新。

状态估计的五阶段循环与各阶段工作者

你可能会问：“为什么不直接用检索增强生成？应该就够了吧？”实际上，它并不够。

比如，我问：“这个项目现在是什么状态？还按计划推进吗？”截至三月十六日，一个模型可能很高兴地找到几条 Slack 消息和几张幻灯片，然后回答：“没问题，是绿色。”

但它漏掉了很多上下文。这还不够。

1.3.7. 更新记录：把汇报与证据分开，保留旧月份

我们怎样开始建立这个世界模型？第一步，是一致、稳健地更新信息。

还是以幻灯片和汇报为例，我们按月处理。到了新月份，就取上个月的记录和这个月的幻灯片，构建一条纵向记录。

我们已经这样做了三年，积累了相当大的历史记录库，现在可以据此构建一个稳健的组织或企业世界模型。

先从基本问题做起。有时，这些模型连最基础的事也会遇到困难，但这很正常。比如，一个项目突然改名了。但通过查看历史记录，模型可以根据参与者，以及目标上的连续性，推断它其实仍然是 Northstar 项目。

更有意思的是，你需要让智能体系统区分：“别人汇报了什么”，以及“实际证据支持什么”。

例如，某份项目汇报把状态标成绿色，但系统识别出它实际上应该标成黄色，因为有人在评论里说，仍有一项依赖没有解决。

最重要的是，不去改以前月份的记录。我们通过向前生效的方式纠正。这样，后面才能进行可靠的评测。

更新步骤写下的东西很简单：当时怎样汇报，证据指向哪里，以及为什么两者不同。

1.3.8. 每个事实都有时效，每项主张都要带日期

接下来加入第二部分：老化。

现实是，每个事实都有自己的半衰期。大家都见过这样的事：翻看旧幻灯片，发现一个项目的上线日期一直往后拖。一月说第二季度，后来变成第三季度，现在又变成十月。

把数据真正收集起来，就能开始得到一些有意思的分析结果。

例如，查看过去三年的交付日期，平均约一半会在两个月内改变，而这些变更中有90% 是推迟到最初提议日期之后。

这看起来很基础，但它会迫使你为具体主张关联一个日期。这样，当你询问某个项目、某个人，或者公司的意图时，智能体才能把信息的新旧程度纳入判断。

同一项目的历史名称、汇报状态、证据状态和日期

1.3.9. 观察：让专门的工作流保留细节

接下来是观察。我会很快带过，但给大家一个具体的工程经验。

刚开始，一个很有诱惑力的方法是：干脆把全部资料一次性交给 Claude 或其他模型，看看它能做出什么。

结果很明显，很多信息会丢失，模型会失去对细节的注意。

最后，我们构建了一个简单的智能体工作流：由一组专门的智能体拆解这些材料，寻找特定信息，再由其他智能体复核它们的发现，等等。

右边的结果显示，这样做之后，针对单个项目、有洞见的更新数量增加了一倍以上。

所以，要有意识地设计工作流，不要假定把全部东西一次丢给模型，就能得到好结果。

1.3.10. 评分：拿后来发生的事，检验当时的预警

现在到了我认为真正有意思的部分。一个世界模型应该能告诉你，接下来会发生什么：哪个项目快要延期？哪个绿色项目下个月可能变红？

我们其实可以评测这一点。回到某个过去日期，建立当时的快照，然后做回测。

比如，建立截至二月的快照，再看后来出现的状态标签，比较智能体当时说哪些会延期、哪些需要标记，与之后实际发生的情况。

我们发现，那些状态为绿色、但被智能体标记的项目，后来转为黄色或红色的可能性大约是其他项目的两倍。

这令人鼓舞。它不是在准确预测究竟哪里会出错，但至少应该能告诉你，哪里值得关注。

被标记与未标记绿色项目的后续状态变化

1.3.11. 纠正：问一个事实，还是问一条规则

你有这十八个被智能体标记、后来发生变化的案例，那些没有这种结果的情况怎么办？这就需要一些产品判断。

首先，怎样建立一个顺畅的循环，把真实用户、利益相关者和人纳入其中？你问他们什么？又在哪里与他们交互？

我花了相当多精力研究，怎样最好地收集这些信息。要到用户本来就在使用的地方：他们的应用、Slack、邮件，等等。

离用户越近，收集反馈越简单，这个过程就越容易扩展，也越稳健。

问什么也很重要。你是在问一个只能修正单条输出的事实，还是在问一条规则？一旦智能体理解了某种模式，就能更好地修复这条规则覆盖的所有输出，不仅是现在，也包括未来。

因此，现在我们的记录不仅保存智能体推断了什么，更重要的是，还记录哪些内容是在一个人真正提供信号之后得到确认的。

1.3.12. 自下而上：会议、Slack、代码和会话轨迹

再来看自下而上的材料。

我鼓励大家探索这些不同的数据来源，把它们结合起来建立模型。

Slack 相对简单：逐条查看讨论线程，根据附件、参与者和内容，理解需要记录或更新哪些主张。事情发生在什么时候？谁负责？涉及谁、哪个项目？证据链接在哪里？等等。

代码合并请求展示具体改了什么，是观察项目怎样演进的好方式。

但要理解项目如何运行和部署的细节，查看自愿参与的用户和工程师留下的实际会话轨迹，会非常有意思。你能看到需求怎样变化、哪些测试失败，以及开发者作了什么具体决定。

这些过程最终会形成一个合并请求，但把中间材料综合起来，我认为会带来很大不同。

1.3.13. 传感器坏了，不等于车速变成零

还有一个容易踩的坑：要仔细考虑来自不同“传感器”的信号是否有效。

[!warning] 传感器坏了，不等于车速变成零
假设你正在高速公路开车，速度表突然消失。这不代表你现在的速度是每小时零英里，只代表信号出了问题。

在自下而上的处理中，我们也遇到过类似问题。系统出现一种判断：“这个频道、这件事怎么安静下来了？”但实际情况是，我们把它当成了零，而它本来不该被当成零。

我们不断迭代，逐渐弄清楚应该怎样记录：上次尝试从这个传感器获取信息是什么时候？上次正常获取是什么时候？两者出现差距时，应该怎么办？

下面是官方页面摘出的演示字段：

{
  "slack": {
    "last_tried": "2026-03-16",
    "last_ok": "2026-02-20",
    "state": "unseen"
  }
}

现在，再看我们构建出的实际记录，智能体就更能理解真实状态。

它不再只是“绿色”，而是：“上线日期已经推迟两次；证据表明是黄色；大家正在讨论失败的测试；接下来可能会很棘手。”

1.3.14. 用在领导讨论、每周阅读和共享上下文

我们用它做什么？首先，引导领导层的讨论。

不再把一份文稿发给所有人，要求大家逐页浏览、最后又只是草草看过。我们从真正重要的地方开始，从汇报与证据不一致的地方开始。

我们也为经理和领导生成每周阅读材料，告诉他们哪些事情卡住了，哪些地方变得安静。

更重要的是，我们开始拥有一层所有智能体都可以依赖的上下文。

我们正在把这种模式设计成可以扩展到其他用途。例如，在客户业务中，我们也想用类似模型更好地服务客户：谁持有什么？他们关心什么？怎样综合各种分散的内部和外部信息，尽可能提前理解客户需求？

1.3.15. 两个难题：身份对齐，以及何时询问人

还有几件很难做的事情。

比如，一个客户在四个不同系统里有四条记录，又没有统一标识，怎样以简洁有效的方式把它们对应起来？这个问题，我认为我们还没有明确答案。

第二，怎样更有效地从利益相关者和用户那里获取信号？

当模型很有把握，而且事情风险较低时，就应该自动应用更新。风险低、但模型不确定时，就等更多证据。

如果风险很高，问谁、什么时候问，以及整个交互机制，就非常重要。

1.3.16. 从一开始，就把评测与人的反馈设计进去

再回到这个循环：更新、老化、观察、评分和纠正。

我希望大家带走三点。

[!tip] 三点建议

1. 把公司的模型看作一个状态估计器。 不要以为把一切建立索引、编目就够了。这些事情本来就非常细微，很多内在信息存在于字里行间，即使最先进的模型也很难捕捉。
2. 用接下来实际发生的事给它评分。 从一开始，就认真思考怎样把评测整合进系统。
3. 设计一种顺畅的方式，让模型、智能体和利益相关者能够很好地协作。

你的公司可以拥有关于自己的模型。如果现在还没有开始收集这些资料，我鼓励你从现在开始。

尤其是在大公司，如果你和我一样，幸运或者不幸地需要处理成千上万份文稿，就更应该认真考虑。我确实已经看到明显改善：这些智能体能够重建组织记忆，把它应用到各种日常任务中，而不再对事情的来龙去脉感到混乱。

原视频：

https://ai.engineer/nyc/2026/talks/citadel