从 AI 火焰图分析到经验证的修复：用 OpenResty XRay 驱动 Coding Agent 性能优化闭环
内容提要
OpenResty XRay AI Assistant Skill 让 Claude Code 等 coding agent 接入 XRay 真实采样数据，补齐运行时视野。以 Checkout 边缘服务为例，经三轮重构（精简审计对象、消除重复 JSON 编码、去除风控重复扫描），吞吐量从 336 RPS 提升至近 30,000 RPS。业务决策仍由工程师把关，且需目标机器已部署 XRay Agent。
延伸解读
为什么 coding agent 需要运行时视野
Claude Code、Codex、Cursor 等 coding agent 擅长阅读和重构静态代码，但面对“优化性能”这类任务时，只能凭通用经验猜测热点，容易做出无关痛痒的微优化。在 vibe coding 场景下，大量代码由 AI 生成，重复序列化、重复扫描等性能反模式会在快速迭代中悄悄累积，功能正确、测试通过，性能却远低于应有水位。OpenResty XRay AI Assistant Skill 的作用，就是把真实运行时采样接入 agent 上下文，让热点定位有据可查，而不是停留在对源码的空泛猜测。
三轮重构的递进逻辑与数据对比
案例中三轮优化并非同时铺开，而是每次只验证一个假设。Stage 1 把审计对象改为 Allowlist DTO，吞吐从 336 RPS 升至 4,457 RPS；Stage 2 只保留一次 JSON 编码，升至 26,028 RPS；Stage 3 消除风控规则 12 倍重复扫描并复用正则编译结果，达到 29,968 RPS，p99 从 182.86 ms 降至 2.97 ms。这一过程说明：铲除主要瓶颈后，次要热点才会显现，优化顺序本身依赖采样数据而非主观猜测。
Lua 与 C 双视角避免误判瓶颈
Stage 2 后 Lua 火焰图显示风控调用链占比约 36.7%，但切换到 C on-CPU 分析器后，pcre2_match_8 仅占 3.1%，writev 却占 33.0%。文章特别提示：writev 主要是响应写出和网络传输层开销，不能因为它在 C 火焰图里很宽就去改业务代码。Lua 火焰图用于定位业务代码和调用链，C 火焰图用于确认 Native 层真实执行成本，两者结合才能避免把网络开销误判为业务瓶颈，也避免把 Lua 侧重复逻辑归咎于 PCRE。
使用边界与工程师把关点
这套工作流有明确前提和边界。目标机器必须已部署 OpenResty XRay Agent，否则 Skill 无数据可读；创建分析任务需工程师二次确认，agent 不会自行启动。审计字段能否删除、风险分值契约如何定义，属于业务决策，必须由工程师确认。本文仅实际验证了 lj-lua-on-cpu 和 lj-c-on-cpu 两个分析器，其他分析器是否可用取决于运行时、Agent 版本、权限等条件。短采样、目标离线或样本不足都会使报告无法支撑强结论，优化建议应回到原始报告核对。
Q&A
OpenResty XRay AI Assistant Skill 是什么？它和 OpenResty XRay 控制台里的 AI 助手有什么区别？
OpenResty XRay AI Assistant Skill 是 OpenResty XRay 的接入方式之一，让 Claude Code、Codex、Cursor 等 coding agent 通过 MCP 直接对接 OpenResty XRay，基于真实运行时采样完成火焰图分析并映射到源文件行号。它和控制台 AI 助手是同一能力的两个出口：控制台 AI 助手内置在网页中，适合看报告时直接提问；Skill 接入 coding agent，让分析数据和源代码出现在同一上下文里，适合完成“解读 → 改代码 → 回归验证”的完整循环。两者目前都处于 Beta 阶段。
使用 OpenResty XRay AI Assistant Skill 需要满足哪些前提条件？
目标机器上必须已经安装并运行 OpenResty XRay 的 Agent 守护进程，并且使用的 AI coding agent 支持 MCP 协议（如 Claude Code、Codex、Cursor）。Skill 本身不采集任何数据，它读取的是 OpenResty XRay 通过非侵入式动态追踪采集的运行时采样。目标应用无需修改代码、无需重启。如果没有 Agent 在后台采集数据，Skill 就没有任何数据可读，也无法创建分析任务。
AI 会不会未经授权就在我的机器上启动分析任务？
不会。创建分析任务属于会改变 OpenResty XRay 状态的操作，需要经过明确的确认门控。Skill 在提交任务前会返回确认请求，例如“Confirmation required before changing XRay state. Create a new jobs resource. choices: approve | reject”，只有工程师明确回复 approve 后，coding agent 才会继续提交任务；回复 reject 则拒绝当前操作。读取报告、对照代码和继续追问则可以在同一对话上下文中直接进行。
它和把火焰图截图贴给 ChatGPT 有什么区别？
通用聊天机器人只能看到粘贴的图片或文字，结论本质上是对代码的猜测。AI Assistant Skill 直接读取 OpenResty XRay 采集的采样级数据：实际进程、样本数量、源文件、行号和跨层调用链都在证据链里，结论可以回到原始报告逐条核对。它给出的仍是有证据支撑的推断而非绝对真理，业务决策仍由工程师把关。
演示案例中三轮优化分别做了什么？吞吐量提升了多少？
演示案例是一个 Checkout 边缘服务，三轮优化如下：Stage 1 将审计对象改为 Allowlist DTO，吞吐量从 336 RPS 提升到 4,457 RPS；Stage 2 同一份 DTO 只进行一次 JSON 编码，吞吐量提升到 26,028 RPS；Stage 3 风控规则单次执行并复用正则编译结果，吞吐量提升到 29,968 RPS。p99 延迟从 182.86 ms 降至 2.97 ms。
这套工作流有哪些边界和限制？
边界包括：业务决策由工程师把关，审计字段能否删、风险分值契约如何定义等需工程师确认；coding agent 给出的是有据可查的推论而非绝对真理，每项建议都应回到原始报告核对；高度依赖已部署 OpenResty XRay Agent 的环境；本文只验证了 lj-lua-on-cpu 和 lj-c-on-cpu 两个分析器，其他分析器是否可用取决于目标运行时、Agent 版本、操作系统依赖、权限等；coding agent 侧只验证了当前 Skill，不能替代对各客户端版本的逐一兼容性测试；短采样、目标离线、负载结束或样本不足都会使报告无法支撑强结论。
如何优化 vibe coding（AI 生成）代码的性能？
如果应用运行的机器上已经部署了 OpenResty XRay，就把生成这些代码的 coding agent 通过 AI Assistant Skill 接到 OpenResty XRay 的真实运行时采样上。AI 生成的代码常常功能正确、测试能过，跑起来却悄悄变慢——重复序列化、重复扫描这类反模式会在不知不觉中累积。让 agent 在开发阶段就读取真实火焰图数据，它就能在上线前拦住自己欠下的性能债。注意 Skill 不是独立工具：没有 OpenResty XRay Agent 在目标机器上采集数据，它就无从读取。
