Personalized Agent Swarms Analyzer 深度解析从对话历史到个性化 Mini-Agent 群组的模式提取与生成【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai本篇技术指南聚焦generative-ai仓库中agents/personalized-agent-swarms项目的Analyzer 模块analyzer/README.md。它是整条「个性化 Mini-Agent 群组」流水线的第二阶段读取用户会话历史用 Gemini 3.1 Pro 提取重复出现的意图模式并为每个模式自动生成带触发器trigger、作用域向量scope embedding与 Python 代码的 mini-agent。读完本文你将掌握该模块的完整流水线、核心源码调用链、特征匹配与软惩罚逻辑以及从命令行运行到产出物解读的端到端实操方法。Analyzer 在流水线中的定位personalized-agent-swarms是一条完整的研究型实验流水线先由harvest/模拟多轮人机对话生成历史history/{user_id}/再由Analyzer从历史中提炼模式并生成群组swarms/{user_id}/最后由augmented_assistant_agent/在运行时加载这些 mini-agent 提供个性化回答。仓库根目录的 README.md 明确注明这是一套experimental research pipeline实验性研究管道并非生产级产品运行前需要在.env中配置自己的 Google Cloud 项目与模型。Analyzer 的核心职责可以概括为一句官方描述Processes conversational history to extract recurring intent patterns and generate personalized mini-agent swarms——处理会话历史提取重复意图模式并生成个性化 mini-agent 群组。它向上承接harvest/orchestrator.py产出的会话 JSON向下为运行时匹配提供triggers.json、user_style.json和agents/*.py。工作原理一条 10 步生成流水线analyzer/README.md 用 10 个步骤概括了从「历史」到「群组」的完整链路以下逐一结合源码展开加载会话日志从history/{user_id}/读取全部session_*.json。在 analyze_history.py 中通过sorted(user_history_dir.glob(session_*.json))按文件名排序加载若目录不存在或为空则直接返回。分批送审每 10 个会话为一批batch_size10见 pattern_extractor.py 的sessions[i:ibatch_size]分片逻辑调用 Gemini 3.1 Pro 做模式提取。批处理时会把会话做瘦身仅保留scenario_id、intent、follow_up_strategy、turns、turn_count以控制上下文长度。跨批合并去重每批返回的模式按pattern_name归并同名的调用Pattern.merge()叠加频次、合并触发词dict.fromkeys保序去重、偏好字典做浅合并复杂度只要任一方为dynamic就升级为dynamic。此外还通过 Jaccard 相似度做跨名合并当两个模式的 trigger signals 集合相似度 0.5时低频模式并入高频模式pattern_extractor.py。频次过滤只保留出现次数 3个会话的模式min_frequency3按频次降序排列。任务模式与行为模式分离pattern_type task的是「用户要做什么」如调试代码、写营销文案pattern_type behavioral的是「用户怎么沟通」如消息经常发一半、被长文淹没。行为模式被聚合进user_style.json作为共享风格画像而不是生成独立 agent——这是为了避免把沟通风格误判为意图导致误触发。行为模式 →user_style.json由 swarm_generator.py 的_generate_user_style合成输出response_length、language_level、format、tone、follow_up、avoid等键。Prompt 特别强调要用任务模式来校正行为模式的矛盾比如用户偶尔觉得信息过载但任务模式显示他要全面深入的输出时不应写成 short/concise。任务模式逐个生成三件套每个任务模式都会生成触发器定义triggers.json含结构化属性规则、Python mini-agent 文件agents/{pattern_name}.py、768 维作用域向量text-embedding-005。生成时还有两道 V8 加固并行双候选生成温度 0.2 与 0.35 各出一份代码都通过compile()后用 Flash 挑选更 grounded 的一份swarm_generator.py和生成后事实核查_fact_check_agent扫描ENRICHED_PROMPT中的 API 名、CLI flag、URL 等声明并按 HIGH/MEDIUM/LOW 置信度分级LOW 置信度声明会被改写为带 verify the exact flag name 之类的保守措辞。Critic/修订轮用真实历史会话逐 agent 验证最多 3 轮。每轮做compile()校验、确认execute()是 async、用匹配会话的首条用户消息运行 agent、把输出与历史中的 gold reference 一起交给 critic LLM 打分0-10 分10 个维度不过 7 分就触发独立的 revise LLM 改写。评价与修订使用两次独立 LLM 调用以避免评分偏差发现 2 处事实矛盾编造的 API 名、CLI flag、URL、函数签名时触发捏造硬顶得分封顶 4/10 并强制修订swarm_generator.py。非参数化质量排名critic 之后由 Gemini 3.1 Pro 用 5 维评分VALUE×3、DISTINCTIVENESS×2、TRIGGER_CLARITY×2、QUALITY×2、FREQUENCY×1满分 50逐个打分加权总分在 Python 侧计算不设固定目标数量凡 25/50 全部保留另有独立的 veto 轮剔除冗余或低价值 agent生成前有 30 个的硬性安全上限HARD_CAP_AGENTS见 swarm_generator.py防止极端情况下的成本失控。LLM 打分整体失败时回退到纯频次过滤 4 个会话。覆盖率校验排名淘汰 agent 后检查被淘汰模式是否仍被幸存者覆盖swarm_generator.py。存在缺口时通过作用域向量余弦相似度找到最近的幸存 agent把孤儿模式的域并入其规则domain扩展、冲突exclude_keywords移除跨域用户persona 同时含 software_engineering 与 devops_infrastructure 等还会扩展最高频 agent 的域列表最后重算所有作用域向量。流水线末尾还有一个V8 验证门validation gate对排名后幸存的每个 agent从历史中选 3 个相似 3 个不同场景用与 Phase 4 相同的多轮评测 harness模拟用户 3 维 judgeaccuracy/helpfulness/personalization实测满足avg_quality 2.5、trigger_rate 0、false_positive_count 1、无捏造才保留swarm_generator.py。核心组件与源码调用链Analyzer 目录下共 5 个核心文件职责高度内聚文件职责analyze_history.py主入口解析 CLI 参数、发现用户、串联「提取模式 → 生成群组」pattern_extractor.py基于 LLM 的模式聚类批处理、合并、去重、频次过滤swarm_generator.py生成 mini-agent.py、触发器、嵌入向量运行 critic/排名/覆盖率/验证门trigger_schema.py特征 schema、提取 Prompt、软惩罚匹配逻辑、规则校验、二元问卷llm_util.py对 Google Cloud 调用的重试 模型降级包装入口的调用链非常清晰analyze_history.main()→asyncio.run(async_main())→ 每个用户执行analyze_user()→extract_patterns()模式提取→generate_swarm()群组生成。generate_swarm内部按序执行生成 user_style → 逐个生成 agent 代码 → 生成属性规则 → 生成二元问卷 → 计算作用域向量 → 写入triggers.json/manifest.json→ critic 轮 → 重叠 agent 合并 → 质量排名 → 覆盖率校验 → 验证门 → 最终写盘swarm_generator.py。值得注意的设计细节触发匹配逻辑在生成期与运行期共享。trigger_schema.py 的文档字符串写明它同时被swarm_generator.py生成时构建 agent 规则和active_mem.py运行时特征提取 规则匹配使用trigger_matcher.py 则将「消息 → agent」的完整匹配管线抽成共享函数验证门和运行时走同一套逻辑确保验证质量与实际评测一致。匹配逻辑软惩罚取代硬拒绝这是 README 单独成节强调的核心设计值得重点展开。trigger_schema.py定义了完整的特征 schemadomain 标签13 个software_engineering、devops_infrastructure、data_science_ml、marketing_advertising、business_strategy、finance_accounting、food_beverage、travel_leisure、academic_research、consumer_lifestyle、human_resources、legal_compliance、othertask_type 标签10 个create_generate、debug_troubleshoot、analyze_evaluate、explain_teach、plan_strategize、configure_setup、find_search、format_structure、negotiate_communicate、otherspecificitygeneric/domain_aware/specialistoutput_formatcode/structured_text/narrative/calculation/mixedscopesingle_item/comparison/comprehensive/iterative运行时先用一次 Flash 调用抽取这 5 个枚举字段加topic_keywords3-8 个关键词和action_object动作对象短语再调用match_agent_rules_with_embeddingtrigger_schema.py做打分。其核心变化是domain 不匹配扣 0.15 分、task_type 不匹配扣 0.10 分而不是一票否决DOMAIN_MISMATCH_PENALTY 0.15、TASK_TYPE_MISMATCH_PENALTY 0.10见 trigger_schema.py。这样跨域请求只要语义相似度足够高仍能命中——例如一个 Dockerfile 请求可以匹配到用户的 code-example agent。specificity 下限仍是硬拒绝min_specificity防止噪音但默认generic规则生成 Prompt 甚至明确警告「NEVER use specialist」以免误伤真实用户消息。关键词匹配require_any_keyword/exclude_keywords已彻底移除只保留纯语义匹配相似度阈值默认 0.45EMBEDDING_SIMILARITY_THRESHOLD可由每个用户的_config.similarity_threshold覆盖。生成规则时同样有validate_rules()trigger_schema.py把关检查 domain/task_type 标签是否在合法集合内、require_any_keyword是否非空列表等非法规则会打印警告。运行时两阶段匹配上下文补充README 虽未展开但匹配逻辑的最终消费端是 trigger_matcher.py 的match_message_to_agentStage 1 并发执行特征抽取 消息嵌入对所有 agent 计算带惩罚的余弦相似度并按分排序Stage 2 对分数最高的至多 5 个候选并行执行各自 3-5 道二元问卷yes/no单次 Flash 调用合成分为40% 嵌入 60% 问卷匹配率问卷匹配率 0.8 的单一候选直接胜出若问卷无法区分再升级到 Pro 模型做 tiebreakerREVIEW_MODEL gemini-2.5-pro。这套「宽召回 精消歧」的层级设计正是 V8 版本误触发率大幅下降的关键。命令行使用从预览到全量生成README 提供了 4 条核心命令全部由 analyze_history.py 的argparse定义解析。完整用法如下source .venv/bin/activate # 分析所有用户自动发现 history/ 下所有 user_* 目录 python analyzer/analyze_history.py # 单个用户dry run只打印模式不生成任何文件 python analyzer/analyze_history.py --user user_1 --dry-run --verbose # 单个用户完整生成含 critic 轮 python analyzer/analyze_history.py --user user_1 # 跳过 critic 轮更快但质量略低 python analyzer/analyze_history.py --user user_1 --skip-critic四个 CLI 参数的含义与源码一一对应参数源码位置作用--user USER_IDanalyze_history.py只分析指定用户不传则扫描history/下所有user_*目录--dry-run同上#L109-L111提取并打印模式后立即返回跳过generate_swarm--skip-critic#L148-L149把skip_critic传入generate_swarmmanifest 中 critic_pass 标记为 skipped--verbose/-v#L90-L107打印每个模式的触发词、典型流程、用户偏好以及 critic/排名明细Dry-run 的-v输出会按• pattern_name (freqN, complexity) [behavioral]: description的格式列出所有模式并展开 Triggers、Flow、Preferences 三行细节便于在投入 LLM 成本前先人工审阅模式质量。运行前提需要先完成仓库根目录的 README.md 中的安装步骤uv syncgcloud auth application-default login并在.env中配置GOOGLE_GENAI_USE_VERTEXAITRUE、GOOGLE_CLOUD_PROJECT、GOOGLE_CLOUD_LOCATION。会话历史必须先由python harvest/orchestrator.pyharvest/orchestrator.py生成如果history/下没有任何用户目录主程序会提示先运行 harvest 并退出analyze_history.py。输出产物swarms/{user_id}/ 目录结构README 给出了生成目录的标准结构运行结束后会在swarms/{user_id}/下产出swarms/{user_id}/ ├── manifest.json # 全部 agent 的索引 元数据 critic/排名结果 ├── triggers.json # 触发器规则 作用域向量768 维 _config ├── user_style.json # 行为模式画像 └── agents/ ├── pattern_name_1.py # mini-agent含 async execute() 函数 └── pattern_name_2.py # 数量由质量排名决定通常 5-10 个各文件在源码中的写入位置均可追溯manifest.json在 swarm_generator.py 中构建记录user_id、generated_at、total_sessions_analyzed、agent_count、behavioral_patterns_absorbed、has_user_style以及每个 agent 的name/file/complexity/frequency/trigger_typecritic、merge、ranking、coverage、validation 各阶段结果也会追加写入。triggers.json键为 agent 名值为{trigger_type, rules, description, scope_embedding, binary_questions}特殊键_config存similarity_threshold: 0.45可在评测后按用户调优swarm_generator.py。user_style.json行为模式合成 _sanitize_user_style净化后的风格画像净化会剥离「检测消息截断」「逐条确认」「bite-sized」等会让一次性 agent 陷入多轮碎嘴的风格指令并注入全局覆盖「Always provide a complete, direct, self-contained answer」见 swarm_generator.py。agents/*.py生成的 mini-agent 是独立可运行的 Python 模块统一暴露async def execute(user_message: str, llm_client, historyNone) - str。complexity static时核心是AGENT_METAENRICHED_PROMPT单次 LLM 调用complexity dynamic时则是STEPS列表最多 3 步技术域 draft → verify → format非技术域 draft → synthesizeexecute()逐步前馈输出并只返回最后一步结果。生成 Prompt 强制要求调用形式await llm_client.aio.models.generate_content(...)generate_content_async不存在并在结尾注入「agent-specific instructions 优先于运行时注入的 STYLE INSTRUCTIONS」等约束。关于 agent 数量README 说明「typically 5-10」但实际是质量驱动而非固定数量——V8 排名阈值 25/50 veto 验证门共同决定最终保留数。仓库根 README 的评测结果也印证了这一点5 个模拟用户各 50 个会话最终生成 23 个任务 agent每用户 1-6 个不等。模型配置与容错Analyzer 所有 LLM 调用都经过 llm_util.py 的generate_with_fallback对主模型最多重试 2 次30s、60s 退避429 配额耗尽或 404 模型不可用时自动降级到后备模型全部失败才抛错。模型清单集中定义在仓库根 config.pyAnalyzer 相关的关键配置为配置项默认值用途ANALYSIS_MODELgemini-3.1-pro-preview模式提取、agent 生成、critic、排名ANALYSIS_FALLBACKS[gemini-3-pro-preview, gemini-2.5-pro]分析类调用的降级链TRIGGER_MODELgemini-2.5-flash运行时特征抽取 问卷评估低成本高吞吐REVIEW_MODELgemini-2.5-pro问卷无法区分时的 Pro tiebreakerEMBED_MODELtext-embedding-005作用域向量与消息嵌入768 维LOCATIONglobal所有模型走 global 端点单一值即可需要说明的是config.py中所有 Gemini 3.x 与 text-embedding-005 都依赖 Google Cloud 的模型可用性具体地区可用性请以你的 GCP 项目实际配额为准若目标模型不在global端点提供服务可通过.env的GOOGLE_CLOUD_LOCATION覆盖。小结一条可复现的个性化 agent 生产线Analyzer 模块把「从用户历史到个性化 agent 群组」这一抽象目标落成了一条完全可复现、可审计的工程流水线批式 LLM 模式提取 → 任务/行为分离 → 结构化触发器 语义作用域向量 → 双候选并行生成 事实核查 → 多轮 critic → 非参数化质量排名 → 覆盖率校验 → 多轮评测验证门。它在工程上最值得借鉴的三点设计是软惩罚匹配用扣分替代硬拒绝兼顾召回与精度、生成期与运行期共享同一套匹配逻辑验证即真实评测、以及分层质量闸门编译检查、LLM 打分、向量覆盖率、端到端多轮评测逐层过滤。对于想要构建「千人千面」式 agent 个性化系统的开发者这份源码是研究运行时 agent 个性化这一方向的完整范本。【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Personalized Agent Swarms Analyzer 深度解析：从对话历史到个性化 Mini-Agent 群组的模式提取与生成
Personalized Agent Swarms Analyzer 深度解析从对话历史到个性化 Mini-Agent 群组的模式提取与生成【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai本篇技术指南聚焦generative-ai仓库中agents/personalized-agent-swarms项目的Analyzer 模块analyzer/README.md。它是整条「个性化 Mini-Agent 群组」流水线的第二阶段读取用户会话历史用 Gemini 3.1 Pro 提取重复出现的意图模式并为每个模式自动生成带触发器trigger、作用域向量scope embedding与 Python 代码的 mini-agent。读完本文你将掌握该模块的完整流水线、核心源码调用链、特征匹配与软惩罚逻辑以及从命令行运行到产出物解读的端到端实操方法。Analyzer 在流水线中的定位personalized-agent-swarms是一条完整的研究型实验流水线先由harvest/模拟多轮人机对话生成历史history/{user_id}/再由Analyzer从历史中提炼模式并生成群组swarms/{user_id}/最后由augmented_assistant_agent/在运行时加载这些 mini-agent 提供个性化回答。仓库根目录的 README.md 明确注明这是一套experimental research pipeline实验性研究管道并非生产级产品运行前需要在.env中配置自己的 Google Cloud 项目与模型。Analyzer 的核心职责可以概括为一句官方描述Processes conversational history to extract recurring intent patterns and generate personalized mini-agent swarms——处理会话历史提取重复意图模式并生成个性化 mini-agent 群组。它向上承接harvest/orchestrator.py产出的会话 JSON向下为运行时匹配提供triggers.json、user_style.json和agents/*.py。工作原理一条 10 步生成流水线analyzer/README.md 用 10 个步骤概括了从「历史」到「群组」的完整链路以下逐一结合源码展开加载会话日志从history/{user_id}/读取全部session_*.json。在 analyze_history.py 中通过sorted(user_history_dir.glob(session_*.json))按文件名排序加载若目录不存在或为空则直接返回。分批送审每 10 个会话为一批batch_size10见 pattern_extractor.py 的sessions[i:ibatch_size]分片逻辑调用 Gemini 3.1 Pro 做模式提取。批处理时会把会话做瘦身仅保留scenario_id、intent、follow_up_strategy、turns、turn_count以控制上下文长度。跨批合并去重每批返回的模式按pattern_name归并同名的调用Pattern.merge()叠加频次、合并触发词dict.fromkeys保序去重、偏好字典做浅合并复杂度只要任一方为dynamic就升级为dynamic。此外还通过 Jaccard 相似度做跨名合并当两个模式的 trigger signals 集合相似度 0.5时低频模式并入高频模式pattern_extractor.py。频次过滤只保留出现次数 3个会话的模式min_frequency3按频次降序排列。任务模式与行为模式分离pattern_type task的是「用户要做什么」如调试代码、写营销文案pattern_type behavioral的是「用户怎么沟通」如消息经常发一半、被长文淹没。行为模式被聚合进user_style.json作为共享风格画像而不是生成独立 agent——这是为了避免把沟通风格误判为意图导致误触发。行为模式 →user_style.json由 swarm_generator.py 的_generate_user_style合成输出response_length、language_level、format、tone、follow_up、avoid等键。Prompt 特别强调要用任务模式来校正行为模式的矛盾比如用户偶尔觉得信息过载但任务模式显示他要全面深入的输出时不应写成 short/concise。任务模式逐个生成三件套每个任务模式都会生成触发器定义triggers.json含结构化属性规则、Python mini-agent 文件agents/{pattern_name}.py、768 维作用域向量text-embedding-005。生成时还有两道 V8 加固并行双候选生成温度 0.2 与 0.35 各出一份代码都通过compile()后用 Flash 挑选更 grounded 的一份swarm_generator.py和生成后事实核查_fact_check_agent扫描ENRICHED_PROMPT中的 API 名、CLI flag、URL 等声明并按 HIGH/MEDIUM/LOW 置信度分级LOW 置信度声明会被改写为带 verify the exact flag name 之类的保守措辞。Critic/修订轮用真实历史会话逐 agent 验证最多 3 轮。每轮做compile()校验、确认execute()是 async、用匹配会话的首条用户消息运行 agent、把输出与历史中的 gold reference 一起交给 critic LLM 打分0-10 分10 个维度不过 7 分就触发独立的 revise LLM 改写。评价与修订使用两次独立 LLM 调用以避免评分偏差发现 2 处事实矛盾编造的 API 名、CLI flag、URL、函数签名时触发捏造硬顶得分封顶 4/10 并强制修订swarm_generator.py。非参数化质量排名critic 之后由 Gemini 3.1 Pro 用 5 维评分VALUE×3、DISTINCTIVENESS×2、TRIGGER_CLARITY×2、QUALITY×2、FREQUENCY×1满分 50逐个打分加权总分在 Python 侧计算不设固定目标数量凡 25/50 全部保留另有独立的 veto 轮剔除冗余或低价值 agent生成前有 30 个的硬性安全上限HARD_CAP_AGENTS见 swarm_generator.py防止极端情况下的成本失控。LLM 打分整体失败时回退到纯频次过滤 4 个会话。覆盖率校验排名淘汰 agent 后检查被淘汰模式是否仍被幸存者覆盖swarm_generator.py。存在缺口时通过作用域向量余弦相似度找到最近的幸存 agent把孤儿模式的域并入其规则domain扩展、冲突exclude_keywords移除跨域用户persona 同时含 software_engineering 与 devops_infrastructure 等还会扩展最高频 agent 的域列表最后重算所有作用域向量。流水线末尾还有一个V8 验证门validation gate对排名后幸存的每个 agent从历史中选 3 个相似 3 个不同场景用与 Phase 4 相同的多轮评测 harness模拟用户 3 维 judgeaccuracy/helpfulness/personalization实测满足avg_quality 2.5、trigger_rate 0、false_positive_count 1、无捏造才保留swarm_generator.py。核心组件与源码调用链Analyzer 目录下共 5 个核心文件职责高度内聚文件职责analyze_history.py主入口解析 CLI 参数、发现用户、串联「提取模式 → 生成群组」pattern_extractor.py基于 LLM 的模式聚类批处理、合并、去重、频次过滤swarm_generator.py生成 mini-agent.py、触发器、嵌入向量运行 critic/排名/覆盖率/验证门trigger_schema.py特征 schema、提取 Prompt、软惩罚匹配逻辑、规则校验、二元问卷llm_util.py对 Google Cloud 调用的重试 模型降级包装入口的调用链非常清晰analyze_history.main()→asyncio.run(async_main())→ 每个用户执行analyze_user()→extract_patterns()模式提取→generate_swarm()群组生成。generate_swarm内部按序执行生成 user_style → 逐个生成 agent 代码 → 生成属性规则 → 生成二元问卷 → 计算作用域向量 → 写入triggers.json/manifest.json→ critic 轮 → 重叠 agent 合并 → 质量排名 → 覆盖率校验 → 验证门 → 最终写盘swarm_generator.py。值得注意的设计细节触发匹配逻辑在生成期与运行期共享。trigger_schema.py 的文档字符串写明它同时被swarm_generator.py生成时构建 agent 规则和active_mem.py运行时特征提取 规则匹配使用trigger_matcher.py 则将「消息 → agent」的完整匹配管线抽成共享函数验证门和运行时走同一套逻辑确保验证质量与实际评测一致。匹配逻辑软惩罚取代硬拒绝这是 README 单独成节强调的核心设计值得重点展开。trigger_schema.py定义了完整的特征 schemadomain 标签13 个software_engineering、devops_infrastructure、data_science_ml、marketing_advertising、business_strategy、finance_accounting、food_beverage、travel_leisure、academic_research、consumer_lifestyle、human_resources、legal_compliance、othertask_type 标签10 个create_generate、debug_troubleshoot、analyze_evaluate、explain_teach、plan_strategize、configure_setup、find_search、format_structure、negotiate_communicate、otherspecificitygeneric/domain_aware/specialistoutput_formatcode/structured_text/narrative/calculation/mixedscopesingle_item/comparison/comprehensive/iterative运行时先用一次 Flash 调用抽取这 5 个枚举字段加topic_keywords3-8 个关键词和action_object动作对象短语再调用match_agent_rules_with_embeddingtrigger_schema.py做打分。其核心变化是domain 不匹配扣 0.15 分、task_type 不匹配扣 0.10 分而不是一票否决DOMAIN_MISMATCH_PENALTY 0.15、TASK_TYPE_MISMATCH_PENALTY 0.10见 trigger_schema.py。这样跨域请求只要语义相似度足够高仍能命中——例如一个 Dockerfile 请求可以匹配到用户的 code-example agent。specificity 下限仍是硬拒绝min_specificity防止噪音但默认generic规则生成 Prompt 甚至明确警告「NEVER use specialist」以免误伤真实用户消息。关键词匹配require_any_keyword/exclude_keywords已彻底移除只保留纯语义匹配相似度阈值默认 0.45EMBEDDING_SIMILARITY_THRESHOLD可由每个用户的_config.similarity_threshold覆盖。生成规则时同样有validate_rules()trigger_schema.py把关检查 domain/task_type 标签是否在合法集合内、require_any_keyword是否非空列表等非法规则会打印警告。运行时两阶段匹配上下文补充README 虽未展开但匹配逻辑的最终消费端是 trigger_matcher.py 的match_message_to_agentStage 1 并发执行特征抽取 消息嵌入对所有 agent 计算带惩罚的余弦相似度并按分排序Stage 2 对分数最高的至多 5 个候选并行执行各自 3-5 道二元问卷yes/no单次 Flash 调用合成分为40% 嵌入 60% 问卷匹配率问卷匹配率 0.8 的单一候选直接胜出若问卷无法区分再升级到 Pro 模型做 tiebreakerREVIEW_MODEL gemini-2.5-pro。这套「宽召回 精消歧」的层级设计正是 V8 版本误触发率大幅下降的关键。命令行使用从预览到全量生成README 提供了 4 条核心命令全部由 analyze_history.py 的argparse定义解析。完整用法如下source .venv/bin/activate # 分析所有用户自动发现 history/ 下所有 user_* 目录 python analyzer/analyze_history.py # 单个用户dry run只打印模式不生成任何文件 python analyzer/analyze_history.py --user user_1 --dry-run --verbose # 单个用户完整生成含 critic 轮 python analyzer/analyze_history.py --user user_1 # 跳过 critic 轮更快但质量略低 python analyzer/analyze_history.py --user user_1 --skip-critic四个 CLI 参数的含义与源码一一对应参数源码位置作用--user USER_IDanalyze_history.py只分析指定用户不传则扫描history/下所有user_*目录--dry-run同上#L109-L111提取并打印模式后立即返回跳过generate_swarm--skip-critic#L148-L149把skip_critic传入generate_swarmmanifest 中 critic_pass 标记为 skipped--verbose/-v#L90-L107打印每个模式的触发词、典型流程、用户偏好以及 critic/排名明细Dry-run 的-v输出会按• pattern_name (freqN, complexity) [behavioral]: description的格式列出所有模式并展开 Triggers、Flow、Preferences 三行细节便于在投入 LLM 成本前先人工审阅模式质量。运行前提需要先完成仓库根目录的 README.md 中的安装步骤uv syncgcloud auth application-default login并在.env中配置GOOGLE_GENAI_USE_VERTEXAITRUE、GOOGLE_CLOUD_PROJECT、GOOGLE_CLOUD_LOCATION。会话历史必须先由python harvest/orchestrator.pyharvest/orchestrator.py生成如果history/下没有任何用户目录主程序会提示先运行 harvest 并退出analyze_history.py。输出产物swarms/{user_id}/ 目录结构README 给出了生成目录的标准结构运行结束后会在swarms/{user_id}/下产出swarms/{user_id}/ ├── manifest.json # 全部 agent 的索引 元数据 critic/排名结果 ├── triggers.json # 触发器规则 作用域向量768 维 _config ├── user_style.json # 行为模式画像 └── agents/ ├── pattern_name_1.py # mini-agent含 async execute() 函数 └── pattern_name_2.py # 数量由质量排名决定通常 5-10 个各文件在源码中的写入位置均可追溯manifest.json在 swarm_generator.py 中构建记录user_id、generated_at、total_sessions_analyzed、agent_count、behavioral_patterns_absorbed、has_user_style以及每个 agent 的name/file/complexity/frequency/trigger_typecritic、merge、ranking、coverage、validation 各阶段结果也会追加写入。triggers.json键为 agent 名值为{trigger_type, rules, description, scope_embedding, binary_questions}特殊键_config存similarity_threshold: 0.45可在评测后按用户调优swarm_generator.py。user_style.json行为模式合成 _sanitize_user_style净化后的风格画像净化会剥离「检测消息截断」「逐条确认」「bite-sized」等会让一次性 agent 陷入多轮碎嘴的风格指令并注入全局覆盖「Always provide a complete, direct, self-contained answer」见 swarm_generator.py。agents/*.py生成的 mini-agent 是独立可运行的 Python 模块统一暴露async def execute(user_message: str, llm_client, historyNone) - str。complexity static时核心是AGENT_METAENRICHED_PROMPT单次 LLM 调用complexity dynamic时则是STEPS列表最多 3 步技术域 draft → verify → format非技术域 draft → synthesizeexecute()逐步前馈输出并只返回最后一步结果。生成 Prompt 强制要求调用形式await llm_client.aio.models.generate_content(...)generate_content_async不存在并在结尾注入「agent-specific instructions 优先于运行时注入的 STYLE INSTRUCTIONS」等约束。关于 agent 数量README 说明「typically 5-10」但实际是质量驱动而非固定数量——V8 排名阈值 25/50 veto 验证门共同决定最终保留数。仓库根 README 的评测结果也印证了这一点5 个模拟用户各 50 个会话最终生成 23 个任务 agent每用户 1-6 个不等。模型配置与容错Analyzer 所有 LLM 调用都经过 llm_util.py 的generate_with_fallback对主模型最多重试 2 次30s、60s 退避429 配额耗尽或 404 模型不可用时自动降级到后备模型全部失败才抛错。模型清单集中定义在仓库根 config.pyAnalyzer 相关的关键配置为配置项默认值用途ANALYSIS_MODELgemini-3.1-pro-preview模式提取、agent 生成、critic、排名ANALYSIS_FALLBACKS[gemini-3-pro-preview, gemini-2.5-pro]分析类调用的降级链TRIGGER_MODELgemini-2.5-flash运行时特征抽取 问卷评估低成本高吞吐REVIEW_MODELgemini-2.5-pro问卷无法区分时的 Pro tiebreakerEMBED_MODELtext-embedding-005作用域向量与消息嵌入768 维LOCATIONglobal所有模型走 global 端点单一值即可需要说明的是config.py中所有 Gemini 3.x 与 text-embedding-005 都依赖 Google Cloud 的模型可用性具体地区可用性请以你的 GCP 项目实际配额为准若目标模型不在global端点提供服务可通过.env的GOOGLE_CLOUD_LOCATION覆盖。小结一条可复现的个性化 agent 生产线Analyzer 模块把「从用户历史到个性化 agent 群组」这一抽象目标落成了一条完全可复现、可审计的工程流水线批式 LLM 模式提取 → 任务/行为分离 → 结构化触发器 语义作用域向量 → 双候选并行生成 事实核查 → 多轮 critic → 非参数化质量排名 → 覆盖率校验 → 多轮评测验证门。它在工程上最值得借鉴的三点设计是软惩罚匹配用扣分替代硬拒绝兼顾召回与精度、生成期与运行期共享同一套匹配逻辑验证即真实评测、以及分层质量闸门编译检查、LLM 打分、向量覆盖率、端到端多轮评测逐层过滤。对于想要构建「千人千面」式 agent 个性化系统的开发者这份源码是研究运行时 agent 个性化这一方向的完整范本。【免费下载链接】generative-aiSample code and notebooks for Generative AI on Google Cloud, with Gemini Enterprise Agent Platform项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考