大家好，让我们从一个简单的问题开始：到底什么是威胁建模？是什么促使你进入这个领域？这是一个非常好的问题，巴拉吉。但我想从一个可能更贴近大家内心的话题开始说起。我们都熟悉高速列车对吧？那么，火车运行需要什么？我们有常见的道岔和轨道。这具有可预测性：你知道有起点，也有终点，轨道有一套固定的路线。

现在，如果你把轨道撤掉，换上越野轮胎呢？你拥有一个自主系统来决定如何带你到达目的地。这意味着什么？你失去了火车路线的可预测性。列车实际上可能会穿过某人的后院、工厂或农田，而你完全无法控制它。把它想象成传统的软件模型：那些轨道就是你的 AI 安全护栏，对吧？

但在当今时代，AI 在不断进化。自主系统基本上在控制代码接下来要做什么，做出这些决策。更令人担忧的是事情发生的速度。如今的 AI 代码周转非常快。而安全领域总是在追赶。考虑到这一点，我们想看看目前行业中现有的威胁建模方法，以及它实际上如何帮助那些拥有专职网络安全团队并设有平台的企业。

这是一个很好的类比。你能否向观众解释一下，到底什么是威胁建模？我们在哪里使用它，以便他们能更清楚地理解？当然。基本上，威胁建模是在问题发生之前询问“什么会出错”。它映射你在系统景观或系统图、数据流、信任边界中拥有的资产，然后列出攻击并决定缓解措施。

简而言之，威胁建模是软件设计的一个组成部分，如今往往倾向于有效地被吸收到整体工程流程中。正如我提到的，AI 提高了风险等级，对吧？AI 系统是非确定性的：你不知道火车的路线。因此出现了新的攻击面，比如提示注入、滥用行为以及不必要的权限提升。在使用 AI 辅助编码时，你失去了一部分控制权。

如果你不对该 AI 的架构权限进行建模，你不仅仅是在发布一个漏洞，你基本上是把钥匙交给了自主代理，并指望它能安全驾驶。另一个我们应该考虑的关键因素——这也是我们的主要动机之一——是越来越多的新法规正在出台，例如欧盟《网络弹性法案》，它现在要求“设计即风险评估”。我们都听说过“安全左移”或“设计即安全”，希望如此。这进一步证实了这一点。

也许维奈想在此基础上补充一些内容？是的，我认为马杜已经讲得很好了。威胁建模……如果你看看它与仅仅找出代码中错误以及扫描的区别，关键区别在于：威胁建模关注的是“不存在”的东西，而扫描和其他技术关注的是“存在”的东西。它可以利用任何计算能力来查看当前存在的代码，并找出其中是否有问题。

但威胁建模基本上关注的是真正缺失的部分，这是仅通过查看现有内容无法发现的。它需要从高层视角来看待：你看的是系统视图，这就是威胁建模所做的关键区别所在。谢谢阿达希和维奈。也许我会让你们两位向我们的观众介绍一下，你们具体做什么？以及我们是如何走到这一步的？简单介绍一下贵公司正在做的事情及相关细节。

我是 ThreatMantis 的创始人兼董事总经理。我们的网站已上线，产品也已发布，网址是 threatmantis.ai。这是一个由 AI 驱动的应用平台，旨在帮助企业进行威胁建模流程。维奈是我们的首席产品官。是的，谢谢阿达希。我们对最近上线的这个产品感到非常兴奋，但我们从今年年初就开始为此努力了。

ThreatMantis 是我们团队进入职业生涯后半段的结果——希望我没有暴露年龄（笑声）。我们在这里的团队都是拥有约 20 年经验的企业专业人士。我们都看到了负面影响和挑战，这也正是我们致力于开发此类产品的动机所在。这就是我们今天在这里所做的。

非常感谢两位的介绍。在进入其他部分之前，我们能否通过屏幕共享或其他方式展示这个产品具体做什么？它如何帮助企业？为什么每个人都应该进入这种威胁建模和高安全阶段非常重要？我们会进行展示，尽可能多地讨论相关内容。我可以在回答相关问题时随时调出它，虽然我已经准备好了。

那么下一个问题：威胁建模能捕捉到漏洞扫描或渗透测试无法发现的东西是什么？这是一个非常好的问题，马诺杰。因为渗透测试是我们都熟悉的事情，而威胁建模发生在设计阶段。有时它被局限于架构团队，并没有真正流向实际执行开发的开发人员。但请这样想：扫描器基本上是在现有代码中发现已知的漏洞。

正如维奈所说，它无法发现你尚未编码的内容。但威胁建模基本上可以发现与实现状态无关的设计缺陷。我喜欢这样比喻：渗透测试基本上是窃贼在测试你的锁，而威胁建模是你正在审查平面图。如果任何观众是《星际迷航》……

各位星球大战迷，我想到的一个最酷的例子是在第四部曲的早期电影中出现的死星。我喜欢说，如果当时有威胁建模，就能发现那个让卢克·天行者能够潜入的2米宽的漏洞。这基本上就是威胁建模所做的：你是在整个设计中找出漏洞。渗透测试则像是反抗军入侵，破坏大门并试图消灭暴风兵，这基本上就是你的渗透测试。我知道幸好对反抗军有利，但这告诉你正在试图捕捉设计本身中的主要漏洞。

在核心软件开发中，你可以这样想：假设你忘记或者更准确地说没有为你的管理门户构建安全网关系统。它仍然通过了，因为该系统不存在，但威胁建模会告诉你需要建立某些东西。

明白了。所以就像在开发之前我们有一个计划，而这个模型将验证构建它是否安全，并给我们审查和建议以及如何修复这些东西。

是的，完全正确。你可以通过图表来做这件事。不仅仅是图表，好吗？你还可以通过你的集成系统来完成这一点。许多公司使用工具来设计他们的整体景观。比如你有这个设计，还有一些其他产品也被广泛使用。所以你可以建立连接来做这件事。也许我们也可以在这里展示给你看。

很酷。根据我的理解，我们有这个架构图，你的系统将分析该架构并给我们审查或反馈？

是的。大部分正确，但我稍微修改一下说法：仅仅是架构图可能是一个来源……但输入是架构信息。它是一个复合数据集，当然可以包括任何形式的描述。它可以以图表形式呈现，也可以包含图表加其他内容，但一般来说它摄取架构信息。

我想这里举一个小例子可能会有所帮助。

当然可以。你在这里看到的是我们平台的仪表板。让我跳到一个威胁模型中，就像我刚才解释的那样，威胁建模已经使用架构信息进行了分析，真正关注的是景观是什么、可能的漏洞有哪些等等。但我想快速展示一点：这并不意味着不需要查看代码，而是说代码是在之后才涉及的。

你已经查看了你的架构，对你的设计进行了建模，现在有了这个上下文，当系统查看你的代码库时，它可以告诉你：“好的，这是你的系统架构，这是你的意图，你试图做什么，但当我查看代码时，这是我仍然看到的开放状态。这就是正在发生的事情。”这里有一个小细节可以指出在代码中发现的位置，但如果把代码作为起点来看待，我们最终会遇到我之前提到的问题：它只能查看存在的东西并在那里发现问题。

但当我们从漏洞优先的角度开始看时，它就知道了在代码中寻找什么。所以我们需要查看代码来闭环，但我们从威胁建模开始。然后这就引出了基于代码的分析以及参考威胁模型本身的过程。

很酷，谢谢。但在看完这个之后，我脑海中浮现了一些想法。我们之前谈论了架构图，也讨论了基于漏洞需要修复的代码。那么为什么我不能直接使用像ChatGPT、Codex或Claude Code这样的编码代理，它们也能做所有这些事情呢？你想在这里带来什么区别？我想理解这一点。

因为每天当我作为开发人员开发某些东西时，我也会查看这些架构图并设计这些东西。我广泛使用这些编码代理来处理漏洞，完全像这样。所以我想从开发人员的角度理解：我能从中获得什么好处？

这是一个非常有效的问题，我相信任何人都会问。我建议做一个小实验，也许你和观众在看完视频后可以尝试一下。

截取国际象棋.com上任意位置的截图，上传到你选择的LLM工具（如ChatGPT或Claude），然后要求它给出接下来的三步棋。十次中有九次，你会发现非常有趣且奇怪的事情：它建议的甚至是不可能的步骤。看起来它对阻挡位置的某些棋子视而不见，却提出了不可能的移动。

实际上我做过这个实验，我经常下棋，我想节省国际象棋.com的会员费。然后我才意识到，因为国际象棋早已被Stockfish解决，它不需要最先进的AI。最大的区别在于真正起作用的国际象棋引擎拥有一张知识图谱，清晰地映射出可能的移动树。然后它将当前位置与之匹配并查看概率。

而LLM做的是基于文本的处理，注意力块帮助它根据上下文理解某些内容。但它并不是完全编码的知识图谱。所以首先，如果我们把威胁模型作为一个例子来看待：它创建了一个非常详细的图，展示了资产、流程、边界和参与者。

基于这个关于当前架构中确切内容的非常严格的知识图谱，以及另一方面严格按照STRIDE、MITRE和OWASP标准建模的内容，它基于此进行操作。

当然，还有最重要的一点是知识库的概念。这正是上下文锚定发挥作用的地方。组织拥有他们的政策以及任何他们想要添加的内容，所有这些都会被整合进去，从而使系统能够实际运行并给出可靠的答案。否则，它可能会给你一个错误的答案。就像国际象棋的例子一样，你可以轻易看出它是错的——如果系统说“将兵向前移动两格”，你知道这是不可能的。但在这些情况下，你往往无法察觉错误，而实际上很多事情都出了错。因此，这是最大的风险：对于超出小范围（例如上传一个框并让其告诉你结果）的事物进行扩展时，你无法做到这一点。

此外，我们甚至还没有谈到治理要素。比如用户和工作流、令牌管理、使用情况、有多少用户参与协作以及审批工作流等。我甚至没有提及治理方面的所有内容，你知道的，就是治理本身。如果没有这些，它在公司的实际场景中就不是一个真正可用的产品。尽管如此，对于人们理解什么是威胁建模来说，这仍然是一件很好的事情。我仍然建议人们去查看这些内容，以便理解其语言以及什么是威胁建模。实际上，我们鼓励人们在通用工具上尝试一下，以使其变得熟练。

是的，很酷。那么当你谈到这个知识库时，我脑海中浮现出下一个问题。这里我们讨论的是漏洞和威胁。那么当“可能正确”并不可接受时，你如何处理幻觉问题呢？正如你提到的国际象棋例子那样，大型语言模型经常会出现这种情况。在你的系统中你是如何处理这一点的？我认为我会先从我们的推导引擎在结构上如何被迫将发现映射到工业标准类别开始谈起。你可能已经听说过 STRIDE 了吧？这是我们采用的标准之一。

其次，引擎将系统理解为一个知识图谱——就像我之前展示的那样。我们向系统提供了大量的上下文信息，因此你可以提供一个空间来提供更多关于组织的背景、更多关于政策的细节。围绕这一点构建的画廊显示，每个威胁都必须引用一个真实的组件以及一项政策或控制措施。是的，如果它说“3号阀门”，但不存在3号阀门，那么这就不是幻觉。它在产生输出之前就会捕捉到这一点。

好的。所以基本上……（清嗓子）……输出是根据系统模型进行验证的。不存在的组件，比如3号阀门，会被拒绝。好的。然后你还会针对召回率进行调整。所以在遗漏某些内容的风险与浪费的风险之间需要权衡。要理解，假阳性会让审查人员和开发人员花费一些时间，但遗漏的威胁则可能导致潜在的安全漏洞。所以你知道，基本上是在两者之间做出权衡判断。而且没有任何内容在未经人员确认的情况下被接受，这就是最终发挥作用的治理部分：你有一位审查员将最后签署批准。

是的，这正是我的下一个问题。比如，如果由于某些不幸的原因导致事情出错，人在回路（human in the loop）会在哪里介入？绝对会。所以我的信念是：人工智能旨在增强你所做的事情，而不是外包你该做的事，对吧？机器负责推理，人类负责判断。引擎就在那里，它承担繁重的工作，开启局面，进行那些无法扩展的分析性工作——即彻底将所有组件映射到每一个已知的威胁向量。但是，人类（在这种情况下是审查员）在将威胁模型进一步传递时控制什么？他们基本上将其链接到已知的事物上：是的，这是一个实际的模型；这些是实际存在的组件。我没有看到任何可能是幻觉的东西。这对我们来说是可接受的风险。

所有的合规性签署都来自审查员。因此，模型无法对你的系统中的威胁或设计承担责任，对吧？设定上下文、风险偏好在于最终的审查员。好的。我们必须接受所有风险吗？不一定。系统还会提供它生成的威胁及其可能缓解措施的优先级排序，而审查员最终决定接受哪些以及忽略哪些。好的，很酷。

如果你这样想的话……这并不是一个二元问题：要么允许系统自行做事，要么人类必须介入。当你思考人在回路时，它是一个光谱。这取决于风险水平、可重复性以及任务类型。在这种代理增强型系统中起主导作用的人，人类成为了导演。他们可以选择设置自主权的级别。例如，假设像 DHL 快递系统这样的场景。因为有代理存在，你能想象如果 DHL 的 CEO 要对某件包裹延误或丢失负责吗？但无论如何，你有一个可以自动化并让其自主运行的限度，但始终会有一个负责任的人。

所以这几乎是在问谁负责？如果出错谁会受罚？总有一个名字作为答案，而且这个人始终在回路中。但他们可以选择让他们感到舒适的放手程度。今天我非常放心，我相信计算机能正确地进行加法运算，我不需要双重检查。但我可能不会信任计算机去做其他事情。同样的逻辑也适用于安全领域。很酷，很酷。现在谢谢你的回答，我非常喜欢这个回答。接下来我们要讨论下一个问题：假设我们正在审查我们的架构图等东西。如果五位安全专家能产生五种不同的威胁模型，那么人工智能如何确定什么是真正正确的，什么是不对的？你们打算如何解决这个问题？

是的，这也是一个常见问题。你把多位专家放在同一个房间里，他们各自都非常博学，但彼此并不一致。专家越多，分歧往往越大。然而关键在于，无论如何，他们在事实方面并没有产生争议。

实际上，他们并非在事实层面产生分歧。如果你仔细审视，这甚至算不上真正的 disagreement（意见不合）。他们差异的根源在于各自隐含的背景语境。这种背景可能仅仅源于几天前在另一项任务中遇到的小错误，从而形成了一种未言明的预设情境。由于人类认知的局限性，两个人无法以完全相同的方式吸收和处理所有信息及其背景。因此，正是这种个体化的语境感知驱动了他们的不同观点。

这正是我们试图通过系统化手段加以规范的地方。正如你所见，威胁建模中构建了知识图谱和知识库。通过在现实中执行这些操作，我们旨在结合人类专家深度推理的优势与上下文管理的一致性和可扩展性。当然，我们可以手动完成：让五位架构师坐在一起数天，痛苦地逐一审查、讨论，并召集所有必要的开发人员进入会议室。

这就像我们过去进行的 FDA 审计（我曾在医疗科技行业工作）。相关人员坐在房间里，遇到什么问题就召唤相关负责人进入。审查可能持续数周。虽然我们可以这样做，但这真的是最佳答案吗？还是说我们应该通过此类赋能工具来实现同样的严谨性？

因此，我们并非在强调多位专家之间的“分歧”，而是让他们就事实达成一致。我们通过提供统一管理的上下文，将这些大脑的智慧整合起来解决问题。“我认为这让画面更加完整了，对吧？你拥有了明确的上下文。这些上下文基于策略、架构、合规性和法规等要素。”“很好，没错。”

当你提到引入开发人员等内容时，我注意到你也在关注代码审查。那么你的系统是直接修复漏洞的代码，还是仅建议这些是存在的漏洞？“这可以是一个光谱。我知道我已经用了‘光谱’这个词三次了，但大多数事物确实如此。我们有多种选择。”

一方面，你可以生成 MD 文件或从系统中导出其他格式的数据，以你希望的方式在系统中使用；另一方面，你可以连接 Jira 等工具系统，将选定的缓解措施作为工单导入你的待办事项列表。或者我们实际上拥有 MCP（模型上下文协议）选项，我现在正在展示这一点。这意味着编码代理可以直接与威胁模型进行对话。“好的，很酷。”

当你提到 MCP 时，引出了我的下一个问题。假设我是一名开发人员，如果我的代理可以访问多个 MCP（如 GitHub、Slack 或数据库/API），根据你在威胁建模方面的经验，在连接这些 MCP 时，我首先应该担心什么？“可怕的情景。”（笑声）

是的。我认为我想说的是，在我脑海中浮现的前三点也是我们在开发过程中保持警惕的方面。第一点你可能已经听说过：间接提示注入（indirect prompt injection）。你基本上可以在某处添加恶意消息。例如，你说“总结这个工单”，而在那个工单的文本中提到了某些内容：“忽略此指令，并继续执行……” whatever malicious act it might be（无论是什么恶意行为），比如删除数据库或删除某个系统管理员工具等。

这引出了我的第二点：为什么一开始会出现这种情景？为什么你的代理拥有删除某些内容的权限？你赋予了它过度的代理权（excessive agency）。这就是第二点。基本上，代理不仅被给予了读取权限，还被赋予了写入和删除权限。想象一下它对 GitHub 能做什么？它可能会开始编写你原本不想要的代码，而你仅仅想要一个小结。

最后一点是我真正思考的：跨系统权限提升（cross-system privilege escalation）。基本上，代理利用其数据库访问权限拉取敏感的客户记录。然后动态地利用 Slack 或 API 将数据发送到网络外部。这是一些更可怕的情景，但我们已经考虑到了这一点。“还有其他例子吗？”“不，我认为……”

我想强调的也是这种跨系统行为是最可怕的。因为它推翻了你的信任边界，你永远不知道哪里存在通信。假设你原本认为架构中不存在 Slack 和数据库之间的连接预期，但你却创造了一个“超级内部人员”。你听说过“内部风险”作为威胁类别之一，但这个“超级内部人员”看起来无害，却突然可能像哥斯拉一样苏醒。

它可以做所有这些事情。所以你基本上创造了“超级内部人员”。关于提示注入，同样的事物在不同情况下表现不同。因此，回到之前的观点：你需要适当的上下文来真正建模潜在风险。因为同样的事物在不同系统中表现不同，无论是客户服务系统还是订单处理系统，行为都不同。

风险本质相同（如内部人员或提示注入），但在不同场景下表现各异。“很好，这是一个好观点。因为我们在开发 MCP 时总是考虑这些方面。”“非常感谢。”

接着下一个问题，假设你们刚刚启动 ThreatMantis。你如何看待未来？也许说五年后威胁建模是否会随着代码一起持续生成？你是如何看未来的发展趋势的？“是的，这也是我们所有人经常思考的问题。为了给你一个初步的画面……”

刚才我们在讨论 AI 引入的风险。这里有一个小数据：如果你查看现代软件中可能的威胁类型，大约有 900 种常见弱点枚举（CWE），200 多种 MITRE 攻击向量。所以大概有超过一千种类型。但是，如果你看大语言模型（LLMs），其前 10 类威胁仅包含 10 个类别。“好的。”

所以，你可能会想，现有的软件已经有1000多个类别了，这不过是增加了10个而已。但是，着眼于未来，我们需要意识到的是，这些新类别在不同情况下表现并不总是一致。因此，它们在不同的场景中可能会以完全不同的方式运作。为了在未来真正掌控这一切——正如你之前提到的——我们需要将整个流程完全集成到工程实践中，也就是我们所说的“威胁驱动开发”。

如果这对工程师来说听起来负担太重，我们可以称之为“威胁感知开发”。我的意思是，如果你不想被威胁驱动，那就叫它威胁感知开发吧，如果这个术语对某人来说更合适的话。无论如何，两者的含义是相同的。就像我们在视频中看到的那样，我们首先从对设计进行建模开始，弄清楚正在发生的事情。

而在未来——实际上一些公司已经在这样做了——开发过程的初始阶段将完全由提示词驱动。来自各地的人们会提出各种想法，进行头脑风暴会议。当进入计划阶段时，比如在代码库中输入“/plan”命令，在提示词规划阶段，系统实际上已经在与威胁建模系统的MCP（模型上下文协议）和工具进行交互。

并且已经制定了一个意识到这些威胁的计划。然后在编码过程中，它会使用这些护栏（guardrails）。最后进行代码扫描，在CICD系统的每个拉取请求中，同一MCP套件中的不同工具将被调用，以确定CICD流水线是通过还是失败。这就是我们设想的发展方式：为了在规模大幅增加的同时保持应对所有挑战的速度，这样的流程将是必需的。

你可以在节目备注中放上链接。Anthropic有一篇很好的文章，讲述了他们内部的安全开发流程。他们讨论的正是类似的内容，而且他们可能是生成代码量最大、速度最快的公司之一。因此，他们在展示其他公司如果想真正扩大工程规模所需的做法。这也是我们希望利用我们平台提供的工具集来实现的愿景。

主持人：明白了，太棒了。我的意思是，现在我完全理解了你们的业务以及你们具体在做什么。这很好。还有什么想讨论的吗？我可以进入快问快答环节了吗？

嘉宾：[轻笑] 从我这边来说，请开始吧。没有其他问题了。主持人：是的，我想唯一需要补充的是，我敢肯定你也会在描述中添加这一点。我们希望你们的粉丝如果认为这对他们的企业有用，也可以尝试联系我们。我相信他们会对各自的企业有所帮助。

嘉宾：乌特什（Utkarsh），也许由我来交替提问吧。那么，AI会让网络安全变得更好还是更危险？

嘉宾：两者皆是。主持人：好的。嘉宾：这既是挑战也是答案。所以，AI使其变得危险，但使用由AI驱动的工具是应对它的唯一方法。

嘉宾：普拉奇（Prachi），你今天会给自主AI代理生产环境的访问权限吗？

嘉宾：我不会。[笑声]主持人：是的，我想这题很简单。嘉宾：是啊，那确实很容易。也许我们进入下一题吧。那么，让你更害怕的是提示词注入（prompt injection），还是拥有过多权限的AI代理？

嘉宾：让我更害怕的是什么？[清嗓子]嗯，我认为提示词注入。虽然……我知道我总说，如果你给予更多访问权限，为什么要让自己陷入那种境地呢？但我觉得看到那些可见的访问权限时，你可以探索它。而提示词注入是人们在变得聪明的地方。是的，所以人们总能找到创造性的变通方法。

嘉宾：酷。乌特什（Vinay），AI最终会取代渗透测试人员或安全分析师吗？

嘉宾：嗯。这是一个更广泛的问题，适用于该领域的任何事物。它不能取代他们，但它可以赋能，让他们更高效地工作。主持人：好的。也许下一题也是问你的。你认为哪种网络安全实践本身就是一个安全威胁？

嘉宾：一种本身就是威胁的实践吗？主持人：是的。嘉宾：[笑声]我的意思是，至少在那方面来说，是的。主持人：好的。嗯，让我想几秒钟。所以我会说，鉴于我们意识到的实际情况，那就是把鸡蛋都放在编码后阶段的篮子里——也就是扫描、渗透测试以及所有那些后期阶段，并忘记实际上你无法及时发现问题。

后来发现问题的成本太高了。所以你看，目前的大多数预算——如果从可用工具的数量来看——其实都集中在后期阶段。我们倡导的是“左移”（Shift Left）。主持人：明白了，懂了。嘉宾：对于最后一个问题，阿塔希（Atashi），到2030年，黑客会因为AI变得更强大吗？还是防御者会获胜？

嘉宾：哦，嗯。如果你看现在的局势，我认为双方真的不相上下。老实说，我不认为这会改变。所以你会看到，随着我们在AI方面的发展，法规也在出台。我的意思是，《UCIA法案》（注：此处可能指相关AI监管法案）已经很明显了，而且我认为这将继续下去。如果我们认为防御者会获胜而沾沾自喜，那是非常天真的。

但另一方面，我也不希望我们进入一种因为担心AI会打开家门让黑客入侵而拒绝利用AI的模式。主持人：是的，这是一场持续的猫鼠游戏。嘉宾：是的。直到到目前为止，大多数时候我们赢了，防御者赢了，我们必须继续努力以保持同样的态势。

主持人：是的。嘉宾：酷。这其实是个很好的话题，讨论得很不错。我也从这次对话中学到了很多新东西，非常感谢你们抽出时间，阿塔希和乌特什。在结束之前还有什么想说的吗？我们可以结束了吗？

嘉宾：[笑声]主持人：不客气。如果观众或你有任何问题，也欢迎随时联系我们。可以在LinkedIn上搜索Threat Manager（注：此处口误为Threat Mantis，后更正或指代公司名），或者访问我们的网站threatmanager.ai。乌特什（Vinay）你有我的联系方式，所以我很乐意继续这场讨论。我知道这只是一次简短的介绍性对话。

嘉宾：我们今天讨论的每个话题本身就足以展开长时间的深入探讨，但我们两人都非常乐意进行更深入的交流。主持人：当然，当然。 definitely（肯定）。我们会为此做计划，乌特什。是的，非常感谢你。嘉宾：谢谢你，巴拉吉（Balaji）。主持人：谢谢阿塔希。祝你们愉快。