0:00 / --:--
Latent Space · 6 月 2 日
GitHub COO Kyle Daigle 认为，AI 智能体（Agent）要真正进入企业软件开发，不能只会生成代码，还必须接入邮件、会议、规范等可信上下文，并在操作系统级沙箱与合规约束下安全运行。
GitHub 首席运营官 Kyle Daigle 描述了一条从个人 AI 工作流、组织知识检索到编码智能体（Agent）的路线：智能体若要真正进入软件开发与企业工作，就不能只会生成代码，还必须接入可信上下文，并在安全与治理约束下运行。
这集还没有学习卡。生成后会保存在这一集，下次直接打开。
No Priors· 2026-10-29挑战 ServiceNow：面向我们普通人的编程智能体，与 Serval 联合创始人兼 CEO Jake Stauch 对谈Taking on ServiceNow: Coding Agents the Rest of Us with Serval Co-Founder and CEO Jake Stauch同主题：AI 编程
Latent Space· 2026-10-28为什么 AI 智能体喜欢 SupabaseWhy Agents Love Supabase同主题：AI 编程
a16z Show· 2026-10-26OpenAI：当 AI 智能体使用电脑的速度比你还快OpenAI: When AI Agents Use Computers Faster Than YouKyle 说自己在 GitHub 工作了十三年，入职时是一名开发者，曾建设 webhooks、参与 API 团队及平台层工作。他把后来承担的运营、对外沟通和开发者工作，视为同一条职业线索的延伸：既理解产品如何建成，也要向开发者、企业客户和业务负责人解释它为什么重要。
这场谈话以一个很具体的问题展开：AI 为什么让一位不再日常写代码的管理者重新增加了提交？Kyle 的回答逐渐从个人效率扩展到 GitHub 的内部工具、开源依赖安全、Copilot 的产品方向，以及微软如何让智能体在企业设备和工作资料中安全地运行。
这集访谈的主线不是“AI 能替开发者写多少代码”，而是智能体能否在真实组织中取得足够上下文、完成有用的工作，同时仍受安全边界约束。Kyle 从自己的工作流谈起：他让工具回看 PR、公开发布内容、笔记、会议转写及消息，先判断过去一周发生了什么，再提出未来几天可以调整的方向。GitHub 内部把可复用的能力做成较小的 skills，经由 CLI、应用和仓库分享，而不是期待一条庞大指令长期适用于所有职业与场景。
这个思路也解释了他对 Copilot 的定位。代码补全仍在改进，但他更关注共享底层 SDK 与运行机制的 CLI、桌面应用和云端智能体，能否延伸到安全修复、问题处理及文档核对。更远的目标，是让开发工具理解邮件、会议、规范及团队判断，而不只读取代码。Microsoft Build 相关讨论则把问题推到操作系统、沙箱、企业资料连接和合规层面：个人周末能快速做出的应用，进入大型企业后仍须经过安全审查。值得保留的分歧是，更多上下文会提高智能体的帮助程度，也可能带来权限与控制权问题；AI 制作材料可以省时，但产物仍需有人负责核验。另一个证据边界同样重要：所给转写省略了约半小时中段，因此有关该段议题只能据可见发言和标题提示说明，不能还原未提供的论证。
💬 他们说了什么：主持人以 GitHub COO 的身份介绍 Kyle；开场对其头衔另有口误，Kyle 随后说明自己的扩展职责是微软开发者领域的 CMO。他说自己在 GitHub 工作了十三年，作为开发者加入，曾建设 webhooks，并参与 API 团队和平台层。他回忆，直至 2018 年前后，与 GitHub 集成相关的许多东西由他建设，或由他负责的工程团队建设。后来他的工作扩展为连接开发者、企业客户和业务领导者，并参与 GitHub 在微软收购后的运营。他把对外工作的原则概括为讲真话、保持真实、展示产品用法，让产品自己说话。
💡 为什么重要：这解释了访谈为何能同时讨论代码、组织运作和市场沟通。Kyle 谈 AI 时不是单从模型能力出发，而是从一个既建过平台、又管理团队的人如何使用它出发。
⚡ 争议点：开场出现的“CEO”称呼与此处反复使用的“COO”不一致，整理身份时不应沿用该口误。
💬 主持人注意到 Kyle 的代码提交增加；Kyle 将自己重返编码归因于 AI。他说自己有时在写软件，更多时候则是在连接不同数据源，为管理和沟通工作建立智能体及工作流。他给出的输入包括当天 PR、网上发布内容、过去三个月的工作、Obsidian 笔记、工作会议转写和 Slack 信息；其中 Teams 转写可经 WorkIQ MCP server 获取。他尤其强调一个“先向后看、再稍微向前看”的循环：复盘本周做了什么、哪些有效，再问未来三四天该调整什么。他还说，新 GitHub Copilot 桌面应用中的工作流会在他打开笔记本电脑时运行，产物最终会进入 GitHub。
💡 这里的 AI 价值不只是加快一项写作或编码任务，而是把散落的工作记录转成可讨论的近期判断。把回顾与短期计划连起来，也比要求工具凭空制定长期战略更贴近 Kyle 描述的实际用法。
⚡ Kyle 认为大模型擅长回顾和提取模式，但访谈没有给出这些复盘结论的准确率或独立核验结果。
💬 Kyle 说，向工程之外推广 AI 时，他不希望员工先改变工作方式或学习一整套新工具。GitHub 内部建立了一组 skills，也向非技术人员分发 CLI，让工具读取 GitHub、Teams、邮件和 Slack 中与工作有关的内容。他解释，GitHub 用 Teams 进行视频沟通，却仍在 Slack 中聊天和运行长期形成的 ChatOps 流程；迁移既有命令和工具会很昂贵。团队可以把发现自动写入 GitHub issues 或 discussions，也会把做好的 skill 放进仓库供同事复用。对于 skill 设计，他更倾向于“只做好一件事”的微型积木，而不是会随业务变化而变脆的大型、完整工作流；同样叫“总结”，面向分析师、客户或营销同事的要求也不同。
💡 组织采用 AI 的成本常藏在现有流程中，而非只在模型调用中。微型 skill 允许共同复用基础动作，同时保留不同职业对输出的判断标准。
⚡ 主持人追问 skills 泛滥及内部影响力问题；Kyle 给出了缩小 skill 粒度的方向，但没有提供治理数量、权限或质量的完整制度。
💬 主持人提出，这是否是曾任开发者、如今身处领导岗位者的“黄金时代”。Kyle 认为自己的核心能力一直是识别模式和解决问题，这既帮助他做开发，也帮助他担任 COO 和 CMO。AI 让他能重新动手做应用，同时把十多年积累的业务知识带回开发过程。他举例说，孩子打长曲棍球时，他可以在周六同时启动十五个智能体。他也描述了年度收入规划中的一次实践：汇集已有资料与 skills，用一个小应用和 SQLite 数据库查看信息，随后制作整套演示材料。
💡 Kyle 的论点不是“管理者又能写代码了”这么简单，而是跨领域经验可以直接影响做什么、如何呈现，以及产物能否投入工作。AI 降低制作门槛后，识别问题与判断用途反而更显眼。
⚡ “十五个智能体”是他的个人场景，不等于一般团队可以稳定获得相同的生产率。访谈也未量化这套规划材料相对传统流程节省了多少时间。
💬 Kyle 说，收入规划演示使用了他的 Obsidian 笔记及其他工作上下文。他还制作了一个 skill，使材料不要显得刻意“像 AI 做的”；他向 CRO、CFO 及其团队展示时，AI 制作过程没有成为话题。主持人提醒，坦率承认 AI 参与，也可能帮助听众理解材料中或许存在未经核验的错误。谈到幕僚长，Kyle 明确表示自己仍有 chief of staff，只是不再需要对方把大量时间用于制作幻灯片。他认为这一角色更有价值的部分，是发现团队与人之间的联系，安排恰当的会面，协助更快地做决定。
💡 这区分了“制作信息载体”和“理解组织关系”两种工作。自动化前者，不必然使后者消失，却会改变幕僚长的时间分配。
⚡ “没有人提到是 AI 做的”不等于材料已被充分验证；主持人关于责任归属的提醒，在转写中没有得到一套明确的审核规则作为回答。
💬 Kyle 回忆，在 2018 年微软收购完成前，他曾作为工程负责人推出第一版 GitHub Actions；他把 GitHub Universe 的发布时间记为大约 2018 年 10 月。谈到更早的 GitHub Services，他说开发者曾可提交 Ruby 代码，由 GitHub 代为运行，以完成集成；当时的隔离方式与今天不同。他认为，从代跑任意代码发展到容器化的 Actions，再到更快启动的智能体计算环境，是一条持续改善隔离的路线。他也指出，工作流依赖若不固定到特定 SHA，而只使用宽泛版本或最新版，会造成痛点。关于 npm，他说收购时的重要目标是让这一广泛使用的服务继续运行并扩容；提高安全性又可能破坏已有使用方式，因此 GitHub 调整过双因素认证和令牌处理，也会使发现暴露或可能暴露的令牌失效。
💡 GitHub 的智能体计划并非凭空出现：平台早就面对“替别人运行代码”的需求与风险。历史经验使计算隔离、依赖固定和兼容性成为讨论智能体时绕不开的工程条件。
⚡ 主持人问 Actions 是否是 GitHub 安全问题的首要来源，Kyle 没有给出支持这一排名的数据。有关早期系统是否发生过问题，他使用的是“据我所知”之类有限定性的表述。
💬 主持人提出一种设想：少依赖包管理发布，让编码智能体读取源代码，只取所需部分并 vendoring 到项目中；他随即追问这是否现实、能否解决安全问题。Kyle 回答，这不会解决根本问题，并回忆 2013、2014 年左右也有过把依赖纳入项目、讨论是否只取一个文件的实践。他认为缩小依赖范围可能有所帮助，但智能体仍可能被诱导错误判断一段代码是否安全。因此，静态分析、运行时测试及对引入代码的安全检查仍需投入。证据边界：所给转写随后标示“中段省略”，直到约 1:03:43 才恢复可见正文；时间提示列出了其间话题，却没有提供可供还原的具体发言。
💡 减少依赖体积与验证依赖安全，是相关但不同的问题。把“由 AI 看过”直接当作安全保证，正是 Kyle 在可见回答中拒绝的推论。
⚡ 主持人的方案属于探索性提问，并非 GitHub 已宣布取消 npm 的计划。缺失中段涉及 PR、规模、可靠性与 Actions 等提示主题，其论据和结论不能由本稿补写。
💬 可见转写在本段提示之后、约 1:03:43 的发言处恢复。Kyle 说，Copilot 曾投入模型微调，包括总体使用场景，也包括有此需求的客户；随后基础模型进步，编码工具格局也发生变化。他表示，GitHub 仍投资代码补全、后训练及特定语言的建议，同时为 Copilot 编码智能体建立共同的 SDK 和运行机制，使新 CLI、桌面应用及云端智能体使用同一底层。他设想将智能体用于安全修复、处理 GitHub issue，以及找出仓库文档与实际状态不相符之处。他特别推荐重新查看 Copilot 桌面应用，称其已成为自己的日常工具，同时也提到 CLI、可使用不同模型和自带密钥的选择。
💡 这表明 Kyle 希望 Copilot 的价值不止于编辑器里生成下一段代码，而是贯穿代码之外的维护任务。共享底层机制则让不同入口的智能体能力有机会保持一致。
⚡ “给每个 issue 派智能体试一试”是方向性的设想，不等于智能体能够可靠完成每个 issue。由于本处此前转写缺失，不能据现有文字重建整段 Copilot 历史讨论。
💬 Kyle 说，理想中的 GitHub 应逐渐理解“Kyle 想怎样工作”，但主持人提醒这是开放研究问题，Kyle 表示同意。随后他认为，当前对 AI 的关注仍过于局限在编码入口：即使智能体在后台运行，也常因安全和治理原因，拿不到编码之外的工作上下文。他想要的“环境式 AI”能理解规范文档、邮件、线上讨论，以及团队成员与业务状况，并把这些纳入实现选择。他以 OpenClaw 的跨数据源连接为例，追问如何让这类信息真正帮助软件开发，而不只是增加一个启动编码智能体的渠道。主持人则提出控制权倒置的担忧：终有一天，可能变成 AI 告诉人该做什么。
💡 软件开发并非一条由个人独自写出“完美代码”的流水线。若产品目标是帮助作出正确实现选择，相关的人、文档和决策缘由就与代码本身一样关键。
⚡ 上下文接入越广，越需要回答谁能授权、智能体可采取什么行动、用户何时介入。Kyle 也区分了愿意接受“提醒喝水”与不愿轻易接受“改变车辆目的地”的主动性边界。
💬 主持人问，微软为何会有专门面向 OpenClaw 的 CVP，而微软并不拥有该项目。Kyle 认为，OpenClaw 让人直观看到一种有价值的智能体：它能使用用户有权访问的资源，也能操作计算机，从而超出单一任务或聊天工具。他把问题转到工作场景：如果智能体安装在个人或工作设备上，就需要更好的操作系统级沙箱，才能安全地接触工作资产。他说微软关注 Windows 上的沙箱、云端沙箱和开源项目，也需要从平台组件而非单一顶层产品的角度投入。谈到“AI 的新操作系统”这一说法，他进一步指出，变化可能深入到 Azure 的计算与硅层，因为智能体工作负载不只是“需要更多推理”。
💡 这一段把智能体体验与底层平台连在一起：有用的智能体需要权限和执行能力，可信的智能体又需要隔离。两者必须同时成立，才能进入企业日常设备。
⚡ Kyle 对微软投入与未来需求的描述属于嘉宾陈述；访谈未列出沙箱产品的具体安全指标。OpenClaw 被当作需求范例，不应误写成微软拥有的产品。
💬 Kyle 邀请听众查看 Build 公告，并称微软正试图更直接地面向开发者，包括可能让日常使用 Mac 或 Linux 的人重新注意 Windows 上的开发体验。他反复提出一句工作目标：周末怎样构建应用，工作时也应尽可能那样构建；但在 Fortune 100 或 Fortune 500 企业，应用仍须经过安全与合规流程。他推荐身处 M365 环境的人查看 WorkIQ 和 FoundryIQ，将其简化描述为连接工作上下文及既有资料库的“上下文引擎”。他表示，GitHub 员工已用这些工具询问工作资料中的问题，并强调企业工具若造成私人信息泄露风险，便可能根本不获准使用。主持人指出 WorkIQ 团队应与 Copilot 团队紧密合作；Kyle 回答，过去几个月他们确实一直在一起工作，代码资产有其特殊性，但共同问题是上下文。
💡 企业采用的关键不是演示中智能体能做什么，而是员工明天是否获准在真实资料上使用它。把现有存储连接起来、同时满足组织约束，是 Kyle 描述的产品机会。
⚡ “可以在企业安全使用”的方向需要具体权限与合规表现来验证；访谈没有给出 WorkIQ、FoundryIQ 的测试结果或部署数据。
💬 主持人说自己将在 Build 采访 Satya，并问 Kyle 应该提出什么问题。Kyle 建议问：Satya 认为两三年后什么会被证明是真的？他希望这个问题触及微软如何看待 AI、推理、token，以及人们届时如何工作。Kyle 认为，微软近期的一些调整指向减少彼此割裂的产品和到处缺少上下文的状态，因此需要解释今天的做法为什么会在两年后得到回报。主持人承认外界存在疑虑，认为直接回答会提供有价值的判断材料，并表示会问这个问题。
💡 这一收尾把整集的工具细节提升为一个可追问的战略命题：整合上下文与智能体平台，究竟凭什么值得现在投入。它也保留了时间维度，避免只凭眼前演示判断路线成败。
⚡ 这是拟向 Satya 提出的问题，不是 Satya 已作出的预测或承诺。本集也没有给出“两年后奏效”的可量化判据。
“Tell the truth, be authentic, show people how to use it and then let the products speak for themselves.” “讲真话、保持真实、向人们展示如何使用，然后让产品自己说话。”——Kyle
“We’re really talking about these like incredibly micro skills that are just doing one thing for us very well.” “我们真正讨论的是极小的 skills：每一个都把一件事做好。”——Kyle
“How I build on the weekend should be how I build at work.” “我周末怎样构建，工作时也应该怎样构建。”——Kyle
“It’s all just context, exactly.” “没错，归根结底都是上下文。”——Kyle
“I need to be able to use that Claw and not get fired.” “我得能够使用那个 Claw，而不用因此丢掉工作。”——Kyle
reused_en_transcript（用户提供的英文转写；其中明确包含“中段省略”）