博客

我的 AI 智能体到底做了什么?用证据回答四个问题

每个 AI 智能体任务,你都应该看到是谁做的、改了什么、跳过了什么、为什么这样做,并有可核查的证据,而不只是一条写着“完成”的评论。

Weft 是为独立创业者和小团队打造的 AI 任务管理工具。

全部文章

作者: Andrei Finogeev ·

想知道你的 AI 智能体做了什么,别从它的总结开始看。检查四件事:是哪个连接做的,改了什么(用你自己能打开的东西来证明),哪些没做,以及做了什么决定、为什么。只要四项里有一项只凭智能体一面之词,你手里的就是叙述,而不是记录。

Weft 是我们做的。关于其他产品的事实来自它们的官方页面,核对于 2026年10月27日。

为什么一条写着“完成”的评论不够?

评论是智能体在描述自己的工作。它很可能是准确的,但评论本身证明不了这一点,因为作者恰恰就是你要核查的那一方。知道某个智能体动过某个任务,回答的是“谁”。它回答不了这项工作是不是你以为的那样。

Hypertask 关于 AI 工作归属的文章提出了一个中肯的观点:智能体的工作应该和人的工作落在同一块看板上,而不是躺在没人看的终端日志里。Hypertask 还让智能体以服务账号的形式拥有自己的身份,所以写入记在智能体名下而不是你名下;它也有任务证据和租约,不过它的文档说,这些有意只作为 REST 端点提供,而不是 MCP 工具。我们的分歧在于记录里应该装什么。一串带着智能体输出的评论,是智能体说过什么的日志。我们希望记录里装的是证据。

这篇指南里没有调查数据。今天下午你就可以在自己的看板上检验这四个问题,这比任何行业平均数都更能说明问题。

这四个问题是什么?

随便挑一个智能体上周完成的任务。不问智能体、不打开它的对话,你应该能在一分钟内回答下面每一个问题:

  1. 谁做的?是哪个客户端、通过哪个连接认领并完成了这个任务。
  2. 改了什么?结果,以及你不必信任智能体就能核查的产物:提交哈希、URL、文件、消息 id。
  3. 哪些没做?它跳过的部分,以及它拿不准的地方。
  4. 做了什么决定,为什么?过程中做出的任何选择、权衡过的选项,以及你每一次把工作退回的情况。
问题弱答案:一条写着“完成”的评论强答案:可以核查的证据
谁做的?每处改动都写着“智能体”或你自己的名字,因为所有工具共用一个密钥认领并完成任务的那个连接,显示客户端注册时的名字,每条日志事件都标明来自人还是 MCP,并带有客户端 id
改了什么?“重构了认证模块,测试通过”提交哈希、PR 或页面 URL、带 sha256 的文件、消息 id:你自己能打开的东西
哪些没做?什么都没说,于是你以为什么都没跳过一份 notDone 清单(“没有在 staging 上跑迁移”)和一份 unknowns 清单(“不确定旧端点有没有别的调用方”)
做了什么决定,为什么?埋在一段早已滚走的对话里一条决策记录,写明权衡过的选项和重新审视的条件,再加上任务的决策历史,包括它为什么被退回

怎么知道是哪个智能体做的?

Weft 通过 Model Context Protocol 在一个端点 https://letsweft.com/api/mcp 上连接 AI 客户端。每个 OAuth 客户端和每个个人访问令牌都是一个独立的操作者。任务会记录是哪个客户端创建的,看板上显示该客户端登录时注册的名字,外加一个图标。任务日志里的每条事件都会保存它来自人还是来自 MCP,以及是哪个客户端发出的。

完整日志(get_task_history 的 full 模式)会显示每条事件的原始客户端 id:一个 OAuth 客户端 id,或者 mcp-token 后跟令牌的 id。它不是好读的名字,但很精确,即使两个连接来自同一个产品,也能把它们区分开。

工作期间的归属也是明确的。智能体调用 start_task,用 20 分钟的租约认领任务并把它移到 Doing。report_progress 续租。第二个尝试同一任务的智能体会收到 already_claimed,而过期的租约会把任务释放给别人。认领循环指南逐步讲解了这些,在一块看板上运行多个智能体讲的是多客户端的情况。

一条实用规则:给每个工具单独一个连接。如果两个客户端共用一个访问令牌,看板只会看到一个操作者,“谁做的”这个问题就失去了答案。

改了什么?不问智能体能核查吗?

智能体完成时,会调用 complete_task。只有任务 id 是必填的;其他一切都是可选的,这个调用永远不会因为缺少证据而失败。这是有意为之:丢掉已完成的工作,比把它记成未经验证更糟。一张回执可以包含:

  • outcome:最多 1,000 个字符,说明做了什么、结果在哪里。
  • artifacts:最多 20 条,每条包括类型(url、file、message、commit 等)、位置,以及可选的 sha256 摘要。
  • claims:智能体声称自己做了的事,作为声明而非已验证的事实保存。
  • notDone 和 unknowns:下一节会讲。
  • nextStep:如果你接受,智能体接下来会做什么。
complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

outcome 那一行仍然是叙述。产物才是你能核查的部分。一个提交哈希要么在你的仓库里存在,要么不存在。一个 URL 要么能打开,要么打不开。一个文件的 sha256 要么对得上,要么对不上。如果一张回执只有 outcome 而没有产物,就把它当作智能体自报的工作,因为它就是这样。在网页上,Done 里的卡片会显示任务是“已验证”还是“智能体自报”。

智能体没做什么?

这是大多数记录都会跳过的问题,也是两周后会反咬你一口的问题。complete_task 为此准备了两份清单,每份最多 20 条、每条 500 个字符:notDone 记录智能体有意略过的部分,unknowns 记录它拿不准的地方。这个工具自己的描述就要求智能体明明白白说出自己没做什么。这正是“一个你能依赖的结果”和“一个你得重新推敲的结果”之间的区别。

先读这两份清单。“没有针对 staging 数据库跑测试”会改变你下一步要做的事。一个大任务的回执里如果一条 notDone 都没有,这本身就值得问一句。

做了什么决定,为什么?

在对话里做出的决定,会随着对话滚走而消失。record_decision 用两种方式把它们留下来:

  • 一条独立的决策记录:标题、结论、背景、实际权衡过的选项、后果,以及在什么条件下需要重新审视。记录不可修改;要改,就记一条新决策来取代它,旧的仍然保留,并标为已被取代。
  • 一次裁决转达:当你在对话里对智能体说“接受”、“按 X 重做”、“放弃”或“现在不做”时,它会把这个裁决连同你的备注记到任务上。

get_task_history 用三种模式把它们读回来:summary(卡片、最新回执和计数)、decisions(关于这个任务的每一个决定,包括它为什么被退回,即使之后被接受,这些也会保留)和 full(原始日志,最多 100 条事件)。get_context 会在 token 预算内把仍然有效的决定交给下一个智能体,让下一次运行从已经定下的事情出发,而不是从零开始。更多内容见为什么 AI 对话里的决定会丢失。

在哪里审阅?该点什么?

默认情况下,完成的任务直接进 Done。当任务需要审阅,或验证检查没通过时,它会停在你的收件箱里。你在那里能看到回执和四个按钮:“接受”、“返工”、“以后再说”和“放弃”。选“返工”时要写一条备注,这条备注会回到智能体那里。

如果智能体传了 nextStep,它会显示在“接受”按钮上方,而接受批准的恰好就是这一步。批准有效期 72 小时,会通过 get_my_work 或 start_task 回到智能体那里,作为下一步唯一要做的事。智能体用 request_input 提的问题会进入同一个收件箱,网页和 iOS、Android 应用上都有,同时发送手机推送。

收件箱是有意设了上限的:单人工作区 5 个待处理项,团队 10 个,或者预估审阅时间 45 分钟,以先到者为准。满了之后,start_task 会用 attention_queue_full 拒绝,于是智能体会去完成或澄清已有的工作,而不是堆出更多等你检查的东西。

不同类型的任务该要什么证据?

把这些写进任务描述,让智能体知道你期望什么样的证据:

  • 代码:把提交哈希和 PR 链接作为产物。notDone 应该写明没跑的测试、没执行的迁移,以及有意没动的文件。
  • 内容:已发布的 URL;如果还没上线,就给草稿文件和它的 sha256。unknowns 应该列出智能体没能确认的事实。
  • 调研:每个关键论断给一个来源 URL,再加上笔记文件。unknowns 应该把来源说的和智能体推断的区分开。
  • 外联:每条已发送消息的消息 id,以及作为文件的收件人列表。notDone 应该列出没联系上谁、为什么。

怎么从一开始就控制智能体能做什么?

事后归属,最好配上事前限制。在 Weft 里,每个 OAuth 连接有三种权限级别之一,在授权页面上设置,或者之后在设置 → 已连接的 AI 客户端里修改:

  • full(默认):全部 32 个工具。
  • write:除三个破坏性工具(trash_task、archive_done_tasks、complete_sprint)之外的全部。
  • read:只有 11 个只读工具。

每次调用都会检查权限。断开连接会撤销该连接的刷新令牌,并在下一次调用时拒绝断开前签发的任何令牌。个人访问令牌是给不支持 OAuth 的客户端用的,没有权限范围:一个令牌就能用全部 32 个工具,撤销会在下一次调用时生效。智能体可以把任务移入保留 30 天的回收站,但不能永久删除;从回收站还原是 Pro 功能。

这方面 Weft 不做什么?

  • 它没有 GitHub 或 Slack 集成,所以 Weft 不会替你查你的提交或消息。产物要你自己打开。
  • 它没有公开的 REST API、webhook 或 CLI,没法把回执推送到其他系统。有 JSON 和 Markdown 导出。
  • 它不追踪模型的每一步。在模型层记录提示词、token 和延迟的工具做的是另一件事,你可能也需要一个。
  • 回执是智能体自己写的。Weft 能让声明和证据之间的差距一目了然,但没法让智能体变诚实。

如果你想通过 REST API 把智能体当作服务账号来管理,想要给 CI 脚本用的 CLI,或者想要写任务、分拣这类内置 AI 功能,Hypertask 更合适。我们的 Hypertask 替代方案页面对两者做了并排对比。

看 git 历史不就能知道智能体做了什么吗?
Git 显示的是代码改了什么。它显示不了智能体跳过了什么、对什么拿不准,或者在两个选项之间选了哪个。把提交哈希作为任务上的产物,其余的留在回执和决策记录里。
智能体不能随便编一个产物吗?
它可以发送任意字符串。产物的意义在于你能打开它:一个你能查的哈希、一个你能加载的 URL、一个你能找到的消息 id。编出来的产物一查就露馅,而评论永远不会。当任务带有验证检查且某项阻断性检查失败时,任务就进不了 Done。
每个完成的任务都要等我审阅吗?
不是。默认情况下,完成的任务进 Done。只有当任务需要审阅或验证检查没通过时,它才会在你的收件箱里等你选择“接受”、“返工”、“以后再说”或“放弃”。
哪些 AI 客户端能往 Weft 写回执?
任何 MCP 客户端。在 ChatGPT 里,Weft 是已发布的插件,所有方案都能用,包括免费版。Claude Code 用 claude mcp add --transport http weft https://letsweft.com/api/mcp 连接。Claude.ai 和 Claude Desktop 用自定义连接器。一共有 33 个客户端的设置页面,比如 Claude Code、ChatGPT、Cursor 和 Codex。
这要花多少钱?
免费版包含 50 个任务和每月 200 次 AI 调用。Pro 每席位每月 $7 或每年 $60。Weft 没有 AI 点数:思考发生在你自己的 AI 客户端里。参见价格。