欢迎大家来到AI工程师世界博览会，感谢大家参加今天的研讨会。我是Andy Wong，在Atlassian工作了四年，从事AI领域工作两年半。今天与我一同分享的还有两位优秀的同事：Shane Wolf和Andre Bohan。我们将探讨智能代理系统如何改变软件开发生命周期，以及编排技术带来的变革。

Shane稍后会分发号码牌，起初可能有些奇怪，但介绍结束后一切都会清晰。我将快速过一遍Atlassian过去一年半构建的AI工具概览，让大家了解我们将提供的各种功能。

大家可能知道，AI代理已深刻改变了软件开发流程。随着更多辅助工具的出现，生产力提升逐渐趋于平缓。因此我们认为最大的机会在于代码之外的环节：规划、编排、代码审查及运维等。我们开发了团队协作图谱，以及AI Planner、AutoDev、Reviewer和Central of All（即AI Context Machine）等代理工具。

今天主要测试的是Jira Coding Agent，这是Atlassian原生的编码智能体，拥有深厚的企业上下文理解能力。它能读取Jira工单、Confluence文档、邮件和Slack消息，收集所需上下文以规划并实现特定工单。

您可以在Jira生态系统中直接与Pull Request交互，所有操作均在云端完成和维护。此外，您可以直接将工作分配给特定代理。如果您不想使用Jira Agent也没关系，我们可以将工单指派给您偏好的其他AI代理（如Claude、Cursor或CodeEx）。

我们还有SDLC自动化功能。当满足特定条件时，您可以自动生成代码（使用Jira Coding Agent或您选择的任何代理）。

在代码审查方面，我们有AI Reviewer。它类似于行业内的许多工具，旨在通过代理检查Pull Request以发现Bug、执行标准并验证需求。审查不仅限于代码本身，还会检索Jira、Confluence、SCM和Slack中的上下文，形成对代码需求的整体视图并提供审查意见。

此外还有集中式标准管理功能。每个团队和组织都有自己的仓库实施规范，这往往很繁琐。我们的目标是简化经理和工程师在所有Pull Request中执行这些标准的流程。该功能支持GitHub、GitLab和Bitbucket Cloud等所有SCM平台，允许您将标准应用于Pull Request。

Atlassian的AI Reviewer旨在减少代码审查过程中的噪音。我们发现某些审查过程过于挑剔或提供大量低价值评论。我们在DevOps团队训练并筛选了模型，用于过滤掉我们认为无价值的噪音或无需的评论。

结果显示，使用这些模型后，代码审查意见的解决质量显著提高。人类代码审查解决率约为40%，接近人类的基线水平（45%）。我们一直在为各种工具构建仪表板，以展示代理运行次数和审查数量等数据，直观体现这些工具在DevOps空间中的价值。

最后介绍近期实施的产品之一：AI AutoDev。

识别出哪些工单可以自主运行。应用所有的标准规范，然后创建准备好进行审查的拉取请求。所有这些操作都可以在 Jira 生态系统内部触发。您可以配置各种需求，例如每月使用的最大积分数量、每个用户运行的自动开发工单的最大数量等。您还可以指定要在哪些代码仓库中运行此功能，或者是否在组织内的所有代码仓库中运行。

一如既往，我们提供了一个仪表板来展示所有的自动开发运行情况、其工作方式、需要审查的自动开发拉取请求数量以及故事审查需求。我们总是试图为工程师和团队提供尽可能多的元数据，以便他们真正了解自动开发的整体表现。

另外一点是我们将自动开发集成到了 Slack 中。一旦在代码仓库内部集成了自动开发，它就会根据工单的可用性开始处理特定的工作项，或者如果您需要任何输入来完成它们以获取更有投资回报率的见解。我们总是试图尽可能多地衡量，看看从自动开发整体中看到了什么样的总体投资回报率。

最后，关于 AI 事故响应（AI Incident Response），我们都经历过事故，都明白特别是在凌晨两三点时诊断和处理事故的困难。AI 事故响应旨在抓取之前事故、Jira 和 Confluence 中的所有上下文，并尝试找出事故发生的原因，同时提供在事故再次发生时如何修复的具体建议。

它已与 Slack 集成，因此您应该能够获得正在发生情况的快速摘要，了解是否影响多个外部客户还是仅影响一小部分客户。它将为您提供详细的理由和步骤，说明如何缓解您遇到的问题。如您所见，它会提供根因分析，并给出多种可能的修复方案供您参考。

我一直在强调上下文以及上下文对智能体本身的帮助。我们试图构建的是 AI 上下文智能体（AI Context Agent）。许多人在大型单体代码仓库中工作，所有这些信息都分散在不同的代码仓库或整个工作区中的不同文档片段里。

AI 上下文引擎旨在抓取所有这些内容，并为您创建一个标准化的上下文环境，供所有智能体以更有效的方式运行。我知道我说了很多关于“上下文”的话，这是过去一年来我们试图做的最重要的事情：尽可能抓取所有上下文，并创建一个强大的引擎来为未来的智能体提供动力。

如您所见，AI 上下文引擎将使用语义代码搜索来运行我们的所有工具（如 Jira、Confluence）以及之前的实例。我们将能够向未来使用的任何智能体提供所有这些上下文信息。

我们还试图让许多工具变得易于通过插件访问。我们希望工程师只需将工具添加到浏览器、IDE 或 CLI 中，就能开箱即用地使用它们。我说我想保持简短，因为我们身处 AI 工程师世界博览会。我们要构建东西。

因此，我为大家提供一个小工作坊来体验 Jira Coding Agent。您可能会看到 Shane 拿着特定的号码走动并递给您，那就是您的账户号。让我快速介绍一下这里的工作流程：该号码将绑定到您的登录信息上，以下是登录方式。

抱歉，遇到了一些 Wi-Fi 问题。

看来不只是我一个人的问题。好的，明白了。回到这个界面，只是为了确保每个人都有可用的二维码。

是的。

好，让我们看看……好的，我将停止共享屏幕。我会来处理这个情况。

天哪，是的。不太对劲。网速真的很慢吗？让我看看……哦，Wi-Fi 很慢。你连接上了吗？

啊，在那儿呢。网络已更改。>> 你的云防火墙还开着吗？试试关掉它。 >> 已经关了，确实关掉了。让我们看看……

进展如何？>> 是的，我们正在尝试解决目前的问题。 >> 对。

是啊，那是 Wi-Fi 的问题。这不起作用吗？>> 是的，它没反应。

好的，明白了。 >> 对，我要试一下我的设备。

懂了。是的。在我们解决 Wi-Fi 问题的同时，大家有什么 [轻笑] 问题我们可以讨论一下吗？

好吧，不过就像…… >> 或者站得近一点。>> 就站在这儿。好的。所以在解决 Wi-Fi 问题的同时，正如我刚才所说，大家有什么关于产品路线、可用功能、人们感兴趣的内容或工作流等方面的问题想讨论吗？我很乐意解答。 >> 抱歉，请讲

多给我们讲讲上下文引擎的情况。好的，所以本质上，在 Atlassian 内部我们有多个图数据库连接到您作为 Atlassian 客户最终接入到 ATL（Atlassian 产品）中的所有数据。比如 Confluence、Jira、Bitbucket，这些东西都连接在一起。

我们可以通过使用产品时的推断来建立这些连接，也可以让连接变得显式化。例如，当您处理一个 Jira 工单时，该工单基于 Confluence 中的某个规范文档。我们还将这些链接到第三方产品，比如我们会集成 Notion、Slack 等工具。所有这些内容都编织进这个庞大的上下文网络中。归根结底，我们现在构建的是如何在这个所有上下文的顶层进行语义搜索？这种情况在 Atlassian 内部经常发生，我们往往在一个生态系统的某一侧构建平台。

需要从其他团队（如平台文档）或其他部门正在进行的、可能影响当前构建内容的举措中获取上下文。通过上下文引擎，所有这些信息都会被拉取到当前的智能编码会话中。例如，Shane 目前正专注于 Wi-Fi 连接性这一主线任务，这正是他团队正在处理的内容。我们认为取得较大成功的领域之一是新的代码搜索产品。

历史上，许多团队倾向于采用单体仓库（monorepo），以便让智能体随时拥有上下文。但这存在缺陷，意味着需要构建大量工具链，导致效率低下。选择单体仓库往往伴随着技术债务和额外的工具建设成本。

借助代码上下文引擎，我们只需保留产品仓库即可。因为可以通过 Hawk 快速拉取上下文，实现高速的代码级访问。这意味着即使逻辑可能过时（例如 Confluence 文档仅是某时刻的快照，而代码才是真相），也能通过高吞吐量和良好的搜索语义高效获取最新信息。抱歉，刚才有点激动。这回答你的问题了吗？好的，还有其他问题吗？

请讲。

例如，如果有一个 GR... 抱歉，我重新表述一下问题。第一个问题是关于是否动态生成上下文。第二个问题是什么？ 第二个是关于冲突信息的问题。 哦，我们如何解决冲突对吧？是的，这很好。我认为会议上会有很多关于记忆的讨论，智能体记忆是一个热点话题。

智能体从不同来源推导知识，但最终需要人类确认其真实性或特定情况下的适用性。在信息获取方面，通常不会进行快照存储，因为那样会有过时风险并增加复杂性。其价值在于即时获取最新信息。

如果缓存数据，则面临过时风险及相关的复杂性。历史上处理权威性（authoritiveness）的方式是提供“人在回路”功能，让人类确认某些内容具有更高权威性。这在 Jira 工作项中较难实现，虽然可以做，但更繁琐且存在自动化导致权威性误判的风险。

好吧，网络恢复了吗？ 我想应该恢复了。是的，页面现在应该对所有人可用了。我会重新发布 Go Link 和二维码。

请确认每个人都有号码，这是登录凭证。我们将使用“Alaskan University”系统。请使用 Shane 之前提供的号码作为学生账号登录，以测试 Jira Coding Agent。

请在 Confluence 页面上找到链接进入我们的测试 Jira Workspace，那里有 Starter Repository（Atlassian swag）。登录后请直接尝试使用智能体。

哦，网络还是不行。 你在同一个网络上吗？我在同一网络。可能需要一点时间加载。

是的，我们联系了 IT 部门寻求解决方案，对此深表歉意。

我可以再放一次二维码吗？ 没关系。号码，号码... Shane 拿着写有号码的杯子走了吗？抱歉，请问 Shane 的号码杯在哪里？好问题，稍等。需要更多号码...

最好的号码。我想那是王牌吧。

我觉得没人能连上 Wi-Fi 了。 是的，我想这是2026年未解之谜之一。也许拯救我们免于 AGI 的就是 Wi-Fi，或者修好它就不需要救了。 [笑声] 你得优化流量...

在解决 Wi-Fi 问题之前，还有其他问题吗？请讲。

验证要求。好的，抱歉。问题是关于需求验证方面。

当 Jira Coding Agent 处理特定工作项时，我们期望该工作项包含验收标准清单。当智能体生成代码以完成特定任务时，它会验证这些具体事项。Jira Coding Agent 运行在完整的沙箱环境中，可以安装和运行任何东西。

只要你有...

仓库中的指令说明了如何运行这些内容，它可以弹出浏览器并执行验证步骤。关于沙箱环境的问题：它在哪里？是托管的吗，还是你可以自己引入的？目前还没有自行引入的能力。这是一个 Atlassian 专有的沙箱，本质上是一个容器，启用了 Docker，你可以运行想要的任何内容。

关于计费方面，是否使用您自己的 API 密钥？目前这些代理可以使用 Anthropic、OpenAI 或托管模型的 API 密钥。计费通过 Atlassian 积分进行，或者直接使用您自己的 API 密钥。每个代理都可以指向特定的模型，Jira Coding Agent 目前支持所有 Anthropic 和 OpenAI 的模型。

这是否意味着它是按使用量付费的模式？是的，类似于按需支付。目前 Jira Coding Agent 已经发布一段时间了。关于积分使用报告：从公司角度来看，月底需要汇报使用了多少 AI 积分吗？

目前积分是按产品细分的。例如，特定用户在 Jira Coding Agent（JCA）的特定体验中使用了多少积分，这是目前能获得的详细程度。但这还不是基于测试级别的报告，我们正在开发这项功能，因为随着越来越多的人使用代理式编码，确保投资回报率（ROI）变得至关重要。

我们需要防止有人浪费大量 token 在无关紧要的任务上，而不是让代理真正发挥作用。接下来是关于 Wi-Fi 的问题以及其他问题。

登录信息如下：网址是 1-ish-devo.atlassian.net，用户名是学生编号加大学后缀。密码在屏幕上显示为 ZXC on the academy。会话结束后会清除数据，所以不用担心安全问题。

关于模型路由的问题：目前 Jira Coding Agent 允许您选择要路由到的特定模型。此外，通过子代理和技能（Skills），您可以指定某个技能需要特定的模型或子代理。目前我们没有自动的智能路由功能，但这正在开发中，旨在帮助识别高成功率的任务并强制执行相应策略。

技能主要由用户定义。虽然有一些预设，但对于 Jira Coding Agent（前身为 Rode Dev），我们提供了一个框架：顶层进行模型选择，而在技能层面可以指定特定任务所需的模型或子代理。

由于 Wi-Fi 问题尚未解决，我们稍后会再次尝试连接。大家是否可以保持演示站点开放一段时间？我们可以一直将其保留到 AI AIS 展会期间。这样当 Wi-Fi 恢复时，大家可以自行探索工具。

请注意登录安全性：输入的信息应如同放在 GitHub Gist 或 Bitbucket Snippet 上一样安全，不要放入敏感数据。还有其他问题吗？

清理过时上下文的重要性究竟有多大？这个问题很有意思，能详细说说吗？比如你具体是什么意思？Atlassian 已经存在了十五到二十年，期间积累了大量的产品信息。在所有这些内容中……好吧，抱歉，这是个很好的问题。这个问题的核心在于：对于一个已经使用 Atlassian 长达十到十五年的大型组织来说，修剪掉一些旧内容的重要性有多大？目的是防止这些信息出现在搜索结果中，或者确保 AI 代理在寻找答案时不会抓取到这些过时内容。

根据我们的经验，总体而言处理这种情况还算顺利，这很大程度上是因为我们倾向于优先展示较新的结果。我认为权威性在这里起到了一定作用：如果某份文档已经存在十年，且至今仍是最前沿的指导文件，那么它就应该被保留。我们之前发布了一个功能，即在会议中展示的“已验证徽章”。这基本上是我们内部用来标识某内容仍然是最新、最佳实践的标准，并使其在上下文搜索中获得优先推荐。

大家好。好的，很棒。我想我们有一些关于“标准”的问题。不幸的是，“标准”功能并未直接集成在本次演示中，但我希望能花一点时间展示一下“Robo Dev”产品内部是如何运作标准的，以及我们如何为特定的代码库分配标准。这是一个快速演示：这是“标准”页面。虽然内置了一些模板，但我现在要展示的是如何创建自定义标准。

你可以选择多种不同的模板，但我要做的是创建一个新标准并给出简短描述。例如，“设计令牌执行”。如果我们要命名这个标准为“Design Token Enforcement”，添加描述和规则，那么在添加标准和规则后，你可以指定要将这些标准应用到哪些代码库。

你可以手动选择所有代码库，或者通过模式匹配来选择。随着这些代码库加载完成，你可以决定应用范围并创建标准。正如我所说的，在软件内部我们有自己的标准。与其手动强制执行这些 PR 流程中的规则，我们可以设置标准和目标代码库，“Robo Dev”的编码代理将在拉取请求过程中运行，并添加评论以检查 PR 是否符合标准中指定的要求。

我还想演示另外两个功能：“AI Planner”和“AutoDev”。我们无法进行完整的演示，但我想强调的是，我们正致力于代码生命周期的左侧（即开发前期）。我认为“AI Planner”和“AutoDev”更侧重于代码开发的早期阶段。虽然我没有完整的演示，但我可以通过幻灯片来讲解一下。

接下来开始介绍 AutoDev。实际上，Andre 在 AutoDev 方面投入了大量精力。你能简要概述一下你希望通过 AutoDev 实现的主要目标吗？以及它是如何工作的呢？（Andre 正在调试麦克风）……试着搞清楚麦克风怎么工作。应该碰它吗？不应该碰它哦，好了。天哪，谢谢。（抱歉）那我就站在这里吧。

好的，关于 AutoDev，这本质上是我们进入 AI SDLC（软件开发生命周期）编排领域的尝试。其基本思路是释放工程团队的时间，让他们专注于功能开发。AutoDev 的初始发布将侧重于从你的积压工作项中抓取那些我们认为代理能够自主处理的任务，然后为团队生成拉取请求以供审查。这样可以确保我们在做正确的事情、遵守正确的标准，并迭代测试环境，以较轻的方式让代码库准备好供代理使用。

这基本上确立了我们的方向。目前定义是：我们将抓取你的积压工作项，并允许你帮助我们识别哪些具体事项希望 AutoDev 来处理。对于下一步的发展方向我们有一些想法，比如标准执行。Andy 可能会在审查环节讨论这一点。我们认为标准在一定程度上类似于代码检查（linting），但在代理强制执行时会更宽松一些。

在审查器中，我们有一个面向未来的链接工作流：你将标准添加到代码审查器中，这将确保未来进入代码库的任何代码都符合要求。对于 AutoDev，我们有一个工作流可以扫描现有的部分（即现有代码库），并找出如何逐步提交 PR，从而使所有旧内容符合标准。

这里存在一些复杂性：因为没有人会批准一个更改了半个代码库的 PR，仅仅因为你引入了新标准；也没有人会批准导致大量变动的更改。因此，在使用 AutoDev 时，我们要小心不要给团队带来过重的工作负担。没有人愿意每天花时间去审查五十个 PR。

因此，我们提供了配置选项，让你可以设定团队的工作量分配，例如每个成员每周只接收三到五个 PR。这有助于实现渐进式进展，同时释放团队的时间去从事他们真正想要做的功能开发工作，并推进其他倡议。

这涉及两项举措，我将其视为组织层面的引导。这在大型组织中很常见，比如大家试图从某个版本的 Rails 迁移到另一个版本，这是一个大工程。我们有约一万项服务，它们非常相似，许多学习成果、记忆和工作流程是相通的。因此，你需要一个专注于单个团队的方案，让他们只需生成拉取请求（PR），由智能体完成大部分工作，人类仅负责协调。我们还会通过某种记忆机制将这一过程闭环。

这是我们的愿景，也是我们认为其对工作流程有益的地方：在拥有大量服务的大型组织中，我们花费了大量时间。我们希望工程师不必深度介入这些事务，而智能体是推动这一进程的巨大机遇。如果 AutoDev 代表团队自主工作，你需要了解其动态，并在它选错对象或分配错误人员时进行干预。我们会从这些经验中学习。

将其集成到 Jira 看板的原因是，无论人们是否愿意，当试图确定下一步工作时，都会盯着它看。之前提到的在制品限制（WIP limit）也很重要，要确保团队不会被过多的 PR 或其他非优先工作淹没。此外，我们还在考虑限制成本，这在当前环境下至关重要。你不希望智能体毫无节制地运行。

如果你想为 AutoDev 启动工作流，需要设定每项任务或每周的支出上限。这些似乎已是基本要求。当开发人员开始工作时，我们会提供广泛的审查机制。我在回顾积压任务时意识到，其中许多工作项描述不足，比如只有一行“做这件事”的摘要。虽然有价值，但我们缺乏信心去执行，因为不清楚具体目标。

这时我们会引入人类参与：“这是什么？我们要做吗？请帮我细化需求。”一旦达到足够的详细程度，我们才开始实际工作。“需要审查”阶段即在此时引入人类进行评审。我们还注意到，在自主工作流程中，“审查”环节往往是瓶颈所在，因为人们忙于其他事务。

我们正在构建一个系统，在合适时机联系相关人员：“请快速看一眼，判断是否合并或废弃。”AutoDev 初始版本的主要沟通渠道将是 Slack。此外还有投资回报率（ROI）洞察，确保你没有为不必要的工作付费，并能掌握我们实际处理工作的范围。

接下来快速讨论规划部分。我们将推出一款新产品叫 AI Planner，更适合项目经理或希望评估当前仓库可行性的管理者。你可以提供构建想法，AI Planner 会通过上下文引擎分析你的代码库、计划及可行性。如果可行，它会告知你；第二部分则是提供实施特定功能或想法的详细分解计划及执行方式。

我们谈到了上下文引擎，Shane 就在现场，他主要致力于 Code Chat（代码聊天）。Shane，能否多谈谈 Code Chat 功能以及上下文引擎本身？没有幻灯片。好的。我们拥有约一万五千个代码库，询问“在哪里实现此更改”或“哪些服务使用某项功能”等问题非常复杂。

上下文引擎的核心在于缩小检索和搜索范围，将答案锁定在代码中最可能存在的区域，并深入挖掘以回答问题。在此基础上，结合 Teamwork Graph（团队协作图）中的信息。文档通常过时且不准确，仅搜索文档会得到过去某个时间点的真理。但其中也包含大量有价值的信息。

这些信息表明，该项目在此时构建了这一功能。当时情况确实如此，但现在已不再适用。然而，这些决策在当时做出的原因对于未来的变更具有价值。因此，我们可以利用当前存在的代码、过去某个时间点形成这些决策的历史背景，并利用这些信息来指导实施路径或规划。例如，解释为何应以特定方式更改代码。这说得通吗？有什么问题吗？是的，关于决策原因的历史信息通常被遗漏在 AI 代理生成的代码之外，但对于避免重蹈过去的覆辙而言，这种历史背景至关重要。这就是我们对上下文引擎的思考方式。

太棒了，谢谢。我们这边有一个问题。是的，其中很大一部分被使用了，比如 AI 规划器利用它来做很多事情，你们两位能否就此多说一些？AI 规划器目前大量使用它。如果你试图弄清楚如何构建某样东西，它可以查看相关项目的文档及其周围的上下文信息。因此，它处于我们正在构建的许多新能力的核心位置。AutoDev 也使用它，你可以对此多说一些。AI Reviewer 今天用得不多，但我们开始实验如何将其更多地纳入其中。

此外，它目前暴露的另一个地方是在 Robo Chat 中。如果你与 Robo 对话……我们几个月前刚宣布了这一功能，目前正与少数客户进行早期访问。如果你今天询问代码相关问题，它主要通过 Confluence 搜索和一些其他连接的工具来回答这些问题。如果你有 GitHub 或 Bitbucket，它会使用它们的搜索 API。但如果你启用了名为“代码上下文启用”的新功能，它将拥有更连贯的代码理解能力，基于当下的事实以及过去做出的历史决策。

抱歉，访问权限？是的，Team Graph CLI 是我们开始暴露许多这些能力的地方。上下文引擎本身更像是一种代理式搜索，你可以这样理解它。我们拥有许多核心原语，将通过 CLI 暴露给你的代理使用，但我认为随着时间的推移，我们也可能会考虑将更多功能移入其中。是的，Team Graph CLI 可以访问所有代码上下文技能。后面有一位提问者。

好的，我有两个问题。第一个是关于标准的。看起来标准是用 Pros 和 Markdown 标记的，对吗？这是正确的，是的。你们有任何方法可以将这些映射到像 CI 检查这样确定的内容吗？就像我们说的，比如一个复选框场景。我想起来的话，我们可能需要在 Markdown 本身中实现这一点。但这确实是一个很有趣的用例，你可以提供具体的二进制判断：这是否满足？是或否。

目前我认为我们没有开箱即用地提供该功能，但我会将此反馈给标准团队，看看未来是否能实现这一点。是的，那将会非常酷，让它变得更……太棒了。对。就像 Epic 那样，你可以将其分解并细分为多个阶段或代理波次。通常会有基础性工作随后展开，以解除阻塞。对。

重申一下，我认为你的用例类似：你有一个 Epic，可能希望将其分解为更小的问题，然后在这些较小的问题中，你可以让代理波次依次执行每个小部分。是这样吗？你是否希望更进一步，在实现第一波之后启动第二波代理？是的。好的，太棒了。这是一个很好的问题。实际上我昨天用 JCA 试过了。

你可以让 JCA 将 Epic 分解为更小的问题，如果你提供了一个 Jur Epic（Jira Epic），它能够将其分解为较小的 Jira 任务。之后，你可以利用一些自动化规则进行操作。假设你有一个 Epic 被分解后，可以通过自动化重新启动 JCA 实例或启动一个会话，从而自主地开发每一个部分。

我认为没有什么能阻止你进一步扩展这一点：比如这里是我想要分解的所有故事，将它们分为多个 Epic。基础性工作、V0、V1、V2 等，然后让它进一步细化其中的工单。我认为没有什么能阻止你这样做。哦，你可以继续下去。是的，你可以灵活操作。继续吧。

这听起来更像是 JCA 的自动化功能。我不确定 Robo 能否直接做到，但我肯定认为可以通过自动化实现。是的，而且我认为 AutoDev 可能也能做其中的一些工作。AutoDev？对。好的，我用 GAS（Google Apps Script）做过类似的事情。（笑声）你们做得很好，谢谢。不客气。

我有一个问题。我只是想弄清楚实际上我的代码是我更改了代码。重申一下，假设你在 IDE 中进行了代码更改。哦是的。我认为你需要这样理解 JCA：它的代理会话是非常隔离的。因此，如果你说在代理会话本身内进行更改，那么它是实时的。

如果你在云中的 VS Code 实例中进行更改，是的，所有这些更改都会实时发生，并且你将能够在云会话本身中反映这些变化。你在 IDE 上所做的更改是单独的实例，对吧？所以是的，对于代理而言，请将其视为完全在云中进行的任何更改。你在 Jira 会话或 Jur 代理会话本身内的所有更改都将是实时的。

这边有一个问题。你……我想你是说你的实例更像是本地部署（on-prem），并且你想在本地运行许多代理，对吗？甚至不是……我想问的是开发环境是怎样的。我们需要使用 Docker 文件吗？那是……是 Docker。它是 Docker。是的，没错。好的。酷。我想我们还有一个问题的时间。

这是一个很好的问题。呃，我们认为我们实际上最近才开始支持技能功能，我想大概就在不久之前。

没错。是的。所以我认为对于 AI Reviewer（AI 审查员）本身，我们确实支持诸如技能之类的功能。我想就在不到一个月前，我们发布了 Leads（线索/负责人）功能。听起来不错。>> 酷。好的，谢谢大家。我们得走了。如果还有其他问题，我们会一直在场。但>> 是的，非常感谢大家参加我们的研讨会。特别感谢技术团队帮我们解决了所有的 Wi-Fi 问题，向他们致以热烈的谢意。希望大家在会议期间剩下的时间里度过愉快的一周。非常感谢大家。

[音乐]