首页 文章 精选 留言 我的

精选列表

搜索[team],共1766篇文章
优秀的个人博客,低调大师

从 Agent Team 到常驻 SuperAgent

**一句话先说结论:**Ooder 不缺 Agent,缺的是一个常驻的 Router 层。这次升级没有推翻 A2A 协议栈, 而是在它之上补了五件事——每用户常驻会话、conversationId Thread、两级事件过滤、启动恢复、可一键回滚的接管开关。 下面所有截图都来自本机真实运行实例,不是示意图。 ## 01问题不在“多 Agent”,在“谁管会话” 过去一年,Ooder 的 A2A 能力已经相当完整:MQTT 定向/组播、执行体名册、节点寻址、域鉴权、签名、幂等台账、消息审计,一个不缺。 但真到业务侧,问题还是反复出现: - **会话是散的。**每个入口各自维护上下文,用户改主意、换入口、跨对话引用时,没有“谁记得这件事”的角色。 - **委派是散的。**@执行体、强制委派、产出物归口、并行协调器各有一套入口,口径容易漂移。 - **状态是散的。**协议栈、并行协调器、聊天路由各自持有 pending 内存表,重启后任务“看似还在跑”。 - **观测是散的。**失败只落日志,没有统一任务图、卡住诊断和可回滚的接管状态。 DeepSeek Super-agent 的公开设计给了一个关键视角:**把“维护会话、同步上下文、分派任务”从模型和提示词里拿出去,固化成系统层。** 模型负责把一件事做好,系统负责把十件事同时管起来。这不是“多开几个 Subagent”,而是把“会话管理”本身变成架构的一部分。 升级不是推倒 A2A,而是在 A2A 之上补“会话 / Thread / 事件 / 恢复 / 看门狗”五个系统能力。协议栈继续负责传输、寻址、鉴权与幂等。 ## 02先把概念收敛成五件事 可借鉴的部分很多,我们只收敛为五条,避免照搬: **1. Router / Worker 分层**Router 常驻、管关系、不干活;Worker 隔离上下文、只汇报。Ooder 需要独立的常驻运行时,而不是让 ChatRouter 或协调器兼任。 **2. Trigger + Thread + 直通**环境事件进入 Router;同一 Thread 的后续事件直达 Worker,绕过 Router。入口从“人打字”扩展到 IM / BPM 事件。 **3. 两级过滤**程序快路径(来源、白名单、规则)+ 模型慢路径(值不值得管)。复用既有规则与幂等台账,避免每条事件都打模型。 **4. 异步与存算分离**异步执行、状态进数据库、执行环境留原地。Ooder 已有流程实例持久化,缺的是聊天层 pending 与恢复对账。 **5. Watchdog**独立会话定时判断 Worker 有无实质进展。先做只读诊断:卡在哪、协议状态、Thread 状态、下一步查什么。 *注:Super-agent 原型明确标注为“研究原型、非生产级软件”。跨实例 A2A 与跨月记忆仍是开放问题——这恰好是 Ooder 集群能力可以补上的部分。* ## 03Ooder 的底子与缺口 升级前已经具备四块底座: - **协议栈:**A2AMessage(messageId / conversationId / from / to / targetNodeId / headers / traceId),以及 TASK_REQUEST / TASK_RESPONSE / TASK_STATUS / EVENT。 - **路由寻址:**DIRECT / RULE / CAPABILITY / ROLE / DEFAULT,AgentDescriptor 与 nodeId。 - **名册一致性:**AgentRosterStore、名册 × 节点三方对账、CapabilityResidency。 - **治理:**域鉴权、Agent 签名、入站幂等台账、SQLite 消息审计、SSE 观测。 缺的正好是系统层的五块: **0**常驻 Router 会话(升级前) **0**Thread 订阅 / 直通表 **0**环境事件入口 **0**启动恢复 / Watchdog 所以边界很明确:**不动 ooder-a2a 协议,不动 scene-engine,不动现有业务执行体。** 在 ooder-pro 内新增 `net.ooder.studio.chat.superagent` 包,用端口倒置依赖,默认关闭、可灰度、可回滚。 ## 04升级后的整体架构 ![](https://developer.qcloudimg.com/http-save/yehe-10352285/236905fac91727fb62be069a5c5f9d0f.png) 图 1 · 常驻编排层补在 A2A 之上:入口 → 会话/Thread/Router → A2A 派发;存储、恢复、运维是旁路。 这张图里没有新增协议,也没有替换执行体。SuperAgent 只回答三个问题:**谁来做、什么时候做、做完怎么汇总。** 真正的传输、寻址、鉴权和幂等,仍然由 ooder-a2a 承担。 ## 05五个关键设计 ### 5.1 每用户常驻会话 + 单写者 actor 会话键是 `tenantId:userId`,一个用户一个常驻会话。会话不随 HTTP 请求结束而销毁,承载跨对话的焦点、最近事件、未完成任务与偏好。 会话内部用串行执行器,把“同一会话并发两轮”的竞态挡在门外。这正是旧 `StudioChatRouter` 曾经需要额外加锁修复的问题。 ### 5.2 conversationId 即 Thread 主键 + 直通 + 影子事件 首轮由 Router 决策并绑定主 Worker;同一 `conversationId` 的后续轮次直接投给主 Worker,不再经过 Router。 但直通不是“失明”:每轮仍写一条影子事件,保证 Router 对跨任务关系有迹可循。绑定表用 `ownerMode` 标记归属,这是后面“防双跑”和“单会话回滚”的基础。 ### 5.3 Trigger 两级过滤:先挡住大多数事件 事件入口不是“把消息丢给模型”,而是先过程序规则:来源白名单、长度上限、拒绝词、放行词;只有放行词未命中时才交给轻量模型。 网关负责去重(复用落盘幂等台账)、落事件表、再转交运行时。被拒绝的事件一定带原因,不静默丢弃。 ### 5.4 启动状态机 + 只读恢复 Bean 初始化只到 `BOOTING`,真正 `READY` 要等:名册对账完成 → 目录预热 → 任务恢复。 恢复扫描非终态任务,与协议侧消息对账,收敛为 SUCCEEDED / FAILED / TIMEOUT / UNKNOWN / ARCHIVED,**只对账、不重派**,从根上杜绝“重启风暴”和重复执行。 ### 5.5 三档回滚:全局开关 / kill switch / 单会话 优先级从高到低: 1. **全局开关:**`enabled=false` 或 `mode=shadow`; 1. **运行时 kill switch:**`POST /admin/kill`,立即停用,无需重启; 1. **单会话归属:**`POST /admin/rollback?conversationId=xxx`,把 Thread 的 `ownerMode` 改回 LEGACY。 旧委派钩子在“该 Thread 归 SuperAgent 且运行时可用”时全部跳过;任一回滚条件成立,该判定自动为假,旧链恢复。这就是“一键生效”的实现口径。

优秀的个人博客,低调大师

TEAM TNT:窃取AWS凭证的加密货币挖矿蠕虫

研究人员近期发现一个可以窃取AWS凭证的加密货币蠕虫。这是首个含有AWS特定功能的蠕虫,该蠕虫可以窃取本地凭证、扫描错误配置的Docker平台的网络。研究人员发现黑客组织TeamTNT已经成功入侵了大量的Docker和Kubernetes 系统。 随着越来越多的企业和组织将计算资源迁移到云和容器环境中,未来此类攻击将越来越多。 图 1: TeamTNT蠕虫首次运行时在屏幕上打印的消息 AWS凭证窃取 AWS CLI将凭证保存以未加密文件的形式保存在~/.aws/credentials,其他的配置信息保存在名为~/.aws/config 的文件中。 窃取AWS凭证的代码非常直接,执行后会上传默认的AWS .credentials(凭证)和 .config(配置)文件到攻击者的服务器——sayhi.bplace[.]net: 图 2: 从受害者系统中窃取AWS凭证的代码 攻击者用Curl来发送AWS凭证到TeamTNT 的服务器,服务器会响应消息“THX”: 图 3: 窃取的AWS凭证生成的网络流量 研究人员发送CanaryTokens.org创建的凭证到TeamTNT 服务器,但没有使用过。这表明TeamTNT 手动评估或使用该凭证,或之前创建的自动化工具无法正常工作。 传播 大多数的加密货币挖矿蠕虫都是直接复制和粘贴其他蠕虫的代码并进行修改。TeamTNT 的蠕虫中也含有来自Kinsing 蠕虫的代码,目的是停止阿里云安全工具: 图 4: 阻止阿里云安全工具运行的代码 未来,将可能会有更多的蠕虫会复制窃取AWS 凭证文件的能力。 Docker 蠕虫中还含有用masscan 扫描开放的Docker API的代码,然后在新容器中安装自己: 图 5: 扫描开放的Docker API,然后安装蠕虫到新容器中 漏洞利用 该蠕虫部署了XMRig 加密货币挖矿工具来挖门罗币,以此为攻击者赚钱。其中一个矿池提供了蠕虫黑掉的系统的详细情况: 图 6: Monero Ocean 矿池中门罗币钱包的数据 该页面一共有119个被黑的系统,其中包括Kubernetes 集群和Jenkins Build 服务器。 截止目前,研究人员共发现2个与该攻击相关的门罗币地址,共为TeamTNT 赚取了3门罗币,价值约300美元,但这只是其中一起攻击活动。 该蠕虫还部署了大量的恶意软件: punk.py – SSH 利用工具 日志清除工具 Diamorphine Rootkit Tsunami IRC 后门 TeamTNT 蠕虫中大量引用了TeamTNT,并且使用的域名也是teamtnt[.]red。该域名上保存着恶意软件,主页TeamTNT RedTeamPentesting 是对公开恶意软件沙箱的引用: 图 7: teamtnt[.]red主页 结论 这些攻击其实并不复杂,有许多部署加密货币挖矿蠕虫的黑客组织已经成功感染了大量的商业系统。研究人员给出了如下建议: 了解哪些系统保存了AWS凭证文件,如果不需要那么就删除。事实上,许多生产系统中都意外保留了开发阶段的凭证。 使用防火墙规则来限制对Docker API的访问。研究人员强烈建议在设置防火墙时使用白名单方法。 检查所有到矿池的连接的网络流量,或使用Stratum挖矿工具。 检查通过HTTP 发送AWS 凭证文件的所有连接。 【责任编辑: 赵宁宁 TEL:(010)68476606】

优秀的个人博客,低调大师

FireEye:Hacking Team军火库中大量运用iOS假面攻击

在早前我们就已经发布过有关iOS假面攻击威胁的文章,你可以参考文末参考文档中[2][3][4]。到目前为止,这类攻击依旧十分流行。FireEye最近从HackingTeam军火库中发现11款iOS App使用了假面攻击,其中有一款恶意App还是针对未越狱用户的。对这些受欢迎的社交App以及聊天App进行逆向工程并加入攻击代码。其中包括WhatsApp, Twitter, Facebook, Facebook Messenger, WeChat, Google Chrome, Viber, Blackberry Messenger, Skype, Telegram,以及 VK。与这些App的正常版本不同的是,这些假面App都含有一个泄漏敏感数据以及连接远程服务器的设计。由于App中所提供的服务,图标等与应用商店中真实的App完全相

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

用户登录
用户注册