30 秒看懂
前金融分析师 Yijia Liang 介绍 Compound 如何为机构交易团队设计智能体。他讨论共享邮件工作流、兼容 Office 的文档引擎以及处理大型文件集合的方法,并提出公司针对性能与兼容性的具体说法。
- 1金融工作不是预订餐厅交易工作可能涉及数周迭代、多名审查者和数千份私有文件。
- 2共享智能体收件箱基于邮件的协作需要验证线程中参与者的身份和访问权限。
- 3以 token 衡量的构建过程Liang 报告说,公司开发引擎使用了 1.5 万亿个输入和输出 token,生成超过 800 万行代码。
- 4针对特定工作负载的速度说法Compound 报告其测试中 20 MB 电子表格的重新计算速度提高四倍。
- 5写入、渲染、检查、修正自主控制的渲染循环让智能体可以检查并修改生成的文档。
- 6处理大型资料室Liang 介绍如何把文件分析分配给多个智能体,并将发现关联到源文档。
要点建议
- 机构金融任务涉及多人、漫长的审查周期以及大量私有数据。
- 共享智能体收件箱需要验证参与者身份并实施适当的访问控制。
- Compound 构建文档引擎,以支持并行工作及写入、渲染、检查的迭代。
- 演讲者给出的速度和保真度数字是针对特定工作负载的公司说法,并非普遍保证。
- 引用帮助分析师将发现追溯到源文档,但不能替代审查。
- 自动化旨在让交易团队腾出时间应用判断,监督程度应与任务相适应。
按章节阅读整理后的全文
为什么金融需要不同的智能体
Liang 比较个人智能体与机构金融中耗时更长、需要协作且数据密集的工作。
我曾在 Coatue 担任约三年副总裁,专注于后期私营软件投资。很多工作意味着深夜使用 Excel 和 PowerPoint。我离开后开始为自己过去的工作构建工具;今天我想介绍 Compound 如何处理金融领域的长时间运行智能体。
我们认为个人智能体变得更有用有三个原因:后台工作更可靠,智能体可以主动行动,还能连接邮件、日历和云盘等重要上下文。但在机构金融工作流中,这些因素呈现出的情况并不相同。
预订餐厅不能等同于把资料室转换成投资委员会所需的模型、幻灯片和备忘录。后者可能涉及数周工作和多轮审查。董事总经理可能不希望智能体在没有指示的情况下行动;相关上下文还可能包括数千份文件和公司多年来的记录。
我们的方法有三个部分:让交易团队共享智能体作为协作者,使用自建文档引擎并行运行长任务,并处理公司数据的广度与深度。每一部分都对应委派更复杂工作时的不同障碍。
共享智能体与邮件
交易团队可以共同参与智能体线程,但访问控制和交互设计十分重要。
交易团队不是单个用户。分析师即使分别在聊天界面或插件中工作,仍要通过邮件或 Teams 传递文件并向同事征求反馈。我们希望同一工作流中的相关人员参与同一线程,让智能体获得交易参与者的相关输入。
在 Compound,每个智能体都有收件箱,因为机构金融中的许多工作都发生在 Outlook 邮件线程中。让智能体使用邮件并不只是连接邮箱:系统需要验证参与者身份并确保其拥有适当权限,尤其是交易信息受保密协议约束时。
我们也考虑了交互细节。如果多人短时间内连续发邮件,智能体逐一确认可能会向整个线程发送大量消息。回复前加入一定延迟,是我们为让智能体更像现有对话中的队友而采取的一项设计选择。
构建文档引擎
Compound 将智能体生成的实现与 Office 对比,并使用引擎开展并行工作和渲染检查。
仅有协作并不能解决并行执行问题。我们评估了桌面插件、控制 Office 应用的虚拟机,以及现有开源或商业引擎。按照我们的评估,它们没有同时满足我们对保真度和规模的要求,因此我们决定自建兼容 Office 的引擎。
我估计,这项开发使用了 1.5 万亿个输入和输出 token,生成了超过 800 万行代码。我们的方法是给编程智能体设定保真度目标,把结果与 Office 比较,再反复迭代。这些数字描述的是我们的项目,本身并不能证明已经复现 Office 的每一项功能。

对于电子表格引擎,我们从开源项目 IronCalc 开始,使用在线收集的文件和内部创建的示例进行测试。我将结果描述为高度保真的复刻,但兼容性和速度仍取决于具体测试的文件与功能。
我们把类似的对比循环用于演示文稿和文档。渲染是关键:文件既要在我们的编辑器中显示正确,也要在团队下载到 Office 后显示正确。金融机构需要能够检查和发送的成果,因此视觉与文件兼容性和智能体生成内容的能力同样重要。
我认为,无头引擎可以并行执行工作,而不必让每个智能体都绑定到虚拟机中的桌面应用。我们的测试观察到 20 MB 电子表格的重新计算速度提高四倍。这是公司针对特定工作负载的说法,并非适用于所有电子表格的通用基准。
拥有编辑器也改变了协作方式。我先让智能体生成这次演示文稿的初稿,再通过评论提出格式要求。交易团队的多名成员可以通过共享界面添加自己的意见,让智能体异步处理反馈。

我们的引擎为智能体提供写入、渲染、检查和修正的循环。如果代码库只能编辑电子表格单元格,却不能渲染结果,系统就缺少直接检查格式的方式。通过控制渲染,我们可以让智能体在交给人之前检查输出并迭代。

寻找和理解数据
公司介绍如何处理大型资料室和工作簿,并结合来源引用与公司特有上下文。
数据问题同时有广度和深度。资料室可能包含超过 1.5 万份文件,而一个工作簿就可能达到几十 MB,包含大量公式。挑战不仅是找到文档,还包括理解其中的细节。

在广度方面,我们使用主智能体划分文件范围,把工作交给多个智能体,再根据发现迭代。我更倾向于在这一工作流中直接读取文件,使用搜索或其他方法,同时也承认向量数据库在特定用途下仍可能有价值。
我们希望每项发现都附有指向源文档的引用。引用让分析师能够回到数字或陈述背后的证据;但它仍需结合上下文审查,不能自动保证结论正确。
在深度方面,我们的电子表格引擎处理工作簿,并向模型提供结构化信息和工具。我认为,这可能比让现成模型通过代码反复打印、检查大量工作簿上下文更快、更便宜。比较结果取决于任务和具体实现。
目标是减少寻找文件或反复解释格式偏好所花的时间,把更多精力用于判断交易。工作流连接 SharePoint 和 Outlook 等来源,以引用支撑发现,并纳入公司的知识与偏好。

从辅助到委派
Liang 讨论哪些工作仍需要人深度参与,以及更大规模委派所需的保障。
我区分了现有工具已经能够自动完成的任务,以及人们仍希望深度参与的、更长且影响更大的工作。制作详细的投资委员会演示文稿或符合公司要求的模型,需要仔细审查和控制;我们的目标是在保留判断的同时扩大可委派的范围。
我借用编程领域的类比:当检查机制可用时,人们从接受单条建议转向委派更复杂的任务。在金融领域,这种转变需要可靠工具、证据和适当的人类监督。我的更广泛预测是,公司会尝试让部分工作流从辅助驾驶转向更自主的运行。
同频道的其他文章
15:51EN → 简体中文
20:39EN → 简体中文
18:33EN → 简体中文
18:57EN → 简体中文
16:37EN → 简体中文
18:52EN → 简体中文