Claude实现了Agent记忆,但语义与本体仍是缺失的一环 Ashwin Gopinath 2026-05-08 13.8 KB 26.9K 264 ☆ 收藏 𝕏 文章列表 文章探讨了Anthropic最新发布的Claude“托管代理”中的记忆功能,指出虽然文件化的记忆存储为Agent提供了可检查、可跨会话持久化的基础,但仅有存储并不等同于理解。作者强调,真正的智能记忆需要“语义”(定义事物是什么)和“本体”(定义事物为何重要)。文章以企业场景为例,阐述了销售、法务、产品等不同部门对同一信息的不同理解视角(即本体),并提出企业AI的未来在于构建共享的底层记忆基座与上层可定制的领域本体(透镜层),从而让AI从被动问答转向主动提供上下文。 AgentClaude记忆系统本体论企业AI语义分析架构设计知识图谱 74 值得读 ▶ 文章结合最新Agent技术,深刻剖析了企业级AI记忆系统在语义和本体论上的缺失,创新性地提出了'底层存储与视角分离'的架构思想,逻辑清晰,极具启发性。 # Claude Made Agent Memory Real. But Semantics and Ontology Are Still Missing **作者**: Ashwin Gopinath **日期**: 2026-05-07T15:19:23.000Z **来源**: [https://x.com/ashwingop/status/2052407955086254262](https://x.com/ashwingop/status/2052407955086254262) ---  Claude’s newest Managed Agents announcement is a useful marker for where enterprise AI is going. Anthropic describes “dreaming” as a scheduled process that reviews agent sessions and memory stores, extracts patterns, and curates memories so agents improve over time; the same release also introduces outcomes and multiagent orchestration in Managed Agents (Claude blog). Anthropic’s memory docs describe memory stores as workspace-scoped collections of text documents that can be attached to a Managed Agent session, mounted into the session’s container under /mnt/memory/, and read or written by the agent with the same file tools it uses elsewhere (Claude API Docs). Anthropic’s memory launch post also says these memories are file-based, exportable, manageable through the API, and built with scoped permissions, audit logs, and rollback/versioning controls (Claude blog). That is exactly the right direction. Agents need memory they can inspect, edit, carry across sessions, and share under boundaries. A file-based memory store is especially interesting because it treats memory as part of the agent’s working environment rather than a black box retrieval service bolted on the side. But a place to remember is not the same as memory that understands. A pile of notes is storage. Useful memory needs semantics and ontology. Semantics tells the system what something is. Ontology tells the system why it matters from a particular perspective. Take a rock. Semantically, it is a rock: shape, weight, material, location, texture. But to a tired hiker, it is a chair. To a sculptor, it is raw material. To a geologist, it is evidence. To a construction crew, it is an obstacle. Same object. Same facts. Different perspective. Different meaning. Personal memory has this problem everywhere. “Call Ravi next week” is not useful unless the system knows what Ravi means to you. Is Ravi an investor, a friend, a student, a customer, a doctor, or a co-founder? The reminder has the same words in every case, but the memory should behave differently depending on the relationship. That is why personal memory is hard. A person’s ontology is fluid because we are many people at once. We are parents, friends, colleagues, patients, customers, managers, students, and founders, often in the same day. The same artifact can change meaning as the person changes frame. Organizations are different. They still have politics, ambiguity, and competing incentives, but they also have roles: sales, finance, legal, support, engineering, procurement, operations, leadership. Roles give organizational memory more stable ontologies. A supplier delay email has one semantic structure: vendor, purchase order, delayed item, original date, revised date, reason. To procurement, it is supplier risk. To finance, it is an accrual issue. To operations, it is a production delay. To legal, it may be contractual exposure. Same file. Same semantic facts. Different ontology. That is the point I want to make about Company Brain. Claude gives agents a place to remember. Sentra’s bet is that company memory also needs structure: files as source, semantics as extraction, ontology as perspective, and a permissioned memory graph as the substrate agents can use. The next chapter of enterprise AI will not be one assistant that knows everything. It will be a company that remembers enough for humans and agents to act from the same reality without forcing everyone to see that reality the same way. In Part 5, I argued that memory has to become shared semantic state rather than a feature inside individual tools. That argument was about the substrate. This piece is about what sits above it, because the substrate alone does not create adoption. The thing that creates adoption is the lens layer. The dominant enterprise AI playbook is still one assistant per company, with one company-wide model of how the work fits together. Even when companies invest heavily in that direction, adoption stays uneven. Sales uses it one way, product another, support barely at all, legal almost never, and leadership turns it into a search box. The interface looks unified, but the use does not. The reason is that the assistant is implicitly carrying one ontology. One ontology cannot fit how seven different functions actually see their work. Custom ontologies are the real path to organization-wide AI adoption. Adoption is not optimized by giving every employee the same assistant and hoping they prompt it well. That still asks people to translate their work into the AI’s interface. The better direction is the reverse: AI should understand the way each part of the company already sees the work. Sales thinks in accounts, stakeholders, objections, renewal risk, buying committees, and commitments. Product thinks in signals, roadmap tradeoffs, launch blockers, regressions, feature requests, and customer pain. Support thinks in severity, recurrence, workarounds, customer impact, escalations, and resolution paths. Legal thinks in obligations, approvals, exposure, redlines, and commitments. Leadership thinks in strategy, drift, execution gaps, ownership, and company state. These are not separate companies. They are different ways the same company understands the same work. The architectural move is to separate the substrate from the lens. The substrate is shared, permissioned, inspectable, and durable. The lens is functional, customizable, and per-vertical. A company defines a broad ontology of how it operates, and each function defines a narrower ontology of how it sees its slice. The substrate holds the same memory underneath. The lens decides what that memory means in context. This is also why file-based memory is such an interesting starting point, but not the whole destination. In Claude’s Managed Agents system, memory stores can be attached at session creation, and multiple stores can be attached when different parts of memory have different owners or access rules (Claude API Docs). That maps naturally to the enterprise problem because memory does not have one owner. Some memory belongs to a user, some to a project, some to a function, and some to the company. The harder question is how those memories become meaningful. If a customer issue is discussed in a meeting, appears again in a Slack thread, becomes a support ticket, triggers a sales concern, and later changes a roadmap priority, those should not become five unrelated memories. They should become one evolving memory with different traces: a support trace, a customer trace, a product trace, a revenue trace, an action trace, and a decision trace. Each trace exists because an ontology decided what mattered. When this becomes mature, the interface to AI changes. Most AI at work is still reactive. You open a chat box, ask a question, paste context, wait for an answer, and then go do the work. Even when the answer is good, the burden is still on you to know what to ask, where the context lives, and what should happen next. Mature company memory flips that script. The system already knows what happened across meetings, messages, emails, tickets, workflows, and actions. It knows what usually matters to your role, which ontology applies, which conditions changed, and what action may be available. So it can bring the work to you instead of waiting for you to go looking for it. That is the product shift I care about most: AI brings the context, the human makes the decision, and agents complete the task. It sounds simple, but it changes who carries the burden of context. A manager starts the day and sees that a customer commitment was made in a meeting last week but never became work. The system does not wait for the manager to search for it. It says what happened, where it came from, who was involved, why it matters, and what action is available. The manager makes the decision in thirty seconds. Without the substrate, that commitment gets surfaced two months later by an angry customer. A CEO sees that a strategic initiative is drifting because the decisions in leadership meetings are not matching the work being created in the operating teams. That is the kind of thing a dashboard usually misses because the dashboard sees metrics after the fact. Company memory can see the gap earlier because it remembers the commitments, the rationale, the handoffs, and the actions that followed or failed to follow. The CEO does not need a new report. The CEO needs the gap surfaced in the moment it opens. An agent working on a support escalation needs more than the latest ticket. It should know that the same issue appeared in a customer call, that sales promised a workaround, that product deprioritized the fix, and that the customer is up for renewal. The same memory looks different depending on whether the agent is briefing support, preparing an account executive, or warning product about roadmap risk. Proactive AI needs boundaries because the more useful it becomes, the more those boundaries matter. Ontology determines what matters. Permissions determine who can see it. Provenance shows where it came from. Action memory shows what has already been done. Humans approve the meaningful decisions. Agents execute within guardrails. Without those boundaries, proactive AI becomes noise or surveillance. With those boundaries, it becomes a way for the company to act from shared reality. Here is the bet I am making, specific enough to be wrong. Within eighteen months, the gap between companies that have built shared semantic state and companies that have bolted agents onto fragmented data will become measurable in a particular way. It will not show up in AI usage metrics because both groups will have high usage. It will show up in the rate at which decisions translate into action. The first group will close the loop between meetings and work, commitments and follow-through, strategy and execution. The second group will keep generating activity that does not compound. The metric to watch is not how often people use AI. It is how often the company successfully does the thing it decided to do. That is what mature company memory enables. The useful parts of interactions become memory. The memory becomes a model of how the company works. The model brings the next important thing to the person who can do something about it. As traces accumulate, the system learns which signals matter, which actions work, which commitments tend to slip, which handoffs fail, and which decisions create downstream consequences. The company starts to learn from itself. Claude’s memory announcement matters because it makes persistent agent memory feel like infrastructure rather than a product gimmick. A memory store mounted into an agent’s filesystem is a good primitive. But enterprise memory cannot stop at notes. Notes have to become semantic. Semantic objects have to become traces. Traces have to be interpreted through the right ontology. The ontology has to respect the role, the permission boundary, and the action surface. Factual memory tells the company what exists and what happened. Interaction memory preserves why things happened and how people reasoned. Action memory remembers what was done, when, and by whom. The semantic substrate holds it together. Ontologies decide how different people and agents should understand it. The end state is not one AI that knows everything. It is shared company memory: one reality, many lenses, and humans and agents acting from the same state. That is the bet. One substrate, many lenses, work that compounds. The thing we are building toward is not a smarter assistant. It is a company that remembers itself. —- Part 1: Why most companies have date but no memory Part 2: Factual Memory Part 3: Interaction Memory Part 4: Action Memory Part 5: Memory Is State, Not a Service Part 6: Lessons From Building A Company Brain At Sentra, where we are building what can be only described as a "company brain", a shared intelligence/memory layer that sits on all communication channels, knowledge bases, action and agent traces to understand how everyone in an organization actually works as well as how work actually gets done, constructing a living world model of the entire company in near real time. ## 相关链接 - [Ashwin Gopinath](https://x.com/ashwingop) - [@ashwingop](https://x.com/ashwingop) - [15K](https://x.com/ashwingop/status/2052407955086254262/analytics) - [Claude blog](https://claude.com/blog/new-in-claude-managed-agents) - [Claude API Docs](https://platform.claude.com/docs/en/managed-agents/memory) - [Claude blog](https://claude.com/blog/claude-managed-agents-memory) - [Company Brain](https://x.com/ashwingop/status/2049641901410955694) - [Part 5](https://x.com/ashwingop/status/2051691477831745907) - [Claude API Docs](https://platform.claude.com/docs/en/managed-agents/memory) - [Why most companies have date but no memory](https://x.com/ashwingop/status/2049641901410955694) - [Factual Memory](https://x.com/ashwingop/status/2049885545288077720) - [Interaction Memory](https://x.com/ashwingop/status/2050963469898506342) - [Action Memory](https://x.com/ashwingop/status/2051317871750558077?s=20) - [Memory Is State, Not a Service](https://x.com/ashwingop/status/2051691477831745907) - [Lessons From Building A Company Brain](https://x.com/ashwingop/status/2052051032566530216) - [Sentra](https://www.sentra.app/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:19 PM · May 7, 2026](https://x.com/ashwingop/status/2052407955086254262) - [15.8K Views](https://x.com/ashwingop/status/2052407955086254262/analytics) - [View quotes](https://x.com/ashwingop/status/2052407955086254262/quotes) --- *导出时间: 2026/5/8 13:30:07* --- ## 中文翻译 # Claude 让 Agent 记忆成为现实。但语义与本体论依然缺失 **作者**: Ashwin Gopinath **日期**: 2026-05-07T15:19:23.000Z **来源**: [https://x.com/ashwingop/status/2052407955086254262](https://x.com/ashwingop/status/2052407955086254262) ---  Claude 最新的 Managed Agents(托管代理)发布是企业 AI 发展方向的一个有用标志。Anthropic 将“做梦”描述为一个定期过程,用于审查代理会话和记忆存储,提取模式,并策划记忆,以便代理随着时间的推移而改进;同一版本还在 Managed Agents 中引入了结果和多代理编排(Claude blog)。Anthropic 的记忆文档将记忆存储描述为工作区范围内的文本文档集合,可以附加到托管代理会话,挂载到会话容器的 /mnt/memory/ 下,并由代理使用与其在其他地方使用的相同的文件工具进行读取或写入(Claude API Docs)。Anthropic 的记忆发布文章还提到,这些记忆是基于文件的、可导出的、可通过 API 管理的,并内置了范围权限、审计日志和回滚/版本控制(Claude blog)。 这正是正确的方向。Agent 需要能够检查、编辑、跨会话携带并在边界内共享的记忆。基于文件的记忆存储特别有趣,因为它将记忆视为代理工作环境的一部分,而不是附加在旁边的黑盒检索服务。 但是,一个记忆的地方并不等同于能够理解的记忆。一堆笔记只是存储。有用的记忆需要语义和本体论。语义告诉系统某物是什么。本体论告诉系统从特定角度来看为什么它很重要。 拿一块石头来说。在语义上,它是一块石头:形状、重量、材料、位置、质地。但对于疲惫的徒步旅行者来说,它是一把椅子。对于雕塑家来说,它是原材料。对于地质学家来说,它是证据。对于建筑工人来说,它是障碍。同一个物体。相同的事实。不同的视角。不同的意义。 个人记忆无处不在存在这个问题。“下周给 Ravi 打电话”是没有用的,除非系统知道 Ravi 对你意味着什么。Ravi 是投资者、朋友、学生、客户、医生还是联合创始人?提醒语在每个案例中都有相同的词,但记忆应该根据关系有不同的表现。 这就是为什么个人记忆很难。一个人的本体论是流动的,因为我们同时是多重身份。我们在同一天里往往是父母、朋友、同事、患者、客户、经理、学生和创始人。随着一个人转换视角,同一个工件可以改变意义。 组织则不同。它们仍然有政治、歧义和相互冲突的激励机制,但它们也有角色:销售、财务、法务、支持、工程、采购、运营、领导层。角色赋予组织记忆更稳定的本体论。 一封供应商延迟邮件有一种语义结构:供应商、采购订单、延迟物品、原日期、修改后的日期、原因。对于采购,它是供应商风险。对于财务,它是权责发生制问题。对于运营,它是生产延迟。对于法务,它可能是合同风险。 同一个文件。相同的事实。不同的本体论。 这就是我想关于“公司大脑”提出的观点。Claude 为 Agent 提供了一个记忆的地方。Sentra 的赌注是,公司记忆也需要结构:文件作为来源,语义作为提取,本体论作为视角,以及一个有权限的记忆图作为 Agent 可以使用的基板。 企业 AI 的下一章将不是一个无所不知的助手。它将是一家能够记住足够多事情的公司,让人类和 Agent 从同一个现实出发行动,而无需强迫每个人都以同样的方式看待那个现实。 在第 5 部分中,我认为记忆必须成为共享的语义状态,而不是单个工具中的一个功能。那个论点是关于基底的。这篇文章是关于位于其上层的,因为仅凭基底无法创造采用。创造采用的是“透镜层”。 主导的企业 AI 玩法仍然是每个公司一个助手,以及一个公司范围内关于工作如何组合在一起的模型。即使公司在这个方向上投入巨资,采用仍然不均衡。销售以一种方式使用它,产品以另一种方式,支持几乎不用,法务几乎从不,而领导层把它变成一个搜索框。接口看起来是统一的,但使用并非如此。 原因是该助手隐式地承载了一种本体论。一种本体论无法适应七个不同的职能实际看待其工作的方式。 定制本体论是组织范围内 AI 采用的真正途径。采用并不是通过给每个员工相同的助手并希望他们能很好地提示它来优化的。这仍然要求人们将他们的工作翻译成 AI 的接口。更好的方向是相反的:AI 应该理解公司每个部分已经如何看待工作。 销售思考的是账户、利益相关者、异议、续约风险、购买委员会和承诺。产品思考的是信号、路线图权衡、发布阻碍、回归、功能请求和客户痛点。支持思考的是严重性、复发、变通方法、客户影响、升级和解决路径。法务思考的是义务、审批、风险敞口、红线和承诺。领导层思考的是战略、偏差、执行差距、所有权和公司状态。 这些不是独立的公司。它们是同一家公司以不同方式理解相同的工作。 架构上的举措是将基底与透镜分离。基底是共享的、有权限的、可检查的和持久的。透镜是功能的、可定制的和垂直的。公司定义了一个关于其如何运作的广泛本体论,每个职能定义了一个关于它如何看待其局部的更狭窄的本体论。基底在下方持有相同的记忆。透镜决定该记忆在上下文中的意义。 这也是为什么基于文件的记忆是一个有趣的起点,但不是整个终点。在 Claude 的托管代理系统中,可以在创建会话时附加记忆存储,并且当记忆的不同部分具有不同的所有者或访问规则时,可以附加多个存储(Claude API Docs)。这自然地映射到企业问题,因为记忆没有一个所有者。有些记忆属于用户,有些属于项目,有些属于职能,有些属于公司。 更难的问题是这些记忆如何变得有意义。如果客户问题在会议中被讨论,再次出现在 Slack 线程中,变成支持工单,引发销售担忧,后来改变了路线图优先级,这些不应该变成五个不相关的记忆。它们应该成为一个具有不同轨迹的进化记忆:支持轨迹、客户轨迹、产品轨迹、收入轨迹、行动轨迹和决策轨迹。每个轨迹的存在都是因为本体论决定了什么是重要的。 当这变得成熟时,AI 的界面就会改变。大多数工作中的 AI 仍然是反应式的。你打开一个聊天框,问一个问题,粘贴上下文,等待回答,然后去工作。即使答案是好的,负担仍然在于你知道要问什么,上下文在哪里,接下来应该发生什么。 成熟的公司记忆改变了这个剧本。系统已经知道在会议、消息、电子邮件、工单、工作流和行动中发生了什么。它知道通常对你的角色重要的是什么,哪个本体论适用,哪些条件改变了,以及什么行动可能是可用的。所以它可以把工作带给你,而不是等着你去寻找。 这是我最关心的产品转变:AI 带来上下文,人类做出决定,Agent 完成任务。这听起来很简单,但它改变了谁承担上下文的负担。 一位经理开始一天的工作,看到上周在会议中做出的客户承诺从未变成工作。系统不会等待经理去搜索它。它说明发生了什么,来自哪里,谁参与了,为什么重要,以及什么行动是可用的。经理在三十秒内做出决定。如果没有基底,这个承诺会在两个月后由愤怒的客户提出来。 一位 CEO 看到一个战略举措正在偏离,因为领导会议中的决策与运营团队中创建的工作不匹配。这正是仪表盘通常会错过的那种事情,因为仪表盘是在事后看到指标。公司记忆可以更早看到差距,因为它记住了承诺、基本原理、交接以及随之而来或未能随之而来的行动。CEO 不需要一份新报告。CEO 需要在差距出现的时刻就将其呈现出来。 处理支持升级的 Agent 需要的不仅仅是最新的工单。它应该知道同样的问题出现在客户通话中,销售承诺了变通方法,产品降低了修复优先级,以及客户即将续约。相同的记忆看起来会不同,这取决于 Agent 是在向支持做简报、准备客户主管,还是警告产品有关路线图风险。 主动 AI 需要边界,因为它变得越有用,这些边界就越重要。本体论决定什么是重要的。权限决定谁能看到它。来源显示它来自哪里。行动记忆显示已经做了什么。人类批准有意义的决定。Agent 在护栏内执行。 如果没有这些边界,主动 AI 就会变成噪音或监控。有了这些边界,它就成为公司从共享现实出发行动的一种方式。 这就是我下的赌注,具体到可能是错误的。在十八个月内,已经建立了共享语义状态的公司与将 Agent 安装在碎片化数据上的公司之间的差距,将以一种特定的方式变得可衡量。它不会出现在 AI 使用指标中,因为两组都会有很高的使用率。它将出现在决策转化为行动的比率中。 第一组将缩小会议与工作、承诺与跟进、战略与执行之间的循环。第二组将继续产生不复合的活动。要关注的指标不是人们多久使用一次 AI。而是公司成功完成其决定要做的事情的频率。 这就是成熟的公司记忆所启用的。互动中有用的部分变成记忆。记忆变成公司如何运作的模型。该模型将下一个重要的事情带给可以对此采取行动的人。随着轨迹的积累,系统学习哪些信号重要,哪些行动有效,哪些承诺倾向于滑坡,哪些交接失败,以及哪些决策会产生下游后果。公司开始从自己身上学习。 Claude 的记忆发布之所以重要,是因为它让持久的 Agent 记忆感觉像是基础设施而不是产品噱头。挂载到 Agent 文件系统的记忆存储是一个很好的基元。但企业记忆不能止步于笔记。笔记必须变成语义。语义对象必须变成轨迹。轨迹必须通过正确的本体论来解释。本体论必须尊重角色、权限边界和行动表面。 事实记忆告诉公司存在什么以及发生了什么。互动记忆保留事情为什么发生以及人们如何推理。行动记忆记录做了什么,何时做的,以及由谁做的。语义基底将它们维系在一起。本体论决定不同的人和 Agent 应该如何理解它。 最终状态不是一个无所不知的 AI。它是共享的公司记忆:一个现实,多个透镜,以及人类和 Agent 从同一状态出发行动。 这就是赌注。一个基底,多个透镜,复合的工作。我们正在构建的目标不是一个更聪明的助手。它是一个能记住自身的公司。 —— 第 1 部分:为什么大多数公司有数据但没有记忆 第 2 部分:事实记忆 第 3 部分:互动记忆 第 4 部分:行动记忆 第 5 部分:记忆是状态,不是服务 第 6 部分:构建公司大脑的经验教训 在 Sentra,我们正在构建只能被描述为“公司大脑”的东西,一个位于所有通信渠道、知识库、行动和 Agent 轨迹之上的共享智能/记忆层,以理解组织中的每个人实际上是如何工作的,以及工作实际上是如何完成的,在近乎实时地构建整个公司的生动世界模型。 ## 相关链接 - [Ashwin Gopinath](https://x.com/ashwingop) - [@ashwingop](https://x.com/ashwingop) - [15K](https://x.com/ashwingop/status/2052407955086254262/analytics) - [Claude blog](https://claude.com/blog/new-in-claude-managed-agents) - [Claude API Docs](https://platform.claude.com/docs/en/managed-agents/memory) - [Claude blog](https://claude.com/blog/claude-managed-agents-memory) - [Company Brain](https://x.com/ashwingop/status/2049641901410955694) - [Part 5](https://x.com/ashwingop/status/2051691477831745907) - [Claude API Docs](https://platform.claude.com/docs/en/managed-agents/memory) - [Why most companies have date but no memory](https://x.com/ashwingop/status/2049641901410955694) - [Factual Memory](https://x.com/ashwingop/status/2049885545288077720) - [Interaction Memory](https://x.com/ashwingop/status/2050963469898506342) - [Action Memory](https://x.com/ashwingop/status/2051317871750558077?s=20) - [Memory Is State, Not a Service](https://x.com/ashwingop/status/2051691477831745907) - [Lessons From Building A Company Brain](https://x.com/ashwingop/status/2052051032566530216) - [Sentra](https://www.sentra.app/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:19 PM · May 7, 2026](https://x.com/ashwingop/status/2052407955086254262) - [15.8K Views](https://x.com/ashwingop/status/2052407955086254262/analytics) - [View quotes](https://x.com/ashwingop/status/2052407955086254262/quotes) --- *导出时间: 2026/5/8 13:30:07*
H How to Build a Multi-Model Team of AI Agents in 2026 本文介绍 2026 年构建多模型 AI Agent 团队的完整方法。作者指出使用单一模型会导致高成本低效、专业能力受限以及单供应商故障/盲点风险,主张按任务步骤选择合适模型。文章梳理了 2026 年 9 月的主流模型阵容(Claude Opus/Sonnet/Haiku/Fable 5.1、GPT-6 Astra、TypeSafe Jev)及定价,提出五层架构:路由器、编排器、专家模型、评审者(critic)和纯代码层,并讲解如何先对工作负载分类(决策、简单生成、真实工作、难题),再为每层选择最划算的模型。文中附有统一封装多供应商 API 的示例代码,涵盖 effort 参数与 thinking block 处理细节。 技术 › Agent Khairallah AL-Awady 2026-10-10 多模型Agent路由模型编排ClaudeOpenAI成本优化LLM架构设计
开 开源 Company Brain:多玩家 Agent Harness 的架构设计 Supermemory 团队宣布开源其 Company Brain 产品,并详细介绍了背后的多玩家 Agent Harness 设计。该系统构建于 Cloudflare Agents SDK 之上,核心是一个以组织 ID 为键的 Durable Object,负责回合生命周期、状态管理、权限策略、记忆边界和工具调用。文章重点阐述了如何设计一个'像队友而非机器人'的 Agent:包括 Slack 事件的分类路由、基于置信度模型而非二元判断的主动性决策、审批流程、steering 处理、运行时恢复等。作者还解释了停止该产品的原因——团队希望专注于构建世界领先的 Agent 记忆 API。 技术 › Agent Dhravya Shah 2026-09-26 AgentHarness开源CloudflareSlack多玩家架构设计记忆系统Durable Object主动性
R RAG 治不了 Agent 记忆过期:时序上下文的四个机制与开源路线实操 文章剖析了标准 RAG 在处理新旧事实冲突上的结构性缺陷:向量检索没有时间轴、不理解'取代'关系,只能把矛盾甩给模型猜测。作者提出时序上下文的四个核心机制——有效期标记、取代关系、软删除与遗忘、审计日志与证据链,并以 Graphiti 和 OpenContext 两条开源路线为参照讲解落地方式。OpenContext 提供基于时序上下文图的 remember/recall/improve/forget 四动词 API,在数据层解决事实过期问题;Graphiti 则专注作为可插拔的时序知识图谱记忆引擎。文末用律所预算变更案例演示了完整代码流程。 技术 › Agent AYi 2026-08-18 RAGAgent记忆系统时序上下文GraphitiZepOpenContext知识图谱向量检索LLM
P Palantir的企业AI部署方法论:FDE与Ontology 随着大模型进入企业级应用,前沿AI能力与实际生产落地之间仍存在巨大的工程鸿沟。本文深入剖析了Palantir的现场部署(FDE)方法,指出将AI接入企业运营的核心在于构建“本体”。Ontology不仅是数据的语义层,还包含动作、逻辑与安全边界。文章结合医院和水处理厂的真实案例,探讨了如何通过定义动词、控制权限,将企业的隐性知识转化为可执行、可审计的系统资产,为AI在企业中的安全落地提供了实践框架。 技术 › Agent Russell 2026-08-07 PalantirFDEOntology企业AIAgent大模型部署数字化转型企业架构知识图谱
K Karpathy 的 LLM Wiki 工程指南 本文介绍了 Andrej Karpathy 提出的 LLM Wiki 架构,旨在解决传统 AI 工具重复处理文档导致的资源浪费问题。通过构建 raw/、wiki/ 和 instructions/ 三个文件夹,将文档一次性编译为结构化知识库,大幅降低查询成本并实现长期记忆。 技术 › Hermes kai 2026-08-04 LLMKarpathy知识库Obsidian架构设计自动化Agent效率Claude
B BestBlogs 精选周刊 | 第 106 期:1% 法则 本期周刊探讨 AI 产品从演示到落地的距离。引用 Jeff Dean 的“1%法则”,将焦点从模型能力转移到系统工程细节。文章深入分析了规格定义、评测验证、任务成本、系统记忆、Skill 治理等关键问题,强调通过工程化手段实现智能体的稳定交付与闭环。 技术 › Agent ginobefun 2026-08-03 Agent工程化LLM评测架构设计ClaudeOpenAI
A Agent 开发指南:技术太多,该怎么学? 文章深入分析了 Agent 开发的技术趋势,指出核心稀缺资源已从“代码”转向“可信结果”。阐述了 Harness Engineering 的重要性,强调在概率性推理之外建立确定性执行外壳,通过状态管理、身份验证和结果验收,让 Agent 能够在复杂系统中可靠承担责任。 技术 › Agent 浮之静 2026-08-01 AgentHarness EngineeringContext Engineering技术趋势架构设计AI编程LLM系统架构Claude开发指南
T The complete Graph Engineering playbook for Claude Code 本文介绍了Graph Engineering(图工程)的概念,阐述如何利用Claude Code构建分布式Agent系统。通过将任务分解为线性、分发、规约和验证等节点,实现高效、可靠的AI工作流,优化计算成本和结果质量。 技术 › Claude Code Gyomei 2026-07-24 图工程AI工作流ClaudeAgent架构设计编程分布式系统自动化
H How to master graph engineering 本课程教授如何构建 AI 智能体图,涵盖图的基本概念、关键模式(如菱形模式)、停止规则及人工审批环节。包含三个实战案例:深度研究台、SEO 内容生成器和市场推广套件,旨在提升业务效率并控制成本。 技术 › Agent Machina 2026-07-23 AgentGraphLLMClaudeWorkflow工程化自动化架构设计效率实战
G Graph Engineering with Claude: the 11-Step Roadmap From Loops to Graph Architect 本文阐述了从单一循环工程向图工程演进的必要性。针对单一 Agent 在处理复杂任务时上下文混淆和幻觉问题,作者提出了由节点、边、路由器和状态四大基础构建块组成的图架构,并通过序贯链和路由器等模式,展示如何协调多 Agent 系统以实现高效输出。 技术 › Claude 0xRafy 2026-07-22 Agent图工程多Agent系统架构设计Claude
G Graph Engineering with Claude: 14-Step roadmap from 0 to graph architect 本文介绍了如何使用 Claude 构建图结构的 Agent,替代传统的线性执行模式。文章详细阐述了节点与边的定义、契约设计、并行化执行等核心概念,通过动态工作流实现任务的分发、验证与聚合,从而提升效率与系统的鲁棒性。 技术 › Claude Codez 2026-07-21 ClaudeAgent图工程并行化工作流编程架构设计JavaScript
使 使用 Fable 5 构建自我改进 Agent 系统的 14 步指南 文章深入探讨了如何充分利用 Claude Fable 5 的潜能,而非仅仅将其视作上下文窗口更大的 Sonnet。作者提出了构建“自我改进系统”的 14 步路线图,区分了自我学习与自我改进,并详细阐述了基于 Loops、Dynamic Workflows 和 Routines 的三层架构。文章还提供了 Fable 5、Opus 和 Sonnet 在系统中的成本与任务分配策略。 技术 › LLM Codez 2026-07-09 Fable 5AgentClaude架构设计提示工程工作流自动化自我改进系统架构最佳实践