Transcript
00:00:00好的，大家都能看到吧。
00:00:15大家好。
00:00:17谢谢大家来参加。
00:00:18我今天要探讨的是，如果你着手
00:00:23构建一个公司大脑，它很可能会
00:00:25泄露公司机密，这也是我们对
00:00:28构建公司大脑一直以来的最大担忧，
00:00:32也就是实习生加入公司后
00:00:34突然获取了薪酬详情这类的情况。
00:00:36你得防范这种情况。
00:00:37你必须对此加以防范。
00:00:40我想这可以说是目前最大的问题所在，
00:00:43一直阻碍我们到处部署 OpenClaw
00:00:47和 Hermes。
00:00:49这也某种程度上说明了——
00:00:50就好像 ClaudeTag 在几天前的
00:00:52近期发布中迎来的巨大机遇，当时它
00:00:54本该成为公司的核心大脑，
00:00:56但随后每个人都觉得，嗯，它
00:00:57看起来——似乎成不了公司的核心
00:01:00大脑，对吧？
00:01:01所以我接下来要谈谈究竟是什么让它充满挑战。
00:01:03所以在进入正题之前，让我们先来了解和剖析
00:01:07这个公司大脑业务，好吗？
00:01:09我是 Tanmay。
00:01:10我是 PromptQL 的首席执行官兼联合创始人。
00:01:13大家以后可以了解一下 PromptQL，我们团队构建这个产品的背景是
00:01:18我们出身于 Hustle Graph——
00:01:21我们是 Hustle GraphQL 引擎的创造者。
00:01:23这是 GraphQL 领域一个非常受欢迎的开源项目，
00:01:26我们在其中解决了许多数据访问问题。
00:01:28我们将它部署到了从 Apple、Meta 到摩根大通等
00:01:32各个地方。
00:01:33这为我们奠定了深厚的基础，也让我们——
00:01:39对数据以及数据安全性产生了一种
00:01:43又爱又恨的复杂情感。
00:01:44因此，我将向大家展示我们过去一年一直在努力的成果，
00:01:51以及我们从中吸取的经验教训，这样你们就可以
00:01:53借鉴这些经验，并在实际中运用和尝试。
00:01:56当然，在演讲结束时，我也很乐意与大家
00:01:58交流心得，看看什么方法管用，
00:02:01或者什么方法可能对你们不太适用。
00:02:06在过去的一年里，我们只与一小部分
00:02:08在规模上表现出某种爆发增长的用户进行了合作。
00:02:12到目前为止大约有 15 到 20 家。
00:02:15现在我们正开始向其他人全面开放。
00:02:17但在这一过程中，我们观察了三种
00:02:20不同类型、需求截然不同的用户群体。
00:02:22一类是 AI 原生公司，他们愿意
00:02:25尝试任何方法，只要管用就行。
00:02:27还有一类是技术前沿公司，比如 Instacart 这样
00:02:30喜欢同类最佳技术的企业。
00:02:33所以他们行动迅速。
00:02:34他们也能容忍东西出问题。
00:02:36但它必须真的非常非常优秀，对吧？
00:02:38还有财富 100 强银行，他们有着极其严苛
00:02:41的最高级别安全标准。
00:02:43谢天谢地他们有，因为那是我的银行。
00:02:45我绝对不希望凭感觉编写的 AI 智能体在
00:02:48银行内部运行，因为我的钱就在那里。
00:02:51所以他们有非常多的安全规则。
00:02:54非常感谢。
00:02:55但我们也同样部署在类似这样的地方，
00:02:59作为公司品牌初期的核心或是
00:03:01前额叶枢纽，对吧？
00:03:02所以我们可以谈谈这些经验教训。
00:03:05我们自己构建公司大脑的实际应用中，
00:03:10规模大约是 5,000 页左右。
00:03:13所以我们把它建模为一个维基。
00:03:14你可以随心所欲地对它进行建模。
00:03:16你可以把它建模为 GitHub 上的一组 Markdown 文件。
00:03:17你可以把它放到，还记得 graph frag 吗？
00:03:21你可以把它建模在知识图谱中。
00:03:23你想怎么做都行。
00:03:25所以你可以把它放在任何你想放的地方。
00:03:27但对我们来说，它大约有 5,000 个相互连接的页面。
00:03:32这里有个问题要问大家。
00:03:33假设你有一个正在运行的公司大脑。
00:03:36而且运行得很好。
00:03:37一切都配置好了，对吧？
00:03:40这个公司大脑每天接收到的更新
00:03:41数量大概会是多少呢，对吧？
00:03:44因为它在不断学习公司里每个人的东西，对吧？
00:03:47对吧？
00:03:47从财务、人力资源，到你的工程师，涵盖所有人。
00:03:52所以，如果你把公司大脑每天发生
00:03:55的更新次数绘制成图表，它会长成什么样？
00:04:00它看起来会大致呈下降趋势吗？
00:04:04就像这些全都是随机图表一样。
00:04:05但它是会开始很高然后降下去呢？
00:04:09还是会保持平稳，随着更新激增而上下波动？
00:04:12或者它会稳步向上增长？
00:04:16所以我们可以思考一下，你的共享技能代码库
00:04:18的提交历史会是什么样子的，对吧？
00:04:21一个健康的公司大脑，每天到底会发生
00:04:26多少次更新，对吧？
00:04:27这种趋势是什么样的？
00:04:29有人选 A 选项吗？
00:04:31有人觉得是 A 选项吗？
00:04:33好的，酷。
00:04:34B 选项呢？
00:04:37C 选项呢？
00:04:39这挺有意思。
00:04:41所以当我把我们的数据绘制成图表时，对吧，
00:04:44为了看看健康的公司大脑是什么样的，
00:04:47如果你看第一种情况，它基本上是说，
00:04:50我们曾有过极高的热情。
00:04:53我们在第一天、第二天构建了公司大脑。
00:04:56我们给某人分配了任务，说：去吧，
00:04:57构建整个共享技能代码库，
00:04:59抓取所有的 Slack，抓取所有的电子邮件，把它建起来，
00:05:02然后我们大家都会用。
00:05:03然后就没人管了，对吧？
00:05:05或者你有一个能够自动学习的系统。
00:05:07也许你在内部部署了一个 Hermes。
00:05:09所以我看到的那种情况是，它在稳步地添加越来越
00:05:11多的注释。
00:05:12它会根据谁有热情而上下波动，对吧？
00:05:14对吧？
00:05:15然后当我绘制我们过去这两个月的
00:05:19历史数据时——现在这已经有点过时了——
00:05:22这就是我们得到的结果。
00:05:24我当时有点震惊。
00:05:26我在想，为什么它在持续增长？
00:05:30你看，这是一条平缓的曲线，对吧？
00:05:32但为什么它会平稳地持续上升呢？
00:05:34为什么每天的更新次数在不断增加？
00:05:38这对我来说是非常神奇的现象。
00:05:39因为我意识到，如果你有一个开始运转的系统，
00:05:42接下来人们就会开始教它更多的东西。
00:05:46这就好比，如果我今天教你查询数据的技能，
00:05:50那么明天我就会教你解读这些数据的技能。
00:05:53然后后天，我将
00:05:55教你如何基于这些数据采取行动的技能。
00:05:57再之后，我还要弄清楚
00:05:59如何基于这些进行A/B测试——所以像你这样的人
00:06:00会源源不断地添加更多内容。
00:06:03但因为一切都是代理，没有哪种学习是完美的，
00:06:05每样东西都有它自己的稳定速率，对吧？
00:06:08所以这些速率...
00:06:08甚至连你那稳定的速率也在不断累加。
00:06:10这就是我在我们自己的项目中开始注意到的情况。
00:06:12这还处于早期，所以谁知道它最终会不会逐渐减弱呢？
00:06:15也许它会开始变得更像B选项那样。
00:06:18但对于一个健康的大脑来说，整体规模当然会持续增长。
00:06:20而且你每天的更新量似乎也一直在增加。
00:06:24所以，这正是你构建了一个优秀大脑的征兆，对吧？
00:06:28一个你为公司打造的健康大脑。
00:06:32太棒了。
00:06:35接下来，我们通过公司大脑的使用场景
00:06:36来分析我们如何构建一个不会泄露机密的系统，对吧？
00:06:39这里有两个使用场景。
00:06:42第一个使用场景是，存在一个公司大脑。
00:06:44我想在我的AI、代理或任何东西中使用它来完成工作，对吧？
00:06:48我来给你们展示一个例子，好吗？
00:06:55就像我收到了一封客户发来的安全问卷邮件，
00:06:56我需要对其进行回复。
00:06:59然后我跟我的AI对话，我说：
00:07:00“查一下公司大脑，帮我回答这个安全问卷。”
00:07:03所以，这绝对是一个非常合理的公司大脑使用场景。
00:07:05第二个是非常有用的使用场景，对吧？
00:07:08因为这是其他人的知识正在传递给我。
00:07:10公司大脑的第二个使用场景有点类似于云标签（cloud tag），
00:07:14也就是多人协作（multiplayer）的概念。
00:07:18如果你一直把代理放在Slack中，让多个人
00:07:21都能与之交互的地方，它其实就被当成了一个共享的AI，对吧？
00:07:25就像是用它来把事情搞定。
00:07:29这其中的一个例子就是协作式事件管理，对吧？
00:07:32比如其中一个例子就是协同事件管理，对吧？
00:07:36所以举个例子，你想说，嘿，我想获取日志。
00:07:40去获取一些日志，调查代码库，提交PR，部署到测试环境，
00:07:42部署到生产环境，设置警报，对吧？
00:07:46你希望有多个人通过公司大脑来做事。
00:07:48所以，这些就是公司大脑的两种使用场景。
00:07:51一种是共享的协作知识使用场景，
00:07:53另一种则是共享AI本身的使用场景，对吧？
00:07:56这两种场景都带来了巨大的安全问题，对吧？
00:08:00因此，为了开始确保其安全，让我们更明确地定义这一点，好吗？
00:08:06那么，到底什么是公司大脑？
00:08:15这就是我给出的定义，对吧？
00:08:18它是你放进Markdown中的共享上下文，
00:08:20也就是你放在一组Markdown文件中的内容，对吧？
00:08:23它是赋予编码代理的、针对不同数据和工具的
00:08:26还有针对不同数据和工具的访问控制规则
00:08:29也就是你想让编程代理去访问的内容。
00:08:34因为我在发言，所以我可以随心所欲地定义。
00:08:38这就是我的定义。
00:08:41所以我并不是说，这是拉入LLM中来执行工具调用的知识，对吧？
00:08:42它不是一个从事通用任务的AI。
00:08:46它是一个解决你抛给它的任何问题的编码代理，对吧？
00:08:48这有点类似于你们大家可能听过的之前的演讲，
00:08:51也就是这个想法：我们能否只用一个编码代理来解决通用问题？
00:08:56就是这样，对吧？
00:09:00在最琐碎的情况下，如果你说，嘿，帮我写条推文，你其实是在写一个调用AI来写小推文的小脚本，对吧？
00:09:04你可能没必要这么做。
00:09:05在最简单的例子中，如果你说，嘿，帮我写条推文，你其实是在写一个调用AI来写简短推文的小脚本，对吧？
00:09:13你可能没必要这么做。
00:09:14AI本身就可以直接把推文返回给你。
00:09:17但基本上，Claude code被用在了所有地方。
00:09:20Claude co-work也是同样的架构。
00:09:22Codex应用也是同样的架构，也就是意识到你可以利用编码代理来解决通用问题。
00:09:28所以我们正在为此构建大脑。
00:09:30我们不是在为公司构建庞大的知识图谱、知识库，然后再试图去保护它。
00:09:34那样做无论如何也行不通——过去没行不通——以后也行不通。
00:09:39所以，就我们如何想要探讨设计公司大脑的方式而言，我们真的应该构建一个公司大脑吗？
00:09:50所以，如果你是一家企业，而你的薪水就是拿来无所事事的，那你就会喜欢构建公司大脑这个主意。
00:09:57因为你会想，太好了，让我接手一个为期两年的项目，我要为摩根大通构建公司大脑。
00:10:02这是不可能发生的。
00:10:03你根本无法为一个拥有100年历史的组织构建公司大脑，对吧？
00:10:07你连为自己成立几个月或几年的家庭构建它都很勉强，对吧？
00:10:13所以，构建公司大脑的理念和方式是，我们希望公司里每一个承担一小部分工作的人，都能拥有并构建他们那部分的专属公司大脑，对吧？
00:10:23这才是我们应该构建的方式。
00:10:25所以这就是我提出的第二个限制条件。
00:10:27第一个是公司大脑的定义，第二个是我们希望采取的构建公司大脑的方法。
00:10:33我比较喜欢这样表述，也就是我们将“培育”一个公司大脑，而不是去“建造”一个，对吧？
00:10:41我们要让它自然成形。
00:10:43让它自然凝聚。
00:10:44这个系统需要自然汇聚，否则根本无法建造。
00:10:47好了。
00:10:48总的来说，我们希望让每个人自主维护自己那部分的微型公司大脑，这些就是你想要遵循的各种步骤。
00:10:57如果你有时间的话，我待会儿会详细展开，但让我们先从一个特定的用例开始，对吧？
00:11:03所以在这一特定的用例中，我有这样一种情况，这也是我想带给各位的具体实例。
00:11:12我收到了一封邮件，就拿安全问卷举个例子，对吧？
00:11:15嘿，我收到了Stitch Fix公司戴夫（Dave）发来的一封邮件，里面有一堆我想回答的问题，对吧？
00:11:20于是它调出了我的邮件，显示邮件里包含他们安全入职流程的截图，然后它开始着手回答这些问题，对吧？
00:11:30我完全不知道它是怎么知道的。
00:11:32看到它回答了所有关于“嘿，这是我们的信任中心，这是我们的安全状况，他们有一个网关”之类的问题，我感到非常惊讶，对吧？
00:11:40它在做一些事情。
00:11:41所有这些基本上都来自于公司大脑，也就是对这些问题的解答，然后我就觉得，嘿，直接把这个发送出去吧。
00:11:50我很喜欢这个草稿，直接把这个草稿发给戴夫，对吧？
00:11:53然后它就去把那封邮件发送了，这就是我想做的事情的一个非常简单的例子。
00:11:57现在，这里的挑战和问题在于，我们如何构建这样一个系统，让其他人可以为其贡献内容，同时又能被第三个人所使用呢？
00:12:13关于我们的安全状况的这些知识究竟是怎么录入进来的？
00:12:18据推测，以前应该有其他人也处理过同样的安全问卷，对吧？
00:12:22所以他们可能拥有一个Hermes代理或别的什么东西。
00:12:24他们当时正在处理它。
00:12:25你自动保存了一些记忆。
00:12:27也许有人写下了一项技能。
00:12:28不知何故，这一片段必须传送到我的AI代理中。
00:12:32我们要如何才能让这一点成为现实呢，对吧？
00:12:35现在，让我们来试试第一件显而易见的事情，也就是每个人都在GitHub上为彼此编写共享技能。
00:12:42所以，当你的安全人员第一次回答安全问卷时——大家都想象一下你们脑海中的安全与合规人员，对吧？
00:12:50现在，想象一下，他们在回答完问卷后，回答问卷可真是一件痛苦的事。
00:12:56在填完这份庞大的Excel表格问卷后，他们竟然还跑去GitHub更新了一个共享技能，对吧？
00:13:04你们当中有许多人很幸运，能和那些品德高尚、人好得像活菩萨一样、愿意主动去GitHub仓库更新共享技能的人一起工作，对吧？
00:13:16大多数人可不会这么做。
00:13:18没有人会在GitHub上为其他人编写技能。
00:13:24这不符合我们的天性，对吧？
00:13:27在日常工作中，我们不会突然决定说：哦，这可能对其他人很有用，哪怕那些人甚至我都不认识，在这种情况下也和未来毫无交集。
00:13:39这根本不可能发生。
00:13:40我连整理自己的记忆和上下文都快做不到了。
00:13:44我根本没有时间把它发给别人，或者为其他人把它写下来。
00:13:49第二，与其建立公司大脑，为什么不建立团队大脑呢？
00:13:53为什么你们不一起使用一个共享的？
00:13:55为什么安全团队不能使用一个更具共享性的数据孤岛来做这件事呢？
00:14:01所以，构建一个代理，让它自己保存到内存中，对吧？
00:14:04这大概就是各位目前采用的架构，可能还结合了类似在 Slack 中添加 Hermes 的做法。
00:14:09有没有人正在使用这种团队大脑，也就是多个人使用同一个 AI，它能自动保存记忆并自动添加上下文？
00:14:18有没有人已经拥有类似的功能，哪怕只适用于一个小团队？
00:14:23一个。还有其他人吗？好的。
00:14:24好，你们中有一些人有。这很酷。
00:14:26这很好，但问题是它仍然不是公司大脑，因为它依然是孤立的，对吧？
00:14:31所以它就像又一个孤岛，对吧？比如，如果配合 claw tag 使用，它具有按频道划分的内存，对吧？
00:14:40所以在每个频道中，它都会被保存，但现在它成了那个特定频道中的另一个孤岛，对吧？
00:14:46所以它再次被锁在了一个地方，无法在其他任何地方使用。
00:14:50因此，如果有人被拉进这个频道，它就能工作，否则就无法工作，对吧？
00:14:55这就是第三种选择。
00:14:59第三种选择是：所有上下文都进入一个单一的共享维基。
00:15:06维基是一组 Markdown 文件，而 Markdown 文件之间可以互相链接。
00:15:08所以试想一个巨大的文件夹。
00:15:10这个文件夹里有很多 Markdown 文件，对吧？
00:15:13而且 Markdown 文件之间可以互相链接。
00:15:16因此，所有的上下文，不是将它们保存在某个文件夹中或将它们孤立起来，
00:15:21而是把它们放入一个 Markdown 文件中，也就是 Markdown 文件的等价物，
00:15:25并让它们彼此链接。
00:15:28你要做的第二件事，是允许每个文件拥有作用域权限，
00:15:33来决定谁对该文件拥有读写访问权限。
00:15:38你要做的第三件事，也是最重要的一件事，
00:15:42就是不要让代理自动添加记忆。
00:15:49你不能让它自动添加，因为如果它自动添加了，你根本不知道发生了什么，对吧？
00:15:55你无法——我们又回到了那种老路子，某些内容被添加了进去，
00:16:00只要你刚好在那个代理的记忆范围内，你就走运了，对吧？
00:16:04所以你做的第三件事是，与其让代理自动添加，
00:16:07不如采取一种方式，让你的代理去建议应该添加什么内容以及对应什么作用域，
00:16:16然后由人类来选择接受或拒绝。
00:16:21所以它没有 GitHub 那么沉重，不需要我去编写、更新共享技能、
00:16:28做 PR 审查，然后等待合并。
00:16:30但它也不是那种由代理自动写入记忆的随性做法（YOLO），
00:16:36对吧？这是一个完美的平衡点：在你工作的同时，
00:16:40它弹出来，建议正确的作用域，并让某人将其添加进去。
00:16:45所以现在通过这个非常简单的补充，你能够让人们向一个巨大的维基中添加内容，
00:16:51但同时又让这个人对他们能看到或不能看到的内容承担责任。
00:16:57因此，如果我正在向财务维基添加内容，我想确保——如果我添加的是敏感内容，
00:17:01我想确保它具有财务作用域。
00:17:03如果我添加的是个人内容，我想确保它具有个人作用域。
00:17:06让我向你们展示一个这样的用户体验示例。这就是我们所做的。
00:17:15这是我最近收到的一封邮件，来自我们的一位销售代表，邀请我加入一个通话。
00:17:33我看了那封邮件，帮忙回复了它，然后我得到了一个小方框，里面建议了
00:17:39一堆要点，告诉我它将要添加什么内容，对吧？
00:17:43当我点击“添加到维基”时——现在审查正在添加的内容变得容易多了。
00:17:47我不在乎。我不在乎它是被加到这个 Markdown 文件还是那个 Markdown 文件，
00:17:52代理会处理好链接。我在乎的是：这些事实是否正确？
00:17:58如果这些事实是正确的，我就点击“添加到维基”，然后就完成了，对吧？
00:18:02而在添加到维基的过程中，我可以选择每个维基页面是否需要添加特定的作用域，
00:18:08对吧？因此，每个维基页面本身都可以获得一组确定的作用域，由你来决定
00:18:12谁能获得什么访问权限，例如，对吧？所以举个例子，我的邮件，这是我拥有的
00:18:17关于我的邮件以及邮件优先级排序的维基页面，我现在可以决定谁能访问它，
00:18:22谁是它的所有者，以及它的基于角色的访问控制（RBAC）是什么。所以系统具体长什么样
00:18:26由你们决定，但核心思想是：你要让代理去建议更改，
00:18:32而不是直接执行更改。好了。所以有两条规则。第一，确保所有内容都进入同一个
00:18:38公司级维基，绝对不要违背这条规则。第二，确保作为其中的一部分，
00:18:44每一项更改背后都有一个人的名字。维基里绝对不允许出现诸如“Claude 添加了此内容”
00:18:51或“你的 AI 代理添加了此内容”或“Hermes 添加了此内容”之类的信息。不，必须是 Tanmay 添加了此内容。这个名字必须存在，
00:18:57这样你就能追溯到：就是这个人搞砸了，允许所有人看到了
00:19:04所有人的薪酬之类的机密，对吧？然后你就可以采取纠正措施，
00:19:09无论那是什么。把他们放入绩效改进计划（PIP）。连维基都不会编辑。所以这一点非常、非常重要。
00:19:14而规则二，一旦你决定了这一点，你就可以进入第二个范畴，也就是
00:19:19好吧，你必须让人们轻松地完成这件事，这就是作用域机制发挥作用的地方，
00:19:23你希望根据谁能获得访问权限来对每个文件进行作用域划分。你将围绕它构建一个系统。
00:19:26它的架构图大致是这样的：用户与代理对话，
00:19:32代理在读取上下文时，会使用该特定用户的声明（Claims），对吧？
00:19:39所以如果我正在读取用于解决财务问题的内容，它会使用我的财务声明以我的身份进行读取，
00:19:46因为我有权访问财务维基，所以我可以读取它，并且每一次都是如此，
00:19:52对吧？所以代理总是使用用户的凭据来读取维基的正确部分。
00:20:00好了。第二个用例的时间我差不多用完了。所以我接下来要做的是，给你们快速介绍一下
00:20:06第二个用例的大致情况，但要将这个思路延伸开来。这是那个终极用例（daddy use case）。这就像是，
00:20:13这是一个真正复杂的用例，因为现在
00:20:17不只是一个人在回复一邮件。而是我们这群人一起使用共享上下文，
00:20:25在拥有不同升级权限级别的情况下同时解决一个问题，
00:20:31对吧？这些就是与 AI 的交互，在这些交互中会产生最大量的
00:20:36公司大脑知识，对吧？例如，我将向你们展示一个真实的简短示例，
00:20:42看看这对于我们来说是什么样的。这是一个 SRE（站点可靠性工程）场景中的案例，
00:20:50当时有人说：“嘿，我们的自动学习、维基学习（非常具有元编程色彩）失败了。它没有起作用。
00:20:57怎么回事？”对吧？然后它开始进行调查，结果很糟糕，因为它没有相关技能，失败了。
00:21:02于是（某人）说：“兄弟，别这样。请使用这个 OpenTelemetry 跨度（Span）名称。”
00:21:07（AI）使用了 OpenTelemetry 跨度名称后，表现稍微好了一点，但还是真的很慢。所以
00:21:13他看了看代码并说道：“哦，你用了 like 查询。你是个大笨蛋。”
00:21:18这是 opus 4.5 诶。“别这么干，”对吧？所以他接着说：“不要用 like 查询，
00:21:24要用 equals to（等于）查询，”对吧？然后（AI）执行了等于查询，浮现出了一些细节，
00:21:29接着他说：“哦，再深入挖掘一下这个。”（AI）便指出：不管怎样，这就是报错的代码行。
00:21:33很简单的事情，对吧？现在它浮现出了一些知识并说道：
00:21:39“啊哈，我学到了我应该用 equals to 而不是 like，”对吧？“我学到了如果在维基页面名称中
00:21:45添加自定义前缀，可能会导致问题，”对吧？嗯，所以它提供了这些你可以选择接受的经验教训。
00:21:50于是他继续深入挖掘，去探究问题究竟出在哪里。
00:21:56另一个人加入了对话，对吧？并说道：“我们在这里做出的技术决策是
00:22:02错误的。为什么会这样？”现在两个人开始争论起来，对吧？他们争论了起来。
00:22:09说：“嘿，不应该是这样的。应该这样。但为什么是这样？但它就应该是这样，”
00:22:12对吧？这种争论创造了知识，因为实际的问题是有人做出了
00:22:17一个没有被记录下来的技术决策，对吧？当他们决定修复该问题，
00:22:22并观察到这确实是根本原因，并决定这就是修复方式时：
00:22:26“嘿，我们应该移除这个导致问题的北缀，无论如何，不管具体是什么，”
00:22:31这就会创造出要添加到你大脑中的最高质量的上下文。因为先前的建议是
00:22:38“页面不应该有前缀”，但“页面带有前缀是一个问题”才是真正的事实。
00:22:44对吧？所以现在你要记录在大脑中的内容是：页面不应该有前缀。
00:22:49如果它们有前缀，可能会在生产环境中导致查找问题。当多个人互相交谈时就会发生这种情况，
00:22:54对吧？并且一起解决问题。这就是在 Slack 线程中当两个人互相交谈
00:22:59并解决问题时发生的事情。它创造了最高质量的上下文。但是，这也是你在这里所追求的。
00:23:05但挑战在于，围绕这一点的权限提升变得非常、非常严重。
00:23:10如果你正在构建一个可以被多个人包围并能做任何事情的代理，那就太可怕了。
00:23:18因为工程师原本只被允许做 PR 工作，但现在我可以使用同一个代理
00:23:23部署到生产环境。这就太可怕了。我不能一边进行对话调试，
00:23:29一边又安全地进行部署，对吧？特别是如果你在一家银行里，对吧？比如负责调试、
00:23:35部署到暂存环境、设置警报以及部署的人并不是同一拨人。但把他们合为一体
00:23:40有着巨大的价值，因为所有的知识都产生于此，对吧？因此这自然而然地把我们带到了
00:23:45第二种架构，我不会过多深入细节。但可以把它想象成相同的思路：——
00:23:49使用用户凭据和声明来读取上下文。除此之外，同样要使用用户凭据，
00:23:58对吧？当代码在执行工具时。所以永远不要将凭据存储在沙盒中。
00:24:05相反，在 HTTP 层、SQL 层注入用户的凭据，从而允许 AI 在特定的交互中
00:24:13表现得就像人类一样，对吧？这里有一些有趣的细节。但正是这一点
00:24:20让共享 AI 能够处理共享上下文，对吧？这些就是需要处理的两个关键部分。
00:24:25所以我会总结一下，这个架构并不是特别复杂，但是从这两条规则反推
00:24:30会非常简单。不要在云沙盒中存储凭据。第二，
00:24:36将与真实数据的所有交互虚拟化、代理化、虚拟化，无论你想用什么词，
00:24:41并让用户来控制它们。因此，添加特定工具的用户应该控制谁能获得
00:24:48对该特定工具的访问权限。所以，如果你遵循这四个原则并以此逆向推导，
00:24:53你就能推导整个体系。只有一种架构是可能的、合乎逻辑的，
00:24:58即你如何管理上下文、你设置了什么约束、你如何管理工具以及你设置了什么安全
00:25:02规则。我的时间到了。演讲结束后我很高兴能和大家多聊聊。我们也有一个展位，
00:25:10所以很高兴能通过展位进一步探讨这个架构内部的细微差别。我是 Twitter 上的 Tanmay Goh。
00:25:16我们公司叫 PromptQL。请多关注我们。归根结底，在 AI 工程社区中，
00:25:24我们要发布一款产品。所以我很乐意与各位、与大家分享这一点。
00:25:30我要和台下的所有人合张影，这样我就可以分享它了。所以趁我在这里，让我拍一张。
00:25:40好了。大家想说茄子吗？
00:25:45非常感谢。所以请关注这个。这是我们对 Cloud Tag 的方法，也就是 PromptQL Tag，
00:25:52它与我们在这里讨论的想法非常相似，除了你不会被困在 Cloud 上。
00:25:57你可以使用 GLM，也可以使用 GPT，然后 Sol 就会问世，我们就可以使用它并尽情享受了。
00:26:03所以一定要去看看。另外，我们不久后见。
00:26:19我们马上回来。