AI agent 越来越多地接入文件系统、邮件、数据库、CI 和内部工具。问题也随之变得具体：一次工具调用是谁发起的，执行了什么动作，结果是什么，是否和上一条记录连在一起，事后还能不能验证这条记录没有被随手改掉。

今天推荐的 agent-receipts/obsigna 就在做这件事。它围绕 Agent Receipts 协议实现了一套参考工具，用签名收据和链式记录描述 AI agent 动作，并提供 daemon、MCP proxy、Claude Code / agent runtime hook、CLI，以及 Go、TypeScript、Python SDK。它不是一个替代 observability 平台的大而全产品，更像是给 agent 行为审计补上一层结构化、可验证的底座。

发布时 GitHub 数据显示项目约 20 stars、4 forks，主要语言是 Go，仓库同时包含 Python 和 TypeScript SDK。项目创建于 2026-04-02，最近更新时间为 2026-06-16，主仓许可为 Apache-2.0，协议规范目录使用 MIT 许可。最新 GitHub release 是 obsigna v0.25.0，发布时间为 2026-06-13。

项目概览

属性详情
仓库agent-receipts/obsigna
定位AI agent 动作的签名收据和审计链工具集
Stars约 20
Forks约 4
主要语言Go
许可Apache-2.0；协议规范为 MIT
最新版本obsigna v0.25.0

它把“agent 做了什么”变成一条收据

很多 agent 日志只是普通文本：工具名、参数、输出、时间戳。它们能帮助调试，但如果要交给安全团队、合规流程或下游服务判断，就会缺少几个关键问题的答案：记录格式是否稳定，动作类型是否可分类，记录是否签名，前后事件是否能连成一条审计链。

Agent Receipts 的思路是把一次动作写成结构化 receipt。收据里包含 issuer、principal、action、outcome、sequence、chain id 等字段，再通过签名和 hash chain 把它变成可验证的记录。这样做的价值不是让 agent 变得绝对可信，而是让事后检查有一个明确对象：哪条记录、哪个 key、哪段链、哪个动作类型、哪个结果。

Obsigna 是这个协议的参考实现。仓库里既有协议规范和 JSON schema，也有可以直接嵌入应用的 SDK，还有围绕 agent runtime 的工具。对工程团队来说，这比只看一份协议文档更容易试：可以先在本地生成几条 receipt，再决定是否把 daemon 或 MCP proxy 接到真实工作流里。

工具层拆得比较清楚

Obsigna 仓库里的几个组件职责分明。

obsigna-daemon 负责把签名 key 放到 agent 进程外，由 daemon 持有 key 并维护审计链。这个设计很重要：如果签名 key 直接放在 agent 进程里，那么 agent 一旦被提示注入或任意代码执行影响，就可能自己伪造收据。daemon 不能解决所有威胁，但至少把 key custody 从业务代码里拆了出来。

obsigna-mcp 是 MCP stdio proxy。它可以包住已有 MCP server，在工具调用周围添加签名收据、policy hook 和风险评分。对已经围绕 MCP 构建 agent 工具链的团队来说，这条接入路径很自然：不一定要改每个工具 server，先在代理层记录每次 tool call。

obsigna-hook 则面向 Claude Code 这类支持 tool-use hook 的 runtime。README 给出的例子是通过 PostToolUse hook 自动记录工具调用，然后用 CLI 查看和验证审计链。这个路径适合个人或小团队先试，不需要马上搭一整套平台。

最后是 obsigna CLI 和 Go / TypeScript / Python SDK。CLI 用于浏览、展示、验证 receipt database；SDK 则让应用自己创建和签名收据。对需要自定义 agent runtime、内部任务 runner 或安全网关的团队来说，SDK 会比 proxy 更灵活。

它值得关注的不是“签名”两个字

给日志加签名并不新鲜。Obsigna 更值得看的地方，是它把 agent 场景里的几个维度一起建模了。

第一，动作类型不是随便写一句话。README 示例里能看到类似 filesystem.file.read 这样的 action type，以及 risk level、outcome status、chain sequence 等字段。只要分类足够稳定，后续就可以围绕动作类型做策略、告警和审计查询，而不是在日志字符串里搜关键词。

第二，它承认不同部署有不同信任模型。README 里的 SDK quick start 明确提醒：如果 key 留在 agent 进程内，那么拥有该进程代码执行能力的人可以伪造收据；要防 compromised agent，应该走 daemon-mediated path。这个边界说得清楚，比把“签名日志”包装成万能安全方案更可靠。

第三，它把 MCP 当成一等入口。现在很多 agent 工具都通过 MCP 暴露，如果每个 MCP tool call 都能在代理层留下 receipt，团队就可以逐步把“agent 调了什么工具”从 debug log 提升为审计数据。特别是涉及邮件、工单、云资源或生产数据库的工具，这类记录很快会变得必要。

适合什么场景

我觉得 Obsigna 适合从低风险链路开始试。

第一类是本地 coding agent 或内部 agent runner。先记录文件读取、命令执行、代码修改、PR 操作这类动作，验证 receipt 是否足够表达真实工作流，再决定是否扩大到敏感工具。

第二类是已经在用 MCP 的团队。用 MCP proxy 包住一两个重要 server，例如 issue tracker、deployment helper、database read-only tool，观察 signed receipt 能否帮忙回答“哪次 agent 调用了什么”。

第三类是做 agent 平台、agent gateway 或内部安全审计的团队。与其每个工具都写一套私有日志格式，不如先评估一个公开协议和跨语言 SDK，看看能不能把收据作为事件边界。

它暂时不适合被当成完整合规平台。仓库提供的是协议、工具和参考实现，不是权限系统、SIEM、审批流、长期归档和组织级报表的全部替代品。真正落地时，还需要考虑 key 管理、数据库权限、receipt retention、隐私字段脱敏，以及审计数据怎么进入现有安全系统。

小结

agent-receipts/obsigna 的方向很务实：AI agent 的能力越强，越需要把关键动作从“控制台日志”提升成“可验证记录”。它用 receipt format、签名、链式结构、daemon、MCP proxy 和多语言 SDK，把这个问题拆成可以试跑的工程组件。

我最喜欢的一点是它没有回避信任边界。in-process SDK 适合快速嵌入，但 daemon-mediated path 才更适合对抗被影响的 agent 进程；MCP proxy 适合低侵入接入，但不能替代更完整的策略和权限系统。对正在把 AI agent 接入真实工具链的团队来说，Obsigna 是一个值得提前观察的小众项目。