# OS-Agent **Repository Path**: ligiteehust/os-agent ## Basic Information - **Project Name**: OS-Agent - **Description**: 2026年全国大学生计算机系统能力大赛-操作系统设计赛(全国)-OS功能挑战赛道 proj18 - **Primary Language**: Unknown - **License**: Apache-2.0 - **Default Branch**: main - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2026-09-03 - **Last Updated**: 2026-09-03 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # OS-Agent OS-Agent 是 2026 年全国大学生计算机系统能力大赛操作系统设计赛（全国）OS 功能挑战赛道 Proj18 “面向小型操作系统的分析比对智能体系统设计”的参赛项目。 ## 参赛信息 - **赛事**：2026 年全国大学生计算机系统能力大赛-操作系统设计赛 - **赛道**：OS 功能挑战赛道 - **项目**：Proj18 · 面向小型操作系统的分析比对智能体系统设计 - **队伍名称**：OS照妖镜 - **队伍编号**：T2026104879910136 - **队员**：刘建博、李佳峻 - **学校**：华中科技大学 项目面向历届和当届 OS Kernel 作品，使用 Claude Code 组织多个专业 Agent，结合源码、Git 历史、Git Blob 与 AST 指纹，回答评委最关心的四个问题：作品实现了什么、代码从哪里发展而来、选手完成了哪些实质工作，以及是否存在需要复核的测评定向行为。相似度只用于召回候选，来源、传播方向和工作量由 Agent 综合版本历史与内核机制判断。 ## 核心能力 - **内核结构描述**：围绕体系结构、进程、内存、文件系统、I/O、同步、设备、Linux ABI 和网络九个核心模块，解释真实对象、关键执行链、设计边界与特殊机制。 - **来源与版本追溯**：使用 Git Blob 和 AST 指纹召回候选，再结合分支、提交历史和源码定位来源版本、引入提交及同届传播方向；明确区分真实来源与最近比较对象。 - **真实工作量分析**：区分原样继承、外部实现、接口适配、缺陷修复、功能扩展、主要重构和独立设计，并结合内部快照与开发阶段展示作品演进。 - **历史作品对比**：对比对象取真实来源（基座）与目标起点最接近的版本，按共享基线、目标独有、base 独有三块呈现；目标独有按改写、新增自研、测试与评测工程、第三方引入分层，并给出脚本实测的行级增删数字，独有部分才是本队工作量的归属对象。来源无法定位时才选最相似作品并声明。不把相似度写成抄袭概率。 - **开发与测评行为检查**：梳理批量导入、持续开发和 AI 使用记录；将自定义入口、黑白名单等真实执行测例的工程单列为中性“测评适配”，再分别识别需复核的成功存根、闭合的测例定向路径和未运行真实测例的结果伪造。是否构成作弊、处分及测评影响由组委会认定。 - **语义通用性分析**：围绕“特定输入触发、异常分支、必要状态变化缺失、结果可见”追踪只对固定测例、程序特征或输入形态成立的实现，并结合 Git 判断来源和首次引入位置。当前由 Agent 阅读局部源码与调用关系完成，不声称已经实现 CFG/CPG、程序切片或自动反事实执行。 - **批量交付**：每件作品生成一页摘要和三份 Markdown 报告；必要时可调用官方 runner 组织本地编译与运行，固定命令、环境和日志。最后通过首页统一检索并直接下载四份文件。 ## 项目成果 赛题同时涉及内核语义理解、历史版本追溯、工作量归属和测评风险判断，多个结论会被源码、文档、Git 历史和指纹结果交叉影响。OS-Agent 没有将这些问题压缩为单一相似度或固定规则，而是在真实作品调查中形成了以下方法和工程成果： - **Commit 级来源链路**：将 HEAD 指纹定位为候选召回信号，进一步追溯目标代码首次大规模出现的提交与来源仓库历史提交，形成“目标引入 commit ↔ 来源历史 commit”的可复核链路。对于同届高相似作品，分别追溯共同来源并比较扣除共同部分后的剩余实现，避免把共享 Base 误判为同届传播。 - **真实工作量分层**：不再要求所有作品都围绕精确 Base 描述差异。系统可以使用外部来源、目标引入快照、同队旧版本、仓库内部快照和最终实现作为不同分析基线，区分本队既有积累、本届实质新增、主要重构、平台适配、接口接入和原样继承。对比报告的目标独有块由 `pair-breakdown` 按行为分层（改写/新增自研/测试与评测工程/第三方引入），行级增删数字由脚本实测、可复核，整体入库的框架组件树按外来性线索单列不计入工作量；两侧仓库结构不同时自动做顶层目录对齐（同路径同内容才对齐），异构重组（如基座 kernel/src 重组为 api/core）时放弃路径级分层、改以内容与 AST 结构继承率呈现。 - **面向评委的内核描述**：以九个独立核心模块输出组织机制分析，并按需补充 0–2 个跨模块特殊设计。每次模块审查最多处理两个独立 job，直接解释入口、核心对象、状态变化、控制流、资源回收和实现边界，而不是罗列文件、函数或 syscall 数量。 - **测评适配与定向行为的分层调查**：自定义入口、黑白名单、跳过、重试、日志过滤和测试分组先作为适配事实检查，重点确认原测试二进制是否真实执行、原始输出是否未经改写到达 judge；它们不算内核功能贡献，也不会仅因名单存在而升级。只有“测例身份或固定输入、实际可达的特殊路径、通用语义短路、judge 可观察结果”完整闭合时才归入规则模式；未运行真实测例却预录、合成、重复或改写通过结果才归入结果伪造。BPF/eBPF 测例形态特化、假对象、虚构环境等则依闭环程度进入功能边界或评委复核。现阶段该方法依靠领域 Prompt 约束下的 Agent 源码调查，CFG/CPG、静态程序切片和反事实执行属于后续演进方向。 - **领域经验的 Agent 化**：以六个 callable roles 承载来源、模块、风险、对比和报告工作，按 job 动态加载模块、风险、统一语言和最终语义审查指南。确定性脚本只负责 Git、Blob、AST、永久链接、格式校验和文档生成，复杂语义判断继续由 Agent 综合多类材料完成。 - **可直接使用的数据与报告体系**：整理历届作品、失效链接对应的原始开源仓库及常见外部参考，建立可批量更新的 HEAD 指纹缓存；每件作品固定交付摘要、作品描述、开发过程和历史对比四份文件，并通过静态首页统一检索。 ## 开发历程 OS-Agent 的技术路线并非预先设定的单一工作流，而是在真实作品分析和批量实验中逐步收敛。Git 历史记录了从 2026 年 1 月 28 日首个原型，到自研 Runtime、共享状态、MCP 与指纹实验，再到当前多 Agent 四文档方案的完整演进： ```text 分模块 ReAct 描述 → 自研 Agent Runtime 与题单 → 共享 Kernel Tree → Claude Code + MCP/Skill + 指纹 → 多 Agent 来源追溯与工作量分层 → 评测复现、语义逆向与四文档交付 ``` ### 阶段一：分模块 ReAct 描述（1 月下旬至 3 月） 该项目最早由出题人 邵志远 作为 操作系统原理课设 给出。 早期原型保存在 `QA-Agent-legacy`。首个版本使用 LangGraph 的 `create_react_agent` 和兼容 OpenAI API 的模型接口，将内核拆为启动、内存、进程、Trap、文件系统、设备、同步、多核、网络等 9–13 个技术模块，并加入概览、历史和总结章节。每个阶段由简单的 `tool_calls` 循环读取仓库，最终拼接为 Markdown 报告。仓库中仍保留 Starry Mix、Undefined-OS 等作品的分章节产物，说明这一路线已经完成过真实内核验证，而非停留在 Prompt 草案。 该阶段默认使用 DeepSeek V3.2，并尝试过 Qwen 3.5；开发记录显示主要使用 Antigravity 与 Gemini 3 辅助编码。实验首先证明了 LLM 能够分模块阅读教学型内核，但输出质量缺少稳定参照：Prompt 主要依据作者文档和少量样例迭代，容易复述声明；不同章节粒度不一致，接口、文件名或 syscall 注册也可能被误写成完整实现。此时尚未完成 thinking/CoT 兼容，对比任务也没有形成方法。添加了RAG也并没有提升效果，实测RAG模型还会有错误召回，对于小型仓库，RAG 不适用。为了让 ReAct Agent 工作，项目还需要自行维护读文件、目录遍历、Git 历史和报告写入等工具，而这些能力的覆盖面仍弱于通用 Bash 与代码搜索工具。 ### 阶段二：自研 Agent Runtime 与题单对比（3 月下旬至 5 月） 3 月 27 日的 V4.0 开始引入 Plan–Execute–Review。转向题单和 JSON 并非单纯的工程偏好：当时出题方提出产出应当可复现、结构化，项目据此将“可复现”理解为固定问题、固定输入范围、保存中间状态并允许重复执行，将“结构化”落实为可由程序检查和比较的 JSON 答案。4 月 14 日的 `5258d2a` 正式改为 QA + JSON，4 月 16 日的 `23320d7` 继续强化输出规范和解析约束；随后经历 Review 移除与恢复，并在 5 月 13 日进入 Multi-Agent 实现。 最终管线包含 Plan Agent、Task Builder、并行 Task ReAct Agent、Evidence Verifier、Stage Assembler、Review Agent、事件日志和断点状态。Plan 将一个模块的多个 question 组合成 Task，Task Agent 查找证据，Verifier 校验路径、行号和负向搜索，Review 再根据证据支撑情况提出修正任务。代码中保留的 8 个技术域题单共 201 个问题，覆盖选择、填空和简答等答案形态。计划、原始回答、解析结果、错误记录、任务状态、事件和 Evidence 都分别保存为 JSON，使一次分析可以追踪和恢复；这一结构化思路后来又延续到 Kernel Tree、`report.json` 和 MCP 阶段的大型数据契约，因此项目在较长时间内都以 JSON 作为主要中间产物。 这套 Harness 确实提高了流程可追踪性和格式层面的可复现性，却没有解决作品比较的核心问题。两件作品都回答“实现了 mmap”或“未实现 futex”，并不能说明 VMA、缺页、回写或同步路径是否相同；简答结果受模型随机性影响，继续增加 JSON 字段又会把注意力转移到格式。5 月 28 日虽然一次压缩了超过 1.4 万行题单定义，格式负担仍未消失。与此同时，项目必须自行处理HTTP服务、模型api字段的接口字段差异、LLM输出的JSON 修复、工具权限、并发池、LSP/RAG 串行锁、超时恢复、事件面板和 HTML 渲染。测试时发现直接让 Claude Code 或 Codex 按同一要求阅读代码时回答，能够以更少的 Runtime 开发获得更好的工具覆盖和输出稳定性，因此继续自研通用 Agent Runtime 的投入已偏离赛题核心。 该阶段主要使用 Cursor 与 Composer 1.5/2 辅助开发。 ### 阶段三：共享 Kernel Tree 与全局状态（6 月上旬） 新分支初期尝试以 Kernel Tree 表达内核知识：按照从构建、启动、内存、Trap、进程到文件系统、设备和用户 ABI 的实现依赖组织约 20 个分析批次，并把已经确认的节点、Claim 和证据写入全局状态，期望前序结果能够帮助后续模块和批次。设计思路接近人类构造内核时的依赖顺序，也为异步、并行分析提供了统一坐标。 实际实现很快暴露出状态模型的代价。多个 Agent 需要协调文件写入、锁、失效传播和并发上限；更关键的是，来源和工作量结论会因新候选、新提交或外部依赖证据而被推翻，早期误判一旦进入共享树就会成为后续角色的错误先验。该方案存在时间很短，项目没有继续扩张全局知识树，而是转向“小产物、窄角色、必要信息交接”。 这一阶段主要使用 Cladue Code (Sonnet 4.6) 来设计。 ### 阶段四：Claude Code、MCP/Skill 与指纹辅助（6 月至 7 月中旬） 6 月 7 日的无父提交 `0a358da` 建立了新的 `os-agent-v2` 分支，并首次引入 `core/code_atlas/` 与 `tools/code_atlas/`。初版 `code_atlas` 使用 Tree-sitter 扫描全仓源码，对函数生成 normalized Token 与 AST shape hash，提取字面量和调用边，解析跨文件调用关系并计算 PageRank，最后汇总为大型 `code_atlas.json`。它把函数事实、结构指纹和调用图放进同一套重型数据模型；随后来源分析、Comparison、Scope、Evidence 和报告契约继续围绕这套模型扩展，逐渐形成较高的维护成本。 6 月 10 日的 `5e1e66e` 没有为查重另建轻量提取器，而是让 `scripts/fingerprint.py` 直接调用 `build_code_atlas()`，从完整 Atlas 再派生 normalized Token、AST shape 和汇编指纹。后续版本还会为同一 commit 分别保存完整 Atlas、函数单元、Token 集合、AST 集合和元数据；再叠加不可变源码快照与多分支构建，同一批事实以不同形式重复落盘。`code_atlas` 因此不仅是早期导航工具，也是后来指纹建库速度慢、内存占用高和缓存体积膨胀的重要结构性原因。 项目同时转向 Claude Code，由 Skill 注入操作系统分析经验。首版 `mcp_server.py` 也随 `5e1e66e` 引入，除候选检索和来源归属外，还提供 `unit_source`、`grep_repo` 和 `list_dir`，最初设想是让 Claude Code 通过项目 MCP 完成源码读取、搜索和目录浏览，而不是直接使用原生 Read、Grep、Glob 与 Bash。项目很快删除了一批可由 Bash 替代的接口，但后续 MCP 又继续承载不可变快照、Scope、Comparison、Evidence、报告、CodeAtlas 和 LSP，最终演变为庞大的中间层。对已知继承关系的 xv6 系作品进行复核后还发现，旧题单虽然较容易给出“实现、桩实现、未实现”等可重复答案，却不能展示代码从何处继承、具体改了什么。项目因此将描述与比较合并为同一分析过程，并使用 Git Blob、AST shape 和 normalized Token 三类信号辅助缩小阅读范围。 normalized Token 原本用于识别改名、拆函数等规避式改写，但大规模实验中表现出明显局限：变量归一化顺序和局部重排会造成指纹偏移，缓存和比较开销也高于预期，部分应命中的结构改写反而无法稳定检出。旧架构内的建库和比对先后经历三次调整： - 6 月 11 日的 `a6a3104` 将缓存改为分支感知，并预建所有分支的指纹。它解决了只比较当前 HEAD 导致的历史版本遗漏，但缓存文件一度增长到 484 份。 - 6 月 26 日的 `edec1b1` 停止在缓存中复制完整源码快照，改为直接读取 Git commit object，只保留 Atlas、函数单元和指纹集合等派生数据，降低了第一轮空间开销。 - 7 月 5 日的 `3e6da75` 删除 normalized Token/MiniHash，将完全相同内容交给 Git Blob hash，AST shape 仅用于改名、拆分和合并等结构变化；7 月 15 日的 `e6cdce0` 随后彻底移除旧 `code_atlas` 实现。 截至 6 月底，无参数执行 `python scripts/run.py --build` 仍会为每个仓库的所有可见分支建立指纹。这里的“所有分支”准确指本地分支及主远端分支所指向的唯一 tip commit，多个分支指向同一 commit 时只构建一次，并不遍历全部历史提交。即便如此，在仓库和分支数量增长后，完整 AST 缓存仍然庞大。 这条路线增加了进程通信、环境依赖和阻塞点，也让 Agent 的阅读过程受制于项目自定义接口。对 140 件初赛作品的批量实验进一步表明，Claude Code 原生工具更适合开放式源码调查，确定性 Git/指纹操作则适合作为 Skill 调用的窄脚本；复杂判断仍应留给 Agent。大 JSON 契约还会诱发模板化填充、字段遗漏和繁重校验，配套 HTML 也难以形成便于评委阅读的表达。该阶段使用 Antigravity (Gemini 3.5 Flash) + Codex(GPT 5.5) + Claude Code (DeepSeek V4)辅助实现。 ### 阶段五：多 Agent 来源追溯与工作量分层（7 月上旬至 8 月初） 7 月 9 日起，单一大型 Skill 被拆为来源、模块、历史、测评风险、历史对比、摘要和矛盾确认等窄职责角色。Python 脚本 不再代替 Agent 判断“原创”或“抄袭”，只负责 Git/指纹事实、缓存、永久链接、轻量格式校验和发布。角色按需读取短材料，模块分析可以并行；来源结论先确定，再向模块和历史角色交接版本、路径和开发阶段，降低长上下文造成的注意力稀释、角色越界和套话填充。 真实误判促成了 commit 级来源追溯。曾有两件同届作品都在一次大规模提交中导入 RocketOS 的早期快照，仅比较各自 HEAD 与 RocketOS 当前 HEAD 时，会把共同历史来源误判为同届传播；另一些作品共同引入 lwext4 等外部模块，第三方重合甚至高于内核主体 Base。系统由此形成“HEAD 只负责召回候选，目标侧定位首次大规模出现，来源侧搜索全部 refs，最终确认目标引入 commit 与来源历史 commit”的两阶段方法。同届候选还需分别追溯共同来源，扣除共同 Base、第三方、测试与生成物后，再判断剩余代码的传播方向。 同一时期形成了真实工作量分层方法论：来源关系、最近历史比较对象和工作量起点不再混为一谈。精确 Base 可从引入快照观察后续改造；来源版本不唯一时使用等价快照或仓库内部早期状态；无可靠 Base 的作品仍根据最终机制和可见历史评价其设计。项目也在提交记录和源码中发现过自述 hard code、成功存根和结果伪造线索，因而增加独立的测评风险角色。面向 2026 决赛材料的阶段分析曾作为条件上下文加入 Prompt，这一实验保留了“按比赛阶段区分实质更新与表面修改”的方法，但没有把年度规则写进通用来源算法。 旧 `code_atlas` 被拆除后，建库和比对又经历了四轮重建与修正： - 7 月 12–14 日的 `422a03c` 和 `1866213` 建立当前 `fp_cache///` 方向，Blob 由集合改为保留完整路径和重复出现次数的 occurrence 列表，AST 只保存函数结构单元；同时加入按需历史 Blob 缓存、全 refs 对象召回和显式 commit 对比较，避免路径被抹去后覆盖同名文件。 - 7 月 21 日的 `e780ec7` 将比较升级为带双方 `ref@commit` 的 commit pair，并让 include/exclude 路径范围同时作用于 Blob 和 AST。来源角色可以先排除第三方、测试和生成物，再比较目标引入提交与来源历史提交；程序还会检查 commit 是否可从所声明 ref 到达。 - 7 月 29 日的 `9f38eb8` 增加进程锁、临时文件与原子替换，防止并行建库破坏 JSON；Blob-only 历史操作会复用有效 AST，不再误删、降级或把旧 AST 标成当前版本。这一轮主要修正缓存一致性，而不是改变相似度公式。 - 8 月 2 日的 `570ffab` 才集中优化当前实现的速度和体积：删除未被比较消费的 AST 字段并改用紧凑 JSON；每个 commit 只枚举一次 Git tree，同一 Git object 只读取一次并分批调用 `git cat-file`；加入并行建库和有效缓存复用；为每个 HEAD 生成只含 hash 计数的 `recall.json`，全库排列时不再加载完整 Blob/AST。来源 Agent 选出 3–5 个候选后才展开 Blob 路径，AST 只在少量 commit 对需要识别结构改写时按需使用。 当前 `fp_cache` 只预建 `works.yaml` 中每件作品锁定评审分支的 HEAD，历史版本按来源追溯需要单独缓存；HEAD 排列同时保留整仓相近度、目标覆盖率和候选包含率，不再沿用 6 月底的全分支默认策略，也不让单一相似度直接决定来源。 该阶段通过对一些明显有AI痕迹的作品进行调查，找到能判断AI参与生成代码的信号：注释所占行数的比例变化（找到AI参与的起点）、注释的整齐程度和格式（LLM风格）、初始形态的大小。 该阶段使用 Codex (GPT 5.6) + Claude Code (DeepSeek V4) ### 阶段六：评测复现、语义逆向与四文档交付（8 月 2 日起） 8 月 2 日收到 Proj18 决赛交付要求后，项目开始压缩产物和角色输出。原有完整单作品网页虽然信息量大，却要求维护 Evidence 对象、JSON view model、前端章节映射和多层导航，评委仍需在重复文本中寻找结论。当前方案保留内部复杂推理，但将公开结果收敛为一页摘要、作品描述、开发过程和历史对比四份文件；专业角色直接撰写自己的最终段落，首页只负责批量搜索和提供文件下载。 8 月 8–9 日，本地评测复现从高分异常样本进一步追到 runner、judge 和内核源码。在所调查的多支高分作品中，项目观察到预录或合成结果、重复计分、BPF/eBPF 测例形态特化、假对象、虚构环境、用例替换和结果传播改写等具体手法。由此形成的语义逆向分析不再依赖字符串命中，而是沿五个方向闭合事实：输入或测试身份、真实执行路径、内核状态副作用、资源生命周期以及结果如何到达判分端。普通缺陷、诚实返回 `ENOSYS` 和针对真实瓶颈形成的通用优化不会直接归入测评定向；证据链或实际判分影响不完整时，只提示评委复核。 这些经验已经被压缩进 `module-reviewer` 的九份动态模块指南和 `risk-reviewer` 的风险指南：模块审查先核对机制的真实数据来源、消费方、状态维护和通用输入语义，风险审查再负责触发条件、可达性、上游归属和结果影响的定性。项目同时整理官方 runner、judge、镜像、测试盘和日志目录，使本地复现材料与静态源码结论能够对应，但不把本地结果冒充官方成绩。至此，OS-Agent 的工程重点从“实现更多 Agent 基础设施”转回赛题本身：准确说明内核设计、恢复来源演进、划分真实工作量，并以最短路径交付评委可复核的结论。 8月 11-12日，2026届一批以 StarryOS 为Base的案例进一步表明：当排名信息被外部crates污染时，可能会误导推理能力差的Agent，Agent判定的结论可能开始瞎猜去读了Cargo.toml `repository`，但是真实Base（github@Starry-OS/StarryOS）当时就在召回并集内却从未被展开。这是因为引入的base版本不是HEAD导致的偏移，还加上巨量crates污染了排名。判定Base原有流程出现漏洞；声明候选应该沿共享 commit 哈希与 moved-to 公告上溯宿主；同届 fork 仓库只作见证不作来源；对比报告是判 base 的对外载体：比较对象为 base@与待评价作品初始状态/当前形态的起点状态最接近的 commit，报告按共享基线/目标独有/base 独有三块呈现，并且细化的统计口径的表述，独有部分才是工作量归属对象。 报告语言自然化：Agent的统一语言指南规定正文只写结论与证据，禁止内部流程词（判 base、骨架、见证、宿主、档案、scope、命令原文等）进入公开报告；来源与比较段按示范句直接写自然语言表述（如“作品主体代码来自《StarryOS》”“比较对象取本地保存的《XX》上游 2021-05-09 完整副本”）；术语首次出现给出中文解释，内部指标首此出现一句话说明口径，不写“局部/实质/重写”等评委无法复核的档位标签。语言由中文负责主体语义，Agent语义复核：不能出现中文作为英文的胶水（现在的推理/Code/MATH模型的语言风格）的情况。 ## 项目结构 ```text README.md 项目能力、环境准备和完整使用方法 LICENSE 项目许可证 requirements.txt Python 运行依赖 config/works.yaml 作品身份、仓库位置和评审分支 data/ 人工整理的历届、2026 初赛和决赛作品 CSV repos/ 被分析作品与来源候选仓库，不提交 fp_cache/// HEAD 与按需历史版本的 Blob/AST/recall 缓存 .claude/settings.json Claude Code 权限与三层 Agent 配置 .claude/skills/os-agent/ 批次主 Agent 的 Skill 入口 .claude/agents/ 六个 callable role Prompt .claude/guides/ 按 job 动态加载的模块、风险、报告领域指南 .claude/architecture/ 非运行时的能力迁移映射 core/git_source.py 锁定 commit 的 Git tree 与 object 读取 core/review_case/ 指纹、比较、文档契约、校验和发布实现 scripts/review.py Agent 使用的统一确定性脚本入口 scripts/clone-works-repos.py 按 works.yaml 批量克隆规范仓库 output// 单件分析目录、内部材料和四份公开文件 output/site/ 可直接部署的批量静态首页与报告文件 review_viewer/src/ 批量首页的 Vite React 源码 review_viewer/dist/ 受 Git 跟踪的预构建首页 oscomp-eval/ 本地 runner、testsuite、镜像和测试盘，不提交 oscomp-eval/data/ 测评脚本的配置和官方 Sdcard image，不提交 测评工作/ 评测复现、违规边界和语义逆向研究记录 doc/competition/ 官方规则和赛题规则的可读摘要 doc/design/设计书.tex 设计书 LaTeX 源码，不属于 Agent 运行依赖 doc/design/设计书.pdf 编译后的设计书 26_final_draft.md 2026 届决赛队伍来源与 AI 信号调查方法验证(仅供参考) OS-Agent-项目汇报.pptx 项目汇报ppt ``` 仓库跟踪 `repos/`、`fp_cache/` 和 `output/` 的空目录标记，便于新机器恢复布局；目录中的克隆、缓存和报告仍由 `.gitignore` 排除。`oscomp-eval/` 由评测环境准备步骤创建，其中的 runner、可选 testsuite 源码、镜像、测试盘和临时日志均不提交。OS-Agent 不改写官方 runner 的输出位置；作品负责 Agent 只消费本次调用明确提供、且能够对应锁定 commit 和实际命令的文件。 `config/works.yaml` 和 `data/` 是人工维护且受 Git 跟踪的数据。前者是 Agent 读取作品身份、规范目录、原始仓库和评审分支的唯一入口；后者保存原始汇总表，不能代替 `works.yaml`。当前数据文件为： - `data/含26初赛历年汇总.csv`：包含 2026 初赛作品的历年作品汇总。 - `data/2026OS内核初赛提交情况.csv`：2026 初赛队伍编号与提交情况。 - `data/初赛排行榜2026.csv`：2026 初赛排行榜整理结果。来源：https://course.educg.net/pages/contest/contest_rank.jsp?contestID=Z7zWWwTfti0&taskID=9787459 - `data/含26决赛版repo汇总.csv`：包含 2026 决赛仓库选择和人工核对字段（kernel name）的汇总。 CSV 统一使用 UTF-8 BOM、CRLF 和 RFC 4180 引号规则，兼顾 Git 文本处理和 Excel 打开。身份或仓库信息修正后，应同时更新相关 CSV 与 `config/works.yaml`，并将二者一起提交。 ## 公开产物 每件作品只发布四个文件： ```text output//public/ summary.pdf 一页评审摘要 description.md 内核结构与九个核心模块描述 development.md 开发过程、工作量演进与 AI 使用记录 comparison.md 与一个最近历史作品的对比分析 ``` `summary.pdf` 用于快速浏览；三份 Markdown 保留可复核的路径、行号、commit 和永久链接。项目不生成单作品网页。批量首页只提供搜索、筛选和四份文件的下载入口，不复制报告正文。 分析目录中的以下文件用于角色协作，不公开发布： ```text source.md 来源、版本精度与比较对象 description-intro.md 描述报告的总览和结构表 summary.md 一页摘要的受限源稿 risk.md 测评适配、规则模式与结果真实性分析 modules/*.md 九个核心模块和动态模块片段 case_state/facts/ 候选、等价快照和唯一统计事实 case_state/timings.json 阶段墙钟时间与重试次数 ``` ## 分析流程 ```text 紧凑 HEAD 召回 → 骨架形态判定与骨架召回（baseline-recall，判 base 的主要依据） → 来源定位与等价快照搜索 → 编译验证（compile-only，官方镜像内仅 make） → snapshot-diff 生成唯一 Base→HEAD 统计并通过来源预检 → 九个核心模块与开发报告并行 → 风险报告与历史对比并行（pair-breakdown 分层目标独有） → 组装作品描述 → 撰写一页摘要源稿 → 确定性 preflight → 最终语义复核 → 必要时一次定向返工后复核 → 渲染摘要 PDF 与 check-all → 批量首页索引 ``` `lineage-reviewer` 首先区分两类对象： - `primary_source`：作品的真实主体来源，可以不存在，也可能只能定位到分支、版本范围或等价快照。 - `comparison_target`：对比报告的呈现对象，锁定为 `primary_source` 本身（真实来源）在与目标起点（引入时快照/骨架形态）最接近的 `ref@commit` 版本——对比报告呈现“作品相对基座的差异”，目标独有部分才是本队工作量的归属对象。只有来源确实无法定位、或作品从零搭建/Vibe Coding 时，才退而选择指纹库中最相似的作品作比较对象，并在报告中声明“比较对象为最相似作品而非来源，来源不明确”。 当来源能够精确定位时，系统继续追溯“目标引入 commit ↔ 来源历史 commit”，说明继承范围和后续改造；当作品没有可靠 Base 或表现为从零构造、Vibe Coding 时，仍描述最终设计，并与最相似作品比较，但会在报告中声明比较对象不是来源。 九个核心模块为： 1. 体系结构、启动、Trap 与上下文切换 2. 进程、线程与调度 3. 虚拟内存与地址变换 4. 文件系统与文件描述符 5. IPC、I/O 与事件机制 6. 并发同步与资源生命周期 7. 设备、块 I/O 与平台适配 8. Linux ABI 与用户程序兼容 9. 网络栈 高级调度、slab、futex、Ext4 journal、DMA、零拷贝等归入所属核心模块。九个核心模块固定分为六个 `module-reviewer` 调用：architecture-boot；memory-management；process-management + synchronization；file-system + ipc-io-event；device-driver + network-stack；user-abi-compat。Lead 必须在同一条消息中把这六个调用与 development 一次性并列派发，不能逐组等待。跨模块且能够体现作品设计特征的机制可作为 0–2 个独立动态 job；来源阶段已经识别时优先放进单 job 调用的空余名额。每次调用最多两个 job，九个核心模块始终各自保留独立正文。缺失模块仍保留一行结论，使报告边界明确，但不补写操作系统背景知识。 ## Agent 与脚本边界 OS-Agent 采用“批次主 Agent → 作品负责 Agent → 六个 callable roles”的三层组织方式。角色 Prompt 保持短小，模块、风险、统一语言和最终语义复核要求仅在对应 job 动态加载。 | 层次 | 责任 | |---|---| | 人工 | 维护作品身份、原始仓库、评审分支，复核需要平台日志或纪律判断的问题 | | 批次主 Agent | 选择作品、控制批量并发、监督失败并构建首页 | | `work-review-lead` | 锁定单件作品版本，组织六个 callable roles、阶段门和最终语义复核 | | `lineage-reviewer` | 以 source/development mode 分别写来源与开发过程；无可靠 base 时不设比较对象 | | `comparison-reviewer` | 产出唯一历史对比：有 base 渲染 source.md 锁定对象，无 base 按赛题要求兜底选最相似作品（剔除第三方后 AST 最相似，closest_only） | | `module-reviewer` | 每次只审查 1–2 个独立模块 job；九个核心模块不合并，动态模块最多 2 个 | | `risk-reviewer` | 只写测评适配、测例定向和结果真实性风险 | | `report-editor` | 每次只写描述导语或摘要中的一个 job | | Python 脚本 | 独占生成 Git 路径、源码文本增删行、Blob/AST 与等价快照事实；检查格式和跨文档契约，拼装描述、记录耗时、渲染 PDF 和发布索引 | Python 不自动选择 Base，不根据关键词判定抄袭、工作量或违规，也不改写 Agent 的技术结论。来源角色先声明互不重叠的统计范围，脚本再按范围生成事实；Agent 不得另用 Git 手工重算。Markdown 中的事实依据直接使用规范路径、行号、commit 和 GitHub/GitLab 永久链接，避免额外编号和证据数据库增加写作负担。 四类口径严格分开：语义功能只按真实入口、状态变化、失败路径和资源闭环定性；代码量只称“源码文件文本增删行”；文件量按 Git 跟踪路径统计并单列 manifest、lock 与补丁残件；Blob 内容实例、同路径实例、双方覆盖率和 AST 单元分别报告，不能合成“总体抄袭比例”。规模账只出现在开发报告，相似度只出现在对比报告，摘要和作品描述只保留语义结论。 ## 调查工作文档 `测评工作/` 保存初赛作品复现、LTP 环境、语义真实性检查和已知案例。入口见 [测评工作/README.md](测评工作/README.md)。案例中的队伍、分数和环境数值不会整体注入 Agent Prompt；活动 Prompt 只保留数据来源、资源生命周期、状态副作用、身份分流和结果传播等通用检查方法。 `doc/competition/` 保存从 [OS2026 官方材料仓库](https://gitlab.eduxiji.net/csc1/csc-os/os2026) 提炼的规则摘要，当前锁定 `main@05d645f8f6d0aa1be131f4e6f1d25b4eb83664f0`。原始 PDF 只作为本地核对材料，不进入 Agent 上下文或 Git；规则变化时由人工更新摘要。 ## 环境准备 推荐 Linux 或 WSL。项目使用当前终端 `PATH` 中的 Python，不依赖个人目录、固定 Conda 环境名或特定发行版。先选择 Python 环境并安装依赖，再从同一终端启动 Claude Code： ```bash command -v python python -m pip install -r requirements.txt python -c "import yaml, pypdf, tree_sitter" claude --version ``` Conda、venv 和系统 Python 均可。关键是 `python`、安装依赖时的解释器和 Claude Code sub-agent 继承的 `PATH` 一致。系统还需要 `git` 和 `rg`。 一页摘要 PDF 由 **report-editor 亲手编辑 xelatex 模板**产出：复制 `core/review_case/templates/summary.tex` 到 `case_state/summary-render/summary.tex`，自行填写内容与美化样式并用 `xelatex` 编译；`python scripts/review.py render-summary --case-dir …` 仅作验收兜底（编译 Agent 写的 tex、校验恰好一页且无超链接、写 `tags.json` 与渲染记录，不生成任何 tex 内容）。项目固定使用 `Noto Sans CJK SC`，运行前需保证 `xelatex` 与中文字体可从当前环境发现。 `doc/design/设计书.tex` 是参赛设计文档源码，重新生成同目录的 `设计书.pdf` 时才需要 XeLaTeX/CTeX；它不属于 OS-Agent 分析或摘要生成环境。 Debian/Ubuntu 安装 TeX Live（xelatex 与常用宏包）与中文字体： ```bash sudo apt update sudo apt install -y texlive-xetex texlive-lang-chinese \ texlive-latex-extra texlive-fonts-recommended \ fonts-noto-cjk lmodern ``` Arch Linux： ```bash sudo pacman -S --needed texlive-xetex texlive-langchinese noto-fonts-cjk ``` 安装后统一检查： ```bash xelatex --version fc-list :lang=zh family | rg 'Noto Sans CJK SC' ``` 摘要超过一页、缺少中文字体或包含 PDF 超链接时，`render-summary` 会失败并要求修正环境或由摘要角色缩写。 Claude Code 按官方方式安装： ```bash curl -fsSL https://claude.ai/install.sh | bash claude doctor ``` ## 可选编译与评测环境 源码来源和模块描述不依赖 Docker；只有需要确认作品能否构建、某条运行路径是否真实触发或 judge 如何消费结果时，作品负责 Agent 才组织本地复现。专业角色不直接启动容器。作者自测、OS-Agent 本地复现和官方平台结果必须分开记录。 ### 1. 安装 Docker 与基础工具 Ubuntu： ```bash sudo apt update sudo apt install -y docker.io docker-compose-v2 git curl wget gzip xz-utils zip sudo systemctl enable --now docker ``` Arch Linux： ```bash sudo pacman -S --needed docker docker-compose git curl wget gzip xz zip sudo systemctl enable --now docker ``` 可选地将当前用户加入 `docker` 组，重新登录后生效： ```bash sudo usermod -aG docker "$USER" docker run --rm hello-world ``` 如果不调整用户组，后续 Docker 命令使用 `sudo`。不要把密码、Docker socket 或宿主设备权限写入 Agent Prompt。 ### 2. 准备锁定的评测资产 `oscomp-eval/` 是官方 runner 和本地运行材料的唯一目录，`repos/` 不重复保存评测仓库。执行已发布的测试盘只需要 `autotest-for-oskernel`，不需要克隆 `testsuits-for-oskernel` 源码： ```bash mkdir -p oscomp-eval/data git clone --depth 1 --single-branch --branch main \ https://github.com/oscomp/autotest-for-oskernel.git \ oscomp-eval/autotest-for-oskernel ``` 本地运行步骤以 [autotest-for-oskernel 官方 README](https://github.com/oscomp/autotest-for-oskernel#readme) 为准；克隆后也可直接阅读 `oscomp-eval/autotest-for-oskernel/README.md`。下文使用的 Docker image、judge scripts、两张发布版 SD card image、`kernel.zip` 打包方式和 Docker 调用方式均来自该官方说明，OS-Agent 只统一本地目录和运行材料留存方式。每轮复现开始前记录 runner 的 `ref@commit`，分析过程中不自动更新。 当前已验证研究环境使用官方构建镜像 `zhouzhouyi/os-contest:20260510`： ```bash docker pull zhouzhouyi/os-contest:20260510 docker image inspect zhouzhouyi/os-contest:20260510 --format '{{.Id}}' ``` 镜像构建源为 。镜像约占数十 GB 磁盘；tag 和 image ID 都要随运行材料记录。后续批次出现新镜像时，不得继续沿用旧 tag 并声称复现了新平台。 初赛测试盘来自 `testsuits-for-oskernel` 的 `pre-20250615` Release。发布文件是 `.img.xz`；官方 runner 默认读取 `.img.gz`，因此下载后需要先解压，再压缩为 gzip： ```bash cd oscomp-eval/data wget https://github.com/oscomp/testsuits-for-oskernel/releases/download/pre-20250615/sdcard-rv.img.xz wget https://github.com/oscomp/testsuits-for-oskernel/releases/download/pre-20250615/sdcard-la.img.xz unxz sdcard-rv.img.xz unxz sdcard-la.img.xz gzip -f sdcard-rv.img gzip -f sdcard-la.img ``` 准备完成后，测试盘应为： ```text oscomp-eval/data/ sdcard-rv.img.gz sdcard-la.img.gz ``` 当前本地这两张镜像已经完成 `.xz → raw image → .img.gz` 转换，runner 会在运行时解压并作为 raw SD card image 挂载，不需要长期保留解压后的 `.img`。还需按官方 README 将 `kernel/judge/` 复制到 `data/`，并将 runner 的 Python `kernel/` 目录打包为 `kernel.zip`： ```bash cp -rf oscomp-eval/autotest-for-oskernel/kernel/judge/* oscomp-eval/data/ ( cd oscomp-eval/autotest-for-oskernel/kernel zip ../kernel.zip -r . ) ``` 这里的 `kernel.zip` 是评测 runner，不是被测操作系统内核。修改本地 judge 分支后必须重新打包。当前 runner 还会读取测试数据目录中的 `config.json`；该文件由 runner 实现和本次本地配置决定，不属于官方 README 中上述下载步骤。完整目录、配置和故障处理见 [测评工作/01-评测用法.md](测评工作/01-评测用法.md)，LTP 口径见 [测评工作/05-LTP基准跑方法.md](测评工作/05-LTP基准跑方法.md)。 只有需要阅读测例源码、重新编译测试程序或自行生成 SD card image 时，才额外克隆 `testsuits-for-oskernel`；直接运行上述发布镜像不依赖该 clone： ```bash git clone --depth 1 --single-branch --branch pre-2025 \ https://github.com/oscomp/testsuits-for-oskernel.git \ oscomp-eval/testsuits-for-oskernel ``` `pre-2025` 只是当前初赛复现材料对应的分支，不是永久默认值。更换比赛批次时，应依据当期官方说明重新确认 runner、测试盘、judge 和测试源码分支。 ### 3. 运行与实际输出 先在目标作品锁定 commit 上执行官方 runner。下面的变量都应使用绝对路径，以便 Docker bind mount；它们只存在于运行命令，不写入项目配置： ```bash OS_REPO="$(realpath repos/<作品目录>)" EVAL_ROOT="$(realpath oscomp-eval)" docker run --rm \ -v "$OS_REPO:/coursegrader/submit" \ -v "$EVAL_ROOT/data:/coursegrader/testdata" \ -v "$EVAL_ROOT/autotest-for-oskernel:/cg" \ -v "$EVAL_ROOT/data:/mnt/cghook" \ zhouzhouyi/os-contest:20260510 \ python3 /cg/kernel.zip ``` 作品构建脚本确实需要 loop mount 时，普通容器可能因权限失败；确认失败点后才为该次隔离运行增加 `--privileged`，并在运行记录中注明。不要把特权模式作为所有作品的默认配置。 官方 runner 不接受 OS-Agent 自定义输出目录。其实际写入位置为： ```text 作品仓库/ kernel-rv、kernel-la、可选磁盘镜像 make all 的构建产物 os_serial_out_rv.txt RISC-V 串口输出 os_serial_out_la.txt LoongArch 串口输出 oscomp-eval/data/console_log runner 运行期间反复覆盖的临时输出 Docker stdout 完整判分输出 ``` 官方流程不生成 `judge.log` 或 OS-Agent 专用的 `result.json`。需要保留完整判分结果时，由操作者在运行命令外层显式保存 Docker stdout；本仓库现有的 `oscomp-eval/first-eval.log` 就是一次人工保存的结果。`data/console_log` 会在运行阶段和重跑时被覆盖，不能默认视为长期材料。 Docker 本身可以启动多个容器，但当前 runner 不适合并发评测多件作品：每个容器内部已经同时启动 RISC-V 与 LoongArch 两个 QEMU，多个容器还会共同写入同一个 `oscomp-eval/data/console_log`。因此 Blob/AST 建库、源码阅读和专业角色可以并发，完整 Docker/QEMU/judge 复现必须全局串行。若未来为每次执行准备独立 data 目录并重新评估 CPU、内存和磁盘压力，再单独放开运行并发。 ## 准备作品和指纹库 作品和历史参考仓库由人工登记在 `config/works.yaml`，并 clone 到各自 `canonical_dir`。公开文本只能使用 `display_name`，不能使用平台 fork 编号或机器目录名。 建立所有登记作品的 HEAD Blob/AST 指纹： ```bash python scripts/review.py build-fp-cache python scripts/review.py build-fp-cache --jobs 4 ``` 正式分析前直接对全部登记作品执行一次即可；已有且 commit 未变化的缓存会快速复用。指纹缓存保留每个 Blob 的完整路径实例和函数级 AST shape。`recall.json` 只保存紧凑计数，用于快速排列全部 HEAD 候选；完整路径详情不会在第一轮被批量加载。 来源调查采用按需展开： ```bash # 轻量排列全部 HEAD 候选 python scripts/review.py search-head-candidates \ --case-dir output/ \ --top-k-per-view 30 --expand-depth 2 # Agent 综合三种排名、作者声明、目录和 Git 历史后选择 3–5 个候选 python scripts/review.py search-head-candidates \ --case-dir output/ \ --top-k-per-view 30 --expand-depth 2 \ --expand-work-id \ --expand-work-id \ --expand-work-id ``` 每种排名只返回前 30 名的并集，并标记候选总数与截断状态；展开阶段只生成一级、二级目录聚合，用于区分内核主体、公共框架、第三方组件、测试和生成物。HEAD 排名只作兜底线索：判 base 的主要依据是**骨架形态判定与骨架召回**——来源角色先按作者身份变化点和离当前版本最近的基座状态判定作品的骨架（引入时快照），再对骨架建指纹与全部候选的 HEAD 与历史比较，回答“哪个仓库的 HEAD/历史装着我的骨架”： ```bash python scripts/review.py baseline-recall \ --case-dir output/ --skeleton-commit <骨架 commit> \ [--skeleton-prefix <骨架核心前缀>] ``` 随后 Agent 定位目标代码首次大规模出现的提交，并用确定性命令在来源仓库全部 refs 中搜索同路径、同 Blob 的等价快照： ```bash python scripts/review.py find-equivalent-snapshots \ --target-work --target-ref --target-commit \ --candidate-work \ --target-prefix --candidate-prefix \ --output output//case_state/facts/equivalent-.json ``` 来源角色锁定目标侧工作量 Base 并声明互不重叠的命名范围后，生成唯一 Base→HEAD 统计并执行来源预检： ```bash python scripts/review.py snapshot-diff --case-dir output/ python scripts/review.py preflight --case-dir output/ ``` `work-diff.json` 按命名范围保存完整计数及有界路径样本，并分类记录 Git 跟踪路径变化、源码文件文本增删行、manifest/lock、二进制与补丁残件；大型第三方导入不会再把数千条路径塞进 Agent 上下文。后续 Agent 只能引用，不能自行重算。来源关系还可对有意义的 commit 对执行过滤后的比较： ```bash python scripts/review.py compare-commits \ --left-work --left-ref --left-commit \ --right-work --right-ref --right-commit ``` 只有 Blob 无法解释的核心残差表现出系统性改名、移动或拆合文件时，才为最终 1–2 个 commit 对追加 `--ast`。同届高相似必须分别追溯共同历史来源，不能用 HEAD 排名直接判断传播方向。 ## 使用 Claude Code 分析 在仓库根目录启动 Claude Code，并使用自然语言入口： ```text /os-agent 重新分析作品： /os-agent 继续分析作品： /os-agent 重新分析作品并执行QEMU/judge： /os-agent 重新分析作品，结合测例/评分程序代码分析作弊情况： ``` 默认只进行静态分析，不编译、不启动 QEMU、不运行 judge，也不自动读取本地评测目录。只有用户明确要求 QEMU/judge 复现时，作品负责 Agent 才可使用本地评测环境；只有用户明确要求结合测例/评分程序代码分析作弊情况时，风险分析才从项目根目录已有的 `oscomp-eval/` 读取所需锁定文件，不要求用户提供路径，也不运行 QEMU。缺少这些材料不阻止静态报告。作者自测、OS-Agent 本地复现和官方平台结果始终分开表述。 编译与运行仍沿用上一节列出的官方输出位置。作品负责 Agent 在调用专业角色时，把需要读取的真实文件以绝对路径逐项放入 `allowed_materials`，同时说明其对应的作品、锁定 commit 和实际命令。它不会要求修改官方命令，也不会自动搬运产物或生成额外的运行清单。 只有操作者明确保存的 Docker stdout 才能作为完整判分日志；`data/console_log` 是会被覆盖的过程输出，无法确认与本次执行对应时不得用于报告。校验器只检查分析文档和公开产物结构，不验证一个官方 runner 并不存在的归档格式。 专业角色在需要固定源码或提交位置时调用永久链接命令： ```bash python scripts/review.py permalink source \ --work-id --commit \ --path --lines : python scripts/review.py permalink commit \ --work-id --commit ``` 单件流程使用的确定性命令如下： ```bash python scripts/review.py start --work-id python scripts/review.py mark-stage --case-dir output/ --stage source --event start python scripts/review.py fingerprint --case-dir output/ python scripts/review.py search-head-candidates --case-dir output/ --top-k-per-view 30 --expand-depth 2 python scripts/review.py baseline-recall --target-work --skeleton-commit --output output//case_state/facts/baseline_recall.json python scripts/review.py find-shared-commits --left-work --right-work --output output//case_state/facts/shared-commits.json python scripts/review.py locate-blob-commits --target-work --target-commit --candidate-work --output output//case_state/facts/locate-blob.json python scripts/review.py snapshot-diff --case-dir output/ python scripts/review.py preflight --case-dir output/ python scripts/review.py mark-stage --case-dir output/ --stage source --event finish --status success python scripts/review.py module-sim --case-dir output/ python scripts/review.py pair-breakdown --case-dir output/ python scripts/review.py assemble-description --case-dir output/ python scripts/review.py render-summary --case-dir output/ python scripts/review.py check-all --case-dir output/ ``` `start` 用于完整重做一件作品，锁定评审分支并重建该作品分析目录；继续分析时不执行 `start`。`fingerprint` 在紧凑候选召回前生成锁定 HEAD 的事实。`preflight` 在只有来源材料时充当来源门，在公开草稿完成后检查全部机械契约；`mark-stage` 只写内部耗时和重试记录。`assemble-description` 只按稳定顺序拼接总览、九个核心模块和实际动态模块，不改写正文。Lead 的最终语义复核不创建文件；若发现问题，只允许一次定向返工及其直接下游重生成，之后执行一次 `preflight` 和限定复核，仍未消除则该作品失败。随后 `render-summary` 生成恰好一页的中文 PDF。`check-all` 只检查四份公开文件、永久链接格式、来源关系、模块完整性和摘要页数，前后不修改 Agent 文案。 ## 批量首页与部署 单件作品通过后，构建批量首页： ```bash python scripts/review.py build-index \ --output output/site \ output/ output/ ``` 首页显示作品、一句话结论、最近来源或比较对象、技术亮点、中性的测评适配和需评委复核项，以及“下载摘要 PDF、下载作品描述、下载开发过程、下载对比分析”四个链接。适配说明与复核项使用不同样式，搜索和关注项筛选同时覆盖两者。 `output/site/` 是自包含的静态目录，可直接上传到任意静态文件服务器： ```text output/site/ index.html site_index.json assets/ reports// summary.pdf description.md development.md comparison.md ``` ## 结论边界 - Blob/AST 分数是候选线索，不是抄袭概率。 - 最近历史比较对象不等于真实来源；无可靠来源时必须明确二者区别。 - 同届方向需要共同来源排除、双方引入提交、来源作品连续开发历史和残差代码共同支持。 - 语义功能、Git 跟踪路径、源码文件文本增删行和 Blob/AST 相似度是四种不同口径；后三类只能由确定性脚本产生，也都不能直接代替实质工作判断。 - AI 参与只展示作者披露、提交标记、Agent 配置、日志和源码痕迹，不估算 AI 代码比例。 - 自定义入口、黑白名单、跳过、重试、日志过滤和分组默认属于测评适配；真实测例执行、结果来自自身输出且未经改写时不得仅凭入口或名单升级。测例特征分支需形成“身份/固定输入—可达特殊路径—通用语义短路—judge 可观察结果”的完整链；未运行真实测例却预录、合成、重复或改写结果才属于结果伪造。是否构成作弊、处分及测评影响由组委会认定。 - 静态源码可以说明机制是否存在和链路是否闭合，不能声称官方测试通过、实际性能达标或获得特定分数。 ## AI 使用与 Agent 协作说明 本项目在开发过程中使用 Claude Code、Codex，以及早期阶段使用的 Cursor、Antigravity 等 AI 编程工具；涉及的模型包括 GPT-5.5/5.6、DeepSeek V4、Sonnet 4.6 和 Gemini 3.5 Flash。AI 工具参与了大部分代码实现、环境配置、作品编译测试与 Debug，也用于处理重复性和大数据量工作、整理项目文档及讨论流程设计方案。 AI 主要承担候选方案生成、代码实现、机械性处理和辅助检查。团队在赛前设计问题拆分、Agent 职责边界、Skill 与 Prompt 的初始方法、查重与测评风险的定性边界、报告粒度和脚本功能取舍；现场单件报告由 Agent 与确定性脚本生成。LLM 负责整理、补充和实现，分析结论的最终赛事认定由组委会结合平台记录作出。 由于本项目研究对象本身是 Agent，AI 同时是开发工具和系统实现的一部分。开发过程中发现的来源误判、上下文稀释、模块描述粒度不足和测评行为理解偏差，会通过样本复核转化为角色 Prompt 和流程约束。组委会评审标准用于界定测评行为与规则模式的关系；自定义入口和名单等适配事实保持中性，对边缘手法或需要平台成绩、日志支持的影响只提交组委会复核，不由模型自行扩大为作弊或处分结论。 ## 官方参考材料 - [OSComp 内核测例 pre-2025分支](https://github.com/oscomp/testsuits-for-oskernel) - [OSComp 自动评测框架](https://github.com/oscomp/autotest-for-oskernel) - [OSComp 2026 评审标准与比赛要求材料](https://gitlab.eduxiji.net/csc1/csc-os/os2026) 需要核对 runner 或 judge 行为时，读取 `oscomp-eval/autotest-for-oskernel` 中锁定的 `ref@commit`；只有需要核对 workload 源码时才读取可选的 `oscomp-eval/testsuits-for-oskernel`。官方评测材料不加入 `works.yaml`，不建立指纹，也不作为内核来源候选。学生作品仓库中自带的测试脚本或 testsuite 属于作品内容，继续随作品分析，用于确认执行入口替换、测例特化和来源归属。