技术深度解析
Rigor的架构是对一个微妙问题的精妙回应：基于LLM的智能体受限于上下文窗口长度、缺乏会话外的持久记忆，且没有内在机制来保障长期项目一致性。其输出可能随着即时提示（可能与早期架构决策或既定模式冲突）生成代码而逐渐“腐化”。
系统运行在提取、表征、评判、修正的持续循环中。提取阶段涉及解析整个代码库、提交历史、文档及潜在设计文件（如ADR——架构决策记录）。这些原始数据输入至表征阶段，Rigor在此构建其标志性的“认知图谱”。这并非简单的知识库，而是一个语义网络：节点代表实体（如`UserService`、`PostgreSQLAdapter`、`auth middleware`），边代表关系（`depends_on`、`implements`、`violates_pattern`、`rationale_for`）。图谱的构建与更新结合了静态代码分析、语义相似性嵌入以及LLM驱动的摘要与关系推断。
评判阶段由一个独立的LLM（可以是不同模型或专门微调的实例）执行，负责评估新的代码建议。评判者会接收到来自认知图谱的相关子图（例如“这是我们服务层的架构以及我们用于数据访问的三种设计模式”）以及主智能体提议的代码变更。评判者的任务是从架构对齐度、命名规范一致性、安全模式遵循度、与现有系统逻辑连贯性等维度为提案打分。关键在于，评判者的“知识”锚定于图谱，而非其自身的参数化记忆。
若评判者标记出问题，系统进入修正阶段，可能涉及生成替代建议、向开发者提供上下文警告，或对简单的风格违规触发基于规则的自动修正。
此领域一个关键GitHub仓库（虽非Rigor本身）是`graphrag`（基于图谱的检索增强生成），这是一个微软研究项目，展示了如何从非结构化数据构建和查询知识图谱以供LLM使用。该项目已获超3.2k星标，为Rigor这类项目可能利用的“表征”阶段提供了基础工具包。另一个相关仓库是`crewai`，一个用于编排角色扮演AI智能体的框架，它阐释了“主智能体 vs. 评判者”的多智能体模式。
| 组件 | 技术栈（示例） | 主要功能 |
|---|---|---|
| 图谱构建器 | LangChain/ LlamaIndex, NetworkX, CodeQL, Sentence Transformers | 从代码/文档中提取实体与关系以构建语义图谱 |
| 图谱存储 | Neo4j, Weaviate, LanceDB | 持久化存储认知图谱并支持高效查询 |
| 主智能体 | GPT-4, Claude 3.5 Sonnet, DeepSeek-Coder | 作为“工作者”智能体生成代码建议 |
| 评判智能体 | 另一LLM（如为成本考虑选用Claude 3 Haiku）或微调模型 | 对照图谱评估建议的一致性与质量 |
| 编排器 | 自定义Python/TypeScript服务 | 管理所有组件间的工作流 |
核心洞见： 该架构揭示了一种朝向异构、多模型AI系统的趋势。可靠性并非通过单一庞然大模型实现，而是通过一个由专用组件（图谱数据库、不同LLM）处理特定子任务（记忆、判断）的管道达成，从而超越了任何单一模型的上下文窗口限制或推理偏差。
关键参与者与案例研究
Rigor的兴起标志着AI编码助手市场的成熟化，该市场目前由注重能力的参与者主导。GitHub Copilot凭借其巨大采用率，主要在无状态、提示响应的模式下运行。Cursor和Windsurf推进了IDE与智能体的集成，但仍将会话视为相对孤立的。Claude Code（Anthropic）和OpenCode（假设性/代表性）等专用智能体虽推动了编码专用推理的边界，但并未从根本上解决长期知识一致性问题。
Rigor的方法在概念上与Sourcegraph等公司的努力方向一致（该公司长期倡导代码智能图谱），也与Amazon CodeWhisperer（其提供的安全扫描可视为一种事后评判形式）相契合。然而，Rigor将图谱与评判集成到*实时建议循环*中，这标志着一个显著的进步。
一个引人注目的案例研究是其在大规模金融科技或受监管的健康科技开发中的潜在应用。一个使用Claude Code构建支付处理系统长达18个月的团队，可能会面临微妙的“漂移”问题：后期生成的代码逐渐偏离早期确立的安全协议或审计跟踪要求，而传统工具难以捕捉这种渐进式偏差。Rigor的认知图谱可以编码诸如“所有交易日志必须遵循ISO-8583字段映射”等约束，其评判智能体则能在每次代码生成时执行合规性检查，从而将一致性维护从人工审查转变为自动化、持续的过程。