我大概是第一个把 AI Agent 和 Warframe / 星际战甲紫卡分析结合起来的人。

一周多前，我开源了 Riven Analyst。它不是一个传统的紫卡查询网站，也不是在数据库外面简单套上一层聊天界面，而是一组运行在 Claude Code、Codex 等通用 Agent 中的领域知识、工作流和 MCP 工具。

玩家只需要提供一张紫卡截图，Agent 就会识别卡面、查询武器数据与本地领域知识，并根据需求决定是否检索参考配卡、调用计算工具，最后给出一份可以继续追问、质疑和修正的分析报告。

• 项目仓库：ruali-dev/Riven-Analyst
• 演示视频：

项目发布后，我没有立刻写复盘，而是先把它挂到B站上公开一段时间，看看问题会在哪里暴露。本来计划收集一周反馈后动笔，中间却去了一趟上海旅行，直到昨天回家，今天才真正坐下来写下这篇文章。

这既是一份技术记录，也是一篇带有个人观点的杂谈：我为什么没有再做第二个极境，为什么选择让 Riven Analyst“寄生”在通用 Agent 上，以及在开发过程中，我如何重新理解用户体验、Harness、领域知识和所谓的“从 0 到 1”。

技术细节

Riven Analyst 本身是一组面向通用 Coding Agent 的领域知识、工作流和 MCP 工具。通俗易懂地说，就是一个 Claude Code 类 Agent 的插件。用户提供一张紫卡截图后，Agent 会调用视觉模型识别卡片信息，查询武器数据和本地领域知识，根据任务复杂度决定是否进入完整配卡分析，最后生成紫卡评价和操作建议。

工作流程

完整流程的书面叙述较长，读者若不感兴趣可跳过本节细节；核心只有一句：Agent 会按既定流程查询领域知识，再给出分析。

整个分析可以拆成两个阶段：默认的快速价值判断，以及玩家明确要求后的配卡深化。下面以一次完整的分析为例，按实际执行顺序说明。

1 输入与识别

玩家将紫卡截图放入项目目录，提出分析需求。Agent 先确认当前日期与游戏版本，随后调用视觉 MCP（parse_riven_image）读取卡面。视觉模型按内置指令模板保守地报告可见字段：武器名、词条、数值、段位与洗炼次数。若首轮识别存在不确定的词条，工具会自动进行二次复查。此阶段只产出“看到了什么”的结构化观察信息。

2 标准化与歧义消解

识别结果随后进入标准化环节。中文玩家习惯使用简称与旧译名，视觉识别也会引入符号误读、数值位数偏差，这些差异在此层统一处理：词条名称映射到注册表的标准 ID，武器名经审核过的别名表解析为具体家族。若该家族存在多个变体而截图未指明版本，Agent 不会擅自推断，而是先输出按变体区分的条件性结论；仅当结论会在不同变体之间反转、且无法用条件表述时，才向玩家询问持有哪个变体。以布莱顿家族为例，其下就有圣装（国际服称 Prime）、破坏者、亡魂、MK1 与普通版等多个变体。识别出的数值还会与词条理论范围（倾向 × 公式）核对……超出区间的读数会被标记，提示玩家确认。

3 依据查询

判断需要依据。Agent 依次查询本地库：从 WFCD 派生的武器原始面板与机制标签、审核过的武器事实、MOD 满级效果，以及一份已审核的领域知识索引。默认阶段不发起任何联网请求；仅当本地资料未覆盖新武器或版本变化，且玩家明确要求配卡分析时，才按预算（至多三次检索、六次页面读取）进行有限联网。

4 快速价值判断

依据齐备后，Agent 对“直接使用 / 继续洗炼 / 暂缓”给出结论，并说明每条属性对这把武器的实际意义、负面是否可接受，以及下次洗炼值得追求的方向。此阶段刻意不做两件事：不给出完整八槽配卡，不指名要替换哪张 MOD——避免在未计算、未查证的情况下给出超出证据的结论。

5 配卡深化（条件触发）
玩家明确要求完整配卡、替换分析或具体 DPS 数据时，分析才进入第二阶段。流程固定为：先检索当前可检视的社区参考配卡（以中文社区来源优先，参考必须标注来源、作者与版本），再以最少的同条件计算次数调用计算 MCP（calculate_build），比较替换紫卡前后在伤害、射速、弹匣循环等指标上的变化，最后输出八槽配卡表与紫卡替换位置说明。若预算内未找到可检视的参考，或某张 MOD 无法确认为具体名称，则如实说明缺口并省略对应部分，绝不以模型自拟的配卡冒充社区配卡。此阶段的报告在输出前还需经过审核子 Agent 的检查，证据不一致的草稿会被拦截。

6 报告输出
最终报告按结论、原因、提升方向、操作建议的顺序组织，并明确说明依据来源、假设条件与分析限制——例如该武器缺乏本地精确数据、近战计算尚未覆盖等。整份报告使用玩家语言，不暴露工具名称、内部 ID 或审计日志；识别出的数值若与常识不符，也会在报告中直接指出。

视觉 MCP 设计

视觉 MCP 我不打算采用传统的 OCR，因为传统的 OCR 方案在这里并不划算：紫卡截图不是规则表格，玩家可能用 QQ 截图随手截下，大小和位置都不统一，武器名、极性、段位、属性与数值散落在不同区域。即便 OCR 本身稳定，中英文名称、游戏字体与背景特效仍会影响识别，而识别结果最终还需要与武器数据库对齐。

我想要的是，随便截一张“正常”的紫卡截图，然后就能给 Agent 用的体验，结合上述的毛病，与其维护一套复杂的 OCR 管线，不如直接使用多模态模型——如今的多模态模型已足够强大，发一张图片远比调 PaddleOCR 可靠；API 配置方面我也做了用户友好的设计，具体可以看后面章节。

按 API 计费的模式对商业产品而言成本过高，要求用户自行寻找并配置视觉模型 API 更是闻所未闻——不过这个项目本来就没打算做成 SaaS。

而且我没有把视觉识别当成最终答案，而是把它当成 Agent 获取输入信息的第一步。截图中的文字可以被模型识别，但武器是否存在、属性是否合法、名称如何标准化，仍然需要由后续数据和领域知识确认。

计算 MCP

早期开发的过程中，GPT-Sol 的思路是比较传统的那种一张张卡拼上去，有点像极境的体验。但是我看到后觉得不行，首先是不可拓展，现在早就不是几年前那种纯 MOD 版本了，现在的版本赋能非常强大，侵染之类的赋能直接以一己之力开创了一个流派，传统一张张卡拼上去，后面怎么扩展到赋能、宠物，还需要维护一张庞大的 MOD/赋能/宠物数据库，过于庞大。极境都停更很久了，可能维护确实费时费力。

我的思路是参考现在很多玩家用 Excel 拉表计算伤害的思路，这样天然就跳脱出了老思路的局限性，通过建立一张可检查的配卡表，让 Agent 像用户操作 Excel 一样填入武器、MOD 和紫卡属性，再比较不同配置之间的结果。模型负责决定“应该比较什么”，计算工具负责给出“比较结果是多少”。赋能作为新加成来源，已经通过同一套规则接入；宠物加成、战甲加成等后续来源也可以沿这条路径扩展，而不需要为每个新机制重写一套拼卡逻辑。当然，我并没有专门实现一个 Excel 或者调用系统的 Excel，只是计算过程是在模仿这个流程。

从用户出发

完成分析流程只是第一步。如果安装插件本身比分析一张紫卡还麻烦，那么再完整的架构也没有意义。

以前看电影，关于计算机，都是直接在键盘上噼里啪啦敲几个字，然后按下回车键，屏幕上的终端就开始闪烁滚动一长串东西，然后事情就解决了。你笑导演不懂技术，导演笑你不懂未来。

HTML 配置视觉 MCP API Key

虽然对开发者来说把 API Key 填入环境变量或者 JSON 配置文件可能只是几十秒的事情，但是我觉得麻烦。对普通玩家来说，他可能根本不知道配置文件在哪里，也不知道引号、路径和转义字符为什么会导致程序启动失败。

所以我为视觉 MCP 增加了一个 HTML 配置页面。用户不需要打开代码编辑器，只需要在本地的浏览器网页中填写 API Key，页面就会自动生成配置。如果一个面向玩家的插件，第一步就要求用户手动寻找配置文件并填写 API Key，那么它在真正开始分析紫卡之前，就已经先考验了一遍用户的开发环境知识。这在我看来多少有点蠢。

设计了一套按 Agent 一键安装的引导流程

我希望的体验就是，打开 Claude Code，看到这个插件有意思，直接把 GitHub 链接甩给 Claude Code，“给自己装个这个插件”，然后事情解决了。为此，我设计了一套按 Agent 一键安装的引导流程，README 的原文就是

## 快速开始
### 让 Agent 安装
把下面这段话发给 Claude Code：

请帮我安装这个仓库：
https://github.com/ruali-dev/Riven-Analyst

请按照 docs/INSTALL.md 完成安装。需要配置视觉模型时，打开插件里的 mcp-server/vision-config.html 让我填写；保存后重启 Claude Code 会话，确认插件可以使用后告诉我。

Agent 会完成仓库注册、插件安装和一次性权限配置。详细安装步骤放在 [docs/INSTALL.md](https://github.com/ruali-dev/Riven-Analyst/blob/main/docs/INSTALL.md)，marketplace 与 JSON 配置也由 Agent 管理。

如果你用的不是 Claude Code 而是 WorkBuddy 或者 Trae 这种本土商业 Agent，我想应该也是能适配的，这套安装方式并不严格绑定 Claude Code。配置视觉 API 并重启会话以外的步骤，都可以由具备文件操作和命令执行能力的 Agent 完成；MCP 与 Skill 才是真正跨宿主的能力载体。

我想降低的是没有意义的操作门槛，而不是抹掉这种工具本身的形态。用户不应该因为不会编辑 JSON 而被挡在外面，但他至少要愿意接触 Claude Code、Codex 这类通用 Agent。Riven Analyst 并不追求成为一个面向所有玩家的网页服务，它首先服务的，就是愿意尝试新工具范式的那部分人。

从 0 到 1

Riven Analyst 最初并不是从某种宏大的 Agent 产品构想开始的。尽管它现在看起来是一个非常典型的垂直专业领域 Agent 知识问答项目。我只是觉得，每次拿到一张紫卡以后，再去查武器、翻配卡、拉表比较、问其他玩家，实在太麻烦了。如果大模型已经能够读懂截图、调用工具、查找资料并生成解释，那么这些重复过程理论上都可以交给它。

现有的紫卡工具已经很好地解决了价格、倾向、武器数据和基础计算问题。如果我继续沿着相同方向开发，最后大概率只是做出第二个极境（riven im）：界面可能不同，技术栈可能更新，但它所解决的问题没有变化。

紫卡分析很难被完全压缩成一个固定公式。相同词条放在不同武器、不同流派甚至不同玩家手里，结论都可能不同。传统工具可以告诉用户数值和倾向，却很难进一步解释：为什么这条负面在某把武器上反而有价值、这张卡应该替换哪张 MOD、当前配卡是否真的能吃到它的收益。

大模型第一次让这种开放式、上下文相关的判断具备了被软件化的可能。

在数据层面，我没有重复整理 WFCD 已经提供的武器基础数据；在知识层面，我把紫卡词条、武器机制和常见流派逐渐沉淀到本地知识库中；社区搜索则主要用于补充当前版本中的参考配卡和特殊玩法。数据负责提供事实，模型与工具负责结合具体上下文形成判断。

这个紫卡助手，我没有做独立前端或者专用聊天机器人，不是因为懒得做，而是一项架构选择。

我不认为每一个 Agent 应用都需要从聊天界面、上下文管理和工具循环重新做起。Claude Code、Codex 这类通用 Agent 已经具备了相当完整的本体能力，直接让 Riven Analyst “寄生”在现成的通用 Claude Code 类 Agent 上，只需要补充 Warframe 紫卡分析需要的知识、工具和流程，直接沿用现在成熟的 Skill、MCP、Workflow 范式就可以了。

“寄生”在 Claude Code 上，看起来像是把产品做成了程序员插件，但 Claude Code 与 Android Studio 这类专用开发工具并不是同一种东西。它更接近一个能够读取文件、调用工具、搜索资料并执行工作流的通用计算机 Agent。用户是否写代码，并不决定他能否利用这些能力。

而且，现在愿意配置并使用通用 Agent 的玩家，本身就更可能对这种新范式具有包容度。这构成了一次自然的用户筛选：Riven Analyst 不需要从一开始就服务所有 Warframe 玩家，只需要先服务那些既有紫卡分析需求，又愿意尝试 Claude Code、Codex 等通用 Agent 的人。

Warframe 紫卡分析本身已经是一个足够细分的领域，而“通用 Agent＋本地领域知识＋计算工具”又是一个新的交叉点。在这个交叉点上，我几乎找不到真正意义上的同类产品，也没有必要再和传统紫卡工具挤在同一条赛道上竞争。

传统紫卡计算工具的核心用户，往往本身就拥有足够的游戏理解，愿意花时间拉表、计算、极化并反复测试。他们能够从大量武器数据、词条和评分中自行得出结论。对于普通玩家而言，这些工具虽然展示了数据，却仍然要求用户理解应该怎样解释数据、怎样把它们放回具体武器和流派中。

如果只是在这个基础上继续增加更多字段、搜集更多数据，再通过固定公式给出评分，本质上仍然是新瓶装旧酒。它与传统专家系统相似：开发者预先整理规则和答案，用户输入条件，再由系统返回一个已经被设计好的结果。

Agent 的意义，是把原本藏在老玩家经验里的判断过程也显式化。它不仅展示数据，还需要解释这些数据为什么重要、当前结论建立在什么假设上，以及玩家下一步应该怎么做。

传统工具的一次查询，通常到结果页面就结束了。它可以显示这张卡的倾向、价格、属性评分和理论增益，但用户很难继续问：你为什么认为这个负面可以接受？如果我走的是触发流呢？这张卡会换掉我当前配卡里的哪一张 MOD？如果我没有某个赋能，结论会不会改变？

Agent 的分析不是一个终点。玩家可以质疑它的假设、补充自己的流派、要求它更换参考配卡，或者让它针对某个争议点重新计算。报告因此不再是一张静态结果页，而是一次可以继续推进的分析过程。

在我看来，这才是大模型相对于传统数据库和专家系统的根本变化。它并不只是从数据库里取出更多字段，而是能够围绕用户不断补充的上下文，重新组织知识、调用工具并修改结论。

这也反过来验证了前面的架构选择，既然核心能力来自持续的上下文、工具调用和追问，那么重新制作一个只能完成单轮问答的专用聊天机器人，反而是在把现成 Agent 的能力重新阉割一遍。

至少在紫卡分析这种高度依赖上下文、又无法完全公式化的问题上，我认为“大模型泛化能力＋本地知识库＋工具调用”的新范式，对“硬编码数据＋固定查表”的旧范式就是一种降维打击。后者只能预先回答开发者设想过的问题，前者则可以继续处理用户临时补充的条件，甚至围绕结论展开追问和反驳。

这次开发也让我重新思考了所谓的“从 0 到 1”。

从 0 到 1 并不一定是凭空构想一个前所未有的宏大产品，也不是给旧工具换一套技术栈，或者在传统紫卡计算器旁边接上一个聊天框。它更可能始于看清现有工具已经解决了什么、又被旧技术限制在了哪里，然后利用一种真正新增的能力，重新定义这个工具原本可以是什么。

Riven Analyst 最初只是为了省去几次查表、计算和询问，最后却变成了一个可以识别截图、调用知识、执行计算，并与玩家持续讨论结论的领域 Agent。对我而言，这才是这个项目真正有意思的地方。

了解现有的瓶颈，不甘于现状，从 0 到 1。

Harness

当一个工具开始依赖模型理解截图、调用数据、选择计算方式并形成开放式判断时，新的问题也随之出现：究竟应该给予模型多少自由，又应该用多少规则约束它？

不久前刷到一个伯克利教授谈 Harness 和 ontology，Why Agentic Systems Need Ontologies — Frank Coyle, UC Berkeley，他的想法很美好，将 Claude 的工具调用循环包裹上一层验证器：当模型提议调用工具时，先用 Pydantic 校验输入类型，再用本体校验输出结果，通过后才真正执行。那些用自然语言写起来费劲又易错的规则，由此浓缩为几行清晰逻辑。

但是实际上，在紫卡分析这种长上下文、复杂语义任务中，不能指望模型始终严格输出完全符合语法验证的结构。

在开发 Riven Analyst 的早期版本时，GPT-Sol 和他的想法不谋而合，但实际使用 DeepSeek V4 接入 Claude Code 测试时，只要上下文变长、分析步骤变多，模型就会偶尔调整结构、遗漏字段或用自然语言替代规定格式。验证器能够发现问题，却不能自动完成分析；如果因为少一个字段就让整次长流程失败，系统反而变得更脆弱。我怀疑要获得严格的格式对应，得增加额外的模型微调或者 RL 后训练。

因此，我最终选择对流程进行约束，而不是对每一句输出进行约束。工具调用、数据查询和计算过程尽可能结构化；最终报告则只规定必须覆盖的内容和大体顺序，允许模型根据具体情况组织语言。相当于对模型报告的约束只是一种“大体、松散性”的约束，让大模型负责的部分也只是“它独特能力”所擅长的部分。

当前的 Riven Analyst 更接近一套工作流、本地知识库与隐式领域模型的组合。部分知识已经结构化为数据和工具接口，部分规则仍然以 Markdown 指令存在，最终由模型理解和执行。因此它还不是严格意义上的 ontology-driven system，但已经具备了某种半结构化领域本体的雏形。

至于严格语法校验在这类长上下文场景中是否始终成立，以及现有 API 模型的指令遵循能力能否达到足够稳定的水平，我仍然持怀疑态度。

但这并不意味着验证器、本体或者结构化约束没有价值。我的结论只是：约束必须放在合适的层级。

工具参数、数据结构、武器标识和计算过程应当尽可能严格，因为这些部分有明确的正确与错误；流派判断、价值解释和最终报告则需要保留一定弹性，因为它们天然依赖上下文、不完整信息和玩家的实际需求。

真正可靠的 Agent 系统，既不是把模型压进一套试图覆盖所有语义的 Schema，也不是把一切交给模型自由发挥。更合理的分工，是把确定性留给代码、数据和工具，把开放式判断留给模型，再用工作流把两者连接起来。

这也是我目前对 Harness 最直接的理解：它不应该替代模型的智能，而应该规定模型在什么边界内使用自己的智能。

后记

当前版本当然谈不上完整。我一个人整理领域知识，遗漏几乎不可避免。发布时，我也没有追求把每个角落都打磨到完美，而是先把核心流程跑通，把最重要的边界补上，然后尽早交给真实用户检验。

永远等待 perfect，本身也不算 perfect。

最初决定开源时，我就希望社区里的其他玩家能够补充领域知识、提交 Issue，或者直接发起 PR，把这个工具继续迭代下去。理想状态当然是大家一起完善它，最后我什么都不做，也能躺着用上一个更好的紫卡助手。

Riven Analyst 大约起源于七月中旬的一个想法，之后集中开发和迭代了一周多，主要借助了 GPT-Sol 和 Kimi K3。但整个开发过程也再次证明：即使到了 AI 时代，AI 依然只是一个放大器。

它可以放大开发效率、整理能力和实现速度，却不会凭空补齐开发者不存在的领域理解。开发期间，钓鱼竿曾经被错判为绝路，守望者 Prime 与普通守望者的弹匣容量也曾被混淆。这些问题如果没有真正玩过 Warframe、接触过具体武器和流派，可能很难在第一时间察觉。

缺少领域知识时，AI 并不会自动带来正确答案。很多时候，它只是更快地把一个错误实现出来，并且让这个错误看起来更加合理。

至于接下来的计划，我暂时不会继续高强度地堆功能。评论区和真实使用中暴露的问题会慢慢整理，本地知识库与计算边界也会逐步补充。这个项目已经完成了它最重要的一步：从一个让我自己省事的想法，变成了一个真正被发布、使用和讨论的工具。

剩下的，让它在真实用户和社区反馈中继续生长。至于我自己，短时间内大概真的不想再碰紫卡助手了。