AI Agent何时停止猜测：Qwen+MCP实战

不确定性作为一等公民输出

一笔付款恰好是某张发票金额的一半。支付者的电子邮件与文件中的客户相匹配。由 Paystack（非洲的 Stripe 等价物支付处理商）生成的参考号根本不匹配任何东西。

Qwen 看了一下，回复了 30% 的置信度和没有指定的发票名称。

我为全球 AI 黑客松系列用 Qwen Cloud 构建了 Recona，截止日期是 2026 年 7 月 20 日——一个自动对账 Paystack 支付与未结发票的 agent，并追收逾期的发票，简单情况下完全无需人工介入。这笔交易不应该是演示中有趣的部分。它反而成了整个要点。

如果你在尼日利亚从事自由职业或经营小企业进行支付收款，钱会以 PMT final tunde 这样的参考号到账，你得花一整晚弄清楚它结清了哪张发票——还有你忘记追的是哪个客户。Recona 自动处理两部分。它用 Qwen 将传入的支付与未结发票匹配，并运行日常催收扫描，在发票到期时起草并发送越来越严厉的提醒。

Cloudflare Workers 和 D1 处理摄取和编排——签名验证的 Paystack webhooks，对重复交付具有幂等性。阿里云 SAS 运行一个 Dockerized Node 服务，包含所有 Qwen 推理逻辑，独立部署在摄取层之外。对账引擎以 REST 和 MCP 工具的形式暴露其匹配引擎——match_transaction_to_invoice、draft_payment_reminder——通过流式 HTTP。Telegram 是人在回路中的交互界面，因为这里的实际工作是关闭工作流本身，而不是另一个要登录的仪表板。

我设计的规则是：模型提议，确定性代码决定。自动结清发票需要金额精确、货币匹配以及置信度超过阈值——在 Qwen 响应后在代码中检查，绝不信任提示词。LLM 读出凌乱的笔迹。计算器授权这笔存款。

我预期演示的内容

我计划了一个干净的故事。客户支付发票的一半。Qwen 正确识别出是哪一张。我的确定性守卫仍然阻止自动结清，因为金额错了。模型是对的，代码出于安全考虑推翻了它。好的演示节拍。

这不是发生的事情。

我通过真实系统运行了真实交易——实际的 Cloudflare Worker，位于 recon-ingest.fpl-test.workers.dev，实际部署的对账程序，实际的 Qwen API。我运行了两次：一次针对原始发票，一次在将新发票重新生成为正好是支付金额两倍后再运行，以排除巧合。

两次，对于一笔与发票客户电子邮件相匹配但金额恰好是一半的支付，引用号与任何发票号都没有任何关联，Qwen 都返回了 30% 的置信度和没有已承诺的发票 ID——尽管它自己的推理文本按 ID 命名了正确的发票。它没有错。它只是不愿意对没有足够信号支持的答案做出承诺。

我有个选择：强制演示视频与我已经写好的脚本相匹配，或者让它展示模型实际做的事情。我改写了叙述以匹配现实。

为什么诚实的版本是更好的演示

我设计的是防范我担心的失败模式——一个充满信心的错误答案溜过我的守卫。我没有同样仔细地设计防范相反的模式：一个被谨慎包裹得如此之紧的系统，以至于模型自己的确定性永远无法成为可用的信号，人类最终会审查一切，不管模型是否真的知道答案。

我看到的介于两者之间。Qwen 大声推理了正确的发票，拒绝声称它，并向编排层传递了一个可读的数字——30%，原因如下。这正是你可以围绕它构建策略的东西。我的自动结清门不必评判模型的猜测是否正确。它只需要信任 Qwen 已经自己计算的关于自己的置信度数字，并在该数字较低时默认由人工处理。

不要构建你的安全层来捕捉模型何时出错。要构建它来将模型自己的不确定性视为第一输出，并将你的防护栏放在那个上面。替代方案要求你在判断模型自己的答案方面比模型更聪明。这个只需要模型对它不知道的东西诚实——在我的测试中，Qwen 是的。

一个总是很确定的初级员工很难信任。一个说"我 30% 把握，原因如下"的员工才是你真正可以围绕它建立流程的。

项目库：github.com/dannwaneri/recona——MIT 许可证。为全球 AI 黑客松系列用 Qwen Cloud 构建，Track 4：自主驾驶 Agent。

一些评论可能只对已登录访问者可见。登录以查看所有评论。

若有其他操作，你可以考虑屏蔽此人或/和报告滥用行为。