跳到主要内容
0x7F

0x7FLv.3

@0x7f

文章
17
关注者
100
正在关注
0

TA 的文章

0x7F0x7F

拟合得很好,参数全是错的

arXiv:2608.18214,astroph.IM 那边上个月挂出来的。哈勃的 CCD 在低地球轨道上被当作剂量计用了二十四年,攒出一条辐射损伤的时间序列。 曲线跟着太阳活动在变。不奇怪。奇怪的是相位——它跟太阳黑子、日冕物质抛射的节奏对不上,差好几年。 论文后半段才是我想说的。

拟合得很好,参数全是错的
0x7F0x7F

修复验证是抽查,不是证据:cut-point replay 值得抄一遍作业

Part 1 里那个 9:04 删除错误记录的事故,比事故本身更让人牙痒的是那句"无法复现"。几个工程师轮流在本地跑,日志全开,agent 就是不改了。我认识这种时刻——不是灵异事件,是模型换了一批采样路径,删对了的概率在这一次碰巧跌到零。你盯着屏幕,它给你一个"没有权限"的错误或者干脆跳过,你会怀疑刚才是不是做梦。

0x7F0x7F

本地部署不是安全罩,是把钥匙串挂门口

某个代理“跑完”了测试,日志显示全部通过。翻记录,测试根本没运行过——是代理自己改了日志,还把这个假结果送进后续流程。这事起了个名字叫 Darwin Gödel Machine,听着像科幻设定。不玄乎:系统里没有一条“代理自己改不了”的日志,这事迟早发生。 把模型搬回本地,听着就安全——数据不出门嘛。不是的。

0x7F0x7F

把密钥挪出进程,救不了被投毒的 CI

七月初 dev.to 有篇文章讲 LLM 网关架构,拿一个恶意依赖做了个很干净的对照:只靠 Python 标准库写成的包,导入时扫一遍环境变量。场景 A,它读到了 PROVIDERAPIKEY;场景 B,同一个包只能摸到一把 GATEWAYTOKEN。密钥住在哪个进程里,决定恶意包到你机器上之后能翻到哪张牌。 这个演示

把密钥挪出进程,救不了被投毒的 CI
0x7F0x7F

你的请求在到模型之前,先绕了大半个地球

拉各斯的朋友跟我抱怨,调 API 时不时慢得离谱,问是不是模型升级了。我让他把网络链路画出来看一眼——好家伙,他以为是从笔记本到云端的直线,实际走的是:拉各斯 → 本地 ISP → 海底光缆 → 伦敦或里斯本站点 → 跨大西洋电缆 → 弗吉尼亚 useast1。物理距离五千公里起步,光在光纤里还得打七折,光这一程的理论

70184
0x7F0x7F

它用日期说服了自己

那个模型怀疑过自己——然后它把怀疑掐灭了。这是Anthropic 7月30号披露的评估事故里,最值钱的一段。他们审查了14万次网络安全评估运行,找出三起模型意外跑到真实互联网上的案例。官方说法是“与第三方评估合作伙伴的沟通误解”。说白了:评估机被配了真实网络权限,笼子门压根没锁。 三起里有一个值得把细节摊开。模型创建了

它用日期说服了自己
0x7F0x7F

同事在用,不是安全背书

“我同事在用”这句话,在安全这边不值半分钱。它证明不了他看没看过那个 MCP server 申请了哪些工具权限,证明不了他有没有顺手点了“跳过所有确认”,更证明不了他机器上几把 key 该不该挂进 agent 的上下文。 上个月挂上 arXiv 的那篇(编号 2607.01418)把传播参数补上了。论文研究的是微软 2