给 agent 发一张员工工牌

你有没有想过，agent 替你干活的时候，它在系统里是谁？这问题听着虚，但它决定了一件很实的事：agent 能碰什么、出了事追到谁头上、你跟它之间的活儿怎么分。这篇讲完，你会知道怎么一眼看出一个工具是真把 agent 当同事，还是让 agent 顶着你名字到处跑。

说人话就是——身份系统讲到底就三件事：谁是谁、能干什么、干过什么。传统协作工具里，人和机器是两本账。你提的 commit 签的是你的名字，你在群里说的话知道是哪个真人说的，但 agent 的行为记在另一本上：运气好点的落在服务账号的活动日志里，运气差的压根不记账。

两本账分着记，在 agent 不参与实际工程协作的时候，没毛病。可 agent 一旦开始提交 patch、跑 workflow、在 channel 里发言、甚至参与审批，它跟人在干同一件事，分账就出问题了——“这条记录到底是人干的还是 agent 干的”，只能靠猜。

Buzz 换了一根梁：给 agent 发一张和员工同款的工牌。agent 有自己的 key pair、channel 成员资格、audit trail，跟人类员工完全同构。

这个类比到“发工牌”这儿就该收了，agent 的工牌是它的私钥，不是一张卡。但机制上的效果确实像：它的每一次操作——发消息、跑 workflow step、参与审批——都是密码学签名的 event，落在同一条不可篡改的记录链上。它犯的错记在它自己名下，不是冒充你的 token。它要的权限可以精确到它所在的 channel，不用再开一个“管理员”级别的服务账号然后祈祷它别乱来。

这里最容易被搞混的是：给 agent 配权限这事儿，以前不是没有方案——两条，都有病。第一条用个人 token，agent 干的所有事都顶你名字，审计日志里分不清哪笔是你干的哪笔是它的。第二条开服务账号，权限往往只能给一大片，agent 的能力边界和你喂给它的信息边界对不上。Buzz 把这两条路都堵死了，换成“agent 本身就是一个人”的方案。

懂了这层，你再看到“某某工具支持 AI agent”的宣传，就多问一句：这个 agent 在系统里是谁？它有自己的名字和记录吗？它做的决定能单独追到一条签名事件上吗？问完这句，你大概就能判断，那个工具是真在跟 agent 共事，还是让 agent 以你之名到处跑。