开场与嘉宾介绍
我是 Scott Worland，Norm AI 的首席技术官。很荣幸今天能和 Blackstone 的首席技术官 John Stecher 同台。我听说 John 基本上有三份全职工作：负责 Blackstone 的全部技术、为公司的投资提供建议，还为旗下投资组合公司提供技术方面的支持。我漏了什么吗？
没有，概括得完全准确。
这工作真不错。如果你还不知道 Blackstone 是做什么的，那你大概走错会场了，我就不展开了。不过你可能还不了解 Norm。简单说，我们是一家专注法律和监管领域的 AI 公司。我们的企业级 AI 平台已经部署在全球一些最大的金融机构中；我们还有关联律所 Norm Law，律所也使用我们的 AI 平台。
怎样把 AI 智能体用对
从去年年底开始，尤其是今年，大家都在竞相摸索如何部署 AI 智能体。我很想听听 Blackstone 怎么看这件事，以及你们怎样确保把它做好。
这场竞赛确实已经开始了。技术进步很大，尤其是从去年二三月以来。比如上下文窗口变大了，模型可以持续处理任务更长时间，因此人们能创造出更多价值。
数据战略要先行
我们一直很关注的一件事，也是我经常建议并协助投资组合公司关注的，是要想把 AI 智能体做好，首先得把数据这件事理顺。很多公司一门心思想全面拥抱 AI、尽可能多地造智能体、从中挖掘价值，但最大的障碍之一就是缺少连贯的数据战略：要把数据从交易系统中迁出来，放到智能体能够访问、方便管理和调用的地方。否则项目就会失败。
这也是我们投入很多精力的重点。作为大型资产管理公司，我们有海量的专有数据和公开数据，彼此交织。我们必须把它们从现有系统里迁出来，放到真正能供 AI 使用的地方。
直通式处理依然重要
第二件事其实和 AI 本身无关，但可以借助 AI 找到更好的做法：直通式处理（straight-through processing）依然重要。我一直很惊讶，大家好像都把智能体说成世界上最重要的差异化优势。我自己用 Factory 等工具在公司里写代码，发现更值得做的是花时间让智能体帮我构思方案、弄清大家现有的工作流程，然后真正写代码来优化直通式处理；再在必要之处引入智能体，让它补上过去由人做判断的智能环节，处理各种繁琐工作。这两件事是我每天花很多时间思考的重点。
从智能体的角度，最重要的是退一步想清楚：哪些工作值得交给智能体做得更好，从而释放投资专业人士、财务人员和工程师的脑力，让他们去做更高价值的事？软件开发生命周期里有很多这样的工作，比如编写测试用例，包括功能测试和性能测试；管理版本，以及维护应用底层的库。这些是每个工程师都头疼的事。我做这一行 27 年了，一直很讨厌这些工作。让智能体去做这些……
Norm 早期的工作流方案
Norm 成立于 2023 年。那时距离 GPT-1 大约三四年，但思维链还没出现，算是技术发展的一个有意思阶段。我记得第一次全员团队聚会时，我们在斯坦福待了一周。具体时间线我可能记错了，但感觉上下文窗口从 4K 到 8K 再到 128K，多模态也接踵而来，一切像是同时发生。后来前沿进展有一段时间慢了下来。
所以在 2024 年初，很多公司包括我们，都在尝试把模型接进工作流和生产软件。我们因此在系统各层加了很多结构：比如把需要加入模型上下文的内容按特定方式处理，安排模型调用顺序，检查结果的一致性，最后把所有内容提炼成有用的输出。整体上变成一个很大的“映射再缩减”问题。我们给智能体搭了很多脚手架，对模型运行方式也规定得很细。这更像一套工作流。
智能体让旧代码过时
这种做法让我们得到质量很高、非常准确而且一致的结果；在监管领域，这点特别重要。为了给这个庞大系统做回归测试，我们积累了一大批评测样本：数万条由专家手工标注的案例。
当智能体开始真正可用时——我说的智能体，就是给大语言模型一套工具、一个目标，以及一种核验目标是否达成的办法，让它自己找出最好的完成路径——我们立刻把这些基准样本拿来测试更具智能体特征的方法。很多人都经历过那一刻：盯着团队认真写下的几十万行代码，突然意识到其中大部分已经过时，甚至成了阻碍。
我们很快采取行动。我召集工程领导团队，租了一辆 Sprinter 面包车，开到纽约州北部。当时刚经历一场大暴雪，我们住在 Airbnb。我说：“先把 Norm 放一边。以我们现在掌握的知识，如果从头开始，会造一个什么样的平台？”最后我们整理出一套规格，要求平台能做到两件事：一是给客户提供智能体体验；二是让 AI 能作为共同开发者，与我们自己的工程团队协作。从那以后我们就一直按这个方向推进。
金融服务领域的评测
我觉得你提到了关键点。你刚才说到评测。如果在金融服务领域工作，智能体交付成果的质量门槛非常高。必须认真设计评测集，用来检验智能体执行的工作以及输出是否合理、一致、可重复。我见过模型版本一变，答案就不一样，信息准确度也会发生偏差。要有好的评测，才能持续运行测试、真正衡量系统健康状况，这对成功至关重要。
底层运行框架变了，答案也会变；数据变了，答案同样会变。所以在金融服务领域，对准确性的责任要求就这么高。怎样达到这个标准，是我们一直在思考的问题。
“苦涩的教训”
这正好引出我们一直在谈的“苦涩的教训”：人们凭聪明才智、针对问题手工设计的系统，最终往往会被能随着算力扩展的系统超越。Rich Sutton 在 2019 年谈过这个观点，但类似的历史从神经网络开端就有了。回到 20 世纪五六十年代，Rosenblatt 的感知机曾被《纽约时报》或其他媒体称为第一台能够拥有原创思想的机器。专家系统与联结主义之间的争论也有段很有意思的历史，在英国甚至闹上了法庭，不少 AI 研究因此被拆散。
还有个有趣的例子：到了 80 年代，IBM 翻译实验室的一位负责人说过一句很符合“苦涩的教训”的话：“我每解雇一位语言学家，模型就会进步。”重点是，与其让语言学家试图穷举语言规则，不如基于概率训练统计模型。来到今天，我们一直能看到类似的情形。谈到 Blackstone 的路线图和团队提出的项目，你是怎么把这个教训放在心上的？
投资回报，以及何时等待下一代模型
很多问题本质上都很简单：只要给足算力，未来某个时候，硬件和软件就能解决它们。Elon Musk 也从能源等角度谈过这个问题。但怎么把这个宏大图景拉回现实？我和团队工程师、产品人员、SRE 团队以及业务相关方共事时，花很多时间界定要做的事情能带来什么投资回报。
无论是构建智能体、整理数据、做仪表盘还是交易平台，我都会看团队提出的需求能创造多少回报，以及今天把它建出来的真实成本，然后权衡。有时我会判断：模型六个月后就足够强，我们也会有充足算力，那今天解决这个问题可能不值得；不如等新模型成熟些再做，成本会更低。如果应用并不急着上线，今天做和六个月后做也不会带来明显的业务价值提升，我们过去确实做过这样的决定。
这种取舍我们经常做，也经常思考。另一方面……
快速做出概念验证
另一方面，也不能等太久才开始做东西。你总可以一直等新模型、新技术。现在各种软件开发工具很厉害，只要善用，就能很快从一个想法、和产品人员或相关方一起梳理规划，走到写代码并做出可用的概念验证。所谓可用，就是别人能点进去、能交互的东西。它还没经过网络安全审查，也没完成我们这个行业要求的其他生产上线流程，但做出 POC 或 POV 可以非常快。
我经常鼓励工程师赶紧做出 POC，别花时间做 PowerPoint 或纠结其他事情。大胆用 token；我觉得一味计算 token 是个误区，应该关注创造的价值。先做出价值、做出 POV，拿给人看，快速迭代；不需要时就扔掉。这样花的时间和钱都会少很多。这是我们解决问题的一种重要方式，也让我们能用更短的周期来应对算力增长和工具进步。
很有意思，你提到了很多大家都会想的问题。回到 2023 年，我们这群人刚开始讨论要做什么时，就知道“苦涩的教训”，也讨论过怎样避免陷进去。现在我越来越清楚，这其实是一个连续的光谱，并非非黑即白，也不可能造出一套完美技术，把前沿不断出现的新东西全都整合进来，同时还能不丢弃任何东西。
真正的问题是：哪些地方值得重投入，哪些地方应该保守投入？正如你说的，我们今天需要一些东西，但也知道某些投资可能会很快过时。比如围绕智能体基础能力，我们建了相当复杂的系统，包括运行框架、沙箱、出站流量机制等；与此同时，也得确保前沿实验室或第三方推出新东西时，我们能及时接入。所以关键在于什么时候更新，而这正是最难的事情之一……
更新到 Claude Code
关于什么时候更新，一个很好的例子是我大幅升级到了 Claude Code。关键不只是它突然带来了一些我们职业领域里特别厉害的新工具，而是它让我开始相信，我们真的能实现具有普适性的能力。我之前对此有些怀疑。Claude Code 能写代码，也能执行代码；我们实际上是在一种可验证的方式下运行一台计算机。那一刻我意识到，我们已经具备了真正通用智能的所有要素。只要能大规模做到这一点，大多数知识工作，甚至知识工作以外的事情，理论上都能完成，我们现在已经看到一些迹象。
这也是为什么现在的 AI 助手很惊人：你可以提出一个从未出现过、完全超出分布的问题，它能在后台启动计算机并把事情办好。对消费者来说很棒，在企业里我们也开始看到这种能力。
这让我重新思考哪些地方要重投入。智能体本身仍值得投入，但正如 John 刚才提到的，数据采集、提炼、作为模型状态提供数据的方式，以及基准测试和评估，也同样重要。以律所为例，我们从零开始建立它，律所和 Norm 一起成长。我们直接与律师合作建立基准和评测。与其按传统路线图思考“什么时候造出能做这三件事的智能体”，不如建立一张评分卡，衡量智能体甚至人类在不同维度上完成任务的表现，并持续观察系统是否进步。
系统做通用改进时，我们应该看到律师工作流程相应改善；同时也不想回到一开始给系统加了太多结构的状态，因为我们发现去掉那些前置结构，表现反而更好。
对。还有一点要考虑：现在可以非常快地做出很多概念验证和价值验证……
难点在于真正投入生产
……但我仍然认为，很多开发真正费力的部分是把东西送进生产环境。比如搭建能在金融服务公司或其他企业现有基础设施中运行的基础设施。这是很多人低估的挑战。如果你在销售 AI 工具，我可以告诉你，落地的另一面确实很难，我经常要处理这些问题。
另一件事是网络安全和可支持性。我注意到智能体现在越来越擅长写软件，但必须确保代码真正可追踪，并接入 SRE 平台，让系统在生产中可监控。这些都是我希望大家认真考虑的事。很多人还没开始用智能体大规模扩展，但他们终究会这么做；从我的角度看，这些问题始终需要放在心上。
仍需人工审查的部分
有道理。我们的做法是，代码库里有些部分仍要求人类全程监督，包括设计、构建、代码所有权，甚至任何代码变更的批准。这些是核心基础能力。可以在它们上面构建其他东西，但上层系统不能未经人工审查就改动这些底层系统。
正如你说的，数据安全对我们来说和快速交付一样重要，甚至更重要。具体做法取决于你所在的领域，是消费者产品，还是像我们这样处理高度敏感数据的业务。我们必须围绕它建立大量基础设施，不能让能力跑到这些技术栈的安全保障前面。有时有人给你看一个很酷的演示，确实令人兴奋，但你也会担心：“这很厉害，可要达到这种能力，我们得暴露很多目前还不能开放的东西。”所以始终要做取舍。
我们会在这些核心部分重投入，在前沿还在持续进步、可能很快变化的地方保守投入。同时要留出接入通道。我今天早上跟团队打了个比方：平台里应该有能让前沿能力流进来的管道，而不是筑起大坝，让智能进来了却进不了技术栈。再说一次，这是一条连续光谱，我们会有做对的地方，也会有做错的地方。要一直留心、多讨论，把核心部分牢牢管住，同时也要愿意拆掉重来。我觉得大家现在越来越擅长这件事了。我认为这是最大的变化之一……
重建，而不是一直维护
……我做这行 27 年了，有时觉得像过了 100 年，有时又觉得才五年。和十年前相比，如今编写软件的能力发生了实质性变化。十年前，做出一款软件要投入大量时间、精力、金钱和人的智力资本，几乎像是船一旦出海就回不了头：设计好、开始写代码后，就只能尽可能一直用下去，直到抵达大洋彼岸。
如今我已经很习惯这样一种想法：很多内部应用可以直接丢掉。为了某个时间点的某个用途把它做出来，同时也要明白它可能会消失，而且现在消失得比过去快得多，然后再考虑下一步做什么。
对我或任何优秀工程师来说，一个应该不断问自己的问题是：要不要重写这个系统？重写的成本是不是比继续给当前版本升级更低？十年前没人会想到这个问题。那时如果你说要重写内部应用，CFO 大概会觉得你疯了。如今这完全是值得认真考虑的事，因为从头做一个新应用最终可能带来更多业务价值。我也鼓励大家这么做。听起来你们 Norm 已经做了不少。
是的。以前昂贵的东西现在变便宜了；如果不及时跟上这个变化，就会错失机会。你说职业生涯有时像 27 年、有时像 5 年或 100 年，真形象。如果你过度押注某个东西，比如六月的技术，到了十月再看，仿佛已经经历了十年的技术进步。
结束语
很好，我们大概只剩一分钟。最后还有什么想说的吗？
如果要给听众留下一点收获，我想说，这些话题都很有意思，但让我兴奋地去工作的，是我又能回到工程实践。我很珍惜这一点。我曾在 IBM 做了十年硬核底层工程师，用 Notepad 和 VI 给 RISC 机器写指令级代码，那非常棒，也特别 geek。现在没人再做那样的事了，但我仍怀念那段时光。
随着职业生涯进阶，每天亲自写代码的门槛会消失，或者变得更难跨越。比如处理流式数据，光是启动项目就要面对很复杂的脚手架。AI 让我重新燃起了动手构建的热情，因为我并没有忘记如何设计系统。很多工程师也是这样：他们在行业里干了十年、二十年、三十年，理解系统设计的复杂性，而这部分知识并没有改变。现在他们可以借助这些新型智能体把知识表达出来。
所以现在无论是创业、在公司工作，还是构建软件，都令人特别兴奋，因为我们可以创造一个全新的世界。这就是让我兴奋的地方。
非常感谢，今天能来很荣幸。
是的，谢谢你们邀请我们今天来这里。我很感激。