操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载本文以 linuxkit 仓库中随依赖 vendored 的 go.opentelemetry.io/otel/AGENTS.md 为骨架系统讲解 OpenTelemetry-Go 项目为自主与半自主编码代理coding agent制定的任务导向协作规范包括核心工程期望、默认开发工作流、make precommit验证体系、文档与 CHANGELOG 约定以及 Feature / Refactoring / Test / Performance / Review 五类 Agent 角色各自的行为契约。读者读完可以完整掌握一套可直接复用的AI 参与开源 Go 项目开发的过程纪律并理解它在 OpenTelemetry-Go 与 linuxkit 实际仓库中的落地方式。一、AGENTS.md 是什么一份为编码代理编写的任务导向指令与面向人类贡献者的 CONTRIBUTING.md介绍 SIG 会议、开发方式、make test与生成文件维护不同AGENTS.md 开宗明义地声明自己是面向在本仓库中工作的自主与半自主编码代理autonomous and semi-autonomous coding agents的、当前有效且任务导向active, task-oriented的指令文件。它要求代理在开始任何任务前先依次阅读三个文件.github/copilot-instructions.md——被当作全局被动指导global passive guidance适用于包括纯文档、纯评审在内的每一项任务CONTRIBUTING.md——人类与代理共同遵守的贡献规范AGENTS.md本身——任务执行的具体纪律。这份文件之所以存在是因为 OpenTelemetry-Go 是一个对规范合规spec compliance、API 稳定性和并发正确性要求极高的基础设施库代理如果按通用代码生成的习惯行事很容易引入破坏性 API 变更或宿主应用不可接受的遥测干扰。AGENTS.md 的作用就是把仓库的隐性工程文化显性化让代理在无需人类逐步监督的情况下也能保持与维护者一致的标准。在 linuxkit 仓库中该文件位于src/cmd/linuxkit/vendor/go.opentelemetry.io/otel/下属于 linuxkit 命令行工具依赖的 vendored 副本。从 src/cmd/linuxkit/go.mod 可见linuxkit 通过go.opentelemetry.io/contrib/instrumentation/.../otelgrpc、otelhttp等间接依赖引入go.opentelemetry.io/otel v1.44.0及其 OTLP 导出器、sdk、trace/metric 子包均标记为// indirect因此这份代理指南也随依赖一并进入仓库成为可本地查阅的一手工程资料。二、核心期望八条贯穿所有任务的工程底线AGENTS.md 用八条核心期望Core expectations为代理的所有行为划定边界它们既是代码评审的检查项也是代理自我约束的原则期望含义保持规范合规、API 稳定与地道 Go任何改动都不得违背 OpenTelemetry 规范、破坏公开 API 兼容性或偏离 Go 惯用法最小、外科手术式改动优先小范围精准修改拒绝大面积重构与顺手清理drive-by cleanup匹配所在包既有风格编辑前先读该包沿用其命名、选项类型、错误处理、注释、测试与并发模式公开 API 向后兼容除非任务明确要求破坏性变更否则保持向后兼容遥测弹性与低耦合不得引入会意外干扰宿主应用host application的行为仔细检查边界输入校验、资源限制、取消、关闭、错误传播、并发、内存增长都要逐一审视故障安全优于隐式假设偏好 fail-safe 行为与显式不变量invariant而非依赖隐含假设依赖最小化且有理有据新增依赖必须精简且有正当理由其中特别强调两条与宿主应用安全相关的硬性要求遥测不应 panic、不应无限阻塞、不应放大攻击者可控的输入同时要求热路径hot path上保持保守——避免不必要的分配allocation、反射、接口抖动interface churn、阻塞、全局状态以及高基数high-cardinality遥测。这些约束直接呼应了 OpenTelemetry-Go 作为嵌入到任意 Go 应用中的 SDK 的定位库代码的每次执行都发生在用户进程内任何失控行为都会直接传导给宿主。最后一条注释纪律也值得注意注释只写意图、不变量与非显而易见的约束禁止重复代码本身Do not add comments that restate the code——这与 docs/coding-style.md 中 linuxkit 自身强调的 Go 代码风格原则一脉相承。三、默认工作流从失败测试到提交前检查的七个步骤对于新功能与行为变更AGENTS.md 规定代理必须按以下顺序执行除非任务明确另有指示先读包阅读相关包、其测试、包文档或README.md先写失败测试新增或更新一个能捕获目标行为或回归的失败单元测试最小实现实现让测试通过的最小改动行为锁定后再重构且重构必须保持 diff 聚焦热路径基准若改动位于热路径或性能敏感代码检查既有 benchmark 并运行覆盖缺失则补充同步更新文档趁上下文还热时更新文档产物遵循下述文档与 CHANGELOG 约定make precommit每次认为工作完成前都必须运行。这本质上是一条测试驱动开发TDD 最小 diff 基准验证 文档同步的闭环流水线。对于纯文档、纯测试或纯评审类任务文件同样要求先阅读前述仓库指导然后跳过不适用的步骤但对范围控制、验证与仓库约定的纪律保持一致。一个值得注意的细节第 2 步与第 3 步的组合先失败测试、后最小实现在五类 Persona 中反复出现说明 OpenTelemetry-Go 把用测试钉住行为视为代理改动安全性的第一道保险——行为一旦被测试锁定后续任何重构或优化都有可验证的基准。四、验证体系make precommit与benchstatAGENTS.md 把make定义为仓库的权威验证命令canonical repository verification command默认目标是precommit并明确make precommit是预期的最终验证步骤覆盖 lint、代码生成、README 检查、模块检查与测试迭代过程中允许用针对性命令如单个包的go test快速反馈但只要改动涉及代码就不能止步于此触碰性能敏感代码时除make外还要运行聚焦基准并用benchstat对比结果。在 vendored 副本的 Makefile 中可以看到该目标的真实定义.DEFAULT_GOAL : precommit .PHONY: precommit ci precommit: generate toolchain-check license-check misspell go-mod-tidy golangci-lint-fix verify-readmes verify-mods test-default ci: generate toolchain-check license-check lint vanity-import-check verify-readmes verify-mods build test-default check-clean-work-tree test-coverage即一次make precommit实际串联了代码生成generate、Go 工具链版本检查toolchain-check、许可证头检查license-check、拼写检查misspell、go mod tidy校验go-mod-tidy、golangci-lint 自动修复golangci-lint-fix、README 校验verify-readmes基于internal/tools/verifyreadmes工具、多模块一致性校验verify-mods基于 multimod 工具以及默认测试集test-default。CI 目标ci则在其上再叠加 vanity import 检查、构建、工作树洁净检查与覆盖率测试。这些与 AGENTS.md 中生成文件必须入库、改动影响生成则保持生成产物最新的习惯相互印证。五、文档与 CHANGELOG 约定AGENTS.md 对文档产物提出了明确且可执行的规则非 internal、非测试的包应有 Go doc 注释通常写在doc.go中。vendored 副本的 doc.go 即典型范例它说明otel包提供 OpenTelemetry API 的全局访问入口默认情况下测得的遥测数据不被处理也不被传输需要由 SDK如go.opentelemetry.io/otel/sdk与 exporter 负责处理和传输并分别指引到 trace、metric、log、propagation/baggage 子包非 internal、非测试、非文档包还应提供README.md至少包含标题与pkg.go.dev徽章。vendored 的 README.md 展示了完整形态项目状态表中 Traces 与 Metrics 为Stable、Logs 为Beta并列出受支持的 OS / Go 版本 / 架构组合文档必须与实际行为保持一致不留过期的注释、示例或包文档用户可见的变更须更新 CHANGELOG.md且必须写入## [Unreleased]下对应的Added/Changed/Deprecated/Fixed/Removed小节。从该文件头部可见其遵循Keep a Changelog格式与Semantic Versioning最新的已发布版本为1.44.0/0.66.0/0.20.0/0.0.172026-05-27。六、仓库习惯代理的日常操作准则AGENTS.md 的Repository habits部分给出六条可操作的日常准则偏好聚焦的 diff避免顺手清理沿用既有选项模式与导出 API 约定不发明新抽象生成文件入库改动影响生成时必须同步更新生成产物偏好快速本地搜索工具如rg来探索仓库变更行为时在测试中把不变量显式化配合前文的验证纪律make precommit是完成判据热路径改动要上 benchmark。这些习惯与第 2 节的最小改动期望形成闭环搜索用rg而非 IDE 漫游改动被测试钉住验证交给统一入口从而把代理的认知负担和意外副作用都压到最低。七、五类 Agent 角色Personas的行为契约AGENTS.md 最独特的部分是为不同任务类型定义了五种代理角色每种角色都有一份明确的行为契约1. Feature Agent新功能代理适用于新行为、新 API 面或规范驱动的功能开发从失败单元测试开始对照规范、既有包行为与公开 API 兼容性确认预期行为实现最小可行改动用户可见变更时同步更新 GoDoc、示例、README.md与CHANGELOG.md触碰热路径时检查基准覆盖缺失则补充。2. Refactoring Agent重构代理适用于不改变行为的结构改进将行为保持视为默认契约当前行为尚未被测试钉住时先加或收紧测试再动代码除非被明确要求避免大范围重写、花哨抽象或包级清理触碰热路径时做重构前后基准对比除非任务另有说明保持 API 形态、语义、并发保证与失败模式不变。3. Test Agent测试代理适用于补覆盖、复现缺陷或加固回归用尽可能小的失败测试复现缺陷或缺失行为优先测试公开行为与外部可见的不变量改生产代码之前先加针对性回归测试仅当为使被测行为正确或可测试时才改动生产代码保持测试确定性、可读性并与包内模式一致。4. Performance Agent性能代理适用于热路径工作、降低分配或吞吐/延迟优化先跑基准建立基线优先减少分配、拷贝、接口抖动与不必要的同步不以正确性、规范合规或 API 稳定性换取微优化性能敏感覆盖缺失时补充或更新基准实质性改变热路径时记录前后结果最好用benchstat。5. Review Agent评审代理适用于评审代码、补丁或 PR先摆结论再讲摘要Lead with findings, not summaries按严重程度排序发现并尽量给出精确的文件与行号引用聚焦正确性、规范合规、API 兼容、并发安全、弹性、性能回归、缺失测试、缺失基准、文档缺口与 CHANGELOG 缺口明确指出 diff 是否超出必要范围若未发现问题要明确说出无问题并注明剩余风险或验证缺口。这五类角色的共性值得总结它们都遵循测试先行 → 最小改动 → 文档同步 → 统一验证 → 基准佐证的同一套底层流程只是根据不同任务类型调整了侧重点——功能角色强调规格对齐重构角色强调行为锁存测试角色强调回归钉桩性能角色强调基线对比评审角色强调结论优先与证据引用。八、这份指南对 linuxkit 的实际意义对 linuxkit 项目而言src/cmd/linuxkit/vendor/go.opentelemetry.io/otel/AGENTS.md的价值体现在两个层面依赖上下文linuxkit 命令行工具src/cmd/linuxkit下的 Go 程序通过间接依赖引入 OpenTelemetry-Go v1.44.0用于经由otelgrpc、otelhttp等 instrumentation 包产生的遥测数据。理解上游 AGENTS.md 中遥测不得干扰宿主应用、热路径必须保守的约束有助于在升级或裁剪该依赖时保持 linuxkit 自身构建镜像流程的性能与稳定性不受影响方法论参考AGENTS.md 所呈现的代理开发纪律失败测试先行、最小 diff、make precommit统一验证、五类角色分工是一套与语言和框架无关的工程过程模板。linuxkit 自身的测试体系如test/cases/下的000_build、020_kernel、040_packages等分组用例与test/_lib公共库同样体现了类似的行为先钉住、再实现、最后统一验证的思想读者可将 AGENTS.md 的流程迁移到任何要求严格 API 兼容与并发安全的 Go 仓库中。综上这份 AGENTS.md 并非传统意义上的 API 文档而是一份高质量的AI 参与开源基础设施库开发的操作手册它用可执行的工作流、可验证的命令和五类明确的角色契约把 OpenTelemetry-Go 的工程文化完整编码给了机器代理。无论你是要在 linuxkit 中维护这份 vendored 依赖还是希望为自己的 Go 项目建立 AI 协作规范它都是一份值得逐条研读并参照落地的范本。赞分享操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载相关推荐用 AI Agent 为 OpenTelemetry-Go 仓库贡献代码AGENTS.md 协作规范、默认工作流与五种 Personas 全解读用 AI Agent 为 OpenTelemetry Go 仓库贡献代码AGENTS.md 协作规范、默认工作流与五种 Personas 全解读 本文以当前仓云原生Podman 仓库中的 OpenTelemetry-Go AGENTS.md 解读面向 AI 编码 Agent 的仓库协作与工程规范指南Podman 仓库中的 OpenTelemetry Go AGENTS.md 解读面向 AI 编码 Agent 的仓库协作与工程规范指南 本文是一篇围绕 ve容器运行时云原生CLIopentelemetry-go 的 AI Agent 协作规范从核心期望、默认工作流到五种 Agent 角色opentelemetry go 的 AI Agent 协作规范从核心期望、默认工作流到五种 Agent 角色 本篇技术指南以当前仓库 vendor/go.o镜像仓库后端存储云原生上一篇Go Music DL歌词视频生成教程一键渲染卡拉OK式逐字高亮高质量视频下一篇如何高效解密QMC音频qmc-decoder完整实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 opentelemetry-go 仓库的 AI 编码代理协作指南：AGENTS.md 工作流、验证体系与五类 Agent 角色实践解析
操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载本文以 linuxkit 仓库中随依赖 vendored 的 go.opentelemetry.io/otel/AGENTS.md 为骨架系统讲解 OpenTelemetry-Go 项目为自主与半自主编码代理coding agent制定的任务导向协作规范包括核心工程期望、默认开发工作流、make precommit验证体系、文档与 CHANGELOG 约定以及 Feature / Refactoring / Test / Performance / Review 五类 Agent 角色各自的行为契约。读者读完可以完整掌握一套可直接复用的AI 参与开源 Go 项目开发的过程纪律并理解它在 OpenTelemetry-Go 与 linuxkit 实际仓库中的落地方式。一、AGENTS.md 是什么一份为编码代理编写的任务导向指令与面向人类贡献者的 CONTRIBUTING.md介绍 SIG 会议、开发方式、make test与生成文件维护不同AGENTS.md 开宗明义地声明自己是面向在本仓库中工作的自主与半自主编码代理autonomous and semi-autonomous coding agents的、当前有效且任务导向active, task-oriented的指令文件。它要求代理在开始任何任务前先依次阅读三个文件.github/copilot-instructions.md——被当作全局被动指导global passive guidance适用于包括纯文档、纯评审在内的每一项任务CONTRIBUTING.md——人类与代理共同遵守的贡献规范AGENTS.md本身——任务执行的具体纪律。这份文件之所以存在是因为 OpenTelemetry-Go 是一个对规范合规spec compliance、API 稳定性和并发正确性要求极高的基础设施库代理如果按通用代码生成的习惯行事很容易引入破坏性 API 变更或宿主应用不可接受的遥测干扰。AGENTS.md 的作用就是把仓库的隐性工程文化显性化让代理在无需人类逐步监督的情况下也能保持与维护者一致的标准。在 linuxkit 仓库中该文件位于src/cmd/linuxkit/vendor/go.opentelemetry.io/otel/下属于 linuxkit 命令行工具依赖的 vendored 副本。从 src/cmd/linuxkit/go.mod 可见linuxkit 通过go.opentelemetry.io/contrib/instrumentation/.../otelgrpc、otelhttp等间接依赖引入go.opentelemetry.io/otel v1.44.0及其 OTLP 导出器、sdk、trace/metric 子包均标记为// indirect因此这份代理指南也随依赖一并进入仓库成为可本地查阅的一手工程资料。二、核心期望八条贯穿所有任务的工程底线AGENTS.md 用八条核心期望Core expectations为代理的所有行为划定边界它们既是代码评审的检查项也是代理自我约束的原则期望含义保持规范合规、API 稳定与地道 Go任何改动都不得违背 OpenTelemetry 规范、破坏公开 API 兼容性或偏离 Go 惯用法最小、外科手术式改动优先小范围精准修改拒绝大面积重构与顺手清理drive-by cleanup匹配所在包既有风格编辑前先读该包沿用其命名、选项类型、错误处理、注释、测试与并发模式公开 API 向后兼容除非任务明确要求破坏性变更否则保持向后兼容遥测弹性与低耦合不得引入会意外干扰宿主应用host application的行为仔细检查边界输入校验、资源限制、取消、关闭、错误传播、并发、内存增长都要逐一审视故障安全优于隐式假设偏好 fail-safe 行为与显式不变量invariant而非依赖隐含假设依赖最小化且有理有据新增依赖必须精简且有正当理由其中特别强调两条与宿主应用安全相关的硬性要求遥测不应 panic、不应无限阻塞、不应放大攻击者可控的输入同时要求热路径hot path上保持保守——避免不必要的分配allocation、反射、接口抖动interface churn、阻塞、全局状态以及高基数high-cardinality遥测。这些约束直接呼应了 OpenTelemetry-Go 作为嵌入到任意 Go 应用中的 SDK 的定位库代码的每次执行都发生在用户进程内任何失控行为都会直接传导给宿主。最后一条注释纪律也值得注意注释只写意图、不变量与非显而易见的约束禁止重复代码本身Do not add comments that restate the code——这与 docs/coding-style.md 中 linuxkit 自身强调的 Go 代码风格原则一脉相承。三、默认工作流从失败测试到提交前检查的七个步骤对于新功能与行为变更AGENTS.md 规定代理必须按以下顺序执行除非任务明确另有指示先读包阅读相关包、其测试、包文档或README.md先写失败测试新增或更新一个能捕获目标行为或回归的失败单元测试最小实现实现让测试通过的最小改动行为锁定后再重构且重构必须保持 diff 聚焦热路径基准若改动位于热路径或性能敏感代码检查既有 benchmark 并运行覆盖缺失则补充同步更新文档趁上下文还热时更新文档产物遵循下述文档与 CHANGELOG 约定make precommit每次认为工作完成前都必须运行。这本质上是一条测试驱动开发TDD 最小 diff 基准验证 文档同步的闭环流水线。对于纯文档、纯测试或纯评审类任务文件同样要求先阅读前述仓库指导然后跳过不适用的步骤但对范围控制、验证与仓库约定的纪律保持一致。一个值得注意的细节第 2 步与第 3 步的组合先失败测试、后最小实现在五类 Persona 中反复出现说明 OpenTelemetry-Go 把用测试钉住行为视为代理改动安全性的第一道保险——行为一旦被测试锁定后续任何重构或优化都有可验证的基准。四、验证体系make precommit与benchstatAGENTS.md 把make定义为仓库的权威验证命令canonical repository verification command默认目标是precommit并明确make precommit是预期的最终验证步骤覆盖 lint、代码生成、README 检查、模块检查与测试迭代过程中允许用针对性命令如单个包的go test快速反馈但只要改动涉及代码就不能止步于此触碰性能敏感代码时除make外还要运行聚焦基准并用benchstat对比结果。在 vendored 副本的 Makefile 中可以看到该目标的真实定义.DEFAULT_GOAL : precommit .PHONY: precommit ci precommit: generate toolchain-check license-check misspell go-mod-tidy golangci-lint-fix verify-readmes verify-mods test-default ci: generate toolchain-check license-check lint vanity-import-check verify-readmes verify-mods build test-default check-clean-work-tree test-coverage即一次make precommit实际串联了代码生成generate、Go 工具链版本检查toolchain-check、许可证头检查license-check、拼写检查misspell、go mod tidy校验go-mod-tidy、golangci-lint 自动修复golangci-lint-fix、README 校验verify-readmes基于internal/tools/verifyreadmes工具、多模块一致性校验verify-mods基于 multimod 工具以及默认测试集test-default。CI 目标ci则在其上再叠加 vanity import 检查、构建、工作树洁净检查与覆盖率测试。这些与 AGENTS.md 中生成文件必须入库、改动影响生成则保持生成产物最新的习惯相互印证。五、文档与 CHANGELOG 约定AGENTS.md 对文档产物提出了明确且可执行的规则非 internal、非测试的包应有 Go doc 注释通常写在doc.go中。vendored 副本的 doc.go 即典型范例它说明otel包提供 OpenTelemetry API 的全局访问入口默认情况下测得的遥测数据不被处理也不被传输需要由 SDK如go.opentelemetry.io/otel/sdk与 exporter 负责处理和传输并分别指引到 trace、metric、log、propagation/baggage 子包非 internal、非测试、非文档包还应提供README.md至少包含标题与pkg.go.dev徽章。vendored 的 README.md 展示了完整形态项目状态表中 Traces 与 Metrics 为Stable、Logs 为Beta并列出受支持的 OS / Go 版本 / 架构组合文档必须与实际行为保持一致不留过期的注释、示例或包文档用户可见的变更须更新 CHANGELOG.md且必须写入## [Unreleased]下对应的Added/Changed/Deprecated/Fixed/Removed小节。从该文件头部可见其遵循Keep a Changelog格式与Semantic Versioning最新的已发布版本为1.44.0/0.66.0/0.20.0/0.0.172026-05-27。六、仓库习惯代理的日常操作准则AGENTS.md 的Repository habits部分给出六条可操作的日常准则偏好聚焦的 diff避免顺手清理沿用既有选项模式与导出 API 约定不发明新抽象生成文件入库改动影响生成时必须同步更新生成产物偏好快速本地搜索工具如rg来探索仓库变更行为时在测试中把不变量显式化配合前文的验证纪律make precommit是完成判据热路径改动要上 benchmark。这些习惯与第 2 节的最小改动期望形成闭环搜索用rg而非 IDE 漫游改动被测试钉住验证交给统一入口从而把代理的认知负担和意外副作用都压到最低。七、五类 Agent 角色Personas的行为契约AGENTS.md 最独特的部分是为不同任务类型定义了五种代理角色每种角色都有一份明确的行为契约1. Feature Agent新功能代理适用于新行为、新 API 面或规范驱动的功能开发从失败单元测试开始对照规范、既有包行为与公开 API 兼容性确认预期行为实现最小可行改动用户可见变更时同步更新 GoDoc、示例、README.md与CHANGELOG.md触碰热路径时检查基准覆盖缺失则补充。2. Refactoring Agent重构代理适用于不改变行为的结构改进将行为保持视为默认契约当前行为尚未被测试钉住时先加或收紧测试再动代码除非被明确要求避免大范围重写、花哨抽象或包级清理触碰热路径时做重构前后基准对比除非任务另有说明保持 API 形态、语义、并发保证与失败模式不变。3. Test Agent测试代理适用于补覆盖、复现缺陷或加固回归用尽可能小的失败测试复现缺陷或缺失行为优先测试公开行为与外部可见的不变量改生产代码之前先加针对性回归测试仅当为使被测行为正确或可测试时才改动生产代码保持测试确定性、可读性并与包内模式一致。4. Performance Agent性能代理适用于热路径工作、降低分配或吞吐/延迟优化先跑基准建立基线优先减少分配、拷贝、接口抖动与不必要的同步不以正确性、规范合规或 API 稳定性换取微优化性能敏感覆盖缺失时补充或更新基准实质性改变热路径时记录前后结果最好用benchstat。5. Review Agent评审代理适用于评审代码、补丁或 PR先摆结论再讲摘要Lead with findings, not summaries按严重程度排序发现并尽量给出精确的文件与行号引用聚焦正确性、规范合规、API 兼容、并发安全、弹性、性能回归、缺失测试、缺失基准、文档缺口与 CHANGELOG 缺口明确指出 diff 是否超出必要范围若未发现问题要明确说出无问题并注明剩余风险或验证缺口。这五类角色的共性值得总结它们都遵循测试先行 → 最小改动 → 文档同步 → 统一验证 → 基准佐证的同一套底层流程只是根据不同任务类型调整了侧重点——功能角色强调规格对齐重构角色强调行为锁存测试角色强调回归钉桩性能角色强调基线对比评审角色强调结论优先与证据引用。八、这份指南对 linuxkit 的实际意义对 linuxkit 项目而言src/cmd/linuxkit/vendor/go.opentelemetry.io/otel/AGENTS.md的价值体现在两个层面依赖上下文linuxkit 命令行工具src/cmd/linuxkit下的 Go 程序通过间接依赖引入 OpenTelemetry-Go v1.44.0用于经由otelgrpc、otelhttp等 instrumentation 包产生的遥测数据。理解上游 AGENTS.md 中遥测不得干扰宿主应用、热路径必须保守的约束有助于在升级或裁剪该依赖时保持 linuxkit 自身构建镜像流程的性能与稳定性不受影响方法论参考AGENTS.md 所呈现的代理开发纪律失败测试先行、最小 diff、make precommit统一验证、五类角色分工是一套与语言和框架无关的工程过程模板。linuxkit 自身的测试体系如test/cases/下的000_build、020_kernel、040_packages等分组用例与test/_lib公共库同样体现了类似的行为先钉住、再实现、最后统一验证的思想读者可将 AGENTS.md 的流程迁移到任何要求严格 API 兼容与并发安全的 Go 仓库中。综上这份 AGENTS.md 并非传统意义上的 API 文档而是一份高质量的AI 参与开源基础设施库开发的操作手册它用可执行的工作流、可验证的命令和五类明确的角色契约把 OpenTelemetry-Go 的工程文化完整编码给了机器代理。无论你是要在 linuxkit 中维护这份 vendored 依赖还是希望为自己的 Go 项目建立 AI 协作规范它都是一份值得逐条研读并参照落地的范本。赞分享操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载相关推荐用 AI Agent 为 OpenTelemetry-Go 仓库贡献代码AGENTS.md 协作规范、默认工作流与五种 Personas 全解读用 AI Agent 为 OpenTelemetry Go 仓库贡献代码AGENTS.md 协作规范、默认工作流与五种 Personas 全解读 本文以当前仓云原生Podman 仓库中的 OpenTelemetry-Go AGENTS.md 解读面向 AI 编码 Agent 的仓库协作与工程规范指南Podman 仓库中的 OpenTelemetry Go AGENTS.md 解读面向 AI 编码 Agent 的仓库协作与工程规范指南 本文是一篇围绕 ve容器运行时云原生CLIopentelemetry-go 的 AI Agent 协作规范从核心期望、默认工作流到五种 Agent 角色opentelemetry go 的 AI Agent 协作规范从核心期望、默认工作流到五种 Agent 角色 本篇技术指南以当前仓库 vendor/go.o镜像仓库后端存储云原生上一篇Go Music DL歌词视频生成教程一键渲染卡拉OK式逐字高亮高质量视频下一篇如何高效解密QMC音频qmc-decoder完整实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考