从 PHP 到 Google Agent 负责人：重新思考判断、审查与数据

在本期节目中，Eira May 与 Stack Overflow 平台工程总监 Peter O'Connor 与 Andi Gutmans 探讨了 PHP 民主化网页开发与当下 AI 智能体民主化软件开发之间的脉络联系。Andi 认为，每位个人贡献者都在成为"一支 AI 智能体团队的负责人"，并深入探讨了这如何重塑代码评审、面试方式，以及人类判断与 AI 智能体判断之间的平衡。他还解释了自己为何认为最大的瓶颈已不再是模型本身，而是如何将组织的数据整理成 AI 智能体真正能够进行推理的状态。

访谈涵盖了 Google 如何改变自身的面试流程，评估候选人如何借助 AI 智能体进行推理和引导，而非考察他们独立手写代码的能力。

探讨了"人在环中、AI 智能体在环中、AI 智能体在环外"这一框架，用于判断评审实际需要在何处发生——以及为何这本质上是一个风险管理问题，而非对 AI 的信任问题。

用 Waymo 安全数据与感知能力之间的差距作为类比，解释为何组织（和个人）有时会抗拒 AI 智能体的自主权，即使数据表明这样做并无必要。

介绍了 Google 的"无界数据湖仓"概念，以及从人类数据管理向 AI 智能体驱动本体构建的转变。

在 LinkedIn 上与 Andi Gutmans 建立联系。

在 LinkedIn 上与 Peter O'Connor 建立联系。

大家好，欢迎来到 Leaders of Code 节目。这是 Stack Overflow Podcast 的一个环节，我们邀请资深工程领袖齐聚一堂，探讨他们正在做的工作、如何组建团队，以及目前面临的最大挑战。我叫 Eira May，是 Stack Overflow 的 B2B 编辑。我和我的同事 Peter O'Connor 在一起，他是 Stack Overflow 的平台工程总监。大家好，Peter。

你好，一切顺利吗？

很顺利，周一感觉还不错。今天我们有一位非常期待的嘉宾。我们邀请的是 Andi Gutmans，他是 Google Agentic Data Cloud 负责人，同时据我了解，PHP 3 的诞生背景是一个大学课外学分项目，而如今 PHP 已成为了网页开发的基础。Andi，欢迎来到节目。

嘿，谢谢你们邀请我。

非常感谢你来参加。我想先问 Andi 一个问题，然后交给你和 Peter 来主导后续对话。你曾帮助构建工具，让那一代网页开发者能够实现"写完代码就上线"的体验。那么从你的角度来看，向 AI 智能体时代的转变感觉如何？基于你的经历，这是一次巨大的变革，还是更像一种自然的演进？

对我来说，这更像是一种自然的演进。当年我们做 PHP 时，真正令人兴奋的事情之一是我们真正让网页开发民主化了。实际上，当年非常重要的一点是，使用 PHP 构建网站不需要你是计算机科学专业毕业。只要你稍微懂一点技术，就能真正建网站。在我的职业生涯中，甚至有医生告诉我："哦，我用你们的语言为我诊所建了一个网站"等等。所以我认为那是一个非常关键的时刻，我们让网页开发对所有人开放，而不仅仅是计算机科学专业的人。我认为你可以把此刻看作一个非常相似的节点——AI 智能体正在让众多从业者能够实现非凡的成果。

我妹妹不是技术出身，她学的法律，但她在用 Lovable 这样的工具建网站，建出的网站非常棒。所以你可以这样理解，这就像是 PHP，但几乎在每个维度上都好得多。另外一个真正重要的维度是信任和安全方面——在 AI 智能体开发中，最佳实践实际上可以由 AI 智能体来驱动了。而在我那个年代，非计算机科学专业的人建网站时出现的一个问题是，他们可能会构建不安全的网站，或者写出大量糟糕的代码。所以我们现在拥有的这一整个新台阶真的很令人兴奋。

有意思。从平台工程的角度来看，Andi，我们是在为这些开发者构建工具。让他们的生活更轻松。当我们试图让他们更轻松时，在思考如何对待 AI 以及如何正确引导它、让人们正确使用这些工具方面，你有哪些原则？你有没有一些护栏或建议，比如"如果你想正确地做这件事，这里有一些模式可以遵循"？你是怎么思考这个问题的？

是的，不，这是一个很好的问题。我认为用 AI 开发和使用 AI 之前开发，需要关注的东西是一样的。你是否达到了正确程度的信任？你是否得到了正确的结果？安全、合规——所有这些事情比以往任何时候都更重要，甚至更加重要。成本也很重要，确保它易于使用。所以我想说这些维度在方式上可能非常非常相似。

但现在的变化是，AI 智能体可以自主完成大量工作，所以当我们思考护栏以及如何确保我们以正确的方式得到正确的结果时，我们必须以一种略有不同的方式来处理。但我认为，真正重要的根本性东西仍然是一样的。这就是为什么确保你有正确的数据来激活这些 AI 智能体是非常重要的，你需要正确的决策机制来控制风险——什么时候是人在环中？什么时候是 AI 智能体在环中？什么时候是 AI 智能体在环外？你需要决定你想如何运作，但这实际上与过去在其他维度上需要做出的工程决策并没有太大的不同。

确实。很高兴听到数据很重要，确保我们正确引导事物，而且人类仍然很重要。我这边经常听到工程师们的一个完全可以理解的担忧是，代码工艺对他们来说非常重要。所以当我让一个 AI 智能体来做这件事时，它可能不会完全按照我想要的方式做，因为它没有严格遵循我喜欢的模式。在你看来，代码工艺中的模式是否也同样重要？还是我们应该退一步说，"也许这已经不像以前那么重要了？"

是的，我的意思是，即使在 AI 智能体开发之前，你用什么语言编程也没那么重要。当然在某种程度上是重要的，但真正重要的是你是否理解业务问题？你是否构建了合理的架构？你是否有可扩展的运维能力？所以实际情况是，因为你过去需要做大量手工编码，你可能花了 80% 的时间在编码上，只有 20% 的时间在其他这些事情上。而现在你可以把更多时间花在实际确保你得到正确的结果上。

所以我这样想这个问题：价值现在只是转移到了确保你正在运用你的判断力来引导 AI 智能体。你还要确保你以适当的方式审查 AI 智能体的工作。例如，我写了点代码，AI 智能体为我构建了一千个测试，然后我让另一个 AI 智能体批评这些测试，我发现这些测试实际上不太好，我不得不改进它们。所以这仍然需要我的判断。只是我作为其中一部分做的编码工作减少了，而做了更多的设计和编排工作。我真正这样想的是：现在每位个人贡献者都成为了一支 AI 智能体团队的负责人。

有意思。我认为这是一个非常好的思考角度。我非常喜欢 AI 智能体团队负责人这个想法。你认为一个人需要拥有怎样的知识广度才能胜任这份工作？因为当我想到团队负责人时，我说的是一个资深的人。我们如何确保人们具备这些技能？我们会不会遇到人才 pipeline 的问题？会不会遇到技能问题？

我认为这个问题会自然消解，因为我认为随着你思考孩子上大学、学习计算机科学等等，我们学习计算机科学的方式也会改变。当然，对于人们来说，了解一个系统是如何构建的、如何运行的、如何扩展的，这些判断能力仍然至关重要。所以很多这些东西还是一样的。但如果你想一想，他们实际上可以承担比现在手写代码更复杂、规模更大的大学项目，使用智能体。所以我认为自然发生的事情是，大学生毕业时就已经会在大学期间获得这种超级能力，而且他们已经被训练成智能体的团队负责人。所以我确实认为这只是事物运作方式的自然演变。并不是说我们不需要计算机专业毕业生进入劳动力市场。

是的，我非常非常同意这一点。我认为我在一个播客上谈过我自己，实际上做了一次关于面试技巧的采访。我说，我们真正需要关注的最大变化之一，不是你如何很好地解决某个抽象问题。我更想听到你围绕它的推理过程，我想了解你会如何在更大规模上编排那个问题？这很难。

是的。顺便说一下，我们正在改变我们的面试流程。所以不再是让工程师来手写一个快速排序算法然后我们看他的代码。实际上是给他们一个机会，让他们使用 Gemini、使用智能体，给他们一个问题，看看他们如何处理它，如何思考，如何推理问题，他们实际上是如何引导智能体的。所以我认为这只是我们有机会在工作中使用智能体的自然演变。

他们再同意不过了。对我来说，这也揭示了我在面试中不断看到的一个根本性东西——一个有天赋的人，他们愿意尝试和学习。他们有一种活力。你实际上可以看到他们在解决问题，你可以了解他们的设计思路空间。这真的令人兴奋，而不是"是的，好的，太棒了。这是第 20 个我做过的快速排序。""好吧，不赖。"

是的，没意思。那么，也许退后一步，你稍微谈到了你做过的 PHP 工作，以及我们如何尝试让不会写代码的人重新写代码。我不确定你是否知道，我相信你知道，但我会说，我最近读到 Linus Torvalds 的一句话，他说，"嘿，工程师们……"我转述一下。他说，"嘿，工程师们担心他们不理解自己写的代码。"他的回应是，"他们从来就不理解。"你最近听说过这个吗？听到"你知道吗？你从来就没有真正了解过你写的代码。"这句话对你有什么意义？这重要吗？

是的。我想说，大多数在大型项目上工作过的工程师，从来就没有能力 100% 理解代码。他们大致了解他们正在工作的那部分代码，也许还有一些相邻模块，但也许 Linus 从头到尾都理解完整的 Linux 内核。但在大多数企业环境中，通常没有一个工程师知道每一行代码。所以我认为在某种程度上，环境就是这样。

我实际上认为现在有趣的是，使用智能体进入一个你不熟悉的代码库，真正理解它、浏览它、理解你可以在哪里进行修改，我认为这实际上是一个很好的机会，在某种程度上会推动更高的质量。我仍然认为在很多情况下仍然需要人类代码审查。我的意思是，在 Google，我们有人类代码审查和智能体代码审查。我们几乎两者都需要。所以我们确实需要人类判断，但我们已经看到，有一类 bug 智能体有时更容易发现，因为它们可以浏览比人类能看到的更广泛的代码库。

是的，这真的很有趣。这让我想到，我们如何确保我们在代码审查或评估正在被修改的内容上花费正确的人类工作量，而不是智能体？我的意思是，就个人而言，我自己凭感觉编程了一些东西，这实际上很有趣，但如果你只是在审查成百上千行的 PR，你的脑容量就会耗尽。如果我在不同上下文之间切换，就更难了。当你想说"听着，人类确实需要审查某些东西"时，你们是如何处理的？你如何确保他们有正确的能力来做这件事？

听着，我认为就像工作中的任何事情一样，没有人会 100% 的时间审查所有内容。所以你要在自己的判断上决定哪里需要审查，哪里不需要审查。这就是关于"你在哪里需要人类参与、在哪里可以使用自主智能体"这个整体问题。所以我认为这是一系列情况。例如，如果你正在处理一个非常敏感的代码，可能涉及安全令牌之类，你可能希望人类专家也看一下。但是例如，如果是 CSS 和 HTML 的变化，而你准备好或也在使用你的智能体做安全审查，实际上很可能你使用智能体会发现比让某个人来做完整审查更多的问题。

所以我认为这一切都是风险管理的问题，有些是感知问题。如果你想想 Waymo，人类乘坐 Waymo 发生伤害性事故的概率比乘坐 Uber 低 80%。但大多数人仍然觉得座位上有个人类司机更安心。我让我的女儿坐 Waymo，因为我知道数据。所以我认为这也有那个因素在里面，那就是替代方案也不是 100% 无懈可击的。所以你基本上必须使用你的判断力。

是的，我最近读了一篇文章，关于 Waymo 如何在某些地区继续运营的一些问题。我的意思是，人类车祸是真实存在的。

所以是的，我们在 Stack 采用 AI 时也有过同样的讨论，这是一个合理的担忧。我怎么知道 AI 会创建无懈可击的代码或最佳代码？第一步是退后一步说，"好吧，我们一直在写代码。我们会犯错吗？"确实发生过。我喜欢风险影响那种感觉的想法。你必须知道你在哪里可能有高风险，但如果影响很低，你在乎吗？但如果是安全，影响很高，让我们对此非常谨慎。

是的。安全不仅涉及代码，还涉及它如何部署、如何管理。你有多层防御。然后在防御侧使用智能体也是我们看到越来越多进入生产环境的另一个部分。

是的，当然。在防御方面，这始终是一场军备竞赛。所以完全理解。你能告诉我一些 Google 的实际例子吗，如果你可以分享的话，你实际运行了多少个智能体？如果我是一个开发者，一个团队开发者在一个项目上工作，智能体在 Google 无处不在吗？我只是一个被束缚的工程师吗？在那里工作现在是什么感觉？

是的。我的意思是，当然，作为一家 AI 优先的公司，我们让 AI 超级易于被员工使用，无论是在编码方面还是仅在 Gemini enterprise 上处理工作相关的事情，比如日历或电子邮件或支持。所以我们确实让所有员工都能使用 AI。但坦白说，这与当今企业可以做的没有太大不同。他们也可以获得所有这些能力。我认为我们在哪里找到了很多成功，是在真正用 AI 在内部构建这些更自主的智能体。例如，我们的网站可靠性工程，我们使用智能体，我们在客户支持中使用智能体。我们在安全方面使用智能体，确保我们主动识别和修复漏洞，而且比过去快得多。所以我们做了很多事情来使用智能体，真正减少人类的苦差事，同时也加快成果。

听到这些真的很酷。我认为有太多地方你可以着手，我们不想做那些工作，而有其他我们更愿意做的工作。所以我完全理解。当你想到减少这种苦差事时，你在哪些地方仍然看到差距，我们需要，"嘿，在某些领域我们仍然没有用 AI 真正解决问题，我们需要投资那里。"

我认为，如果我们看看当前的模型，无论是 Gemini、Opus 还是其他模型，它们已经处于一个非常好的状态，能够真正自动化大部分企业工作流。所以我的看法是，我们现在不再面临严重的模型问题。我认为我们面临的挑战之一——这也是我投入大量精力的方向——是：好吧，为了让 AI 智能体能够以高度的信任和自主性采取行动，你需要理解你的数据...抱歉，是你的数据存储阶段。你需要理解这些知识，以及它如何与这些工作流相关联。所以我们现在看到，重点很大程度上放在了一件事上：如何让 100% 的数据都能被 AI 激活。传统上，你只会激活很少一部分数据用于分析。

那只是一小部分结构化数据，但现在变成了全部结构化数据，也包括运营数据。还有非结构化数据，无论它存储在对象存储还是其他地方，比如图片、PDF、合同等，然后确保你对数据的语义及其与业务问题的关系有足够的理解，以推动产生结果。这确实是我们投入大量精力的方向——模型当然会继续变得更好，但我认为目前的关键瓶颈之一是：我们如何确保数据能够以最佳方式被 AI 激活，从而推动最佳结果。当我考虑最佳结果时，它既关乎最高质量和信任，也关乎降低 token 使用量和成本。

这确实很有力量，去思考我们拥有的所有数据，而我们从未将它们连接起来。我想到过去做很多软件工作时，通过 API 连接外部系统来拉取数据，那从来不是光鲜亮丽的工作。而今天我感觉得到了证明。把数据汇聚在一起实际上很重要，但它仍然处于各自的孤岛中。所以把它拿出来真的很难。在企业级规模上连接这些数据，目前最大的挑战在哪里？因为我们看到的最大问题之一就是企业级意味着企业级的权限和访问控制。这是不是你们最大的重点领域之一，确保访问权限也到位了，还是说挑战在别处？

是的，完全同意。首先，我认为现在利用 AI 智能体激活所有这些数据是一个很好的机会。过去，这是一个非常困难的问题，因为它主要由数据管理员驱动。你不可能雇佣成千上万的数据管理员来确保所有数据都能被发现了。所以现在我们可以雇佣 AI 智能体了。我们实际上正在构建智能体化的体验，去发现你的数据放在哪里，它们之间如何关联。我们知道，对于我们的大多数客户，他们的数据分布在多个云上，也有本地部署的数据。所以我们不能只考虑 GCP。我们还必须考虑可能位于 AWS、Azure 或本地部署的数据。现在不同的是，我们解决这个问题的基础原语要好得多。例如，我们可以跨云以个位数毫秒延迟进行跨云互联，完全安全地在互联网之外，费用相当低。

所以现实是，打破那些数据孤岛、访问你所有的数据，比过去要可行得多。我们能够实现安全性和治理自动化，这样当你需要在不同环境中进行某种细粒度的访问控制，而现在你想通过 AI 智能体访问数据时，我们可以尊重那个权限设置。现在确实有大量的机会，不仅因为 AI，还因为基础设施的演进，我们实际上能够打破那些数据孤岛。我们称之为无边界数据湖（borderless lake house）。这一切都是关于无边界——我们可以激活数据，无论它存储在哪里，真正让客户更容易拥有能够对所有数据进行推理和行动的 AI 智能体。

Google，我真的很喜欢这个打破壁垒的想法。这是很长一段时间以来我一直想做的事情。当我观察市场时，我看到发生的另一件事也在给你的观点带来摩擦，那就是现在我们似乎正在转向更多的按用量驱动的方式。而且我们也在建造更多的围墙花园，「嘿，你想出去，API 不再免费了。」你们是如何处理这个问题的？你认为这是一个威胁，还是认为「嘿，这就是往这个方向发展的代价」？

所以我认为业界一件好事是，我们确实有开放的数据格式，比如 Iceberg。我认为我们看到的是 vendors 正在意识到这一点，并且受到客户的压力，要以这些开放格式提供他们所有的数据。当然，通过这些跨云互联，你可以访问那些数据，而不需要按 GB 收取出口费用。你只需要支付带宽费用。这就是我之前谈论基础原语的原因。我认为你看到行业正在演进，首先，所有这些基本上允许——以我们为例，我们一直非常致力于开放。对我们来说，这是理所当然的。但即使是一些更传统的 vendors，特别是 SaaS vendors，已经意识到客户要求他们以零拷贝且经济有效的方式提供数据访问。

这种事情正在几乎整个行业中发生。例如，我们的无边界数据湖与 SAP、Workday、ServiceNow、Salesforce 都能协作。所以我们看到那些围墙花园正在被拆除。可能仍然会有一些落后者，但我的猜测是，客户会给那些落后者施加足够的压力，他们也将不得不拥抱开放，确保客户能够按照他们想要的方式使用他们的数据。

是的。我非常赞同这个积极的观点。我认为这非常正确。刚开始的灼烧感就像，「哦，天哪，AI 要拿走一切。」然后就是，「好吧，一开始很可怕。让我们冷静一下。然后我认为市场会意识到，是的，开放仍然很重要。」事实上，Google 最近为你们的 AI 智能体发布了一个新的开放存储 LLM Wiki。是这样吗？

是的，我们发布了开放知识格式（open knowledge format），这一切都是关于开放的。就像，「好吧，我如何以一种可以被使用的方式捕获知识，无论是被我们的平台还是其他平台？」所以我们看到相当多的 vendors 和客户对此感到兴奋，并正在拥抱它。这真的是我们的目标——推动这种开放，确保客户真正能够完全控制他们的数据。你可以把这一点看作是几乎类似于你围绕工具和平台拥有的技能。这是你拥有的知识。