Plano 实战指南：用 AI 原生 Proxy 给多 Agent 应用装上智能路由与可观测性
把 Agent 应用从 demo 推到生产环境，最难的部分往往不是写 Agent 的逻辑本身，而是路由、编排、可观测性和模型管理这一整套「隐形中间件」。Plano（原名 ArchGW，GitHub 6.6k ⭐）正是为了解决这个问题而生的 AI 原生 Proxy 服务器，它基于 Envoy 构建，把 Agent 应用的通用基础设施抽离成一个统一的数据平面，让你用 YAML 声明配置就能获得智能路由、多 Agent 编排、自动可观测性和安全过滤链。
安装与启动
Plano 原生运行，不需要 Docker 或 Rust 工具链。首次启动时自动下载预编译的二进制文件：
curl -LsSf https://astral.sh/uv/install.sh | sh uv tool install planoai==0.4.26 planoai up config.yaml
预览版（v0.4.26）还处于快速迭代阶段，支持的 LLM 提供商包括 OpenAI、Anthropic、Google 等主流模型。
实战场景 1：统一 LLM 路由，告别 Provider 切换
团队使用多个 LLM 提供商是常态——GPT-5 写代码好，Claude 擅长复杂推理，本地模型省钱。Plano 在 12000 端口启动一个统一网关，所有应用只需指向它，路由策略在 YAML 里配置：
model_providers:
- model: openai/gpt-5.2
access_key: $OPENAI_API_KEY
default: true
- model: anthropic/claude-sonnet-4-5
access_key: $ANTHROPIC_API_KEY
- model: google/gemini-2.5-pro
access_key: $GOOGLE_API_KEY
应用代码里只需要写一个 base_url：
from openai import AsyncOpenAI
llm = AsyncOpenAI(base_url="http://localhost:12000/v1", api_key="EMPTY")
response = await llm.chat.completions.create(
model="openai/gpt-5.2",
messages=[{"role": "user", "content": "解释量子纠缠"}]
)
Plano 支持三种路由模式：模型名直连（openai/gpt-5.2）、别名路由（fast-cheap 映射到 google/gemini-2.5-flash）和偏好路由（自动按延迟/成本选择）。别名路由最实用——你可以在不修改应用代码的前提下换模型。
实战场景 2：多 Agent 编排，一个查询分派给两个 Agent
这是 Plano 最亮眼的能力。你只需定义每个 Agent 的 URL 和自然语言描述，Plano 内置的意图识别模型（4B 参数的 Plano-Orchestrator）自动判断查询该路由给哪个 Agent。下面的例子是一个旅行助手，同时对接天气和航班两个 Agent：
version: v0.3.0
agents:
- id: weather_agent
url: http://localhost:10510
- id: flight_agent
url: http://localhost:10520
listeners:
- type: agent
name: travel_assistant
port: 8001
router: plano_orchestrator_v1
agents:
- id: weather_agent
description: |
获取全球任意城市的实时天气和预报。
处理：「巴黎天气如何」「东京会下雨吗」
- id: flight_agent
description: |
搜索两机场之间的航班，含实时状态和时刻表。
处理：「纽约到洛杉矶的航班」「帮我查去西雅图的飞机」
Agent 代码只是实现了 OpenAI 兼容的 HTTP 端点：
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse
from openai import AsyncOpenAI
app = FastAPI()
llm = AsyncOpenAI(base_url="http://localhost:12000/v1", api_key="EMPTY")
@app.post("/v1/chat/completions")
async def chat(request: Request):
body = await request.json()
messages = body.get("messages", [])
weather_data = await fetch_weather_data(messages)
stream = await llm.chat.completions.create(
model="openai/gpt-4o",
messages=[{"role": "system", "content": f"天气数据：{weather_data}"}, *messages],
stream=True
)
return StreamingResponse(
(f"data: {chunk.model_dump_json()}\n\n" async for chunk in stream),
media_type="text/event-stream"
)
启动后，一个查询会自动路由到两个 Agent 并在同一次对话中返回完整结果：
curl http://localhost:8001/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4o",
"messages": [{"role": "user", "content": "下周想去巴黎，天气如何？帮我查下航班"}]
}'
新增 Agent 时只需在 YAML 中添加配置然后重启——不需要改任何路由代码。
实战场景 3：零代码可观测性与过滤链
Plano 自动为每个请求生成 OpenTelemetry 链路追踪，完全不需要埋点代码。每次 Agent 调用自动在 traces 中可见，包含路由决策、模型调用、过滤链处理等全部 span。
更强大的是 Filter Chains——你可以在请求到达 Agent 之前插入一系列过滤步骤，每个 Filter 是一个独立的 HTTP 服务。典型用途包括：
- 安全检查：在请求进入 Agent 前做 Jailbreak 检测
- 上下文增强：自动注入用户历史记忆
- 合规拦截：检测敏感数据后直接短路返回
filters:
- id: jailbreak_check
url: http://localhost:9001/check-jailbreak
- id: pii_redaction
url: http://localhost:9002/redact-pii
model_providers:
- model: openai/gpt-4o-mini
access_key: $OPENAI_API_KEY
default: true
listeners:
- type: agent
name: secured_assistant
port: 8001
router: plano_agent_router
agents:
- id: my_agent
filter_chain:
- jailbreak_check
- pii_redaction
每个 Filter 可以修改请求、短路返回或者只是记录日志——这给了你在不修改 Agent 代码的前提下，全局统一控制安全策略的能力。
最佳实践
- 首选别名路由：别让模型名硬编码在应用里。用
fast,precise,cheap这样的别名，调模型时只需改 YAML - 用 Agent 描述精细调优：
description字段写得越具体，Orchestrator 的路由准确率越高。包含示例查询语句帮助巨大 - Filter Chain 先过安全检查：Jailbreak 检测应该放在 Filter Chain 的第一位，这样不会对越狱请求浪费模型调用费
- 本地开发用 Plano 自带模型：Plano-Orchestrator 免费托管在美国中部地区，开发阶段直接用，生产环境才需要自部署
- 随机采样的链路追踪：设置
tracing.random_sampling: 100采集全部 trace，配合 Agentic Signals 从生产流量中提取改进信号
总结
Plano 把 Agent 应用的「隐形成本」——路由、编排、可观测性和模型管理——从分散的框架代码集中到了一个统一的数据平面。相比每个 Agent 单独写意图分类器、各自挂监控，Plano 的声明式 YAML 加 AI 原生路由，让团队能更快地把 Agent 推到生产环境。如果你正在构建多 Agent 系统或者管理多个 LLM 模型，Plano 值得一试。
相关链接：