企业官网建设流程全解析

Source Registry 实战指南：为自主研究 Agent 构建可审计的外部证据准入体系

【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering

本篇指南以本仓库researcher/source-registry.md为骨架，讲解如何为 autonomous researcher（自主研究 Agent）设计一套"来源注册表"：在花费任何评估 token 之前，先明确该监控什么、什么证据可采纳、什么必须拒绝。读完本文，你将掌握三档来源优先级分级、五条硬性排除规则、监控查询族的组织方法、候选来源的强制元数据 schema、刷新节奏与接受偏差清单，并看到这套策略在本仓库 Researcher Operating System（researcher/README.md）中是如何被脚本强制执行的。

一、Source Registry 在 Researcher OS 中的定位

本仓库的researcher/目录定义了一套"把外部研究转化为技能变更"的原生工作流，其生命周期为：

discover -> triage -> evaluate -> extract -> map -> draft -> validate -> prepare-pr -> human-merge

其中triage（分诊）阶段的核心输入就是source-registry.md。在 researcher/README.md 的阶段说明中，Triage 阶段被明确描述为 "Source class and exclusion check fromsource-registry.md"，即：用来源分类（source class）和排除检查（exclusion check）来决定一个候选来源是否值得继续消耗评估成本。

在自主研究循环 runbook 的 Setup 步骤中，规则更加直白：

1. 用research_loop.py init创建 run ID；
2. 读取source-registry.md并为本任务选择来源分类；
3. 读取机制注册表（researcher/mechanisms/registry.jsonl），在声称"新颖"之前先了解已接受的机制；
4. 在评估任何内容之前先阅读相关评分卡；
5. 声明锁定表面（rubrics、清单、机制注册表、合并策略在评分期间不可编辑）；
6. 声明可编辑表面（评估、提案、草稿、run 局部机制提案、追加式日志）。

可以看到，来源注册表是整个研究流水线的"准入闸门"：它服务于一个朴素但关键的目标——在花掉评估 token 之前就决定值不值得花。

二、优先级来源分层：三档来源、六类渠道

注册表将候选来源划分为三个优先级档位，每一档都给出了典型渠道与用途：

实际使用中的几个关键判读：

• Tier 1 同时容纳"论文"与"AI 实验室工程博客"，因为这两类渠道分别供应"新机制/基准结果/消融实验"与"生产模式/模型行为/代理架构"，用途互补而非互斥；
• Tier 2 的价值在于运维教训与系统设计模式，它们未必产出论文，但往往暴露真实生产环境中的失败模式；
• Tier 3 被明确定位为"发现线索"：摘要、播客、视频只能帮你找到线索，在接受之前必须回头去评估原始来源（primary sources）。

这一分级在本仓库的种子数据中可以直接得到印证。researcher/discovery/manual-seed.jsonl 共记录 12 条手工种子候选，其source_type分布为：engineering_blog8 条（覆盖 OpenAI、Anthropic、Google Research、Cursor、Vercel、Prime Intellect、Cohere 等 Tier 1/2 机构）、paper3 条（机制洞察、治理实践、自主实验系统）、code1 条（Karpathy autoresearch 程序）。每条记录都带有candidate_reason字段，说明"为什么这条值得进入管线"——这正是注册表思想在数据层的落地。

三、排除规则：五条硬性拒绝模式

注册表要求对命中以下任何模式的来源执行拒绝或延后（reject or defer）：

1. 匿名或无法核实的作者，且没有一手证据（Anonymous or unverifiable author with no primary evidence）；
2. 缺乏机制、产物、指标或可复现声明的厂商营销（Vendor marketing with no mechanism, artifact, metric, or reproducible claim）；
3. 仅复述提示工程或 RAG 基础知识的入门教程（Basic tutorials that restate prompt engineering or RAG fundamentals）；
4. 仅凭截图、演示或私人轶事、且细节不足以实现的主张（Claims based only on screenshots, demos, or private anecdotes without enough detail to implement）；
5. 核心洞见已被本仓库覆盖、且未带来新证据、新失败模式或新实现细节的内容（Content whose main insight is already covered in the repo without new evidence, failure modes, or implementation detail）。

这五条规则与内容策展评分卡中的四个 Gatekeeper 门槛一一呼应：

• 排除规则 1、2 → G4 Source Verifiability（作者或组织可识别且技术上可信，否则 REJECT）；
• 排除规则 3 → G3 Beyond Basics（只覆盖入门内容视为不过）；
• 排除规则 4 → G2 Implementable Artifacts（纯评论、无产物或不可复现流程视为不过）；
• 排除规则 5 → 与仓库机制注册表（researcher/mechanisms/registry.jsonl）形成闭环：重复的洞见在 novelty 阶段就会被novelty_check.py拦下。

评分卡还明确了"任何门槛失败即拒绝"的语义（"any failed gate rejects the source unless a human explicitly overrides it"），且 researcher/scripts/validate_repo.py 的validate_researcher()会检查评分卡中是否写明了这种门禁语义（要求文本包含 "any failed gate rejects" 或 "any gate fails"，否则给出警告）。

四、监控查询族：把发现阶段变成可复用的关键词资产

注册表建议在运行 web 或论文发现时使用以下查询族：

• context engineering agent systems tool design evaluation memory compression
• harness engineering AI agents eval harness agent loop scratchpad
• autonomous research agent self improving agents experiment loop
• LLM agent evaluation rubric source quality citation accuracy
• agent memory durable scratchpad file system state
• AlphaEvolve FunSearch autoresearch autonomous experimentation
• OpenAI Anthropic Cohere DeepMind agent engineering blog

使用建议（结合仓库实践）：

• 查询族按"主题簇"而非单个关键词组织，便于定期轮换、避免同一批候选反复出现；
• 前五组对应仓库技能栈的五大主题（context engineering、harness engineering、autonomous research、evaluation、memory）；
• 后两组分别覆盖"自主实验系统"（AlphaEvolve、FunSearch、autoresearch 等）与"实验室工程博客"渠道——前者正是harness-engineering技能与claim-harness-locked-evaluator等主张的来源地；
• 发现到的候选应当写入 run 的sources/queue.jsonl（由research_loop.py init自动创建 S001 记录），而不是散落在聊天记录里。

五、来源元数据：每个候选来源的强制记录格式

注册表规定，每一个候选来源都必须记录以下字段：

url: "" title: "" author_or_org: "" published_at: "" source_type: "paper | engineering_blog | documentation | benchmark | code | talk | other" retrieval_status: "retrieved | partial | failed" primary_or_secondary: "primary | secondary" candidate_reason: ""

字段语义与使用要点：

• source_type的七种枚举值（paper、engineering_blog、documentation、benchmark、code、talk、other）与research_loop.py init --source-type的可选值完全一致，也与 Tier 表中的来源类别对应；
• retrieval_status三态（retrieved/partial/failed）是评估的前置条件：runbook 明确要求"评估前先记录检索状态"，并且治理规则第 2 条写明"只引用已检索到的来源；若来源加载失败，记录失败并不得将其作为证据引用"；
• primary_or_secondary区分一手与二手来源，直接服务于"接受偏差"第 5 条（见第七节）；
• candidate_reason要求记录"为什么这条值得"，是后续 novelty 检查和人工复核的第一手上下文。

这套 YAML schema 在仓库中有对应的机器可读形态：researcher/templates/source-evaluation.json。它把source字段原样承载（url、title、author_or_org、published_at、source_type、retrieval_status、primary_or_secondary），并追加gatekeeper（G1–G4 逐项 pass/evidence）、scoring（D1–D4 各 0–2 分与加权总分）、decision（verdict、override、confidence、justification）、extraction（机制摘要、可实现产物、失败模式、候选技能目标）等结构化区块。该模板由research_loop.py的create_source_evaluation()在init时自动实例化为sources/evaluations/source-evaluation-draft.json，初始决策固定为HUMAN_REVIEW、置信度low——即"骨架必须先经过真实检索与评分，不允许空转通过"。仓库现存的实际 run researcher/runs/20260515-035228-executable-autonomous-research-frameworks/sources/evaluations/source-evaluation-draft.json 正是这种"草稿脚手架"的实证。

六、刷新节奏：周、月、PR 前三级 cadence

• 每周：实验室博客、arXiv/OpenReview、公开基准仓库、活跃的工程博客；
• 每月：对旧来源做再验证（revalidation），尤其针对波动性高的主张——模型相关的阈值与基准数字（例如claims/index.jsonl中标记为volatility: high的 claim）；
• PR 之前：重新抓取每一个被引用的来源，确认证据仍然支持拟议的技能变更。

这三条节奏在仓库中同样有落点：

• claims/index.jsonl为每个 volatile 主张记录retrieved_at、last_reviewed、volatility、evidence_strength字段，例如claim-latent-briefing-public-results被标记为volatility: high、evidence_strength: secondary，属于月度再验证的重点对象；
• 治理规则第 2 条（"cite only retrieved sources"）与 PR 前重抓取相互配合，防止"证据已过期但仍被引用"；
• researcher/rubrics/skill-change.md 与 researcher/rubrics/harness-change.md 作为技能/框架变更门禁，与注册表的 PR 前检查一起构成发布闸门。

七、接受偏差清单：五条评估纪律

注册表列出的五条"必须避免的接受偏差"，本质上是给评估者（无论是人还是 LLM judge）的行为约束：

1. 不因机构有名就接受薄弱产物（Do not accept a weak artifact because the organization is famous）；
2. 不拒绝失败的实验——只要它揭示了可操作的失败模式（Do not reject negative or failed experiments if they reveal a practical failure mode）；
3. 不迷信长报告——目标是"可实现的机制密度"（implementable mechanism density），而不是篇幅；
4. 不轻信基准主张——必须核查评估设置、基线与局限（evaluation setup, baselines, and limitations）；
5. 有二手摘要时不得把二手来源当作真相（Do not treat secondary summaries as sources of truth when primary sources are available）。

这五条在评分卡中对应着量化的惩罚与强制项：

• 偏差 1、3 → D4 Novelty and Insight（0–2 分）与 D1 Technical Depth（35% 权重）共同约束"华而不实"的来源；
• 偏差 4 → D3 Evidence and Rigor（20% 权重）：只有"定量证据、基线、消融、公开日志或可复现方法"才能得满分 2 分，"貌似合理的经验报告"最多 1 分；
• 偏差 5 → 由primary_or_secondary字段承载，并在 O3 覆盖规则中体现：当 D3 只得 1 分而总分达标时，强制降级为HUMAN_REVIEW。

八、源码级佐证：注册表如何被脚本强制与保护

来源注册表不是一份"建议文档"，它被本仓库的校验与治理机制直接引用：

1. 注册表是 Researcher OS 的必需文件。researcher/scripts/validate_repo.py 第 21–33 行的REQUIRED_RESEARCHER_FILES列表将source-registry.md与mechanisms/registry.jsonl、claims/index.jsonl、corpus/index.json等并列，validate_researcher()（第 319 行起）逐项检查文件存在性，并额外校验templates/source-evaluation.json可被 JSON 解析、内容评分卡必须显式声明门禁失败语义。

2. 注册表属于"锁定表面"。researcher/scripts/research_loop.py 顶部定义：

LOCKED_SURFACES = [ "researcher/rubrics/content-curation.md", "researcher/rubrics/skill-change.md", "researcher/rubrics/harness-change.md", "researcher/mechanisms/registry.jsonl", ... ]

这与机制注册表中locked-editable-surfaces机制（"在循环开始前把表面划分为 locked / editable / append-only / human-controlled，防止 Agent 用被自己改过的评估器来批准自己的工作"）以及claim-harness-locked-evaluator主张（"自主循环需要锁定的评估器与狭窄的可编辑表面"）完全一致——准入规则比产物更难修改，这是治理规则第 1 条的硬性要求。

3. 评分卡阈值被确定性校验。validate_rubrics()要求content-curation.md必须包含 G1–G4、O1–O4 以及阈值1.4与0.9；skill-change.md必须包含 S1–S5 与1.4；harness-change.md必须包含 H1–H5 与1.5。这意味着"评估标准"本身是受版本控制的、可审计的资产，而不是评估者随手可改的软约束。

4. 机制注册表与主张台账形成证据闭环。只有当research_loop.py promote-mechanisms在 run 通过就绪校验且记录人工复核（--reviewed-by必填）后，机制提案才能写入mechanisms/registry.jsonl并追加到mechanisms/ledgers/accepted.jsonl；被拒机制则追加到rejected.jsonl，确保未来的 Agent 不会重复探索同一条死路。这与注册表"拒绝或延后"的策略遥相呼应。

九、从注册表到可执行管线：一个最小 run 的完整闭环

将上述所有要素串起来，一次符合注册表纪律的研究 run 大致是：

# 1. 初始化 run（自动生成 THREAD.md、来源队列、评估草稿、提案草稿、锁定/可编辑表面声明） python researcher/scripts/research_loop.py init --title "Source title" --url "https://example.com/source" --source-type paper # 2. 记录原始证据（复制到 run 的 sources/evidence/raw/，并把队列状态更新为 retrieved） python researcher/scripts/research_loop.py retrieve --run-dir researcher/runs/<run-id> --file ./source.pdf # 3. 填写 source-evaluation-draft.json（G1–G4、D1–D4、决策），然后登记评估完成 python researcher/scripts/research_loop.py evaluate --run-dir researcher/runs/<run-id> # 4. 修改已发布技能前，先做机制重叠检查（注册表重叠是首要重复信号） python researcher/scripts/novelty_check.py --file researcher/runs/<run-id>/proposals/skill-proposal.md # 5. 确定性校验：仓库级与 run 级 python researcher/scripts/validate_repo.py --strict python researcher/scripts/validate_run.py --run-dir researcher/runs/<run-id> # 6. 记录 PR 就绪说明并关闭 run（accepted / rejected / reference-only / abandoned） python researcher/scripts/research_loop.py pr-ready --run-dir researcher/runs/<run-id> --summary "..." --test-plan "..." --risks "..." python researcher/scripts/research_loop.py close --run-dir researcher/runs/<run-id> --status reference-only --reason "..."

需要特别说明的限制与边界：

• 这些命令不会调用任何 LLM；research_loop.py的职责只是创建持久化产物（run-state.json、THREAD.md、评估与提案文件），然后运行确定性校验；
• 在 run 启动前，注册表（source-registry.md）、评分卡与机制注册表均为锁定表面，评估过程中不可修改；
• 管线允许 Agent 准备分支与 PR 内容，但合并必须由人完成——README 明确写明 "No workflow in this directory authorizes auto-merge"；
• 若某个提案同时存在多个竞争草稿，先运行python researcher/scripts/compare_skill_revisions.py skills/evaluation/SKILL.md skills/advanced-evaluation/SKILL.md做确定性预检，再套用成对技能修订评分卡。

十、在本仓库中继续阅读与验证

想深入验证本文所述机制，可以按以下路径只读浏览仓库：

1. 策略层：researcher/source-registry.md（本文主体）→ researcher/README.md（生命周期与目录地图）→ researcher/runbooks/autonomous-research-loop.md（run 级执行细则）；
2. 评分层：researcher/rubrics/content-curation.md（G1–G4 门禁与 D1–D4 加权评分）→ researcher/rubrics/harness-change.md；
3. 证据层：researcher/templates/source-evaluation.json（机器可读评估形态）→ researcher/mechanisms/registry.jsonl（已接受机制）→ researcher/claims/index.jsonl（volatile 主张台账）→ researcher/discovery/manual-seed.jsonl（种子候选示例）；
4. 执行层：researcher/scripts/research_loop.py（锁定/可编辑表面、状态机、机制晋升）→ researcher/scripts/validate_repo.py（必需文件与评分卡阈值校验）→ researcher/scripts/novelty_check.py；
5. 实跑样例：researcher/runs/20260515-035228-executable-autonomous-research-frameworks/（含 THREAD.md、评估草稿、验证报告、机制提案）与 researcher/fixtures/skill-proposals/harness-engineering-proposal.md（一份含 novelty 判定与风险说明的完整提案样板）。

如果只想做一次快速自检，可以直接运行仓库自带的确定性校验器：python researcher/scripts/validate_repo.py。该命令会检查 Researcher OS 必需文件（含source-registry.md）、评分卡阈值、机制注册表结构、主张台账与 corpus 索引的一致性，输出错误与警告统计——这也是本仓库"确定性优先于 LLM 判断"机制（deterministic-first-validation）在注册表层面的最终兜底。

【免费下载链接】Agent-Skills-for-Context-EngineeringA comprehensive collection of Agent Skills for context engineering, multi-agent architectures, and production agent systems. Use when building, optimizing, or debugging agent systems that require effective context management.项目地址: https://gitcode.com/GitHub_Trending/ag/Agent-Skills-for-Context-Engineering