如何在一个框架中实现「动态 Agent 发现「
1️⃣ 考察意图
面试官想看你能否设计一个"可扩展的 Agent 系统"——不是写死 3 个 Agent，而是运行时动态发现和注册新 Agent。刁钻点在于：很多人只答"用注册中心"，但说不清服务发现、健康检查、能力匹配、负载均衡等细节。答好了能展示你的微服务架构 + Agent 系统的交叉能力。
2️⃣ 标准答
动态 Agent 发现的核心是"注册中心 + 能力匹配 + 健康检查"三件套。
1. Agent 注册中心（Agent Registry）
注册中心是所有 Agent 的"通讯录"，存储每个 Agent 的元信息：
{ "agent_id": "agent_code_reviewer_01", "name": "代码审查专家", "description": "擅长 Python/Go 代码审查，熟悉 PEP8 和 Go 代码规范", "capabilities": ["code_review", "bug_detection", "style_check"], "endpoint": "grpc://10.0.0.5:50051", "status": "healthy", "load": {"active_tasks": 2, "max_tasks": 5}, "registered_at": "2025-01-15T10:00:00Z", "last_heartbeat": "2025-01-15T10:30:05Z" }实现选择：
- etcd/Consul：生产级注册中心，支持 TTL 健康检查、Watch 机制（Agent 上下线时自动通知）
- Redis：用 Hash 存 Agent 信息 + TTL 做 heartbeat，轻量但功能少
- PostgreSQL：持久化存储，适合需要审计的场景，但实时性差
2. Agent 注册流程
`Agent 启动 → 向 Registry 注册（agent_id, capabilities, endpoint）** → 定期发送 heartbeat（每 10 秒） → Registry 更新 last_heartbeat
Agent 停止 → 向 Registry 注销（deregister） → 或 heartbeat 超时（30 秒无心跳），Registry 自动剔除`3. 能力匹配（Capability Matching）**
当 Router Agent 收到任务时，需要找到"最合适"的 Agent：
- 精确匹配：任务的
required_capabilities与 Agent 的capabilities做集合交集。简单但可能匹配不到（Agent 能力描述不全） - 语义匹配：用 embedding 计算任务描述与 Agent description 的相似度。更灵活但需要预计算 embedding
- LLM 匹配：将任务和所有可用 Agent 的描述传给 LLM，让 LLM 选择。最准确但最慢（200-500ms）
生产建议：精确匹配做粗筛 → 语义匹配做精选 → LLM 做决策（可选）
4. 负载均衡
多个同类 Agent 可用时，需要做负载均衡：
| 策略 | 实现 | 适用场景 |
|---|---|---|
| 轮询（Round Robin） | 维护 index 轮流分配 | Agent 能力相同 |
| 最少连接（Least Connections） | 选择 active_tasks 最少的 | Agent 处理速度不同 |
| 加权随机（Weighted Random） | 按 Agent 的 max_tasks 加权 | Agent 容量不同 |
| 一致性哈希（Consistent Hash） | 按 task_id 哈希分配 | 需要会话保持 |
5. 健康检查与故障转移
- 主动检查：Registry 每 30 秒 ping 所有 Agent，无响应的标记为
unhealthy - 被动检查：Router 调用 Agent 失败时，标记为
unhealthy并重试其他 Agent - 故障转移：Agent 标记为
unhealthy后，Router 不再分配新任务。已有任务超时后重新分配给其他 Agent - 自动恢复：
unhealthy的 Agent 恢复后（heartbeat 恢复），自动变为healthy
6. 完整架构
┌──────────────┐** │ Agent Registry │ │ (etcd/Consul) │ └──────┬───────┘ │ Watch (Agent 上下线通知) ┌──────▼───────┐ User Request → │ Router Agent │ │ (能力匹配+负载均衡) │ └──┬───┬───┬───┘ │ │ │ ┌────────┘ │ └────────┐ ▼ ▼ ▼ ┌─────┐ ┌─────┐ ┌─────┐ │Agent A│ │Agent B│ │Agent C│ │(Coder)│ │(Tester)│ │(Reviewer)│ └─────┘ └─────┘ └─────┘
3️⃣ 答题模板（30 秒电梯版）
"动态 Agent 发现三件套：注册中心 + 能力匹配 + 健康检查。注册中心用 etcd/Consul，存储 Agent 的 id/capabilities/endpoint/status。Agent 启动时注册，每 10 秒 heartbeat，超时 30 秒自动剔除。能力匹配三级：精确匹配做粗筛（capabilities 交集）→ 语义匹配做精选（embedding 相似度）→ LLM 做决策（可选）。负载均衡用最少连接策略。故障转移：调用失败标记 unhealthy，任务重新分配。总结一句：动态发现让 Agent 系统像微服务一样可扩展。"
4️⃣ 高频追问 & 应对
追问 1**：Agent 的能力描述不准确怎么办？比如 Agent 说自己"擅长代码审查"但实际上审查质量很差。
三层保障：(1) 质量评分——每次任务完成后，调用方给 Agent 打分（1-5 星），Registry 维护滑动平均分。低于 3 星的 Agent 降级为"备选"；(2) A/B 测试——新注册的 Agent 先处理 10% 的流量，与老 Agent 对比效果。达标后升为"正式"；(3) 人工认证——关键 Agent（如处理支付的 Agent）需要人工审核能力描述后才能注册。这些机制类似于 Uber 司机的评分和认证系统。
追问 2：etcd/Consul 和自己用 Redis 实现注册中心有什么区别？
核心区别是"一致性保证"：(1) etcd/Consul 用 Raft 协议保证强一致性——任何时刻所有客户端看到相同的 Agent 列表。Redis 是 eventual consistency——不同 Redis 节点可能短暂不一致；(2) etcd/Consul 有 Watch 机制——Agent 上下线时主动推送通知，Router 不需要轮询。Redis 需要轮询或用 Keyspace Notification（不够可靠）；(3) etcd/Consul 有 TTL 租约——Agent 注册时绑定 TTL，过期自动剔除。Redis 用 expire key 模拟，但不够精确。建议：POC 用 Redis，生产用 etcd/Consul。
追问 3：动态发现会不会带来安全问题？比如恶意 Agent 注册到 Registry 中？
会。安全措施：(1) 注册认证——Agent 注册时需要携带 token/certificate，Registry 验证后才允许注册。类似 mTLS；(2) 能力白名单——Agent 只能注册预定义的能力类型，不能自创（如不能注册 "capability: delete_database"）；(3) 网络隔离——Registry 和 Agent 在内网通信，不暴露公网。外部 Agent 通过 API Gateway 中转注册；(4) 审计日志——所有注册/注销事件记录到审计日志，便于追溯。参考 Kubernetes 的 Service Account + RBAC 模型。
5️⃣ 避坑 · 常见错误答法
- ❌ "动态发现太复杂了，写死 3 个 Agent 就行" → ✅ "写死 Agent 在 POC 阶段可以，但生产环境需要动态发现——Agent 可能宕机、扩容、升级。没有动态发现，每次 Agent 变更都需要修改代码和重启。"
- ❌ "用 Kubernetes 的 Service Discovery 就行了" → ✅ "K8s Service Discovery 只做网络层发现（IP+端口），不包含 Agent 的能力信息（capabilities）。Agent 发现需要应用层的注册中心，存储能力描述和负载信息。可以在 K8s 之上加一层 Agent Registry。"
- ❌ "Router 用 LLM 做能力匹配最准确" → ✅ "LLM 匹配准确但慢（200-500ms）且贵（每次调用消耗 token）。生产环境应该用 embedding 做粗筛（<10ms）+ LLM 做精选（可选）。100 个 Agent 中先用 embedding 选 top-3，再用 LLM 从 3 个中选 1 个。"
6️⃣ 简历呼应
- 如果你有微服务架构经验：从"服务发现迁移到 Agent 发现"切入，说明你理解 K8s Service Discovery / etcd / Consul 的原理，以及 Agent 发现额外需要的能力匹配层
- 如果你只做过单进程 Agent：用"从单体到微服务"类比，说明你理解动态发现的必要性（可扩展、容错、弹性），以及实现方案
- 如果你是校招无项目：用 etcd + Python 实现一个 Agent 注册中心，支持注册/注销/heartbeat/能力匹配，写一篇博客
- "Designing Data-Intensive Applications" (Kleppmann, 2017) — 第6章 分区
- "Service Discovery in Distributed Systems" (Richardson, 2018)
- "Multi-Agent System Architecture Patterns" (Ji et al., 2024)
本章学习完毕 ← 返回 Agent 岗面试宝典 v3 · 精华版 | 📝 建议整理错题笔记 | 🎯 标记掌握程度