Progress AI Observability

一句话定位

老牌软件公司 Progress 给生产环境 AI agent 做的可观测平台：追踪每一次模型调用、 工具调用和检索，把花费归因到 agent/工作流/模型，并在同一份轨迹上跑 LLM-as-a-judge 评估。

做这个东西的人

Progress（NASDAQ: PRGS），老牌基础设施与开发工具公司，以 .NET 生态工具知名。 产品由 PM Lyubomir Atanasov（Lyubo）带队，2026-08-07 在 发布平台 发布， 当日 164 赞、第 6 名。SDK 同时覆盖 .NET、Python、TypeScript/JavaScript—— 一个从第一天就押注企业 .NET 渠道的定位。

判断：大厂下场 agent 可观测，说明这个品类已经过了"是不是伪需求"的验证期。 Progress 的牌是 .NET/企业渠道，不是技术领先——市场上 LangSmith、Langfuse、 Helicone 已经在跑了。

它到底能做哪几件事

• 端到端追踪 → SDK 自动采集 OpenTelemetry traces，把一次多步运行拆成 模型调用、工具调用、检索、自定义操作的 span 树，能回答"这个工作流是不是 跳过了某个工具、把烂的检索上下文喂给了模型、重试循环烧了多少钱"
• 成本归因 → 按 agent、工作流、模型、provider 聚合预估花费，找出贵的环节
• LLM-as-a-judge 评估 → 对已捕获的轨迹跑评估任务，出结论、打分和解释； 历史与实时都支持，评估结果和产生它的执行路径绑定在一起
• 质量评分卡 → 把"看起来成功其实错了"的运行识别出来——传统日志最容易漏这一类
• 架构三层 → 轻量 SDK（Python/.NET/TS）→ 专用 collector（验证 key、补成本计算 和用户归因、存储）→ 网页 dashboard

它在替代什么旧行为

以前看 agent 有没有出问题，靠的是普通 APM/日志：能告诉你服务活着、延迟多少、 有没有报错，但说不清"agent 为什么选了那个工具、为什么卡在昂贵的循环里、 为什么答得一本正经却是幻觉"。团队排查只能人肉翻对话记录。 Progress 替代的是"APM 看得到宕机、看不到答错"这个盲区——把执行轨迹、 花费和输出质量放进同一个视图。

商业模式

SaaS 订阅，按"单位"计量。 免费档 10,000 units、7 天留存；Starter $29/月 （200,000 units、30 天）；Pro $299/月（1M units、60 天）；Enterprise $3,000/月起、 定制量。超出部分 $8/100,000 units。一个 span 算 1 unit，一次评估算 2 units—— 意味着一个重度埋点的多步 agent，每次用户请求可能吃掉好几个 unit。

判断：按 unit 定价是精明的——评估比追踪贵一倍，逼着用户在"采样"上做功课， 同时给平台留了涨价空间。但计费口径复杂，中小企业容易踩坑。

硬数字

• PH 2026-08-07 发布：164 赞、15 评论，当日第 6 名
• 定价：免费 / $29 / $299 / $3,000+/月 四档，实际可查
• SDK：.NET、Python、TypeScript/JS；集成列表含 Semantic Kernel、LangChain、 LlamaIndex、AutoGen、Microsoft Agent Framework、OpenAI、Azure OpenAI、Anthropic
• 第三方包索引观察到 progress-observability 的 Python 发行包依赖 Traceloop SDK， 与老牌可观测厂商的收购/合作迹象，未核实
• 用户规模：未披露；Reddit 上已有客户称"接近功能对齐"，但明确提出"有人实测过吗"

四维评估

判断

值得关注，但这是"老牌厂商的追赶型产品"模板。 它功能齐全、定价真实、 渠道明确（.NET 企业客户），这种打法在传统软件里每次都能成立。 但它没有展示出任何 agent 时代的独门认知——所有能力在 LangSmith 和 Langfuse 那里都有对应的。它的差异化只剩两条：Progress 的品牌信任和 .NET 生态的 深度绑定，这两条在纯 AI 创业公司里都不存在。

真正的悬念是渠道能不能转化。 Progress 有现成的企业销售管道， 如果 .NET/Azure 技术栈的团队开始批量引入，这个产品能在不靠创新赢的情况下 靠渠道吃下一块市场。这是值得跟踪的"渠道型竞争"样本。

下一步看什么

① Reddit 上"有人实测过吗"的质疑是否被真实客户案例替代——有没有企业公开背书 ② .NET/Azure 渠道客户是否开始出现——这是它区别于创业公司的唯一优势 ③ unit 计费是否被用户吐槽复杂/昂贵——计费口径决定了它能不能在中小企业铺开

可借鉴的做法

产品逻辑：如果你做质量评估类功能，参考"评估必须和产生它的执行路径绑定"—— 脱离轨迹的评分是摆设，用户无法判断分数可信。另一个可抄点：把"花费归因" 做成一级功能，因为成本是用户最容易感知的痛点，比"质量"更愿意付钱。

定价结构：按 span/评估计量的 unit 定价，评估定价是追踪的两倍——这鼓励用户 学会采样，同时给平台留了自然涨价空间。做按量付费可以参考这个计费口径。

结论

值得关注。 产品本身没有惊艳的创新，但渠道型打法值得观察——老牌公司 能不能用现有销售管道在 agent 可观测市场切一块。三个月后看渠道转化和 真实客户背书。