2026年10月18日 · 阅读 —
2026-10-18-周复盘：本周 34 篇文章的沉淀与复盘
2026-10-18 周复盘（2026-10-12 → 2026-10-18）
1. 统计窗口
- 时间范围：
2026-10-12到2026-10-18 - 统计口径：按文件名日期落在本周窗口内的
01-Articles/文章（共 34 篇，合计约 16,072 字）
2. 本周一句话总结
- 本周共沉淀 34 篇文章，聚焦「测试」这组主线。
3. 本周新增文章清单
| 日期 | 标题 | 字数 |
|---|---|---|
| 2026-10-16 | Testkube：把测试都搬进 Kubernetes 一个平台 | 282 |
| 2026-10-15 | xx002-声明式用例：一份YAML搞定接口测试 | 1,126 |
| 2026-10-15 | xx003-跑起来与读报告：判闸、hermetic、能力矩阵 | 787 |
| 2026-10-15 | xx004-LLM是助手不是司机：意图调度与四个Agent | 881 |
| 2026-10-15 | xx005-自主进化闭环：框架怎么自己长用例不失控 | 770 |
| 2026-10-15 | xx006-失败治理：先分类再动手，红灯要的是诊断 | 643 |
| 2026-10-15 | xx007-预测分析与本地可观测：接口还没挂之前，怎么提前看出来 | 810 |
| 2026-10-15 | xx008-把一个业务接进harness：从脚手架到CI判闸 | 1,258 |
| 2026-10-15 | xx001-需求定位：为什么做一个有LLM却不靠LLM的接口测试框架 | 906 |
| 2026-10-15 | 手绘画风提示词配方库解读：21套画风，还带验收合同 | 497 |
| 2026-10-15 | 智能问数评测：发布标题候选 | 249 |
| 2026-10-15 | 智能问数评测：指标与术语索引 | 109 |
| 2026-10-15 | 智能问数评测：系列阅读与发布顺序 | 50 |
| 2026-10-15 | 智能问数评测路线：入口怎么选，SQL和受控IR怎样对照 | 416 |
| 2026-10-15 | 从企微问题到查询交付：智能问数的十二个观察节点 | 388 |
| 2026-10-15 | 主Agent、数据权限与系统安全：从意图检查到故障恢复 | 372 |
| 2026-10-15 | 问数、分析、报告与记忆：用独立真值逐层验收 | 715 |
| 2026-10-15 | 智能问数回归与数据集：从变更影响到可比较的执行 | 452 |
| 2026-10-15 | 评测框架怎样接入智能问数：从Case到证据与发布门禁 | 389 |
| 2026-10-15 | 首次智能问数评测适配：工具箱、框架扩展与Harness Loop | 514 |
| 2026-10-15 | 一次问数请求怎样测：沿A到D1定义输入、证据和断言 | 326 |
| 2026-10-15 | 五类测试怎样落地：把设计、构建、跑批和复核做成工作包 | 279 |
| 2026-10-15 | 固定一个测试账号，怎样批量验证六种数据权限 | 367 |
| 2026-10-15 | 自然语言条件怎样评测：从人工标注到归一化与多轮状态 | 323 |
| 2026-10-15 | 报表怎样成为问数参考：条件采集、问法改写与独立对账 | 366 |
| 2026-10-15 | 交付与安全怎样联合验收：从事实核对到故障恢复 | 365 |
| 2026-10-15 | 测试怎样按阶段落地：依赖、人工复核、复测与交付 | 263 |
| 2026-10-15 | 专用智能问数的基座怎样选：从产品职责到架构不变量 | 293 |
| 2026-10-15 | Agent项目为什么难维护：把运行时耦合变成可验证的架构问题 | 207 |
| 2026-10-15 | Hermes加固、服务抽离与应用编排：三条路线怎样公平比较 | 242 |
| 2026-10-15 | OpenAI Agents SDK、LangGraph与普通应用：问数框架怎样选型验证 | 323 |
| 2026-10-15 | 问数应用架构怎样落到代码：可信上下文、任务API、状态与缓存 | 392 |
| 2026-10-15 | 可测试的问数架构：依赖替身、逐节点断言与迁移复用 | 443 |
| 2026-10-15 | 问数平台怎样迁移：同条件PoC、单路交付与可验证回滚 | 269 |
4. 本周主题复盘
Agent / 自动化（9 篇）
- 《xx004-LLM是助手不是司机：意图调度与四个Agent》（2026-10-15，881 字）：# LLM 是助手不是司机：意图调度与四个 Agent > 概述：前一篇立起”跑 + 判 + 报告”确定性闭环，这篇开始往闭环上接 AI。 > 核心一条：LLM 不主动说话，只有被意图调度点到了才干活。 > 调度是”司机”，LLM 是”助手”——开车的是确定性规则，LLM 只在规则覆盖不到的开放处被叫来帮忙， > 而且它的建议最终还要过一道确定的验证门。 “分析这个失败的用例”这句话，怎么
- 《xx001-需求定位：为什么做一个有LLM却不靠LLM的接口测试框架》（2026-10-15，906 字）：# 需求定位：为什么做一个有LLM却不靠LLM的接口测试框架 > 概述：pytest + LLM 辅助 + OpenAI-SDK agent 的接口自动化测试框架。 > 声明式 YAML 写用例，LLM 只做辅助（数据生成 / 失败诊断 / 自愈 / 报告分析 / 预测）， > 测试主干完全确定性——
LLMOFF=1下零网络、CI 无密钥全绿。 本系列 8 篇，对应一套完整能力。这篇 - 《主Agent、数据权限与系统安全：从意图检查到故障恢复》（2026-10-15，372 字）：# 主Agent、数据权限与系统安全：从意图检查到故障恢复 主Agent会理解问题、选择工具、生成查询，还可能重试和调用辅助能力。权限与安全评测如果只核对最终文本，就会错过“先读取后拒绝”“改用其他入口取数”以及“重复查询后只展示一次”等行为。 主Agent评测需要依次验证意图、条件、分发调度、用户权限、系统安全、渠道恢复和存储增长。授权配置与数据使用虚构示例，教学代码只表达检查逻辑。最终裁决同时
- 《评测框架怎样接入智能问数：从Case到证据与发布门禁》（2026-10-15，389 字）：# 评测框架怎样接入智能问数：从Case到证据与发布门禁 评测框架收到了HTTP200，保存了一份报告，为什么仍然不能说业务通过？因为传输完成、工具轨迹、独立结果与发布门禁是不同事实。实施方案必须明确每一步由谁执行、输出什么证据、缺证据时停在哪里。 以agent-eval-harness为例，可以将接入过程组织为资源预检、协议映射、确定性断言、语义评分和发布门禁。下面用其现有Python接口说明一
- 《首次智能问数评测适配：工具箱、框架扩展与Harness Loop》（2026-10-15，514 字）：# 首次智能问数评测适配：工具箱、框架扩展与Harness Loop 第一次用通用Agent评测框架承接智能问数，容易把两种工作混为一谈：业务系统答得对不对，以及评测框架有没有把真实输入、证据和失败正确传递。框架冒烟通过可以证明协议的一部分，不会替业务金额、行级权限和企微交付背书。 工具选择应从实际缺口出发。缺SQL结构证据时考虑解析器，缺反例时考虑属性测试，缺隔离引擎时考虑容器，缺跨服务关联时考
- 《专用智能问数的基座怎样选：从产品职责到架构不变量》（2026-10-15，293 字）：# 专用智能问数的基座怎样选：从产品职责到架构不变量 企业问数的架构核心，是让合法主体在批准口径与数据版本下得到允许访问、能够对账的结果。自然语言是入口，模型与Agent运行时是实现手段。围绕这些职责讨论长期基座，比先为某个产品或SDK站队更容易形成可验证的决策。 以下限定为业务范围固定的专用问数产品，不推及个人开放助手。架构方向属于设计判断，候选的性能、稳定性和维护收益仍须同条件验证。 产品范围
测试工程（15 篇）
- 《Testkube：把测试都搬进 Kubernetes 一个平台》（2026-10-16，282 字）：# Testkube：把测试都搬进 Kubernetes 一个平台 先给个落点：Testkube 是一个跑在 Kubernetes 集群里的开源测试编排平台，把散在 CI、本地、各台机器上的那堆测试，收拢成一份能统一定义、统一触发、统一看结果的 Test Workflow。 仓库是 kubeshop/testkube，MIT 加 Testkube Community License 双协议开源，目
- 《xx002-声明式用例：一份YAML搞定接口测试》（2026-10-15，1,126 字）：# 声明式用例：一份 YAML 搞定接口测试 > 概述：接口用例不是 Python 代码，是一份 YAML。请求、断言、提取、分类全写成数据， > 不写样板代码。这份 YAML 放在
projects/<业务>/data/下，被加载、筛选、执行， > 是整套确定性骨架的第一块砖。 操作手册docs/operation.md第三节详细讲了”写第一个用例”；本系列 02 篇逐个拆它给的三 - 《xx006-失败治理：先分类再动手，红灯要的是诊断》（2026-10-15，643 字）：# 失败治理：先分类再动手，红灯要的是诊断 > 概述：接口测试最大的敌人不是接口坏，是分不清红灯为什么亮。同样是红灯， > 可能是脚本写错了、服务真挂了、网络抖了一下、或是早已知道的已知问题。 > 治理第一步是给失败分类，再决定动作，铁律只有一条：观察可以，但不许为了绿而造假绿灯。 这套治理实现在
src/ah/failure/目录，核心是triage.py（分类）、` - 《xx007-预测分析与本地可观测：接口还没挂之前，怎么提前看出来》（2026-10-15，810 字）：# 预测分析与本地可观测：接口还没挂之前，怎么提前看出来 > 概述：接口测试最好的状态，不是”红了才提醒”，而是”快坏了就知道”。预测分析（
src/ah/predict/） > 从历史运行里嗅出哪些接口在退化，本地可观测（src/ah/observe/）用本地 SQLite + 一个网页看每次运行的来龙去脉， > 顺带把 LLM 成本记账收进来——可观测不只盯接口，还得盯大模型烧了多少钱。 - 《xx001-需求定位：为什么做一个有LLM却不靠LLM的接口测试框架》（2026-10-15，906 字）：# 需求定位：为什么做一个有LLM却不靠LLM的接口测试框架 > 概述：pytest + LLM 辅助 + OpenAI-SDK agent 的接口自动化测试框架。 > 声明式 YAML 写用例，LLM 只做辅助（数据生成 / 失败诊断 / 自愈 / 报告分析 / 预测）， > 测试主干完全确定性——
LLMOFF=1下零网络、CI 无密钥全绿。 本系列 8 篇，对应一套完整能力。这篇 - 《智能问数评测：发布标题候选》（2026-10-15，249 字）：# 智能问数评测：发布标题候选 每篇正文采用当前主标题，以下保留四个可选方向，不包含未经验证的效果承诺。 ## 01 智能问数评测路线：入口怎么选，SQL和受控IR怎样对照 - 智能问数评测路线：入口怎么选，SQL和受控IR怎样对照 - API能跑通，为什么还需要企微和组件测试 - 四种测试入口各自证明什么：问数评测先选路线 - 从Text-to-SQL到受控IR，怎样设计公平对照 ## 02 从
其他（12 篇）
- 《xx003-跑起来与读报告：判闸、hermetic、能力矩阵》（2026-10-15，787 字）：# 跑起来与读报告：判闸、hermetic、能力矩阵 > 概述：前两篇讲”用例怎么写”，这篇讲用例怎么被真正跑起来、结果怎么变成能进 CI 的报告。 > 顺序是先把”跑 + 判 + 报告”这个最小闭环跑通，再接 LLM、进化、治理。 > 闭环是地基，后面的每一样能力都踩在这个闭环的结果上。 本文把
docs/operation.md的”运行与判闸""阅读报告”两节拆开，配上 `art - 《xx005-自主进化闭环：框架怎么自己长用例不失控》（2026-10-15，770 字）：# 自主进化闭环：框架怎么自己长用例不失控 > 概述：前面几篇是”人写用例，框架跑”，这篇不同——让框架自己长用例。 > 框架在”跑、分析、生成、持久化”的闭环里自己补用例，下一轮重跑验证。 > 但”自己长用例”最危险的不是”会不会长”，是”长出来的东西能不能信”， > 所以这篇主要讲四道护栏怎么保证它不失控、不造假绿灯、能回滚。 核心命令
ah evolve，实现集中在 `s - 《xx008-把一个业务接进harness：从脚手架到CI判闸》（2026-10-15，1,258 字）：# 把一个业务接进harness：从脚手架到CI判闸 > 概述：前几篇讲完框架的能力内核（写用例、跑闭环、接 AI、进化、治理、预测、可观测）。这一篇回答最实际问题： > 一个全新业务怎么从零接进这套框架、一路跑到 CI 判闸。散落的框架级能力——重试、超时、软断言、占位符、 > 多服务、认证、属性探索、OpenAPI 导入——分别在哪一步用上，一次串清楚。 `docs/onboarding.md
- 《手绘画风提示词配方库解读：21套画风，还带验收合同》（2026-10-15，497 字）：想用 AI 画一张手绘风格的图，卡住的往往不是”画什么”，而是”怎么把想要的那种画风说清楚”。 要吉卜力那种柔和水彩、暖光的调子，还是要小豆人黑色涂鸦讲解图的利落，还是水墨那种”墨分五色”的写意——对着生图模型各写各的提示词，每个人写出来都不一样，翻来覆去调，最后效果还不稳定。 GitHub 上这个 2.4k star 的仓库
threerocks/hand-drawn-styles，把这件事 - 《智能问数评测：指标与术语索引》（2026-10-15，109 字）：# 智能问数评测：指标与术语索引 正文中的定义继续保留。此索引只用于快速对照，不替代各篇的适用条件、公式和证据要求。 ## 术语 |词汇|释义|使用限制| |---|---|---| |Case|一条固定业务用例，包括输入、前提及预期|角色或实质条件改变可形成新场景，多标签不重复计数| |trial / turn|trial是用例的一次完整执行，turn是多轮中的一次回合|底层重试不自动等于独立业
- 《智能问数评测：系列阅读与发布顺序》（2026-10-15，50 字）：# 智能问数评测：系列阅读与发布顺序 系列分三组，共二十一篇。第一组构建评测体系和框架接入；第二组沿业务流程组织数据、执行与复核；第三组讨论架构职责、候选比较和渐进迁移。每篇保留适用指标、计数口径、词汇解释及技术示例，可单独阅读。 ## 评测体系与框架接入 |顺序|章节|文章| |---|---|---| |01|A|[智能问数评测路线：入口怎么选，SQL和受控IR怎样对照](2026-10-15
复盘要点
- 共同点：本周文章整体围绕「把工具/流程收敛成可复用资产」。
- 启发：沉淀优先级应从「信息收集」转向「可执行、可验收、可检索」。
- 下一步：挑 1-2 篇最有复用价值的主题深化成技能/模板。
5. 本周观察
- 文章即资产：
01-Articles/同时作为71-Wiki源①，沉淀后会被编译进知识库，形成可检索闭环。 - 写作主线：注意保持「能落地、能复用、能验收」的取舍，避免只罗列工具资讯。
6. 下周建议
- 继续把每周折腾收敛成可复用文章，回填
01-Articles/。 - 对长期未更新的主题，考虑合并或归档，保持目录干净。