AI Agent 说“任务完成”，就真的完成了吗？从工具调用到交付验收

前言

最近在研究 AI Agent 自动化开发时，我发现一个非常值得讨论的问题。

我们让 AI Agent 完成一个任务，例如：

“开发一个简单的网页工具，运行测试，推送代码仓库，最后发布到应用展示平台。”

AI Agent 可能在执行过程中不断输出：

• 项目代码已生成。

• 测试执行成功。

• Git 仓库推送完成。

• 应用发布成功。

从交互体验来看，这些反馈让人感觉任务正在顺利推进。

但问题是：

AI Agent 说某一步成功了，是否意味着这一步真的完成了？

例如，执行 Git Push 的命令退出码为 0，是否代表远程仓库包含预期文件？

发布接口返回 HTTP 201，是否代表用户已经可以在公开页面看到作品？

自动化测试全部通过，是否代表网页的真实按钮都能正常使用？

这些问题看起来简单，但对于需要连续执行多个步骤的 AI Agent 来说非常重要。

传统软件开发强调测试和交付验收，而 AI Agent 自动化同样需要建立这样的机制。

本文就从开发者角度，讨论如何让 AI Agent 从“声称完成任务”，逐步走向“提供能够验证的交付结果”。

一、为什么 AI Agent 容易出现“看起来完成了”？

AI Agent 与普通聊天机器人最大的区别之一，是它可以调用工具。

例如，一个开发类 Agent 可能依次执行：

用户提出任务
     ↓
AI 生成代码
     ↓
调用终端创建文件
     ↓
运行测试
     ↓
推送 Git 仓库
     ↓
调用发布 API
     ↓
返回最终报告

这种工作流有一个特点：

模型负责规划和判断下一步，而工具负责实际执行。

如果模型只根据工具输出中的部分信息判断成功，就可能出现误判。

例如：

执行命令：
npm test

输出：
Tests passed

AI 看到 Tests passed，便认为项目已经完全通过验证。

但实际上，这些测试可能只覆盖了几个基础函数，没有验证真实浏览器中的用户交互。

同样，代码编译成功不代表程序运行正常。

服务器启动成功也不代表外部用户可以访问。

因此，一个可靠的 Agent 必须知道：

不同的成功信号，能够证明的范围是不一样的。

二、理解三个层次：执行成功、结果成功、业务成功

我认为可以把 AI Agent 的完成状态分成三个层次。

第一层：执行成功

表示工具确实运行了，而且返回了预期的执行状态。

例如：

git push origin master
exit code: 0

这能够说明 Git Push 命令成功完成。

但它并不自动证明：

• 推送到了预期仓库。

• 推送的分支正确。

• 所有需要的文件都已提交。

• 代码符合项目要求。

第二层：结果成功

表示工具执行后，产生了预期的资源或状态。

例如：

Remote repository:
https://example.com/user/demo

Branch:
master

Commit:
abc123

如果再通过远程接口检查，确认对应分支包含预期提交，就能获得比单纯退出码更充分的证据。

第三层：业务成功

表示最终结果真正满足用户的任务目标。

假设用户要求的是：

“开发并公开发布一个可以使用的网页工具。”

那么业务成功至少涉及：

• 网页功能符合需求。

• 代码已经保存到远程仓库。

• 必要测试已经通过。

• 发布平台存在对应作品记录。

• 公开页面能够正常访问。

这三个层次存在递进关系。

命令执行成功，并不必然等于业务交付成功。

三、一个真实场景：发布接口返回 201，还需要验证吗？

假设 AI Agent 调用一个应用发布接口：

POST /api/works
Content-Type: application/json

{
  "name": "Demo App",
  "repository": "https://example.com/demo"
}

服务端返回：

HTTP/1.1 201 Created
Content-Type: application/json

{
  "success": true,
  "workId": "work-2026-001"
}

对于资源创建接口而言，HTTP 201 通常表示创建成功。

这个结果已经是非常重要的成功证据。

但是，如果用户要求“公开发布并可以访问”，还应该进一步检查：

1. 作品 ID 是否能够查询到。

2. 作品状态是否符合公开要求。

3. 作品名称、仓库地址等信息是否正确。

4. 公共访问页面是否能够打开。

这里需要特别注意：

验证不等于再次执行创建操作。

如果已经获得了真实作品 ID，正确做法通常是查询这条记录，而不是再次发送创建请求。

否则，原本用于确认成功的验证过程，反而可能造成重复发布。

此外，一些平台可能存在短暂的状态同步延迟。

因此，创建成功后暂时无法从公开查询接口看到记录，并不一定意味着创建失败。

这时应该根据平台文档，在有限时间内进行只读状态查询，而不是立即重新提交。

四、为什么只检查 HTTP 200 还不够？

HTTP 200 是开发中最常见的成功状态之一。

但它的含义取决于请求的是哪个接口。

例如：

GET /api/health

返回：

{
  "status": "ok"
}

这只能说明健康检查接口返回了预期结果。

它不能证明：

• 用户登录正常。

• 文件上传权限有效。

• 数据库写入正常。

• 应用发布接口可用。

• 当前账号具备执行某项操作的资格。

一个系统可能能够正常返回公开接口数据，却无法完成需要身份认证的写入操作。

因此，不能因为一个公开接口返回 HTTP 200，就认定整个系统的所有功能都已经就绪。

更合理的方式是建立能力级验证。

例如：

不同能力使用不同的验证方法，避免用一个简单的健康检查代表全部流程。

五、动手实践：用 Python 实现一个最小交付验收器

接下来通过一个简单示例说明：

如何不依赖 AI 的文字报告，而是使用程序验证实际交付文件。

假设某个 AI Agent 负责生成以下项目：

demo-project/
├── index.html
├── style.css
└── script.js

我们希望验证三个问题：

第一，文件是否真实存在。

第二，文件是否为空。

第三，HTML 是否正确引用 CSS 和 JavaScript。

可以使用 Python 标准库完成这项工作。

from pathlib import Path
from hashlib import sha256

PROJECT = Path("demo-project")

REQUIRED_FILES = [
    "index.html",
    "style.css",
    "script.js"
]

def verify_project():
    results = []
    all_passed = True

    for filename in REQUIRED_FILES:
        path = PROJECT / filename

        if not path.is_file():
            results.append({
                "file": filename,
                "status": "MISSING"
            })
            all_passed = False
            continue

        content = path.read_bytes()

        if not content:
            results.append({
                "file": filename,
                "status": "EMPTY"
            })
            all_passed = False
            continue

        digest = sha256(content).hexdigest()

        results.append({
            "file": filename,
            "status": "PASS",
            "size": len(content),
            "sha256": digest
        })

    index_path = PROJECT / "index.html"

    if index_path.is_file():
        html = index_path.read_text(
            encoding="utf-8"
        )

        if "style.css" not in html:
            all_passed = False
            results.append({
                "check": "CSS reference",
                "status": "FAIL"
            })

        if "script.js" not in html:
            all_passed = False
            results.append({
                "check": "JS reference",
                "status": "FAIL"
            })

    return all_passed, results


passed, report = verify_project()

for item in report:
    print(item)

print("交付文件检查：", "PASS" if passed else "FAIL")

这段代码并不复杂，但体现了一个重要的思路：

最终验收应该依据真实文件与可检查的结果，而不是只依赖 Agent 的总结。

同时也要清楚它的能力边界。

这段脚本只能检查文件存在性、非空、文件摘要和简单的引用关系。

它不能证明 JavaScript 逻辑正确，也不能证明页面能够在浏览器中正常渲染。

因此，还需要更进一步的测试。

六、为什么浏览器测试不能完全被代码检查替代？

对于网页类项目，静态检查很有用。

例如：

• JavaScript 是否有语法错误。

• HTML 是否引用了正确的文件。

• 资源是否缺失。

• 项目目录结构是否正确。

但这些检查无法完全模拟真实用户操作。

例如，一个随机选择工具可能有以下功能：

1. 用户输入多个选项。

2. 点击按钮。

3. 页面展示随机结果。

4. 用户复制结果。

即使随机函数的单元测试全部通过，也仍然可能发生：

• 按钮没有绑定事件。

• 结果没有显示到页面。

• 移动端布局错乱。

• 复制功能因浏览器权限问题失败。

这些问题需要使用浏览器进行验证。

例如，Playwright 自动化测试可以检查：

const { chromium } = require("playwright");

async function main() {
  const browser = await chromium.launch({
    headless: true
  });

  try {
    const page = await browser.newPage();

    await page.goto(
      "http://127.0.0.1:3000",
      { waitUntil: "load" }
    );

    await page.screenshot({
      path: "homepage.png",
      fullPage: true
    });

    console.log("页面标题：", await page.title());
    console.log("页面截图已生成");
  } finally {
    await browser.close();
  }
}

main().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

运行这个示例，需要事先安装 Playwright 及兼容的浏览器，并启动本地网站。

这段代码可以验证浏览器能否启动、页面能否加载以及截图能否生成。

如果还需要验证按钮功能，则应该增加定位元素、输入数据、点击按钮和断言输出等操作。

因此，浏览器能打开网页只是第一步。

真正的功能验收需要对应真实用户行为。

七、建立证据链：每一步都留下可检查的结果

对于多步骤 AI Agent，我比较推荐一种方式：

为关键任务步骤建立可验证的执行记录。

例如：

{
  "task": "publish_web_app",
  "steps": {
    "files": {
      "status": "passed",
      "evidence": "file verification report"
    },
    "tests": {
      "status": "passed",
      "evidence": "test result"
    },
    "git_push": {
      "status": "passed",
      "evidence": "remote commit"
    },
    "publish": {
      "status": "passed",
      "evidence": "remote work ID"
    }
  }
}

这里的 evidence 应该对应真实保存的验证信息，而不是模型自行编造的字符串。

例如：

文件检查可以保存文件摘要。

自动化测试可以保存退出码和测试结果。

Git Push 可以保存远端仓库地址与提交 ID。

发布操作可以保存服务端返回的作品 ID。

当任务中途失败时，Agent 也能根据已有证据判断哪些步骤可以复用。

不过，验证记录本身也需要可信。

如果只是让模型自行编写一份全部显示 passed 的 JSON 文件，那仍然无法证明任务真实完成。

更可靠的设计，是让验证程序从文件系统、测试运行结果以及远端服务中直接采集证据。

八、失败状态不能只有“成功”和“失败”

很多自动化系统习惯用两个状态表示任务执行结果：

SUCCESS
FAILED

但对于实际的 AI Agent，这通常不够。

例如，Agent 调用远程发布接口时发生网络超时。

它不知道服务端有没有创建成功。

这时不能直接标记为失败，因为操作可能已经完成。

也不能标记为成功，因为没有足够证据。

更合理的状态设计可以包含：

其中，UNKNOWN 和 BLOCKED 都很有价值。

UNKNOWN 用于表示结果不确定，例如远端请求超时。

BLOCKED 用于表示当前无法继续，例如浏览器环境不可用、授权不足或必要发布条件不满足。

这样，Agent 就不会为了生成一份看起来完整的报告，而把所有异常都归为“任务失败”或者“任务成功”。

九、环境预检也是交付可靠性的一部分

在跨平台自动化开发中，环境差异往往是影响成功率的重要因素。

例如：

同样的网页项目，在 Windows、Linux x86_64 和 Linux ARM64 环境中，所需的浏览器依赖可能不同。

某个自动化脚本虽然存在，但当前环境未必能够执行。

因此，在正式开始多步骤任务之前，可以快速检查：

• 操作系统与 CPU 架构。

• 必要的命令是否存在。

• 浏览器能否真实启动。

• 系统字体是否支持所需语言。

• 当前账号是否具备对应权限。

• 外部服务接口是否可用。

但这里也要避免另一种极端：

不要把环境预检变成无止境的检查过程。

合理的做法是只检测当前任务真正需要的能力。

例如，一个纯本地文本处理脚本，并不需要在开始运行前检查浏览器。

而一个必须生成网页截图的发布任务，则有必要提前验证 Chromium 是否能够启动。

这样既可以减少后期返工，又不会产生大量与任务无关的工具调用。

十、如何防止 AI Agent 伪造“完成证据”？

这是我认为最重要的一点。

假设某个发布工作流规定：

必须有浏览器截图，才能通过发布检查。

那么正确的做法应该是：

1. 真实启动浏览器。

2. 打开目标网页。

3. 生成截图。

4. 检查截图文件与页面内容。

5. 使用正式验证程序判断是否通过。

错误的做法则是：

直接创建一个名为“截图成功”的标记文件，然后跳过实际截图。

这种方式虽然可能让某些简单的检查显示通过，但并没有完成原本需要验证的工作。

同理：

不能自己编造测试通过的输出。

不能用本地文件存在代替远端发布成功。

不能把 API 连接正常当成用户权限已经验证。

也不能因为模型在最终报告中写了“完成”，就认定所有交付条件已经满足。

如果 AI Agent 被用于实际生产流程，这种区分尤其重要。

系统应该奖励真实完成任务，而不是奖励生成漂亮的成功报告。

十一、一个实用的 AI Agent 交付验收清单

对于需要修改代码、执行测试和发布应用的任务，我建议把验收规则直接写入用户的任务要求。

开发阶段

检查源代码是否真实存在，必要文件是否完整。

测试阶段

运行针对业务功能的测试，并保留真实结果。

环境阶段

验证任务必需的外部工具是否可用，不用无关检查拖慢执行。

上传阶段

确认远端仓库、分支及提交与预期一致。

发布阶段

依据正式接口返回的资源 ID 查询实际状态。

安全阶段

确认敏感凭据没有进入公开仓库、截图、压缩包或日志。

最终报告阶段

只报告已经获得证据支持的结果。

对于没有完成的步骤，明确说明阻断原因。

这样，开发者就可以更加清晰地判断：

哪些工作已经完成？

哪些仍然需要处理？

当前是否可以安全结束任务？

十二、总结

AI Agent 正在从传统的问答助手，逐渐发展为能够执行真实任务的自动化系统。

但当 AI 开始操作文件、调用 API、管理代码仓库和发布应用时，传统的“模型回答看起来正确”已经不足以衡量任务是否成功。

我们还需要关注：

工具有没有真正执行？

执行后有没有产生预期结果？

最终结果是否满足用户的业务目标？

通过执行状态检查、真实产物验证、远端状态查询和独立验收程序，可以让 AI Agent 的行为更加可靠。

本文最重要的观点可以概括为：

第一，工具执行成功不等于业务任务完成。

第二，不同能力需要不同的验证方法。

第三，关键步骤应当保留真实、可追溯的执行证据。

第四，未知结果应当继续核实，而不是直接判定失败。

第五，不允许通过伪造标记或编造日志替代必要验证。

我认为，随着 AI Agent 在自动化开发、运维和企业工作流中的应用越来越广泛，可验证的交付能力 将成为衡量智能体工程质量的重要标准。

未来优秀的 AI Agent，不应该只是告诉用户：

“我已经完成了。”

而应该能够进一步回答：

“我完成了哪些操作，有什么证据，以及你应该如何验证最终结果。”