2026年7月16日，Sentinel读取代码库，理清真正的业务流程，并在前端和后端之间进行端到端的测试。它在MIT许可下开源。点击和理解之间的差距 将一个典型的AI代理放在您的应用程序上，它打开一个页面，点击几下，注意到一个未对齐的元素或控制台错误，然后宣告运行完成。这在某种程度上是有用的，就像烟雾测试一样。代理没有您产品实际功能的模型。值得聘用的QA工程师不会随便点击。他们首先学习产品，然后推理：这是一个酒店系统，所以我需要测试一个单一预订，一个团队预订，一个释放房间的取消手续，入住，退房，以及夜审，并且我要确认每个操作实际上在服务器上持久保存，而不是信任UI看起来很顺利。 我们给它一个真实应用和没有说明的情况下发生了什么 我们将Sentinel指向一个正常工作的全栈酒店PMS（物业管理系统）：一个Next.js前端，一个单独的API服务，一个Postgres数据库。这个PMS是KaribuKit，我们自己的产品，这也是我们能为一个一次性测试租户提供管理员凭证的原因。这也是它所获得的一切——代码库和这些凭证。没有测试计划，没有流程列表。它读取了代码，得出产品是一个精品酒店和野生动物园酒店PMS，并自行推导出九个关键业务流程：完整的预订生命周期、团队预订、从潜在客户到提案的管道、价格管理、客人自助服务、中途更换房间、夜审、通过发票到退款的付款，以及AI副驾驶。取消也包含在其中，尽管此次运行将它作为边缘案例融合在其他流程内部，而不是推导出一个独立的流程。这接近于人类QA领导在第一天会写出的列表，没有人将它交给代理。 运行本身：计划来自代码库，前两个流程各深度测试两次，然后视图遍历它访问过的每个屏幕。然后它运行那两个流程，每个流程两次，跟踪的记录就像观看一个人在工作：它调用GET /api/availability，得到了400，找出缺少的参数，并重试使用adults=2&children=0得到了200。它使用POST /api/reservations创建了一个真实的预订（201），然后取回它以确认它已在正确的房间和费率中持久化。它走过状态生命周期，通过试验找到登机口（/checkin返回404，/check-in返回400，然后有效调用返回200），查看账单。它验证的账单：三晚房费每晚178美元，余额534美元。角落里的红色提示是一个实时捕获的错误：“没有可用房间”在一个已经持有房间的预订上。它暴露出来的错误是您仅通过UI无法找到的：确认一个预订返回NO_AVAILABILITY，即使该预订已经持有房间。一个后端状态机错误，UI在一次尝试中变成了一个误导的“没有可用房间”提示，在另一尝试中则完全没有反馈。日历在已经存在预订的情况下显示房间为可用。API和UI不一致，只有检查这两层才能捕捉到它。登机返回200，但客人的registrationStatus在服务器上保持为NONE：一个状态转换只完成了一半。日历在运行中，填满了代理自己创建的预订，待定和确认并排显示。 它是如何工作的 QA代理的深层引擎，流程，是一个管道：读取代码库。一个确定性的重访过程（grep和find，无模型调用）提取结构：前端路由，API路由模块，服务，数据库实体。模型基于该摘要进行推理，而不是盲目爬行单体库，这很慢且常常遗漏。推导流程。Mimo，我们在pi代理工具中运行的Xiaomi模型，将摘要转化为有优先级的端到端业务流程列表，每个流程都有UI步骤、后端断言和边缘案例。计划是按提交进行缓存，因此只有在代码更改时才重新推导。将每个流程作为代理循环运行：模型决定下一个操作，Playwright驱动浏览器，而一个一流的api_request工具在每个步骤通过在页面内部运行fetch来检查服务器状态，重播前端自身发送的Authorization头。模型仅获得浏览器和API工具，永远不会触及您的shell或文件系统，每次尝试都有硬预算限制。超过90个工具调用后，操作工具拒绝行动，唯一的选择是完成。多次运行。自主代理是非确定性的。我们在一个流程上进行了测量，其中一次尝试发现了零个错误，而另一次发现了五个。因此每个流程默认运行两次（FLOW_ATTEMPTS，一个旋钮），发现的错误按并集计算：任何一次尝试发现的错误都会进入报告，而每个流程保留其在尝试中的最差判决。评估设计。代理访问的每个不同屏幕（通过URL去重，每次运行最多八个）