开场：什么是 PAT？

大家好。

我叫 Brendan McManus，是 Bridgewater Associates 应用 AI 团队的负责人。Bridgewater 是一家系统化宏观对冲基金。

我在 Bridgewater 已经快十年了。最开始我是软件工程师，后来成为系统化投资者和研究员，而过去几年里，我的主要精力一直放在弥合投资与技术之间的鸿沟上。

今天我和两位同事 Michael Ran、Santi Weight 一起来到这里。他们分别是这个项目的投资负责人和技术负责人。我们想和大家介绍一个由 Bridgewater 内部开发的工具，叫做 PAT，也就是 Pocket Analyst Tool（口袋分析师工具）。

在今天的演讲结束之前，我们希望让大家看到，我们是如何构建出一个 AI 分析师的：它可以在几分钟内完成原本需要专家花上数小时的研究工作；目前已经在公司内部部署给数百名投资者使用；而且它会从每一次互动中持续学习。

除此之外，我们还会非常具体地展示，它的整个系统架构到底是怎么搭建的。

Bridgewater 为什么天然适合进入 AI 时代

在正式展示产品之前，我想先简单讲一下 Bridgewater 看待 AI 的方式。

Bridgewater 过去几十年——准确地说，是 50 年——一直在思考一件事：如何把市场与经济运行规律编码进一个能够不断积累和复利的系统里。

这一切其实始于屏幕上看到的东西：我们在 1980 年建立的债券系统。当时这些规则就写在一本黄色便笺本上。

它背后的理念很简单：每一次你准备做一笔交易时，都把你为什么认为这笔交易合理的规则明确写下来，把背后的因果逻辑准确地写下来。

因为一旦你把它写下来，另一位投资者就可以检查你的逻辑，帮助你找出哪里出了问题，也可以帮助你改进整个决策过程。

每当你学到新的东西，就划掉一条旧规则，写下一条新的规则。久而久之，这就形成了一套非常强大的学习机制，而这套机制也成为 Bridgewater 过去 50 年里许多工作的基础。

在几十年的时间里，我们不断在这套机制之上积累。我们把每一条经验、每一种方法、每一条关于“为什么这么交易、怎么交易”的规则，都逐步编码进一个专家系统。这个系统既可以被机器读取，也可以被人类理解。

所以到今天，我们实际上已经拥有了非常庞大的数据和知识资产。而这些数据，也恰恰让我们在 AI 时代拥有了非常好的起点。

我们不需要为了 Agent 时代再回头把所有知识重新整理一遍，因为那些东西本来就已经在那里，可以直接被 AI 调用。

Bridgewater 从两个角度看待 AI

整体而言，我们从两个角度使用 AI。

第一个角度，是作为投资者。

作为投资者，我们必须深刻理解所有正在塑造全球市场与经济的重要力量。就像过去我们必须理解新冠疫情，或者最近发生的石油供应冲击一样，我们现在也必须理解 AI。

AI 供给与需求之间的不匹配到底是什么样的？推动基础设施建设的力量是什么？这些变化最终又会如何影响市场？

对我们而言，理解这些东西，是一个投资者最基本的能力要求。

第二个角度，是作为 AI 的实际使用者。这也是今天演讲主要会讨论的部分。

我们正在把 AI 应用于整个研究流程的各个环节。最终目标，是构建出一个“人工投资者”，让它具备人类投资者每天所进行的完整工作能力。

“人工投资者”需要具备什么能力？

那么，人类投资者实际上每天都在做什么？

我们把它理解成一个“研究闭环”。

投资者会持续感知外部世界正在发生什么；提出关于“什么是真实的”“自己可能遗漏了什么”的问题；展开分析和调查来回答这些问题；综合研究结果；最后，把新学到的知识重新放回公司长期积累的共同认知之中，也就是我们不断建设的专家系统。

这里最关键的其实是最后一步。

研究过程中学到的一切，最终都会回到一个共享记忆中，供其他人继续调用。

因此，如果你真的想构建一个人工投资者，它就必须能够完成研究流程里的所有这些步骤。

你可以想象，我们针对研究闭环里的每一个部分，分别构建不同的子 Agent。事实上，这正是我们正在做的事情。

我们为人类投资者必须完成的不同任务分别打造专门 Agent，而这些 Agent 调用的，是 Bridgewater 过去 50 年里积累下来的同一套知识与理解。

不过今天我们只介绍其中一个 Agent：负责“调查与分析”这一部分的 Agent。它要完成的是那种原本人类分析师可能需要几天甚至几周才能完成的深度分析工作。

我们把这个工具叫做 PAT，也就是 Pocket Analyst Tool。

这里需要先明确一点：PAT 并不是用来决定 Bridgewater 应该怎么交易的。它真正解决的是深度探索性研究，让投资者能够去研究以前因为时间和精力有限，根本没有余力追的问题。

PAT 从一开始的产品要求

PAT 从第一天开始的产品要求其实非常简单：它必须能够做人类投资者在调查和分析时所做的全部事情。

首先是数据。

PAT 必须能够搜索并读取 Bridgewater 内部所有不同类型的数据。既包括结构化的时间序列数据，比如几十年以来的股票价格，也包括非结构化数据，例如我们订阅的券商研究报告，以及公司内部自己撰写的备忘录。

PAT 必须能够搜索并理解这一切。

其次，它还必须能够使用人类分析师手里的所有工具，包括我们自己开发的可视化工具、诊断工具，以及用于评估各种指标想法质量的专有工具。

除此之外，还有一个对技术人员来说更有意思的问题：PAT 做的很多分析，如果让人类分析师完成，可能需要好几个小时。也就是说，这些分析本身非常复杂。

因此，PAT 产生的整个分析过程必须是完全可以诊断和追踪的。不仅人类要能够检查，后台运行的其他 Agent 也必须能够读取完整轨迹，理解每一个步骤，并确认每一个计算是否正确。

再往上一步，也是 Bridgewater 过去 50 年持续把知识写下来的真正价值所在：PAT 知道我们的全部上下文。

它可以访问我们的投资流程和分析框架。它知道 Bridgewater 的分析师应该怎样工作，因为这些方法，我们已经持续记录了 50 年。

最后，PAT 还必须能够学习。

而且它的学习不能只让某一个投资者受益，而要能够让整个公司的所有投资者一起受益。

PAT 今天已经不是一个原型产品。它在几个月前就已经在 Bridgewater 内部部署，目前每天有数百名投资者在使用它。

这形成了一个非常强大的改进飞轮：投资者用 PAT 做真实研究；与此同时，后台一直有 Agent 持续扫描这些交互，寻找 PAT 做错的地方，建立经过人类审核的 Benchmark；然后根据这些结果调整上下文以及 PAT 的 Harness。最终，PAT 得到的改进并不是只服务于某一个人，而是会让所有用户共同受益。

一个 50 年历史的对冲基金，怎么做出这种东西？

我经常被问到一个问题：一家已经成立 50 年的对冲基金，究竟怎么能做出你们马上就会看到的这种产品？

第一步，是你必须愿意主动打破自己原有的组织方式。

构建 PAT 的团队，本质上是一家孵化在 Bridgewater 内部的应用 AI 创业公司。它可以非常快速、灵活地行动，同时又能够调用整个公司的资源。

此外，我们还建立了多种角色混合在一起的团队：投资者、技术人员、科学家坐在一起，共同开发产品。

我认为，如果你想为专家用户打造 AI 系统，这是非常关键的。

投资者带来上下文和领域知识；技术人员带来系统架构能力；科学家带来严谨性。

要真正构建面向专家的 AI 系统，这种多角色组合的团队非常重要。

Bridgewater 内部本身就有数百名专家用户在使用各种 AI 工具，而不只是 PAT。这些专家每天都在产生反馈信号，告诉我们产品应该如何继续演进。

与此同时，我们还有一个非常强大的、能够不断复利的生态系统可以接入：50 年积累的共享数据、工具和方法论。这些东西过去是为人类分析师建设的，而现在也可以直接提供给 Agent 使用。

我们最终的目标，是构建一个完整的人工投资者，让它能够完成人类投资者今天能做的所有事情。

接下来，我把时间交给项目的投资负责人 Michael Ran，由他来演示我们做出来的产品，并介绍产品架构。

Michael Ran：PAT 实际是怎么工作的？

谢谢 Brendan。

我叫 Michael Ran，是 Pocket Analyst Tool 的投资负责人。我在 Bridgewater 工作了五年，最初加入公司时是一名技术人员，但大多数时间都在做投资相关的工作。

现在我主要关注的是：我们怎样把 AI 真正融入投资流程。

接下来，我直接通过一个 PAT 的 Demo 来展示它的能力，以及 Bridgewater 的投资者平时到底怎么用它。

屏幕上现在是 PAT 的首页，以及今天演示要使用的 Prompt。

这个问题大致是：让 PAT 研究最近中东冲突发生后，市场是如何反应的；再把今天的事件和历史上类似的情形做比较；最后，让 PAT 生成一些可视化图表，展示今天的情况和过去发生过的石油供应冲击究竟有多相似，或者有多不同。

这是 Bridgewater 在过去几个月中真实研究过的问题，而 PAT 已经被投资者实际用于加快这类研究。

一个容易被忽视的安全问题

不过在提交 Prompt 之前，我想先讲一个我们设计 PAT Harness 时遇到的很有意思的安全问题。

我们的出发点是：如果 PAT 想真正帮助投资者，它就必须能够访问投资者在研究过程中能够访问的全部信息。

但 Bridgewater 有一个现实情况：不同投资者拥有的信息访问权限并不相同。

举个例子，某位投资者可能有权限查看 Bridgewater 今天在全球各个市场里的实际持仓，那么他的 PAT 也必须能够读取这些信息。

但另一些分析师并没有权限接触这些内容。对于他们而言，我们同样必须确保 PAT 不会意外把这些高度敏感的知识产权或内部信息泄露出去。

所以，PAT 和 Claude Code 这种所有人共享同一套 System Prompt、同一组工具的 Harness 不一样。

在 Bridgewater，每个人实际上都有一个属于自己的 PAT 版本。它会根据这个人的访问权限决定什么能看、什么不能看。

具体来说，不同版本之间的差异，主要就是各自能够获得哪些 Context，以及能够调用哪些 Tool。

第一步：搜索世界与内部知识库

现在我们提交这个 Prompt。

分析开始之后，PAT 首先会搜索 Web，以及 Bridgewater 自己的非结构化数据仓库，以理解今天世界正在发生什么，并把这些事件放进历史背景中进行比较。

Web 搜索对于今天的聊天类应用来说，已经属于基础能力。真正形成差异的，是 PAT 能够搜索的非结构化内容规模。

我们有一个包含数百万份文档的数据库，内容来自世界各地，包括券商研究报告、公司财报电话会逐字稿、内部邮件等。

而且这个数据库几乎是实时更新的，每天都会新增数千份材料。

这又回到了刚才那个原则：如果 PAT 想真正产生杠杆，它就必须可以访问用户本人可以访问的一切，然后尽可能模拟这个用户实际会如何做研究。

第二步：搜索时间序列数据库

收集完背景之后，PAT 下一步会搜索我们的时间序列数据库，找出这项分析真正需要的数据。

这个数据库里有数千万条时间序列。Bridgewater 已经持续建设和建模了 50 年。

数据库既包括外部世界的数据，比如石油价格，也包括我们自己内部计算出来的概念，例如“我们认为 12 个月后的通胀会是多少”。

搜索 Agent 当然会使用传统的搜索技术，比如 RAG、Re-ranking 等。

但我们发现，一个真正产生巨大提升的东西，是在搜索流程中加入类似人类研究员的“检查和判断”。

什么意思？

当人类研究员寻找数据时，他们不会只看时间序列叫什么名字。他们还会看数据频率、使用什么货币，更重要的是，他们会判断数据的实际数值是否符合自己原先对这个世界的基本认知。

我们把这种推理方式加入搜索 Agent 后，搜索准确率从大约 50% 提升到了 90%。

第三步：先把研究问题问清楚

当 PAT 已经拿到了背景与数据，它会回到用户面前，提出澄清问题，有时还会建议一些额外值得研究的角度。

在开发 PAT 的过程中，我们逐渐形成了一个非常明确的认识：计划本身，就是分析。

如果我们能够得到一个高质量而且足够具体的计划，那么我们就有信心，可以稳定地执行这个计划并生成预期结果。

后面 Santi 还会更深入地讲这一点。

今天的聊天机器人会问澄清问题已经很常见，所以我们真正关注的并不是“有没有问问题”，而是这些问题本身有没有足够高的质量。

我们投入了大量时间和精力，去构建相关的上下文与 Benchmark，用来塑造这种能力。

我们会教 PAT 什么叫好的研究问题，什么叫差的研究问题。

这种来回互动，也能帮助人类把研究计划真正想清楚——因为人其实往往不会在规划阶段投入足够多的精力。

第四步：生成完整分析计划

所有模糊点解决之后，PAT 就进入规划阶段。

在这一阶段，它主要做三件事。

第一，列出整个分析最终要生成哪些 DataFrame。

第二，定义每一个 DataFrame 的 Schema。

第三，也是最重要的一点：明确这些 DataFrame 之间到底怎么连接、谁依赖谁。

从时间成本来说，规划阶段其实比较昂贵。但这是我们刻意愿意支付的成本，因为一个足够详细的计划，会在后面的执行阶段带来非常大的收益。

第五步：并行生成代码

计划锁定后，正式执行的第一步，就是生成代码。

因为我们已经有了非常详细的计划，所以每一个 DataFrame 所需要的代码都可以交给不同的子 Agent 并行生成。

之所以能这么做，是因为每一个子 Agent 都已经知道：自己依赖哪些 DataFrame；那些 DataFrame 的 Schema 是什么；以及自己最终要生成的 DataFrame 应该长什么样。

因此，一个只有 3 个 DataFrame 的分析，和一个有大约 30 个 DataFrame 的中型分析，在代码生成阶段所需要的时间可以非常接近。

第六步：执行、监督和纠错

代码生成完成后，我们就执行这些 Python 函数。

执行过程中，会有一个 Agent 负责监督。如果它看到运行时错误，或者看到一些明显不合理的数据，就会介入。

这里还有一个很重要的设计：PAT 分析最终计算出来的时间序列，会重新写回我们一开始读取输入数据的同一个数据库。

这件事很重要，有两个原因。

第一，PAT 产出的任何时间序列，从系统的角度看，和过去多年由人类上传的时间序列没有区别。

第二，更重要的是，一次 PAT 分析的输出，可以直接成为下一次 PAT 分析的输入。

这样就形成了一个环境：人类和 Agent 可以非常自然地相互利用彼此的研究成果，并继续在前人的工作之上积累。

第七步：像初级分析师一样主动复核

执行结束以后，就像你会希望自己的初级分析师在拿结果来见你之前先检查一遍一样，我们也要求 PAT 做同样的事情。

PAT 会检查已经计算出来的数据和生成的可视化结果，确认数字是否合理、图表是否干净。

如果发现某些地方看起来不对，PAT 会退回一步，诊断问题，修改分析，直到它自己认为结果足够可信，才把结果交给用户。

最终结果是一份交互式报告。

里面的可视化图表，看起来就和 Bridgewater 投资者自己平时制作的图表一样。PAT 使用的是同一套内部图表库，也会调用我们几十年来一直在维护的同一套文本模板。

用户可以放大或缩小图表，也可以把交互报告中的数据直接发送到内部图表工具里，再进行进一步修改。

PAT 怎么从用户互动中持续变聪明？

PAT 主要通过两种方式不断变好。

第一种，是 Brendan 前面提到的自动学习。后台会有 Agent 审查已经完成的对话，寻找 PAT 可以改进的地方。

第二种是更显式的学习方式：如果用户认为某一次和 PAT 的互动中，有值得系统学习的东西，他可以直接在这次分析里启动学习流程。

比如这里，用户只是要求换一套可视化方式。

注意，他并没有说原来的结果是错的，只是认为从另一个角度看数据，对回答当前问题更有价值。

如果用户觉得 PAT 从一开始就应该生成或主动建议这组图表，他可以点击“Teach”按钮。

这会启动一个 Agent，让它重新查看整个对话，寻找诸如行为错误、Context 缺口，或者本来可以提前预测到的用户引导行为。

用户可以修改 Agent 总结出来的反馈，也可以直接原样提交。

提交之后，后台首先会由一个 Agent 创建一个我们预期会失败的 Benchmark，以证明这个糟糕行为是可以稳定复现的。

随后，系统会不断迭代 Context Repository 或 Harness 本身，直到这个 Benchmark 通过。

接下来还要确认，为了让这个 Benchmark 通过而做的修改，没有把其他测试搞坏。

全部通过后，我们会在 Slack 收到一条消息，里面包含一个 Pull Request，以及 Agent 希望对 PAT 做出的具体修改。

这样一来，下一个人再拿类似问题来问 PAT 时，他从一开始得到的，就应该已经是更好的 PAT。

下面把时间交给 Santi，由他介绍技术实现。

Santi：把 Agentic Coding 当成“编译器问题”

大家好，我是 Santi，是 Pocket Analyst Tool 的技术负责人。

我相信现场很多人也和我们一样，正在构建 Coding Agent 产品。

而这真的非常难。

Coding Agent 很脆弱，也很不可预测，经常会犯错。运气特别差的时候，它们甚至会彻底跑偏，试图把你的数据全删掉，或者做出其他灾难性的事情。

所以，打造一个用户觉得“不错”的产品本身就已经不容易；让他们真正愿意把这个东西嵌入每天的工作流程中，就更难。

而我们是在一家对冲基金里工作，要处理和数十亿美元交易相关的问题。我们不能让一种凭感觉、靠“vibe coding”做出来的分析，成为整个投资分析的基础。

我的背景是编译器理论和编程语言设计。

编译器其实有一组和这里非常相似的要求：它必须高度确定、正确并且可靠。

例如在飞机控制软件里，你不能容忍一个 off-by-one error（差一位错误）。这里面对的问题有非常相似的形状。

编译器会把用户写的代码编译成 JavaScript 之类的目标形式；而 Coding Agent，则会把用户的 Prompt 或计划“编译”为 Python。

我们非常喜欢从这个角度看问题。

今天时间有限，所以我会重点讲这个，也希望大家可以把这种思路带回自己的工作中。

先把 Chat Agent 和 Coding Agent 分开

我们先看 Chat Agent。

它的目标，是让用户和 Agent 对“我们究竟要完成什么”形成一个共同理解。

这个 Chat Agent 是用 LangGraph 实现的。我们主要使用它的 Persistent State（持久状态）能力，它也原生支持取消和继续。

以前这些事情都是我们自己维护的，效果明显差得多。

Chat Agent 可以调用不同工具，包括刚才 Michael 提到的数据序列搜索、非结构化内容搜索等。每一种能力本身都是一次 Tool Call。

等 Chat Agent 确认自己已经掌握分析所需的全部数据，它就会制定计划，并调用一个子 Agent，也就是我们的 Coding Agent。

Coding Agent 最终会生成一个基于 Python 和 Pandas 的分析。

那么，为什么一定要把两个 Agent 分开？

我们很早就做出了一个判断：Bridgewater 的投资者本质上不是程序员，他们真正关心的是投资。

因此，我们决定让聊天界面只讨论投资内容，把代码完全隐藏在实现层里。

最终产品的效果是：Coding 只是实现细节。从聊天界面里，你甚至感觉不到底层有代码存在。

这种拆分还带来了一些意外的好处。

每个 Agent 拿到的 Context 都更干净，所以它们会自然地在各自任务上变得更加专业，也更容易持续优化。

同时，我们也可以更有针对性地设计整个聊天体验。

高质量领域 Context，比“通用聪明”更重要

Bridgewater 的投资领域 Context 质量非常高。

我们会教 Chat Agent 怎样像 Bridgewater 的投资者一样说话。这里面有大量行业和公司内部术语需要掌握。

最终，用户和 Agent 的对话，会很像两个 Bridgewater 同事在交流。

我们也允许投资者像开发者给代码库贡献代码一样，直接为 Agent 的 Context 作出贡献。Michael 刚才展示的 Teach 功能，本质上就是这个机制的一部分。

这里有一个很重要的经验：你的用户很可能比你更擅长写领域 Context。

所以不要太执着于“Context 必须由开发团队自己写”。降低 ego，让真正的专家直接参与贡献，往往更有效。

另外，我们并不是只给 Chat Agent 塞一大堆 Context。否则最后很容易变成一团信息密度很高、但并不像真正工作流程的模糊知识。

相反，我们会针对特定分析类型，给 Agent 明确的、一步一步的操作指南。

做到这一点之后，它才更像一个真正的产品：拥有可以依赖的稳定工作流。

Coding Agent：把分析计划看成“自然语言 Python 项目”

接下来是我个人最喜欢的部分，也就是 Coding Agent。

你现在看到的是它的高层架构图。

这里所有东西实际上都只是普通 Python 代码。整个设计受 LangGraph 启发，但这里并没有 Agentic Orchestration。

我们从左侧开始，也就是 Chat Agent 生成的 Analysis Plan。

整个计划会被拆成多个 Task。每一个 Task 大致对应一个 Python 函数，而这个函数负责计算出一个 DataFrame。

一个 Task 的 Schema 大致包括：名称、要计算什么的描述，以及最终 DataFrame 应该具有什么结构和语义信息。

我们的要求是：每一个 Task 都应该能够通过 LLM，被确定性地“编译”为代码。

也就是说，两个不同 LLM 对同一个 Task 生成代码后，这两段代码只要运行，语义上应该是等价的，最后得到的数据值应该完全一样。

因此，我们眼里的 Analysis Plan 并不像 Claude Code 里那种普通 To-do List。

我们把它理解为一个用自然语言写出来的 Python 项目。

因为计划足够详细，后面的代码生成就可以采用一些更高级的技术。

并行代码生成：任务越多，不一定越慢

第一步，我们把整个计划拆成 Task，再并行调用 LLM 生成代码。

由于计划已经足够详细，即使某个可视化 Task 位于整个计划的最后，它也已经明确知道自己最终需要从前面尚未完成代码生成的数据加载任务那里获得什么输入。

和 Claude Code 相比，在使用同样的 Context 和同一份计划时，我们平均能够把代码生成速度提高大约 4 倍。

更重要的是，这个方案还具有一种很强的扩展特性：20 个 Task 的计划，生成代码所花的时间可以和 3 个 Task 的计划接近。

不相信“一次生成就正确”，而是在架构里强制验证

现在我们已经得到代码，接下来要执行。

理想情况下，你当然希望直接运行代码就结束。

但现实是，今天的 LLM 在我们的任务上还不够完美，所以通常无法一次就生成完全正确的代码。

因此，我们会拿到原始 Task，以及根据 Task 生成出来的代码；运行代码；再把运行结果和原 Task 的要求进行对照；判断是否正确；如果不正确，就修改代码，然后继续执行，直到完成。

对代码首先会进行静态分析，然后识别出整个 DAG（有向无环图），接着并行运行 Validation Agent。

例如，两项互相独立的 Task 可以同时被验证。

一个 5 个 Task 的计划可能最终形成 3 层验证结构，而一个 20 个 Task 的计划可能也只需要 4 到 5 层。

这里最重要的一点是：我们是在系统架构层面强制正确性。

这里仍然没有 Agentic Orchestration，而是普通的 Python 代码。

所以 Guardrail 非常硬。Agent 不可能“忘记”做验证，因为架构强迫它必须验证。

最终结果是，当我们针对任意计划运行测试套件时，大约 95% 的情况下，两个不同 Agent 最后生成出来的代码结果是完全一样的。

也就是说，我们实际上得到了一个接近确定性的 Coding Agent。

而一旦 Agent 具有这种高度可复现性，后面无论是扩展系统、做 Hill Climbing，还是做评估，都比依赖“感觉”或者 LLM-as-a-Judge 的评测方式可靠得多。

执行层：不要让 LLM 自己负责运行代码

最后再讲一个话题：Execution Layer。

通常 Coding Agent 会自己调用自己生成的代码。它生成代码，然后通过 Terminal 自己执行。

这种做法有几个明显的问题。

首先，Tool Call 会带来比较高的延迟；其次，就像大家都经历过的那样，Agent 有时会在执行过程中迷路。

所以我们的做法是：代码由系统替 LLM 执行，而不是让 LLM 自己执行。

我们使用经典的静态分析 Pipeline，自动向 Python 代码里注入缓存标记，避免重复执行，并把代码放进自定义框架里运行。

我们做过一个 Benchmark，对比 Claude Code 自己调用代码和 Pocket Analyst 的执行方式。

PAT 更快，因为它不会重复加载同一份数据，也不会重复执行已经计算过的中间结果。

但真正的优势甚至不在第一次执行，而在第二次。

例如，我们只把整个计划最后一张图表的名称稍微改一下。

Claude Code 会重新运行几乎所有代码，所以执行时间和第一次差不多，尽管它修改代码本身的速度会更快。

而 Pocket Analyst 在第二轮中，代码执行几乎是瞬间完成的。

这意味着，当投资者使用这个产品时，可以对自己的分析做很多小调整，而不需要承担传统迭代流程里巨大的重复执行成本。

最后的两个核心经验

时间差不多了。我们其实学到了很多东西，但今天只能讲其中一部分。

第一个最重要的经验是：我们非常相信 Agent 应该专业化。

我们并不太相信那种通用、无所不能的强大 Agent。

这种 Agent 可以做出非常酷的 Demo，我相信我们很多人都展示过类似东西。

但如果你想把它真正变成一个每天都会使用、而且用户可以依赖的稳定工作流，就会非常困难。

因此，我们通常从非常狭窄、明确的工作流开始，然后对这些工作流建立大量 Benchmark，再围绕这些 Benchmark 持续 Hill Climbing，把性能一点点推高。

等这些专门 Agent 做好之后，你当然可以再把它们组合起来。

但如果一开始先做一个很宽泛、很通用的 Agent，再想倒过头把它变成稳定可靠的专用 Agent，难度反而更大。

最后一点更像一个思考题，也是我希望大家可以带回去的一件事：

把 Agentic Coding 看成一个“编译器问题”，而不是一个“Agent 问题”。

编译器已经存在了几十年，在如何更可靠、更正确、更确定性地生成代码这件事上，已经积累了大量成熟技术。

我们非常愿意继续和大家交流这些问题。

最后也感谢直接参与这个项目的团队成员。还有很多其他人也为项目作出了贡献，这里展示的是最直接的核心团队。

谢谢大家。我们接下来会在外面参加 AMA，也非常欢迎大家来聊聊，看看你们是否也对这些问题感兴趣。