【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载导读这篇技术指南围绕 learn-harness-engineering 仓库中的标准操作流程SOP文档 observability-feedback-loop.md 展开讲解如何为编码 Agent 构建一条日志—指标—追踪—可重复负载的本地反馈回路让 Agent 从只看代码升级为从运行证据推理。文中将以仓库的实践项目 Project 06 为实例展示结构化日志、基准脚本、清理扫描器等真实实现读完你可以直接在自己的 harness 中落地这套可观测性反馈回路并写出符合 RELIABILITY.md 要求的可靠性文档。一、为什么要给 Agent 一条可观测性反馈回路1.1 没有可观测性时调试为什么这么慢当出现以下三种症状时就应该启用这条 SOP调试很慢改一行代码要反复猜测、反复重启才能定位问题Agent 反复宣称成功了却没有证据没有日志、没有指标、没有可重复的运行结果Agent 只能凭代码印象下结论运行时行为比代码本身更难检查代码审查只能看到写的是什么运行时追踪才能看到实际跑的是什么。课程 Lecture 11: Making the Agents Runtime Observable 明确指出当 Agent 在执行任务时看不到真实的运行时状态它的每一个决策本质上都是猜测。缺少可观测性会系统性地产生四类问题——无法区分正确与看起来正确、评估变成主观玄学、重试变成盲目的乱撞、会话交接时新会话要从零开始诊断据观察这类冗余诊断可能浪费 30%50% 的会话时间。1.2 SOP 的目标本 SOP 的目标很明确给 Agent 一个围绕日志logs、指标metrics、追踪traces和可运行负载runnable workloads的本地反馈回路使它能够从执行结果推理而不是仅仅从代码检查推理。也就是说可观测性不是多加几行日志而是让 Agent 的每次决策都有运行时证据支撑。二、最小可观测性技术栈Minimum StackSOP 给出的最小技术栈包含五个组成部分缺一不可组件作用在 Project 06 中的对应实现应用发出结构化日志机器可解析、可查询、可关联logger.ts 输出的单行 JSON 日志应用在可行时发出指标与追踪量化延迟、失败数、队列深度indexing-service.ts 中的吞吐量指标、QA 延迟本地fan-out / 采集层汇聚所有信号统一出口所有服务通过logger.forService()汇聚到同一个 Logger 单例日志、指标、追踪的查询接口让 Agent 能问运行时IPC_CHANNELS中indexing:status、app:status等 14 个通道可重复负载或用户场景每次改动后都能重跑benchmark.sh 的 import/index/query/verify 四任务其中最后一项可重复负载是关键它把我修好了从口头声明变成可复现的事实——同一份负载在每次改动后重新执行通过与否一目了然。三、SOP 执行步骤七步建立反馈回路SOP 给出了七步执行流程每一步都有明确的产出物定义最重要的 golden 运行时场景golden runtime journeys确定哪些用户旅程是系统健康的基准。Project 06 的 benchmark.sh 定义了 import导入吞吐、index批量索引速度、query问答延迟、verify数据完整性四个黄金场景。在启动路径和关键路径上加入结构化日志启动时的服务初始化、关键业务操作都要留痕。在有用之处加入延迟、失败数或队列深度指标例如批量索引完成时记录throughputchunks/secQA 回答生成时记录durationMs和confidence。为慢流程或多步流程加入追踪或时间标记Project 06 用Date.now()记录每个阶段耗时见 indexing-service.ts 中的startTime/duration更完整的方案是用 OpenTelemetry 为每个会话建 trace、每个任务建 span。让信号从本地开发环境可查询Agent 应能通过命令或 IPC 主动查询运行时状态而不是只靠被动看终端输出。给 Agent 一个可重复的负载或场景用于重跑bash scripts/benchmark.sh就是这样一个可重复负载。强制要求闭环查询 - 关联 - 推理 - 实现 - 重启 - 重跑 - 验证。缺少任何一环反馈回路就不成立。其中第 7 步的闭环是整个 SOP 的灵魂。它要求 Agent 的每一次修复都走完一圈先查询信号定位问题再关联信号与代码层基于证据推理根因实现修复后重启应用重跑同一份负载最后用新的信号验证修复确实生效。四、调试会话检查清单Debug Session Checklist当一次调试会话结束时SOP 要求逐项回答以下六个问题确保不是感觉修好了而是证据上修好了什么失败了What failed?哪个信号证明了失败Which signal proves the failure?——必须有具体的日志条目、指标或追踪片段作证失败属于哪一层Which layer owns the failure?——是 UI、IPC、服务层还是持久化层Project 06 的架构分层见 ARCHITECTURE.md 与 AGENTS.md 中的 Electron 层边界修复后什么发生了变化What changed after the fix?——对比修复前后的信号差异应用是否干净地重启了Did the app restart cleanly?——启动日志是否无 ERROR同一份负载重跑后是否通过Did the same workload pass after rerun?——重跑 benchmark 确认。这套清单把调试完成的定义从主观感受切换为可验证证据与课程 Lecture 09 强调的过早宣布胜利问题直接对应。五、Definition of Done什么时候这条 SOP 算落地SOP 给出了四条完成标准Agent 能基于运行时证据解释故障模式——能指出具体是哪条日志、哪个指标证明了失败同一份负载能在每次改动后重跑——benchmark 脚本随时可执行重启和重跑是普通任务循环的一部分——不是额外步骤而是默认流程可靠性信号被记录在docs/RELIABILITY.md中——把信号源、验证命令、golden journeys 固化进文档。第四点正是仓库中 repo-template 的 RELIABILITY.md 模板所要求的它规定了标准路径bootstrap/verification/run/debug 四条命令、强制运行时信号结构化日志、健康检查、追踪/计时数据、用户可见的错误状态、golden journeys 列表以及三条可靠性规则——没有任何功能在系统不能干净重启后算完成、运行时故障必须能用仓库本地信号诊断、反复出现的故障模式要加 benchmark 或限制器。六、仓库实践Project 06 的完整可观测性落地Project 06 是本仓库的实践项目Capstone其 solution 目录完整实现了上述 SOP 的每一项要求是理解反馈回路长什么样的最佳样例。6.1 结构化日志从console.log到机器可解析 JSON日志系统的实现在 src/services/logger.ts定义DEBUG / INFO / WARN / ERROR四个级别由LEVEL_ORDER数组决定过滤规则shouldLog每条日志输出为单行 JSON{ timestamp, level, service, message, data }通过logger.forService(document-service)得到按服务隔离的子 Logger保证日志带统一的服务标签单例logger从环境变量LOG_LEVEL读取最低级别默认DEBUG。典型的 JSON 日志条目见 RELIABILITY.md{ timestamp: 2026-03-30T12:00:00.000Z, level: INFO, service: document-service, message: Document imported successfully, data: { documentId: abc-123, filename: design-notes.md, sizeBytes: 2048 } }日志级别使用约定级别适用场景示例DEBUG常规数据访问、文件读取Retrieved chunks for documentINFO重要事件Document imported、Batch indexing completeWARN缺失但非致命的数据Content not found for documentERROR失败File not found during import6.2 指标关键路径上的量化信号指标不是独立设施而是从日志的data字段中携带的量化值。从源码可以看到指标埋点indexing-service.ts 在批量索引完成时记录durationMs与throughputchunks/secqa-service.ts 在回答生成时记录durationMs、confidence置信度、citationCount、answerLength——其中confidence: citations.length 0 ? 0.85 : 0.3直接量化了回答有没有依据document-service.ts 在导入时记录sizeBytes、contentLength、totalDocuments。6.3 追踪/时间标记慢路径与多步流程Project 06 目前用Date.now()计时器作为轻量追踪例如导入、索引、问答三个阶段各记录startTime与duration这对应 SOP 第 4 步的时间标记。课程 Lecture 11 给出了更标准化的升级路径用OpenTelemetry为每个 harness 会话建一个 trace每个任务建一个 span每个验证步骤建子 span并用标准属性标注关键信息使可观测性数据能接入 Jaeger、Zipkin 等标准工具链。这与 SOP 的最小栈一脉相承——先有时间标记再平滑演进到标准追踪。6.4 查询接口让信号可被问Project 06 通过 Electron IPC 提供 14 个查询通道定义在 src/shared/types.ts 的IPC_CHANNELS常量注册于 ipc-handlers.ts读类操作DEBUG 级别documents:list、documents:get、indexing:status、indexing:chunks、qa:history、feedback:list、app:status写类操作INFO 级别documents:import、documents:delete、indexing:start、qa:ask、qa:clear-history、feedback:submit、app:reset。值得注意的是 ipc-handlers.ts 中每个 handler 都以结构化日志记录自己的调用例如logger.info(SERVICE, IPC: IMPORT_DOCUMENT, { filePath })且RESET_DATA使用 WARN 级别提示这是破坏性操作——这本身就演示了让 Agent 的每次交互也变成可观测信号。6.5 可重复负载benchmark.shscripts/benchmark.sh 是 SOP 第 6 步的完整实现——一个不依赖 Electron 窗口、直接用文件模拟服务层操作的可重复负载任务测量内容目标import文档导入吞吐3 个文件 1sindex批量索引速度14 个 chunk 1squery问答响应延迟每问 500msverify数据完整性检查0 错误运行方式bash scripts/benchmark.sh示例输出 Benchmark Results [import] 3 files: 120ms (25.0 files/sec) [index] 3 documents: 80ms (175.0 chunks/sec) [query] 5 questions: 1250ms (250.0ms avg) [verify] Data integrity: PASS Summary: 4/4 tasks passed 这就是 SOP 要求的同一份负载可以反复重跑每次 Agent 改动后重跑 benchmark用量化结果代替口头宣称。6.6 清理扫描器反馈回路的卫生保障scripts/cleanup-scanner.sh 对应 RELIABILITY.md 中的规则清理是可靠性的一部分而不是独立事项。它检查六类数据一致性问题检查项说明孤立内容文件有 content 无对应元数据悬空 chunk 文件有 chunks 无索引条目缺失内容文件元数据存在但内容文件丢失不一致元数据标记为 indexed 但没有 chunk 文件空数据文件本应有数据的 JSON 为空数组过期 QA 引用历史记录引用已删除的文档运行方式bash scripts/cleanup-scanner.sh [data-dir]未提供参数时使用 Electron 默认 userData 路径如 Linux 的~/.config/knowledge-base/knowledge-base-data。输出类似 Cleanup Scanner [OK] No orphaned content files [OK] No dangling chunk files [OK] No missing content files [OK] All indexed documents have chunk files [OK] No stale QA references Result: CLEAN (0 issues) 七、落地清单在你自己 harness 中启用本 SOP参考 Project 06 的 AGENTS.md 启动规则在写任何代码前先读文档、跑init.sh验证构建、读feature_list.json了解功能状态以及 RELIABILITY.md 的三块内容落地本 SOP 的检查顺序是日志所有服务统一走结构化 JSON 日志带level、service、data字段LOG_LEVEL环境变量可调节输出LOG_LEVELINFO npm run dev只显示 INFO/WARN/ERROR指标/追踪在启动、关键路径、慢流程处埋点至少是时间标记最好是 OpenTelemetry span查询接口提供可编程查询通道如 IPC 或 CLI 命令让 Agent 能主动问运行时可重复负载准备一个 benchmark 脚本或用户旅程脚本每次改动后重跑清理与干净状态调试后运行清理扫描器必要时走RESET_DATA通道重置数据再验证 clean-state-checklist.md文档化把标准路径命令、强制运行时信号、golden journeys 和可靠性规则写进docs/RELIABILITY.md。八、关键要点回顾可观测性是 harness 的架构属性不是事后补的功能——它必须从设计之初就内建反馈回路要求信号可查询 负载可重跑两者齐备缺一 Agent 就只能回到猜代码闭环七步查询 → 关联 → 推理 → 实现 → 重启 → 重跑 → 验证是调试质量的下限保障结构化日志是地基单行 JSON、级别分层、按服务打标签才能支撑后续的关联与查询可靠性文档是收尾把 golden journeys 和验证命令固化进docs/RELIABILITY.md让健康有明确定义、可复现、可传承。延伸阅读更完整的可观测性理论本 SOP 所属的 OpenAI Advanced SOPs 目录以及课程 Lecture 11: Making the Agents Runtime Observable含 sprint contract、evaluator rubric、Anthropic 三 Agent 架构实验的详细数据可靠性模板RELIABILITY.md 模板完整实践Project 06 解决方案目录重点阅读 docs/RELIABILITY.md、src/services/logger.ts、scripts/benchmark.sh 与 scripts/cleanup-scanner.sh。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐为 Agent 建立可观测性反馈闭环learn-harness-engineering 中 Observability Feedback Loop SOP 的落地实战为 Agent 建立可观测性反馈闭环learn harness engineering 中 Observability Feedback Loop SOP 的构建 Agent 可观测性反馈回路Observability Feedback Loop SOP从运行时证据到可验证修复的 Harness 实战指南构建 Agent 可观测性反馈回路Observability Feedback Loop SOP从运行时证据到可验证修复的 Harness 实战指南 本指为 Agent 构建可观测性反馈回路基于 learn-harness-engineering 的日志、指标、追踪与可重复验证 SOP为 Agent 构建可观测性反馈回路基于 learn harness engineering 的日志、指标、追踪与可重复验证 SOP 调试缓慢、Agent 反上一篇DRG存档编辑器3分钟掌握《深岩银河》游戏进度自定义的终极指南下一篇5步解决Windows 11 LTSC商店缺失完整微软应用商店恢复方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为 Agent 建立可观测性反馈回路：以 learn-harness-engineering 的 Observability Feedback Loop SOP 为例
【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载导读这篇技术指南围绕 learn-harness-engineering 仓库中的标准操作流程SOP文档 observability-feedback-loop.md 展开讲解如何为编码 Agent 构建一条日志—指标—追踪—可重复负载的本地反馈回路让 Agent 从只看代码升级为从运行证据推理。文中将以仓库的实践项目 Project 06 为实例展示结构化日志、基准脚本、清理扫描器等真实实现读完你可以直接在自己的 harness 中落地这套可观测性反馈回路并写出符合 RELIABILITY.md 要求的可靠性文档。一、为什么要给 Agent 一条可观测性反馈回路1.1 没有可观测性时调试为什么这么慢当出现以下三种症状时就应该启用这条 SOP调试很慢改一行代码要反复猜测、反复重启才能定位问题Agent 反复宣称成功了却没有证据没有日志、没有指标、没有可重复的运行结果Agent 只能凭代码印象下结论运行时行为比代码本身更难检查代码审查只能看到写的是什么运行时追踪才能看到实际跑的是什么。课程 Lecture 11: Making the Agents Runtime Observable 明确指出当 Agent 在执行任务时看不到真实的运行时状态它的每一个决策本质上都是猜测。缺少可观测性会系统性地产生四类问题——无法区分正确与看起来正确、评估变成主观玄学、重试变成盲目的乱撞、会话交接时新会话要从零开始诊断据观察这类冗余诊断可能浪费 30%50% 的会话时间。1.2 SOP 的目标本 SOP 的目标很明确给 Agent 一个围绕日志logs、指标metrics、追踪traces和可运行负载runnable workloads的本地反馈回路使它能够从执行结果推理而不是仅仅从代码检查推理。也就是说可观测性不是多加几行日志而是让 Agent 的每次决策都有运行时证据支撑。二、最小可观测性技术栈Minimum StackSOP 给出的最小技术栈包含五个组成部分缺一不可组件作用在 Project 06 中的对应实现应用发出结构化日志机器可解析、可查询、可关联logger.ts 输出的单行 JSON 日志应用在可行时发出指标与追踪量化延迟、失败数、队列深度indexing-service.ts 中的吞吐量指标、QA 延迟本地fan-out / 采集层汇聚所有信号统一出口所有服务通过logger.forService()汇聚到同一个 Logger 单例日志、指标、追踪的查询接口让 Agent 能问运行时IPC_CHANNELS中indexing:status、app:status等 14 个通道可重复负载或用户场景每次改动后都能重跑benchmark.sh 的 import/index/query/verify 四任务其中最后一项可重复负载是关键它把我修好了从口头声明变成可复现的事实——同一份负载在每次改动后重新执行通过与否一目了然。三、SOP 执行步骤七步建立反馈回路SOP 给出了七步执行流程每一步都有明确的产出物定义最重要的 golden 运行时场景golden runtime journeys确定哪些用户旅程是系统健康的基准。Project 06 的 benchmark.sh 定义了 import导入吞吐、index批量索引速度、query问答延迟、verify数据完整性四个黄金场景。在启动路径和关键路径上加入结构化日志启动时的服务初始化、关键业务操作都要留痕。在有用之处加入延迟、失败数或队列深度指标例如批量索引完成时记录throughputchunks/secQA 回答生成时记录durationMs和confidence。为慢流程或多步流程加入追踪或时间标记Project 06 用Date.now()记录每个阶段耗时见 indexing-service.ts 中的startTime/duration更完整的方案是用 OpenTelemetry 为每个会话建 trace、每个任务建 span。让信号从本地开发环境可查询Agent 应能通过命令或 IPC 主动查询运行时状态而不是只靠被动看终端输出。给 Agent 一个可重复的负载或场景用于重跑bash scripts/benchmark.sh就是这样一个可重复负载。强制要求闭环查询 - 关联 - 推理 - 实现 - 重启 - 重跑 - 验证。缺少任何一环反馈回路就不成立。其中第 7 步的闭环是整个 SOP 的灵魂。它要求 Agent 的每一次修复都走完一圈先查询信号定位问题再关联信号与代码层基于证据推理根因实现修复后重启应用重跑同一份负载最后用新的信号验证修复确实生效。四、调试会话检查清单Debug Session Checklist当一次调试会话结束时SOP 要求逐项回答以下六个问题确保不是感觉修好了而是证据上修好了什么失败了What failed?哪个信号证明了失败Which signal proves the failure?——必须有具体的日志条目、指标或追踪片段作证失败属于哪一层Which layer owns the failure?——是 UI、IPC、服务层还是持久化层Project 06 的架构分层见 ARCHITECTURE.md 与 AGENTS.md 中的 Electron 层边界修复后什么发生了变化What changed after the fix?——对比修复前后的信号差异应用是否干净地重启了Did the app restart cleanly?——启动日志是否无 ERROR同一份负载重跑后是否通过Did the same workload pass after rerun?——重跑 benchmark 确认。这套清单把调试完成的定义从主观感受切换为可验证证据与课程 Lecture 09 强调的过早宣布胜利问题直接对应。五、Definition of Done什么时候这条 SOP 算落地SOP 给出了四条完成标准Agent 能基于运行时证据解释故障模式——能指出具体是哪条日志、哪个指标证明了失败同一份负载能在每次改动后重跑——benchmark 脚本随时可执行重启和重跑是普通任务循环的一部分——不是额外步骤而是默认流程可靠性信号被记录在docs/RELIABILITY.md中——把信号源、验证命令、golden journeys 固化进文档。第四点正是仓库中 repo-template 的 RELIABILITY.md 模板所要求的它规定了标准路径bootstrap/verification/run/debug 四条命令、强制运行时信号结构化日志、健康检查、追踪/计时数据、用户可见的错误状态、golden journeys 列表以及三条可靠性规则——没有任何功能在系统不能干净重启后算完成、运行时故障必须能用仓库本地信号诊断、反复出现的故障模式要加 benchmark 或限制器。六、仓库实践Project 06 的完整可观测性落地Project 06 是本仓库的实践项目Capstone其 solution 目录完整实现了上述 SOP 的每一项要求是理解反馈回路长什么样的最佳样例。6.1 结构化日志从console.log到机器可解析 JSON日志系统的实现在 src/services/logger.ts定义DEBUG / INFO / WARN / ERROR四个级别由LEVEL_ORDER数组决定过滤规则shouldLog每条日志输出为单行 JSON{ timestamp, level, service, message, data }通过logger.forService(document-service)得到按服务隔离的子 Logger保证日志带统一的服务标签单例logger从环境变量LOG_LEVEL读取最低级别默认DEBUG。典型的 JSON 日志条目见 RELIABILITY.md{ timestamp: 2026-03-30T12:00:00.000Z, level: INFO, service: document-service, message: Document imported successfully, data: { documentId: abc-123, filename: design-notes.md, sizeBytes: 2048 } }日志级别使用约定级别适用场景示例DEBUG常规数据访问、文件读取Retrieved chunks for documentINFO重要事件Document imported、Batch indexing completeWARN缺失但非致命的数据Content not found for documentERROR失败File not found during import6.2 指标关键路径上的量化信号指标不是独立设施而是从日志的data字段中携带的量化值。从源码可以看到指标埋点indexing-service.ts 在批量索引完成时记录durationMs与throughputchunks/secqa-service.ts 在回答生成时记录durationMs、confidence置信度、citationCount、answerLength——其中confidence: citations.length 0 ? 0.85 : 0.3直接量化了回答有没有依据document-service.ts 在导入时记录sizeBytes、contentLength、totalDocuments。6.3 追踪/时间标记慢路径与多步流程Project 06 目前用Date.now()计时器作为轻量追踪例如导入、索引、问答三个阶段各记录startTime与duration这对应 SOP 第 4 步的时间标记。课程 Lecture 11 给出了更标准化的升级路径用OpenTelemetry为每个 harness 会话建一个 trace每个任务建一个 span每个验证步骤建子 span并用标准属性标注关键信息使可观测性数据能接入 Jaeger、Zipkin 等标准工具链。这与 SOP 的最小栈一脉相承——先有时间标记再平滑演进到标准追踪。6.4 查询接口让信号可被问Project 06 通过 Electron IPC 提供 14 个查询通道定义在 src/shared/types.ts 的IPC_CHANNELS常量注册于 ipc-handlers.ts读类操作DEBUG 级别documents:list、documents:get、indexing:status、indexing:chunks、qa:history、feedback:list、app:status写类操作INFO 级别documents:import、documents:delete、indexing:start、qa:ask、qa:clear-history、feedback:submit、app:reset。值得注意的是 ipc-handlers.ts 中每个 handler 都以结构化日志记录自己的调用例如logger.info(SERVICE, IPC: IMPORT_DOCUMENT, { filePath })且RESET_DATA使用 WARN 级别提示这是破坏性操作——这本身就演示了让 Agent 的每次交互也变成可观测信号。6.5 可重复负载benchmark.shscripts/benchmark.sh 是 SOP 第 6 步的完整实现——一个不依赖 Electron 窗口、直接用文件模拟服务层操作的可重复负载任务测量内容目标import文档导入吞吐3 个文件 1sindex批量索引速度14 个 chunk 1squery问答响应延迟每问 500msverify数据完整性检查0 错误运行方式bash scripts/benchmark.sh示例输出 Benchmark Results [import] 3 files: 120ms (25.0 files/sec) [index] 3 documents: 80ms (175.0 chunks/sec) [query] 5 questions: 1250ms (250.0ms avg) [verify] Data integrity: PASS Summary: 4/4 tasks passed 这就是 SOP 要求的同一份负载可以反复重跑每次 Agent 改动后重跑 benchmark用量化结果代替口头宣称。6.6 清理扫描器反馈回路的卫生保障scripts/cleanup-scanner.sh 对应 RELIABILITY.md 中的规则清理是可靠性的一部分而不是独立事项。它检查六类数据一致性问题检查项说明孤立内容文件有 content 无对应元数据悬空 chunk 文件有 chunks 无索引条目缺失内容文件元数据存在但内容文件丢失不一致元数据标记为 indexed 但没有 chunk 文件空数据文件本应有数据的 JSON 为空数组过期 QA 引用历史记录引用已删除的文档运行方式bash scripts/cleanup-scanner.sh [data-dir]未提供参数时使用 Electron 默认 userData 路径如 Linux 的~/.config/knowledge-base/knowledge-base-data。输出类似 Cleanup Scanner [OK] No orphaned content files [OK] No dangling chunk files [OK] No missing content files [OK] All indexed documents have chunk files [OK] No stale QA references Result: CLEAN (0 issues) 七、落地清单在你自己 harness 中启用本 SOP参考 Project 06 的 AGENTS.md 启动规则在写任何代码前先读文档、跑init.sh验证构建、读feature_list.json了解功能状态以及 RELIABILITY.md 的三块内容落地本 SOP 的检查顺序是日志所有服务统一走结构化 JSON 日志带level、service、data字段LOG_LEVEL环境变量可调节输出LOG_LEVELINFO npm run dev只显示 INFO/WARN/ERROR指标/追踪在启动、关键路径、慢流程处埋点至少是时间标记最好是 OpenTelemetry span查询接口提供可编程查询通道如 IPC 或 CLI 命令让 Agent 能主动问运行时可重复负载准备一个 benchmark 脚本或用户旅程脚本每次改动后重跑清理与干净状态调试后运行清理扫描器必要时走RESET_DATA通道重置数据再验证 clean-state-checklist.md文档化把标准路径命令、强制运行时信号、golden journeys 和可靠性规则写进docs/RELIABILITY.md。八、关键要点回顾可观测性是 harness 的架构属性不是事后补的功能——它必须从设计之初就内建反馈回路要求信号可查询 负载可重跑两者齐备缺一 Agent 就只能回到猜代码闭环七步查询 → 关联 → 推理 → 实现 → 重启 → 重跑 → 验证是调试质量的下限保障结构化日志是地基单行 JSON、级别分层、按服务打标签才能支撑后续的关联与查询可靠性文档是收尾把 golden journeys 和验证命令固化进docs/RELIABILITY.md让健康有明确定义、可复现、可传承。延伸阅读更完整的可观测性理论本 SOP 所属的 OpenAI Advanced SOPs 目录以及课程 Lecture 11: Making the Agents Runtime Observable含 sprint contract、evaluator rubric、Anthropic 三 Agent 架构实验的详细数据可靠性模板RELIABILITY.md 模板完整实践Project 06 解决方案目录重点阅读 docs/RELIABILITY.md、src/services/logger.ts、scripts/benchmark.sh 与 scripts/cleanup-scanner.sh。赞分享【免费下载链接】learn-harness-engineeringHarness engineering beginner tutorial, from 0 to 1项目地址https://gitcode.com/gh_mirrors/le/learn-harness-engineering点击查看免费下载相关推荐为 Agent 建立可观测性反馈闭环learn-harness-engineering 中 Observability Feedback Loop SOP 的落地实战为 Agent 建立可观测性反馈闭环learn harness engineering 中 Observability Feedback Loop SOP 的构建 Agent 可观测性反馈回路Observability Feedback Loop SOP从运行时证据到可验证修复的 Harness 实战指南构建 Agent 可观测性反馈回路Observability Feedback Loop SOP从运行时证据到可验证修复的 Harness 实战指南 本指为 Agent 构建可观测性反馈回路基于 learn-harness-engineering 的日志、指标、追踪与可重复验证 SOP为 Agent 构建可观测性反馈回路基于 learn harness engineering 的日志、指标、追踪与可重复验证 SOP 调试缓慢、Agent 反上一篇DRG存档编辑器3分钟掌握《深岩银河》游戏进度自定义的终极指南下一篇5步解决Windows 11 LTSC商店缺失完整微软应用商店恢复方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考