我们为自己的待办事项打造了一个 AI 智能体，现在它也属于您

问题

在 Ostorlab，我们打造的是发现问题的工具——发现移动应用、Web 应用、API 和代码中的问题。这就是我们的工作，而它也有代价：我们发现的每一个问题都会变成一张工单。

我们自己的平台也不例外。日志中出现错误、有人报告缺陷、扫描发现问题，每一项都会变成一张工单。而工单源源不断。

其中很多工单并不难。堆栈跟踪指向确切的代码行，错误信息说明了出了什么问题，修复往往只需要几行代码。但仍然需要有人停下手头的工作：打开工单、阅读、找到代码、编写修复、测试，然后提交拉取请求。

于是，简单的工单只能等待——不是因为它们难，而是因为每个人都在忙更难的工作。一个小修复可能会搁置好几天，待办事项越积越多。堆积的不是难题，而是没人有时间处理的简单问题。

机会

当我们仔细审视这些工单时，我们注意到了一件事：其中很多根本不是人写的。它们是根据错误日志和扫描结果自动生成的，而这些来源已经记录了细节：错误信息、堆栈跟踪、文件、代码行。工单已经说明了哪里坏了、坏在何处，而且往往还说明了原因。

我们设计这些工单，是为了让工程师获得开始修复所需的一切。而我们意识到，工程师开始修复所需要的，也正是 AI 智能体所需要的。信息已经在那里了，缺少的是时间。

这让我们提出了一个简单的问题：如果一个智能体能够接手工单并开始修复，会怎样？

编码智能体已经能够阅读代码、追踪错误并编写修复。但它们大多仍需等待开发人员打开它们并输入提示词。我们想要的是不同的东西。我们不想再给工程师增加一个需要记着去用的工具；我们希望工作就在它原本所在的地方——工单中——开始。

一张工单进来，一个智能体接手，产出一个拉取请求，再由一位工程师审查。工程师始终掌控全局，只是跳过了重复性的部分。而且由于每张工单都交给各自的智能体，工作量可以随待办事项扩展：有多少张工单需要处理，就有多少个智能体并行运行。

第一个版本

我们有意从小处着手。我们构建了一个只做一件事的智能体：读取一张缺陷工单，并提交一个修复它的拉取请求。

我们称它为 Rubberduck。并不是团队里每个人都喜欢这个名字，但它还是被沿用了下来。

流程很简单。工程师把工单分配给 Rubberduck，就像分配给一位队友一样。然后由智能体接手：

• 它阅读工单及其评论。
• 它找到相关的代码。
• 它弄清楚哪里出了问题。
• 它编写修复并提交拉取请求。
• 它在工单上留下评论，附上该拉取请求的链接。

如果审查者需要修改，也不需要使用新工具。他们只需像对待任何同事一样留下评论，Rubberduck 就会读取评论并更新它的工作。

就这么简单。没有仪表板，没有设置——一个智能体，一项任务。它并不完美，但已经足够好，可以让我们将它投入到真实工单的处理中。

我们自己先用起来

我们把自己待办事项中的真实工单交给 Rubberduck，它开始提交拉取请求。有些不错，有些不行，而每一个错误都让我们学到了一些东西。

找到根因，而不是症状。 早期的修复有时只是把错误掩盖起来，而不是真正解决它。于是我们教智能体像一位细心的工程师那样工作：阅读错误，追溯其真正的根因，复现它，然后再修复。

为人而写。 最初的拉取请求标题往往只是从工单中复制的错误信息，在长列表中很难阅读。现在，智能体会写一个简短的标题，说明它修复了什么。

不知道时要说出来。 有时工单没有足够的信息。智能体会去猜测，而猜测会导致糟糕的修复。我们教它停下来提问。现在，它可以报告工单已修复、部分修复、受阻，或需要更多上下文。

把工作做完。 测试失败的拉取请求算不上修复。因此，智能体现在会等待检查通过，并修复出错的地方。

遵守我们的规则。 每个团队都有自己的代码编写方式。我们把风格指南交给了智能体，还给了它记忆，让在一张工单上学到的经验能帮助处理下一张。

让密钥远离智能体。 智能体需要访问我们的代码，但它永远不应该看到我们的密码或密钥。因此，我们将它们完全移出智能体的访问范围：它们在运行时注入，智能体可以使用它们，但永远无法读取它们。

当 Rubberduck 的拉取请求开始与其他所有人的拉取请求一起出现在我们的审查队列中时，我们就不再把它当作一项实验了。我们以同样的方式审查它们。它已经成为团队的一员。

更重要的认识

Rubberduck 运转起来之后，团队成员开始提出更多需求：

“它能按紧急程度对新工单排序吗？” “它能根据我们的合规规则检查我们的发现吗？” “它能在每周一审查未关闭的工单吗？”

这些都是好主意，但 Rubberduck 做不到。它的任务是内置的：它只修复代码，别的什么也不做。我们已经构建了第二个智能体，一个负责规划工作而不是编写代码的智能体，而它也有同样的问题——它的任务同样是内置的。我们可以为每项新任务构建一个新智能体，但那将永无止境。

使用 Rubberduck 不需要任何设置。但构建每个新智能体都需要：您必须手动编写一个很长的配置文件，其中每个名称都必须准确无误。这能行得通，但感觉应该有更好的方法。

就在那时，我们看到了真正的机会。问题从来不是“我们需要一个修复代码的智能体”，而是“我们的工单里有没人有时间处理的工作”，而修复代码只是这类工作中的一种。

因此，智能体不应该有固定的任务。它应该接受团队交给它的任何任务——而设置一个智能体应该像填写表单一样，而不是编写配置文件。您用平实的语言描述任务，选择一个模型，再选择它何时运行。

我们构建了什么

我们围绕这个理念重建了工单智能体。现在只有一种智能体，在您给它分配任务之前，它没有任何任务。您只需在表单中经过几个步骤即可完成设置。

给它起个名字。 任何您想要的名字都可以。请慎重选择——名字一旦起了就会沿用下去。这一点我们深有体会。

给它一项任务。 您用平实的语言写下智能体应该做什么。不知道从哪里开始？我们的设置指南会一步步引导您，并附上我们一路走来积累的经验。

选择一个模型。 您可以使用自己的 AI 提供商密钥，也可以使用 Ostorlab 提供的模型并以您的额度余额付费。每次运行在开始时会预留额度，未使用的额度会退还给您。

选择它何时运行。 您可以添加规则。规则可以在以下情况下触发：

• 当工单发生某些事件时：工单被创建、被分配、被重新打开、收到新评论，或错过截止期限，
• 当一次扫描完成时，
• 或按计划运行，例如每周一早上。

您可以缩小每条规则的范围。例如，仅限严重级别的工单，或仅限某一个应用的扫描。

教它了解您的工作方式。 您可以为它提供技能：解释您的团队如何做事的简短指南。您还可以为它提供记忆，让它在一张工单上学到的东西能帮助处理下一张。

将它连接到您的工具。 智能体可以使用 MCP（Model Context Protocol）服务器，因此它可以使用您团队已经在用的工具，而不仅仅是 Ostorlab 自己的工具。

与人并肩工作。 您可以像把工单分配给队友一样把工单分配给智能体。一张工单可以同时分配给两者。智能体完成它的部分，而人始终负责。

从模板开始。 如果您不想从零开始，可以使用现成的智能体来进行漏洞分诊或合规审查。

模板的规则默认处于关闭状态，因此在您启用之前不会运行任何内容。

工单智能体能为您的团队做什么

我们最初是为自己构建它的。现在，它已经为您的团队准备就绪。

您的智能体可以修复缺陷、对新工单排序、审查合规性，或在每周一进行检查。您决定它的任务、何时运行以及允许它接触哪些内容——而最终决定权始终在人手中。

如果您的待办事项看起来和我们当初一样，工单智能体可以清理掉简单的工单，让您的团队专注于困难的工单。

像我们一样从小处着手。选择一个模板，给它分配一张测试工单，阅读它给出的结果，然后再决定接下来交给它什么。

您可以在平台的 Agents → AI Agents 下找到工单智能体，完整的工单智能体设置指南从头到尾介绍了配置方法。

常见问题

什么是 Ostorlab 工单智能体？ 它是一个处理您工单待办事项的 AI 智能体。您用平实的语言给它分配任务，选择一个模型，并设置它何时运行的规则。它可以修复缺陷并提交拉取请求、对新工单进行分诊、审查合规性或按计划运行，而它的工作始终由人来审查。

智能体如何知道何时运行？ 您可以添加规则。规则可以在工单发生某些事件时触发（被创建、被分配、被重新打开、收到评论或错过截止期限），在扫描完成时触发，或按计划触发，例如每周一早上。您可以缩小每条规则的范围，例如仅限严重级别的工单或仅限某一个应用的扫描。

我可以使用自己的 AI 模型吗？ 可以。您可以使用自己的 AI 提供商密钥，也可以使用 Ostorlab 提供的模型并以您的额度余额付费。每次运行在开始时会预留额度，未使用的部分会退还给您。

智能体会取代我的工程师吗？ 不会。您可以像把工单分配给队友一样把工单分配给智能体，一张工单也可以同时分配给两者。智能体完成重复性的部分并提交拉取请求；由人来审查，并拥有最终决定权。

它能连接 Ostorlab 之外的工具吗？ 可以。智能体可以使用 MCP（Model Context Protocol）服务器，无论是远程、本地还是 Ostorlab OXO 服务器，因此它可以与您团队已经在用的工具协同工作。

如何开始使用？ 选择一个模板，例如 Vulnerability Triage 或 Compliance Review，给它分配一张测试工单，然后阅读它的报告。模板的规则默认处于关闭状态，因此在您启用之前不会运行任何内容。完整的设置指南从头到尾介绍了配置方法。

需要帮助设置您的第一个智能体？请发送电子邮件至 support@ostorlab.dev。