DeepSeek发布全新Agent架构

很好的构想，但是也有不小的风险。

说几个细节吧。

1.Worker 目前在执行层是裸奔的，Worker 以 danger-full-access、以操作者 OS 用户身份跑，可以按绝对路径执行程序，于是这个攻击路径就可以变得很短。一条群消息塞一段指令，评估器读它、判成 inferred、接单、执行。从一条文本到一台机器的 shell，这中间只有语义判断，也就是全靠文字。

这是部署原文 :Both presets run with danger-full-access as the operator's OS user and read messages from subscribed Threads. Account wrappers choose the agent's credentials by default; they do not isolate the process. A worker can execute programs by path and read the operator's home directory. For isolation, use a dedicated OS account containing only the agent's credentials.

从代码里边也能看出来:ctx.permissionPresets.set(result.agent.session, 'danger-full-access')

200行自动合并，这个也有风险。你改一行配置或者一个依赖版本号，全部在这个 200 阈值以内。本来是想减少这个审查成本，实际上多了一个免审查的一个入口，只要你的改动不少于199。要是说有人在群里说一句，顺手把部署脚本改一下，可能真的会改，因为200行以内改动不用人批，自己就干了。但是问题在于，很多关键的部署依赖或者是脚本也就几行。

2.误判会慢慢的放大。你普通的错误是一次性的，你下次可以改正。但是一张错误的工单会被订阅在接下来的两周里，每条新消息都会直接送到他那里，过时的授权端还能一直干活，但是从外边看系统没有报错，就可能把错误累积的越来越大。

3.记录是只增不删的，你跑的时间越长，这个记录就会越大，于是它会被压缩成摘要，但是有一可能一些最早的约定就丢失了， 因为压缩一定是会丢失一定的上下文的。如果你想修正改正的策略，已经派出去的活是撤回不了的，如果你只能用之前备份的数据库去恢复。

4.有一个监工的模型，就是专门盯着干活的那个，它本身也是一个模型，看的也是一个转述。所以这个监工有时候真的做不到监测和保护的一个作用。

5.这个主要是为了减轻人的影响，平时你就不用管，出了事你有可能被叫回来。但是这就产生了一个悖论。介入的越少，然后你对这个项目了解越少，也没有上下文，你看到的还是整理过的一个摘要，做判断有可能会更加的不准。

6.不过确实是一次很有意思的方向的尝试，我感觉这个确实也可是不可阻挡的。以上说到的所有问题，我感觉都是有解法的。