LintLang
在 Agent 运行之前，用本地确定性静态检查拦下含糊的工具描述、缺失的停止条件和 schema 缺口。
- Star 数
- ★ 125
- 最近更新
- 今天
- License
- Apache-2.0
- 主语言
- Python
- FA 评分
- 67/100 · 存在缺口
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台Claude CodeCodex（部分支持）
- 费用
- 免费，无需付费服务
- 上手难度
- 低 · 几分钟可跑通
- 开始前需要
- 典型场景
- 维护 MCP 服务器或函数调用工具集的团队，想在上线前确认多个同级工具的描述不会让模型无从选择。
- 不适合
- 希望用大模型自动修复提示词、而不接受确定性静态检查的团队
- 想验证 Agent 在运行时是否真的选对工具的团队
- 需要跨文件合并工具选择空间做全局冲突检测的团队
- 源码审查
- 67/100 · 存在缺口
这个 Agent 能做什么，适合哪些场景？
LintLang 是 Hermes Labs 开发的本地确定性静态检查工具，专门针对喂给 AI Agent 的指令和工具接口。它直接扫描你已有的项目目录，从 JSON/YAML 中嵌套的 MCP 与函数工具定义、参数 schema、系统提示、messages、输出约定，以及 AGENTS.md、CLAUDE.md、GEMINI.md、SKILL.md 和部分 Python 提示代码中提取面向 Agent 的内容。检查完全基于静态规则、不调用任何模型，因此结果可复现、可放进 CI。它能发现同类工具描述互相重叠、重试或循环缺少边界、schema 缺必填字段、一个提示里出现多种输出格式、长指令列表没有优先级、SKILL.md 元数据缺失或技能名与目录不符等问题。每条结果都会说明自己检查了什么，没有识别到 Agent 相关结构的内容会被标为 SKIPPED 而不是 PASS。输出支持文本、JSON、SARIF 与 GitLab Code Quality，便于接入流水线。
运行 lintlang scan <目录或文件> 时，工具会递归遍历目标路径，识别并解析支持的 Agent 配置载体：JSON/YAML 中的 MCP 与函数工具定义、参数 schema、系统提示与 messages、输出契约、AGENTS.md / CLAUDE.md / GEMINI.md / SKILL.md，以及受支持的 Python 提示代码。解析后它会执行一组确定性检查：H1.x 系列比较同一个已解析输入内的同级工具，找出职责重叠、缺少区分依据的工具；H5 检测长指令列表缺少优先级；H6 检测一个提示中出现两种以上被识别的输出格式（即使各自限定在某个分支）；同时检查重试、循环、工具调用是否缺少显式停止或进度条件，schema 是否缺必填字段、参数含义不清，SKILL.md 元数据是否缺失或非法、技能名是否与目录一致，上下文与消息是否存在过期引用、无界持久化、角色格式错误、工具消息序列断裂，以及受支持 Python 提示中的字面工具定义与流水线阈值。每条结果都标注实际检查的对象；未识别到 Agent 结构的内容标记为 SKIPPED。CLI 支持 --fail-on fail（仅 HIGH/CRITICAL 阻断）与 --fail-on review（把 MEDIUM 纳入门槛），--write-baseline 可把当前结果写为基线，之后用 --baseline 只对新增或变更的发现设卡；lintlang init --github --path . 生成固定版本的 GitHub Actions 工作流，默认阻断 HIGH/CRITICAL。输出格式包括文本、JSON、SARIF 和 GitLab Code Quality。
- 维护 MCP 服务器或函数调用工具集的团队，想在上线前确认多个同级工具的描述不会让模型无从选择。
- 把 Agent 配置、提示词和 skill 明文的仓库接进 GitHub Actions，需要在 PR 阶段就阻断高风险配置缺陷的工程团队。
- 已经在用 Claude Code、Cursor、Gemini CLI 等工具，希望把 lintlang scan 放进 pre-commit 本地钩子做提交前自检的开发者。
- 为 CLAUDE.md、SKILL.md、AGENTS.md 做评审的人，需要一份确定性清单来核对元数据、使用条件和命名规范。
- 已经积累大量历史告警的项目，希望用 .lintlang-baseline.json 冻结旧问题、只对新引入的发现设门槛。
- 需要把检查结果接入 GitHub Code Scanning 或 GitLab Code Quality 面板、用 SARIF 统一展示的安全与平台工程师。
如何安装或部署这个 Agent？
需要 Python 3.10 及以上版本。如果只想跑一次而不安装：
uvx lintlang scan .用 pip 安装到环境里：
pip install lintlang
lintlang scan .macOS 上也可以用 Homebrew：
brew install hermes-labs-ai/tap/lintlang
lintlang scan .如何使用这个 Agent？
可以直接指定某个配置来源，而不是整个目录：
uvx lintlang scan AGENTS.md
uvx lintlang scan SKILL.md
uvx lintlang scan agent.yaml默认发现只作提示；要阻断 HIGH 或 CRITICAL 级别的问题：
lintlang scan . --fail-on fail把 MEDIUM 也纳入门槛：
lintlang scan . --fail-on review生成固定版本的 GitHub Actions 工作流：
lintlang init --github --path .如果仓库已有历史问题，先写一份基线，再只对新增或变更的发现设卡：
lintlang scan . --write-baseline .lintlang-baseline.jsonlintlang scan . \
--baseline .lintlang-baseline.json \
--fail-on review这个 Agent 有哪些优点和局限？
- 完全本地、零 LLM 的确定性检查：不调用模型、不需要 API key、结果可复现，扫描不会把代码或提示内容发送到外部服务。
- 覆盖面针对 Agent 配置本身——同级工具混淆、停止条件缺失、schema 缺口、输出格式混杂、SKILL.md 元数据错误，这些是通用 YAML/JSON linter 不会检查的。
- 报告语义诚实：没有识别到 Agent 结构的内容标为 SKIPPED 而非 PASS，每条结果都说明检查对象，不会给出虚假的通过结论。
- 原生支持 SARIF、JSON 和 GitLab Code Quality，可直接接入 GitHub Code Scanning、GitLab CI 或 MegaLinter，基线机制让历史项目可以渐进式收口。
- 安装路径轻量：uvx 免安装即可试跑，也支持 pip 与 Homebrew，CLI 之外还提供 Claude Code、Cursor、Copilot CLI、Gemini CLI 等集成说明。
- 不做语义矛盾检测：项目明确说明它不会发现“总是做 X”与“永远不要做 X”这类相互冲突的指令，H5/H6 只覆盖优先级缺失和输出格式数量。
- 不验证运行时行为：它不运行模型、不观察实际的工具选择，一次干净扫描只代表所选静态检查在已识别内容里没发现问题，不能等同于 Agent 生产可用。
- 工具比较限定在单个已解析输入内，一次目录扫描不会把不同文件中的工具合并到同一个选择空间，跨文件冲突需要自行拆分扫描或另行处理。
- 能力边界依赖识别规则：只有被支持的结构才会被检查，未识别的文件会被跳过而不报错，配置写法超出支持范围时可能得到“看起来很干净”的结果。
- 需要 Python 3.10+ 运行时；文档只覆盖 macOS 的 Homebrew 路径，Linux/Windows 的原生安装需自行使用 pip 或 uvx。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| LintLang 当前 | 67 · 存在缺口 | 命令行工具免费 | ★ 125 | 今天 | Python | Claude Code |
| AgentSys | 52 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 990 | 1 天前 | JavaScript | Codex · Claude Code |
| Argot 仓库风格审查器 | 93 · 表现优秀 | 命令行工具免费 | ★ 50 | 27 天前 | Rust | Claude Code |
| Jev Review | 81 · 表现良好 | Agent 插件 / 技能免费 + 模型费 | ★ 224 | 12 天前 | TypeScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示该工具是本地、零 LLM 的静态检查器，默认只读扫描目录，不执行模型、不观察运行时工具选择，因此权限面较小（least_privilege=2）；但 README 未说明扫描是否会读取或上传敏感内容，也未提供任何数据流/隐私说明（data_flow_transparency=2 仅因“本地、零 LLM”这一明确声明，sensitive_data_handling=1 因缺少对提示词/配置中可能含密钥的处理说明）。用户确认方面，默认“findings are advisory”，但 --fail-on fail/review 会直接使 CI 失败，属于有外部后果的默认门禁，未见交互式确认机制（user_confirmation=1）。依赖仅 pyyaml>=6.0.3，dev 依赖有上界约束，CI 中 GitHub Actions 均以 commit SHA 固定，属正向证据（dependency_security=2）；但未提供 SBOM、依赖审计或漏洞响应细节。外部影响限于写 SARIF/JSON 报告与 baseline 文件，未见破坏性默认（external_effects=2）。回滚方面有 --write-baseline 与 baseline 门禁，可视为一种变更控制，但没有对已生成报告/配置的撤销或恢复说明（rollback=1）。来源归属明确标注 Hermes Labs、Apache-2.0、SECURITY.md 联系邮箱，但发布者身份未经验证（source_attribution=2）。
自洽性：README 对能力边界（不检测语义矛盾、SKIPPED 不等于 PASS、工具比较限于单个解析输入）的表述与 pyproject 描述、CI 自扫描样例一致（self_consistency=2）。依赖可用性：requires-python>=3.10，CI 覆盖 3.10–3.13，依赖仅 pyyaml，安装路径（uvx/pip/brew）明确（dependency_availability=2）。失败信息：devcontainer 测试断言 malformed 输入输出 'Input error'，README 说明 SKIPPED 与 PASS 的区别，说明有可辨识的失败/跳过语义（failure_messages=2）；但未展示具体错误消息格式或退出码表。
受众与场景：面向开发者与 CI，覆盖 GitHub Actions、GitLab、pre-commit、多种 CLI 集成（audience_and_scenarios=2）。能力边界：README 明确列出不做什么（不运行模型、不观察运行时、不保证生产安全、不检测语义矛盾），并说明 SKIPPED 语义，属较充分的边界声明（capability_boundaries=3）。触发精度：--fail-on fail/review 与 baseline 提供分级门禁，但 H5/H6 等规则被描述为“任何两种格式即标记”，可能产生噪声，未见阈值调优说明（trigger_precision=2）。环境适配：支持多 Python 版本、Homebrew、devcontainer，但未说明 Windows 或非 POSIX 环境（environment_fit=2）。
信息架构：README 结构清晰（能力、快速开始、CI、集成、文档、贡献、许可），但 llms-full.txt 与 docs/ 内容未在证据中提供，无法核实（information_architecture=2）。安装说明：uvx、pip、brew、lintlang init 均有具体命令（install_notes=3）。命名稳定性：规则 ID（H1.1、H3、H5、H6、H1.9）在 README 与 CI 中出现，但未见版本化规则 ID 稳定性承诺（naming_stability=2）。示例与 FAQ：有 quickstart 示例与 devcontainer 测试样例，但无 FAQ（examples_and_faq=2）。已知限制：明确列出不检测语义矛盾、SKIPPED 语义、工具比较范围（known_limitations=3）。许可：Apache-2.0 全文与 pyproject 声明一致（license=3）。版本与变更日志：pyproject 版本 0.8.1，CI 引用 v0.7.1，CHANGELOG.md 被链接但内容未提供（versioning_changelog=2）。维护责任：SECURITY.md 给出响应时限与联系邮箱，但发布者未验证，维护承诺无法独立核实（maintenance_responsibility=2）。
输出可用性：支持 JSON、SARIF、GitLab Code Quality，CI 中验证 SARIF 结构与规则 ID，输出可被自动化消费（output_usability=2）。边际价值：在已有 linter 生态中提供针对 agent 配置/工具描述的专门检查，属差异化，但未提供与现有工具对比或误报率数据（marginal_value=2）。成本收益：零 LLM、确定性、单依赖、uvx 即用，成本低；但未量化扫描耗时或大规模仓库表现（cost_benefit=2）。
主张可追溯：README 引用合并 PR #5656 与 Zenodo DOI，但证据中未包含这些外部内容，无法核实（claim_traceability=2）。交叉来源印证：README、pyproject、CI、devcontainer 测试在版本、命令、规则 ID 上相互一致（cross_source_corroboration=2）。事实与推断分离：README 明确区分“静态检查发现”与“生产安全”主张，并说明 SKIPPED 不等于 PASS（fact_inference_separation=2）；但截图被标注为“stylized”，其展示的发现无法从证据核实。
- README 未说明扫描过程中如何处理可能包含密钥或敏感信息的提示词与配置文件，建议在采用前确认本地读取与缓存行为。
- 默认 advisory，但 --fail-on fail/review 会直接使 CI 失败，属于有外部后果的门禁，团队应先在非阻塞模式下评估误报。
- 发布者身份未经验证，SECURITY.md 中的响应时限与维护承诺无法独立核实。
- CHANGELOG.md、llms-full.txt 与 docs/ 内容未在证据中提供，版本与规则稳定性无法核实；pyproject 为 0.8.1 而 CI 引用 v0.7.1。
- H5/H6 等规则被描述为“任何两种格式即标记”，可能产生噪声，建议先用 baseline 观察实际命中率。