Ashwin Gopinath 认为 Claude Managed Agents 是 AI 技术栈走向的有用信号。
Anthropic 将 Managed Agents 描述为预构建、可配置的 Agent 基础设施，Claude 可以在其中读取文件、运行命令、浏览网页、执行代码和连接 MCP 服务器——无需开发者从头构建 Agent 循环、沙箱或工具执行层。Quickstart 中，运行时配置容器、运行 Agent 循环、在容器内执行文件写入、bash 命令和工具调用、流式传输事件，然后在会话结束后变为空闲。
这应该告诉我们一些事情。即使是 Agent 也在从"每个人自己构建循环"转向托管原语。 表面上看起来神奇的东西实际上是底层基础设施：session、container、tool、file、event、permission 和 state。
下一层：公司大脑
Ashwin 认为下一层是 Company Brain。不是公司的聊天机器人，也不是带更好搜索的知识库。而是让每个应用、Agent、工作流和人类决策表面从同一公司状态行动的基础设施层。
这是 Sentra 正在构建的东西。人们称之为"Agent 记忆"的东西实际上是 Company Brain 的开端。
Claude 在这里做了一个 telling move。其文档将 Memory 描述为 Claude 跨对话存储和检索信息、随时间构建知识库、维护项目上下文和从过去交互中学习的方式。Managed Agents 记忆文档将 memory stores 描述为工作空间范围的文本文档集合，可以附加到会话，挂载在 /mnt/memory/ 下，由 Agent 用普通文件工具读写。
方向是对的。但知识库不等于公司大脑。 知识库存储有用信息。公司大脑维护运营状态。它必须知道发生了什么、为什么重要、谁看到了、哪个来源可信、什么行动跟随、哪个权限适用、公司应该从结果中学到什么。
这不是存储。这是基础设施。
应用错误
任何严肃公司的第一个本能将是构建自己的 Company Brain。这种本能可以理解。数据敏感、工作流奇怪、权限混乱、词汇公司特定。没有外部系统能简单地走进来理解公司如何运作。
全部 true。但这仍然不意味着每家公司都应该从头构建底层。这就是 vibe coding 制造虚假信心感的地方。Vibe coding 是真实的，Ashwin constantly 使用这些工具。小团队可以比以往更快原型化内部 AI 应用：连接 Slack、Drive、Jira、Salesforce、GitHub 和会议记录；创建 embeddings；添加图；顶上放聊天框。有人问"这个客户发生了什么？"答案好到让所有人 lean forward。
那个 demo 是 seductive 的，因为它感觉东西存在了。但基础设施不是由第一个答案评判的。它是由六个月的写入、权限变更、陈旧文档、重复客户、重命名项目、冲突来源和同时行动的 Agent 之后发生什么来评判的。
应用可以有用同时 messy。基础设施必须 survive being depended on。
Markdown 大脑是原型
最近的 markdown-brain 运动方向正确。Garry Tan 将 GBrain 描述为 Agent 对 10,000+ markdown 文件有 recall 的开源设置。Andrej Karpathy 的 LLM Wiki 描述了一种模式，其中原始来源被编译成 LLM 生成的 markdown wiki，有实体页面、概念页面、交叉引用、引用、健康检查和可以归档回 wiki 的答案。
Ashwin 喜欢这些想法。它们显示社区正在 converge 于某种真实的东西：持久上下文应该是可读、可编辑、可版本化和接近文件的。Markdown 是个人或小团队大脑系统的伟大媒介，因为人类可以检查它、Agent 可以写它、Git 可以跟踪它、整个东西保持可移植。
Scaling boundary 出现在大脑变成组织级时。 个人 markdown 大脑通常有一个所有者、一个信任边界、一个 messiness 容忍度和一个最终仲裁者。如果模型写了 bad summary，你可以修复它。如果两页矛盾，你决定相信哪个。
公司没有那种简单性。它们有多写者、多读者、继承权限、监管数据、陈旧来源、冲突团队和可能基于读到的东西采取行动的 Agent。Markdown 文件可以 hold 信息。它本身不决定谁可以看、哪个本体适用、是否陈旧、是事实还是解释、或两个 Agent 同时更新相关状态时发生什么。
这就是为什么文件隐喻有用但不完整。 文件可以是来源。公司大脑是让文件、轨迹、语义、本体、权限和行动一起工作的底层。
AWS 教训
云基础设施已经教过我们这个模式。在 AWS 变得明显之前，许多公司认为基础设施太 central 以至于不能依赖别人。它们有服务器、infra 团队、安全需求、合规要求和 custom workloads。它们对基础设施的重要性没错。它们错在哪些部分是差异化的。
AWS 将云计算描述为通过互联网按需交付 IT 资源，公司可以访问 compute、storage 和 database 等服务，而非购买、拥有和维护物理数据中心和服务器。云没有让基础设施消失。它让原语可靠到足以让公司在堆栈更高处构建。
公司大脑有相同的形状。 每家公司都需要自己的本体、政策、权限模型和判断。但将工作转化为持久、可检查的公司状态的底层不是每家公司都应该从零重建的东西。
错误在于认为选择是 generic brain 和 fully internal one 之间。更好的架构是共享基础设施 + 公司特定本体。
工具访问不是公司大脑
MCP 是当前 AI 技术栈的重大一步。MCP 文档将其描述为连接 AI 应用到外部系统（包括数据源、工具和工作流）的开源标准。Anthropic 将 MCP 介绍为将 AI 助手连接到数据所在系统的开放标准，包括内容仓库、业务工具和开发环境。
Agent 需要工具。它们需要读取文档、搜索 Slack、查询数据库、检查工单、调用 API 和写回记录系统。工具访问将是每个严肃企业 Agent 技术栈的一部分。
但工具访问不是公司大脑。 这里有陷阱。公司连接 Agent 到 MCP 服务器，让 Agent 搜索几个系统、获取一些文档、总结结果，并称其为大脑。它会 demo well，因为 Agent 现在可以查找东西。但 Agent 仍在每次行动时重建公司。
那是 query-time context。 Agent 启动任务、调用工具、搜索系统、拉取文档、读取工单、检查记录、on the fly 组装上下文。它感觉灵活。它也慢、贵、难验证、易遗漏重要东西。
公司大脑应该不同工作。 上下文图应该已经作为 maintained state 存在。会议、消息、工单、文档、客户电话、决策和行动应该在工作发生时更新大脑。然后，当 Agent 需要行动时，它不是从零发现公司。它从公司的当前状态操作，附带来源和权限。
困难的部分是状态
读取已经够难了。写入是内部构建变成基础设施的地方。
Claude 的记忆工具文档描述了一个基于文件的目录，Claude 可以在其中创建、读取、更新、删除和重命名文件，应用程序在客户端执行操作。同一文档说开发者应该将记忆操作限制在 /memories 目录，并通过验证路径和拒绝像 ../ 这样的遍历模式来实现路径遍历保护。
那些细节是基础设施问题的开端。 现在想象一家多 Agent 和人类写入同一大脑的公司。支持 Agent 更新客户风险。销售 Agent 写跟进。产品 Agent 改变功能请求状态。人类编辑来源文档。Slack 线程与昨天的总结矛盾。
谁赢当两个 Agent 写入同一状态时？ 什么被版本化？什么被标记为陈旧？如果 Agent 写了错误解释，另一个 Agent 后来作为事实读取，发生什么？如果用户可以看到工单但看不到解释它的客户电话，发生什么？
这就是为什么"我们就存笔记"停止工作。 公司大脑需要并发控制、来源追溯、权限传播、本体绑定、行动轨迹、评估、删除政策和冲突处理。那些不是 demo 后撒上的功能。它们是系统可以被信任的原因。
Sentra 的构建
关键点不是公司应该外包对自己的理解。公司应该拥有表达其运作方式的东西：本体、权限、可信来源、工作流和判断。
Sentra 正在构建所有权之下的底层。文件保持为来源。语义提取内部内容。本体应用视角。图维护跨 artifact、交互、决策和行动的轨迹。权限决定谁可以看到什么。评估告诉我们 Agent 在行动前是否实际拥有正确的上下文。
这就是为什么公司大脑应该是基础设施，不是应用。 应用坐在上面：CEO surface、manager surface、IC surface、支持 Agent、销售 Agent、工程 Agent、客户跟进工作流、升级工作流、规划工作流。相同的基础公司状态应该通过不同 lens 服务所有它们。
获胜的公司不会是拥有最多内部 AI demo 的公司。它们会是将工作转化为公司状态快到足以让人类和 Agent 从中行动的公司。 这不意味着每家公司都必须构建底层。
拥有本体。拥有政策。拥有判断。但不要将公司大脑与另一个应用混淆。它是应用将坐在上面的基础设施层。