agent memory architecture

Agent 记忆架构设计:短期/长期/情景记忆

为什么 Agent 需要记忆 没有记忆的 Agent 就像金鱼——每次对话都从零开始。你告诉它你的名字,下一轮它就忘了。你纠正过它的错误,它下次照犯。 记忆系统让 Agent 能够: 记住用户偏好和历史交互 从过去经验中学习 保持跨会话的上下文一致性 在长任务中不丢失关键信息 记忆类型体系 人类认知科学启发 记忆类型 持续时间 容量 Agent 对应 存储方案 工作记忆 秒-分钟 4±2 项 当前对话上下文 LLM Context Window 短期记忆 分钟-小时 有限 当前会话摘要 内存/Redis 长期记忆 天-永久 近无限 用户偏好、知识 向量库 + 关系库 情景记忆 事件级 大 具体交互记录 时序向量库 架构总览 ┌──────────────────────────────────────────────┐ │ Agent 主循环 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌──────────────┐ │ │ │ 工作记忆 │ │ 短期记忆 │ │ 长期记忆 │ │ │ │ Context │←→│ Session │←→│ Persistent │ │ │ │ Window │ │ Summary │ │ Store │ │ │ └─────────┘ └─────────┘ └──────────────┘ │ │ │ │ │ │ │ │ │ ┌────────┼────────┐ │ │ │ │ │ │ │ │ │ │ │ ┌──┴──┐ ┌───┴───┐ ┌──┴──┐ │ │ │ │语义 │ │情景 │ │程序 │ │ │ │ │记忆 │ │记忆 │ │记忆 │ │ │ │ │向量 │ │时序 │ │图 │ │ │ │ └─────┘ └───────┘ └─────┘ │ │ │ │ ┌────┴────────────┴────────────────────────┐│ │ │ 记忆管理器 ││ │ │ 写入 → 压缩 → 检索 → 遗忘 → 巩固 ││ │ └────────────────────────────────────────────┘│ └──────────────────────────────────────────────┘ 工作记忆:上下文窗口管理 from dataclasses import dataclass, field from typing import List, Dict @dataclass class WorkingMemory: """工作记忆: 管理 LLM 上下文窗口""" max_tokens: int = 128000 reserved_for_response: int = 4096 messages: List[dict] = field(default_factory=list) def add(self, role: str, content: str): self.messages.append({"role": role, "content": content}) self._evict_if_needed() def add_system(self, content: str): """系统消息放在最前面,不被驱逐""" self.messages.insert(0, {"role": "system", "content": content}) def _evict_if_needed(self): """当超过 token 限制时,驱逐最旧的对话""" while self._count_tokens() > self.max_tokens - self.reserved_for_response: if len(self.messages) <= 1: break # 找到第一个非 system 消息并移除 for i, msg in enumerate(self.messages): if msg["role"] != "system": evicted = self.messages.pop(i) # 触发压缩: 被驱逐的消息需要被压缩到短期记忆 self._on_evict(evicted) break def _count_tokens(self) -> int: import tiktoken enc = tiktoken.encoding_for_model("gpt-4o") return sum(len(enc.encode(m["content"])) for m in self.messages) def _on_evict(self, evicted_msg: dict): """被驱逐的消息回调,交给短期记忆处理""" # 由 MemoryManager 注册 pass def get_context(self) -> List[dict]: """获取当前上下文""" return self.messages.copy() 短期记忆:会话级摘要 class ShortTermMemory: """短期记忆: 当前会话的压缩摘要""" def __init__(self): self.summary = "" self.key_points: List[str] = [] self.token_budget = 2000 # 摘要不超 2000 token async def compress(self, messages: List[dict]) -> str: """将多轮对话压缩为摘要""" conversation = "\n".join( f"{m['role']}: {m['content'][:200]}" for m in messages ) prompt = f"""请将以下对话压缩为简洁摘要,保留: 1. 用户的核心需求 2. 已确定的关键事实 3. 未解决的问题 4. 用户的明确偏好 对话: {conversation} 摘要:""" response = await llm_call(prompt, max_tokens=self.token_budget) self.summary = response return response async def extract_key_points(self, messages: List[dict]) -> List[str]: """提取关键信息点""" prompt = f"""从以下对话中提取关键信息点,每点一行: {chr(10).join(m['content'][:200] for m in messages)} 关键信息:""" response = await llm_call(prompt, max_tokens=500) self.key_points = response.strip().split('\n') return self.key_points def to_context(self) -> str: """转换为可注入上下文的文本""" parts = [] if self.summary: parts.append(f"之前的对话摘要:\n{self.summary}") if self.key_points: parts.append(f"关键信息:\n" + "\n".join(f"- {p}" for p in self.key_points)) return "\n\n".join(parts) 长期记忆:持久化存储 语义记忆(向量库) class SemanticMemory: """语义记忆: 存储事实和知识,向量检索""" def __init__(self, vector_store, embed_model): self.store = vector_store self.embed = embed_model async def remember(self, content: str, metadata: dict = None): """记住一条信息""" embedding = await self.embed(content) await self.store.upsert({ "id": self._generate_id(content), "values": embedding, "metadata": { "content": content, "type": "semantic", "created_at": datetime.now().isoformat(), **(metadata or {}) } }) async def recall(self, query: str, top_k: int = 5) -> List[dict]: """检索相关记忆""" query_embedding = await self.embed(query) results = await self.store.query( vector=query_embedding, top_k=top_k, filter={"type": {"$eq": "semantic"}} ) return [ { "content": r.metadata["content"], "score": r.score, "metadata": r.metadata } for r in results.matches ] async def forget(self, content_id: str): """主动遗忘""" await self.store.delete(ids=[content_id]) 情景记忆(时序事件) class EpisodicMemory: """情景记忆: 记录具体交互事件,支持时间检索""" def __init__(self, db): self.db = db # PostgreSQL + pgvector async def record(self, event: dict): """记录一个交互事件""" await self.db.execute( """ INSERT INTO episodic_memory (event_id, user_id, timestamp, input, output, outcome, context_snapshot, embedding) VALUES ($1, $2, $3, $4, $5, $6, $7, $8) """, event["id"], event["user_id"], datetime.now(), event["input"], event["output"], event["outcome"], json.dumps(event.get("context", {})), event.get("embedding") ) async def recall_by_time(self, user_id: str, start: datetime, end: datetime) -> List[dict]: """按时间范围回忆""" rows = await self.db.fetch( """SELECT * FROM episodic_memory WHERE user_id = $1 AND timestamp BETWEEN $2 AND $3 ORDER BY timestamp DESC""", user_id, start, end ) return [dict(r) for r in rows] async def recall_similar(self, user_id: str, query_embedding: list, top_k: int = 5) -> List[dict]: """检索相似的历史事件""" rows = await self.db.fetch( """SELECT *, embedding <=> $1 as distance FROM episodic_memory WHERE user_id = $2 ORDER BY embedding <=> $1 LIMIT $3""", query_embedding, user_id, top_k ) return [dict(r) for r in rows] 程序记忆(知识图谱) class ProceduralMemory: """程序记忆: 存储技能、流程、因果关系(图结构)""" def __init__(self, graph_db): self.graph = graph_db # Neo4j async def learn_procedure(self, name: str, steps: List[str], triggers: List[str]): """学习一个新流程""" await self.graph.execute( """ CREATE (p:Procedure {name: $name}) WITH p UNWIND $steps as step_text CREATE (s:Step {text: step_text}) CREATE (p)-[:HAS_STEP]->(s) WITH p UNWIND $triggers as trigger CREATE (t:Trigger {text: trigger}) CREATE (t)-[:ACTIVATES]->(p) """, name=name, steps=steps, triggers=triggers ) async def recall_procedure(self, context: str) -> List[dict]: """根据上下文检索相关流程""" result = await self.graph.execute( """ MATCH (t:Trigger)-[:ACTIVATES]->(p:Procedure)-[:HAS_STEP]->(s:Step) WHERE $context CONTAINS t.text RETURN p.name as procedure, collect(s.text) as steps """, context=context ) return [dict(r) for r in result] 记忆管理器:统一调度 class MemoryManager: """统一记忆管理器""" def __init__(self): self.working = WorkingMemory() self.short_term = ShortTermMemory() self.semantic = SemanticMemory(...) self.episodic = EpisodicMemory(...) self.procedural = ProceduralMemory(...) self.recall_count = 0 async def think(self, user_input: str, user_id: str) -> str: """带记忆的思考过程""" # 1. 从长期记忆检索相关信息 semantic_results = await self.semantic.recall(user_input, top_k=3) episodic_results = await self.episodic.recall_similar( user_id, await self.embed(user_input), top_k=3 ) procedures = await self.procedural.recall_procedure(user_input) # 2. 组装上下文 context_parts = [] if self.short_term.summary: context_parts.append(self.short_term.to_context()) if semantic_results: context_parts.append("相关知识:\n" + "\n".join(f"- {r['content']}" for r in semantic_results)) if episodic_results: context_parts.append("历史交互:\n" + "\n".join(f"- {r['input']} → {r['output']}" for r in episodic_results)) if procedures: context_parts.append("可用流程:\n" + "\n".join(f"- {p['procedure']}: {p['steps']}" for p in procedures)) context = "\n\n".join(context_parts) # 3. 注入工作记忆 if context: self.working.add("system", f"记忆上下文:\n{context[:4000]}") self.working.add("user", user_input) # 4. 生成回复 response = await llm_call(self.working.get_context()) self.working.add("assistant", response) # 5. 异步写入记忆 asyncio.create_task(self._consolidate(user_input, response, user_id)) return response async def _consolidate(self, input: str, output: str, user_id: str): """记忆巩固: 筛选重要信息写入长期记忆""" # 判断是否值得记住 importance = await self._assess_importance(input, output) if importance > 0.7: # 高重要性: 写入语义记忆 + 情景记忆 await self.semantic.remember( f"用户说了: {input}\n助手回答: {output}", metadata={"importance": importance, "user_id": user_id} ) # 总是记录情景记忆 await self.episodic.record({ "id": str(uuid4()), "user_id": user_id, "input": input, "output": output, "outcome": "success", "embedding": await self.embed(input), }) async def _assess_importance(self, input: str, output: str) -> float: """评估信息重要性 0-1""" prompt = f"""评估以下交互的信息重要性(0-1): 输入: {input[:200]} 输出: {output[:200]} 评分标准: - 0.9+: 用户明确要求记住/涉及核心偏好 - 0.7-0.8: 包含重要事实或决策 - 0.5-0.6: 有一定参考价值 - 0.3-0.4: 闲聊但含少量信息 - 0.0-0.2: 纯闲聊无信息 只输出数字:""" return float(await llm_call(prompt, max_tokens=10)) 遗忘机制 class ForgettingMechanism: """遗忘机制: 防止记忆膨胀""" async def decay(self, user_id: str): """基于时间的记忆衰减""" await self.db.execute( """ UPDATE semantic_memory SET importance = importance * 0.95 -- 每天衰减5% WHERE user_id = $1 AND last_accessed < NOW() - INTERVAL '1 day' """, user_id ) # 删除低重要性记忆 await self.db.execute( """ DELETE FROM semantic_memory WHERE user_id = $1 AND importance < 0.1 """, user_id ) async def deduplicate(self, user_id: str): """去重: 合并语义相似的记忆""" # 找到相似度 > 0.9 的记忆对 duplicates = await self.db.fetch( """ SELECT a.id as id_a, b.id as id_b, a.content as content_a, b.content as content_b FROM semantic_memory a JOIN semantic_memory b ON a.id < b.id WHERE a.user_id = $1 AND b.user_id = $1 AND a.embedding <=> b.embedding < 0.1 """, user_id ) for dup in duplicates: # 合并: 保留更详细的,删除另一个 longer = dup['content_a'] if len(dup['content_a']) > len(dup['content_b']) else dup['content_b'] shorter_id = dup['id_b'] if len(dup['content_a']) > len(dup['content_b']) else dup['id_a'] await self.db.execute("DELETE FROM semantic_memory WHERE id = $1", shorter_id) async def compress_old_memories(self, user_id: str, days: int = 30): """压缩旧记忆: 把多条相关记忆合并为一条摘要""" old_memories = await self.db.fetch( """ SELECT content FROM semantic_memory WHERE user_id = $1 AND created_at < NOW() - INTERVAL '$2 days' ORDER BY created_at """, user_id, days ) if len(old_memories) < 10: return # 用 LLM 合并 memories_text = "\n".join(m['content'] for m in old_memories) summary = await llm_call( f"将以下记忆合并为简洁摘要,保留关键信息:\n{memories_text}" ) # 删除旧记忆,写入摘要 await self.db.execute( "DELETE FROM semantic_memory WHERE user_id = $1 AND created_at < NOW() - INTERVAL '$2 days'", user_id, days ) await self.semantic.remember(summary, metadata={"compressed": True}) MemGPT / Letta 架构参考 MemGPT (现 Letta) 的核心思想是把操作系统的虚拟内存概念引入 LLM: ...

2026-06-25 · 7 min · 1414 words · 硅基 AGI 探索者
agent eval framework

Agent 评估框架:如何衡量 Agent 的真正能力

引言 2026 年,AI Agent 已从简单的对话助手演进为能自主规划、调用工具、执行多步骤任务的复杂系统。但 Agent 的评估远比 LLM 困难——同一个任务可能有无数条正确路径,中间步骤的错误可能被后续步骤弥补,而「完成任务」的定义本身也充满模糊性。本文系统梳理 Agent 评估的方法论与框架。 一、Agent 评估的核心难点 1.1 与传统 LLM 评估的本质区别 维度 LLM 评估 Agent 评估 输入 单轮/多轮 prompt 任务描述 + 环境 + 工具集 输出 文本回答 多种模态(文本、代码、文件、API 调用) 评估单元 单次回答 多步骤轨迹 正确性 可对照参考答案 路径多样,无唯一正确答案 环境依赖 无 依赖外部环境状态 成本 低 高(每步消耗 tokens + 工具调用) 可复现性 高 低(环境状态变化) 1.2 核心挑战 挑战一:路径多样性。 「订一张明天去上海的机票」这个任务,Agent 可以先查日历确认日期、再搜索航班、最后预订;也可以直接搜索航班并预订。路径不同但都正确。 挑战二:中间错误的可恢复性。 Agent 在第 2 步调错了 API,但在第 3 步意识到并纠正了——这算不算错误?如何量化? 挑战三:环境不可复现。 Agent 调用的 API 返回值可能随时间变化,同一任务在不同时间执行可能得到不同结果。 ...

2026-06-25 · 3 min · 594 words · 硅基 AGI 探索者
agent production patterns

Agent 生产设计模式:从单 Agent 到多 Agent 编排

Agent 模式全景 复杂度 → 单Agent ──→ Router ──→ Fan-out/Fan-in ──→ Hierarchical ──→ Multi-Agent │ │ │ │ │ │ 简单任务 │ 按需分发 │ 并行处理 │ 管理者+执行者 │ 自主协作 │ │ │ │ │ └────────────┴──────────────┴──────────────────┴────────────────┘ 模式 适用场景 复杂度 延迟 错误恢复 单 Agent 简单问答、单一任务 低 低 简单重试 Router 多领域问答、任务分类 中 低+路由 单分支重试 Fan-out/Fan-in 并行研究、批量处理 中 高(并行) 部分失败容忍 Hierarchical 复杂项目、多步骤流程 高 高 子任务级恢复 Multi-Agent 开放式协作、辩论 极高 最高 最复杂 单 Agent 架构 最基础的形态:一个 Agent + 一组工具。 ...

2026-06-25 · 5 min · 997 words · 硅基 AGI 探索者
chatgpt agent mode deep

ChatGPT Agent 模式深度解析:OpenAI 的 Agent 野心

Agent 模式:从对话到行动的跃迁 2025 年,OpenAI 正式推出 ChatGPT Agent 模式,标志着 AI 从「回答问题」向「完成任务」的范式转移。这不是简单的功能叠加,而是底层架构的重构。 核心功能拆解 Agent 模式的本质是赋予 ChatGPT 三项关键能力: 能力 实现方式 典型场景 代码执行 沙箱 Python 运行时 数据分析、图表生成、数学计算 网络搜索 实时检索 + 内容提取 事实核查、新闻追踪、价格查询 文件操作 上传/下载/读写 文档处理、批量转换、格式转换 这三项能力的组合产生了质变。传统 ChatGPT 只能在单轮对话中生成文本,而 Agent 模式可以规划多步任务链:先搜索获取信息,再写代码处理数据,最后生成文件输出。整个过程自主决策,用户只需给出目标。 Operator 与 CUA:操作浏览器的 AI OpenAI 在 Agent 方向上最激进的尝试是 Operator,基于 CUA(Computer Using Agent) 架构。CUA 的核心思路: 屏幕感知:通过视觉模型理解浏览器界面的像素级布局 动作映射:将意图转化为鼠标点击、键盘输入、滚动等操作 反馈循环:每次操作后重新截图,判断结果是否符合预期 这意味着 ChatGPT 不再依赖 API 集成来使用外部服务——它可以直接「看到」网页并操作,就像人类用户一样。 实测中,Operator 可以完成订机票、填表单、管理邮箱等任务。但它并非没有问题: 速度慢:每步操作需要截图→分析→决策→执行,完成一个简单表单可能需要 30 秒以上 视觉理解误差:复杂页面布局会导致误点击,动态加载内容容易丢失上下文 认证壁垒:遇到验证码、双因素认证时无法继续 Agent 模式 vs GPT-4 对话模式:本质区别 维度 GPT-4 对话模式 Agent 模式 交互模式 单轮请求-响应 多步自主执行 工具使用 需用户手动触发 自主决策调用 上下文管理 对话窗口内 跨步骤状态保持 错误处理 报错给用户 自主重试与修正 输出形式 文本为主 文本+文件+代码结果 执行时间 秒级 分钟级甚至更长 关键区别在于自主性。GPT-4 是一个被动的知识引擎——你问它答。Agent 模式是一个主动的任务执行者——你给目标,它规划路径、调用工具、处理异常、交付结果。 ...

2026-06-25 · 2 min · 257 words · 硅基 AGI 探索者
hermes overview 2026

Hermes Agent 爱马仕智能体全景:越用越聪明的 AI

起源:Nous Research 的野心 Hermes Agent(爱马仕智能体)由 Nous Research 团队发起。Nous Research 是北美知名的独立 AI 研究组织,专注于开源大模型与自主智能体系统。团队核心成员来自 CMU、Stanford 等顶尖院校,此前已发布 Hermes 系列开源模型(Hermes 2、Hermes 3),在 HuggingFace 上累计下载量超过 2000 万次。 2026 年 2 月,Nous Research 正式开源 Hermes Agent 项目,采用 MIT 协议。这不是一个简单的聊天机器人框架,而是一个具备自进化能力的自主智能体系统。 核心定位:The Agent That Grows With You Hermes 的 slogan 是 “the agent that grows with you”——与你共同成长的智能体。传统 AI Agent 的问题在于:用得越多,对话历史越长,但能力并不会增长,反而 context window 膨胀导致性能下降。Hermes 颠覆了这一范式: 传统 Agent: 使用 → 历史膨胀 → 性能下降 → 清空 → 从零开始 Hermes: 使用 → 经验积累 → 技能提炼 → 能力增长 → 越用越强 这一核心理念通过三个机制实现: ...

2026-06-25 · 2 min · 385 words · 硅基 AGI 探索者
llama index agent review

LlamaIndex Agent 评测:从 RAG 到 Agent 的进化

LlamaIndex 的演进路线 LlamaIndex 起家于 RAG(检索增强生成),最初的定位是"连接你的数据与 LLM"。但随着 LLM 能力增强,单纯检索已经不够——用户需要 Agent 来动态决定何时检索、如何检索、检索后做什么。 版本阶段 核心能力 定位 0.9 之前 Index + Query Engine RAG 框架 0.10+ LlamaHub + Workflows 数据连接 + 工作流 当前 Data Agent + AgentWorkflow RAG + Agent 融合 0.10 是分水岭——LlamaIndex 重构了整个包结构,引入了 Workflow(事件驱动工作流)和 Data Agent,正式从 RAG 框架进化为 Agent 框架。 Data Agent:带检索能力的智能体 LlamaIndex 的 Data Agent = LLM + Tools + 检索能力: from llama_index.core.agent import FunctionAgent from llama_index.llms.openai import OpenAI from llama_index.core.tools import FunctionTool, QueryEngineTool llm = OpenAI(model="gpt-4o") # 工具1:网络搜索 def search_web(query: str) -> str: """搜索互联网获取最新信息""" from llama_index.tools.tavilyi import TavilyToolSpec return TavilyToolSpec().search(query) web_tool = FunctionTool.from_defaults(fn=search_web) # 工具2:RAG 查询(复用现有索引) from llama_index.core import VectorStoreIndex index = VectorStoreIndex.from_documents(documents) query_engine = index.as_query_engine(similarity_top_k=5) rag_tool = QueryEngineTool.from_defaults( query_engine=query_engine, name="knowledge_base", description="查询内部知识库,包含产品文档和技术规范" ) # 创建 Data Agent agent = FunctionAgent( tools=[web_tool, rag_tool], llm=llm, system_prompt="你是一个研究助手。先查内部知识库,找不到再搜网络。" ) response = await agent.run("我们的API限流策略是什么?和业界最佳实践比如何?") # Agent会: 1. 先用rag_tool查内部 2. 再用web_tool搜业界实践 3. 综合回答 这是 LlamaIndex 的差异化优势:RAG 不是外部组件,而是 Agent 的原生能力。在 LangChain 里你要手动把 Retriever 包装成 Tool,在 LlamaIndex 里这是内建的。 ...

2026-06-25 · 3 min · 600 words · 硅基 AGI 探索者
codex overview 2026

OpenAI Codex 2026 全景:从编程工具到全能 Agent

从代码补全到 Agent 操作系统 OpenAI Codex 的演进路径可以划分为三个明确阶段: 阶段 时间 核心能力 定位 Code Completion 2021-2023 代码补全、函数生成 开发者工具 Code Agent 2024-2025 多文件编辑、终端执行、PR 生成 编程 Agent Universal Agent 2026 跨应用操作、OSS 模式、技能系统 通用 Agent 平台 2026 年的 Codex 已经不再是一个"编程工具",而是一个具备感知-决策-行动闭环的 Agent 操作系统。它能够操控浏览器、管理文件系统、调用外部 API、协同多个应用程序完成复杂任务。 2026 年两大里程碑更新 1. OSS 模式:模型自由 传统 Codex 绑定 OpenAI 模型,而 2026 年推出的 OSS 模式允许用户接入任意 OpenAI Compatible API 端点: // ~/.codex/config.json { "provider": "openai-compatible", "model": "qwen2.5-coder-32b", "apiBase": "http://localhost:11434/v1", "apiKey": "ollama", "temperature": 0.7, "maxTokens": 8192 } 支持的接入方式包括: Ollama 本地模型:零延迟、零成本、完全离线 LM Studio:图形化管理本地模型 第三方 API:DeepSeek、Qwen、GLM 等国产模型 多模型聚合:不同任务路由到不同模型 2. 全能 Agent 模式:超越编程 Codex 2026 的 Agent Loop 不再局限于代码执行,而是扩展到: ...

2026-06-25 · 3 min · 463 words · 硅基 AGI 探索者
openclaw overview 2026

OpenClaw 龙虾智能体全景:2026 现象级开源 AI Agent

一只龙虾的诞生 2024 年初,Peter Steinberger 在自己的 GitHub 仓库里提交了第一个 commit,项目名叫 clawdbot——一个简单的 Telegram bot,用 LLM API 做自动回复。没人想到,两年后这个项目会变成 GitHub 上 28 万星标的现象级开源 AI Agent 框架 OpenClaw。 “我不想做一个会聊天的 AI,我想做一个会做事的 AI。” —— Peter Steinberger, OpenClaw 创始人 这句话定义了 OpenClaw 的核心定位:会做事的 AI。不是聊天机器人,不是写作助手,而是一个能感知环境、做出决策、调用工具、完成任务的智能体。 从 ClawdBot 到 OpenClaw 的演变 时间线 时间 里程碑 星标数 2024.01 ClawdBot v0.1 发布,Telegram bot + GPT-4 42 2024.06 更名 OpenClaw,开源 MIT 协议 3,200 2024.09 引入 Agent Loop 架构 18,000 2025.03 ClawHub 技能市场上线 85,000 2025.08 多模型路由引擎发布 156,000 2026.01 记忆系统 2.0 + L3 智能体框架 280,000+ 为什么叫"龙虾"? Steinberger 在一次播客中解释:龙虾(Lobster)有两个钳子,代表 Agent 的"感知"和"行动"两个核心能力。龙虾有坚硬的外壳——代表安全性和隐私保护。龙虾在极端环境下也能生存——代表 Agent 的鲁棒性。而且,“OpenClaw” 里的 Claw 既是龙虾钳子,也是代码里的爪子(hook)。 ...

2026-06-25 · 2 min · 353 words · 硅基 AGI 探索者
openclaw agent review

OpenClaw 评测:个人 AI Agent 的开源实践

OpenClaw 的定位:个人 AI Agent 操作系统 OpenClaw 不是一个 Library,是一个运行时。你不需要在代码里 import 它——你启动它,它作为一个常驻服务运行,管理你的 AI Agent 的感知、决策和行动。 特征 OpenClaw LangChain/LangGraph CrewAI/AutoGen 形态 常驻服务(运行时) Python Library Python Library 使用方式 配置 + 自然语言 写代码 写代码 目标用户 非开发者 / 轻开发者 开发者 开发者 运行环境 本地机器 / 服务器 你的应用进程 你的应用进程 核心抽象 Skill + Memory + Channel Chain + Graph Agent + Crew 这个定位决定了 OpenClaw 的设计取舍——它更像一个"AI Agent OS",而不是一个"Agent 开发框架"。 架构拆解 OpenClaw 的架构可以简化为五层: ┌─────────────────────────────────────────┐ │ Channel 层(渠道) │ │ WebChat / Discord / WhatsApp / API │ ├─────────────────────────────────────────┤ │ Agent 层(核心) │ │ LLM 推理 / 工具调用 / 决策循环 │ ├─────────────────────────────────────────┤ │ Skill 层(能力) │ │ 邮件 / 搜索 / 文档 / 浏览器 / 自定义 │ ├─────────────────────────────────────────┤ │ Memory 层(记忆) │ │ MEMORY.md / Daily Notes / LCM 压缩 │ ├─────────────────────────────────────────┤ │ Scheduler 层(调度) │ │ Heartbeat / Cron / Event 触发 │ └─────────────────────────────────────────┘ Skill 系统:插件化能力 OpenClaw 的 Skill 是一个 Markdown 文件(SKILL.md),包含指令和可能的脚本: ...

2026-06-25 · 4 min · 655 words · 硅基 AGI 探索者
qwen cloud platform

阿里 Qwen Cloud 平台:从模型到 Agent 生态

从"中国最大模型实验室"到"AI 开发平台" 2026 年 6 月,阿里巴巴在杭州举办首届 Qwen Conference,正式发布 Qwen Cloud 平台。这不是一次简单的产品发布——它标志着阿里从"拥有中国最强开源模型"到"构建 AI 开发生态"的战略转型。 Qwen Cloud 的定位很明确:做 AI 时代的"阿里云"——一个让开发者从想法到部署、从模型到 Agent、从单机到集群的一站式平台。 Qwen Cloud 平台架构 三层架构设计 ┌──────────────────────────────────────────────┐ │ Agent Layer(智能体层) │ │ Qwen Agent Studio · 模板市场 · 插件生态 │ ├──────────────────────────────────────────────┤ │ Tool Layer(工具层) │ │ Qwen Code · Qwen Search · Qwen Vision │ │ 代码解释器 · 网页浏览 · API 编排 │ ├──────────────────────────────────────────────┤ │ Model Layer(模型层) │ │ Qwen3-Max · Qwen3-Plus · Qwen3-Turbo │ │ Qwen3-Coder · Qwen3-VL · Qwen3-Math │ │ 端侧:Qwen3-4B · Qwen3-1.8B │ ├──────────────────────────────────────────────┤ │ Infra Layer(基础设施层) │ │ 阿里云 PAI · GPU 集群 · 灵骏计算平台 │ └──────────────────────────────────────────────┘ 核心产品矩阵 产品 定位 核心功能 对标产品 Qwen Cloud Studio Web IDE 可视化 Agent 构建 + 代码编辑 OpenAI Playground + Coze Qwen Code CLI 工具 终端代码生成、重构、调试 GitHub Copilot CLI Qwen Agent Studio Agent 平台 可视化智能体编排 Dify, Coze Qwen Hub 模型仓库 模型下载、微调、部署 Hugging Face Qwen API API 服务 统一模型 API OpenAI API Qwen Code:终端里的 AI 编程助手 产品定位 Qwen Code 是 Qwen Cloud 生态中最受开发者欢迎的工具之一。它是一个基于终端的 AI 编程助手,支持命令行代码生成、代码审查、自动化重构、测试生成等功能。 ...

2026-06-25 · 3 min · 513 words · 硅基 AGI 探索者
鲁ICP备2026018361号