mimo code 的核心是将逻辑推理与任务执行严格分离：推理 agent 仅生成可验证的结构化计划，执行 agent 仅按契约精准执行。二者通过明确定义的 plan schema 和 result schema 协作，实现安全隔离、性能解耦与调试友好。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
多 Agent 编程中，MiMo Code 的核心设计思想是把“逻辑推理”和“任务执行”拆开——前者由擅长思考的 Agent（如 LLM）负责，后者交给专注操作的 Agent（如代码执行器、API 调用器）完成。这种分离不是为了炫技，而是为了解决大模型在真实工程场景中的三个硬伤：幻觉输出不可控、工具调用不精准、错误恢复能力弱。
推理 Agent 只管“想清楚”，不碰“做动作”
推理 Agent 的唯一职责是理解目标、拆解步骤、生成可验证的中间计划，并明确每一步该调用哪个执行 Agent、传什么参数。它不生成最终代码，也不直接调用 API。比如用户说“查北京今天天气并转成英文发邮件给张三”，推理 Agent 输出的是结构化 plan：
- Step 1：调用 WeatherAgent，输入 location="北京"
- Step 2：调用 TranslationAgent，输入 text="{weather_result}"，target_lang="en"
- Step 3：调用 EmailAgent，输入 recipient="zhangsan@example.com"，body="{translated_text}"
这个 plan 是可读、可审计、可打断重试的，避免了端到端生成导致的链式错误扩散。
执行 Agent 只管“做准确”，不参与“怎么想”
每个执行 Agent 都封装了确定性能力：WeatherAgent 内部固定调用高可信度气象 API 并做字段校验；TranslationAgent 基于轻量微调模型或规则引擎，拒绝模糊翻译；EmailAgent 使用企业邮箱 SDK，自带发送日志与失败重试机制。它们接收结构化指令，返回结构化结果（含 status、data、error），不接受自然语言输入，也不输出自由文本。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
MiMo Code 的通信契约是关键约束
推理和执行之间不靠 prompt 对齐，而靠明确定义的 schema 协作：
- Plan Schema：必须含 step_id、agent_name、input_dict、expected_output_keys
- Result Schema：每个执行 Agent 返回 {step_id, status: "success"/"fail", data: {...}, error: null/str}
- 错误处理规则：status=fail 时，推理 Agent 自动触发 fallback plan（如换 API、降级查询、请求人工确认），而非重试原步骤
这套契约让系统可测试、可观测、可替换——换掉某个执行 Agent 不影响推理逻辑，升级 LLM 也不需重写工具代码。
分离带来可落地的工程收益
实际部署中，这种分离直接转化为运维优势：
- 安全隔离：执行 Agent 运行在受限沙箱，无网络/文件权限，推理 Agent 完全无权访问敏感资源
- 性能解耦：推理用大模型（如 Qwen2.5-72B），执行用轻量服务（如 FastAPI 封装的本地函数），资源按需分配
- 调试友好：日志天然分两段——推理日志记录“为什么这么想”，执行日志记录“实际做了什么”，问题定位时间缩短 60%+
不复杂但容易忽略：真正的分离不在代码分层，而在责任边界的刚性定义。
