LangWatch
面向 LLM 应用的评测、智能体测试、追踪与生产监控平台。
证据明确披露本地 CLI 会安装多个服务、生成本地密钥、打开本地端口，并说明 Langy 工作进程以用户身份无沙箱运行；CI 使用只读 contents 权限，外部密钥发布流程也有目标仓库与失败保护。敏感数据方面提到轨迹密钥和 PII 脱敏、外部 Secret、数据驻留、自托管及漏洞披露流程。许可证、NOTICE 路径和版权主体提供了充分来源归属。扣分在于：未见面向运行时组件的完整最小权限模型或逐项数据流清单；安装、联网、发布和删除 ~/.langwatch 等外部效果没有展示交互式确认机制；安全与合规声明部分只是陈述；依赖虽固定版本且 GitHub Actions 固定提交，但没有提供该修订的依赖审计或漏洞扫描结果；回滚主要是整目录重置、Helm 卸载和备份机制，缺少细粒度恢复说明。
README、package 清单、Go 模块、CI 和 Helm 测试形成一致的产品与部署叙述；插件发布会核对双清单版本、标签和镜像内容，测试覆盖升级密码保持、缺失 Secret、备份告警及多种部署模式。错误路径包含明确的 ::error::、FAIL 和可操作诊断，因此失败消息证据充分。扣分仅在依赖可用性：系统依赖 Node、pnpm、uv、数据库、容器、Helm/Kubernetes及大量第三方模块，虽有版本约束和 frozen lockfile 用法，但所给材料没有离线供应、镜像可用性或依赖失效策略的完整证明。
材料明确面向需要回归测试、模拟、评估、可观测性和治理的团队，并覆盖云端、本地、Docker Compose、Kubernetes、OnPrem、混合部署及多种框架和模型提供商，环境适配证据很强。功能开关、备份开关、外部 Secret、单副本与多副本测试也展示了条件化行为。扣分在于能力边界主要散落在安装说明、安全范围和许可说明中，没有统一的支持矩阵；触发精度在 CI 路径门控和配置验证中证据良好，但没有提供 Agent 本身所有工具调用、自动动作或运行触发条件的完整静态定义。
README 结构清楚，涵盖定位、安装、部署、集成、支持、贡献、许可与安全；本地和容器安装命令、运行地址、环境变量及依赖体积均较具体。插件发布流程强制多个清单、版本与标签一致，许可证正文和开源/企业目录边界明确；安全邮箱、GitHub Issues、Discord和企业支持说明了维护路径。扣分在于示例主要是快速开始链接和部署命令，所给材料没有完整 FAQ；限制虽披露无沙箱运行、资源体积及若干部署条件，但没有集中、全面的已知限制清单；版本号和发布标签机制存在，发布注释提到 changelog，但未提供实际 changelog 内容或兼容性政策。
产品输出围绕轨迹、数据集、评估、模拟、告警、注释、提示词版本和治理，形成可直接用于测试与运维的工作流；将观测、评估、模拟和网关整合在一个平台，相比自行拼接工具具有明确的边际价值。扣分在成本收益：材料给出组件下载体积、预算控制和约 700 ns 热路径开销等信息，但没有提供测量方法、基准数据、总体资源需求或云端价格，因此不能充分验证实际成本收益。
若干声明可追溯到具体静态材料：package 元数据支持产品定位，工作流支持版本与发布一致性，Helm 脚本支持 Secret、升级、备份和告警行为，LICENSE 支持许可声明；这些来源之间也有一定交叉印证。扣分在于许多核心产品、安全、合规、无锁定及性能声明只在 README 中出现，外部文档内容未随提示提供，且没有执行结果；营销性事实、推断和经验证结论没有被系统区分，尤其是合规状态、全面可见性及性能数字。
- 本地快捷安装会把多个运行时和数据服务写入 ~/.langwatch，启动本地端口，并默认启用以当前用户身份无沙箱运行的 Langy；应先审查安装包与运行权限，并在隔离环境中评估。
- 不要把 rm -rf ~/.langwatch 当作可恢复的普通回滚；它会删除该目录中的本地配置、密钥和数据，执行前应确认备份和准确路径。
- README 中的 GDPR、ISO 27001、约 700 ns 开销、脱敏和无锁定声明未由所给静态材料独立证明，采购或生产部署前应索取相应报告、基准和数据流说明。
- 依赖图庞大且包含未来时间戳式伪版本；本次仅依据清单静态审查，未运行漏洞扫描、构建、测试或来源完整性验证。
- 仓库采用 Apache-2.0、MIT SDK 与商业企业模块的开放核心拆分；分发或生产使用前应核对目标目录及对应许可证。
这个 Agent 能做什么，适合哪些场景？
LangWatch 用于在发布前和生产环境中测试、模拟、评测及监控 LLM 驱动的智能体。它把 OpenTelemetry 追踪、数据集、离线评测、提示词与模型优化以及复测连接成一个工作循环，并提供运行审阅和失败标注功能。场景模拟会覆盖工具、状态、用户模拟器和裁判，从而定位智能体在哪个决策环节出现问题。独立的 Go AI Gateway 提供兼容 OpenAI 和 Anthropic 的代理接口，并支持虚拟密钥、分层预算、内联护栏及跨提供商回退。团队可以使用托管云服务，也可以通过本地服务器、Docker Compose、Kubernetes Helm 或云厂商 OnPrem 方案自行部署；另有混合式数据驻留模式。核心平台采用 Apache 2.0 开源核心模式，但部分企业模块需要商业许可证，SDK 则采用 MIT 许可证。
LangWatch 从集成到应用中的追踪接口或任何兼容 OpenTelemetry/OTLP 的库接收智能体和 LLM 运行数据。团队可将追踪转为 dataset，运行 offline evaluation，并在 Optimization Studio 中优化提示词或模型后重新测试。Scenario 功能针对包含工具、状态、用户模拟器和 judge 的完整智能体栈执行现实场景，输出可定位到具体决策的失败信息。平台还能审阅运行、标注失败、管理标注队列、通过 GitHub 集成将提示词保存在 Git 中，并把提示词版本关联到追踪。services/aigateway/ 中的独立 Go 网关以 OpenAI/Anthropic 兼容代理运行，管理虚拟密钥、分层预算、内联护栏、提供商自动回退和 Anthropic cache_control 透传。它还提供 LangWatch MCP，可供 Claude Desktop 等 MCP 客户端使用。
- 开发智能体的团队在发布前用完整场景模拟覆盖工具调用、状态变化、模拟用户和裁判，并检查具体失败决策。
- 维护生产 LLM 应用的工程团队通过 OpenTelemetry 追踪质量、性能和成本，并将线上问题转为回归评测数据集。
- 需要持续改进提示词的团队把 trace、dataset、offline evaluation、Optimization Studio 和复测串成闭环。
- 同时使用多个模型提供商的平台团队通过 AI Gateway 设置虚拟密钥、分层预算、内联护栏和自动回退。
- 有数据驻留要求的企业在自有基础设施上采用 Docker Compose、Kubernetes Helm、OnPrem 或混合部署。
- 需要领域专家参与质量审查的团队使用运行审阅、失败标注和标注队列记录边界案例。
这个 Agent 有哪些优点和局限？
- 将追踪、数据集、离线评测、提示词或模型优化及复测放在同一工作循环中，减少评测与可观测性工具之间的拼接。
- Scenario 能测试包含工具、状态、模拟用户和裁判的完整智能体栈，而不只检查单次模型回答。
- 以 OpenTelemetry/OTLP 为追踪基础，并明确支持多个框架和 OpenAI、Anthropic、Azure OpenAI、Vertex AI、Bedrock、Groq、Ollama 等提供商。
- 提供托管云、本地 CLI、Docker Compose、Kubernetes Helm、OnPrem 和混合数据驻留等多种部署边界。
- AI Gateway 提供虚拟密钥、分层预算、内联护栏和跨提供商自动回退等治理能力。
- 并非所有代码都采用 Apache 2.0：SSO、SCIM、审计日志、网关 webhook、计费和后台管理等 platform/app/ee/ 模块在生产使用时需要商业许可证。
- 本地 CLI 会在 ~/.langwatch/ 中安装并运行 Postgres、Redis、ClickHouse、网关及其他运行时，带来明显的磁盘、进程和运维负担。
- Langy worker 默认启用，并以当前用户身份在本机无沙箱运行；采用方需要评估这一执行边界。
- 可选的 Presidio 和 Lingua 评测器分别增加约 670MB 和 95MB 的语言模型，Langy 运行时约增加 45MB。
- 所给材料没有提供完整的 SDK 初始化、API key 环境变量名称或端到端代码示例，首次集成仍需查阅外部文档。
如何安装或部署这个 Agent？
最简本地安装要求 Node.js，在终端运行：
npx @langwatch/serverCLI 会把 uv、Postgres、Redis、ClickHouse、AI Gateway 二进制文件和 Langy 运行时安装到 ~/.langwatch/，生成带本地密钥的 ~/.langwatch/.env，并行启动服务，然后打开 http://localhost:5560。默认启用 LANGWATCH_ENABLE_LANGY=true；可按需设置 LANGWATCH_ENABLE_PRESIDIO 和 LANGWATCH_ENABLE_LINGUA。Docker Compose 路径为：
git clone https://github.com/langwatch/langwatch.git
cd platform/app
cp platform/app/.env.example platform/app/.env
docker compose up -d --wait --build服务启动后访问 http://localhost:5560。托管方式无需本地安装：在 https://app.langwatch.ai 创建免费账户和项目，然后复制项目 API key。Kubernetes 可通过文档所述 Helm 方案部署。
如何使用这个 Agent？
首次使用时，选择托管云或启动本地服务，在 Web 界面创建项目并取得 API key。随后根据应用语言和框架接入 LangWatch 追踪；平台原生列出了 LangChain、LangGraph、Vercel AI SDK、Mastra、CrewAI、Google ADK，并支持任何兼容 OpenTelemetry 的库。发送首批 traces 后，可从追踪构建 dataset，运行 offline evaluation，在 Optimization Studio 调整提示词或模型，再重复测试。测试智能体时创建 Scenario，让完整应用栈与用户模拟器及 judge 交互并检查各项决策。若需要集中治理模型访问，可把请求经 OpenAI/Anthropic 兼容的 AI Gateway 转发。README 没有给出可复制的 SDK 初始化代码、环境变量形式的 API key 配置或首个 API 调用示例，因此这些细节不能仅凭所给材料确定。
这个 Agent 与同类方案有什么区别？
与自行拼接追踪、数据集、评测和提示词优化工具相比，LangWatch 明确将这些环节整合为 trace → dataset → evaluate → optimize → re-test 的循环。它还以 OpenTelemetry 为基础，因此可接收兼容该标准的库所产生的追踪，而不局限于 README 列出的直接集成。