演讲来源：AI Engineer 演讲嘉宾： Stefano Fabbri、Oliver Steffmann，应用 AI 工程团队
Stefano Fabbri 和 Oliver Steffmann 来自 OpenAI 应用 AI 工程团队，主要与金融机构合作，推动 AI 在实际业务中的应用。在这场 AI Engineer 工作坊中，两人展示了如何结合金融数据、专业 Skill 和 Plugin，在 ChatGPT Work 与 Codex 中构建可定制的金融 Agent，支持投研分析、财务建模和报告生成等任务。
工作坊进一步讨论了如何将机构内部数据、研究方法和业务系统接入现有 AI 工作平台，以及如何利用多 Agent 协作完成复杂研究。同时，两人还介绍了模型成本优化、Skill 复用、Eval、企业权限和审计机制，探讨金融 Agent 从实验工具走向企业实际应用所需的工程能力。
TL;DR：OpenAI 核心观点 1. OpenAI 正在将金融 AI 从问答工具扩展为可定制的工作平台。 金融产品整合 LSEG、PitchBook 等数据来源，以及投行、股票研究等专业 plugin，支持投资组合分析、估值建模和客户材料制作。金融机构还可以通过 ChatGPT Work 和 Codex，接入内部数据、研究方法与业务系统，减少另建独立应用的需要。 2. skill、plugin 和 plugin extension 对应不同层次的定制需求。 skill 沉淀研究方法、规则和模板；plugin 将这些能力与 MCP、工具连接和权限配置打包；plugin extension 则提供机构自己的操作界面。应优先建设可复用的核心能力，而不是为每个任务创建独立 skill。 3. 复杂金融研究可以通过动态 agent 编排完成。 工作坊介绍了股票 deep research 的实现方式：规划 agent 拆解问题，多个 subagent 并行调查，再通过交叉核查与反馈处理矛盾。Codex 还被用于复现量化金融论文，借助 compaction 管理长任务的上下文。 4. 明确的 skill 和 eval，有机会降低模型使用成本。 对于重复性金融任务，清晰的业务规则与输出标准，可能让较小模型达到所需质量。复杂研究可以使用更强模型，执行子任务则根据要求选择不同模型。具体选择需要通过任务 eval 比较质量、成本与耗时。 5. 金融 agent 进入生产环境，难点不只是模型能力。 企业还需要解决数据授权、身份认证、工具权限、安全隔离和审计记录。工作坊介绍了研究结果回写外部业务系统的案例。业务专家与工程师共同设计 eval，检验任务质量；来源、操作日志和权限记录则支持后续检查与追溯。 演讲精编 金融工作流 我们是 OpenAI 应用 AI 工程团队的 Stefano 和 Oliver，团队的 Dom 也在现场协助。
这是一场互动工作坊，会使用 ChatGPT Work 和 Codex。我们想展示，怎样把金融数据、 LLM 的能力，以及恰当的输出放在一起，支持日常业务。
今天选择财富管理案例，因为现场有很多来自资产管理和投资银行的参与者。我们的团队主要与客户一起工作，研究模型怎样在企业中投入使用，让投入真正产生价值。无论是运营、 agent 还是编程效率，都是日常接触的问题。
我们也有金融服务、资产管理和银行业背景，但首先是喜欢建设产品的人。今天除了展示用途，也会讨论怎样在平台上自己建设。
我们会为大家开放一个专用工作空间，提供金融数据，以及本次会话不限 token 的使用额度。我们还开启了 Ultra Fast 模式，让大家更快地完成实验。6.1 Sol 和 6 Astra 在这个模式下，平均生成速度约为每秒 300 个 token，适合在工作坊里快速构建东西。
计划先介绍金融服务产品，完成环境设置，再分别体验现成能力和 Codex 中的定制建设，最后讨论问题与反馈。
三种工作入口 三种工作入口：ChatGPT探索问题，ChatGPT Work完成任务，Codex建设方法
今天先体验 ChatGPT Work，再进入 Codex。但这不是说 Codex 只能给工程师使用，它也可以成为业务人员和知识工作者的入口。区别在于，我们后半场会利用它做更深入的定制。
金融产品的三部分 金融服务产品介绍：数据、专业任务与交付物 面向金融服务的产品，有三个主要组成部分。
第一是数据。产品内置一部分金融数据，也能连接第三方数据供应商，让 agent 直接使用。
第二是专业任务能力。我们围绕并购、股票研究等金融工作进行了训练和产品建设。
第三是交付物。模型不只回答问题，还要制作演示文稿、电子表格，并参考历史模板，把新的分析放进机构惯用的格式。
需要区分，基础模型与产品层面的适配不是同一件事。这里既有模型能力的改善，也有数据、工具、 prompt 和上下文层面的专门设计，并不是每种专业功能都意味着额外训练了一套独立模型。
实操部分不只看能否找到数据，也会看怎样要求图表、怎样验证结果、怎样标注来源。只有把这些环节放在一起，才是领域产品。
数据不是接上就够 金融数据来源：监管文件、电话会、财务指标、私人公司资料与行情 我们提供的金融服务版本面向企业，内置的数据供应商包括 Daloopa、LSEG、PitchBook、Crunchbase 等。
这些数据包括美国证券监管文件、市场数据、新闻、私人公司资料和业绩电话会记录。部分行情有大约十五分钟的延迟。
关键不只是把原始数据传进来。我们针对数据集做了组织和预处理，让模型更容易读取、提取和使用。
我自己以前做过类似工作。把监管文件收集下来还只是开始：要做到规模化、及时取得新信息，还要在后面有一个足够有效的上下文层。供应商连接、持续采集、内容组织和快速检索，合起来才构成可用能力。
plugin 提供专业起点
金融研究与分析 plugin：研究、建模、图表与检查 为了让这些数据进入分析，我们建设了投资银行、股票研究等金融 plugin。
这里说的 plugin，可以理解成一组 skill，加上 MCP 等工具连接。我们与金融机构合作，把行业方法放进能够使用的起点里。
例如，股票研究员可以先取用现成 skill，再建立定期任务或分析流程，逐步加入自己的观点和缺失环节。你不用完全从零开始，而是在已有专业方法上定制。
你可以把它想成，我们先提供八成的基础，你再补上自己需要的两成，把自己的方法加进去。
现成任务包括推介材料准备、业绩分析、估值和杠杆收购建模。今天会把重点放在资产管理。
即使对有资本市场经验的人，这些 skill 也有帮助。我曾通过现成 plugin 运行估值例子，更快理解投资银行客户在讨论什么。
财富顾问的工作流 将分析转成机构风格的客户材料：模板、格式、来源和假设 先看财富顾问。我们希望减少团队花在组合检查、解释变化、准备会议和制作材料上的时间，让顾问有更多时间与客户交流。
我们先看客户的投资组合发生了哪些变化，再分析损益或组合归因，解释变化的原因，最后准备客户演示文稿，说明怎样恢复目标配置。
不同顾问、不同团队的方法可能不一样，所以这是一个可以定制的终端工具。我们提供 prompt 和样例数据，让大家按组合分析、研究、图表等不同部分自行体验。
我们还在工作坊页面安排了模拟资金和任务步骤，方便大家在练习时查看自己的进度。
另建应用还是扩展 如果现成产品已经满足大部分需求，接下来的问题是：机构自己的数据和业务要求怎样进来？
有两条路线。第一，使用 OpenAI API，自建网页和应用，在企业内部部署，再维护相应的软件生命周期。
第二，员工已经在使用 ChatGPT Work 和 Codex，能不能把所需流程继续放在这个生态里？
后半场就是从内部开发者角度，用 Codex 建设 skill、 plugin 和 plugin extension，在现有入口中实现所需应用，而不必让使用者再跳进另一个系统。
三层定制方式 plugin 结构文档： skill、服务连接、工具配置与界面能力 skill，是把可复用的方法写成 Markdown 等文件，告诉模型这类任务应该怎样做，可以带上模板、参考材料或脚本。
如果还要连接内部数据，就需要工具、MCP 服务、认证等更多结构。这时 plugin 是更完整的包，既可以包含 skill，也可以包含系统连接与其他能力。
plugin extension 则进一步处理界面。比如，在特定对话或文件类型出现时，弹出机构自己的操作面板；或者在工作入口中添加导航、设置和应用位置。
这让财富顾问既能使用现成金融分析，也能在同一个入口调用机构自己的流程。
不同入口的边界 工作坊实操页：使用Codex建设 plugin extension 今天，我们通过 ChatGPT Work 网页端使用金融服务产品。桌面端可以使用的能力，并不意味着 CLI 也能读取同一套内置金融数据。
plugin 可以用于网页端或桌面端，但我们今天演示的界面扩展主要在桌面端运行，网页支持还在推进。
因此，不能因为能在桌面建设一个 plugin，就假定所有入口都能使用完全相同的数据、界面和 API。特别是数据授权，也会限制能否另行通过程序取得数据。
建议大家使用 Astra 或 6.1 Sol，并选择相应的高速选项。注意，Ultra Fast 控制生成速度，Ultra 对应推理投入，这是两个不同的设置。
金融服务实验设置：选择模型与Financial Services入口 从 prompt 观察 tool call
现场调用金融 plugin：观察使用的数据与工具执行过程 在演示中，我们把 prompt 放进产品，可以看到它选用了金融服务 plugin，以及内部使用的金融数据与 tool call。
prompt 里对相应 plugin 的指向，是帮助模型选对能力的一种方式。
响应也可以更贴近任务。问营收时，产品知道适合给表格和图表，并以更有针对性的界面呈现。基础模型单独使用，不一定自动选择同样的展示方式； plugin 提供了相关上下文。
图表核查步骤：检查源表、季度口径、单位及估算与重述标记 机构可以在这个基础上添加自己的 plugin、工具和数据。现成金融数据不可能覆盖每家公司的全部需求，内部业务逻辑才是最后的定制层。
用 skill 控制成本 近几个月，token效率、成本和等待时间，是我们与客户经常讨论的重点。
建设全新代码库、探索新问题时，最强模型通常有优势。但对于重复任务，清楚的上下文和 skill 可能让成本较低的模型也达到所需质量。
例如，把预期行为、输出格式与规则写清楚，使用 Luna 或 6.1 Sol，也可能完成高质量报告与分析，而不是始终调用最昂贵的 Astra。
多 agent 流程也一样。负责整体规划的模型，可能需要更强能力；各个执行子任务的模型未必都要相同规格，可以尝试 Terra、Luna 等选择。
我们见过某些任务保留约95%的整体效果，但这必须针对具体用例 eval，不能把一个比例当作普遍保证。
财富管理若覆盖大量客户，成本与耗时会迅速累积。因此，要把 skill、模型和推理投入放在一起比较，确认输出满足要求。
我建设这次工作坊网站时，就让 Astra 先完成较复杂的部分，再用更快、更经济的 Sol 做局部调整。每次模型更新，都要重新了解不同投入水平与价格点上的能力。
plugin 怎样进入企业 工作坊架构图：工作入口、 plugin、金融服务与机构内部系统 plugin 结构中，可以有 skill、MCP 服务、工具配置和界面组件。建设时先问：最终用户在哪个入口工作？
桌面端可以先用本地 MCP 做原型，连接内部证券、组合、客户数据库，或者 Salesforce 等系统。
网页端可以通过相应的 plugin 创建工具接入；桌面端则可以用机构已有的软件分发机制，把 plugin 与客户端配置一起管理、部署。
另建独立应用时，通常还要处理登录、访问控制和企业审批。如果已有入口已经部署并纳入管理，把流程接进去，可能减少很多重复建设。
但这不免除外部服务的工作。内置金融数据仍有自己的可用范围；内部数据库需要另外建设工具连接，确定认证是系统身份还是代表当前用户，并落实权限。
企业也可以控制哪些员工能访问哪些 plugin 和数据。把原型变成实际可用流程时，不能只看它在开发者电脑上跑通。
部署位置详图：本地Codex与stdio MCP、托管ChatGPT和企业HTTPS MCP 是否一定要服务器 skill、MCP、 plugin 与 plugin extension 的用途对照 是否需要服务器，取决于 plugin 做什么。只有 skill 文件的包，不一定需要独立远端服务；要连接企业系统、处理认证和逻辑，则需要相应的服务或工具实现。
skill 提供可复用的方法，但不天然解决系统到系统、代表用户访问等集成问题。 plugin 可以把这些能力组合起来，再以一个包分发。
工具也可以带有用于展示的界面组件。把 skill、连接配置、代码与相关界面组织在一起，才能成为适合机构部署的完整能力。
把流程留在一个入口 本地客户审阅面板：筛选客户、模拟慢响应并预览有限上下文
plugin extension 示意：在导航、主区域和侧栏中加入定制界面 界面扩展不只是增加一个图标。它可以在导航、设置或业务操作位置上，加入机构自己的界面。
设想一个员工完成工作需要在五个网站之间来回跳转。我们希望他留在常用、由 AI 支持的入口，通过对话推进任务。
当对话进入客户会议准备，就出现相应面板，读取这个客户的内部资料或展示业务需要的指标。用户不必离开当前工作区。
如果大家从今天带走的只有一件事，就是理解这些层次怎样连接起来，这场工作坊就已经很有价值。
模型快不等于任务快 在Codex中构建Advisor Review plugin：任务要求、subagent与模型推理投入 现在我们让 Codex 建设示例 plugin。即使使用高速模型，生成代码、在本地运行和检查，也需要时间。
同一台电脑可以打开多个任务，但不能因此无限扩展计算资源。比如，对大型代码仓库做应用安全检查，会占用很多本地计算。
任务多时，需要考虑远端 runtime 或云端计算。模型生成很快，不代表代码执行、数据处理和 tool call 也会同样快。
企业若能方便地分配计算环境，就可以把任务交过去，完成后再回来检查。今天的示例在本地运行，仍然受笔记本性能限制。
把模板与经验共享 plugin 和 skill 的目标，不是让每个人都维护完全不同的一套，而是让团队共享一个能力库。
这也包括交付物模板：网站、演示文稿、电子表格，都可以提供历史范例。
例如，给私人财富客户制作研究材料，可以把几份过去的报告放进 plugin，在 skill 中说明按这些格式组织新的分析。
金融行业很重视格式。我们在模型制作表格和演示材料的能力上投入很多，不只是数值正确，也包括布局和专业标准。
实际可以拿自己的表格、演示文稿或 PDF 作参照，要求模型把新分析放进去。输出仍有细节不对，就把这些反馈补进 skill，使下一次更接近要求。
共享 skill 的另一个价值，是改进可以被其他人复用，而不是只留在某个人的聊天记录中。
生成的SKILL.md：客户证据、来源编号、缺失输入与plugin校验结果 从独立研究应用迁移 以前，有些复杂流程只能通过 API 和代码单独建设；现在，其中一部分可以放进 plugin。
我们做过一个面向金融研究的案例，可以理解为更专门的 deep research。它先由规划 agent 理解问题、拆成子问题，再安排不同 subagent 独立调查。
随后，一个核查或反馈环节汇总发现，检查冲突。如果不同结论相互矛盾，就继续安排调查，直到报告达到要求并覆盖问题。
这是一种动态编排，而不只是固定顺序调用几个 prompt。
我们也可以把这样的流程做成 plugin。使用者不必去另一套应用，在 Codex 内就能看到 subagent 正在调查什么，也可以为这些活动设计自己的界面。
研究流程为什么用 plugin Dom： 原来的股票 deep research，是我建设的一套独立应用，目的是进行并行、经过验证、达到专业质量的研究。
里面有很多手工编排：有些步骤调用模型，有些是确定性的程序。
后来，用户越来越习惯在 Codex 或 ChatGPT Work 里完成工作，单独托管一个网站的必要性就降低了。
我开始考虑，能否复用 Codex 的 subagent、动态任务安排、 tool call 和数据连接，而不是自己为每个环节再造一套。
tool call 如果更符合模型受训时熟悉的模式，执行可能更快、更准确。于是，这项能力适合成为一个工作流程：需要哪些硬性门槛、哪些灵活判断，可以按要求安排，再用 Codex 作为主要入口。
过去像一个预先定义好的黑箱应用。改过以后，使用者可以更容易调整数据源、质量门槛和研究方法，让流程随着需求演进。
本地与服务端的衔接 Codex 的一部分核心运行代码是开放的，桌面应用则提供受管理的使用入口。开放代码不意味着所有第一方界面和服务都开源。
如果一个研究员或量化人员在本地做好流程，后来需要扩展到团队或服务端，可以再考虑 SDK、程序化运行或其他服务端部署方式。
这提供了复用工作的路径，而不是每次换运行位置就完全重写。需要区分本地原型、团队部署和独立应用各自要管理的环节。
开放的运行代码，也让企业能够检查行为，并在适当范围内进行定制。
长任务与 compaction 我们认为，模型与 runtime 的配合非常重要。 post-training 让模型熟悉某些工具、编排和运行方式，实际使用这些结构时，更容易发挥能力。
对于较复杂的任务， agent 可以判断是否需要 subagent。更高投入的模式，也可能更积极地使用并行研究能力。
另一个关键是 compaction。我们使用一个辅助模型，持续整理当前对话的上下文，保留重要信息、去掉冗余，让上下文保持在长度限制以内。这样，长时间运行的任务才能继续推进。
我们经常与对冲基金、专业交易公司合作。我曾拿一篇关于布朗运动和期权定价的量化金融论文，要求 Codex 复现代码、生成数值结果，再检查是否与论文一致。
那是几个月前，使用的还是5.5，并不是今天展示的Astra。这项工作运行了几个小时，涉及随机模拟和模型校准。完成后，我对它能复现这样一套代码相当惊讶。
如果没有 compaction，长时间任务很难这样持续推进。使用已有 runtime，可以减少开发者自己建设这一层的负担。但复现结果是否可信，仍然需要回到论文和数值验证。
从 CLI 到工作空间 很多工程师最初习惯使用 CLI，我也是。但我们看到，越来越多技术人员转向完整应用，把更多工作留在同一个空间里。
作为以前做量化研究的人，我过去总开着交互式笔记本，现在也会在 Codex 中完成这些实验。
技术人员可以建设 plugin，再交给非技术同事。借助企业管理机制，有些交付过程有机会从数月缩短为数周，但具体仍取决于机构的集成、验证与审批要求。
金融业务不断接入新数据、调整分析方法，又需要可审阅的文件输出，因此很适合探索这种工作方式。我们的目标，是把编程中已经出现的效率改善，也带给知识工作。
sandbox 与企业控制 交互开发要求：先添加测试，再实现证据缺口筛选及客户切换检查 plugin extension 可能在用户桌面或相应 runtime 里执行代码，因此必须讨论安全。
不能只有一道防线。企业网络安全、终端检查和既有管理要有，应用平台内部也需要控制。
Codex 的管理配置和策略，可以限制本地可访问范围、网络目的地，以及哪些人能使用哪些 plugin。例如，一个团队的 plugin 不应自然取得另一个敏感项目目录的访问权。
这类配置应由管理员按企业和团队要求管理、分发。工具自身的权限和安全，也仍然需要建设，不能以为进入 sandbox 就什么都解决了。
另一个问题是使用体验。安全团队希望限制敏感操作，业务人员却不希望每次访问工具、网站都反复点击确认。
我们还提供 guardian 和审批机制，辅助判断哪些请求涉及敏感操作、哪些不涉及。这样可以在安全团队的策略要求与用户操作的便利之间取得平衡，例如判断是否需要访问某个工作目录。
我们接触的大型机构，几乎都会定制审批与权限配置。这通常是部署讨论中的第一批问题。
分发与生产 eval 客户审阅原型的测试结果：21项测试通过及证据缺口筛选界面 对开发者而言， plugin 市场是一种新的分发渠道；企业内部共享也有类似逻辑。但公开发布仍要经过相应审查，确保安全、稳定，并符合用途。
除了这些现成入口，我们也与客户合作建设定制 API 应用。无论哪种方式，进入生产后都需要回答：实际性能怎样测量？
如果效果不达要求，是 prompt、 runtime、工具连接有问题，还是模型本身达不到？ eval 数据应该帮助区分这些原因，再决定优化什么。
有些限制也需要反馈给研究团队，使下一轮模型改进更贴近真实任务。
Q&A 听众： 金融数据、文件和工具更好用，究竟是 runtime 和 skill 做了什么，还是模型本身有所变化？是否有额外的 ontology 层？
Stefano： 我们的工作包括重新组织数据的含义与上下文，不只是像调用普通 API 一样接上数据源。
以年度、季度报告为例，除了提供文件，还要说明其中不同部分是什么，哪些内容与当前任务相关。供应商接入时，也会一起研究怎样组织数据，怎样用合适的格式交给模型。
plugin 里的 skill 和模板也包含专业知识，来自与金融机构的长期合作，并在选定合作方的任务中验证过。
Oliver： 大规模上下文服务本身需要工程工作。若企业自己做，也要面对持续采集、供应商接入、数据组织和检索效率，而不只是选择一种向量表示。
听众： 能直接访问底层的图结构或 ontology 吗？是不是用了定制 embedding？
Stefano： 这些内部结构并不是面向使用者直接开放的 API。这里的产品主要面向知识工作者。
价格和收益率是不同对象。数据 API 应帮助模型理解这些差别，避免把错误字段用于计算。
也不能简单把它归结为定制 embedding。我们对每个数据集进行预处理，建设适合该数据集的 tool call，使模型更容易取到合适的内容，并理解应当怎样使用。
听众： 换模型之后， skill 还能复用吗？
Stefano： 同一家模型系列的渐进更新中， skill 通常较容易复用。跨较大代际时，可能需要调整。随着模型能力增加，有些说明甚至可以减少，但仍要重新测试。
Oliver： skill 本身也可能变成一个不断膨胀的问题。我们见过客户积累太多 skill，团队难以分享、标准化和维护。
如果两个人做相近的分析，应先看看能否抽出共同能力，而不是各自再建一套。组合分析、交易分析可以是核心 skill，但不必给工作流里的每一步都建一个独立 skill。
我最近就建议过客户删掉一些 skill，先定义清楚真正的核心能力。它首先是组织管理问题，而不只是模型问题。
如果要把一项能力作为应用分发， plugin 提供更清楚的打包与部署边界；如果只是沉淀核心工作方法， skill 可能已经足够。没有一条适用于所有团队的简单答案。
skill 过多还可能增加处理负担。模型更新时，应检验这些方法是否继续产生预期行为；有条件时，可以利用预览版本提前测试。
听众： 这些做法只适合金融吗？是因为金融数据结构比较清楚？医疗或其他领域是否也有类似建设？
Stefano： 有。医疗是重要方向，网络安全也是我们经常接触的场景。
例如，安全团队未必一开始就是 AI 专家。我们除了提供模型和 runtime，也提供面向扫描、审阅与修复的 skill 和 plugin，让团队有一个可以直接使用的起点。Daybreak 就是相关的安全产品。
金融、网络安全、医疗和研究，通常较容易找到可以衡量的任务。
Oliver： 软件供应商也可以把现有产品能力，通过这些新入口交付。
企业的问题往往是数据分散，没有统一上下文。自上而下改造全部数据架构需要很长时间，也可以同时自下而上，让团队从具体任务连接数据，逐步积累上下文。
这两条路线可以并行。不是一定要等全公司数据全部现代化，才开始在有限范围内做有价值的工作。
听众： 你们怎样看市场采用 eval 的成熟度？更高级的自动研究工作流又发展到什么程度？
Stefano： eval 经常是阻碍。我的个人看法是，它难的不只是技术，而是需要把业务专家的知识，放进由工程师建设的数据集和判断机制中。
我以前做量化研究，更相信不测量就无法优化。不能只说“ eval 得了70分”，还要知道哪些子任务做得好、哪里失败。
因此，建议从简单方法开始，不要第一步就用模型当裁判。否则很难分清，到底是 eval 本身不可靠，还是被 eval 的 agent 不可靠。
需要用模型判断时，也尽量把“一到五分”的笼统评价拆成明确的是非问题。二元条件往往更容易理解、校准和检查。
我们也发布了基于 Luna 的 Decision API，可以很快给出是或否的判断，以及相应的概率和置信信息。我认为，它在 eval 中会有很多应用。
自动研究是更大的话题。编程能力与数学能力的改善，使这类工作更有可能推进。复现论文就是一个入口。
另一个入口，是给出一个可以度量的改进目标。Codex 的 goal mode 允许围绕目标持续尝试新想法、检验假设。
例如，给定 agent 和 eval 集，要求调整 prompt，让某项明确指标改善。这是比较简单的自动研究形式，但并不等于没有价值。
我们也在数学研究中使用过类似方式，有些结果附带公开 prompt，能够看到任务怎样拆分、怎样调用 subagent 和合并发现。
当任务使用较高推理投入时， agent 可以把独立研究交给不同子任务，再合并、继续迭代。设计者越来越需要想清楚的是目标，而不只是自己手工安排每一步。
这不意味着不再需要 eval 或任务边界。恰恰相反，目标和检验办法越清楚，自动迭代才越有方向。
听众： 今天看到很多只读 skill 与 plugin。有没有把结果写回业务系统、正式记录系统的案例？
Dom： 可以，具体取决于建设什么。
Codex 可以作为编排入口，而工具和流程把数据存到远端系统。最简单的方式是写入项目范围内的本地文件，明确要求把结果保存在指定位置。
本地文件也可以成为长期任务的记录点。但如果建设完整扩展，可以进一步连接应用服务器或数据库，让正式记录保留在外部系统。
我们做过代理投票相关案例。用户在 Codex 中工作，报告、发现、日期和来源却写入应用服务器背后的数据库，再供原有生产应用使用。
因此，用户的工作入口可以是 Codex，但管理、法律审阅所依据的正式记录系统，在 Codex 之外。
MCP、扩展和 OAuth 等权限机制，帮助连接这些环节。选择本地保存还是外部系统，需要按业务的记录归属和访问要求决定。
对于代理投票等需要审计的流程，我们还会保存标准化日志。
审阅者不应只看到最后结论，还要理解每个判断用了什么数据、经过什么步骤、依据什么逻辑。
在金融这样的监管环境里，能够回溯到数据来源和决策过程很重要。因此，输出交付物时，也应考虑把可审计记录作为流程的一部分保存。
原视频： https://www.youtube.com/watch?v=ZJjRgvjhq3M
