Claude 托管代理指向下一个AI基础设施层：公司大脑

Claude托管代理是AI堆栈发展方向的一个有用信号。Anthropic将托管代理描述为预构建、可配置的代理基础设施，Claude可以读取文件、运行命令、浏览网页、执行代码并连接到MCP服务器，而开发者无需从头构建代理循环、沙箱或工具执行层（Claude API文档）。在快速入门中，运行时环境会预配一个容器、运行代理循环、在容器内执行文件写入、bash命令和工具调用、流式传输事件，然后在会话结束时进入空闲状态（Claude API文档）。

这应该让我们有所领悟。即使是代理也在从“每个人都自己构建循环“转向托管原语。表面上看起来很神奇的东西，实际上是底层的基础设施：会话、容器、工具、文件、事件、权限和状态。

我认为下一层是公司大脑（Company Brain）。我不是指公司聊天机器人或带有更好搜索功能的知识库。我指的是让每个应用、代理、工作流和人类决策面都基于相同的公司状态来行动的基础设施层。

这就是我们在Sentra正在构建的东西。我越深入研究这个问题，就越相信人们所说的“代理记忆“实际上就是公司大脑的开端。本文延续之前的系列：第1部分、第2部分、第3部分、第4部分、第5部分、第6部分和第7部分。

Claude在这里做了一个富有意味的举动。其文档将记忆描述为一种让Claude能够在跨对话中存储和检索信息、随时间构建知识库、维护项目上下文以及从过往交互中学习的方式（Claude API文档）。托管代理的记忆文档将记忆存储描述为工作区范围内的文本文档集合，这些文档可以附加到会话中、挂载到/mnt/memory/目录下，并由代理使用常规文件工具进行读写（Claude API文档）。

这个方向是正确的。但知识库不等于公司大脑。知识库存储有用的信息。公司大脑维护运营状态。它必须知道发生了什么、为什么重要、谁看到了、哪个来源是可信的、随后采取了什么行动、哪个权限适用、以及公司应该从结果中学到什么。

那不是存储。那是基础设施。

应用误区

任何正经公司的第一反应都会是构建自己的公司大脑。这种反应可以理解。数据是敏感的、工作流是奇怪的、权限是混乱的、词汇是公司特有的。没有一个外部系统能够简单进入并理解公司是如何运作的。

所有这些都不假。但这仍然不意味着每家公司都应该从头开始构建底层基座。这就是“氛围编码“（vibe coding）制造虚假自信的地方。氛围编码是真实存在的，我经常使用这些工具。一个小团队可以比以往任何时候都更快地构建一个内部AI应用原型：连接Slack、Drive、Jira、Salesforce、GitHub和会议转录；创建嵌入；添加图谱；在上面放一个聊天框。有人问“这个客户发生了什么？“，答案足够好，让每个人都向前倾倒。

那个演示很有诱惑力，因为它让人觉得这个东西已经存在了。但基础设施不是靠第一个答案来评判的。它是靠六个月后的写入、权限变更、陈旧文档、重复客户、重命名项目、冲突来源以及同时行动的代理来评判的。

一个应用可以在混乱中仍然有用。基础设施必须能够承受被依赖。

Markdown大脑只是原型

最近的markdown大脑运动在方向上是正确的。Garry Tan将GBrain描述为一个开源设置，让代理能够对超过10,000个markdown文件进行回顾（Garry Tan）。Andrej Karpathy的LLM Wiki描述了一种模式，其中原始源被编译成LLM生成的markdown wiki，包含实体页面、概念页面、交叉引用、引用、健康检查和可以归档回wiki的答案（Karpathy）。

我喜欢这些想法。它们表明社区正在收敛到某个真实的东西上：持久的上下文应该是可读、可编辑、可版本化且接近文件的。Markdown是个人或小团队大脑系统的绝佳媒介，因为人类可以检查它、代理可以写入它、Git可以追踪它，并且整个系统保持可移植。

当大脑变成组织级时，扩展的边界就出现了。个人markdown大脑通常只有一个所有者、一个信任边界、一种对混乱的容忍度，以及一个最终仲裁者。如果模型写了一个糟糕的摘要，你可以修复它。如果两个页面相互矛盾，你决定相信哪一个。

公司可没有这么简单。他们有多个写入者、多个读取者、继承的权限、受监管的数据、陈旧的来源、冲突的团队，以及可能基于所读内容采取行动的代理。一个markdown文件可以保存信息。但它本身并不能决定谁可以看、哪个本体适用、是否过时、是事实还是解释、或者当两个代理同时更新相关状态时会发生什么。

这就是为什么文件隐喻虽有用但不完整。文件可以作为来源。而公司大脑是让文件、追踪、语义、本体、权限和行动协同工作的基座。

AWS的教训

云基础设施已经教会了我们这个模式。在AWS变得显而易见之前，许多公司认为基础设施太核心了，不能依赖别人。他们有服务器、基础设施团队、安全需求、合规要求和自定义工作负载。他们对基础设施重要性的判断没有错。他们错的是关于哪些部分具有差异化的判断。

AWS将云计算描述为通过互联网按需交付IT资源，公司可以访问计算、存储和数据库等服务，而不是购买、拥有和维护物理数据中心和服务器（AWS）。云并没有让基础设施消失。它让原语变得足够可靠，公司可以在堆栈的更高层进行构建。

公司大脑具有相同的形态。每家公司都需要自己的本体、策略、权限模型和判断力。但是，将工作转化为持久、可检查的公司状态的那个基座，并不是每家公司都应该从零开始重建的。

错误在于认为选择要么是通用大脑，要么是全内部大脑。更好的架构是共享基础设施加上公司特定的本体。

工具访问不是公司大脑

MCP是当前AI堆栈中的一个重大步骤。模型上下文协议（Model Context Protocol）文档将MCP描述为一个用于将AI应用程序连接到外部系统（包括数据源、工具和工作流）的开源标准（Model Context Protocol）。Anthropic将MCP引入为一种开放标准，用于将AI助手连接到数据所在的系统，包括内容存储库、业务工具和开发环境（Anthropic）。

代理需要工具。他们需要读取文档、搜索Slack、查询数据库、检查工单、调用API并写回记录系统。工具访问将成为每个严肃的企业代理堆栈的一部分。

但工具访问不是公司大脑。这里有一个陷阱。一家公司将代理连接到MCP服务器，让代理搜索几个系统、获取一些文档、总结结果，然后就称之为大脑。这演示起来效果很好，因为代理现在可以查找东西了。但是代理每次行动时仍然在重建公司。

那是查询时的上下文。代理启动一个任务、调用工具、搜索系统、拉取文档、读取工单、检查转录，然后即时组装上下文。这感觉很灵活。但它也很慢、昂贵、难以验证，并且容易遗漏重要的东西。

公司大脑应该以不同的方式工作。上下文图谱应该已经作为维护好的状态存在。会议、消息、工单、文档、客户电话、决策和行动应该在发生工作时更新大脑。然后，当代理需要行动时，它不需要从头发现公司。它是在公司的当前状态下运行，并附带了来源和权限。

困难的部分是状态

读取已经够难了。写入才是内部构建转变为基础设施的地方。Claude的记忆工具文档描述了一个基于文件的目录，Claude可以在其中创建、读取、更新、删除和重命名文件，应用程序在客户端执行操作（Claude API文档）。同一份文档说开发者应该将记忆操作限制在/memories目录内，并通过验证路径和拒绝像../这样的遍历模式来实现路径遍历保护（Claude API文档）。

这些细节是基础设施问题的开始。现在想象一家公司，多个代理和人类同时写入同一个大脑。一个支持代理更新客户风险。一个销售代理写下后续行动。一个产品代理更改了一个功能请求的状态。一个人编辑了源文档。一个Slack线程与昨天的摘要相矛盾。

当两个代理写入同一状态时，谁胜出？什么被版本化？什么被标记为过时？如果一个代理写下了错误的解释，而另一个代理后来当作事实来读取，会发生什么？如果一个用户可以看到工单，但看不到解释它的客户电话，又该怎么办？

这就是为什么“我们只要存笔记“不再奏效。公司大脑需要并发控制、来源追踪、权限传播、本体绑定、行动追踪、评估、删除策略和冲突处理。这些不是在演示之后才添加的功能。它们是系统可以被信任的原因。

Sentra正在构建什么

重点不是公司应该外包对自己的理解。公司应该拥有那些表达它们如何运作的东西：本体、权限、可信来源、工作流和判断力。

Sentra正在构建这种所有权之下的基座。文件仍然是来源。语义提取其中的内容。本体应用视角。图谱维护跨工件、交互、决策和行动的追踪。权限决定谁能看到什么。评估告诉我们代理在行动之前是否真的拥有正确的上下文。

这就是为什么公司大脑应该是基础设施，而不是一个应用。应用位于其上：CEO界面、管理者界面、个体贡献者界面、支持代理、销售代理、工程代理、客户跟进工作流、升级工作流、规划工作流。相同的基础公司状态应该通过不同的视角服务于所有这些。

最终胜出的公司不会是那些内部AI演示最多的公司。而是那些能够足够快地将工作转化为公司状态、让人和代理都能基于它行动的公司。这并不意味着每家公司都必须构建这个基座。

拥有本体。拥有策略。拥有判断力。但不要把公司大脑和另一个应用混淆。它是应用将运行其上的基础设施层。

第1部分：为什么大多数公司有数据但没有记忆 第2部分：事实记忆 第3部分：交互记忆 第4部分：行动记忆 第5部分：记忆是状态，不是服务 第6部分：构建公司大脑的经验教训 第7部分：大脑需要语义和本体

在Sentra，我们正在构建只能被称为“公司大脑“的东西——一个共享的智能/记忆层，它位于所有通信渠道、知识库、行动和代理追踪之上，以理解组织中每个人实际如何工作以及工作实际是如何完成的，几乎实时地构建整个公司的活体世界模型。