Shannon：设计一个生产级多 Agent 平台

大多数 agent 框架给你的是构建模块。Shannon 给你的是一个生产系统。

生产问题

构建 AI agent 很容易。让它们在生产环境里可靠运行，很难。

团队在用 LangGraph、CrewAI 或类似框架做完原型后，通常都会撞上同一组墙：

• 失控成本：一个配置错误的 agent，几个小时就能烧掉几千美元
• 非确定性失败：凌晨 3 点 agent 挂了，你怎么复现这个 bug？
• 安全噩梦：会执行代码或调用 API 的 agent，本身就是攻击面
• 可观测性缺口：token 花到哪里去了？哪个 agent 失败了？决策路径是什么？
• 厂商锁定：换 LLM provider 就意味着重写集成代码

Shannon 从第一天起就是为了解决这些生产问题而设计的：不是事后补丁，而是核心架构决策。

架构：为什么是三种语言？

Shannon 的混合架构不是偶然的。每种语言负责自己最擅长的部分：

Go 做编排

编排层运行在 Temporal 上，而 Go 是 Temporal 的原生语言。这个选择让 Shannon 获得了：

• 确定性 replay：每次 workflow 执行都是 event-sourced。导出任何失败 workflow，在本地 replay，就能精确复现 bug。
• 持久执行：任务能跨越服务重启、网络故障和进程崩溃。不会丢工作。
• 内置重试：按 activity 配置的指数退避自动重试。
• Workflow 版本化：部署新版本 workflow 时，不会破坏正在运行的任务。

不同于其他框架里的状态机或顺序执行，Temporal workflow 天生就是 replay-safe 的。每个决策点都会被记录。每条执行路径都能复现。

Rust 做安全

Agent core 处理的是安全敏感操作，性能和安全都不能妥协：

• WASI 沙箱：运行不可信 Python 代码，无网络访问，只读文件系统。WebAssembly 的安全模型会阻止逃逸。
• gRPC gateway：agent 执行路径上的亚毫秒级开销。延迟关键处用 native code。
• 策略强制：集成 OPA（Open Policy Agent），做细粒度治理。

Rust 的内存安全保证，直接消除了 enforcement layer 里整类安全漏洞。

Python 做 LLM 集成

LLM 服务留在 Python，是因为：

• Provider 生态：几乎每个 LLM provider 都有 Python SDK。跟这件事对抗没有意义。
• 快速迭代：新模型、新工具每周都在出现。Python 的灵活性让集成足够快。
• MCP 工具：通过 YAML 配置添加工具，不需要改代码。

Shannon 支持 15+ LLM provider，包括 OpenAI、Anthropic、Google Gemini、DeepSeek，以及通过 Ollama、LM Studio、vLLM 接入的本地模型，并支持 provider 之间的自动 failover。

解决失控成本

预算控制在 Shannon 里不是一个 feature，而是基础设施。

硬 Token 上限

每个任务都有强制预算上限。到达上限后，执行停止。没有例外，没有超支。

系统在多个粒度追踪成本：

• 按任务：整个 workflow 的总预算
• 按 agent：单个 agent 的 token 消耗
• 按模型：按 provider 和 model tier 归因成本

自动模型降级

当任务接近预算上限时，Shannon 可以自动切换到更便宜的模型。一个 research task 可能先用 Claude Opus 做复杂推理，再切到 Haiku 做综合总结——这一切通过 policy 配置，而不是写进代码。

实时成本归因

每个 workflow 都会返回详细成本拆分：

{
  "usage": {
    "total_tokens": 8547,
    "cost_usd": 0.0127
  },
  "agent_usages": [
    { "agent_id": "research-coordinator", "cost_usd": 0.0031 },
    { "agent_id": "web-search", "cost_usd": 0.0051 },
    { "agent_id": "synthesis", "cost_usd": 0.0045 }
  ]
}

你可以按 agent、model 或时间范围查询成本。token 预算花到哪里，一目了然。

解决非确定性失败

AI 系统里最难的调试问题：复现非确定性 workflow 里的失败。

时间旅行调试

Shannon 的 Temporal 基础提供真正的 workflow replay：

1. 导出：捕获任意失败 workflow 的完整事件历史
2. 本地 replay：用完全相同的输入和决策点重新执行 workflow
3. 逐步检查：查看每个 agent 决策、工具调用和 LLM 响应
4. 修复并验证：应用修复后再次 replay，确认问题解决

AI workflow 不该再有“我本地可以”的调试困境。每一次生产失败都应该能被精确复现。

Event-Sourced 执行

每个 workflow 决策都会被记录为事件：

• Agent spawned
• Tool invoked with parameters
• LLM response received
• Budget checkpoint reached
• Approval requested/granted

这条审计轨迹同时服务于调试和合规。

解决安全漏洞

会执行代码或调用外部 API 的 agent 是攻击面。Shannon 对这件事很认真。

WASI 沙箱

Python 代码执行发生在 WebAssembly 沙箱中：

• 无网络访问：代码不能发起外部 API 调用
• 只读文件系统：代码不能持久化恶意 payload
• 内存限制：防止资源耗尽攻击
• 执行超时：杀掉 runaway process

这个沙箱是在 WebAssembly runtime 层强制的，不是依赖 Python 的信任模型。

OPA 策略治理

对 agent 能做什么进行细粒度控制：

• 每个 agent 能调用哪些工具
• 哪些外部 API 被允许
• 按用户、租户或任务类型设置预算上限
• 高风险操作的人类审批要求

策略以声明式方式定义，并在所有 workflow 中一致执行。

多租户隔离

企业部署获得完整的租户隔离：

• 独立 memory store（Redis namespace、Qdrant collection）
• 独立预算池
• 隔离的 policy 配置
• 每租户独立审计日志

智能 Workflow 选择

Shannon 不要求你手动构建 workflow。编排器会分析任务特征，并路由到最合适的执行模式。

8+ 内置 Workflow 模式

核心模式：

• SimpleTask：低复杂度请求的单 agent 执行
• Supervisor：协调带依赖关系的多 agent
• Streaming：面向交互场景的实时 token streaming

认知模式：

• DAG：fan-out/fan-in 并行执行
• ReAct：带工具使用的迭代推理
• Research：多步骤研究，包含 citation filtering 和 gap detection
• Tree-of-Thoughts：复杂决策中的探索式推理
• Scientific：多视角验证的假设检验

路由逻辑会考虑任务复杂度、依赖结构和认知策略需求，然后自动选择合适模式。

定时执行

生产负载经常需要定时任务。Shannon 支持基于 cron 的调度，并且每次执行都有预算上限：

• 每日 research digest
• 周期性数据分析
• 定时报表生成

每次定时执行都会继承和交互式任务一样的预算控制与可观测性。

访问方式

Shannon 为不同使用场景提供多种接口：

OpenAI-Compatible REST API

在 /v1/chat/completions 上兼容 OpenAI API 格式。现有应用可以无代码修改迁移。

Python SDK

官方 SDK 带 CLI 支持，适合脚本和自动化：

from shannon import ShannonClient

with ShannonClient() as client:
    result = client.submit_task(
        query="Analyze market trends",
        cognitive_strategy="research"
    )

原生桌面应用

为 macOS、Windows、Linux 提供预构建应用，带 system tray 集成。不依赖浏览器，本地优先交互。

Web UI

用于 workflow 监控、成本分析和调试的开发 dashboard。

记忆架构

Agent 既需要快速的 session memory，也需要长期 recall。Shannon 两者都有：

Session Memory（Redis）

用于活跃对话的快速、短暂存储：

• Token usage tracking（防止对话中途预算超支）
• 最近消息历史
• Session metadata

Vector Memory（Qdrant）

用于语义 recall 的长期存储：

• 相似 workflow 检索
• 跨 session 上下文
• Diversity sampling，避免冗余记忆

Agent 会根据上下文需求自动查询这两个存储。

可观测性栈

生产系统需要生产级可观测性。

实时事件流

SSE endpoint 会实时 stream 执行事件：

• Agent thinking states
• Tool invocations
• Decision points
• Completion status

Prometheus Metrics

用于监控和告警的完整 metrics：

• 按 workflow type 统计的任务执行数
• 按 model 和 provider 统计的 token 使用
• 延迟分位数（p50、p95、p99）
• 预算使用率

OpenTelemetry Tracing

跨所有服务的分布式 tracing。每次 agent 执行都是一个 trace span，可以做端到端延迟分析。

Grafana Dashboards

内置用于成本监控、workflow 性能和系统健康的 dashboards。

框架对比

Shannon 适合什么场景

• 你需要确定性 replay 来调试生产失败
• 你在运行带复杂依赖的多 agent workflow
• 你需要按 agent 归因成本，并强制执行硬预算
• 你想把本地模型和云 provider 放在一起跑
• 你需要集成私有 API，而不想 fork 框架
• 你想要无厂商锁定的自托管基础设施

什么时候替代方案更合适

• LangGraph：快速原型、Python-native workflow、LangSmith 生态
• CrewAI：简单顺序 agent 模式、最少基础设施
• AgentKit：可视化 workflow builder、全托管平台、没有运维负担

设计哲学

Shannon 体现了几条明确的架构选择：

1. 生产优先：每个 feature 在考虑便利性之前，先考虑失败模式、成本影响和安全边界。

2. 合适的工具做合适的事：三种语言不是复杂性，而是用 Go 的并发做编排，用 Rust 的安全做 enforcement，用 Python 的生态做 LLM 集成。

3. 配置优于代码：新增 provider、tool 和 policy 不应该需要改代码。YAML 配置提供运维灵活性。

4. 默认可观测：每个 workflow 都产生成本数据、执行 trace 和审计日志。可观测性不是可选项。

5. 自托管，无锁定：企业团队需要控制自己的基础设施。Shannon 完全运行在你的硬件上，没有云依赖。

开始使用

Shannon 以 MIT license 开源：

• Repository: github.com/Kocoro-lab/Shannon
• Documentation: /docs 下有完整指南
• Python SDK: pip install shannon-sdk

使用 Docker Compose 跑 quickstart 不到 5 分钟。对正在评估多 agent 平台的团队来说，Shannon 提供的是一个生产就绪的基础，而不是常见的从原型到生产之间的断崖。

如果你正在构建 AI agent，并已经撞上成本控制、调试或安全这些墙，Shannon 正是为这些问题设计的。Star 这个 repo，试试 demo，然后带着你的使用场景开一个 issue。