当 AI agent 开始真的替你敲命令、改文件、跑 CI，最麻烦的往往不是“它做不做得到”，而是出事后你还能不能还原它做过什么。一次 session 里有哪些 prompt、哪条命令改了哪个文件、一个审批为什么被点过——这些信息通常散在不同的 CLI、编辑器、浏览器和 CI 日志里。只看聊天记录，既难审计，也很难把同一台机器上不同 agent 的行为放到一起比较。

今天看的是 Asymptote-Labs/agent-beacon。它是一个面向 AI agent 的开源遥测层：在 agent 实际运行的位置采集 execution trace，并将 session、prompt、tool、command、file、approval 和 token 等事件规整为统一 schema。开源模式默认将持久化 JSONL 与只读 dashboard 留在本机；需要时也可以把同一份日志转送到自有 SIEM、可观测性平台或对象存储。

按 GitHub repository、README、LICENSE、main 分支 commit API 和 Releases API 在 2026-09-15 18:04 Asia/Shanghai 可核验的信息，Asymptote-Labs/agent-beacon 当前有 448 stars、36 forks，主要语言是 Go，license 是 MIT。仓库创建于 2026-05-12 02:49:33 UTC；latest push 为 2026-09-15 07:29:50 UTC。最新 main commit 是 38aca147，提交时间 2026-09-15 07:29:50 UTC，标题为 Add trust command to brew installation (#508)，属于 Homebrew 安装说明更新。最新 GitHub Release 是 v1.3.10，发布于 2026-09-12 17:49:58 UTC。

项目概览

属性详情
仓库Asymptote-Labs/agent-beacon
定位跨本地、浏览器、CI、云端的 AI agent 统一遥测层
Stars / Forks448 / 36
主要语言Go
许可证MIT
创建时间2026-05-12 02:49:33 UTC
Latest push2026-09-15 07:29:50 UTC
最新 commit38aca147，Add trust command to brew installation (#508)
最新 Releasev1.3.10，2026-09-12 17:49:58 UTC
安装入口brew trust asymptote-labs/tap && brew tap asymptote-labs/tap && brew install beacon
启动入口beacon endpoint install，随后 beacon endpoint dashboard

它解决的是 agent 行为的“拼图问题”

Agent Beacon 的重点不是另造一个聊天界面，而是补齐可观测性里的缺口。README 列出的统一事件模型包含 session、prompt、工具调用、命令、文件改动、审批与 token；它能覆盖 24 种本地 agent runtime，也覆盖 browser chat、CI、cloud agent 和 SDK instrumentation。这样在排查“这个改动是谁、在哪个 runtime、经由什么工具做的”时，不必先把四五套日志手工对齐。

更值得注意的是它的默认边界：开源模式下，日志写为本地 JSONL，dashboard 也是只读的本地界面，不要求账号、API key 或网络。对想先了解自己机器上的 Codex、Claude Code、Cursor 或其他 agent 到底做了哪些操作的人，这比一上来把完整 prompt 和命令流交给托管平台更容易接受。README 也说明同一日志可以由用户控制地转送到 SIEM、日志平台或对象存储，因此本地优先并不等于与现有 observability 栈隔绝。

从一台开发机开始验证

README 给出的 macOS/Linux 入口很短：安装 Homebrew tap 后安装 beacon，运行 beacon endpoint install 将本地 runtime 指向 endpoint，接着用 dashboard 观察事件。

brew trust asymptote-labs/tap
brew tap asymptote-labs/tap
brew install beacon

beacon endpoint install
beacon endpoint dashboard

事件默认落在 ~/.beacon/endpoint/logs/runtime.jsonl。一个实际的试用方式是：先在非生产开发机只接入一种日常使用的 agent，跑几次明确的 code-change 和 test workflow，再回看 session、command、file 与 approval 是否足以回答团队平时的排查问题。确认事件量、字段和保留策略后，再考虑把 JSONL 交给现有的安全或可观测性管道。

离线扫描让遥测不只用于回放

项目还提供 beacon scan，可对本地日志运行开放的 Threat Rules，不依赖网络。这个位置很实在：AI agent 的风险并不只有模型回答错，还包括提示注入后触发了什么命令、某个工具为什么访问了不该访问的路径、审核步骤是否被绕过。结构化事件不会自动判断上下文是否安全，但它至少为本地检测和事后分析提供了比 terminal scrollback 更稳定的输入。

最新的 v1.3.10 增加了对 Goose harness 名称与 hooks event 映射的调整、CLI 安装与 threat-rule 使用示例等改动。这也说明它仍在快速扩展采集面；不同 runtime 的事件完整度并不一定相同。上线前应先针对你实际使用的 harness 验证它能采到哪些字段，而不要仅凭支持列表假设所有 command、file 或 token 信息都会出现。

使用前要先决定数据边界

“本地优先”不等于日志没有敏感性。prompt、命令、文件路径乃至审批记录都可能包含客户信息、密钥线索或内部项目名。应先审阅采集范围和 retention，限制 JSONL 的本地访问权限，并只把经过团队安全评估的字段转送出去。若要在多设备或组织范围铺开，还要额外评估 MDM、SIEM connector 和权限模型，而不是把单机 quickstart 直接当成企业方案。

如果你的痛点是让个人开发机上的多个 agent “留痕并能回放”，Agent Beacon 很值得用一台测试机先跑起来；如果需求只是某个单一 agent 的简单运行日志，现有 harness 的内置记录可能已经足够。它最有价值的地方，是把 agent activity 变成能被审计、检测和转送的工程数据，而不是另一份孤立的聊天记录。

总结

Agent Beacon 把“agent 真的做了什么”从每个工具各自的黑箱里拉出来，做成一份可统一查询的事件流。其本地 JSONL、只读 dashboard、离线规则扫描和按需转送的组合，很适合先在一台开发机建立可观测性基线，再决定是否走向团队级的安全与遥测体系。

项目地址：https://github.com/Asymptote-Labs/agent-beacon