人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载外部即时通讯IM消息驱动的 Agent 运行与桌面端用户在渲染器renderer中发起的交互式运行存在本质差异没有人在看屏幕、没有交互式审批界面、入站内容完全来自不受信任的远端。本文基于 Cherry Studio 仓库中的设计文档 channel-ingress-security.md 展开结合 ChannelMessageHandler.ts、OutputSanitizer.ts、settingsBuilder.ts 等源码实现系统梳理入站链路ingress flow、当前已具备的安全防线、四个待关闭的安全缺口G0–G3以及推荐的安全基线姿势。读完本文你将掌握渠道运行与桌面运行在信任边界上的差异、现有防御层的具体代码落点、每个缺口的攻击含义与修复方向以及如何在渠道场景下配置 Agent 使其达到保守安全基线。威胁模型一个不受信任的远端发言者驱动一个能触碰工作区的 Agent渠道入口安全要回答的核心问题是当一条来自不受信任远端方的消息经由绑定的渠道Slack / Discord / Telegram / 飞书 / 微信 / QQ进入系统驱动一个可以调用工具、读写会话工作区的 Agent 时如何保证运行安全这条运行链路没有人类在渲染器侧监督因此它不能依赖任何人工确认机制作为兜底。设计文档明确给出了这条链路的完整拓扑adapterwebhook/socket→ ChannelManager 注册 adapter.on(message, …) → ChannelMessageHandler.handleIncoming按会话 1s 防抖 串行队列 → processIncoming 解析绑定的 session agent → startAgentSessionRun({ sessionId, userParts, listeners })其中每一环在源码中都有确切的落点可以一一对应验证adapter 事件注册ChannelManager.ts中通过adapter.on(message, (msg) …)建立入站消息监听ChannelManager.ts收到消息后调用channelMessageHandler.handleIncoming(adapter, msg)。入站入口与串行化handleIncomingChannelMessageHandler.ts以${agentId}:${channelId}:${conversationId}:${userId}为键做每会话防抖批处理默认MESSAGE_BATCH_DELAY_MS 10001 秒单个发送者最多可延长到MESSAGE_BATCH_MAX_DELAY_MS 1600016 秒避免微信等 IM 用户连发短消息时每条都触发一次 Agent 往返随后通过enqueueBatch进入每会话串行队列chatQueues保证同一会话同一时刻只有一个流在运行杜绝并发交错ChannelMessageHandler.ts。会话与 Agent 解析processIncoming先解析该会话绑定的 Agent 与工作区若命中孤儿会话agentId null则拒绝运行随后把入站图片/文件持久化到工作区并将文本与附件路径拼接后交给collectStreamResponseChannelMessageHandler.ts。单次运行约束最终调用startAgentSessionRun({ sessionId, userParts, listeners, headless: true, requireIdle: { expectedAgentId } })并通过requireIdle保证同一${agentId}:${channelId}:${conversationId}同时只有一个运行ChannelMessageHandler.ts。设计文档中提到的handleIncoming:54、:111与ChannelManager.ts:301为文档写作时的近似行号对应现代码中防抖/队列逻辑与adapter.on(message)注册位置。已就位的防御层五道防线及其源码落点设计文档将已经存在的防御整理为一张表。结合源码每一层都能看到具体实现防御层代码位置实际作用输出密钥脱敏OutputSanitizer.tssanitizeChannelOutput在 ChannelMessageHandler.ts 附近被调用在 Agent 输出离开渠道之前将 PEM 私钥、AWS / GitHub / Anthropic / OpenAI 密钥、Bearer Token 等替换为[REDACTED]工作区隔离会话workspace.path附件持久化在${workspace}/.cherry-studio/channel-*Agent 的 fs 访问范围被限定在会话工作区内但其强度取决于 Agent 的工具策略一个绑定了宽泛 Bash/Write 且未做每渠道收窄的 Agent实际上不会被有效约束渠道白名单各平台 adapter 的allowed_chat_ids/allowed_channel_ids配置见下文来自未白名单会话/频道的入站消息被静默丢弃每会话串行化ChannelMessageHandler.ts 的chatQueues同一会话同一时刻只有一个流杜绝并发交错写静默write-quiesce入口闸门ChannelMessageHandler.ts 的isWriteQuiesced检查备份恢复期间暂停渠道摄入缓冲批次立即冲刷静默期到达的消息被丢弃并告警与 JobManager / AiStreamManager 的编排契约输出脱敏的具体匹配模式sanitizeChannelOutputOutputSanitizer.ts首先剥离[cite:...]内部引用标记保留代码块中的字面示例随后依次执行 9 组正则模式替换PEM 私钥-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY----- … -----END … PRIVATE KEY-----AWS 访问密钥 IDAKIA 16 位大写字母数字AWS 秘密访问密钥aws_secret_access_key 之后的 40 位 base64Bearer TokenBearer 20 字符以上通用 keyvalue 密钥api_key/password/token/client_secret等键名后 16 位以上值GitHub PATghp_前缀 36 位以上Anthropic 密钥sk-ant-前缀OpenAI 密钥sk-或sk-proj-前缀SSH 公钥内容AAAA开头的 100 位以上 base64要求混合大小写与数字避免误伤统一字符串每次命中都会记录logger.warn(Redacted sensitive content from channel output, { pattern: name })并返回{ text, redacted }供上层判断是否发生了脱敏。渠道白名单的跨平台实现允许列表按平台命名略有差异但语义一致列表为空 不限制列表非空 仅允许列表内的会话/频道飞书allowed_chat_idsFeishuAdapter.ts入站时if (this.allowedChatIds.length 0 !this.allowedChatIds.includes(message.chatId))静默丢弃Discordallowed_channel_idsDiscordAdapter.ts同时匹配原始频道 IDQQallowed_chat_ids支持群 ID 白名单QqAdapter.tsmention_onlyfalse时仍会尊重白名单过滤Slackallowed_channel_ids且会把白名单同步进notifyChatIds见 SlackAdapter.test.ts 的测试Telegram / 微信allowed_chat_ids微信 adapter 的测试明确覆盖了白名单外用户被过滤与白名单内用户被放行两种场景WeChatAdapter.test.ts。此外/whoami命令会直接向当前会话回复Current chat ID: …并提示把这个值加入allowed_chat_idsDiscord 为allowed_channel_ids即可接收通知——这是白名单配置的常用获取方式ChannelMessageHandler.ts。信任边界总结设计文档用一句话概括了当前边界入站文本原样传递入站文件/图片不做内容检查持久化到工作区Agent 经 Read 工具读取受工作区约束出站做密钥脱敏发送者身份未校验见缺口 1。待关闭的缺口D1 评审的实质工作设计文档指出当前实现与 v1 保持平级v1 也没有入站认证以下四个缺口是渠道入口安全后续工作的主体按 G0–G3 编号。G0 — 入站内容没有来源边界入站文本被刻意原样传递给 Agent不携带发送者前缀、边界标记、注入警告、归一化或检测日志。这是产品层面的显式决策——提示词包装prompt wrappers被移除Agent 收到的是用户消息的字面内容。安全含义任何渠道内容都应视为不受信任输入。配置渠道绑定 Agent 的工具与权限时必须以这条文本可能来自恶意攻击者、可能包含提示注入为前提。G1 — 授权是会话级而非发送者级各 adapter 的闸门作用于会话/频道白名单因此白名单群聊中的任意成员都能触发 Agent 运行。修复方向设计文档建议可选的每渠道发送者白名单用户 ID 列表在 adapter 中与会话检查并列执行默认关闭会话级检查仍是基线群聊场景可选开启拒绝时静默丢弃与会话闸门行为一致。注意现有的消息批处理键已包含message.userIdChannelMessageHandler.ts这为发送者级过滤提供了现成的数据基础。G2 — 无监督运行的工具有审批但没有应答方渠道运行不绑定任何渲染器因此审批的emit无绑定对象。在 settingsBuilder.ts 的canUseTool回调中可以看到完整的拒绝链会话无实时工具策略快照 →Tool policy not ready拒绝工具需要交互式应答如 AskUserQuestion且interactionState.userResponse unavailable→ 按无应答者拒绝hasLiveTurnStream false无实时交互流渠道运行即属此类且非后台 Agent →Approval requested outside a live interactive turn — denying拒绝审批 emitter 未绑定渠道运行下peekToolApprovalEmitter返回空→Approval emitter not ready拒绝。净效果需要审批的工具在渠道运行中直接失败除非 Agent 被设置为bypassPermissions——而这恰恰是不安全的绕过方式。这是外部运行设计的关键漏洞设计文档原文This is the key external-run design hole。设计文档给出了两条可选方案按产品意图二选一并记录决策策略驱动、无交互卡片推荐渠道运行下把每个工具解析为allow/deny的非交互式策略Agent 的permission_mode 每渠道工具允许/拒绝列表永不询问。未列入白名单的需审批工具以清晰、模型可见的理由拒绝如 not permitted on this channel让 Agent 可以继续或解释而不是挂起。带外审批Out-of-band通过渠道本身回复 approve/deny或配套渲染器通知把审批呈现给人类。更重仅在渠道上交互式审批确实是硬需求时才采用。G3 — 缺少每渠道权限覆盖v1 允许渠道覆盖 Agent 的permission_modev2 把配置迁移到 Agent 身上后丢弃了该能力。源码中的两处 TODO 佐证了这一状态ChannelMessageHandler.tsTODO(channel-perm-override): channel-level permission_mode used to mutate session.configuration in-place; with config now living on agent, this override needs to flow as a per-dispatch option instead. Tracked separately.ChannelMessageHandler.ts/new命令路径上的同类 TODO。后果渠道无法比其绑定的 Agent更严格例如为一个权限宽泛的 Agent 提供只读工具集。修复方向每渠道permission_mode 工具允许/拒绝覆盖作为每分派选项per-dispatch option线程化传入startAgentSessionRun→ Claude Code 的toolPolicySnapshot叠加在 Agent 策略之上渠道只能收窄narrow绝不能放宽widen。这也是 G2 策略驱动方案所读取的杠杆。推荐的保守基线在 G1–G3 落地之前设计文档明确渠道是opt-in、高信任的特性。在缺口关闭前应记录并遵循以下保守默认值只对可信工作区启用渠道——渠道不是默认开启的能力要求显式会话白名单——每个渠道必须配置allowed_chat_ids/allowed_channel_ids给渠道绑定的 Agent 配置只读工具集——避免宽泛 Bash/Write 工具在没有人工监督时被远程触发不要对渠道连接的 Agent 使用bypassPermissions——这是当前唯一让工具在渠道上跑起来的办法但也是最不安全的办法。修复优先级G2 是第一个要修复的缺口因为当前唯一让工具在渠道上工作的答案bypassPermissions恰是最不安全的。状态与边界说明设计文档声明该方案在本 PR 中未实现——与 v1 平级v1 也没有入站认证作为后续工作跟踪本文档即评审者D1要求的设计答复。因此本文中所有建议方向方案选项均属于设计意图而非已落地功能所有已就位防御均有源码与测试佐证。在 G1–G3 落地前渠道运行的安全强度完全取决于管理员是否遵循上述保守基线。相关代码与文档入口设计文档v2-refactor-temp/docs/ai/channel-ingress-security.md入站处理核心ChannelMessageHandler.ts渠道管理ChannelManager.ts输出脱敏OutputSanitizer.ts工具审批回调settingsBuilder.ts各平台白名单实现FeishuAdapter.ts、DiscordAdapter.ts、QqAdapter.ts、SlackAdapter.ts、TelegramAdapter.ts、WeChatAdapter.ts赞分享人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载相关推荐ruflo V3 Security Architect Agent从威胁建模到 CVE 修复的 Secure-by-Default 安全架构设计ruflo V3 Security Architect Agent从威胁建模到 CVE 修复的 Secure by Default 安全架构设计 本篇技术指南人工智能AI Agent多智能体Agent 编排Agent 记忆工具调用代码智能体MCP 服务AI 评测Agent Control SpecificationACS威胁与安全模型面向 Agent 系统的无状态确定性策略运行时防护指南Agent Control SpecificationACS威胁与安全模型面向 Agent 系统的无状态确定性策略运行时防护指南 导读 本文基于 poli人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配 Hyperresearch 是一个 Agent 驱动的研究知识库agent人工智能深度研究AI AgentMCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cherry Studio 渠道入口安全设计：无监督 Agent 外部触发运行（Channel Ingress Security）的威胁模型、现有防线与待修复缺口
人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载外部即时通讯IM消息驱动的 Agent 运行与桌面端用户在渲染器renderer中发起的交互式运行存在本质差异没有人在看屏幕、没有交互式审批界面、入站内容完全来自不受信任的远端。本文基于 Cherry Studio 仓库中的设计文档 channel-ingress-security.md 展开结合 ChannelMessageHandler.ts、OutputSanitizer.ts、settingsBuilder.ts 等源码实现系统梳理入站链路ingress flow、当前已具备的安全防线、四个待关闭的安全缺口G0–G3以及推荐的安全基线姿势。读完本文你将掌握渠道运行与桌面运行在信任边界上的差异、现有防御层的具体代码落点、每个缺口的攻击含义与修复方向以及如何在渠道场景下配置 Agent 使其达到保守安全基线。威胁模型一个不受信任的远端发言者驱动一个能触碰工作区的 Agent渠道入口安全要回答的核心问题是当一条来自不受信任远端方的消息经由绑定的渠道Slack / Discord / Telegram / 飞书 / 微信 / QQ进入系统驱动一个可以调用工具、读写会话工作区的 Agent 时如何保证运行安全这条运行链路没有人类在渲染器侧监督因此它不能依赖任何人工确认机制作为兜底。设计文档明确给出了这条链路的完整拓扑adapterwebhook/socket→ ChannelManager 注册 adapter.on(message, …) → ChannelMessageHandler.handleIncoming按会话 1s 防抖 串行队列 → processIncoming 解析绑定的 session agent → startAgentSessionRun({ sessionId, userParts, listeners })其中每一环在源码中都有确切的落点可以一一对应验证adapter 事件注册ChannelManager.ts中通过adapter.on(message, (msg) …)建立入站消息监听ChannelManager.ts收到消息后调用channelMessageHandler.handleIncoming(adapter, msg)。入站入口与串行化handleIncomingChannelMessageHandler.ts以${agentId}:${channelId}:${conversationId}:${userId}为键做每会话防抖批处理默认MESSAGE_BATCH_DELAY_MS 10001 秒单个发送者最多可延长到MESSAGE_BATCH_MAX_DELAY_MS 1600016 秒避免微信等 IM 用户连发短消息时每条都触发一次 Agent 往返随后通过enqueueBatch进入每会话串行队列chatQueues保证同一会话同一时刻只有一个流在运行杜绝并发交错ChannelMessageHandler.ts。会话与 Agent 解析processIncoming先解析该会话绑定的 Agent 与工作区若命中孤儿会话agentId null则拒绝运行随后把入站图片/文件持久化到工作区并将文本与附件路径拼接后交给collectStreamResponseChannelMessageHandler.ts。单次运行约束最终调用startAgentSessionRun({ sessionId, userParts, listeners, headless: true, requireIdle: { expectedAgentId } })并通过requireIdle保证同一${agentId}:${channelId}:${conversationId}同时只有一个运行ChannelMessageHandler.ts。设计文档中提到的handleIncoming:54、:111与ChannelManager.ts:301为文档写作时的近似行号对应现代码中防抖/队列逻辑与adapter.on(message)注册位置。已就位的防御层五道防线及其源码落点设计文档将已经存在的防御整理为一张表。结合源码每一层都能看到具体实现防御层代码位置实际作用输出密钥脱敏OutputSanitizer.tssanitizeChannelOutput在 ChannelMessageHandler.ts 附近被调用在 Agent 输出离开渠道之前将 PEM 私钥、AWS / GitHub / Anthropic / OpenAI 密钥、Bearer Token 等替换为[REDACTED]工作区隔离会话workspace.path附件持久化在${workspace}/.cherry-studio/channel-*Agent 的 fs 访问范围被限定在会话工作区内但其强度取决于 Agent 的工具策略一个绑定了宽泛 Bash/Write 且未做每渠道收窄的 Agent实际上不会被有效约束渠道白名单各平台 adapter 的allowed_chat_ids/allowed_channel_ids配置见下文来自未白名单会话/频道的入站消息被静默丢弃每会话串行化ChannelMessageHandler.ts 的chatQueues同一会话同一时刻只有一个流杜绝并发交错写静默write-quiesce入口闸门ChannelMessageHandler.ts 的isWriteQuiesced检查备份恢复期间暂停渠道摄入缓冲批次立即冲刷静默期到达的消息被丢弃并告警与 JobManager / AiStreamManager 的编排契约输出脱敏的具体匹配模式sanitizeChannelOutputOutputSanitizer.ts首先剥离[cite:...]内部引用标记保留代码块中的字面示例随后依次执行 9 组正则模式替换PEM 私钥-----BEGIN (RSA|EC|OPENSSH) PRIVATE KEY----- … -----END … PRIVATE KEY-----AWS 访问密钥 IDAKIA 16 位大写字母数字AWS 秘密访问密钥aws_secret_access_key 之后的 40 位 base64Bearer TokenBearer 20 字符以上通用 keyvalue 密钥api_key/password/token/client_secret等键名后 16 位以上值GitHub PATghp_前缀 36 位以上Anthropic 密钥sk-ant-前缀OpenAI 密钥sk-或sk-proj-前缀SSH 公钥内容AAAA开头的 100 位以上 base64要求混合大小写与数字避免误伤统一字符串每次命中都会记录logger.warn(Redacted sensitive content from channel output, { pattern: name })并返回{ text, redacted }供上层判断是否发生了脱敏。渠道白名单的跨平台实现允许列表按平台命名略有差异但语义一致列表为空 不限制列表非空 仅允许列表内的会话/频道飞书allowed_chat_idsFeishuAdapter.ts入站时if (this.allowedChatIds.length 0 !this.allowedChatIds.includes(message.chatId))静默丢弃Discordallowed_channel_idsDiscordAdapter.ts同时匹配原始频道 IDQQallowed_chat_ids支持群 ID 白名单QqAdapter.tsmention_onlyfalse时仍会尊重白名单过滤Slackallowed_channel_ids且会把白名单同步进notifyChatIds见 SlackAdapter.test.ts 的测试Telegram / 微信allowed_chat_ids微信 adapter 的测试明确覆盖了白名单外用户被过滤与白名单内用户被放行两种场景WeChatAdapter.test.ts。此外/whoami命令会直接向当前会话回复Current chat ID: …并提示把这个值加入allowed_chat_idsDiscord 为allowed_channel_ids即可接收通知——这是白名单配置的常用获取方式ChannelMessageHandler.ts。信任边界总结设计文档用一句话概括了当前边界入站文本原样传递入站文件/图片不做内容检查持久化到工作区Agent 经 Read 工具读取受工作区约束出站做密钥脱敏发送者身份未校验见缺口 1。待关闭的缺口D1 评审的实质工作设计文档指出当前实现与 v1 保持平级v1 也没有入站认证以下四个缺口是渠道入口安全后续工作的主体按 G0–G3 编号。G0 — 入站内容没有来源边界入站文本被刻意原样传递给 Agent不携带发送者前缀、边界标记、注入警告、归一化或检测日志。这是产品层面的显式决策——提示词包装prompt wrappers被移除Agent 收到的是用户消息的字面内容。安全含义任何渠道内容都应视为不受信任输入。配置渠道绑定 Agent 的工具与权限时必须以这条文本可能来自恶意攻击者、可能包含提示注入为前提。G1 — 授权是会话级而非发送者级各 adapter 的闸门作用于会话/频道白名单因此白名单群聊中的任意成员都能触发 Agent 运行。修复方向设计文档建议可选的每渠道发送者白名单用户 ID 列表在 adapter 中与会话检查并列执行默认关闭会话级检查仍是基线群聊场景可选开启拒绝时静默丢弃与会话闸门行为一致。注意现有的消息批处理键已包含message.userIdChannelMessageHandler.ts这为发送者级过滤提供了现成的数据基础。G2 — 无监督运行的工具有审批但没有应答方渠道运行不绑定任何渲染器因此审批的emit无绑定对象。在 settingsBuilder.ts 的canUseTool回调中可以看到完整的拒绝链会话无实时工具策略快照 →Tool policy not ready拒绝工具需要交互式应答如 AskUserQuestion且interactionState.userResponse unavailable→ 按无应答者拒绝hasLiveTurnStream false无实时交互流渠道运行即属此类且非后台 Agent →Approval requested outside a live interactive turn — denying拒绝审批 emitter 未绑定渠道运行下peekToolApprovalEmitter返回空→Approval emitter not ready拒绝。净效果需要审批的工具在渠道运行中直接失败除非 Agent 被设置为bypassPermissions——而这恰恰是不安全的绕过方式。这是外部运行设计的关键漏洞设计文档原文This is the key external-run design hole。设计文档给出了两条可选方案按产品意图二选一并记录决策策略驱动、无交互卡片推荐渠道运行下把每个工具解析为allow/deny的非交互式策略Agent 的permission_mode 每渠道工具允许/拒绝列表永不询问。未列入白名单的需审批工具以清晰、模型可见的理由拒绝如 not permitted on this channel让 Agent 可以继续或解释而不是挂起。带外审批Out-of-band通过渠道本身回复 approve/deny或配套渲染器通知把审批呈现给人类。更重仅在渠道上交互式审批确实是硬需求时才采用。G3 — 缺少每渠道权限覆盖v1 允许渠道覆盖 Agent 的permission_modev2 把配置迁移到 Agent 身上后丢弃了该能力。源码中的两处 TODO 佐证了这一状态ChannelMessageHandler.tsTODO(channel-perm-override): channel-level permission_mode used to mutate session.configuration in-place; with config now living on agent, this override needs to flow as a per-dispatch option instead. Tracked separately.ChannelMessageHandler.ts/new命令路径上的同类 TODO。后果渠道无法比其绑定的 Agent更严格例如为一个权限宽泛的 Agent 提供只读工具集。修复方向每渠道permission_mode 工具允许/拒绝覆盖作为每分派选项per-dispatch option线程化传入startAgentSessionRun→ Claude Code 的toolPolicySnapshot叠加在 Agent 策略之上渠道只能收窄narrow绝不能放宽widen。这也是 G2 策略驱动方案所读取的杠杆。推荐的保守基线在 G1–G3 落地之前设计文档明确渠道是opt-in、高信任的特性。在缺口关闭前应记录并遵循以下保守默认值只对可信工作区启用渠道——渠道不是默认开启的能力要求显式会话白名单——每个渠道必须配置allowed_chat_ids/allowed_channel_ids给渠道绑定的 Agent 配置只读工具集——避免宽泛 Bash/Write 工具在没有人工监督时被远程触发不要对渠道连接的 Agent 使用bypassPermissions——这是当前唯一让工具在渠道上跑起来的办法但也是最不安全的办法。修复优先级G2 是第一个要修复的缺口因为当前唯一让工具在渠道上工作的答案bypassPermissions恰是最不安全的。状态与边界说明设计文档声明该方案在本 PR 中未实现——与 v1 平级v1 也没有入站认证作为后续工作跟踪本文档即评审者D1要求的设计答复。因此本文中所有建议方向方案选项均属于设计意图而非已落地功能所有已就位防御均有源码与测试佐证。在 G1–G3 落地前渠道运行的安全强度完全取决于管理员是否遵循上述保守基线。相关代码与文档入口设计文档v2-refactor-temp/docs/ai/channel-ingress-security.md入站处理核心ChannelMessageHandler.ts渠道管理ChannelManager.ts输出脱敏OutputSanitizer.ts工具审批回调settingsBuilder.ts各平台白名单实现FeishuAdapter.ts、DiscordAdapter.ts、QqAdapter.ts、SlackAdapter.ts、TelegramAdapter.ts、WeChatAdapter.ts赞分享人工智能大模型AI 应用交互助手本地部署【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址https://gitcode.com/CherryHQ/cherry-studio点击查看免费下载相关推荐ruflo V3 Security Architect Agent从威胁建模到 CVE 修复的 Secure-by-Default 安全架构设计ruflo V3 Security Architect Agent从威胁建模到 CVE 修复的 Secure by Default 安全架构设计 本篇技术指南人工智能AI Agent多智能体Agent 编排Agent 记忆工具调用代码智能体MCP 服务AI 评测Agent Control SpecificationACS威胁与安全模型面向 Agent 系统的无状态确定性策略运行时防护指南Agent Control SpecificationACS威胁与安全模型面向 Agent 系统的无状态确定性策略运行时防护指南 导读 本文基于 poli人工智能AI AgentAI 安全治理策略引擎Agent 沙箱认证鉴权Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配Hyperresearch 16个子代理名册全解每个Agent的角色与模型分配 Hyperresearch 是一个 Agent 驱动的研究知识库agent人工智能深度研究AI AgentMCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考