Genspark 工程化实践方法研究综述(基于公开信息)

版本:v1.0 更新时间:2026-01-04 说明:非官方 / 仅基于公开资料归纳
目标:把“Genspark 风格”的可复用工程方法提炼为:模式库 + 参考架构 + 落地清单

0. 使用说明与结论预览

你会在本文得到什么?
  • 一份“Genspark 风格”的工程模式库(可直接迁移到你的 Agent 平台/AI 工作流产品)
  • 一套参考架构:把搜索、异步任务、多智能体、工具生态、记忆与证据链组合成可生产化系统
  • 一份落地清单:从 MVP 到规模化(含质量、安全、成本)
核心方向“从回答问题”→“完成工作”
关键抓手异步任务 + 证据链 + 多智能体画布
平台化MCP/Connectors + 700+ 工具生态(公开宣称)
隐私本地推理(169 个开源权重模型)+ 明确第三方 API 使用边界

注:本文以公开资料为准,包含官方博客、隐私政策与媒体报道;其中一些表述带有产品营销属性,已尽量以“可验证信息 + 工程化归纳”的方式呈现。

1. Genspark:从 AI 搜索到“完成工作的工作空间”

从公开资料看,Genspark 的演进路径可以理解为:以搜索为入口,把答案组织成可复用的结构化页面(Sparkpages),再进一步用“Autopilot/Agent”把信息检索扩展为可执行的任务(异步、并行、可交付),最后沉淀为一个以多智能体和工具生态为底座的 AI Workspace。

1.1 Sparkpages:结构化页面 + 内置 Copilot

官方博客描述 Sparkpages 的目标,是把“传统网页的碎片化信息”重新组织为更清晰、全面、去广告/去商业影响的知识单元,并在页面内内置 AI Copilot 以增强交互。[R2]

工程含义:输出不是一段 chat 文本,而是一份可复用的结构化产物(artifact),可被检索、fork、评论、迭代。[R2]

1.2 Parallel Search:把查询拆成多视角并行研究

Genspark 的产品开发博客提到 “AI Parallel Search”:将用户初始查询拆解为多个视角/子问题,并行进行在线研究,再汇总构建更准确的答案。[R3]

工程含义:把“检索”从单次抓取变成可调度的并行研究图(research graph),核心难点转向:并行、去重、证据汇聚与一致性合成。

1.3 Autopilot Agent:异步任务式研究与交叉核验

在 Autopilot Agent 的介绍中,Genspark 将其定位为“异步 AI 助手”:用户提交任务后,Agent 在后台完成多步规划、并行研究与交叉核验,并在完成后提供“带引用”的总结。[R4]

工程含义:把 agent 从“同步对话”升级为分布式异步作业系统:支持并发任务、进度追踪、失败恢复、通知(例如邮件)等。[R4]

1.4 Multi-Agent 平台:专用画布 + 线性上下文并行

多智能体编排文章提到:不同 agent 在各自的“专用画布/环境”(例如表格、幻灯片、文档)工作,同时为了避免“非线性上下文”造成协作噩梦,采用线性上下文:并行子 agent 共享同一上下文快照,汇总后由 lead agent 统一更新上下文。[R6]

工程含义:用“线性上下文”换取可控性,用“并行子任务”换取吞吐,形成并行执行 / 串行合并的可扩展架构。

1.5 项目级记忆:Hub / Drive / “AI 秘书”集成

Genspark Hub 被描述为每个项目一个空间,包含“不会忘记的 AI 记忆”:文件、对话、决策在项目空间内持续积累,AI 能自动召回并使用相关资料。[R7]

另有“AI 秘书”里程碑:Super Agent 可管理 Gmail、Google Calendar、Google Drive 与 Notion。[R8]

工程含义:记忆不是“聊天历史”,而是项目级知识库 + 文件仓库 + 权限化连接器,为持续任务提供上下文与素材。

1.6 AI Browser:Agentic 浏览 + MCP 工具生态 + 本地推理

官方介绍的 AI Browser 包含 Autopilot Mode,并宣称通过 MCP Store 可连接 700+ 工具。[R11] 另一个版本的发布文中强调 “On-Device Free AI”:可在本地运行 AI 模型(列举 169 个开源权重模型),支持离线、隐私与低延迟。[R12]

工程含义:浏览器成为 agent 的“执行环境”,本地推理/工具生态降低隐私与延迟成本;同时带来权限、注入攻击与行为审计的新挑战。

一句话概括(工程视角):
Genspark 把“搜索”工程化为 可调度的研究图,把“对话”工程化为 可交付的异步任务,把“工具调用”工程化为 多智能体协作平台 + 连接器生态,并用 证据链项目级记忆 把系统从“能用”推向“可依赖”。

2. 可复用的工程化方法:Genspark Pattern Catalog

下面把公开资料里能观察到的关键做法,抽象成“可复用 Pattern”。每个 Pattern 都按:问题 → 机制 → 工程要点 → 风险与对策 来描述,便于直接迁移到你自己的系统。

2.1 Pattern A:任务化(Taskification)

要解决的问题 用户想要的往往不是“答案”,而是完成一个任务:做调研、做报告、做对比、写文档、生成表格、发邮件、打电话……

Genspark 可观察机制 Autopilot Agent 把 prompt “重构成 Task”,并在后台完成多步规划、研究、交叉核验与总结。[R4]

工程要点(可复用)

  • Task Schema:把用户输入规范化为任务对象(目标、约束、交付物类型、截止时间、数据源偏好、合规策略)
  • Deliverable-first:任务必须产生可存档的产物(页面/文档/表格/幻灯片/报告包),而不是仅聊天记录
  • Progress & Partial:支持阶段性产出(draft → refined → final),中途可回滚/重试/补资料

风险与对策

风险对策
目标不清导致任务跑偏在任务化阶段引入“目标对齐提示(Goal Confirmation)”,同时提供“可编辑的任务卡片(Task Card)”
任务过大,成本失控分段预算(token/调用次数/时间),超预算自动降级为“概览模式”或请求用户确认
任务执行结果不可追溯任务日志、证据链、可复现的研究轨迹(sources + snapshots)

2.2 Pattern B:并行研究 + 线性上下文(Linear Context)

要解决的问题 深度研究需要并行,但并行会导致上下文分叉、冲突合并、状态不一致。

Genspark 可观察机制 Multi-Agent 平台强调:并行子 agent 可执行,但保持线性上下文;并行时每个子 agent 拿到同一上下文快照,汇总后由 lead agent 统一更新。[R6]

工程要点(可复用)

  • Context Snapshot:并行子任务读取同一只读快照(版本号/哈希),避免并发写
  • Merge Protocol:子任务输出必须遵循结构化合并协议(结论、证据、置信度、冲突点)
  • Lead Agent Arbitration:由 lead agent 负责冲突解决(例如证据优先、来源可信度、时间新鲜度)

建议实现:并行执行 / 串行合并

User Query
  ↓ Taskify
Lead Agent creates N sub-queries
  ↓ parallel
SubAgent[i] read Context@vK → research → output (facts + evidence)
  ↓ gather
Lead Agent merges outputs → updates Context@vK+1 → generates deliverable
不要轻易做“真正的多写并发上下文”。 公开资料中,“线性上下文”的选择来自“协调噩梦”的经验教训。[R6] 对工程团队而言,这通常是最划算的折中:性能来自并行,正确性来自串行合并。

2.3 Pattern C:异步执行框架(Asynchronous Agent)

要解决的问题 复杂任务需要“给 agent 时间”:读更多内容、交叉验证、反思;同步等待会带来糟糕的交互与不稳定质量。

Genspark 可观察机制 Autopilot Agent 被描述为“世界首个异步 AI agent”,任务可在后台继续执行,用户可离开页面,完成后收到通知(例如邮件)。[R4]

工程要点(可复用)

  • Job Queue + Checkpoint:每一步(plan/search/summarize/verify)写入 checkpoint,可重试
  • Idempotency:工具调用必须幂等(尤其是写操作),可用 request-id 做去重
  • Progress API:前端展示阶段(规划中/检索中/核验中/生成产物/完成)
  • Multi-task Concurrency:同用户/同组织并发控制(配额与优先级)

你可以直接抄的“异步任务状态机”

PENDING → PLANNING → RESEARCHING → VERIFYING → SYNTHESIZING → DELIVERED
           ↘︎ FAILED ↗︎          ↘︎ NEEDS_INPUT ↗︎

2.4 Pattern D:证据化输出(Citations + Screenshots)

要解决的问题 仅靠模型“说得像”不够,用户需要可检查的证据来建立信任。

Genspark 可观察机制 Autopilot Agent 强调:研究与核验来自多个权威来源,并提供透明引用;同时还会包含“智能内联截图”作为支撑证据。[R4]

工程要点(可复用)

  • Evidence Object:把证据作为一等公民(URL、抓取时间、片段、截图、来源评级、hash)
  • Claim-to-Evidence Mapping:每条关键结论至少绑定 1~N 个证据;没有证据就降级为“推测”
  • UI 证据体验:引用不是脚注,而是可点击的“证据卡片”(片段高亮 + 时间戳)
反模式:只给链接列表。 用户仍要自己读、自己核验,体验退化回传统搜索。 证据化输出的价值在于:让核验成本接近 0

2.5 Pattern E:多智能体编排(Specialized Canvases)

要解决的问题 “通用 agent”很难把表格、幻灯片、文档等产物做得专业;而把所有逻辑塞进一个 prompt 会失控。

Genspark 可观察机制 多智能体文章描述:不同 agent 在专用画布工作(Sheets/Slides/Docs),由平台管理跨画布上下文协作。[R6]

工程要点(可复用)

  • Canvas Abstraction:每类产物定义统一 API(read/write/diff/validate/render)
  • Agent Specialization:为不同画布选择不同模型与提示(表格侧重计算与一致性,幻灯片侧重结构与表达)
  • Cross-canvas Contracts:例如“表格的指标”如何映射到“幻灯片的图表”,要有固定协议

建议实现:多智能体输出协议(示例)

SubAgent Output (JSON)
{
  "summary": "...",
  "artifacts": [
    {"type":"sheet", "id":"sheet_123", "ops":[...]},
    {"type":"slides", "id":"deck_9", "ops":[...]}
  ],
  "evidence": [{"url": "...", "snippet": "...", "captured_at": "..."}],
  "open_questions": [...]
}

2.6 Pattern F:动态生成(Ephemeral Agents / Toolgen)

要解决的问题 预置 agent/工具永远覆盖不了真实业务的长尾需求;但“每次都手写提示”又难维护与复用。

Genspark 可观察机制 多智能体文章预告:lead agent 可通过编写 YAML 配置“按需实例化”临时 agent,包含专属工具集、系统提示、甚至专用模型。[R6]

工程要点(可复用)

  • Agent Spec as Code:用可审计的配置(YAML/JSON)描述 agent:模型、提示、工具、策略、输出格式
  • Policy Gate:动态 agent 必须过策略门:工具白名单/数据域权限/成本预算
  • Spec Library:沉淀常用 spec 模板(财务备忘录、竞品分析、周报生成)

示例:轻量 Agent Spec(非官方,仅示意)

name: InvestmentMemoAssistant
model: claude-4-sonnet
tools: [web_search, financial_report, crawler]
output:
  format: memo
  sections: [summary, thesis, market, risks, valuation]
guardrails:
  tool_write: false
  budget_tokens: 120000

2.7 Pattern G:项目记忆与资料仓库(Hub/Drive)

要解决的问题 长周期项目需要持续上下文;“重复讲背景”是知识工作最昂贵的摩擦之一。

Genspark 可观察机制 Hub:每个项目独立空间 + 持久 AI 记忆;AI 可自动召回并使用相关文档。[R7] Drive/Download Agent:可自动下载整理文件并重命名以便检索。[R9]

工程要点(可复用)

  • Memory Layers:短期对话记忆(session)+ 项目记忆(project)+ 组织知识(org)分层
  • Retrieval Policy:召回需遵守权限与最小化原则(只取相关且允许访问的内容)
  • Artifact Index:文件、表格、幻灯片都应有可检索索引与向量表示(含版本)

2.8 Pattern H:工具生态与权限(MCP/Connectors)

要解决的问题 Agent 能力的上限取决于“工具/数据”的可用性;但越多工具意味着越大安全面。

Genspark 可观察机制 AI Browser 发布文提到 MCP Store 与“连接 700+ 工具”。[R11] “AI 秘书”强调对 Gmail/Calendar/Drive/Notion 的管理能力。[R8]

工程要点(可复用)

建议做法
连接器层每个工具单独 OAuth / API Key;权限最小化;分环境(dev/stage/prod)
执行层工具调用 sandbox 化;写操作要求二次确认;引入 allowlist + policy engine
审计层完整记录:谁在何时用什么工具做了什么(含参数摘要);支持回放与撤销
提示注入防护对外部内容做“指令隔离”(content vs instruction);对工具参数做严格 schema 校验

2.9 Pattern I:模型路由与自我改进(MoE + Judges)

要解决的问题 单一模型很难在成本/质量/稳定性上同时最优;同时 agent 系统需要持续迭代。

Genspark 可观察机制 VentureBeat 报道称:Genspark 使用 9 个 LLM 组成 MoE,并配备 80+ 工具;运行经典 agent loop(plan/execute/observe/backtrack),并用 LLM judges 评估会话、把奖励归因到步骤,用于 RL 与 prompt playbook 持续改进。[R14]

工程要点(可复用)

  • Model Router:按任务类型路由(检索/推理/写作/代码/表格),并在失败时做降级/切换
  • Backtracking:允许“走错路后回退重来”,比刚性 workflow 更抗边界条件[R14]
  • Judge & Feedback:建立离线评测集 + 在线判别(用户反馈/LLM judge)+ 回归测试
  • Playbook:把高质量轨迹沉淀为可复用策略(提示模板、工具链、失败恢复路径)
工程提醒: LLM judge 并不是“真理”,它只是一个自动化质量信号。实践中应把 judge 结果与人工抽检、业务指标(完成率/返工率/投诉)结合,避免优化偏移。

2.10 Pattern J:隐私与合规(Data policy / On-device)

要解决的问题 一旦接入邮件/日历/文档等高敏数据,用户最关心的是:数据去哪了、怎么用、会不会被训练、能否本地化。

Genspark 可观察机制 隐私政策提到:查询可能会被发送到 OpenAI 或 Anthropic API;使用 Google Workspace API 来提供特定服务,并明确声明这些 API 数据不用于开发/改进/训练通用 AI/ML 模型。[R13]

另一个机制 AI Browser 的 “On-Device Free AI” 主张本地运行开源权重模型、离线可用且数据不离开设备。[R12]

工程要点(可复用)

  • Data Map:清晰标注每种数据流向(本地/服务端/第三方),并提供可配置开关
  • Least-data Principle:只传递完成任务所需最小字段;敏感字段做脱敏/摘要
  • On-device Options:对高敏场景提供本地推理或私有部署选项(即使能力受限)
  • Retention & Deletion:可见的保留策略与删除机制;对共享/公开内容提供显式提示

补充:规模与生态信号(来自公开报道/公告)

  • Reuters 报道:Genspark 在 2025-02-21 的融资消息中提到其“月活用户 200 万+”,并引用其博客称:具备“多模型协作进行深度在线研究”的特性。[R15]
  • 官方公告:2025-11 的一篇文章宣称 $275M Series B、$1.25B 估值。[R16]
  • 官方公告:与 Microsoft 的合作将其 agent engine 集成到 Microsoft 365,并称其为 Agent 365 launch partners。[R17]

3. 参考架构:如何工程化落地“Genspark 风格平台”

下面给出一个“可落地”的参考架构。它不是对 Genspark 的逆向工程,而是把上面的 Pattern 组合成可实现的系统分层,适合企业/创业团队搭建自己的 Agentic Workspace。

3.1 组件划分

┌──────────────────────────────────────────────┐
│                 Frontend / UI                │
│  Search | Task Cards | Artifacts | Evidence  │
└──────────────────────────────────────────────┘
                 │
                 ▼
┌──────────────────────────────────────────────┐
│            Agent Orchestrator (Lead)          │
│ Taskify | Planner | Router | Merge | Guardrail│
└──────────────────────────────────────────────┘
   │            │                 │
   │ parallel   │ tool calls       │ artifacts
   ▼            ▼                 ▼
┌─────────┐  ┌────────────────┐  ┌──────────────────┐
│SubAgents │  │ Tool Executor   │  │ Artifact Service  │
│(Sheets/  │  │ (Sandbox)       │  │ (Docs/Slides/...) │
│Slides/..)│  └────────────────┘  └──────────────────┘
   │            │                 │
   │            ▼                 ▼
   │      ┌───────────────┐  ┌───────────────┐
   │      │ Connectors/MCP │  │ Memory Store   │
   │      │ Gmail/Drive/...│  │ Hub/Vector/DB  │
   │      └───────────────┘  └───────────────┘
   │
   ▼
┌──────────────────────────────────────────────┐
│           Async Job System (Queue)            │
│  Checkpoints | Retries | Budget | Notifications│
└──────────────────────────────────────────────┘
组件职责对应 Pattern
Agent Orchestrator任务化、规划、并行调度、合并、路由、策略门A/B/E/I/J
Tool Executor统一执行外部工具;sandbox;参数校验;审计H/J
Artifact Service管理产物(Docs/Sheets/Slides/Pages);版本与 diffA/E/G
Evidence Service抓取、截图、片段抽取、来源评级、claim 绑定D
Memory Store项目级记忆(Hub);向量检索;权限过滤;TTLG/J
Async Job System异步执行;checkpoint;重试;通知;并发控制C

3.2 关键数据结构(任务/记忆/证据)

Task(任务对象)

{
  "task_id": "tsk_...",
  "user_id": "...",
  "goal": "生成竞品分析报告",
  "deliverable": {"type":"doc", "template":"competitive_analysis_v2"},
  "constraints": {"deadline":"...", "region":"CN", "sources":["official","papers"]},
  "budget": {"tokens": 80000, "tool_calls": 120},
  "policy": {"allow_write_tools": false, "pii": "redact"},
  "status": "RESEARCHING",
  "context_version": "ctx_v12"
}

Evidence(证据对象)

{
  "evidence_id": "evd_...",
  "url": "https://...",
  "captured_at": "2026-01-04T...",
  "snippet": "…",
  "screenshot_ref": "s3://.../shot.png",
  "source_rank": 0.86,
  "hash": "sha256:..."
}

Project Memory(项目记忆)

{
  "project_id": "hub_...",
  "facts": [{"claim":"...", "evidence":["evd_1","evd_9"]}],
  "decisions": [{"date":"...", "decision":"..."}],
  "artifacts": ["doc_1","sheet_2"],
  "embeddings": "vector_index_ref",
  "acl": {"owner":"...", "members":["..."]}
}

Run Trace(执行轨迹)

{
  "run_id": "run_...",
  "task_id": "tsk_...",
  "steps": [
    {"t":"plan", "model":"...", "cost":0.12},
    {"t":"tool:web_search", "q":"...", "lat_ms":840},
    {"t":"merge", "conflicts":2},
    {"t":"deliver", "artifact":"doc_1"}
  ]
}
为什么把 Evidence / Trace 做成一等公民?
因为在复杂 agent 系统中,“质量问题”往往不是单点 bug,而是链路问题:检索偏、合并错、提示注入、工具输出异常、模型幻觉……没有证据链和可回放轨迹,就无法工程化定位与迭代。

3.3 生产化清单

  • 任务化层:Task schema、交付物类型、预算/并发策略、任务卡片可编辑
  • 异步作业层:队列、checkpoint、重试、超时、幂等、取消/回滚、通知
  • 证据层:抓取/截图、来源评级、claim↔evidence 绑定、可点击证据卡片
  • 工具层:统一 sandbox、schema 校验、写操作确认、权限最小化、审计日志
  • 记忆层:项目空间(Hub)、分层记忆、向量索引、权限过滤、数据保留与删除
  • 评测层:离线 evals、在线指标、回归测试、LLM judge(可选)
  • 可观测性:token/cost/latency、工具失败率、任务完成率、人工抽检
  • 安全:提示注入隔离、敏感数据脱敏、策略引擎、风控(电话/邮件等高风险动作)

4. 从“可用”到“可信”:质量、安全、成本三角

Genspark 公开信息里反复强调“交叉核验、透明来源、证据截图、异步给时间”。[R4] 这些并不是单纯的产品叙事,而是“可信 agent”必须面对的工程三角:质量(正确性/可解释)× 安全(权限/注入/越权)× 成本(并行/模型/缓存)。

4.1 评测与回归(Evals)

建议的评测层次

层次例子指标
Step-level检索是否覆盖关键来源;摘要是否有证据coverage、citation_rate、contradiction_rate
Task-level竞品报告是否包含必备章节、数据是否一致completion_rate、edit_distance、human_score
System-level高峰期并发、工具故障、模型降级p95_latency、failure_recovery_time、cost_per_task
关于 LLM judge: VentureBeat 报道提到用 LLM judges 评估会话并做强化学习回馈。[R14] 在企业落地时,建议先把 judge 用在“自动化回归测试”与“辅助标注”,不要直接用它做唯一的线上准入门槛。

4.2 工具安全与权限

从公开内容看,Genspark 的工具范围包含:文件下载整理、Gmail/日历/Drive/Notion 管理、甚至电话呼叫等高权限动作。[R8][R10] 这类能力的工程落地关键是:权限最小化 + 可审计 + 可撤销

风险面典型事故工程对策
写工具误操作误发邮件、误删文件、错误预约写操作默认二次确认;dry-run;撤销窗口;审批流
提示注入网页内容诱导 agent 泄露密钥或越权调用工具指令隔离;工具参数 schema 校验;敏感动作需显式用户意图
数据越权跨项目召回不该访问的资料ACL + Policy engine;检索前先过滤权限;日志抽检

4.3 成本/延迟优化

可以直接复用的优化策略

  • 并行但线性合并:吞吐来自并行,正确性来自合并(Pattern B)
  • 分级输出:先给概览(低成本),再按需深化(高成本)
  • 模型路由:不同步骤用不同模型;失败再升级(Pattern I)
  • 缓存:对高重复 query / 公开 research 结果做缓存;注意时间敏感与个性化
  • 本地推理:对隐私/低延迟需求提供 on-device(公开宣称的 169 模型)[R12]
实践建议: 把“预算”作为产品能力暴露给用户(例如:极速/标准/深度),让用户参与权衡质量与成本,而不是把成本压力全部藏在后端。

5. 实施路线图(0→1→N)

  1. MVP(2~4 周):搜索 + 引用(RAG) + 基础证据卡片
  2. v0.2:Parallel Search(子问题拆解 + 并行)[R3]
  3. v0.3:异步任务框架(队列 + checkpoint + 通知)[R4]
  4. v0.4:多画布产物(Docs/Sheets/Slides),引入 lead agent 合并协议[R6]
  5. v0.5:项目空间与记忆(Hub/Drive)[R7][R9]
  6. v1.0:工具生态(MCP/Connectors)、权限/审计、评测闭环、模型路由与回退[R11]
最常见的失败方式: 一上来就做“万能 agent”。
更高成功率的路径是:先把“一个高频任务”做成可交付、可核验、可复用的 artifact,然后扩展到任务簇,再平台化。

6. 术语表

术语解释
Artifact结构化交付物:页面/文档/表格/幻灯片/报告包;可版本化与复用。
Evidence证据对象:来源链接、片段、截图、抓取时间、可信度等;用于支撑 Claim。
Taskification把用户输入转为任务对象(目标、约束、产物类型、预算、策略)。
Linear Context并行执行时保持上下文线性演进;子 agent 共享快照,lead agent 合并更新。
Autopilot Agent异步执行的 agent;后台完成多步研究/核验并产出结果。[R4]
MCP Store工具/连接器生态的一种呈现方式;文中宣称可连接 700+ 工具。[R11]
LLM Judge用模型对输出质量做自动评估的机制;可用于回归测试、奖励建模等。[R14]

7. 参考资料

  1. [R1] MainFunc.ai Blog — Welcome to Genspark, the AI Agentic Engine(Genspark Intro)
    https://mainfunc.ai/blog/genspark_intro
  2. [R2] Genspark Blog — Genspark vs. Google and Perplexity: Pioneering a New Era of AI Search(Sparkpages/AI Copilot/Fork)
    https://blog.genspark.ai/blog/genspark_vs_google_vs_perplexity
  3. [R3] MainFunc.ai Blog — Introducing AI Parallel Search(并行研究)
    https://mainfunc.ai/blog/genspark_new_features_20240728
  4. [R4] MainFunc.ai Blog — Introducing Genspark Autopilot Agent: World's First Asynchronous AI Agent(异步任务、交叉核验、截图证据、社区分享)
    https://mainfunc.ai/blog/genspark_autopilot_agent
  5. [R5] MainFunc.ai Blog — World's First Search and Autopilot Agent Integration(搜索结果可用 Autopilot 交叉核验)
    https://mainfunc.ai/blog/genspark_new_features_20240925
  6. [R6] MainFunc.ai Blog — Multi-Agent Orchestration: On-Demand Ephemeral Agent Creation(线性上下文、YAML 动态 agent)
    https://mainfunc.ai/blog/genspark_multiagent_orchestration
  7. [R7] MainFunc.ai Blog — Genspark Hub: Dedicated Space and Memory for Every Project(项目空间与记忆)
    https://mainfunc.ai/blog/genspark_hub
  8. [R8] MainFunc.ai Blog — Genspark Super Agent, Your AI Secretary(Gmail/Calendar/Drive/Notion 集成)
    https://mainfunc.ai/blog/genspark_ai_secretary
  9. [R9] MainFunc.ai Blog — Full Agentic Download Agent and Genspark AI Drive(下载整理与文件仓库)
    https://mainfunc.ai/blog/genspark_download_agent_and_ai_drive
  10. [R10] MainFunc.ai Blog — Beyond Business, AI Now Calls Personal Phones(AI Call for Me)
    https://mainfunc.ai/blog/genspark_ai_calls_personal_phones
  11. [R11] Genspark Blog — Introducing Genspark AI Browser(Autopilot Mode / MCP Store / 700+ tools)
    https://blog.genspark.ai/blog/genspark_ai_browser
  12. [R12] MainFunc.ai Blog — Genspark AI Browser and World's First On-Device Free AI(169 open-weight models / offline / privacy)
    https://mainfunc.ai/blog/genspark_ai_browser_and_on_device_free_ai
  13. [R13] Genspark Privacy Policy(第三方 API、Google Workspace API 数据使用边界等)
    https://blog.genspark.ai/privacy
  14. [R14] VentureBeat — What's inside Genspark?(MoE、多工具、backtracking、LLM judges/RL)
    https://venturebeat.com/ai/whats-inside-genspark-a-new-vibe-working-approach-that-ditches-rigid-workflows-for-autonomous-agents
  15. [R15] Reuters — AI startup Genspark raises $100 million to compete with Google(融资、月活、多模型深度研究特性)
    https://www.reuters.com/technology/artificial-intelligence/ai-startup-genspark-raises-100-million-compete-with-google-source-says-2025-02-21/
  16. [R16] MainFunc.ai Blog — Genspark AI Workspace and Series B Funding($275M Series B / $1.25B)
    https://mainfunc.ai/blog/genspark_ai_workspace_and_series_b_funding
  17. [R17] MainFunc.ai Blog — Collaboration with Microsoft(Agent 365 launch partners)
    https://mainfunc.ai/blog/genspark_microsoft_agent365

版权说明:本文为基于公开信息的二次整理与方法论抽象;引用仅用于溯源与学习研究。