Agent/AI

构建生产级 Agent Memory 系统架构 很多人在做 Agent 时，第一版 Memory 的实现大概长这样： memory = [] memory.append({"role": "user", "content": "你好"}) memory.append({"role": "assistant", "content": "你好！有什么可以帮你的？"}) import java.util.*; List<Map<String, String>> memory = new ArrayList<>(); memory.add(Map.of("role", "user", "content", "你好")); memory.add(Map.of("role", "assistant", "content", "你好！有什么可以帮你的？")); 跑几天后发现问题了： 对话一长，Token 消耗爆炸 用户上次说过的偏好，下次完全不记得 多个 Session 之间的信息没法共享 想查某个历史事实，得翻完整条对话 模型在长上下文里注意力稀释，反而答得更差 于是开始往里面塞向量数据库、塞总结、塞 Graph，结果又发现：Memory 系统不是越复杂越好，而是越适合你 Agent 的行为模式越好。 这篇文章不讲泛泛的概念，而是从工程角度拆解：一个生产级的 Agent Memory 系统到底该考虑哪些维度，每种方案解决什么问题、带来什么新问题，以及如何组合它们。 目录 一、Agent Memory 到底是什么 二、整体架构：三层分离 三、Episodic Memory（情节记忆）：最基础也最容易搞砸的部分 问题本质 常见实现方式对比 推荐方案：分层管理 工程实现要点 四、Semantic Memory（语义记忆）：从经历中提炼事实 核心思路 提取什么 存储选型 提取策略：被动 vs 主动 关键难点：事实的更新与冲突 五、Procedural Memory（程序记忆）：Agent 怎么学会"做事情的方式" 实现方式 何时写入 六、Context Builder：决定往 Prompt 里塞什么 组装策略 Token 预算分配 检索触发策略 七、数据生命周期与维护 TTL 与过期 Consolidation（合并） Importance Scoring（重要性评分） 八、从 Claude Code 中看到的优秀设计 文件即数据库 类型化记忆 检索时的验证机制 不混淆"记忆"和"任务状态" 九、主流框架的 Memory 实现案例 LangChain：模块化 Memory 体系 CrewAI：基于角色的记忆分工 Mem0：专注"记忆层"的独立框架 Spring AI：Java 生态的 Memory 实现 AgentScope4J：observe/call 分离与 MsgHub 记忆共享 Hermes Agent：四层记忆与可插拔 Provider OpenClaw：文件即记忆的"梦境"系统 AutoGen：对话驱动的记忆共享 框架对比小结：Hermes vs OpenClaw 十、生产级 Checklist 十一、总结 一、Agent Memory 到底是什么 很多人把 Memory 等同于"聊天记录"，这是第一个坑。 ...

AgentScope4J 实战：MCP、Function Calling、Hermes、Skills 全链路落地 很多团队在做 AI Agent 时，会把 MCP、Function Calling、Workflow、Skills 混在一起，最后导致系统边界不清晰： 模型在“决策层”做了太多“执行层”的事 工具能力散落在不同模块，难治理、难审计 Demo 阶段能跑，线上阶段一旦扩展就失控 这篇文章给出一个工程化拆解：基于 agentscope4j 搭建一套清晰的分层，把这四个关键能力拼成一条可扩展、可观测、可治理的链路。 一、先把概念边界讲清楚 很多讨论无效，根源是“词对了，语义不对”。下面先做边界划分。 概念 核心职责 解决的问题 不负责的事情 Function Calling 让模型按 JSON Schema 选择并调用本地函数 结构化参数、减少自由文本歧义 跨进程发现工具、权限治理 MCP 标准化“模型如何发现并调用远端工具” 工具注册、工具描述、跨系统接入 业务编排策略 Hermes（编排层） 统一调度策略与执行控制 路由、重试、超时、回退、审批 工具协议本身 Skills 可复用能力单元（提示词+工具+策略） 把“能力”沉淀为可组合模块 具体传输协议 一句话总结： Function Calling 是“调用形态”，MCP 是“工具接入协议”，Hermes 是“执行与治理中枢”，Skills 是“业务能力封装”。 二、目标架构：四层分离 flowchart TD U["User Request"] --> A["AgentScope4J Agent (Planner)"] A --> H["Hermes Orchestrator"] H --> S1["Skill: Research"] H --> S2["Skill: Report"] S1 --> FC["Function Calling Adapter"] S1 --> MCP["MCP Client Adapter"] FC --> T1["Local Tool: SqlTool/FileTool"] MCP --> T2["Remote MCP Tools"] S2 --> T3["Formatter/Exporter"] T1 --> O["Observability: Trace/Log/Metrics"] T2 --> O T3 --> O 设计原则： ...

多智能体系统里，Agent 之间的通信是个容易被低估的难题。本文以 AgentScope-Java 的 MsgHub 为例，聊聊我们在实践中踩过的坑，以及订阅-广播机制的设计思路。 一、为什么要专门做个通信层 1.1 常见但别扭的做法 三个狼人 Agent 讨论今晚刀谁，你会怎么写？ 手动透传消息 // 没有 MsgHub 的情况 Msg aResponse = wolfA.call().block(); wolfB.observe(aResponse).block(); wolfC.observe(aResponse).block(); Msg bResponse = wolfB.call().block(); wolfA.observe(bResponse).block(); wolfC.observe(bResponse).block(); // 代码重复，维护噩梦 并发调用 // 同时调用所有 Agent var responses = Flux.just(wolfA, wolfB, wolfC) .flatMap(agent -> agent.call()) .collectList() .block(); // 问题：每个 Agent 基于相同的初始上下文，无法互相影响 同步阻塞（死锁风险） // 如果每个 Agent 都在等其他人先发言 Msg aResponse = wolfA.call().block(); // A 等 B Msg bResponse = wolfB.call().block(); // B 等 C Msg cResponse = wolfC.call().block(); // C 等 A // 死锁 这些方案要么啰嗦，要么有隐患。我们需要一种让 Agent 既能"听到"彼此，又不会互相卡住的机制。 ...

Claude Code源代码 参考URL: 如何评价Claude Code源代码泄漏？ - 卜寒兮的回答 - 知乎 https://www.zhihu.com/question/2022392127145911515/answer/2022520709964931142 总结：值得借鉴的设计模式 模式 在 Claude Code 里的体现 可借鉴的场景 AsyncGenerator 作为流式原语 query() 的整体结构 任何需要流式输出 + 可中断的 agent 分层错误恢复 五层上下文压缩策略 资源受限下的 long-running task 流式并发工具执行 StreamingToolExecutor 多工具并行调用的 agent 投机性预计算 startSpeculativeClassifierCheck 任何有必然后续操作的流程 工具自声明并发安全性 isConcurrencySafe() 接口 混合读写操作的任务编排 Forked Agent 共享缓存 CacheSafeParams + compact agent 需要 fork 子任务但不想丢失 prompt cache Hook 与主循环解耦 Post-sampling / stop hooks 任何需要插入评估逻辑的 agent 系统 回到上面那句话：harness 编码了对”模型不能独立完成什么”的假设（“the harness itself encodes assumptions about what models cannot do independently”。） ...