1.2 关键特性与功能概览

1.2 关键特性与功能概览

在体系中的位置：1.1 帮你判断"要不要多智能体"，这一节具体看 AgentScope 给了你哪些能力积木。读完你应能把这些特性对号入座到"通信、智能体、环境、工具、记忆、容错"六个槽位里。

框架文档最爱罗列一长串特性，但特性之间是有主次之分的。我把它分成两组：骨架特性（没了它就不再是 AgentScope）和增益特性（有则更好，没有也能跑）。区分这两组，你才知道升级时什么不能动、什么可以取舍。

先看骨架：四根柱子

我们先看四根柱子，它们决定了 AgentScope 的"形状"。

第一根：消息驱动的通信。 所有交互走消息，智能体之间不直接调用方法。这听起来约束，实则是松耦合的前提。第二章 2.4 会展开讲消息格式和路由，这里先记住结论：消息是 AgentScope 的通用货币。

第二根：可编程的智能体。 智能体不是配置项，而是你用代码定义的类。它内部封装模型、记忆、工具，对外只暴露"收消息、回消息"。这种封装让每个智能体能维持自己的角色纪律（呼应 1.1 的临界点）。

第三根：环境作为中介。 智能体不直接操作共享世界，而是通过环境读写状态、触发规则。环境是"舞台"，智能体是"演员"。这条把 1.1 说的"灵活在业务、鲁棒在基础"落到了具体组件上。

第四根：内置容错。 消息发送失败能重试，智能体异常能被隔离，关键状态能持久化。这是 2.0 主线把"鲁棒"做成一级特性的体现。

# 四根柱子的一次最小聚合：两个智能体经 MsgHub 对话
import asyncio
from agentscope.agents import DialogAgent
from agentscope.msghub import MsgHub
from agentscope.models import OpenAIChatModel
from agentscope.message import Msg

model = OpenAIChatModel(model_name="gpt-4o-mini", api_key="环境变量占位")

planner = DialogAgent(name="规划者",
                      sys_prompt="你负责把任务拆成步骤。",
                      model=model)
coder = DialogAgent(name="执行者",
                    sys_prompt="你负责按步骤写代码。",
                    model=model)

async def run():
    async with MsgHub([planner, coder],
                      announcement=Msg("user", "做一个去重函数", "user")) as hub:
        await planner()      # 规划者发言，消息自动广播给执行者
        await coder()        # 执行者能看到规划者的消息后回应
        # MsgHub 在这里同时承担了"消息驱动"和"环境中介"两种角色

asyncio.run(run())
​

运行输出（典型）：规划者先输出步骤列表，执行者紧接着输出代码实现。二者都在同一个 MsgHub 上下文里，所以执行者天然看得到规划者的发言，无需手动传参。这就是四根柱子合起来的体感——你只定义了"谁是谁、说什么"，路由和广播是框架给的。

增益特性：能省事但要会权衡

骨架之外，有几项增益特性，用得好是效率，用不好是负担。

可插拔模型。 换模型基本是换一行配置。但注意：不同模型的工具调用能力、上下文长度差异很大，换模型不是零成本，要在 3.5 性能优化里重新评估。

工具沙箱。 工具在受控环境里执行，避免智能体生成的代码直接伤到宿主。代价是工具调用有序列化开销，高频调用场景要测延迟。

可视化观测。 AgentScope Studio 能把消息流、智能体状态画出来。调试多智能体几乎必备，但生产环境要关掉或限制访问，别把内部状态暴露出去。

增益特性不是文档话术，下面这段把"可插拔模型"和"工具沙箱"一次配齐，你能看到换模型只是换一个 provider 参数，工具在沙箱里执行与直接调用写法一致。

# 增益特性落地：可插拔模型 + 工具沙箱
from agentscope.models import ModelConfig, build_model
from agentscope.agents import ReActAgent
from agentscope.toolkit import Toolkit
from agentscope.tools import tool

# 可插拔模型：今天用 A 厂商，明天换 B 厂商，业务代码不动
cfg = ModelConfig(provider="openai", model_name="gpt-4o-mini", api_key="环境变量占位")
model = build_model(cfg)

@tool
def calc(expr: str) -> str:
    """在沙箱中安全计算数学表达式，避免直接 eval 伤宿主。"""
    try:
        return str(eval(expr, {"__builtins__": {}}))  # 受限命名空间
    except Exception as e:
        return f"计算出错: {e}"

tk = Toolkit()
tk.register_tool(calc)

agent = ReActAgent(
    name="计算助手",
    sys_prompt="用户给算式时调用 calc 工具。",
    model=model,
    toolkit=tk,
)
# agent(Msg(name="user", content="3*(4+5) 等于多少？", role="user"))
​

运行输出（典型）：智能体识别到"3*(4+5)"是算式，调用 calc("3*(4+5)")，沙箱返回 "27"，最终回复"结果是 27。"工具在受限命名空间里执行，即便表达式带恶意调用也触不到宿主，这就是"工具沙箱"增益特性的体感。

记忆后端可替换。 从内存到向量库到 SQLite，记忆存哪由你定。这给长期任务留了口子，但也意味着你要为"选错后端导致检索慢"负责。

特性对照表：看清彼此的代价

把上面这些摆进一张表，你一眼能看出每项特性的收益和代价，而不是被"支持 XX"这种话术带跑。

这张表是后面选型时的速查。你会发现一个规律：几乎所有增益特性都用"一点运行时开销"换"一点工程安全或效率"。AgentScope 的价值观很明确——宁可慢一点，也要稳一点。这跟它"鲁棒"的底座一致。

案例：一个被特性组合救回来的故障

背景：某客服系统用三个智能体（接待、查单、退款），某天查单智能体依赖的外部接口超时。

操作（无容错版设想）：查单智能体抛异常，消息链断裂，用户看到"系统错误"。

操作（用 AgentScope 容错版）：查单智能体在 MsgHub 中抛出异常，框架把异常转成一条"查单失败"消息广播，接待智能体收到后改为告知用户"正在重试"，并触发限次重试；重试耗尽则转人工消息。

结果：用户没看到崩溃，体验是"稍等，正在处理"。

解读：这里用到的不是某个炫酷特性，而是"消息驱动 + 容错"两根柱子的组合。故障被表达成消息，而不是被表达成进程崩溃，所以系统还能继续协商。

变式：如果查单接口是核心且常挂，正确做法不是加重试，而是把查单智能体拆成"查单"和"兜底话术"两个，让兜底话术订阅"查单失败"消息直接接管。特性用错了方向，重试反而会拖慢。

选型速查

• 四根骨架柱子：消息驱动、可编程智能体、环境中介、内置容错——缺一根就不是 AgentScope 的玩法。
• 增益特性（可插拔模型、工具沙箱、可视化、记忆后端）用"运行时开销"换"安全/效率"，按需取用。
• 特性选择的规律：几乎都用一点性能换一点稳健，符合框架"鲁棒优先"的价值观。
• 容错的正确打开方式，是把故障表达成消息让系统继续协商，而不是靠重试硬扛。

⚠️ "支持可视化观测"不等于"生产环境该开着"。Studio 暴露内部状态，上线前要关或加访问控制，否则等于把系统内部摊给外人看。

💡 选型时先问"我的故障会不会被表达成消息"——能表达，容错就接得上；表达不了（比如智能体内部死循环），再加特性也没用，得回到代码逻辑改。