凌晨3点删库后，我花48小时造了个"甩锅终结者"

多智能体系统崩了的时候，最可怕的不是故障本身，是没人认账。

你的产品经理智能体说需求文档没问题。你的代码智能体说按规格写的。你的验证智能体说根本没收到输出。你对着几千行日志grep到凌晨，一无所获。

这就是"责任真空"——每个环节都在踢皮球，每个日志都在打哑谜。开发者Harshit Joshi被这个场景折磨够呛，干脆自己动手造了个开源工具：Agent Blame-Finder。3秒定位肇事智能体，用密码学签名把"谁干的"钉死在账本上。

凌晨删库事件：一场没有凶手的犯罪

Joshi的灵感来自一次真实的 staging 数据库删除事故。多智能体流水线（multi-agent pipeline）在执行任务时突然清空了测试库，团队花了4小时翻日志，最后发现是需求传递环节的语义漂移——PM智能体写的"清理临时数据"被Coder智能体理解成了"删除整个数据库"。

但日志里只有执行记录，没有决策链条。三个智能体互相隔离，因果关系断了。

「我们不是在调试代码，是在做考古。」Joshi在GitHub仓库的README里写道。他意识到，现有监控工具能告诉你"发生了什么"，但回答不了"谁的决定导致了什么"。这是智能体时代的独特痛点：当多个AI协作时，责任边界比人类团队更模糊。

Blame-Finder的核心设计很克制——两个IETF互联网草案（Internet-Drafts）的落地实现。JEP（Judgment Event Protocol，判决事件协议）定义了密码学签名的日志格式，每个智能体决策生成一张"收据"；JAC（Judgment Accountability Chain，判决责任链）用task_based_on字段把决策串成树状结构，像Git的提交历史，但记录的是"谁基于什么上下文做了什么判断"。

四个动词覆盖全部场景：J（Judge，判断）、D（Delegate，委托）、T（Terminate，终止）、V（Verify，验证）。任何多智能体流程都能用这个语法描述。

装饰器哲学：不改一行业务代码

技术实现上，Joshi选了一条对开发者最友好的路。Blame-Finder用Python装饰器（decorator）包裹现有函数，零侵入：

from blame_finder import BlameFinder

finder = BlameFinder(storage="./blackbox_logs")

@finder.trace(agent_name="Coder-Agent")

def write_code(requirement: str) -> str:

# 你的原有逻辑，完全不用改

# 出事后：

print(finder.blame(incident_id="task_123"))

装饰器自动处理哈希计算、签名生成、存储落盘、链式关联。开发者不需要理解JEP/JAC的细节，就像用git commit不需要懂SHA-1。

对比传统调试和Blame-Finder的差异，表格很直观：原来几小时的日志挖掘变成一条命令；原来"可能是Agent X"的猜测变成密码学证明；原来断裂的因果链变成可视化的树状图。Joshi在仓库里放了一张截图， causality tree（因果树）可视化界面长得像GitKraken的提交图谱，但节点是智能体决策。

这个设计选择本身就有产品思维。Joshi自己是产品经理出身，他知道工具要过两关：CTO看技术可行性，PM看接入成本。装饰器方案把接入成本压到近乎为零，密码学背书又给了CTO采购的理由。

IETF草案：不做围墙花园

Blame-Finder的另一个关键决策是协议层开源。JEP和JAC都是向IETF提交的互联网草案，不是私有API。

这意味着什么？如果LangChain、CrewAI、AutoGPT都实现同样的草案，不同框架的智能体可以互认责任链。A框架的PM智能体委托任务给B框架的Coder智能体，JEP收据照样能串起来。Joshi管这叫"基础设施"而非"产品"——他不想再造一个Slack，他想造SMTP。

目前仓库里已有LangChain和CrewAI的原生适配器（native adapters）在开发中，可视化仪表盘（dashboard）已经可以运行，一键生成PDF/HTML责任报告的功能也在路线图里。

GitHub地址直接挂在README最上方：https://github.com/hjs-spec/Agent-Blackbox。 starred数增长曲线我没拿到，但Issues区已经有用户在问：能不能支持异步智能体的时序混乱场景？

命名政治学：PM会恨，CTO会爱

Joshi在文末加了个P.S.：「名字是故意挑衅的。你的PM会恨它，你的CTO会爱它。」

这个细节很有意思。"Blame"在英语里既有"追责"的技术含义，也有"甩锅"的办公室政治色彩。Joshi显然清楚，这个工具触动的不仅是技术痛点，还有组织神经。多智能体系统的责任真空，本质上是人类管理模式的镜像——当团队扩大、层级变多，"谁的决定"就会变得模糊。AI只是把这个问题加速放大了。

密码学签名在这里有个微妙作用：它把"责任"从人际关系里抽出来，变成可验证的数学事实。你不需要相信某个智能体"应该"没做错，你只需要验证它的JEP收据。这对CTO是降本增效，对PM可能是去政治化的压力。

但Joshi没说的是：如果智能体的决策本身就有系统性偏差，Blame-Finder只能告诉你"谁执行的"，不能告诉你"谁设计的奖励函数让智能体倾向于这个决策"。追责到最后一层，可能还是人类。

工具已经开源。下一个在凌晨3点收到Slack消息的运维工程师，会试用它吗？