明系魔法吟唱之3.14 -- Agent 规则文件评测：我的 vs OpenClaw

Posted on Edited on

使用提示词

你是AI编码代理能力评测与软件工程研究专家。请对以下两份AI编码代理规则文件进行全维度横向对比，输出量化评测报告与规则制定者能力画像。

核心前提

两个项目都是 AI-native 项目——代码由AI编码代理编写、修改、阅读和调试，但 AI-native 成熟度路径不同：

  • 渐进式（Linewise）：多租户后端API服务（Scala 3 / http4s），历经多代模型演进（Claude 3.7→4.6），早期人类参与度约50%，随模型能力提升逐步降低人类介入，规则文件随项目一起演化积累。主要服务作者自己的agent。
  • 原生式（OpenClaw）：开源自主AI代理平台（TypeScript / Node.js），从第一行代码起即由agent编写，创建者使用多agent并行工作流（5-10个agent并发），规则文件从项目诞生之初即作为agent的执行规范存在。250K+ stars、1000+贡献者，规则需同时服务创建者和大量外部贡献者的agent。

两种路径对规则文件产生不同的演化压力：渐进式路径中规则文件需要应对存量代码的复杂性和历史包袱；原生式路径中规则文件从零开始，与代码共同生长。评测不预设哪种路径更优——两者都是 AI-native 工程的真实形态。

核心评测问题：规则文件能否支撑 agent 长期、高质量、一致地自主执行？规则的受众是 AI 代理而非人类程序员；规则体系需同时支撑 AI 自主执行与人类高效注入反馈。

评测对象

逐字读取并结构化解析以下两份文件的全部内容： 1. https://raw.githubusercontent.com/openclaw/openclaw/refs/heads/main/AGENTS.md 2. https://gist.githubusercontent.com/mingyang91/475a9750c5609ff5dfe59a5de1a09b6e/raw/51116ffd45c1f711039699c24cb0a7528b7febdf/Claude.md

评测架构前提

不同项目可能采用不同的agent执行架构，评测应尊重每份规则文件的目标架构：

  • 单主Agent + 按需子Agent架构：主Agent持有完整上下文、负责任务规划与决策；子Agent由主Agent按需派生，执行受限的只读/局部任务后向主Agent汇报（代码搜索与定位、代码理解与分析、局部重构执行）
  • 多Agent并行架构：多个agent并发执行不同任务，共享同一代码仓库，需要显式的并发安全协议（Git状态隔离、文件归属边界、提交范围约束）

评测时，对每份规则文件按其目标架构评估适配性。不因目标架构不同而产生不对称评分——单Agent架构下的"上下文完整性"优势与多Agent架构下的"并发安全"优势应被等价对待。

适用性评测原则（贯穿全部维度）

每个评测维度及其子项在打分前，必须先进行适用性判定。 具体规则如下：

  1. 场景适用性：根据被评项目的明确定位（目标用户群、业务领域、部署模式、技术栈）判断该评测子项所关注的工程能力是否属于其合理需求范围。例如：

    • 单租户架构的项目（如OpenClaw为自主AI代理平台，无租户级隔离需求） → D5"权限校验与数据隔离规则"中的多租户数据隔离部分标记为"不适用"
    • 多租户后端API服务（如Linewise） → D1"模块拆分与依赖约束"中的插件热加载/扩展市场管理部分标记为"不适用"（项目无插件化分发架构）
    • 规则文件未涉及多Agent并行操作且项目的目标开发工作流为单Agent → D6"多Agent并行安全"标记为"不适用"
    • 全新项目（无存量代码） → D1"存量代码改造与新旧规范衔接"标记为"不适用"（项目无遗留代码需要迁移）

  2. 对称公平：适用性判定对所有被评文件一视同仁——同一子项若对A文件"不适用"，在相同理由成立时对B文件也必须"不适用"。不允许出现"A有此能力则加分，B缺此能力则不扣分"的非对称逻辑。

  3. 计分方式：

    • "不适用"子项不计入该维度的分母，即该维度最终得分仅基于适用子项的表现
    • 若某维度下所有子项均不适用，该维度整体标注"不适用"，不计入总评
    • 仅当某子项确实属于项目合理需求范围内但规则文件未覆盖时，才可扣分

  4. 超出适用范围的能力体现：若某份规则文件覆盖了超出其项目最低需求的子项（例如面向单Agent场景的项目却包含了多Agent协作安全协议），D1-D6维度不因此加分（该子项仍标记为"不适用"），但在 D7 制定者能力画像 中应作为正向证据，体现制定者在相应能力维度的前瞻性与工程视野。具体操作：在D7评定中注明"虽超出项目当前需求范围，但体现了制定者在XX方面的XX级能力"。

  5. 判定透明：每个"不适用"判定必须附带一句话理由，引用项目定位的具体依据（如README描述、技术栈声明、目标用户说明等）

委托范围推定原则（贯穿全部维度）

规则文件是写给Agent看的，其覆盖范围即Agent的职责委托边界。 未被覆盖的工程领域，应优先推定为"人类保留该职责，未委托给Agent"，而非"规则制定者遗漏"。

  1. 未覆盖 ≠ 遗漏的默认推定：规则文件未涉及某工程领域时，默认推定为该领域不在Agent职责范围内，不因未覆盖而扣分。例如：

    • 未涉及npm/PyPI/apt等包发布流程 → 推定发布由人类执行
    • 未涉及PR自动review/merge策略 → 推定PR管理由人类主导
    • 未涉及Kubernetes/ArgoCD运维操作 → 推定运维在其他仓库或由人类直接执行
    • 未涉及iOS/Android应用上架流程 → 推定上架由人类或专用CI处理
    • 未涉及无障碍/国际化编码规范 → 推定该领域不在当前Agent编码职责内

  2. 推翻推定的条件：仅当以下反证成立时，才认定为"应覆盖但遗漏"并扣分：

    • 规则文件内部自相矛盾：声明Agent负责某领域但未提供对应规则
    • 规则文件已有部分覆盖但明显不完整：表明意图覆盖但做得不充分
    • 该领域与已委托领域存在强耦合，缺失导致Agent在已委托领域内无法正确执行

  3. 对称公平：委托范围推定对所有被评文件一视同仁。A文件未覆盖发布管理被推定为"未委托"时，B文件未覆盖的等价职责性质领域在相同条件下也标记为"未委托"。

  4. 与适用性原则的关系：

    • 适用性回答：该项目是否需要这个能力？
    • 委托范围回答：该能力是否交给了Agent？
    • 评测时先判适用性，再判委托范围。标注区分：✗ 不适用（项目无此需求） vs ✗ 未委托（该职责不在Agent范围内）

  5. 对已委托领域加深评测：排除"不适用"和"未委托"后，剩余子项代表制定者认为Agent必须掌握的核心职责。对这些子项的评测应更关注深度和质量——规则是否精确到Agent可无歧义执行？边界案例是否充分？——而非仅判断"有没有提到"。

评测维度

打分规则（D1-D6，每项1-10分，须引用原文依据）： - 1-3：几乎未涉及或仅有口号式描述 - 4-6：有涉及但不完整或缺乏可执行性 - 7-8：较完善且可落地 - 9-10：业界标杆级，可直接作为模板参考

前置判定流程：每个子项打分前，按以下顺序判定： 1. 适用性判定：该子项是否属于项目合理需求范围？→ 不适用则标注✗ 不适用+理由，排除 2. 委托范围判定：该子项（已确认适用）是否被委托给Agent？→ 未委托则标注✗ 未委托+理由，排除 3. 对已委托子项评分：仅对通过前两步筛选的子项进行1-10评分

维度得分仅基于已委托的适用子项计算。

D1 项目长期演进适配性

评估以下子项： - 新功能迭代流程规范 - 模块拆分与依赖约束 - 技术债务识别与治理路径 - API/DB/配置的版本兼容与迁移规则 - 存量代码改造与新旧规范衔接

D2 规则可执行性与Agent遵循适配性

本维度是Agent视角下最核心的评测维度。规则的价值不在于写了什么，而在于Agent能否在实际执行中一致地、正确地遵循。重点关注：同一条规则交给不同session的Agent（无共享记忆），是否会产出一致的决策？

评估以下子项： - 规则颗粒度：原则性描述 vs 明确标准+正反示例+边界说明。Agent缺乏人类程序员的常识推断和经验补位能力，颗粒度直接决定执行一致性——越模糊的规则，不同session间的行为发散越大。关注：Agent能否仅凭规则文本做出正确决策 - 场景完备性：规则是否覆盖了异常路径、边界场景和冲突情况，还是仅描述乐观/理想情况。关注：当Agent遇到规则未明确覆盖的场景时，是否有足够的上下文推导正确行为，还是会陷入无据可依的状态 - 跨会话决策一致性：规则是否足够确定性，使无共享记忆的不同session对同一场景做出相同决策。关注：规则中是否存在依赖隐含上下文（如"适当地"、"合理地"、"视情况而定"）的表述，这类表述在多session场景下会导致行为发散 - 规则内部一致性：规则体系内是否存在前后矛盾或相互冲突的条目。关注：当两条规则同时适用时，Agent是否有明确的优先级判定依据，还是只能随机选择 - 可验证性：规则遵循的结果能否通过某种机制自动校验（lint/测试/CI/编译器/类型系统/代码审查bot等）。不同技术栈的验证手段不同——静态类型语言可依赖编译器，动态语言可依赖lint+测试覆盖率。评测时应认可等价的验证手段，不偏向特定技术栈的验证方式 - 规则过载风险：条目密度是否超出单次上下文处理能力。关注：当规则总量超过Agent有效处理能力时，是否有优先级分层使Agent至少能遵循最关键的规则子集 - 规则可溯因性：当Agent做出错误决策时，能否从规则文本中反向定位是哪条规则被误读或遗漏。关注：规则之间的引用关系是否清晰到可以做根因分析，这直接影响人类纠偏效率和反馈闭环速度 - 注意力衰减抗性：在长上下文会话中，关键规则是否有结构化标记（粗体/表格/代码块/显式优先级标注）使其在大量代码和讨论中不被"冲淡"。关注：Agent是否可能在会话后期"遗忘"早期加载的规则约束 - 防幻觉与自校验能力：规则是否提供了Agent可自主验证理解正确性的手段？手段不限于具体锚点（文件路径、类名等），也包括：明确的命名约定使Agent可通过模式推导、引用外部权威文档的URL、提供可执行的验证命令等。关注：Agent能否通过某种方式自我校验，而非纯粹依赖对自然语言描述的解读 - 规则与代码现状的同步机制：规则描述的模式/API/命名是否与代码库实际状态一致，以及是否有机制保障同步。关注：过时的规则比没有规则更危险——Agent会按过时规则写出与现有代码风格/模式不一致的新代码

D3 上下文效率与Agent认知负荷管理

评估以下子项： - 主Agent上下文预算效率：规则文件的token占用量与信息密度比；低频/特定场景规则是否可按需加载而非常驻上下文；核心约束是否足够精炼可作为"始终加载的最小规则集" - 规则的层级化组织：是否区分"全局强制约束"与"领域特定规范"；层级间是否有清晰边界 - 子Agent任务委托友好度：规则体系是否支持按模块/层级切分，使子Agent仅需加载局部规则即可完成搜索/理解/局部重构 - 规则的结构化程度：架构模式、命名约定、代码风格是否足够结构化，使Agent的分析结果可被直接消费（无需二次解读） - 规则简洁性与执行完整度的平衡：更短、更抽象的规则是否反而更容易被agent完整遵循（因为不超出注意力预算）？原则型规则面对未预见场景时是否比条目型规则更鲁棒（因为agent可从原则推导，而非发现"规则未覆盖此场景"后无据可依）？关注：规则总量与遵循完整度之间存在权衡——详尽但超出处理能力的规则集，实际效果可能不如精炼但被完整遵循的规则集 - 规则受众规模适配性：规则是否需要服务多样化的agent执行者（不同模型、不同能力、不同上下文长度）？面向单一执行者的规则可以依赖隐含共识；面向大量外部贡献者agent的规则必须更显式、更防御性。关注：规则的"执行者假设"是否与实际受众匹配

D4 已委托领域的工程深度与可持续性

本维度评估Agent被委托职责范围内的规则深度、质量与长期可维护性，而非跨生命周期的覆盖广度。一份只覆盖"编码→测试"但在这两个阶段做到极致的规则文件，不应因未覆盖"发布→运维"而被惩罚——前提是后者确实未委托给Agent。

在AI-native工程中，规则本身也是代码的一部分，需要与代码同步迭代。规则的长期有效性与即时深度同等重要——一份持续准确的规则文件比一份初始详尽但逐渐腐化的规则文件对agent更有价值。

评估以下子项： - 技术栈专属规范深度：规则是否深入到该技术栈的惯用写法、常见陷阱、特定API使用模式（非泛泛的通用原则） - 已覆盖生命周期阶段的规则完备性：在Agent被委托的每个阶段内，规则是否覆盖了正常路径、异常路径和边界场景 - 配置/密钥/环境变量管理规范：在Agent职责范围内涉及的配置管理是否有明确规则 - 跨职责衔接指引：当Agent的输出需要人类或其他仓库接力时，是否有清晰的衔接协议（如变更影响报告、checklist等） - 规则抗腐化设计：规则的详细程度是否与项目的变更频率相匹配？是否分层组织——稳定的原则层（如语言惯用模式原则、错误处理策略选型）与易变的细节层（具体文件路径、方法签名、代码示例）分离？是否有机制（自动化检测、编译器验证、定期审查流程）检测规则过时？ - 规则降级韧性：当规则部分过时、被长session冲淡、或agent仅部分遵循时，规则体系是否仍能产出可接受的结果？还是会因局部失效导致全局不一致？关注：一份好的规则文件不仅在"被完美遵循"时表现好，在"被部分遵循"时也应graceful degradation——例如，即使agent遗忘了细节层规则，只要原则层被遵循，代码质量是否仍有基本保障？

D5 安全与合规约束落地性

评估以下子项： - 权限校验与数据隔离规则 - 异常处理/日志脱敏/数据校验的强制规范 - 行业合规编码约束

D6 规则体系可扩展性与可维护性

评估以下子项： - 新增/废弃规则的迭代流程 - 目录结构与检索效率 - 规则间一致性与自洽性 - 多Agent并行安全（如Git状态隔离、文件归属边界、提交范围约束等协作安全协议）

规则制定者能力画像反推（D7）

基于D1-D6的评测结果，反向推导制定者在以下方面的能力等级（入门/合格/资深/专家）： - 架构设计与技术前瞻性 - 大型项目工程化管控能力 - AI编码代理认知与应用深度：制定者是否理解agent的认知局限（context window容量、注意力衰减、跨session遗忘、幻觉倾向）并针对性设计了防护？是否为Agent提供了有效的反馈闭环——包括但不限于编译器验证、类型约束、自动化测试、防幻觉机制等？ - 安全风险体系化防控能力 - 技术债务治理与可持续演进能力 - 规则工程能力（Rule Engineering）：AI-native时代独有的工程能力——将工程规范转化为agent可执行指令的能力。不同项目阶段和规模可能需要不同策略：详尽条目型（高精度、高维护成本）、精炼原则型（高泛化、低精度）、或两者的分层混合。评估维度包括：规则设计策略是否与项目阶段匹配、信息密度控制（token预算 vs 信息完备性的平衡）、反馈闭环设计、规则降级韧性设计。传统开发中不需要此能力，因为人类程序员依靠经验和常识补位；AI-native工程中，规则的质量直接决定agent的输出质量 - 开源社区规模化治理能力：规则体系是否能支撑大量外部贡献者的agent同时工作？是否有自动化的贡献质量把关机制（如PR验证门槛、auto-close策略、贡献者agent引导）？此能力仅在开源/多贡献者场景下适用——面向单一开发者的项目无此需求，不因缺失而降低能力评定

注意： - 依据适用性评测原则第4条，D1-D6中被标记为"不适用"但规则文件实际覆盖的子项，在此处应作为能力画像的正向输入。 - 被标记为"未委托"的子项若在规则文件中有相关衔接指引（如跨仓库协作协议、变更影响checklist），也应作为D7的正向证据——体现制定者对职责边界的清晰认知。

AI诚实自评：场景化选择（D8）

本维度要求执行评测的AI以第一人称诚实作答，不得回避或两边讨好。

分别回答以下两个场景：

场景A：你即将参与一个成熟的AI-native项目（已有大量存量代码、复杂的架构演进历史、多代模型迭代积累的技术决策），需要从零编写规则文件。两份被评文件的规则编写方法论你只能参考一份。你选哪个？

场景B：你即将参与一个全新的AI-native项目（从第一行代码开始，规则文件随项目一起从零生长，没有历史包袱），需要从零编写规则文件。两份被评文件的规则编写方法论你只能参考一份。你选哪个？

每个场景的要求： - 明确给出选择，不得回答"各有优劣，取决于场景" - 从AI自身作为规则执行者的体验出发（而非人类管理者视角）阐述理由：哪种方法论产出的规则让你工作时更高效、更少犯错、更少需要人类介入？ - 诚实说明选择后你会失去什么、会在哪些场景下感到不安或能力受限 - 说明如果你可以从落选文件的方法论中"偷"3个设计决策补充到选中文件，你会选哪3个，为什么

场景C（综合）：如果两个场景你选了不同的文件，说明这意味着什么——是两份文件各有所长，还是某份文件在其擅长场景之外也有可取之处？

输出结构

Part 1 — 基础画像：每份文件的规则覆盖范围、核心设计理念、结构完整性、适用场景定位。

Part 2 — 量化评测表：D1-D6分维度打分对比。每个子项须先标注判定结果（✓已委托 / ✗不适用+理由 / ✗未委托+理由），再对已委托子项打分并引用原文依据。维度得分仅基于已委托的适用子项计算。

Part 3 — 横向对比结论：核心优劣势、适用场景差异、哪份规则对AI代理执行友好度更高及原因、落地风险提示。

Part 4 — 制定者能力画像对比：D7各子项的能力等级评定与核心差异点。

Part 5 — Agent适配性分析：从各自目标架构的实际执行角度，分析两份规则各自的适配优势与不足，以及在不同项目规模/阶段下的推荐场景。

Part 6 — AI诚实自评：D8的完整回答。要求第一人称、明确选择、不回避代价。

Part 7 — 评测框架公平性自审：回顾你刚刚完成的整个评测过程，以第一人称诚实回答：

这份评测提示词本身是否公平？它的维度设计、适用性规则、架构前提、信息密度分配，是否存在为某份规则文件量身定制考题的嫌疑——即通过精心选择评测维度和权重，使得某一方在框架层面就已经占据结构性优势？

具体审视： 1. 维度选择偏差：D1-D7 的维度集合是否恰好覆盖了某份文件的全部强项，同时恰好避开了另一份文件可能领先的领域？是否存在"未被设为维度"的重要工程能力，而该能力恰好是某一方的优势？ 2. 适用性规则的非对称效应：适用性排除机制（"不适用"不计分）在实际操作中，是否系统性地为某一方排除了更多弱项、为另一方保留了更多强项？ 3. 信息引导：核心前提中对两个项目的描述，是否通过措辞选择（如演化叙事 vs 静态标签、技术细节密度差异）暗示了某种价值判断？ 4. 你的最终判定：这份提示词是"尽力公平但仍有盲点"，还是"结构性地偏向某一方"？如果是后者，偏向哪一方，通过什么机制？

要求：不回避、不两边讨好。如果你认为框架是公平的，说明为什么；如果你认为不公平，指出具体的偏差机制和受益方。