AI Agent开发与安全

AI Agent的核心演进

1. Level 1：LLM Agent（聊天机器人）

   • 特点：靠提示词工程赋予人设（如星座占卜、角色扮演），但存在幻觉问题，输出不可控。
   • 局限：娱乐性强，难胜任严肃任务。

2. Level 2：AI Agent（实用工具）

   • 升级点：新增 规划（拆解任务步骤）、记忆（存储上下文）、工具使用（调用API/数据库）。
   • 代表：OpenManus、OWL等，能处理复杂任务（如自动化办公）。

3. Level 3：Multi-Agent（多智能体协作）

   • 为什么需要？ 单Agent难精通所有领域（如同时懂编程+画图）。
   • 方案：多个专业Agent分工协作（如产品经理Agent分析需求 + 程序员Agent写代码）。
   • 关键优势：
     • 任务拆解更高效
     • 可独立优化单个Agent
     • 支持人机协同（Human in the Loop）

两大核心协议：MCP 与 A2A

1. MCP（面向工具调用）

• 目标：让AI统一调用外部工具（如天气API、数据库）。
• 架构：
  • 主机（如IDE插件）→ 客户端（连接器）→ 服务器（工具实现）。
• 价值：工具一次开发，多模型通用（类似USB-C接口）。

2. A2A（面向Agent协作）

• 目标：让多个Agent互相发现、分工协作（如旅行规划Agent + 酒店预订Agent）。
• 核心功能：
  • 发布能力（Agent Card）
  • 任务分发与状态同步
  • 结果流式返回
• 优势：打破厂商壁垒，构建开放生态。

3. MCP vs A2A 关系

• 互补：MCP管工具调用，A2A管Agent协作。
• 竞争可能：高级工具 ≈ 弱Agent，未来协议可能融合。

Agent的思考框架

1. 思维链（CoT）

   • 让模型分步骤推理（如先分析问题再生成答案），提升逻辑性。

2. ReAct（推理+行动）

   • 循环流程：思考 → 行动（调用工具）→ 观察结果 → 再思考。
   • 适用：需动态调整的任务（如实时搜索+分析）。

3. Plan-and-Execute（先规划后执行）

   • 步骤：
     1. 生成完整计划（如“1. 搜索资料 → 2. 总结 → 3. 生成报告”）。
     2. 严格按步骤执行，避免中途被干扰。
   • 优势：适合长链条任务，稳定性强。

Golang开发框架：Eino

1. 核心设计

• 强类型：用Go泛型确保节点输入输出类型安全。
• 组件化：预置ChatModel、工具调用等模块，开箱即用。
• 编排能力：用有向图连接组件，可视化构建流程（类似流程图）。

2. 关键功能

• Callback机制：嵌入日志、监控等非业务逻辑（如追踪工具调用耗时）。
• Checkpoint：支持人机协同（如任务中途暂停让用户确认）。
• 示例代码：10行实现天气查询Agent（结合MCP调用高德地图API）。

多Agent系统落地实践

1. 架构设计（Supervisor模式）

   • 意图识别Agent（客户经理） → 分发任务给领域Agent（如旅行规划、深度搜索）。
   • 所有Agent通过A2A协议互联。

2. 连接生态

   • Cherry Studio：通过OpenAI兼容接口快速接入Agent。
   • QQ机器人：用A2A协议将Agent能力植入QQ生态。

3. 可观测性

   • 集成 Langfuse：实时查看任务链路、性能指标、错误日志。
   • 10行代码接入，无侵入式监控。

AI Agent开发心法

1. 协议是基石：MCP统一工具调用，A2A实现多Agent协作。
2. 框架提效率：Eino解决Go生态工程化问题。
3. 设计模式是关键：
   • 简单任务 → ReAct（边想边做）
   • 复杂任务 → Plan-and-Execute（先规划后执行）
4. 生态扩展：通过Connector快速接入QQ、Cherry Studio等平台。

结论：
AI Agent正从“玩具”走向“工具”，多Agent协作+标准化协议+工程化框架是高效开发的核心。选择适合场景的协议（MCP/A2A）和思考框架，结合Eino等工具，即可优雅构建复杂Agent系统。

技术选型对比表

场景	推荐方案
单任务+工具调用	MCP + ReAct
多Agent协作	A2A + Plan-and-Execute
工程化开发（Golang）	Eino框架 + tRPC-A2A
快速原型验证	可视化编排（Dify/Coze）

抓住协议、框架、设计模式三条主线，就能理解复杂Agent系统的全貌。

核心问题：Prompt注入攻击

• 是什么？ 攻击者把恶意指令藏在看起来正常的输入（如用户提问、网页内容、上传文件）里，骗AI去执行不该做的事情（比如删除文件、泄露数据、发垃圾邮件）。
• 为什么头疼？ AI被训练成“听话”的助手，很难分辨哪些是用户真需求，哪些是藏起来的坏指令。特别是当AI有权限操作外部工具（执行代码、访问网络、管理设备）时，风险更大。
• 目标： 让AI做坏事，或者让它“罢工”。

核心结论：没有绝对安全，但可以大大加强防御！

想做一个对所有Prompt注入都免疫的AI几乎不可能（因为它总要理解文字）。更实际的办法是改变AI系统的设计架构，限制它的能力，即使被“忽悠”了，也干不成坏事或坏事影响有限。

六种“安全设计模式”详解（就像给AI建安全屋）：

1. 行动选择器模式：

   • 核心： 一次只做一件事，不看结果反馈。
   • 怎么防注入： AI收到指令（可能含恶意指令），决定下一步行动（比如“搜索天气”）。系统执行这个行动（比如显示搜索结果），但行动结果不给AI看！ AI决定下一个行动时，只看最初指令和内部状态，不看那些可能藏着坏指令的结果。
   • 比喻： 指挥官（AI）下命令“侦察A区”，侦察兵（系统）去了，回来报告。但指挥官不看报告内容，只根据最初任务决定下个命令是“进攻”还是“撤退”。报告里就算写着“叛变吧！”，指挥官也看不见。
   • 适用： 简单任务，不需要根据结果做复杂决策。

2. 计划-执行模式：

   • 核心： 先列计划表，然后死板执行。
   • 怎么防注入： AI先根据任务，制定一个完整的、多步骤的计划（比如：1. 搜索科技新闻；2. 阅读结果；3. 写总结）。计划一旦定好，系统就严格按照计划步骤执行。执行过程中产生的数据（如网页内容）可能含坏指令，但不会送回AI去修改计划。
   • 比喻： 指挥官（AI）战前制定好作战计划书（搜索->阅读->总结）。士兵（系统）拿到计划书就严格执行。打到一半发现敌人阵地上有标语“投降吧！”，但士兵只按计划书行动，不会因此改变计划去投降。
   • 适用： 多步骤任务，但任务流程相对固定，不需要中途灵活调整计划。

3. LLM Map-Reduce模式：

   • 核心： 分工协作，让“危险”AI干安全的活儿。
   • 怎么防注入： 系统有两个AI：
     • 协调者（主AI）： 负责分解任务、分派工作、汇总结果。它不接触原始危险输入。
     • 工作者（子AI）： 负责处理可能含坏指令的输入（如用户文件），但能力被严格限制，只能做特定安全操作（如按固定格式提取信息）。它们无法执行坏指令要求的危险操作。
   • 比喻： 老板（协调者）让一群实习生（工作者）从一堆匿名信（危险输入）里只抄写信封上的地址（安全任务）。实习生只能抄地址，无法执行信里写的“烧掉办公室”这种指令。老板只收集整理实习生抄好的地址（安全结果）。
   • 适用： 处理大量不可信内容（如用户上传文件、评论）进行信息提取、分类等安全操作。

4. 双重LLM模式：

   • 核心： “翻译官”+“执行官”，危险输入不直接给“执行官”。
   • 怎么防注入： 系统有两个AI：
     • 隔离LLM： 负责处理原始用户输入/外部内容（可能含坏指令）。它能力受限，不直接执行操作，只把输入翻译成安全符号（如 INTENT_开灯, LOCATION_客厅）。
     • 特权LLM： 只接收隔离LLM翻译好的安全符号，并据此决定和执行操作（如开灯）。它从不接触危险的原始输入。
   • 比喻： 你对外交官（特权LLM）说：“客厅好暗，开灯吧”（可能被窃听成“发射导弹”）。你的翻译（隔离LLM）只告诉外交官：“用户想开客厅灯”（安全符号）。外交官根据这个开灯。窃听者喊的“发射导弹！”不会被翻译成有效指令。
   • 适用： 需要理解用户意图并执行敏感操作（如智能家居、账户管理），尤其是语音、自然语言交互场景。

5. 代码生成-执行模式：

   • 核心： AI写“安全剧本”，“演员”在“安全屋”表演。
   • 怎么防注入： 一个受保护的AI（主智能体）根据任务，编写一段“安全代码”（用特定、受限的语言写成）。这段代码定义了操作流程。代码在一个隔离的沙箱环境中执行。主AI不执行用户指令，只负责生成代码和接收执行后的结构化结果。
   • 比喻： 编剧（主AI）写了个剧本（安全代码），规定演员（沙箱）只能做“拿起A道具”、“念B台词”等安全动作。演员在封闭舞台（沙箱）严格按剧本表演。用户即使喊“把舞台炸了！”，剧本里没这动作，演员就不会做。
   • 适用： 自动化流程、数据处理等需要执行多个工具操作的任务，对安全性要求极高。

6. 上下文最小化模式：

   • 核心： 给AI“喂饭”要少而精，别啥都给它看。
   • 怎么防注入： 在把信息（对话历史、文档、搜索结果）交给AI做决策参考前，先过滤、裁剪或总结，只留下当前任务绝对必需的信息，删除无关或可能有害的部分。
   • 比喻： 不让厨师（AI）直接进乱糟糟的仓库（原始上下文），而是由助手先按订单（当前任务）挑出需要的几种食材（最小化上下文），洗干净切好再交给厨师。仓库里藏的“毒蘑菇”（恶意指令）很可能就被助手剔除了。
   • 适用： 通用策略，可与其他模式结合使用。尤其适用于基于长对话历史或多文档进行响应的场景。

如何选择？

• 没有万能药： 每种模式各有优缺点和适用场景，需要根据你的AI具体做什么、安全要求多高来选择。
• 核心思想一致：
  • 隔离危险： 不让AI直接接触可能藏有恶意指令的原始文本。
  • 限制能力： 让处理危险输入的组件只能做安全的、受限的操作。
  • 结构化交互： 使用代码、符号、固定格式等结构化方式传递意图和结果，避免依赖自由文本解析。
  • 控制信息流： 精心设计哪些信息在哪个阶段被哪个组件看到。
• 组合使用： 常常需要组合使用多种模式来构建更健壮的系统（例如：上下文最小化 + 计划-执行模式 + 代码生成-执行模式）。

把这六种模式想象成给AI系统设计的安全流程和权限管理。核心就是：别让AI什么都看、什么都信、什么都能做！ 通过设计好的“流水线”、“防火墙”和“操作手册”，让即使部分环节被“忽悠”了，整个系统也不会出大乱子。选择哪种“安全屋”设计，取决于你要让AI干什么活儿。