Plano
面向智能体应用的代理与数据平面，统一编排、模型路由、可观测性和护栏。
工作流使用显式的只读内容权限，并将发布权限限定为包写入；配置也通过环境变量引用密钥，而不是在示例中硬编码真实凭据。README披露了代理、模型提供商、过滤器、追踪以及免费托管模型位于美国中部等主要数据路径，工作流还包含Trivy扫描和依赖覆盖。但运行监听器示例绑定0.0.0.0，零配置模式可启用透传认证和全量追踪，未见最小网络权限、用户确认门、消息脱敏、密钥生命周期、追踪保留政策或生产权限建议。Trivy忽略未修复漏洞，在主分支推送时不阻断，且使用master标签和若干curl安装步骤。回退证据主要是planoai down、配置迁移测试及镜像标签，缺少明确的数据或版本回滚流程。项目、Envoy和研究来源有所注明，但核心贡献者和研究领先性表述较笼统，发布者身份及具体维护归属无法由材料确认。未发现红线行为。
README的路由、OpenAI兼容接口、配置版本和追踪主张得到配置测试、原生健康检查、Docker构建以及多提供商和多Python版本工作流的部分印证；配置验证覆盖重复项、未知过滤器、迁移和通配符错误。可用性方面支持本地构建、Docker、多架构和多个模型提供商，也提供健康检查与停止步骤。扣分在于本次未执行任何测试，多个端到端任务依赖外部密钥、网络、托管模型和特定运行器；安装脚本及GitHub发布缓存也是外部可用性依赖。失败消息有具体断言、超时和日志输出，但没有展示运行时面向终端用户的系统化错误分类、重试、降级或恢复语义。
目标用户和场景非常明确：生产化代理应用、模型路由、多代理编排、护栏、可观测性和示例旅行代理均有具体说明，因此受众与场景证据充分。能力边界通过模块化监听器、代理HTTP接口、模型提供商、过滤链和配置模式得到较好界定，且验证测试限制重复定义、缺失过滤器和不兼容通配符。自然语言代理描述和路由偏好提供了触发依据，但没有静态证据说明歧义消解、置信阈值、误路由处理或人工接管。环境适配较强，材料明确支持任意语言或框架、OpenAI兼容HTTP、原生与Docker运行、AMD64/ARM64以及Python 3.10至3.14；未因未执行验证而扣减这些静态可见能力。
README具有概览、架构、分步示例、能力表、入门链接、贡献和联系入口，信息架构清楚；安装说明指向快速入门并给出启动和查询命令，但关键前置条件留在外部文档，源内安装细节不完整。名称和配置版本总体一致，并有v0.3.0到v0.4.0迁移及旧监听器转换测试；不过README示例、旧llm_providers名称和当前model_providers形态并存，显示仍有迁移复杂度。示例丰富且指向完整演示，但没有独立FAQ。限制只披露了免费托管区域和生产扩展选择，没有系统列出安全、隐私、容量或兼容性限制。Apache-2.0全文完整，故许可证满分。版本号出现在包、配置和镜像中，但未提供变更日志或清晰发布政策。贡献指南、路线图和Discord形成更新路径，但所给材料没有明确列出具名维护者或责任边界，且发布者身份未知。
YAML配置、OpenAI兼容端点、curl请求、演示路径、自动追踪和配置校验使产物具备较好的直接可用性；把跨代理路由、模型适配、过滤和遥测集中到数据平面，显示出相对于逐应用自建中间件的实质增量价值。扣分在于效果证据主要是设计、示例和工作流定义，本次静态审查没有运行结果。关于更低成本、低延迟、生产级路由及以4B模型获得成本优势的说法没有基准、测量方法或数值，因此成本收益只能评为薄弱支持。
主要功能主张可追溯到README配置、测试用例和CI任务：提供商检测、配置迁移、过滤器引用、健康检查、多架构镜像和安全扫描均有对应材料，且多种文件之间形成一定交叉印证。扣分在于只提供了有限文件，无法检查核心代理实现、架构图内容、完整演示、锁文件、扫描结果或CI实际状态。README将“行业领先研究”“生产级”“低延迟”“零代码”和成本优势等宣传性推断与可观察事实并列，未清晰标示测量、假设和推断边界，因而事实与推论分离较弱。
- 零配置透传认证和全量追踪可能把请求内容或调用方凭据传给外部模型与遥测端点；生产使用前应核实数据目的地、脱敏、保留和访问控制。
- 示例监听0.0.0.0，材料未展示默认网络隔离或用户确认机制；部署时应限制绑定地址、入站访问、出站提供商和过滤器权限。
- 不要把CI定义视为成功测试结果；本次是未执行的静态审查，且多个端到端任务依赖外部密钥和服务。
- 安全扫描在主分支推送时不阻断并忽略未修复项，部分动作或安装源也未固定到不可变摘要；应另行检查锁文件、SBOM、扫描结果及供应链固定策略。
- 托管模型的生产容量、隐私条款、成本和服务保证未在材料中说明，发布者及具体维护责任也未验证。
这个 Agent 能做什么，适合哪些场景？
Plano 是构建于 Envoy 之上的进程外数据平面，用于集中处理智能体应用的基础设施逻辑。开发者在 YAML 中声明智能体 HTTP 地址、自然语言描述、模型提供商、监听器、路由器和追踪策略，而业务智能体继续作为独立 HTTP 服务运行。智能体需要实现兼容 OpenAI 的 `/v1/chat/completions` 接口；Plano 接收同类请求，并把对话路由到一个或多个合适的智能体。它还能通过统一的 LLM API 按模型名、语义别名或偏好选择模型，并支持 OpenAI 与 Anthropic 配置示例。每次请求可自动生成 OpenTelemetry 追踪、指标和日志，Filter Chains 则用于接入越狱防护、内容审核和记忆逻辑。它适合希望自托管控制平面、保留语言和框架选择权，并愿意采用代理式网络边界的团队。
Plano 通过 planoai up config.yaml 读取 YAML 配置并启动监听器。配置中的 agents 定义智能体 ID 和 URL，listeners 定义对外端口及 plano_orchestrator_v1 等路由器，model_providers 保存模型标识、访问密钥和默认提供商。客户端向监听器的 /v1/chat/completions 发送 OpenAI 格式的消息；Plano 根据各智能体的自然语言描述进行低延迟路由，可在一次对话中依次调用多个智能体，并把最终结果返回给客户端。智能体自身也是 HTTP 服务器，可使用任意语言或框架，并可将 OpenAI SDK 的 base_url 指向 Plano 的 LLM 网关。网关处理提供商适配和模型选择，Filter Chains 可插入审核、护栏及记忆钩子，同时系统自动采集 Agentic Signals、OpenTelemetry traces、metrics 和 logs。
- 拥有多个专用 HTTP 智能体的平台团队，希望通过 YAML 描述其职责，而不是自行编写意图分类器和路由代码。
- 需要在 OpenAI 与 Anthropic 模型之间切换的应用团队，希望把提供商适配、模型别名和回退相关逻辑移出业务服务。
- 准备把智能体原型投入生产的运维团队，需要无需逐个服务埋点即可获得端到端 OpenTelemetry 追踪、指标和日志。
- 安全团队希望通过统一的 Filter Chains 为多个智能体接入越狱防护、内容审核政策或记忆钩子。
- 构建旅行助手等多智能体体验的开发者，需要在同一次对话中先后调用天气、航班等不同智能体。
这个 Agent 有哪些优点和局限？
- 把智能体编排、模型管理、护栏和可观测性集中到独立数据平面，新增智能体主要通过配置完成，无需修改应用路由代码。
- 智能体只需提供兼容 OpenAI 的 HTTP 接口，因此不绑定特定编程语言或智能体框架。
- 支持按模型名、语义别名或偏好进行路由，并明确展示了 OpenAI 和 Anthropic 提供商配置。
- 自动采集端到端 OpenTelemetry traces、metrics、logs 和 Agentic Signals，减少每个服务单独埋点的工作。
- 编排、LLM 路由和护栏可作为模块按需组合，并采用专门的轻量级路由模型。
- 所给材料没有提供 CLI 安装命令、最低运行时版本、资源需求或完整生产部署步骤，采用前必须另行核实。
- 现有智能体必须暴露兼容 OpenAI 的
/v1/chat/completionsHTTP 接口；不符合该协议的服务需要适配。 - 配置变更后新增智能体需要重启，材料没有说明动态热加载能力。
- 默认首体验依赖托管在美国中部区域的 Plano 系列模型；生产扩展需要本地运行这些模型或联系项目方获取 API 密钥。
- 运行路径增加了独立代理和网络跳转，团队需要部署、监控并排查这一额外数据平面。
如何安装或部署这个 Agent？
源码没有给出 Plano CLI 的具体安装命令、受支持的操作系统、容器启动命令或最低运行时版本。开始前需要按照项目所指的 prerequisites guide 安装 Plano 并配置环境；仅凭所给材料无法提供可验证的完整安装命令。示例还要求准备所用模型提供商的凭据，例如 OPENAI_API_KEY 或 ANTHROPIC_API_KEY。
如何使用这个 Agent？
- 创建
config.yaml，设置version: v0.3.0，在agents中填写每个智能体的id和 HTTPurl，并在listeners中配置type: agent、监听端口、路由器及智能体描述。 - 在
model_providers中配置诸如openai/gpt-4o或anthropic/claude-3-5-sonnet的模型，并通过$OPENAI_API_KEY或$ANTHROPIC_API_KEY引用凭据。 - 运行实现
/v1/chat/completions的智能体 HTTP 服务。如需通过 Plano 调用模型，可将 OpenAIAsyncOpenAI客户端设为base_url="http://localhost:12001/v1"、api_key="EMPTY"。 - 启动数据平面：
planoai up config.yaml。 - 首次调用可执行：
curl http://localhost:8001/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"gpt-4o","messages":[{"role":"user","content":"I want to travel from NYC to Paris next week. What is the weather like there, and can you find me some flights?"}]}'。示例配置会把请求路由到天气和航班智能体，并返回组合后的旅行信息。
这个 Agent 与同类方案有什么区别？
与在每个应用中自行实现意图分类、提供商适配、模型回退和 OpenTelemetry 埋点相比，Plano 将这些职责集中到 YAML 配置驱动的进程外数据平面。项目还将其专用 4B 参数编排模型与使用 GPT-4 或重量级框架执行路由的方式对比，主张前者具有更低的成本和延迟；所给材料没有提供独立基准数据。
常见问题
Plano 是否强制使用某一家模型提供商？
openai/gpt-4o 和 anthropic/claude-3-5-sonnet，并支持按模型名、语义别名或偏好路由；使用外部服务时仍需对应提供商凭据。现有智能体需要怎样改造？
/v1/chat/completions 端点。若现有服务使用其他协议，需要增加适配层。