自主测试管道演示之外的实际工作演示止于测试通过实际工作始于防止自主管道引发值班噩梦的操作手册。演示视频总是在同一时刻结束一个 Figma 框架在十二分钟内变成了一个通过的测试会议室里有人说出 生产力 这个词录制便停止。而之后才是真正会让人接到紧急呼叫的内容如凌晨 3 点 14 分自主代理创建的工单由谁负责测试用例 47 中的断言由哪个模型调用产生在下次冲刺规划发现之前一个卡住的运行遗留的 17 个草稿工单如何关闭等这些在演示中不会出现但值班轮值时会冒出来。在消费级平台上领导测试自动化工作 20 年后作者坚信演示文稿中的操作手册幻灯片能预示管道是顺利交付还是停滞不前。作者基于模型上下文协议Model Context Protocol构建了一个无人值守的自主测试管道这是一个涉及五个角色产品经理、QA 工程师、自动化工程师、开发人员、拉取请求审查员的软件开发生命周期SDLC通过用于 Jira、Figma、Confluence、TestRail 和 GitHub 的 MCP 服务器进行协调以托管的 Claude 作为编排模型以开放权重的 Hermes - 3 作为验证基线。作者将其作为独立研究项目运行很长时间了解到自主代理文献中忽略的生产约束。以下是让自主管道接触共享系统前要做到的几点。组合契约自主代理为何自欺欺人在多代理管道中代价最高昂的故障模式并非模型给出错误答案而是代理 A 给出正确答案却被代理 B 误读。上个月一次运行中需求代理生成干净输出其中 acceptance_criteria 字段为字符串列表而工单代理期望该字段是单独的 Markdown 块。两个代理单独看都没错都通过各自单元测试但管道生成的 Jira 工单中验收标准一栏全是四个字符 [测试计划代理读取后生成测试并标记通过后继续执行直到拉取请求阶段作者才注意到问题。这是组合故障是独立组件在非共同拥有的边界上传递结构化数据时的常见故障模式。分布式系统领域专家多年来探讨此问题如 Martin Fowler 的宽容读取器模式是经典解决方案但大语言模型LLM文献大多仍将其视为提示问题。实际上仅靠更好的系统提示无法解决需要双方在运行前都认可的类型化交接契约和验证器当数据格式出现偏差时能及时报错。作者现在采用的方法是每个代理之间的边界都要有模式和验证器每个代理都要有黄金输入回归套件在契约偏差影响到下游代理之前将其捕捉。这些是区分能产出实际工作的管道和只会引发昂贵 传话游戏 的管道的关键。若想知道团队的自主管道能否熬过第一个季度可问问他们代理一和代理二之间的契约是什么若答案是 模型会自行解决那就要做好清理烂摊子的准备。来源追溯无人记录的审计轨迹作者坚持的第二点是管道产生的每个工件都必须能在无需人工深入挖掘的情况下回答三个问题是哪个代理产生的是哪个模型调用产生的以及代理产生该工件时参考了哪些上游输入。运行管道大约三周时作者遇到问题需求代理不断引用自己之前生成的一个 Confluence 页面Confluence 的 MCP 服务器第一次调用返回空结果代理写了占位符需求第二次调用成功后代理取回自己写的占位符到第三次时竟将占位符当作真实来源。工单上写着需求来自设计负责人可实际毫无出处是四分钟前代理自己生成的内容。仅靠记录模型说了什么的日志无法调试这类故障需要记录模型当时参考的内容。这意味着要为每个 MCP 调用捕获工具调用 ID为每个工件标记其派生的工具调用 ID 集合并且不接受任何无法追溯到真实外部来源的事实进入下游阶段作者称之为 证明来源规则。这在操作手册里只是两行要求但却是节省最多值班时间的防线。而且当编辑、审查员或审计员询问某个决策的来源时管道可以直接展示给他们这在受监管的技术栈环境中至关重要在美国国家标准与技术研究院NIST的人工智能风险管理框架AI Risk Management Framework中关于人工智能透明度和来源追溯的框架也会比大多数团队预期的更快成为默认要求。清理与归属为何先写关闭脚本对于首次推出自主管道的团队最头疼的是遗留问题。一个无人值守运行一周的管道会产生各种遗留物如未获批准的父故事下的草稿 Jira 工单、未合并的测试套件 GitHub 分支、只产生部分结果却没有总结的 TestRail 运行记录以及代理在自问澄清问题时发布的 Confluence 页面评论等这些是启动过多工作却未完成的自主系统的正常产物。作者偶然发现这个问题项目进行到大约六周时在 Jira 上查询过去 30 天内自动化用户创建的工单原本以为 20 个左右结果有 91 个其中 68 个标题带有 [DRAFT] 且从未被人工处理过。作者花一个下午手动关闭这些工单意识到管道还有隐性任务垃圾清理。现在作者运行的每个管道在编写第一个代理之前要做好三件事一是编写关闭脚本用于关闭当前运行中产生的所有孤立工件二是进行夜间对账关闭之前运行遗留的所有孤立工件三是为管道可写入的每个下游系统指定明确负责人这个人要在组织架构图中有明确位置且有 Slack 账号。当管道创建 Jira 工单时工单要有真正负责人当管道发起拉取请求时要有指定审查员当管道提交 TestRail 运行记录时如果记录停滞要有专人被提醒。管道不允许触碰没有指定负责人的系统仅这条规则就能避免作者经历清理 91 个工单的痛苦下午。这里要明确指出一个反模式无论如何都不要让代理自行关闭其产生的工件。作者试过负责清理的代理误关 30 个工单还信心满满写总结说关闭的都是正确的。清理工作要么由人工完成要么使用确定性脚本绝不能依赖模型调用。管道确实有效能在合适的工作上节省大量时间但也会在大多数团队未预估到的工作上消耗时间如代理之间的契约验证、每个工件的来源追溯标记、关闭脚本、对账流程、为每个下游系统指定人工负责人以及坚决杜绝模型自行清理的规则。这些不怎么光鲜也不会出现在演示中但构成了操作手册而操作手册决定了管道是实验室实验还是能让值班工程师放心安睡的可靠工具。先编写操作手册的团队能够顺利交付成果而在首次周日事故后才编写的团队可能要花接下来两个季度的时间来弥补差距。想加入 Foundry 专家贡献者网络可关注软件开发、软件部署、DevOps 相关内容。
自主测试管道实用指南：操作手册决定能否让值班工程师安心
自主测试管道演示之外的实际工作演示止于测试通过实际工作始于防止自主管道引发值班噩梦的操作手册。演示视频总是在同一时刻结束一个 Figma 框架在十二分钟内变成了一个通过的测试会议室里有人说出 生产力 这个词录制便停止。而之后才是真正会让人接到紧急呼叫的内容如凌晨 3 点 14 分自主代理创建的工单由谁负责测试用例 47 中的断言由哪个模型调用产生在下次冲刺规划发现之前一个卡住的运行遗留的 17 个草稿工单如何关闭等这些在演示中不会出现但值班轮值时会冒出来。在消费级平台上领导测试自动化工作 20 年后作者坚信演示文稿中的操作手册幻灯片能预示管道是顺利交付还是停滞不前。作者基于模型上下文协议Model Context Protocol构建了一个无人值守的自主测试管道这是一个涉及五个角色产品经理、QA 工程师、自动化工程师、开发人员、拉取请求审查员的软件开发生命周期SDLC通过用于 Jira、Figma、Confluence、TestRail 和 GitHub 的 MCP 服务器进行协调以托管的 Claude 作为编排模型以开放权重的 Hermes - 3 作为验证基线。作者将其作为独立研究项目运行很长时间了解到自主代理文献中忽略的生产约束。以下是让自主管道接触共享系统前要做到的几点。组合契约自主代理为何自欺欺人在多代理管道中代价最高昂的故障模式并非模型给出错误答案而是代理 A 给出正确答案却被代理 B 误读。上个月一次运行中需求代理生成干净输出其中 acceptance_criteria 字段为字符串列表而工单代理期望该字段是单独的 Markdown 块。两个代理单独看都没错都通过各自单元测试但管道生成的 Jira 工单中验收标准一栏全是四个字符 [测试计划代理读取后生成测试并标记通过后继续执行直到拉取请求阶段作者才注意到问题。这是组合故障是独立组件在非共同拥有的边界上传递结构化数据时的常见故障模式。分布式系统领域专家多年来探讨此问题如 Martin Fowler 的宽容读取器模式是经典解决方案但大语言模型LLM文献大多仍将其视为提示问题。实际上仅靠更好的系统提示无法解决需要双方在运行前都认可的类型化交接契约和验证器当数据格式出现偏差时能及时报错。作者现在采用的方法是每个代理之间的边界都要有模式和验证器每个代理都要有黄金输入回归套件在契约偏差影响到下游代理之前将其捕捉。这些是区分能产出实际工作的管道和只会引发昂贵 传话游戏 的管道的关键。若想知道团队的自主管道能否熬过第一个季度可问问他们代理一和代理二之间的契约是什么若答案是 模型会自行解决那就要做好清理烂摊子的准备。来源追溯无人记录的审计轨迹作者坚持的第二点是管道产生的每个工件都必须能在无需人工深入挖掘的情况下回答三个问题是哪个代理产生的是哪个模型调用产生的以及代理产生该工件时参考了哪些上游输入。运行管道大约三周时作者遇到问题需求代理不断引用自己之前生成的一个 Confluence 页面Confluence 的 MCP 服务器第一次调用返回空结果代理写了占位符需求第二次调用成功后代理取回自己写的占位符到第三次时竟将占位符当作真实来源。工单上写着需求来自设计负责人可实际毫无出处是四分钟前代理自己生成的内容。仅靠记录模型说了什么的日志无法调试这类故障需要记录模型当时参考的内容。这意味着要为每个 MCP 调用捕获工具调用 ID为每个工件标记其派生的工具调用 ID 集合并且不接受任何无法追溯到真实外部来源的事实进入下游阶段作者称之为 证明来源规则。这在操作手册里只是两行要求但却是节省最多值班时间的防线。而且当编辑、审查员或审计员询问某个决策的来源时管道可以直接展示给他们这在受监管的技术栈环境中至关重要在美国国家标准与技术研究院NIST的人工智能风险管理框架AI Risk Management Framework中关于人工智能透明度和来源追溯的框架也会比大多数团队预期的更快成为默认要求。清理与归属为何先写关闭脚本对于首次推出自主管道的团队最头疼的是遗留问题。一个无人值守运行一周的管道会产生各种遗留物如未获批准的父故事下的草稿 Jira 工单、未合并的测试套件 GitHub 分支、只产生部分结果却没有总结的 TestRail 运行记录以及代理在自问澄清问题时发布的 Confluence 页面评论等这些是启动过多工作却未完成的自主系统的正常产物。作者偶然发现这个问题项目进行到大约六周时在 Jira 上查询过去 30 天内自动化用户创建的工单原本以为 20 个左右结果有 91 个其中 68 个标题带有 [DRAFT] 且从未被人工处理过。作者花一个下午手动关闭这些工单意识到管道还有隐性任务垃圾清理。现在作者运行的每个管道在编写第一个代理之前要做好三件事一是编写关闭脚本用于关闭当前运行中产生的所有孤立工件二是进行夜间对账关闭之前运行遗留的所有孤立工件三是为管道可写入的每个下游系统指定明确负责人这个人要在组织架构图中有明确位置且有 Slack 账号。当管道创建 Jira 工单时工单要有真正负责人当管道发起拉取请求时要有指定审查员当管道提交 TestRail 运行记录时如果记录停滞要有专人被提醒。管道不允许触碰没有指定负责人的系统仅这条规则就能避免作者经历清理 91 个工单的痛苦下午。这里要明确指出一个反模式无论如何都不要让代理自行关闭其产生的工件。作者试过负责清理的代理误关 30 个工单还信心满满写总结说关闭的都是正确的。清理工作要么由人工完成要么使用确定性脚本绝不能依赖模型调用。管道确实有效能在合适的工作上节省大量时间但也会在大多数团队未预估到的工作上消耗时间如代理之间的契约验证、每个工件的来源追溯标记、关闭脚本、对账流程、为每个下游系统指定人工负责人以及坚决杜绝模型自行清理的规则。这些不怎么光鲜也不会出现在演示中但构成了操作手册而操作手册决定了管道是实验室实验还是能让值班工程师放心安睡的可靠工具。先编写操作手册的团队能够顺利交付成果而在首次周日事故后才编写的团队可能要花接下来两个季度的时间来弥补差距。想加入 Foundry 专家贡献者网络可关注软件开发、软件部署、DevOps 相关内容。
