用技能、数据与 Codex 构建金融工作流

Stefano Fabbri 和 Oliver Steffmann 与金融机构合作应用 AI。他们介绍了一场围绕财富管理的动手工作坊：将金融数据、AI 模型和实用成果结合起来，帮助顾问处理日常工作。

团队帮助客户将模型用于运营、智能体和工程效率等生产场景。Steffmann 说，他有金融服务背景，也希望从构建者和产品用户两个角度展开讨论。

工作坊分为两部分：先使用 ChatGPT Work 处理金融任务，再用 Codex 定制工作流。参与者获得专用工作空间并完成练习，现场也留出了提问时间。

Fabbri 区分了 ChatGPT、面向知识工作和智能体工作流的 ChatGPT Work，以及更侧重工程任务的 Codex。他将金融服务版本描述为针对金融工作配置的产品，而不是不同的底层模型。

讲者列出三个组成部分：内置和外接供应商提供的金融数据、面向金融任务的指导，以及电子表格和演示文稿等成果。他们也强调呈现结果时的来源标注与核验。

他们介绍的内置数据包括申报文件、市场数据、新闻、私营公司资料和财报电话会逐字稿，供应商包括 LSEG、PitchBook 和 Daloopa。他们指出，市场数据可能存在延迟，访问权限取决于产品和数据安排。

团队表示，数据经过上下文处理，让模型更容易检索和理解。Steffmann 将其与自行收集、更新申报文件并构建可扩展上下文层的工作作了比较。

金融插件结合了可复用技能与工具连接。团队说，他们与金融机构合作开发了投资银行和股票研究工作流，用户可以把它作为起点，再按自己的方法调整。

Fabbri 建议把现成技能当作基础：先试用工作流，找出缺失内容，再按组织需求定制。他提到研究、估值、财报分析和演示文稿准备等金融工作。

练习围绕一名财富顾问展开：发现投资组合变化，调查表现与收益归因，准备解释并制作客户演示文稿。目的在于减少准备时间，让顾问有更多时间与客户沟通。

参与者可以探索投资组合问题、研究、图表、顾问简报和客户演示文稿。工作坊提供示例材料；不同团队可以调整练习，而不必假设每位顾问的工作方式都相同。

进入构建部分时，Steffmann 提问：组织如何加入自己的数据并定制工作流？一种方式是用 API 和网页界面构建独立应用；另一种方式是在组织已经使用的工作界面中扩展。

技能保存可复用的指令。需要工具或访问数据时，插件可以打包这些能力；插件扩展则可以为任务添加合适的界面。工作坊让参与者探索每一层。

一位听众询问，金融产品的效果来自指令和工具，还是来自不同的模型。讲者随后解释，相关工作包括为检索准备数据和上下文，而不只是把原始文件接到模型上。

工作坊网站把练习分成面向用户的金融工作流和使用 Codex 构建两部分。参与者可以先做与自己最相关的部分，再添加技能、插件、数据连接或界面扩展。

Steffmann 将扩展描述为按工作流定制周边界面的一种方式，例如在处理特定工作或文件时显示专门视图。插件可以包含技能、工具配置和 MCP 连接。

讲者区分了工作坊举行时不同界面的能力。他们说，ChatGPT for financial services 位于 ChatGPT Work 网页界面，桌面端的扩展能力有所不同；内置金融数据当时无法直接通过 Codex CLI 访问。

谈到模型之外的内容，Fabbri 介绍了金融数据上下文层。它说明不同字段和文档的含义，帮助模型找到相关信息并避免简单误解，例如混淆价格与收益率。

讲者说，技能还包含与金融合作伙伴共同积累的知识。Steffmann 补充说，自行大规模构建类似上下文层既要收集、更新数据，也要高效提供数据。

被问到能否访问底层数据结构时，Fabbri 说该产品没有开放这些结构。他介绍了团队如何与各数据供应商合作，为数据集准备适合模型使用的数据和工具调用，而不是简单地嵌入所有文件。

演示中，提示词选中了金融服务插件，界面展示了使用的数据和工具调用。讲者说，输出结合了数据访问、任务上下文，以及表格或图表等呈现方式。

内置数据不能满足所有企业的需求。Fabbri 建议添加定制插件，连接内部工具和数据集并提供企业专属逻辑，同时把现有金融工作流作为起点。

Steffmann 说，如果能通过程序直接获取内置市场数据会很有用，但数据许可需要考虑。企业也可以连接自己有权使用的数据源，并通过工作流提供这些数据。

Fabbri 说，客户一直关注 token 成本与效率。对新研究或新代码库，他认为能力最强的模型有其用途。对于重复任务，详细上下文和合适技能可能让成本较低的模型也达到质量要求。

在多智能体设置中，他认为协调智能体可能需要比每个工作智能体更强的能力。他强调要测试具体场景：选择应取决于实际测得的表现，而不是一味选择最大的模型。

Steffmann 介绍自己先用能力较强的模型构建工作坊网站，再用速度更快的模型做后续调整。他建议模型变化时重新评估能力、推理投入和价格，不要假设一种设置适合所有任务。

进入构建架构部分时，Steffmann 展示了本地 Codex 项目、本地 MCP 连接、托管交互界面和企业内部系统。开发者可以先为投资组合或客户数据库制作连接原型，再决定如何打包和部署。

讲者介绍了托管网页界面的插件创建方式和单独的桌面端方式。企业可以通过现有部署和访问控制流程分发已批准的插件，不必让每位用户独自组装工作流。

他们说，在这个示例中，内置金融服务数据仍位于网页界面。企业专属插件可以另行连接数据库或服务，并使用适合组织的身份验证和权限。

讲者把沙箱和企业策略作为部署周围的多层控制。Fabbri 说，在提供工作流之前，管理员通常需要决定哪些员工可以使用哪些插件、访问哪些数据。

插件是否需要服务器？这取决于它要做什么。技能可以是一组可复用指令；而连接外部系统的集成可能需要代码、工具端点和身份验证。

Steffmann 解释，插件可以打包技能、MCP 连接和可选的界面组件。扩展可以在工作界面中提供应用入口或专门视图，让顾问无需在多个网站之间切换就能获取相关上下文。

对于更重的任务，Steffmann 区分了模型速度和运行工具、代码所需的本地计算。他讨论了在本地算力成为限制时，将大型安全扫描等资源密集型工作移到远程环境。

Fabbri 建议跨团队共享可复用技能和参考材料。插件可以包含以前的演示文稿、电子表格或研究作为示例，让模型在制作新的客户交付物时有具体格式可循。

他说，团队可以把反复出现的格式或内容问题修正到技能中，再测试下一次输出。目标是在保留可复用方法的同时，让人能够修改最终成果。

Steffmann 提醒，团队也可能创建过多相互重叠的技能。将投资组合分析等共同能力合并后，更容易共享和维护。两位讲者都说，模型变化时团队应重新测试行为。

Fabbri 介绍了此前用 API 构建的金融深度研究应用：规划器将问题拆成子问题，独立智能体分别调查，评议步骤比较结果，并将矛盾交回进一步研究。

一位团队成员介绍了如何将同一工作流重建为插件。原因是希望把研究带入用户已经使用的界面，复用子智能体和工具连接等能力，同时让用户调整数据源和质量关卡。

Steffmann 说，Codex 底层运行框架是开源的；当团队希望把原型发展为服务端应用时，他介绍了使用 SDK 的方式。团队认为，选择桌面还是托管部署取决于工作流。

Fabbri 区分了开源引擎与专有的第一方应用。他说，模型训练和运行框架经过配合设计，并将子智能体和上下文压缩描述为长时间任务的有用能力。

举例来说，Fabbri 曾让 Codex 复现一篇量化金融论文的代码和数值结果。他说任务运行了数小时，并认为上下文压缩帮助系统在工作期间保留足够信息。

讲者讨论了如何通过托管分发，把构建者制作的插件交给非技术同事。他们认为，这可以让组织在现有环境中适应新的数据源或分析任务。

被问及其他行业时，团队提到医疗和网络安全。Steffmann 指出，成熟企业的数据常分散在多个系统中；他建议在逐步更新整体数据架构的同时，自下而上连接有用的数据源。

一位听众询问沙箱机制。Steffmann 说，企业网络和终端控制仍然重要，并介绍了管理员对本地文件、网络目标和插件访问进行管理的策略。团队表示，权限与批准设置是企业部署的核心问题。

在最后的提问环节，Fabbri 认为生产环境中的智能体需要评估，以找出成功和失败之处。结果不佳可能来自工作流、指令、工具或模型本身，因此团队决定修改什么之前需要证据。

他说，构建评估之所以困难，部分原因是领域专家掌握业务知识，而工程师负责搭建测试系统。他建议先从简单检查开始，再逐渐增加复杂度；使用模型评估时，可以把宽泛评分拆成更清晰的是非问题。

对于研究任务，他将目标模式描述为先指定目标，最好是可衡量的目标，再让智能体迭代假设。他举了根据评估集优化提示词的简单例子，也介绍了使用子智能体独立调查。

一位听众问插件能否写回记录系统。一位团队成员介绍，可以通过工具在本地保存结果，也可以在获得适当授权后连接远程服务。在一个代理投票的例子中，生产记录存放在外部应用数据库中。

Fabbri 补充说，受监管工作流需要记录决策所依据的数据源和逻辑，而不只是最终成果。团队最后邀请大规模实施这些工作流的组织提供反馈。