在 AI Agent 走向生产后，评测需要回答的不只是模型能不能答对，还包括配置是否合规、工作流是否可追踪、失败任务能否复现、优化结果能否直接上线。Dev.to AI 的“Agent Platform in Action”系列最终篇展示了这一思路：文章以 ADK Go Graph Workflow 与 Google Research Harness 为基础，介绍 Harness² 在 LINE AI Card Master 项目中的落地方式，并对应 Issue #18 与 PR #19。
四层验证：从单元测试到生产切换
文章将验证归纳为四个层级：Go 原生单元测试、单任务 OpenTelemetry 轨迹诊断、Python 两层递归演化实验、生产环境切换。落到代码中，分别对应测试文件、harness-runner、实验脚本和环境变量。
- internal/harness/harness_test.go 覆盖基础 Harness 加载与校验、拒绝过大 AlwaysOn 和未引用 Skill、演化 Harness 校验与 Skill 匹配，以及 TrajectoryRecorder 渲染 workflow node spans；相关测试均 PASS。
- go test ./… 覆盖 app、cmd/harness-runner、cmd/line-gateway、eval、internal/harness、internal/storage、internal/webhook、internal/workflow，用于确保与既有 Phase 1~5 功能 100% 兼容。
- cmd/harness-runner –validate-only 可在挂载前检查 c1..c4 resident byte count 与 YAML Frontmatter。harness/base 为 OK（1599 always-on bytes），harness/evolved/k2_sequential_memory 为 OK（4661 always-on bytes）。
- harness/run_harness2_experiment.py 自动编译 harness-runner，对 8 大任务、32 independent Rubrics 评估四种配置，并输出 Markdown 表与 harness/experiment_report.json。
- 最优结果可通过 LINE_CARD_HARNESS_DIR=harness/evolved/k2_sequential_memory 挂载，main.go 与 eval/ 不需要修改 Go 代码即可加载演化 Harness 树。
这样，代码测试、配置准入、任务评测和上线切换被拆成可复现步骤。
两层递归实验：四种配置的量化对比
实验比较 base_k0、k1_single_step、k2_parallel、k2_sequential_memory 四种配置，并记录 Task Score、Rubric Pass Rate、Always-On Bytes、Active c6 Skills 与 LongTermMEMORY.md。
- Base Harness（k=0）：5.00 / 8.00，20/32（62.5%），1599 B，无 Active c6 Skills，无 LongTermMEMORY.md。
- Single-Step Propose-Probe-Compose（k=1）：6.75 / 8.00，27/32（84.4%），2505 B，启用 jp_card_ocr、tw_semicon_search。
- Multi-Step Parallel Recursion（k=2，无记忆）：7.75 / 8.00，31/32（96.9%），2998 B，启用 executive_email_drafter、hitl_multi_edit、jp_card_ocr、tw_semicon_search。
- Multi-Step Sequential Recursion + LongTermMEMORY.md（k=2）：8.00 / 8.00，32/32（100.0%），4661 B，启用相同四项技能，并加入 LongTermMEMORY.md。
素材的性能摘要显示，Base Harness 的 4 个 Baseline tasks 得分为 4.00/4.00，4 个 Challenge tasks 只得 0.25，原因与仅通过 RouterNode 意图路由有关。随后，Harness² 在内层递归中继续探测剩余失败任务。k2_parallel 虽达到 96.9%（31/32），但仍在 challenge_pii_safe_executive_followup 的第 4 个 Rubric r4_fintech_compliance_subject_tag 上失败。素材未进一步解释原因，但这一细节说明总分接近满分时，Rubric 仍能暴露具体缺口。
从一次评测到持续演化：生产反馈与自动 PR
文章将这一实践描述为 Google Research Harness² 在 LINE AI Card Master 中的落地，并延伸到 AgentOps 范式：生产观测、数据转换、递归演化和代码提交可以连接成闭环。
素材中的流程图给出两条链路。
- 生产可观测性：真实用户流量通过 LINE Webhook / A2A 进入 Cloud Run 与 Agent Runtime，产生 Cloud Trace OTel Spans，并结合 HITL Retry 等负反馈。
- 夜间自治演化飞轮：系统自动遮蔽 PII，将样本转换为 Challenge Dataset Cases；Harness² 执行 Propose-Probe-Compose 与 Reflector 的两层递归；最后自动发起 GitHub PR，更新 harness/evolved/ 下的 c1..c8。
文章还提到 Harness² 有四个高潜力企业级应用场景，并展示“Scenario A: Fully Automated Nightly Self-Healing Age…”方向。可确认的主线是：生产反馈转为测试样本，实验结果回到仓库，Harness 更新像代码变更一样提交。
对 AI 编程团队的意义
对 AI 编程团队来说，这套做法把 Agent 评测拆成可审计的工程动作：Go 测试检查加载与校验，harness-runner 判断配置准入，Python 脚本输出任务和 Rubric 指标，环境变量完成挂载。
同时，改进过程也能被记录。Active c6 Skills 从 none 到 jp_card_ocr、tw_semicon_search，再到加入 executive_email_drafter、hitl_multi_edit；LongTermMEMORY.md 从 No 到 Yes；Always-On Bytes 从 1599 B 增至 4661 B；Rubric Pass Rate 从 20/32 提升到 32/32。这些变化都放在同一实验报告中，便于回归和复查。
当 Agent 的每次优化都能对应到配置目录、测试命令、实验脚本和 PR，评测就从上线前的临时检查变成持续工程能力。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/agent-ping-ce-ru-he-jin-ru-gong-cheng-liu-shui-xian-adk-go
