30 秒看懂
项目汇报可能显示进展正常,而对话和未解决的依赖却指向风险。Citadel Securities 的 Joao Wenzel 介绍了一套企业记忆系统:它汇集不同信号、保留历史,并接受人员纠正。在一次回测中,被系统标记的绿色项目转为黄色或红色的可能性约为其他绿色项目的两倍。Wenzel 认为,这有助于领导者判断该关注什么,但无法准确预测会出什么问题。
- 1绿色状态报告可能掩盖相反证据Wenzel 将自上而下的汇报与更嘈杂的会议、消息、代码变更和智能体记录结合起来。
- 2把企业知识看作随时间变化的估计证据越旧,可信度可能越低;来源是否可靠、其他信号是否一致也很重要。
- 3保留历史记录,避免改写过去系统记录报告内容、证据和判断,为后续回测提供基础。
- 4观察到的交付日期有一半在两个月内变化Wenzel 说,在三年的记录中,这些变化有 90% 是把日期推迟。
- 5专门智能体比一次性通读找到更多有用更新示例中,拆分资料并让智能体互相审查后,有洞察力的项目更新数量增加了一倍多。
- 6被标记的绿色项目转黄或转红的可能性约为两倍团队重放历史快照,将预警与之后的状态变化进行比较。
- 7数据源故障不等于项目安静团队跟踪上次检查和上次成功工作的时间,避免把缺失数据当成零活动。
要点建议
- 保留带日期的证据和历史快照,而不是覆盖过去记录,以便之后评估。
- 降低对过时信息的信任,并区分数据源不可用和确实没有活动。
- 将大规模审查拆给专门的智能体,并检查返回结果的覆盖情况。
- 用后续结果回测预警,向相关人员收集可复用的规则,而不只是单次纠正。
- 用代码和人员共同控制记录更新;风险越高,越需要人参与。
按章节阅读整理后的全文
为什么公司需要企业记忆
重要背景往往存在于人员经验和相互矛盾的记录中。Wenzel 将正式报告与实际工作证据结合起来。
多数公司都有这样一个人:记得重组、关系以及正式决策背后的政治。Wenzel 把这种人比作公司的世界模型:很有用,却难以规模化,而且知道的事情很少被完整记录。
Wenzel 说,在 Citadel Securities,智能体已经帮助员工完成各种工作。领导层接着提出,智能体能否帮助制定和完善公司战略;这需要了解公司的现状、历史和可能的下一步。
企业记忆需要记录关系与项目历史,比如团队为何停止合作、项目为何多次调整范围。Wenzel 对比了正式的汇报材料和战略文件,以及更嘈杂的会议记录、消息、代码变更和智能体会话。

正式报告可能包含他所说的“西瓜项目”:外面是绿色,里面却是红色。实际工作中的信息也包含有用信号,但噪声更多。企业模型的作用是汇合这两方面的证据。
根据逐渐过时的证据估计现状
模型跟踪来源质量、时效和信号一致性。文件结构解析与视觉识别可以互补。
Wenzel 借用了机器人领域的状态估计器概念。支持某个判断的证据越旧,判断就越不确定;新的观察会带来更新。他说,系统应考虑信号的时效、来源是否可信,以及其他来源是否支持同一结论。
即使提取状态幻灯片也不容易。解析 PowerPoint 的 XML 可能拿到数据,却不容易处理颜色等视觉概念;视觉模型也可能看不清复制进演示文稿的截图。结合结构化文件与视觉模型的读取结果,才能得到更完整的信息。
项目还会改名,因此记录必须能跨时间关联。五天前的汇报可能与后来的 Slack 讨论或仪表盘截图相矛盾;纵向审计记录可以追踪这些变化和分歧。
更新记录但不抹去历史
智能体提出修改,由代码和人决定如何更新。历史记录有助于识别改名项目和报告与证据不符的状态。

他提出的循环是更新、老化、观察、评估和纠正。评估把观察结果与预期比较,纠正则将相关人员的反馈送回系统。智能体参与各环节,但记录如何更新由代码和人决定。
检索系统可能找到几条消息和幻灯片,回答项目是绿色,却遗漏重要背景。Wenzel 的方法建立持续更新的记录,而不是只依赖一次查询检索到的文件。
每个月系统把上月记录与新的状态汇报结合起来。团队已有约三年记录,可以通过参与人员和目标的连续性,推断改名后的项目实际上是原来的项目。
智能体还会区分报告的状态与实际证据。汇报可能将项目标为绿色,但关于未解决依赖的评论可能支持黄色预警。更新记录会写明报告内容、证据、推断状态和原因。
系统不会改写前几个月的记录,而是把纠正用于后续更新,保留历史快照以供评估。这些历史也能显示不同事实变得过时的速度。
衡量事实时效与预警效果
专门智能体收集证据,历史快照则让团队检验被标记的绿色项目之后是否改变状态。
交付日期就是一个例子:原定第二季度上线,可能推迟到第三季度,再推迟到十月。Wenzel 说,三年的记录显示,一半日期在两个月内改变,变化中有 90% 是推迟。

给每个说法关联日期,能让智能体在回答项目、人员或公司意图相关问题时考虑信息的新旧。
团队最初尝试让一个模型一次检查全部资料。Wenzel 说,这会丢失细节。后来团队把材料分给专门智能体,增加智能体之间的审查,并统计返回结果;在这个例子中,有洞察力的项目更新增加了一倍多。

接下来的测试是:正式状态改变之前,模型能否识别问题?团队重建过去某一时刻的快照,只用当时可获得的信息运行分析,再将预警与后来出现的状态标签比较。

在这次回测中,状态为绿色但被智能体标记的项目,之后转黄或转红的可能性约为其他绿色项目的两倍。Wenzel 说,这不能准确预测具体会出什么问题,但能帮助人们判断该看哪里。
收集纠正和实际工作信号
相关人员的反馈可以形成可复用规则。消息、拉取请求和自愿提供的智能体记录可补充背景,但数据源也可能失效。
人工反馈是循环的另一部分。Wenzel 建议在相关人员已经使用的工具中收集反馈,例如 Slack 或邮件,并尽量简化回应。表达一条规则的纠正不仅能改善当前输出,也能改善未来输出。
记录可以区分智能体推断出的内容和经人确认的内容。这能在系统日后使用该记录时保留说法的来源。
自下而上的证据包括会议、Slack、代码变更和智能体会话。系统可以从 Slack 讨论中提取说法、日期、参与者、关联项目和证据链接;拉取请求则显示实际发生了什么变更。
对于选择参与的工程师,智能体会话记录可以补充拉取请求背后的历史:需求如何演变、哪些测试失败以及开发者做过什么决定。Wenzel 认为,将这些记录与其他来源结合可以呈现更完整的情况。

信号可能失效。速度表不显示,并不代表汽车停止;同样,损坏的数据源也可能让项目看起来很安静。团队因此学会跟踪上次尝试获取信息以及数据源上次正常工作的时间。
最终记录可以不只写“绿色”,还可以写上线时间已两次推迟、证据指向黄色、团队正在讨论失败的测试。领导者可以从报告和证据不一致之处开始讨论,管理者也会收到项目进展与沉寂情况的每周摘要。
用信息分歧引导领导讨论
系统向管理者突出报告和证据之间的分歧,并可能用于客户场景。身份匹配和人员反馈仍是待解决的问题。
Wenzel 说,同样的上下文层模式可以扩展到客户信息:汇集内外部来源,了解客户兴趣并提前判断需求。一个尚未解决的问题是,如何在没有统一标识符时匹配不同系统中属于同一客户的记录。
合适的人工介入取决于置信度和风险。低风险场景下,系统可以自动应用有把握的更新;不确定时可以等待更多证据。风险高时,则需要认真考虑向谁提问、何时提问以及如何提问。
Wenzel 最后重申五步循环:更新、老化、观察、评估和纠正。他建议根据后续实际结果评估系统,并设计智能体与相关人员如何协作,而不是假定索引所有文件就能捕捉字里行间的背景。
同频道的其他文章
19:41EN → 简体中文
22:01EN → 简体中文
27:35EN → 简体中文
15:25EN → 简体中文
14:38EN → 简体中文
21:12EN → 简体中文