当前位置：首页 > news >正文

AgentScope：一个多Agent框架

news 2026/5/29 22:09:11

多 Agent 系统最容易“看起来很强，跑起来很乱”：工具调用不可控、状态不可观测、记忆越用越脏、链路一长就难调试。AgentScope 这类多 Agent 框架想解决的核心问题，本质是两件事：

把 Agent 的能力与运行生命周期标准化（工具、记忆、回调、编排）
把多 Agent 协作从“对话堆叠”升级为“可组合的流程系统”（Pipeline + 可观测）

一个可落地的多 Agent 系统，通常应该具备：

能力层：工具（读/写/执行/查询）与外部连接器（DB、搜索、工单、文件）
智能层：不同角色的 Agent（检索、规划、执行、审查、写作）
运行层：Pipeline 编排 + 状态/事件流 + 失败恢复
记忆层：短期上下文 + 长期知识/经历 + 可清理策略
集成层：把外部能力以标准协议接入（例如 MCP），避免私有胶水代码

下面逐块拆开。

1. @Tool

在多 Agent 框架里，@Tool（或 tool 装饰器/注册器）的意义远不止“让模型能调用函数”，而是把工具变成可控的系统接口。

1.1 一个好工具接口需要什么

你希望工具具备四个属性：

可发现：Agent 能“看见”有哪些工具可用
可校验：输入参数有 schema/类型约束，调用前就能拦住脏参
可观测：每次调用都有 trace_id、耗时、错误码、关键字段
可治理：权限、速率、幂等、敏感字段脱敏

因此 @Tool 的设计重点是：把函数签名变成契约。

1.2 工程建议：把工具分层，而不是一把梭

建议按风险与职责分层：

Read Tools（低风险）：搜索、查询、读取资源
Write Tools（高风险）：创建工单、发消息、改配置、触发部署
Compute Tools（中风险）：跑评估、生成报告、执行脚本（要沙箱）

对高风险工具，强烈建议配套：

requires_confirmation: true
idempotency_key
“dry-run 模式”（先返回将要执行的动作）

1.3 一个 @Tool 的伪代码轮廓

@Tool({ name: "ticket.create", description: "创建工单。高风险：会写入系统，需要 confirmation。", inputSchema: { type: "object", properties: { title: { type: "string", minLength: 3 }, priority: { type: "string", enum: ["P0","P1","P2"] }, description: { type: "string" } }, required: ["title","priority"] }, policy: { requiresConfirmation: true, rateLimitPerMin: 10 } }) async function createTicket(input) { // return { id, url, status } }

你会发现：工具“是否好用”不在于函数内部多复杂，而在于外部契约是否足够清晰。

2. Hook

Hook（回调/钩子）是多 Agent 系统可工程化的关键：你需要在关键生命周期点插入逻辑，而不是把所有能力塞进 prompt。

常见 Hook 点（概念上）包括：

on_before_plan：规划前（注入任务上下文、约束、路由信息）
on_after_plan：规划后（计划审计、预算估算、风险打标）
on_before_tool_call / on_after_tool_call：工具调用前后（参数校验、脱敏、trace、缓存）
on_message / on_token_stream：消息/流式输出（实时 UI、日志）
on_error / on_retry：错误与重试（退避、切换工具、降级路径）
on_episode_end：一次任务结束（写入长期记忆、生成总结、清理短期）

2.1 Hook 的三大用途

观测：日志、指标、链路追踪（谁调用了什么，耗时多少，失败原因）
治理：权限、审计、敏感信息处理、成本控制
增强：缓存、结果归一化、自动重试、fallback（例如搜索失败→换源）

2.2 最重要的建议：把“策略”放 Hook，而不是 prompt

例如“所有写操作必须二次确认”“任何包含 PII 的字段必须脱敏”“工具失败重试 2 次再降级”——这些如果写进 prompt，会非常不稳定；写进 Hook 才是系统工程。

3. 长短期记忆

多 Agent 的记忆通常分两类：

3.1 短期记忆（Short-term）

本质是当前任务的工作记忆：对话历史、计划、已用工具结果、临时结论。
关键点：短期记忆要“可裁剪、可结构化”。

AgentScope提供了多种短期记忆后端实现：

InMemoryMemory：内存实现，适合开发和单机部署场景
RedisMemory：Redis后端，适合多实例共享的分布式场景
AsyncSQLAlchemyMemory：关系数据库后端，支持连接池和框架集成

3.2 长期记忆（Long-term）

本质是跨任务可复用的知识与经验，常见包含：

用户偏好与约束（格式、口吻、禁用项）
领域知识索引（向量库/知识库）
Agent 自己的“经验总结”（哪些工具可靠、哪些路径容易失败）

AgentScope通过集成Mem0和ReMe两大长期记忆库，覆盖个人、任务和工具级别的记忆管理-1。长期记忆的核心优势在于：

跨会话持久化：用户今日的偏好，明日依然记得
语义检索：基于向量相似度而非关键词匹配进行召回
混合检索：结合结构化查询和向量语义搜索，提升召回精度

3.3 记忆与多 Agent 的关系：不要共享一锅粥

多 Agent 协作时，建议的做法是：

共享“事实资源”（知识库、可检索证据）
隔离“角色偏见”（不同 Agent 的策略/偏好不要互相污染）
用“协调者 Agent”管理全局状态，其他 Agent 用只读视图或局部写入

4. Pipeline

Pipeline 是多 Agent 系统真正的“生产力来源”。它解决的问题是：
一步一步做事可以，但要能并行、能回滚、能重试、能插人、能观测。

4.1 Pipeline 的基本形态

你可以把 Pipeline 看成由节点组成的 DAG/状态机：

Planner 节点：拆任务、生成步骤
Retriever 节点：检索证据
Executor 节点：调用工具做动作
Critic/Verifier 节点：校验一致性、风险与格式
Writer 节点：生成最终输出
Publisher 节点：发送/落库/归档

每个节点都应输出结构化产物（artifact），而不是只输出文本。

4.2 长任务与流式：让 Pipeline “边跑边交付”

Pipeline 很适合做流式任务：

节点级进度（正在检索/正在生成/正在校验）
artifact 流（先产出大纲、再产出章节、再产出最终稿）
失败时返回“已完成到哪里 + 下一步建议”

4.3 Pipeline 的关键工程要点

幂等：同一节点重跑不造成重复副作用（尤其写操作）
可恢复：失败后从最近 checkpoint 继续
可插人：在关键节点（写入/发布）要求人工确认
可观测：每个节点有统一 trace_id 与耗时/错误统计

5. MCP 集成

当你把系统做大，会遇到一个现实：工具来源越来越多（搜索、文件、工单、数据库、内部 API），每接一个都写一套适配，最后维护成本爆炸。

MCP（Model Context Protocol）的价值在这里体现：它把外部能力标准化为三类对象：

Tools：可调用动作
Resources：可读取上下文
Prompts：可复用提示模板

5.1 AgentScope 多 Agent 如何用 MCP（概念方案）

在 Pipeline 的“工具层”，接入 MCP Client：
- 启动时拉取多个 MCP Server 的 tool/resource/prompt 清单
- 将其映射为本地 @Tool 注册项（或动态工具集合）
用 Hook 做治理：
- on_before_tool_call：schema 校验、权限检查、敏感字段处理
- on_after_tool_call：结果归一化、缓存、写入短期记忆
用资源替代“把一堆文本塞 prompt”：
- Pipeline 节点输出 artifact URI
- 需要时按需读取 resource，减少上下文浪费