AEVS AEVS 为 AI 代理提供执行验证 SDK，记录工具调用并生成可验证凭证，帮助团队验证代理实际执行内容。 热门评论 PH 用户Hey Product Hunt 👋我们在Fetch AI构建了AEVS，因为随着AI智能体开始执行实际任务，回答一个简单但重要的问题变得越来越难：智能体到底执行了什么？🤔聊天记录能告诉你智能体说了什么。日志也有帮助，但它们往往分散、不完整，或者容易丢失。对于那些调用工具、触发工作流、移动数据或与外部系统交互的智能体，团队需要更可靠的东西：一份可验证的执行记录 ✅这就是AEVS提供的。AEVS是一个即插即用的SDK，它能记录每一次AI智能体的工具调用，生成防篡改的执行回执 每份回执包含使用的工具、输入、输出、状态和时机，这样团队就能验证智能体实际做了什么，而不必仅依赖聊天记录或脆弱的日志。目标是让智能体执行更加可信、可审计，并且适合生产环境 🔐它是为使用LangChain/LangGraph、MCP工具和自定义智能体栈的构建者设计的 🛠️你可以将AEVS添加到现有工作流中，无需从头重建智能体，即可开始为工具调用生成可验证的回执 🚀我们特别关注那些智能体执行重要操作的用例：客户支持工作流、财务操作、内部工具、合规敏感任务、数据管道和API自动化我非常希望听到来自智能体构建者、基础架构团队以及任何考虑AI系统信任与验证问题的人的意见 🙌PH 用户我们特别兴奋的一点是，AEVS集成起来非常容易。✅ 大约2行代码即可集成✅ 目前已支持LangChain、LangGraph和MCP✅ CrewAI支持即将上线你甚至可以直接告诉你的编码智能体：Read https://aevs.fetch.ai/llms.txt and add AEVS to my agent，它就能帮你把AEVS直接整合到工作流中。我们的目标很简单：让可验证的智能体执行变得触手可及，同时不强迫开发者重新设计现有架构。PH 用户回执模型对于工具调用可能改变客户状态（比如支持运营或计费自动化）的智能体工作流来说很有意义，聊天记录远远不够。将输入、输出、状态和时机作为回执捕获看起来很有用，但我担心的一个边界情况是敏感负载。团队是否可以在写入回执之前编辑特定字段，同时仍然保持证据防篡改？PH 用户这点我很有共鸣。我发布了一个用于广告账户监控的MCP服务器，结果发现每次工具调用的审计日志（工具、清理后的参数、延迟、结果）成了人们最信任的功能，尤其是当智能体可以在真实账户上触发操作时。我想补充一点：回执回答了“发生了什么”，但对于涉及资金流动或改变客户状态的操作，更大的价值是在执行之前拦截写入，而不仅仅是事后证明。回执加上审批步骤才是真正的组合拳。你们考虑过预执行钩子吗？还是AEVS纯粹是调用之后生成的记录？PH 用户恭喜发布！随着智能体变得越来越自主，了解它们实际做了什么和它们说了什么变得同等重要。执行回执的概念真的很有意思。PH 用户它是否使用了TEE？那样更安全，还能保证执行证明。不过想法不错。 热门产品Mehul2026-06-15原文 打开互动版
我们在Fetch AI构建了AEVS，因为随着AI智能体开始执行实际任务，回答一个简单但重要的问题变得越来越难：
智能体到底执行了什么？🤔
聊天记录能告诉你智能体说了什么。日志也有帮助，但它们往往分散、不完整，或者容易丢失。对于那些调用工具、触发工作流、移动数据或与外部系统交互的智能体，团队需要更可靠的东西：一份可验证的执行记录 ✅
这就是AEVS提供的。
AEVS是一个即插即用的SDK，它能记录每一次AI智能体的工具调用，生成防篡改的执行回执
每份回执包含使用的工具、输入、输出、状态和时机，这样团队就能验证智能体实际做了什么，而不必仅依赖聊天记录或脆弱的日志。
目标是让智能体执行更加可信、可审计，并且适合生产环境 🔐
它是为使用LangChain/LangGraph、MCP工具和自定义智能体栈的构建者设计的 🛠️
你可以将AEVS添加到现有工作流中，无需从头重建智能体，即可开始为工具调用生成可验证的回执 🚀
我们特别关注那些智能体执行重要操作的用例：客户支持工作流、财务操作、内部工具、合规敏感任务、数据管道和API自动化
我非常希望听到来自智能体构建者、基础架构团队以及任何考虑AI系统信任与验证问题的人的意见 🙌
✅ 大约2行代码即可集成
✅ 目前已支持LangChain、LangGraph和MCP
✅ CrewAI支持即将上线
你甚至可以直接告诉你的编码智能体：Read https://aevs.fetch.ai/llms.txt and add AEVS to my agent，它就能帮你把AEVS直接整合到工作流中。
我们的目标很简单：让可验证的智能体执行变得触手可及，同时不强迫开发者重新设计现有架构。