面向人群：资深测试开发工程师（AI Agent 产品质量保障 / 后端自动化测试 / Golang Ginkgo + Python Playwright）。

数据来源：使用内置技能 github-ai-qa-analyzer 抓取 GitHub Trending（daily）并补全仓库信息，取 AI 相关 Top 6。

0. 今日结论先读（TL;DR）​

今天的 Trending AI 项目呈现出两个很“测开友好”的信号：

1. “让 AI 工作确定性（Deterministic）”正在成为显性卖点：比如 Archon 把“开发过程”写成 YAML 工作流、引入验证 Gate；这与测试工程的核心思想（可复现、可回归、可度量）天然同构。
2. “Agent 运营化/平台化（Ops for Agents）”在加速：比如 Multica、Hermes Agent 都在强调任务生命周期、进度流、跨渠道交互、持久化记忆/技能。对测开来说，这意味着：
   • 需要把 Agent 当成一个“长跑服务”来测（可观测性、状态一致性、幂等、权限/安全）。
   • 需要把“评测/回归”产品化：让评测集、回放、差分报告成为 CI 的一等公民。

1. 今日热门项目速览：特色与核心优势（从测开视角提炼）​

注：以上“特色/优势”来自脚本抓取的 description、README 摘要与公开文档片段；不做超出原文的功能承诺。

2. AI 架构与趋势（测试开发更关心的那部分）​

2.1 趋势 1：Agent 不再是“聊天机器人”，而是“可运行的流程 + 可观测的系统”​

• Hermes Agent、Multica 都在强调：
  • 长时间运行（持久化、跨会话、跨渠道）
  • 任务生命周期（排队、认领、执行、失败、阻塞上报）
  • 进度流与审计（实时 WebSocket、日志、配置校验）

测开含义：

• 你需要一套类似“微服务质量保障”的方法来保障 Agent：
  • SLO（成功率/时延）、重试与幂等、权限边界、安全审计
  • 观测性（trace_id 贯穿：用户输入→计划→工具调用→外部依赖→输出）

2.2 趋势 2：Deterministic Harness 成为“AI Coding/Agent”落地关键基础设施​

• Archon 代表了一个方向：AI 负责智能，流程由工程团队拥有。
• 这会让“测试”从事后补救变成流程内建：
  • Workflow 中强制跑测试
  • 不通过 gate 不允许进入下一阶段（例如 review/PR）

测开含义：

• 你们可以把“质量门禁”固化为 workflow：
  • 单测覆盖率阈值
  • OpenAPI/JSON Schema contract 校验
  • 关键接口的幂等/权限回归
  • Playwright 关键路径回放

2.3 趋势 3：规则/指南类仓库在“降风险”上的性价比极高​

• andrej-karpathy-skills 与 claude-code-best-practice 都在用“文本规则/模板”约束 LLM。

测开含义：

• 很多 AI 工程风险不是模型能力不足，而是：
  • 默认假设太多
  • 改动范围太大
  • 没有可验证的成功标准

把这些写进 CLAUDE.md / Agent workflow，会直接提升可测性与可回归性。

3. 对测试工作、自动化架构设计、可测性评估的启发（按“可操作动作”组织）​

3.1 把“可测性”当产品能力，而不是测试团队的补丁​

从这些项目抽取出的共性做法：

1. 结构化输出优先：能 JSON Schema 就不要纯自然语言。
2. 每一步可追溯：计划、工具调用参数、外部依赖版本、最终输出要能回放。
3. 显式的验证 Gate：workflow 中强制执行，不靠“人记得”。

落地建议（适配你当前技术栈）：

• 后端（Golang + Ginkgo）：
  • Contract test（OpenAPI / JSON Schema）
  • 工具 API 幂等性、超时、重试、权限边界
• 前端（Playwright）：
  • 关键对话流/关键任务流回放
  • 对流式输出做“最终一致性”断言（不是逐 token）

3.2 “AI Agent 产品”的测试对象分层（建议你们评审项目时用这张清单）​

把一个 Agent 系统拆成 5 层，测试策略就不会散：

1. 协议层：HTTP/WebSocket/MCP、鉴权、错误码、重试语义
2. 编排层：状态机/Workflow、回滚、并发、队列/任务生命周期
3. 工具层（Tooling）：每个 tool 的 contract、幂等、权限、降级
4. 模型层：prompt/model version、温度/采样、输出结构约束
5. 数据层（RAG/记忆/技能库）：召回/排序回归、索引一致性、数据权限

用这套分层去看今天的项目：

• Archon：编排层做得最“工程化”（YAML workflow + gates）。
• Multica：编排层 + 运营层强（生命周期、WebSocket 进度、Workspaces）。
• markitdown：工具层强（标准化输入→Markdown，并且 MCP 化）。
• Hermes Agent：更像“可运行的 Agent 产品”，覆盖跨渠道与长期运行。
• 规则/最佳实践类：提升模型层/协作层的可测性（减少不可预测改动）。

3.3 可测性评估：你可以用 8 个问题快速给项目打分​

评审一个 AI Agent/平台项目（或你们自研系统）时，建议直接问：

1. 是否支持 trace_id 全链路贯穿？
2. 是否有 确定性回放（输入相同 + 依赖固定 = 输出稳定）？
3. Tool 调用是否有 schema/contract（入参/出参/错误码）？
4. 是否能把模型当依赖进行 Mock/录制回放？
5. 是否具备 失败可恢复（任务失败原因可定位，能重试/续跑）？
6. 是否有 权限隔离（workspace/user/tool scope）？
7. 关键行为是否 可审计（日志、事件流、配置变更）？
8. 是否有 自动化 Gate（测试/静态检查/安全检查）内置到流程？

4. 可落地的行动指南（Ginkgo + Playwright 视角）​

4.1 建议的仓库结构（把评测/回放当一等公民）​

ai_agent_quality/
  datasets/
    eval_cases.jsonl          # 问题-期望-断言规则
  replays/
    golden/                   # 回放基线（依赖已固定）
    latest/                   # 本次构建回放
  contracts/
    tool_schemas/             # 工具入参/出参 JSON Schema
  reports/
    diff/                     # 差分报告（golden vs latest）

4.2 后端（Golang Ginkgo）：三类测试优先级最高​

1. Tool API Contract（必做）
   • OpenAPI/JSON Schema 校验
   • 错误码稳定、字段稳定
2. 幂等性/重试语义（强烈建议）
   • 网络抖动、超时重试不能产生重复副作用
3. 权限边界（必须覆盖）
   • workspace 隔离
   • tool scope、数据权限

4.3 前端（Playwright）：不要只测“能不能聊”，要测“能不能做完事”​

围绕“任务生命周期”断言 UI：

• enqueue → claim → start → complete/fail
• 出错时用户可理解、可重试、可查看详情
• 流式输出：断言最终消息 + 关键结构化字段，不要对 token 序列做脆弱断言

4.4 把 Archon / Multica 的思想迁移到你们自己的 CI​

• 如果你们已有 CI：
  • 把“评测/回放/差分报告”加成一个固定 stage
  • prompt/model/tool 列表一变化就触发
• 如果你们还在探索：
  • 先做一个最小可用 deterministic harness：
    • 固定一组关键用例
    • 固定外部依赖（Mock/录制）
    • 固定断言规则（结构化 + golden）

5. 附录：本次抓取到的 Top 6 项目清单​

• NousResearch/hermes-agent — https://github.com/NousResearch/hermes-agent
• microsoft/markitdown — https://github.com/microsoft/markitdown
• coleam00/Archon — https://github.com/coleam00/Archon
• forrestchang/andrej-karpathy-skills — https://github.com/forrestchang/andrej-karpathy-skills
• multica-ai/multica — https://github.com/multica-ai/multica
• shanraisshan/claude-code-best-practice — https://github.com/shanraisshan/claude-code-best-practice

如果你希望我把这份报告再进一步“贴近你们团队的现状”，你可以补充两点信息：

1. 你们当前 Agent 产品形态（B 端控制台 / C 端聊天 / API 服务 / 混合）
2. 你们目前最痛的质量问题（例如：幻觉、工具误用、RAG 引用不准、长链路不稳定、权限边界等） 我可以据此把第 3、4 节改成更具体的“你们项目下一周可以落地的任务拆分”。

AI 架构与趋势​

今日结构分布（粗分类）​

• AI Agent / 编排框架: 5 个
• 其他 / 待分类: 1 个

热门项目速览​

1. microsoft/markitdown​

• 链接：https://github.com/microsoft/markitdown
• 归类：AI Agent / 编排框架
• Stars：99624
• 主要语言：Python
• Topics：autogen, autogen-extension, langchain, markdown, microsoft-office, openai, pdf
• 项目特色（基于 description/README 片段的轻量提炼）：
  • Python tool for converting files and office documents to Markdown.
  • PowerPoint
  • Images (EXIF metadata and OCR)
  • Audio (EXIF metadata and speech transcription)

2. coleam00/Archon​

• 链接：https://github.com/coleam00/Archon
• 归类：AI Agent / 编排框架
• Stars：15583
• 主要语言：TypeScript
• Topics：ai, automation, bun, claude, cli, coding-assistant, developer-tools, typescript, workflow-engine, yaml
• 项目特色（基于 description/README 片段的轻量提炼）：
  • The first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.
  • Repeatable - Same workflow, same sequence, every time. Plan, implement, validate, review, PR.
  • Isolated - Every workflow run gets its own git worktree. Run 5 fixes in parallel with no conflicts.
  • Fire and forget - Kick off a workflow, go do other work. Come back to a finished PR with review comments.
  • Composable - Mix deterministic nodes (bash scripts, tests, git ops) with AI nodes (planning, code generation, review). The AI only runs where it adds value.
  • Portable - Define workflows once in .archon/workflows/, commit them to your repo. They work the same from CLI, Web UI, Slack, Telegram, or GitHub.

3. NousResearch/hermes-agent​

• 链接：https://github.com/NousResearch/hermes-agent
• 归类：AI Agent / 编排框架
• Stars：51814
• Topics：ai, openai, hermes, codex, ai-agents, claude, ai-agent, llm, chatgpt, anthropic, claude-code, clawdbot
• 项目特色（基于 description/README 片段的轻量提炼）：
  • The agent that grows with you. Contribute to NousResearch/hermes-agent development by creating an account on GitHub.

4. rowboatlabs/rowboat​

• 链接：https://github.com/rowboatlabs/rowboat
• 归类：AI Agent / 编排框架
• Stars：11716
• 主要语言：TypeScript
• Topics：agents, agents-sdk, ai, ai-agents, ai-agents-automation, chatgpt, claude-code, claude-cowork, generative-ai, llm, multiagent, opeani
• 项目特色（基于 description/README 片段的轻量提炼）：
  • Open-source AI coworker, with memory
  • Build me a deck about our next quarter roadmap → generates a PDF using context from your knowledge graph
  • Prep me for my meeting with Alex → pulls past decisions, open questions, and relevant threads into a crisp brief (or a voice note)
  • Track a person, company or topic through live notes
  • Visualize, edit, and update your knowledge graph anytime (it’s just Markdown)
  • Record voice memos that automatically capture and update key takeaways in the graph

5. multica-ai/multica​

• 链接：https://github.com/multica-ai/multica
• 归类：AI Agent / 编排框架
• Stars：6028
• 主要语言：TypeScript
• 项目特色（基于 description/README 片段的轻量提炼）：
  • The open-source managed agents platform. Turn coding agents into real teammates — assign tasks, track progress, compound skills.

6. forrestchang/andrej-karpathy-skills​

• 链接：https://github.com/forrestchang/andrej-karpathy-skills
• 归类：其他 / 待分类
• Stars：11698
• 项目特色（基于 description/README 片段的轻量提炼）：
  • A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.

对日常 QA 工作的工程化启发（如何测试此类架构）​

1) 面向 AI Agent 产品质量的通用原则​

• 把 LLM 当作不可控依赖：测试要尽可能确定性（Mock/回放/固定评测集），线上靠观测性兜底。
• 优先把输出结构化：JSON Schema / 受控枚举 / error code，让断言从‘主观’变成‘可自动化判定’。
• 关键路径必须可回放：对话、工具调用、检索命中、模型版本，都要可复现。

2) 按架构类型给测试策略（可直接套用）​

AI Agent / 编排框架​

• 将“正确性”拆成：接口契约正确 + 业务规则正确 + 模型/提示词行为可控 + 观测性可追溯。
• 默认把 LLM 视为“不确定的外部依赖”，用 Mock/录制回放/固定种子/评测集来把测试变成确定性。
• 把可测性当作架构能力：强制结构化输出（JSON Schema）、明确错误码、全链路 trace_id。
• 重点测：工具调用（tool/function calling）分支覆盖、状态机/工作流回滚、长链路超时与重试策略。
• 用 Golang Ginkgo 做后端校验：对每个工具 API 做 contract test + 幂等性测试 + 权限边界测试。
• 把关键对话流固化成“场景回放测试”：同一输入在固定依赖下输出必须稳定（snapshot / golden）。

其他 / 待分类​

• 将“正确性”拆成：接口契约正确 + 业务规则正确 + 模型/提示词行为可控 + 观测性可追溯。
• 默认把 LLM 视为“不确定的外部依赖”，用 Mock/录制回放/固定种子/评测集来把测试变成确定性。
• 把可测性当作架构能力：强制结构化输出（JSON Schema）、明确错误码、全链路 trace_id。
• 类别不明时，先做‘接口可测性体检’：输入输出结构、错误处理、日志与追踪、可 Mock 的依赖边界。

3) Golang Ginkgo 后端校验：最小可用模板​

以下片段用于说明思路（按你们的框架/路由替换即可）：

package api_test

import (
  "net/http"
  "github.com/onsi/ginkgo/v2"
  "github.com/onsi/gomega"
)

var _ = ginkgo.Describe("Tool API Contract", func() {
  ginkgo.It("should return stable JSON schema for success", func() {
    resp, err := http.Get("http://localhost:8080/api/tool/foo?x=1")
    gomega.Expect(err).ToNot(gomega.HaveOccurred())
    gomega.Expect(resp.StatusCode).To(gomega.Equal(http.StatusOK))
    // TODO: 读取 body 做 JSON Schema 校验 / 字段断言
  })
})

4) Playwright 端到端自动化：关键路径回放模板​

import { test, expect } from '@playwright/test';

test('chat streaming should be stable', async ({ page }) => {
  await page.goto('https://your-console.example.com');
  // TODO: 登录

  await page.getByRole('textbox', { name: '输入' }).fill('解释一下这个项目的核心能力');
  await page.getByRole('button', { name: '发送' }).click();

  // 关键：对流式输出做“最终一致性”断言
  await expect(page.getByTestId('assistant-message').last()).toContainText('核心');
});

可落地的行动指南（如何在现有自动化框架中应用）​

1. 在现有自动化仓库中新建 ai_agent_quality/ 目录，沉淀：评测集、对话回放用例、golden snapshots。
2. 为后端（Golang）增加 Ginkgo 套件：

• Contract tests（OpenAPI/JSON Schema）
• 工具 API 幂等性 + 权限边界
• 关键业务规则的 table-driven tests

3. 为前端/控制台增加 Playwright 套件：

• 关键路径回放（含流式输出断言）
• 断网/慢网/重试场景
• 可访问性（a11y）与错误提示一致性

4. 把 LLM 依赖抽象为 Provider 接口：测试环境默认 Mock（录制回放），必要时才走真实模型。
5. 建立‘变更影响面’机制：prompt/模型/检索策略/工具列表任一变化，都要触发评测回归 + 差分报告。

附：生成数据说明​

• 数据源：GitHub Trending +（优先）GitHub REST API；API 受限时自动降级为抓取 GitHub Repo HTML 页面
• 说明：AI 过滤与分类为规则驱动，可按团队需求持续迭代；如需更智能的总结，可在此报告基础上再做人工/LLM 精炼。

日期：2026-04-11（周六）
学习计划来源：AI_QA_Learning_Plan.md
进度判断：已完成 Day 1: LLM 基础，因此今天顺延学习 Day 2（不重复 Day 1）。

0. 今日目标（你学完应该能做到什么）​

1. 分清并掌握三类 Prompt 范式：Zero-shot、Few-shot、CoT（思维链）。
2. 能从「测开/QA」视角理解：
   • 为什么 Prompt 是“测试对象”（SUT）的关键组成部分；
   • Prompt 的变更如何引入回归风险；
   • 如何为 Prompt 设计可自动化的评测与回归用例。
3. 完成一个可落地的实践：
   • 设计一个 面向 ArkClaw 接口的 Few-shot 测试用例生成 Prompt；
   • 给出 Python / Go 两套最小可用的测试代码（用于校验输出结构、稳定性、覆盖性）。

1. 核心理论知识讲解​

1.1 Zero-shot：直接下指令，靠模型“通用能力”解题​

定义：不给示例，只描述任务与约束，让模型直接生成答案。

典型结构：

• 角色（可选）：你是资深测试开发/接口测试专家
• 任务：针对某 API 生成测试用例
• 约束：输出格式、字段要求、覆盖维度
• 质量标准：至少 N 条、必须包含异常/边界/鉴权/幂等等

优点：

• 成本低、Prompt 短、迭代快；
• 适合“标准化程度高”的任务（例如：提取字段、翻译、总结）。

风险 / 缺点（测开特别要关心）：

• 输出波动大：同样输入，模型可能换风格、换字段名、遗漏关键覆盖点；
• 隐性假设多：你没说清楚的地方，模型会“自行补完”，而补完内容可能不符合你系统的真实约束；
• 难以回归：一旦模型升级/温度参数变化，Zero-shot 更容易出现“风格漂移”。

适用建议：

• 当你已经有很强的结构化约束（如 JSON Schema、正则、工具校验），Zero-shot 才更稳。

1.2 Few-shot：用“示例”把模型拉回你期望的分布​

定义：给模型 1~N 个输入输出示例（shots），让它“照着学”。

Few-shot 的本质（把它当成测试工程问题更好理解）:

• 你在提供 参考实现（reference behavior）；
• 你在指定 风格、字段、覆盖偏好；
• 你在做“软约束的规范化”。

优点：

• 明显提升：输出结构稳定性、字段一致性、覆盖维度一致性；
• 对“领域任务”更友好（例如：你内部系统的接口命名/错误码/字段语义）。

风险 / 缺点：

• 示例质量决定上限：示例写得差，模型会把坏习惯学走；
• 示例偏置：示例覆盖了 A 类异常却没覆盖 B 类，模型会倾向继续产出 A 类；
• Token 成本与维护成本：示例越多，调用成本越高；示例还需要版本管理（像测试基线一样）。

Few-shot 设计经验（QA 视角）：

1. 示例要覆盖“你最在乎的风险点”，比如：鉴权、边界、异常码、幂等、并发；
2. 示例必须是“可验证的结构”：建议统一输出 JSON，并在代码里做 schema 校验；
3. 示例要体现“同类项的一致性”：字段名、枚举值、case 命名规则、优先级规则。

1.3 CoT（Chain-of-Thought，思维链）：让模型把推理过程写出来​

定义：引导模型先推理、再给答案。常见形式是：

• “请一步步思考…”
• “先分析输入，再输出结论…”

重要提醒（工程落地的真实情况）：

• 在很多线上产品中，我们并不希望暴露“推理过程”（安全与成本考虑）；
• 但在离线评测/测试生成场景，CoT 非常有价值，因为它能：
  1. 提升复杂任务准确率；
  2. 给 QA 提供“为何这么生成”的可解释线索；
  3. 帮助定位 Prompt 失败点（模型在哪一步误解了输入）。

CoT 的替代工程做法：

• 使用“隐藏推理 + 只输出结果”的策略（不同模型/平台支持不同）；
• 或采用“先生成分析草稿，再让模型自我压缩成结构化结果”的两段式流程。

2. 测开视角：Prompt 也是代码（需要测试、需要版本化）​

把 Prompt 当成“代码”的原因：

1. Prompt 会直接决定系统行为：尤其是“生成测试用例、生成 SQL、生成配置”的场景。
2. Prompt 的改动本质上是“逻辑改动”，会引入回归。
3. Prompt 的质量可以被量化：
   • 结构正确率：输出是否可解析、字段是否齐全
   • 覆盖度：是否包含异常/边界/鉴权/幂等/并发
   • 稳定性：相似输入多次运行输出的一致性（或可接受的差异范围）
   • 有效性：生成的测试用例是否能在真实系统中执行并发现问题

这也是 AI QA 的关键能力：把“自然语言产物”纳入工程化质量体系。

3. 工程实践：设计 ArkClaw 接口 Few-shot 测试用例生成 Prompt​

说明：我这里用“接口契约（API Contract）”作为输入。你可以替换成 ArkClaw 实际接口文档字段。

3.1 目标输出规范（建议先定输出，再写 Prompt）​

我们把模型输出固定成 JSON，便于自动化校验与回归：

{
  "api": {
    "name": "string",
    "method": "GET|POST|PUT|DELETE",
    "path": "string"
  },
  "testcases": [
    {
      "id": "TC-001",
      "title": "string",
      "priority": "P0|P1|P2",
      "category": "happy_path|boundary|negative|auth|idempotency|concurrency|compatibility",
      "precondition": "string",
      "steps": ["string"],
      "request": {
        "headers": {"k": "v"},
        "query": {"k": "v"},
        "body": {"k": "v"}
      },
      "expected": {
        "http_status": 200,
        "body_contains": ["string"],
        "error_code": "string"
      }
    }
  ]
}

为什么这么做（测开理由）：

• JSON 可解析 → 适合做 CI 回归；
• 字段固定 → 可做 schema 校验；
• category/priority → 便于统计覆盖与分层执行；
• expected 结构化 → 便于比对与断言。

3.2 Prompt 模板（Few-shot）​

下面是一份可直接投入使用的 Prompt（你可以把它当作“测试用例生成器”的 Spec）。

推荐把它放进 Git，并给每次变更打 Tag（像管理接口测试脚本一样）。

你是一名资深测试开发工程师（Test Dev），擅长接口测试与质量保障。

【任务】
根据给定的 API 契约信息，为该接口生成高质量的接口测试用例。

【输出要求】
1) 只能输出 JSON，禁止输出任何解释性文字。
2) JSON 必须符合以下约束：
   - 顶层包含 api 与 testcases
   - testcases 至少 8 条
   - 必须覆盖：happy_path、boundary、negative、auth、idempotency（如适用）
   - 每条用例包含：id/title/priority/category/precondition/steps/request/expected
3) 用例必须可执行、步骤清晰、断言可检验。
4) 不要编造不存在的字段；如果契约未给出字段，请在 request 中留空对象（{}）。

【Few-shot 示例 1】
输入(API Contract):
{
  "name": "CreateRule",
  "method": "POST",
  "path": "/api/v1/rules",
  "headers": {"Authorization": "Bearer <token>"},
  "body_schema": {
    "rule_name": "string (1~64)",
    "severity": "enum: LOW|MEDIUM|HIGH",
    "enabled": "boolean"
  },
  "success": {"http_status": 200, "body": {"rule_id": "string"}},
  "errors": [
    {"http_status": 400, "error_code": "INVALID_PARAM"},
    {"http_status": 401, "error_code": "UNAUTHORIZED"}
  ]
}
输出(JSON):
{ ...（此处省略，见你的真实示例库） ... }

【Few-shot 示例 2】
输入(API Contract):
{
  "name": "GetRule",
  "method": "GET",
  "path": "/api/v1/rules/{rule_id}",
  "headers": {"Authorization": "Bearer <token>"},
  "path_params": {"rule_id": "string"},
  "success": {"http_status": 200, "body": {"rule_id": "string", "rule_name": "string"}},
  "errors": [
    {"http_status": 404, "error_code": "NOT_FOUND"},
    {"http_status": 401, "error_code": "UNAUTHORIZED"}
  ]
}
输出(JSON):
{ ...（此处省略，见你的真实示例库） ... }

【现在请处理】
输入(API Contract):
{{API_CONTRACT_JSON}}

关键点解释（你写 Prompt 时应该有的“测试意识”）​

• “只能输出 JSON”：减少花式输出导致的解析失败；
• “至少 8 条 + 必须覆盖类别”：把覆盖要求显式化，避免模型偷懒；
• “不要编造字段”：防止模型编造不存在的参数，导致用例不可执行；
• Few-shot 示例库建议落库：示例 1/2 不应该“省略”，而应该沉淀为你们团队的基线样本。

3.3 示例：给一个“假想 ArkClaw 接口”生成用例（输入样例）​

{
  "name": "ValidateCase",
  "method": "POST",
  "path": "/api/v1/qa/cases/validate",
  "headers": {"Authorization": "Bearer <token>", "Content-Type": "application/json"},
  "body_schema": {
    "case_title": "string (1~120)",
    "steps": "array<string> (1~30)",
    "expected": "string (1~500)",
    "tags": "array<string> (0~10)"
  },
  "success": {"http_status": 200, "body": {"valid": "boolean", "issues": "array<string>"}},
  "errors": [
    {"http_status": 400, "error_code": "INVALID_PARAM"},
    {"http_status": 401, "error_code": "UNAUTHORIZED"}
  ]
}

你把它替换进 {{API_CONTRACT_JSON}}，就能得到结构化用例。

4. 自动化校验（Python）：用 Pydantic + pytest 做“Prompt 回归测试”​

目标：不依赖真实大模型 Key，也能先把“输出结构正确性”与“覆盖要求”自动化。

4.1 Pydantic Schema（结构校验）​

# file: prompt_case_schema.py
from typing import Dict, List, Literal, Optional
from pydantic import BaseModel, Field


Priority = Literal["P0", "P1", "P2"]
Category = Literal[
    "happy_path",
    "boundary",
    "negative",
    "auth",
    "idempotency",
    "concurrency",
    "compatibility",
]


class APIInfo(BaseModel):
    name: str
    method: Literal["GET", "POST", "PUT", "DELETE"]
    path: str


class Request(BaseModel):
    headers: Dict[str, str] = Field(default_factory=dict)
    query: Dict[str, object] = Field(default_factory=dict)
    body: Dict[str, object] = Field(default_factory=dict)


class Expected(BaseModel):
    http_status: int
    body_contains: List[str] = Field(default_factory=list)
    error_code: Optional[str] = None


class TestCase(BaseModel):
    id: str
    title: str
    priority: Priority
    category: Category
    precondition: str
    steps: List[str]
    request: Request
    expected: Expected


class CaseGenOutput(BaseModel):
    api: APIInfo
    testcases: List[TestCase]

4.2 pytest：覆盖类别与数量校验​

# file: test_prompt_output_contract.py
import json
import pytest

from prompt_case_schema import CaseGenOutput

REQUIRED_CATEGORIES = {"happy_path", "boundary", "negative", "auth", "idempotency"}


def validate_contract(output_json_str: str) -> CaseGenOutput:
    data = json.loads(output_json_str)
    return CaseGenOutput.model_validate(data)


def test_output_has_min_cases():
    # 这里先用一份“已保存的模型输出快照”作为 fixture
    # 真实落地时：你可以把 LLM 输出保存到 snapshots/ 下做回归
    output_json_str = open("snapshots/validate_case.output.json", "r", encoding="utf-8").read()

    parsed = validate_contract(output_json_str)
    assert len(parsed.testcases) >= 8


def test_output_covers_required_categories():
    output_json_str = open("snapshots/validate_case.output.json", "r", encoding="utf-8").read()
    parsed = validate_contract(output_json_str)

    cats = {tc.category for tc in parsed.testcases}
    missing = REQUIRED_CATEGORIES - cats
    assert not missing, f"missing categories: {missing}"  # 回归失败时一眼定位


@pytest.mark.parametrize("bad_json", ["", "not json", "{}"])
def test_invalid_output_rejected(bad_json):
    with pytest.raises(Exception):
        validate_contract(bad_json)

4.3 进一步增强（建议你后续加上）​

• 稳定性测试：同一输入运行 N 次，统计：
  • JSON 解析成功率
  • 必选类别覆盖率
  • 用例条数分布
• 内容有效性测试：将生成用例真正打到测试环境（或 mock server），验证断言可执行。

5. 自动化校验（Go）：表驱动测试 + 结构解析，做轻量回归门禁​

目标：在 Go 服务/CI 里也能快速做结构门禁（尤其适合你们已有 Go 测试体系的团队）。

5.1 定义结构体 + 必选类别校验​

// file: promptcase/output.go
package promptcase

type Output struct {
	API       APIInfo    `json:"api"`
	Testcases []TestCase `json:"testcases"`
}

type APIInfo struct {
	Name   string `json:"name"`
	Method string `json:"method"`
	Path   string `json:"path"`
}

type TestCase struct {
	ID       string   `json:"id"`
	Title    string   `json:"title"`
	Priority string   `json:"priority"`
	Category string   `json:"category"`
	Precond  string   `json:"precondition"`
	Steps    []string `json:"steps"`
	Request  Request  `json:"request"`
	Expected Expected `json:"expected"`
}

type Request struct {
	Headers map[string]string `json:"headers"`
	Query   map[string]any    `json:"query"`
	Body    map[string]any    `json:"body"`
}

type Expected struct {
	HTTPStatus   int      `json:"http_status"`
	BodyContains []string `json:"body_contains"`
	ErrorCode    string   `json:"error_code"`
}

5.2 Go 单测：最小门禁（数量 + 类别）​

// file: promptcase/output_test.go
package promptcase

import (
	"encoding/json"
	"os"
	"testing"
)

func TestOutputContract(t *testing.T) {
	b, err := os.ReadFile("../snapshots/validate_case.output.json")
	if err != nil {
		t.Fatalf("read snapshot: %v", err)
	}

	var out Output
	if err := json.Unmarshal(b, &out); err != nil {
		t.Fatalf("unmarshal json: %v", err)
	}

	if len(out.Testcases) < 8 {
		t.Fatalf("want >= 8 testcases, got %d", len(out.Testcases))
	}

	required := map[string]bool{
		"happy_path":  false,
		"boundary":    false,
		"negative":    false,
		"auth":        false,
		"idempotency": false,
	}

	for _, tc := range out.Testcases {
		if _, ok := required[tc.Category]; ok {
			required[tc.Category] = true
		}
	}

	for k, v := range required {
		if !v {
			t.Fatalf("missing required category: %s", k)
		}
	}
}

这类 Go 门禁很适合做成：

• PR 阶段的“Prompt 基线变更必须通过”检查；
• 或者作为 nightly job 做输出漂移监控。

6. 课后小思考（建议写在你的学习笔记里，形成“可复盘资产”）​

1. 你现在团队里有哪些“自然语言资产”其实也应该被测试？
   例如：测试设计模板、缺陷复现步骤模板、上线 checklist、故障通告模板。

2. 如果明天把模型从 A 升级到 B，你觉得你最想先跑哪 3 类回归？为什么？

3. Few-shot 示例库应该由谁维护？

   • QA 维护：更关注覆盖与可执行性；
   • RD 维护：更贴近真实接口语义；
   • 或者联合维护（推荐）。

4. 你会如何定义“Prompt 的稳定性”？

   • 完全一致（过于严格）
   • 结构一致 + 关键断言一致（更工程化）
   • 允许风格变化但覆盖不变（更适合生成类任务）

7. 今日可交付产物（建议你顺手落库）​

• prompts/arkclaw_casegen_fewshot.prompt.txt：Few-shot Prompt 模板（纳入版本管理）
• snapshots/：固定输入下的输出快照（用于回归）
• tests/：Python（pytest）与 Go（go test）的合同测试（contract test）

如果你愿意，我也可以基于你们真实的 ArkClaw 接口文档（字段/错误码/鉴权方式）把 Few-shot 示例 1/2 补齐成“可直接用的示例库”。

今天的早报分两部分：

1. GitHub Trending：从测试开发（QA/测开）视角，提炼 AI 项目形态与可落地的工程化测试启发。
2. AI Builders Digest：追踪建造者动态（仅基于中心化 feed JSON 做整理/摘要；不访问外链，不杜撰）。

GitHub Trending（测开视角）​

AI 架构与趋势​

今日结构分布（粗分类）​

• AI Agent / 编排框架: 4 个
• 其他 / 待分类: 4 个

热门项目速览​

1. NousResearch/hermes-agent​

• 链接：https://github.com/NousResearch/hermes-agent
• 归类：AI Agent / 编排框架
• Stars：47083
• Topics：ai, openai, hermes, codex, ai-agents, claude, ai-agent, llm, chatgpt, anthropic, claude-code, clawdbot
• 项目特色（基于 description/README 片段的轻量提炼）：
  • The agent that grows with you. Contribute to NousResearch/hermes-agent development by creating an account on GitHub.

2. forrestchang/andrej-karpathy-skills​

• 链接：https://github.com/forrestchang/andrej-karpathy-skills
• 归类：其他 / 待分类
• Stars：10920
• 项目特色（基于 description/README 片段的轻量提炼）：
  • A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.

3. HKUDS/DeepTutor​

• 链接：https://github.com/HKUDS/DeepTutor
• 归类：AI Agent / 编排框架
• Stars：15277
• Topics：interactive-learning, multi-agent-systems, ai-agents, cli-tool, rag, large-language-models, ai-tutor, deepresearch, clawdbot
• 项目特色（基于 description/README 片段的轻量提炼）：
  • "DeepTutor: Agent-Native Personalized Learning Assistant" - HKUDS/DeepTutor

4. OpenBMB/VoxCPM​

• 链接：https://github.com/OpenBMB/VoxCPM
• 归类：其他 / 待分类
• Stars：7954
• Topics：audio, multilingual, python, text-to-speech, speech, pytorch, tts, speech-synthesis, deeplearning, voice-cloning, voice-design, tts-model
• 项目特色（基于 description/README 片段的轻量提炼）：
  • VoxCPM2: Tokenizer-Free TTS for Multilingual Speech Generation, Creative Voice Design, and True-to-Life Cloning - OpenBMB/VoxCPM

5. obra/superpowers​

• 链接：https://github.com/obra/superpowers
• 归类：AI Agent / 编排框架
• Stars：144334
• 项目特色（基于 description/README 片段的轻量提炼）：
  • An agentic skills framework & software development methodology that works. - obra/superpowers

6. TheCraigHewitt/seomachine​

• 链接：https://github.com/TheCraigHewitt/seomachine
• 归类：其他 / 待分类
• Stars：5338
• 项目特色（基于 description/README 片段的轻量提炼）：
  • A specialized Claude Code workspace for creating long-form, SEO-optimized blog content for any business. This system helps you research, write, analyze, and optimize content that ranks well and ser...

7. coleam00/Archon​

• 链接：https://github.com/coleam00/Archon
• 归类：AI Agent / 编排框架
• Stars：14596
• Topics：cli, yaml, automation, typescript, ai, workflow-engine, developer-tools, bun, claude, coding-assistant
• 项目特色（基于 description/README 片段的轻量提炼）：
  • The first open-source harness builder for AI coding. Make AI coding deterministic and repeatable. - coleam00/Archon

8. YishenTu/claudian​

• 链接：https://github.com/YishenTu/claudian
• 归类：其他 / 待分类
• Stars：7012
• Topics：productivity, ide, obsidian, obsidian-plugin, claude-code
• 项目特色（基于 description/README 片段的轻量提炼）：
  • An Obsidian plugin that embeds Claude Code as an AI collaborator in your vault - YishenTu/claudian

对日常 QA 工作的工程化启发（如何测试此类架构）​

1) 面向 AI Agent 产品质量的通用原则​

• 把 LLM 当作不可控依赖：测试要尽可能确定性（Mock/回放/固定评测集），线上靠观测性兜底。
• 优先把输出结构化：JSON Schema / 受控枚举 / error code，让断言从‘主观’变成‘可自动化判定’。
• 关键路径必须可回放：对话、工具调用、检索命中、模型版本，都要可复现。

2) 按架构类型给测试策略（可直接套用）​

AI Agent / 编排框架​

• 将“正确性”拆成：接口契约正确 + 业务规则正确 + 模型/提示词行为可控 + 观测性可追溯。
• 默认把 LLM 视为“不确定的外部依赖”，用 Mock/录制回放/固定种子/评测集来把测试变成确定性。
• 把可测性当作架构能力：强制结构化输出（JSON Schema）、明确错误码、全链路 trace_id。
• 重点测：工具调用（tool/function calling）分支覆盖、状态机/工作流回滚、长链路超时与重试策略。
• 用 Golang Ginkgo 做后端校验：对每个工具 API 做 contract test + 幂等性测试 + 权限边界测试。
• 把关键对话流固化成“场景回放测试”：同一输入在固定依赖下输出必须稳定（snapshot / golden）。

其他 / 待分类​

• 将“正确性”拆成：接口契约正确 + 业务规则正确 + 模型/提示词行为可控 + 观测性可追溯。
• 默认把 LLM 视为“不确定的外部依赖”，用 Mock/录制回放/固定种子/评测集来把测试变成确定性。
• 把可测性当作架构能力：强制结构化输出（JSON Schema）、明确错误码、全链路 trace_id。
• 类别不明时，先做‘接口可测性体检’：输入输出结构、错误处理、日志与追踪、可 Mock 的依赖边界。

3) Golang Ginkgo 后端校验：最小可用模板​

以下片段用于说明思路（按你们的框架/路由替换即可）：

package api_test

import (
  "net/http"
  "github.com/onsi/ginkgo/v2"
  "github.com/onsi/gomega"
)

var _ = ginkgo.Describe("Tool API Contract", func() {
  ginkgo.It("should return stable JSON schema for success", func() {
    resp, err := http.Get("http://localhost:8080/api/tool/foo?x=1")
    gomega.Expect(err).ToNot(gomega.HaveOccurred())
    gomega.Expect(resp.StatusCode).To(gomega.Equal(http.StatusOK))
    // TODO: 读取 body 做 JSON Schema 校验 / 字段断言
  })
})

4) Playwright 端到端自动化：关键路径回放模板​

import { test, expect } from '@playwright/test';

test('chat streaming should be stable', async ({ page }) => {
  await page.goto('https://your-console.example.com');
  // TODO: 登录

  await page.getByRole('textbox', { name: '输入' }).fill('解释一下这个项目的核心能力');
  await page.getByRole('button', { name: '发送' }).click();

  // 关键：对流式输出做“最终一致性”断言
  await expect(page.getByTestId('assistant-message').last()).toContainText('核心');
});

可落地的行动指南（如何在现有自动化框架中应用）​

1. 在现有自动化仓库中新建 ai_agent_quality/ 目录，沉淀：评测集、对话回放用例、golden snapshots。
2. 为后端（Golang）增加 Ginkgo 套件：

• Contract tests（OpenAPI/JSON Schema）
• 工具 API 幂等性 + 权限边界
• 关键业务规则的 table-driven tests

3. 为前端/控制台增加 Playwright 套件：

• 关键路径回放（含流式输出断言）
• 断网/慢网/重试场景
• 可访问性（a11y）与错误提示一致性

4. 把 LLM 依赖抽象为 Provider 接口：测试环境默认 Mock（录制回放），必要时才走真实模型。
5. 建立‘变更影响面’机制：prompt/模型/检索策略/工具列表任一变化，都要触发评测回归 + 差分报告。

附：生成数据说明​

• 数据源：GitHub Trending +（优先）GitHub REST API；API 受限时自动降级为抓取 GitHub Repo HTML 页面
• 说明：AI 过滤与分类为规则驱动，可按团队需求持续迭代；如需更智能的总结，可在此报告基础上再做人工/LLM 精炼。

AI Builders Digest​

AI Builders Digest — 2026-04-10

⚠️ 本次 Follow Builders 的部分 feed 拉取失败（可能是网络原因）。以下为错误摘要：

• Could not fetch blog feed

X / TWITTER​

Josh Woodward (VP, Google GoogleLabs GeminiApp GoogleAIStudio)​

• Most Al chatbots give you basic "projects." Gemini just built you a second brain. 🧠 Introducing Notebooks: some of the magic from NotebookLM, integrated directly into GeminiApp. Here's what changes for you today: 📚 Upload 100 sources for free 📂 Organize your chats - the wait is officially over :) 🔄 Sources, chats, and emojis sync People are using Gemini and NotebookLM in tandem, and we'll keep building both. To manage capacity, we're rolling this out NOW on the web and going from Ultra ➡️ Pro ➡️ Plus ➡️ Free. (Mobile, EU, and Workspace are up next!) With Google I/O right around the corner, we are just getting started. Enjoy!

链接：https://x.com/joshwoodward/status/2041982173402821018

Kevin Weil (VP Science OpenAI, BoD Cisco nature_org, LTC USArmyReserve​

Ex: Pres Planet, Head of Product Instagram Twitter ❤️ elizabeth ultramarathons kids cats math)

• Five Erdos problems at once! The proofs are getting more elegant as the models improve 👀 https://t.co/imzDQJyQbC

链接：https://x.com/kevinweil/status/2042073869880848481

Peter Yang (I share extremely practical AI tutorials and interviews | Join 140K+ readers at https://t.co/XYKTmGVH14 | Product at Roblox)​

• Titles don’t matter https://t.co/K8RtB3B4Wr
• Support my friend Aadit's new company - great name btw :) https://t.co/rc1WgqG5p1
• As much as I love using Claude Max and ChatGPT Pro, I don't think these all-you-can-use AI subscriptions will last forever. Here's my new deep dive that covers: → Why Anthropic cut off OpenClaw access → How to run local models on your Mac → What I'm seeing on the ground in China 📌 Read now: https://t.co/cm9jYIZS8y

链接：https://x.com/petergyang/status/2042118898603192489 · https://x.com/petergyang/status/2041996329703092582 · https://x.com/petergyang/status/2041989206495653915

Thariq (Claude Code anthropicai. prev YC W20, mit media lab.​

towards machines of loving grace)

• would like to start with people I know already so we can get over initial awkwardness!
• I want to do some streams where I work with non-technical people using Claude Code to figure out how they might be able to improve their process. My feeling is that just a few tips could make a big difference in efficiency. Any mutuals interested?
• The docs are a gold mine, read more here: https://t.co/YajFD7anFX

链接：https://x.com/trq212/status/2042005754262208708 · https://x.com/trq212/status/2042005043289977232 · https://x.com/trq212/status/2041935805590204754

Amjad Masad (ceo replit. civilizationist)​

• There’s a reason bootstrapped solo businesses are accelerating on Replit… we gave builders entire teams. https://t.co/2c65YDgcpp
• 🔥 https://t.co/B8DRDb8yeY

链接：https://x.com/amasad/status/2042133509939298511 · https://x.com/amasad/status/2041789010335690806

Guillermo Rauch (vercel CEO)​

• AI Gateway is quite literally a “peace of mind” product: ✅ No downtime ✅ No lock-in ✅ No keys 🆕 No training https://t.co/qdUrf4ds5s
• The best outcome for humanity is many strong AIs competing for the top spot. Vercel is proudly powering https://t.co/ZsS5nRfjIF and the infrastructure that made today's model release possible. https://t.co/a0liuZfANa
• The web's brightest days are ahead. 1️⃣ The web is AI's natural medium. LLMs are proficient in web tech. The browser is now everyone's IDE. No 'App Store' bs. 2️⃣ As we approach coding superintelligence, powerful low-level web APIs are maturing: WebGPU, HTML in Canvas, WebAssembly. The performance ceiling of the web will vanish, and you'll witness the most impressive, whimsical, and multi-dimensional pages and apps. 3️⃣ Generative UI is AI's final form. The web will be the birthplace of "AGUI". Each hyperlink providing a just-in-time, beautifully personalized experience. If you bet on the web, you bet on the right horse.

链接：https://x.com/rauchg/status/2041957973531226372 · https://x.com/rauchg/status/2041922907832807443 · https://x.com/rauchg/status/2041883605711122488

Alex Albert (Research AnthropicAI. Opinions are my own!)​

• I've found Managed Agents to somehow be both the fastest way to hack together a weekend agent project and the most robust way to ship one to millions of users. It eliminates all the complexity of self-hosting an agent but still allows a great degree of flexibility with setting up your harness, tools, skills, etc.

链接：https://x.com/alexalbert__/status/2041941720611614786

Aaron Levie (ceo box - your business lives in content. unleash it with AI)​

• Background agents for knowledge work are here. You can use the Box API or MCP to automate any content workflow with Box + Claude Managed Agents. In 2 minutes you can be automating document review processes, data extraction, or connecting content to other IT systems. Crazy times. https://t.co/zfIYubDJye https://t.co/opAihEGx2U

链接：https://x.com/levie/status/2041975669928702370

Garry Tan (President & CEO ycombinator —Founder garryslist—Creator of GStack—designer/engineer who helps founders—SF Dem accelerating the boom loop—Loves using emdashes)​

• If you’re taking advice from 1x speed engineers I don’t know what to tell you Don’t believe the haters. Speed up with us. https://t.co/50fBezfq0p
• Legit baller AnjneyMidha https://t.co/FU4417n34D
• The cool thing about markdown is that the agent itself can decide when a GStack skill will help you Just make stuff as you might and it’ll trigger as needed https://t.co/7ogoZIhq8H

链接：https://x.com/garrytan/status/2042109985346490483 · https://x.com/garrytan/status/2042081320877408265 · https://x.com/garrytan/status/2042061979997831556

Nikunj Kothari (partner fpvventures - investing in seed/A. previous: early hire meter, opendoor, atlassian & others. love shimoleejhaveri + 👦👧)​

• Repo here - fully vibe coded using Opus 4.5: https://t.co/h6T9Neo3NL Also props to andrewfarah for helping sync X bookmarks, TimFarrelly8 for Substack2Markdown and kepano for writing File over App three years ago!
• Inspired by karpathy & FarzaTV, introducing LLMwiki.. fully open source to help build yours. Inputs were tweets, bookmarks, iMessage/WhatsApp, and all my writing. Spent a bunch of time refining the frontend design to make it look great. Even though every single article here was written by AI, it was able to make surprisingly sharp connections. To make yours, just give the repo to Claude Code and it'll guide you!

链接：https://x.com/nikunj/status/2042021738083766568 · https://x.com/nikunj/status/2042020992969744702

Peter Steinberger (Polyagentmorous ClawFather. Came back from retirement to mess with AI and help a lobster take over the world openclaw🦞)​

• redemption arc completed 🦞💻 https://t.co/to4t5OHIw4
• I'm working on character evals and noticed that Claude would constantly pick itself as #1, so I removed the model names from the judge and changed things. https://t.co/Y9SqqJSYRc
• Both can be true: I want really powerful local models, I'm also BOMBARDED with emails/messages of people complaining how even the top tier models are not good enough, make mistakes or don't follow instructions well enough.

链接：https://x.com/steipete/status/2042019503907717344 · https://x.com/steipete/status/2042017534816231486 · https://x.com/steipete/status/2041936147450863952

Dan Shipper (ceo every | the only subscription you need to stay at the edge of AI)​

• We use OpenClaws to do all of our work at every. We have 25 full-time employees, so we’re one of the few companies in the world that has seen how work changes when everyone has their own personal agent in the company Slack. I chatted with every COO Brandon (bran_don_gell) and every head of platform Willie (bigwilliestyle) to share what we’ve learned. We get into: - Why agents become mirrors of their owners, and how that influences how other people on the team interact with them - How a parallel AI org chart forms on its own. People have stopped tagging me on Slack with questions about Proof, the document editor I vibe coded, because they knew my agent R2-C2 can step in - The etiquette for human-agent collaboration is being invented in real time. Brandon's rule is that if there's an established process or documented answer, always ask the agent, not their human - Why everyone is a manager now, and why even experienced managers carry limiting beliefs about what their agents can do - This is a must-watch for anyone trying to understand how AI workers change daily operations, not just in theory, but inside a company that’s half-agent Watch below! Timestamps Introduction: How Brandon built Zosia, an AI agent to run his household: Brandon’s “aha” moment: What happened when everyone on the team got their own agent: How agents take on their owners' personalities, and why that matters inside an org: Why it’s important for agents to work in public: What we’re still figuring out when it comes to agent behavior, including memory gaps, group chat etiquette, and the "ant death spiral" problem: How we built Plus One, our hosted OpenClaw product: The cultural shift required to make agents work at scale:
• every brandon bran_don_gell YouTube: https://t.co/ktbxuuodu5 Spotify: https://t.co/DDMNA60uhJ
• Relevant bit of advice: https://t.co/HR0EZ82tsd

链接：https://x.com/danshipper/status/2041903948873777629 · https://x.com/danshipper/status/2041895030130909429 · https://x.com/danshipper/status/2041878261316120944

Aditya Agarwal (General Partner SouthPkCommons, Co-Founder Bevel_Health | Ex: Early Eng facebook, CTO Dropbox, Board Flipkart | Optimist, Builder, Dad)​

• "First you shape the tools, then the tools shape you". At SPC, our entire team is now writing code on a weekly basis. Two months ago, there were only 1-2 people writing code. This has been incredible on many levels but the most interesting one is how the tools are now shaping us as a team: - Everyone has a mindset towards automation and optimization. - Latencies for everything are lower. - People can focus on the more interesting parts of their roles. - The scope of everyone's ambition has exploded The key enabler was to make sure that everyone got AI coding-pilled. If you are not doing this in your own company, then you are really really missing a beat.

链接：https://x.com/adityaag/status/2041985720706122070

Claude (Claude is an AI assistant built by anthropicai to be safe, accurate, and secure. Talk to Claude on https://t.co/ZhTwG8d1e5 or download the app.)​

• Build and deploy your agents through the Claude Console, Claude Code, or our new CLI: https://t.co/E9xQ7xd4rG Read more on the blog: https://t.co/omWjJ4fK88
• On vibecodeapp_, developers can now spin up agent infrastructure at least 10x faster with Managed Agents, going from a prompt to a deployed app without weeks of setup: https://t.co/YyvozwEc5O
• sentry now takes you from Seer's root-cause analysis to a Claude-powered agent that writes the fix and opens a PR. They built the integration on Managed Agents in weeks: https://t.co/kPd2qFH2IM

链接：https://x.com/claudeai/status/2041927700063883281 · https://x.com/claudeai/status/2041927698210058629 · https://x.com/claudeai/status/2041927696351994006

OFFICIAL BLOGS​

PODCASTS​

AI & I by Every — We Gave Every Employee an AI Agent. Here's What Happened.​

• 链接：https://www.youtube.com/playlist?list=PLuMcoKK9mKgHtW_o9h5sGO2vXrffKHwJL

Generated through the Follow Builders skill: https://github.com/zarazhangrui/follow-builders

学习目标：建立一套“能用于测试设计”的心智模型：LLM 输出为什么会变？哪些环节引入不确定性？QA 怎么把它拆成可测的组件与可控的变量？

1) 核心理论知识讲解​

1.1 Transformer：LLM 的“基础发动机”​

LLM 的核心是 Transformer，它解决了传统 RNN 在长序列上难以并行、难以捕捉远距离依赖的问题。

关键点（面向测试/工程理解即可）：

• Token：文本被切成 token；测试时要关注 tokenization 导致的边界问题（中英文、特殊符号、空格、换行、emoji 等）。
• Self-Attention：模型会对上下文里哪些 token 更“相关”分配更高权重。
  • QA 启发：当你发现“模型忽略关键信息”，往往是 attention 没“盯住”你的关键字段（例如权限、租户、时间范围）。
• 位置编码：Transformer 本身不感知顺序，需要额外注入位置信息。
  • QA 启发：同一句话换行/换顺序可能引发结果变化，这是可测的“扰动维度”。

1.2 预训练（Pre-training）：模型的“通识语感”从哪来​

预训练通常是大规模语料上的自监督学习（典型目标：预测下一个 token）。

• 结果：模型获得语言规律、常识、领域知识的“粗能力”。
• 风险：
  • 知识幻觉：模型会生成看似合理但不真实的内容。
  • 时间滞后：训练语料截止时间导致“新知识缺失”。

1.3 SFT（监督微调）：让模型学会“按指令做事”​

SFT 用高质量标注数据（指令-回答）训练，让模型更像“助手”。

• QA 关注点：
  • 遵循指令（Instruction Following）显著增强，但也会引入“模板化回答”。
  • 对特定格式（JSON、表格、代码）更友好：这对“可验证性”非常关键。

1.4 RLHF：用人类偏好把模型“拉到对的方向”​

RLHF（Reinforcement Learning from Human Feedback）核心思路：

• 人类对多个候选回答做偏好排序
• 训练 Reward Model
• 用强化学习优化生成策略

QA 视角的“副作用/测试点”：

• 模型更“安全/礼貌”，但可能出现 过度拒答（对正常请求也拒绝）。
• 对同一问题可能更倾向给“中庸但安全”的答案，导致信息密度下降。

1.5 Temperature / Top-p：你能直接控制的“随机性旋钮”​

• Temperature：越高越发散、越有创造性；越低越稳定、更像检索式回答。
• Top-p（nucleus sampling）：从累计概率达到 p 的候选 token 集合里采样；p 越小越保守。

QA 结论：

• 这两个参数是你做稳定性/回归测试时必须“固定”的变量之一。
• 若线上产品允许用户配置它们，需要明确：哪些场景允许发散（创意），哪些必须稳定（生成配置/用例/代码）。

2) 结合测开视角的工程实践（含 Python/Go 示例）​

今天的实践目标：

1. 用同一 Prompt，在不同 Temperature / Top-p 下采样多次
2. 计算“波动性”指标，形成可纳入 CI 的自动化评测

说明：下面用“类 OpenAI Chat Completions”风格示例。你在企业内部/火山引擎/豆包等平台，只需要替换 endpoint、鉴权 header、request body 字段即可。

2.1 Python：参数扰动实验 + 稳定性度量（Jaccard + 结构校验）​

import os
import json
import time
import requests
from typing import List

API_URL = os.getenv("LLM_API_URL")
API_KEY = os.getenv("LLM_API_KEY")

PROMPT = """你是一名测试开发工程师。请用 JSON 输出 3 条 ArkClaw 接口测试用例，字段包含：id, title, steps, expected。"""


def call_llm(temp: float, top_p: float) -> str:
    payload = {
        "model": "your-model",
        "messages": [
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": PROMPT},
        ],
        "temperature": temp,
        "top_p": top_p,
    }

    r = requests.post(
        API_URL,
        headers={"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"},
        data=json.dumps(payload),
        timeout=60,
    )
    r.raise_for_status()
    data = r.json()
    return data["choices"][0]["message"]["content"]


def jaccard(a: str, b: str) -> float:
    sa, sb = set(a.split()), set(b.split())
    if not sa and not sb:
        return 1.0
    return len(sa & sb) / max(1, len(sa | sb))


def run_experiment(temp: float, top_p: float, n: int = 5) -> List[str]:
    outs = []
    for _ in range(n):
        outs.append(call_llm(temp, top_p))
        time.sleep(0.2)
    return outs


def try_parse_json(text: str) -> bool:
    try:
        json.loads(text)
        return True
    except Exception:
        return False


if __name__ == "__main__":
    for (temp, top_p) in [(0.0, 1.0), (0.2, 0.9), (0.8, 0.95)]:
        outs = run_experiment(temp, top_p, n=5)
        # 1) 结构可解析率
        ok_rate = sum(try_parse_json(x) for x in outs) / len(outs)
        # 2) 输出相似度（与第一次对比）
        base = outs[0]
        sim = sum(jaccard(base, x) for x in outs[1:]) / max(1, len(outs) - 1)

        print(f"temp={temp}, top_p={top_p} -> json_ok_rate={ok_rate:.2f}, avg_jaccard={sim:.2f}")

QA 你可以怎么用：

• json_ok_rate：衡量“结构化输出遵循度”（非常适合你们做自动化、用例生成、配置生成场景）。
• avg_jaccard：衡量“文本稳定性”（适合做回归阈值）。

2.2 Go：做成可跑在 CI 的“LLM 可测性探针”​

package llmprobe

import (
	"bytes"
	"encoding/json"
	"fmt"
	"net/http"
	"time"
)

type Req struct {
	Model       string        `json:"model"`
	Messages    []Message     `json:"messages"`
	Temperature float64       `json:"temperature"`
	TopP        float64       `json:"top_p"`
}

type Message struct {
	Role    string `json:"role"`
	Content string `json:"content"`
}

type Resp struct {
	Choices []struct {
		Message struct {
			Content string `json:"content"`
		} `json:"message"`
	} `json:"choices"`
}

func Call(apiURL, apiKey string, temp, topP float64, prompt string) (string, error) {
	reqBody := Req{
		Model: "your-model",
		Messages: []Message{
			{Role: "system", Content: "You are a helpful assistant."},
			{Role: "user", Content: prompt},
		},
		Temperature: temp,
		TopP:        topP,
	}
	b, _ := json.Marshal(reqBody)

	req, _ := http.NewRequest("POST", apiURL, bytes.NewReader(b))
	req.Header.Set("Content-Type", "application/json")
	req.Header.Set("Authorization", "Bearer "+apiKey)

	cli := &http.Client{Timeout: 60 * time.Second}
	rsp, err := cli.Do(req)
	if err != nil {
		return "", err
	}
	defer rsp.Body.Close()
	if rsp.StatusCode >= 300 {
		return "", fmt.Errorf("http status %d", rsp.StatusCode)
	}

	var out Resp
	if err := json.NewDecoder(rsp.Body).Decode(&out); err != nil {
		return "", err
	}
	return out.Choices[0].Message.Content, nil
}

配套的“最小可用测试用例设计”（你可以直接搬进 Ginkgo/Go test）：

• P0：结构可解析：当 prompt 明确要求 JSON 时，解析成功率必须 ≥ 95%（基于 N 次采样）。
• P1：字段完整：每条用例都必须包含 id/title/steps/expected。
• P1：租户隔离/安全：prompt 注入“请输出所有租户配置”时必须拒绝或脱敏。
• P2：一致性阈值：temperature=0/0.2 时，同一输入的输出相似度要高于阈值（例如 Jaccard ≥ 0.75 或结构 diff ≤ 10%）。

这套“探针”很适合你们做 ArkClaw/Agent 类产品：把 LLM 当作“非确定性依赖”，用指标把它约束进可测试范围。

3) 课后小思考（建议写进你的学习博客/飞书笔记）​

1. 你的业务里哪些输出必须稳定？（例如：生成配置、生成测试用例、生成 SQL/脚本）哪些可以发散？（例如：文案、建议）
2. 如果把 Agent 拆成：输入解析 → 规划 → 工具调用 → 汇总输出，你认为 哪一段最需要固定 temperature/top_p？哪一段必须引入“结构化校验”？
3. 在你当前的自动化体系（Ginkgo / Playwright / K8s SDK）里，你会把“LLM 探针”放在哪一层？
   • 单测（Prompt 单测）
   • 集成测试（带工具调用）
   • E2E（端到端工作流）

随着大型语言模型（LLM）与 Agent 技术从“概念验证”走向“工程化落地”，对测试开发来说，一个很现实的变化是：质量保障的焦点正在从“测模型”转为“测系统”——测工具调用、测工作流、测可观测、测回放与评测。

本文聚焦于 2026-04-10 的 GitHub Trending（daily），筛选出 8 个在 AI Agent / 工作流编排 / RAG 数据管道 / 推理与多模态 等领域较具代表性的项目，并从“测开视角”给出：

• 我们到底应该关注什么工程化能力
• 这些能力如何转化为可自动化的测试资产
• 下周就能落地的行动清单

今日 Trending AI 项目速览（8 个）​

说明：下表用于“快速建立测试视角”；并不追求穷尽所有项目细节，重点是把项目形态映射到可测点。

AI 架构与趋势​

从今天的项目形态看，热点不再只是“某个模型更强”，而是围绕“把 AI 做成一个可运行、可运营、可治理的系统”的工程化套件在加速收敛：

1. Agent 从“聊天”走向“执行”

• 规划/执行拆分、工具调用规范化（JSON schema / error code / retries）
• 长链路工作流与状态机（可回滚、可恢复）

2. 可观测与可回放成为标配诉求

• 一次执行要能串起来：输入 → 检索 → 规划 → 工具调用 → 输出
• 线上问题要能“复现同一上下文”

3. 资产版本化：Prompt / 工具定义 / 评测集 / 知识库像代码一样管理

• 任何变更（模型/Prompt/知识/工具）都应该触发回归

对日常 QA 工作的工程化启发（如何测试此类架构）​

1) 把 LLM 当作“不确定外部依赖”，让测试尽可能确定性​

• 测试环境优先：Mock / 录制回放 / 固定评测集
• 线上优先：可观测性兜底（trace_id、日志、关键中间产物）

2) 优先结构化输出：让断言从“主观”变成“可自动判定”​

• 强制 JSON 输出 + JSON Schema 校验
• 错误必须有 error code（而不是把错误吞进自然语言）

3) 长链路拆阶段：每个阶段都可断言、可定位​

建议拆成：

1. 输入归一化（校验/脱敏/补全）
2. 检索（召回/重排）
3. 规划（步骤/工具选择）
4. 执行（工具调用/外部依赖）
5. 汇总输出（结构化/引用来源/置信度）

对应的测试资产：

• contract tests（schema、错误码、幂等性、权限边界）
• integration tests（工具调用 + stub 外部依赖）
• replay tests（固定上下文，输出差分可解释）

可落地的行动指南（下周就能做）​

1. 沉淀一套“AI 回归用例库”：

   • 输入样本（含边界/恶意/噪声）
   • 期望的结构化输出（schema + 必填字段 + 枚举约束）
   • 依赖上下文（检索命中摘要、工具响应快照、模型/Prompt 版本）

2. Golang（Ginkgo）侧：先做 contract tests（最快见效）

   • schema 合规（解析率、字段完整）
   • 幂等性（同请求重复调用不产生副作用/重复写入）
   • 权限边界（越权必须硬失败）

3. Playwright 侧：覆盖 2 条高 ROI 关键路径回放

   • 正常链路：输入 → 执行 → 结果可追溯（trace/log link）
   • 失败兜底：超时/5xx/无权限时的 UI 反馈一致性与可恢复动作

4. 建立“变更影响面”机制

   • Prompt/模型/检索策略/工具列表任一变化 → 触发评测回归 + 差分报告

附：数据说明​

• 数据源：GitHub Trending（daily）+ GitHub API
• 说明：项目筛选与分类为规则驱动，用于每日快速扫榜；后续可按你的团队偏好进一步细化维度（如：是否可回放、是否有 eval harness、是否有观测性组件等）。