AI前沿技术与概念
🔹 Harness Engineering（驾驭工程）与 Prompt Engineering 的本质区别¶
Prompt Engineering 解决的是“单次交互”的质量问题，而 Harness Engineering 解决的是“整个系统”的可靠性、安全性和成本问题。
如果把 LLM 比作一台强劲但不太听话的发动机，那么：
-
Prompt Engineering 是调校油门和点火时机，让每一次燃烧更充分。
-
Harness Engineering 则是给这台发动机配上刹车、方向盘、冷却系统和仪表盘，把它装进一辆能安全上路的车里。
Prompt Engineering Harness Engineering
───────────────────── ────────────────────────
关注点：提示词怎么写 关注点：系统如何可靠运行
目标：单次输出更准、更相关 目标：整体服务可用、可控、可观测
手段：措辞、Few-shot、CoT 手段：缓存、路由、护栏、重试、追踪
产出：一个 Prompt 模板 产出：一套生产级 AI 系统
核心差异一览：
一个 Harness Engineering 的实践示例：一个带缓存的 LLM 调用包装器
这个小小的包装器体现了“驾驭”的思路——不是直接裸露地调用 API，而是加上缓存、重试、追踪等生产必需的横切能力。
import hashlib, json, time
from functools import lru_cache
class HarnessedLLM:
"""一个简单的、被驾驭过的 LLM 调用器"""
def __init__(self, client, cache_size=128):
self.client = client
# 注意：生产环境应使用分布式缓存(Redis)，此处仅作示意
self.cache = lru_cache(maxsize=cache_size)(self._raw_call)
def _raw_call(self, prompt_hash: str):
"""实际调用 LLM 的函数（参数需要可哈希）"""
# 这里需要还原真实的 messages，演示中简化
return "real response"
def call(self, messages: list, temperature: float = 0.7) -> str:
# 1. 生成缓存键（考虑模型和主要参数）
key = hashlib.md5(json.dumps(messages, sort_keys=True).encode()).hexdigest()
# 2. 尝试读取缓存
cached = self.cache(key)
if cached != "real response": # 命中
return cached
# 3. 调用 LLM，带重试机制
for attempt in range(3):
try:
response = self.client.chat.completions.create(
model="gpt-4o",
messages=messages,
temperature=temperature
)
# 4. 记录追踪日志（如耗时、Token 用量）
# ...
result = response.choices[0].message.content
# 5. 写入缓存
self.cache(key, result)
return result
except Exception as e:
if attempt == 2:
raise
time.sleep(2 ** attempt)
在这个例子中，HarnessedLLM 把原本一个简单的 client.chat.completions.create 调用，升级为具备缓存、重试、日志埋点能力的可靠组件。这就是从 Prompt Engineering 走向 Harness Engineering 的微观体现。
一句话收束： Prompt Engineering 让你会说，Harness Engineering 让你能跑。前者决定模型的上限，后者决定系统的底线。
🤖Agent 自主进化（Self-Evolving Agent）与实现路径¶
Agent 的自主进化，是指它能在运行过程中，通过积累经验、反思错误、更新记忆或策略，持续提升后续任务表现的能力。
这打破了传统“训练好就固定”的模型范式，让 Agent 像实习生一样——干得越多，经验越丰富，下次干得越好。
目前主要有三条实现路径，按成熟度排列：
路径一：记忆增强与反思（最常用）
Agent 将失败的任务、成功的策略、人类反馈存入外部记忆（向量库）。
每次接到新任务时，检索相关的历史经验，注入到 Prompt 中。
代表：Reflexion, Self-Refine, MemGPT 等。
路径二：自动提示优化
用一个“优化器 Agent”观察主 Agent 的运行日志，自动修改其 Prompt。
代表：DSPy (自动化提示与微调), PromptAgent 等。
路径三：自我博弈与合成数据微调
Agent 通过自己生成的数据进行强化学习或 SFT，更新模型参数。
代表：SPIN (自我博弈微调), Self-Rewarding Language Models。
此路径风险较高，容易导致模型退化（Model Collapse），需谨慎验证。
一条可以落地的简单路径：带反思记忆的 Agent
以下是一个基于“经验记忆”的简易自主进化 Agent 骨架，它会在每次任务后自动总结成败原因，下次遇到类似任务时检索出来作为参考。
import chromadb, json
from datetime import datetime
class EvolvingAgent:
def __init__(self, llm, vector_db_path="./agent_memory"):
self.llm = llm
self.memory = chromadb.PersistentClient(path=vector_db_path)
self.experience = self.memory.get_or_create_collection("experiences")
def execute(self, task: str) -> str:
# 1. 进化：检索相关历史经验
relevant_exp = self.experience.query(query_texts=[task], n_results=2)
exp_context = "\n".join([e["document"] for e in relevant_exp["documents"][0]])
# 2. 将经验注入提示词
system_prompt = f"""你是一个持续学习的 Agent。
以下是过往类似任务的经验教训，请参考以避免重蹈覆辙：
{exp_context if exp_context else "无相关经验"}"""
# 3. 执行任务（此处简化，实际可能是多步 Agent）
response = self.llm.call(task, system=system_prompt)
# 4. 进化：事后反思并存储新经验
reflection = self.llm.call(
f"任务：{task}\n结果：{response}\n请用一句话总结这次执行的成败原因。"
)
self.experience.add(
documents=[reflection],
metadatas=[{"timestamp": datetime.now().isoformat(), "task": task[:100]}],
ids=[str(hash(task))]
)
return response
这个 Agent 的核心进化循环就是：检索经验 → 应用经验 → 反思 → 存储新经验。随着任务增多，它的“经验库”会自然增长，表现出越来越少的低级失误。
目前的局限与真实前景：
真正意义上的自主进化（如模型参数的在线更新）仍面临稳定性、安全性、成本等诸多挑战。但记忆增强与反思这条路已经能在生产环境中显著提升 Agent 的稳定性和任务成功率，是当前最值得投入的方向。
👨💻 Agentic Coding 如何改变软件开发范式？¶
Agentic Coding（智能体编码）不是更高级的代码补全，而是将整个软件开发生命周期的决策权、规划权和执行权，部分或全部委托给 AI Agent。
它让开发者的角色从 “砌砖工人” 转变为 “建筑设计师和监理”。
范式的根本性转变：
传统编码： 开发者 → 写代码(逐行) → 编译测试 → 修 Bug → 部署
Copilot 时代： 开发者 → 提需求 → AI 补全片段 → 开发者审核 → ...
Agentic 编码： 开发者 → 定义目标 → AI Agent 规划任务 →
→ 多 Agent 协作(架构/编码/测试/审查) → 提交 PR
一个具体的 Agentic Coding 工作流演示 (基于 AutoGen)
假设我们要实现一个“从 CSV 文件读取销售数据，计算各地区总额，并生成 HTML 报告”的任务。我们可以组建一个微型 AI 开发团队：
from autogen import AssistantAgent, UserProxyAgent
# 项目经理 Agent
pm = AssistantAgent("PM", llm_config={"model": "gpt-4o"},
system_message="你是项目经理。将任务拆解为可执行的开发步骤，分配给工程师。")
# 高级工程师 Agent (写代码)
senior_dev = AssistantAgent("SeniorDev", llm_config={"model": "gpt-4o"},
system_message="你是资深 Python 工程师。编写清晰、健壮的代码，处理边界情况。")
# 测试工程师 Agent
qa = AssistantAgent("QA", llm_config={"model": "gpt-4o"},
system_message="你是测试工程师。编写单元测试，并审查代码中的潜在Bug。")
# 代表用户执行代码的 Agent
user_proxy = UserProxyAgent("UserProxy", human_input_mode="NEVER",
code_execution_config={"work_dir": "project_workspace"})
# 启动开发流程
user_proxy.initiate_chat(pm, message="""
请组织团队完成以下任务：
1. 读取 sales.csv 文件（包含 Region, Product, Revenue 列）。
2. 计算每个 Region 的总收入。
3. 将结果生成一个简单的 HTML 报告（表格形式），保存为 report.html。
""")
在 Agentic Coding 模式下，开发者不再需要亲手写循环和 HTML 拼接。他只需要清晰地定义目标、约束和验收标准，然后监督 AI 团队的工作，审查最终的产出。如果中途有偏差，就像产品经理一样提出修改意见。
如何改变开发范式？
-
生产力十倍提升：80% 的样板代码、配置、单元测试由 Agent 自动生成，开发者聚焦核心业务逻辑和创新。
-
降低入门门槛：初级开发者可以直接指挥 Agent 完成复杂任务，学习曲线从“学语法”变为“学架构和协作”。
-
软件形态更灵活：未来可能出现“自适应软件”，能根据用户反馈，通过 Agent 自我修复、自我拓展，而不是等待下一个 Release 周期。
当然，挑战同样巨大： Agent 的幻觉可能在代码中埋下隐蔽的 Bug；安全与权限控制成为生死线；开发者需要建立新的信任机制——如何验证 AI 生成的系统是安全可靠的，这本身就是一个全新的工程领域。
🔧LLM Agent 的 Tool‑Use 进化：从 Function Calling 到 Computer Use¶
Agent 工具使用的进化，本质上就是把模型从“只会说话的大脑”逐步改造成“长着眼睛、手脚，能在真实世界办事的智能体”。 这中间经历了三个关键阶段。
阶段一：硬编码适配 阶段二：标准化协议 阶段三：多模态自主操作
Function Calling / Tools MCP / A2A Computer Use
(2023) (2024) (2025+)
模型只能调用你提前 一次编写，多个 Agent 模型直接操控屏幕、
定义好的函数，且绑定 复用，工具发现自动化 键盘，像人一样用软件
特定平台。 操作真实世界。
阶段一：Function Calling（原生工具调用）
这是起点。OpenAI / Claude 等模型学会输出一种特殊的 JSON 格式，告诉调用方“我想调用哪个函数，参数是什么”。但问题是：每个函数都是开发者为当前应用硬编码的，换个模型、换个项目就要重写，而且模型无法自己发现新工具。就像你给遥控器编好了每个按钮的功能，换台电视就得重新编程。
# 阶段一：手动把函数签名塞进每次请求
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市天气",
"parameters": {"type": "object", "properties": {"city": {"type": "string"}}}
}
}]
response = client.chat.completions.create(model="gpt-4", messages=msgs, tools=tools)
# 开发者自己解析 tool_calls，自己执行函数，自己把结果拼回去。
阶段二：标准化协议（MCP / A2A）
这是工具使用的“USB 接口”时刻。MCP（大模型上下文协议） 让工具提供者只需编写一个标准化的 MCP Server，任何支持 MCP 的 Agent 就能自动发现并调用这些工具，无需提前知道它们的存在。这彻底解耦了工具和 Agent，工具生态开始独立发展。
阶段三：Computer Use（自主操控数字世界）
这是最新的质变。模型不再需要通过预定义的 API 来间接操作软件，而是直接“看见”屏幕截图，并像人一样生成鼠标点击、键盘输入，进而操控任何图形界面软件。Claude 的 Computer Use、OpenAI 的 Operator 都是这个方向的先驱。
示例：Claude Computer Use 的思维链
用户：“帮我把上个月的销售数据从 CRM 里导出并做成图表。” Agent 观察屏幕：“我看到 CRM 图标，点击打开 → 找到‘报表’菜单 → 选择‘销售数据’ → 设置日期为上个月 → 点击导出 CSV → 打开 Excel → 导入数据 → 选择图表类型 → 生成柱状图 → 保存。”
这个阶段，Agent 不再是调用特定工具的“专家”，而是能使用任何软件的“通才”。
进化的核心逻辑：工具的通用性越来越高，Agent 对外界的依赖越来越低，最终走向“万物皆可操作”。从写死的函数签名，到可发现的标准协议，再到直接操控图形界面，每一步都在拓宽 Agent 的操作边界。
🌐 Context Engineering（上下文工程）：为什么它比 Prompt Engineering 更重要？¶
Prompt Engineering 关注的是“怎么提问”，而 Context Engineering 关注的是“提问时，模型眼前有什么信息”。
在大模型上下文窗口已经达到 128K 甚至 1M token 的今天，如何构造、压缩、排序、检索放入窗口的信息，往往比那一两段提示词本身更能决定输出质量。
Prompt Engineering Context Engineering
───────────────────── ────────────────────────
优化单条指令的措辞 管理整个上下文窗口的信息生态
假设模型是“一张白纸” 把模型看作可编程的“记忆体”
输出质量靠“说得好” 输出质量靠“看得全、看得准”
为什么上下文工程更重要？
-
窗口就是战场：100K token 的窗口可以塞进一整本书。但塞进去的东西是“有序、精准、带标注”还是“杂乱、冗余、相互矛盾”，直接决定模型最终是产出洞见还是垃圾。
-
信息架构决定推理深度：把相关文档、对话历史、工具返回结果、用户画像、护栏指令合理地组织在窗口里，就像给模型的大脑铺设了一条清晰的道路，它才能跑得又快又稳。
-
Prompt 的边际效益递减：当任务足够复杂时，试图通过雕琢一两句话来弥补知识的缺失，就像试图用更优美的提问让一个没见过物理书的人解出物理题。不如直接给他一本整理好的教材。
一个 Context Engineering 的工程实践：动态上下文组装器
class ContextBuilder:
"""负责根据当前意图，从多种来源拼装最优的上下文"""
def build(self, user_input: str, user_id: str, session_id: str) -> dict:
ctx = {
"system_prompt": "你是严谨的技术顾问。", # 固定的行为指令
"user_profile": self._get_user_profile(user_id), # 长期记忆
"retrieved_docs": self._retrieve(user_input), # 从知识库捞的相关文档
"conversation_summary": self._get_summary(session_id), # 压缩后的对话摘要
"tool_results": self._get_recent_tool_outputs(session_id), # 最近工具返回的数据
}
# 按优先级和重要性排序后注入模型，而不是全量无脑拼接
return self._assemble(ctx)
def _assemble(self, ctx: dict) -> list:
messages = [{"role": "system", "content": ctx["system_prompt"]}]
if ctx["user_profile"]:
messages.append({"role": "system", "content": f"用户画像: {ctx['user_profile']}"})
if ctx["retrieved_docs"]:
docs_text = "\n---\n".join([d["content"][:500] for d in ctx["retrieved_docs"]])
messages.append({"role": "system", "content": f"参考资料:\n{docs_text}"})
if ctx["conversation_summary"]:
messages.append({"role": "system", "content": f"对话历史摘要: {ctx['conversation_summary']}"})
return messages
在这个例子中，决定最终答案质量的，不只是那一条 system_prompt，更是 retrieved_docs 是否精准、conversation_summary 是否抓住了要害、user_profile 是否提供了个性化背景。这就是上下文工程的魔力——让模型在开口之前，就已经站在了巨人的肩膀上。
收束：如果说 Prompt Engineering 是教你怎么说话，那 Context Engineering 就是决定你站在怎样的信息土壤上开口。未来最顶级的 AI 应用，胜负手一定不是谁多写了一行“Let's think step by step”，而是谁能把上下文这个“黑箱”变成清晰、可控、可编程的战略资源。
🧠LLM 的 Reasoning（推理）能力进化：从 CoT 到 o1/o3¶
如果说工具是 LLM 的“手脚”，上下文是它的“知识”，那么推理就是它的“大脑皮层”。这个大脑在过去三年里经历了从浅层模仿到深度思考的质变。
CoT (2022) o1 / o3 (2024-2025)
────────── ──────────────────
外显的、被提示出的推理 内化的、强化的、自纠错的推理
依赖工程师写 Few-shot 依赖大量强化学习训练
输出“推理+答案” 输出隐式推理后的最终答案
像学生做草稿 像专家在脑中完成全部推演后才开口
第一阶段：Chain‑of‑Thought（思维链）
2022 年，Google 发现只需在提示词中加上“Let's think step by step”，模型的推理准确率就能大幅提升。这是 “外显推理” 的开端——模型被提示词强迫着把中间步骤写出来。
# CoT 的典型用法
prompt = """
Q: 小明有5个苹果，吃了2个，又买了3个，现在有几个？
Let's think step by step.
A: 5 - 2 = 3, 3 + 3 = 6. 答案是6。
"""
但它的问题是：推理过程完全靠提示词“哄”出来，模型本身没有形成推理习惯，一旦遇到复杂逻辑或需要自我纠错的场景，很容易写出流畅但错误的推理链而浑然不知。
第二阶段：Self‑Consistency 与 Tree‑of‑Thought（采样与搜索）
为弥补 CoT 的不稳定性，出现了两种思路：
-
Self‑Consistency：让模型用高温度生成多条推理链，投票选出最终答案。用数量换质量。
-
Tree‑of‑Thought：在每一步生成多个候选思考，用模型自身对它们打分，进行广度/深度搜索。把推理从“直线”变成了“树状搜索”。
第三阶段：o1/o3 与 DeepSeek‑R1（内化推理 + 强化学习）
这是真正质的飞跃。o1 系列不再依赖用户写提示词来“诱导”它推理。它在训练时就通过大规模强化学习（RL） 学会了：
-
在回答前进行隐式、长时间的内部思考（可能包含回溯、验证、自我质疑）。
-
识别自己的错误并主动纠正。
-
根据问题难度动态分配思考时间（即 test‑time compute scaling）。
o1 类模型的推理架构示意图：
Q7: 什么是 AI Agent 的记忆架构？如何设计一个高效的长期记忆系统？¶
1️⃣ Common Answer
AI Agent 的记忆系统通常分为几个层次：
-
工作记忆（Working Memory）：当前对话的上下文窗口，容量有限（受模型上下文长度限制）
-
短期记忆（Short-term Memory）：最近几轮对话的历史，通常存储在内存中
-
长期记忆（Long-term Memory）：持久化存储的历史信息，通常使用向量数据库
-
程序性记忆（Procedural Memory）：Agent 学到的技能和策略，编码在 Prompt 或代码中
实现方式：
-
短期记忆：对话历史列表，FIFO 或滑动窗口
-
长期记忆：向量数据库（如 Milvus、Chroma），通过 Embedding 检索相关记忆
-
记忆整合：定期将短期记忆中的重要信息提取并存入长期记忆
2️⃣ Impressive Answer
Agent 的记忆系统设计是一个被严重低估的技术挑战。大多数 Agent 框架只提供了简单的对话历史管理，但真正的生产级 Agent 需要一个类人的记忆架构。
类人记忆架构设计：
┌─────────────────────────────────────────────┐
│ 感知输入 │
│ 用户消息 / 工具输出 / 环境观察 │
└──────────────────┬──────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ 工作记忆（Working Memory） │
│ 当前上下文窗口，容量 ≈ 模型 Context Length │
│ ┌─────────┐ ┌──────────┐ ┌─────────────┐ │
│ │系统指令 │ │对话历史 │ │检索结果 │ │
│ └─────────┘ └──────────┘ └─────────────┘ │
└──────────────────┬──────────────────────────┘
┌────────┴────────┐
▼ ▼
┌──────────────┐ ┌──────────────────┐
│ 短期记忆 │ │ 长期记忆 │
│ (Redis) │ │ (Vector DB) │
│ 最近 N 轮 │ │ ┌──────────────┐ │
│ 完整对话 │ │ │ 情景记忆 │ │
│ TTL: 24h │ │ │ (经历和事件) │ │
└──────┬───────┘ │ ├──────────────┤ │
│ │ │ 语义记忆 │ │
│ 整合 │ │ (知识和事实) │ │
└──────────→│ ├──────────────┤ │
│ │ 程序性记忆 │ │
│ │ (技能和策略) │ │
│ └──────────────┘ │
└──────────────────┘
三种长期记忆的设计：
- 情景记忆 ——"发生过什么"
public class EpisodicMemory {
// 存储完整的交互事件
public void store(Episode episode) {
EpisodeEmbedding embedding = embedder.embed(episode.getSummary());
vectorStore.upsert(
embedding,
Map.of(
"timestamp", episode.getTimestamp(),
"userId", episode.getUserId(),
"outcome", episode.getOutcome(), // success/failure
"importance", episode.getImportanceScore()
)
);
}
// 检索相关经历
public List<Episode> recall(String currentSituation, int topK) {
return vectorStore.similaritySearch(currentSituation, topK)
.stream()
.filter(e -> e.getImportanceScore() > THRESHOLD)
.sorted(Comparator.comparing(Episode::getRecency)
.thenComparing(Episode::getImportance))
.collect(Collectors.toList());
}
}
-
语义记忆（Semantic Memory）——"知道什么"存储从交互中提取的事实和知识，如用户偏好、业务规则等。
-
程序性记忆（Procedural Memory）——"会做什么"存储 Agent 学到的技能和策略，如"处理退款投诉的最佳流程"。
记忆管理的关键机制：
-
重要性评分：不是所有信息都值得记住，用 LLM 评估每条记忆的重要性
-
记忆衰减：模拟人类遗忘曲线，长期未被检索的记忆权重降低
-
记忆整合：定期将碎片化的短期记忆整合为结构化的长期记忆
-
记忆冲突解决：当新信息与旧记忆矛盾时，需要更新机制
实际案例：在一个个人助理 Agent 中，我设计了三层记忆系统。Agent 能记住用户的偏好（"用户喜欢简洁的回答"）、历史事件（"上周用户问过关于 React 的问题"）和学到的技能（"处理日程冲突时，优先保留标记为重要的事件"）。经过 3 个月的运行，用户满意度从 3.2 分提升到 4.5 分（5 分制），主要提升来自 Agent 能"记住"用户的个性化需求。
Q8: 什么是 Multi-Agent 的涌现行为？多 Agent 系统中有哪些前沿的协作模式？¶
1️⃣ Common Answer
Multi-Agent 涌现行为是指多个 Agent 协作时，系统整体展现出单个 Agent 不具备的能力。这类似于蚁群中单只蚂蚁很简单，但整个蚁群能完成复杂的建筑和觅食任务。
当前主流的多 Agent 协作模式：
-
层级式（Hierarchical）：一个 Manager Agent 负责任务分配，多个 Worker Agent 执行具体任务。如 AutoGen、CrewAI。
-
辩论式（Debate）：多个 Agent 对同一问题给出不同观点，通过辩论达成共识。可以提升回答质量和减少幻觉。
-
流水线式（Pipeline）：Agent 按顺序处理任务，每个 Agent 负责一个阶段。如：需求分析 Agent → 编码 Agent → 测试 Agent。
-
去中心化（Decentralized）：Agent 之间平等协作，通过消息传递和协商完成任务。
2️⃣ Impressive Answer
Multi-Agent 系统的前沿研究正在从"预设协作模式"走向"自组织协作"，这是 Agent 研究中最令人兴奋的方向之一。
协作模式的进化：
Phase 1: 固定拓扑 —— 人工设计 Agent 角色和协作流程
Phase 2: 动态拓扑 —— Agent 根据任务自动调整协作结构
Phase 3: 涌现协作 —— Agent 自发形成协作模式，无需预设
前沿协作模式：
-
Agent Society（Agent 社会）受人类社会启发，构建一个 Agent 社会，每个 Agent 有自己的角色、目标和记忆：
-
Agent 之间可以自由交流和协商
-
存在"社会规范"约束 Agent 行为
-
通过"声誉系统"评估 Agent 的可信度
-
代表性工作：Generative Agents（斯坦福小镇）、MetaGPT
-
Mixture of Agents（MoA）类似于 Mixture of Experts（MoE），但在 Agent 层面：
-
多个 Agent 独立处理同一任务
-
一个 Aggregator Agent 综合所有结果
-
研究表明 MoA 的效果可以超过单个最强 Agent
-
Agent-as-a-Judge用 Agent 来评估其他 Agent 的输出质量：
-
比单纯的 LLM-as-Judge 更可靠（Agent 可以使用工具验证事实）
-
可以形成"评审委员会"，多个 Judge Agent 投票
-
Adversarial Collaboration（对抗式协作）引入"红队 Agent"来挑战"蓝队 Agent"的输出：
-
红队 Agent 专门寻找漏洞和错误
-
蓝队 Agent 必须回应挑战并改进
-
通过对抗提升最终输出质量
A2A 协议对多 Agent 协作的影响：
Google 推出的 A2A（Agent-to-Agent）协议，为多 Agent 协作提供了标准化基础：
-
Agent Card：每个 Agent 的能力描述（类似服务注册）
-
Task Management：标准化的任务分配和状态管理
-
Message Protocol：Agent 间的通信格式
A2A + MCP 的组合，构成了 Agent 生态的"TCP/IP + HTTP"——MCP 解决 Agent 与工具的交互，A2A 解决 Agent 与 Agent 的交互。
工程落地的关键挑战：
-
通信开销：Agent 之间的消息传递需要 LLM 调用，成本和延迟都很高
-
一致性问题：多个 Agent 可能产生矛盾的输出，需要冲突解决机制
-
调试困难：多 Agent 系统的行为难以预测和调试
-
成本爆炸：N 个 Agent 的成本不是线性增长，而是可能指数增长
Q9: 什么是 Structured Output（结构化输出）？它在 Agent 系统中为什么至关重要？¶
1️⃣ Common Answer
Structured Output 是指让 LLM 按照预定义的格式（如 JSON Schema）输出结构化数据，而不是自由文本。
主要实现方式：
-
JSON Mode：模型保证输出有效的 JSON
-
Schema 约束：指定具体的 JSON Schema，模型输出必须符合该 Schema
-
Grammar-based Decoding：在解码时用语法规则约束 Token 生成
在 Agent 系统中的应用：
-
工具调用参数的结构化输出
-
Agent 决策结果的格式化（选择哪个工具、传什么参数）
-
多 Agent 通信消息的标准化
2️⃣ Impressive Answer
Structured Output 是 Agent 系统的"类型系统"——它将 LLM 的概率性输出转化为程序可处理的确定性数据。没有可靠的 Structured Output，Agent 系统就像没有类型检查的代码——能跑但随时可能崩。
为什么 Structured Output 对 Agent 至关重要？
Agent 的每一步决策都需要被程序解析和执行：
技术实现的三个层次：
- Prompt-based（最弱）：在 Prompt 中要求模型输出 JSON
- 优点：简单
-
缺点：不保证格式正确，需要重试机制
-
API-level（中等）：使用 OpenAI 的 response_format 或 Structured Outputs API
- 优点：API 层面保证格式
-
缺点：依赖特定模型提供商
-
Decoding-level（最强）：在 Token 生成时用语法约束
- 如 Outlines、Guidance 等库
- 在每一步 Token 生成时，mask 掉不符合语法的 Token
- 100% 保证输出格式正确
// Spring AI 的 Structured Output 示例
public record AgentDecision(
@JsonProperty(required = true) String thought,
@JsonProperty(required = true) String toolName,
@JsonProperty(required = true) Map<String, Object> toolParams,
@JsonProperty(required = true) double confidence
) {}
ChatResponse response = chatClient.prompt()
.user("用户问：明天北京天气怎么样？")
.call()
.entity(AgentDecision.class); // 自动生成 Schema 并约束输出
在 Agent 系统中的高级应用：
-
决策链的类型安全：每一步 Agent 决策都有明确的类型定义，编译时就能发现错误
-
多 Agent 通信协议：Agent 之间的消息格式标准化，避免解析错误
-
可观测性增强：结构化的决策日志比自由文本更容易分析和监控
Q10: 如何看待 AI Agent 的"幻觉"问题？有哪些前沿的解决方案？¶
1️⃣ Common Answer
幻觉（Hallucination）是指 LLM 生成看似合理但实际上不正确的内容。在 Agent 系统中，幻觉问题更加严重，因为 Agent 的错误输出可能触发错误的工具调用，导致连锁反应。
常见的解决方案：
-
RAG（检索增强生成）：用外部知识库提供事实依据
-
Self-Consistency：多次采样，选择一致性最高的答案
-
Fact-Checking：对关键事实声明进行验证
-
Confidence Scoring：让模型输出置信度分数，低置信度时拒绝回答
2️⃣ Impressive Answer
幻觉是 LLM 的"原罪"——因为模型本质上是在做概率性的文本生成，而非基于事实的推理。在 Agent 系统中，幻觉的危害被放大了 N 倍，因为 Agent 会基于幻觉采取行动。
幻觉的分类：
幻觉类型：
├── 事实性幻觉：生成不存在的事实（"爱因斯坦在 1920 年获得诺贝尔奖"）
├── 忠实性幻觉：与给定上下文矛盾（RAG 检索到 A，但回答了 B）
├── 推理幻觉：推理过程中的逻辑错误
└── 工具幻觉：编造不存在的工具或 API 参数（Agent 特有）
前沿解决方案：
- Retrieval-Augmented Verification（RAV）不仅用 RAG 提供信息，还用 RAG 验证输出：
public class HallucinationDetector {
public VerificationResult verify(String agentOutput, String sourceContext) {
// 1. 提取输出中的事实声明
List<Claim> claims = claimExtractor.extract(agentOutput);
// 2. 对每个声明进行 RAG 验证
for (Claim claim : claims) {
List<Document> evidence = vectorStore.search(claim.getText());
boolean supported = llm.judge(
"以下声明是否被证据支持？\n声明：" + claim + "\n证据：" + evidence
);
if (!supported) {
return VerificationResult.hallucinated(claim);
}
}
return VerificationResult.verified();
}
}
-
Chain-of-Verification（CoVe）让模型自己生成验证问题，然后回答这些问题来检查一致性：
-
生成回答
-
针对回答生成验证问题
-
独立回答验证问题
-
对比原始回答和验证结果
-
Grounding 技术将 Agent 的输出"锚定"到可验证的数据源：
-
每个事实声明都必须附带来源引用
-
工具调用的参数必须来自上下文（而非模型编造）
-
数值数据必须通过工具获取（而非模型生成）
-
Agent 层面的幻觉防护
-
工具验证：Agent 调用工具前，验证工具名和参数是否在允许列表中
-
输出交叉验证：用多个 Agent 独立处理同一任务，对比结果
-
人工兜底：置信度低于阈值时，自动转人工处理
我的实践：在一个金融 Agent 项目中，我们实现了"三层幻觉防护"：
-
RAG 提供事实依据（减少 60% 的事实性幻觉）
-
Structured Output 约束输出格式（消除工具幻觉）
-
关键数据必须通过 API 获取，禁止模型自行生成（消除数值幻觉）
最终将幻觉率从 15% 降到了 2.3%，剩余的 2.3% 主要是推理幻觉，通过引入推理模型（o1）进一步降低到 0.8%。
Q11: 什么是 AI Agent 的 Sandbox（沙箱）技术？为什么它对 Agent 安全至关重要？¶
1️⃣ Common Answer
Sandbox（沙箱）是一种安全隔离技术，为 Agent 的代码执行和工具调用提供受限的运行环境。Agent 在沙箱中执行操作时，即使出错也不会影响宿主系统。
沙箱的核心能力：
-
文件系统隔离：Agent 只能访问指定目录
-
网络隔离：限制 Agent 的网络访问范围
-
资源限制：CPU、内存、执行时间的上限
-
权限控制：禁止危险操作（如 rm -rf、系统调用）
常见实现：Docker 容器、gVisor、WebAssembly（Wasm）、E2B 等。
2️⃣ Impressive Answer
沙箱是 Agent 安全的最后一道防线。当所有的 Prompt 防护、意图检测、权限控制都失败时，沙箱确保 Agent 的"破坏半径"被控制在可接受范围内。
为什么 Agent 比传统应用更需要沙箱？
传统应用的行为是确定性的——代码写了什么就执行什么。但 Agent 的行为是非确定性的——你无法预测 Agent 会生成什么代码、调用什么命令。这意味着：
-
Agent 可能生成恶意代码（被 Prompt 注入攻击）
-
Agent 可能执行危险命令（误解用户意图）
-
Agent 可能无限循环（推理出错）
沙箱架构设计：
┌─────────────────────────────────────┐
│ Agent Runtime │
│ ┌─────────────────────────────┐ │
│ │ Sandbox Layer │ │
│ │ ┌───────┐ ┌───────────┐ │ │
│ │ │ Code │ │ Tool │ │ │
│ │ │ Exec │ │ Exec │ │ │
│ │ │ (Wasm)│ │ (Docker) │ │ │
│ │ └───────┘ └───────────┘ │ │
│ │ ┌───────────────────────┐ │ │
│ │ │ Resource Monitor │ │ │
│ │ │ CPU | Mem | Time | IO│ │ │
│ │ └───────────────────────┘ │ │
│ └─────────────────────────────┘ │
│ ┌─────────────────────────────┐ │
│ │ Permission Gateway │ │
│ │ File | Network | System │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
不同沙箱技术的对比：
实际工程实践：
-
代码执行：用 Wasm 沙箱，毫秒级启动，适合频繁的代码运行
-
工具调用：用 Docker 沙箱，提供完整的 Linux 环境
-
文件操作：用 chroot + seccomp 限制文件系统访问
-
网络请求：用网络策略限制可访问的域名和端口
关键设计原则：
-
最小权限：Agent 只获得完成任务所需的最小权限
-
快速失败：超时、超内存立即终止，不等待
-
可审计：沙箱内的所有操作都被记录
-
可恢复：沙箱销毁后，宿主环境不受影响
Q12: 如何将 AI Agent 服务容器化部署到 Kubernetes？请从镜像构建、K8s 编排、GPU 调度三个维度展开。¶
难度：⭐⭐⭐（Agent 服务容器化、多阶段镜像构建、K8s Deployment/Service/HPA 编排、GPU 资源调度（nvidia.com/gpu）、模型文件挂载策略
1️⃣ Common Answer
将 AI Agent 服务容器化部署到 Kubernetes，主要步骤包括：首先使用 Docker 将 Agent 应用打包成镜像，然后在 Kubernetes 中创建 Deployment 进行部署，配置 Service 暴露服务。如果需要使用 GPU，需要在 Pod 中声明 GPU 资源请求。最后通过 HPA 实现自动扩缩容。这样就能实现 Agent 服务的容器化部署和管理。
2️⃣ Impressive Answer
将 AI Agent 服务容器化部署到 Kubernetes，需要从镜像构建、K8s 编排、GPU 调度三个维度系统设计。我按照总分结构展开：
a) 镜像构建策略
多阶段构建是关键。我使用 builder 阶段安装依赖、编译代码，然后使用轻量级的 runtime 阶段运行应用，避免将构建工具带入最终镜像。基础镜像选择 nvidia/cuda:12.1.0-runtime-ubuntu22.04，既包含 CUDA 运行时又保持镜像体积合理。
模型文件绝对不能打进镜像，因为模型文件动辄几 GB 甚至几十 GB，会导致镜像体积过大、拉取缓慢。我采用 PV/PVC 挂载方案，或者用 init container 预先从对象存储下载模型到共享卷。这样模型文件和代码镜像分离，便于独立更新。
镜像分层优化也很重要。将不常变化的依赖层（如 Python 包、系统库）放在前面的 Dockerfile 指令，频繁变化的代码层放在后面，充分利用 Docker 分层缓存机制，加速构建。
b) K8s 编排设计
Deployment 配置是核心。关键配置包括：
-
资源 requests/limits：CPU、内存设置合理配额，GPU 使用
nvidia.com/gpu: 1声明 -
健康检查：livenessProbe 检测进程存活，readinessProbe 等待模型加载完成才标记就绪，避免过早接流量
-
优雅终止：设置 terminationGracePeriodSeconds 给模型卸载留出时间
Service 暴露策略：内部服务使用 ClusterIP，对外暴露通过 Ingress，配置 TLS 证书和域名路由。
HPA 自动扩缩容：基于 CPU/内存指标的基础扩缩容，结合自定义指标（如 QPS、GPU 利用率、请求队列长度）实现更精细的扩缩容策略。
c) GPU 资源调度
NVIDIA Device Plugin 是基础，它将 GPU 资源暴露给 K8s 调度器。GPU 共享方案根据场景选择：单租户独占用 MIG（Multi-Instance GPU），多租户共享用 vGPU 或 GPU 时间片方案。
节点亲和性很重要：使用 nodeSelector 标记 GPU 节点，或者用 nodeAffinity 设置更复杂的调度规则，如优先调度到 GPU 型号匹配的节点。GPU 拓扑感知调度（如 NVIDIA GDS）可以优化跨 GPU 通信性能。
d) 模型加载优化
模型预热通过 readinessProbe 实现：启动脚本先加载模型到 GPU 内存，只有模型加载完成，readinessProbe 才返回成功，Pod 才会加入 Service 端点。
模型缓存避免重复下载：使用 hostPath 或 PVC 缓存模型文件，多个 Pod 共享同一缓存卷，减少对象存储下载压力和启动时间。
关键 Deployment 配置示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: agent-service
spec:
replicas: 3
selector:
matchLabels:
app: agent-service
template:
metadata:
labels:
app: agent-service
spec:
containers:
- name: agent
image: registry.example.com/agent-service:v1.0.0
resources:
requests:
cpu: "2"
memory: "8Gi"
nvidia.com/gpu: 1
limits:
cpu: "4"
memory: "16Gi"
nvidia.com/gpu: 1
volumeMounts:
- name: model-cache
mountPath: /models
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 60
periodSeconds: 5
initContainers:
- name: model-downloader
image: curlimages/curl:latest
command: ["sh", "-c", "curl -o /models/llama-2-7b.gguf https://storage.example.com/models/llama-2-7b.gguf"]
volumeMounts:
- name: model-cache
mountPath: /models
volumes:
- name: model-cache
persistentVolumeClaim:
claimName: model-pvc
nodeSelector:
gpu-type: "a100"
我的实践
电商导购 Agent 项目中，我们将 Agent 服务部署到 K8s，模型使用 LLaMA-2-7B。镜像采用多阶段构建，最终镜像只有 800MB，模型文件（约 15GB）通过 PVC 挂载。使用 init container 从 OSS 下载模型到 PVC，多个 Pod 共享模型缓存，启动时间从 5 分钟降低到 30 秒。HPA 配置基于 QPS 和 GPU 利用率的双指标扩缩容，高峰期自动扩到 20 个副本，GPU 利用率保持在 70-80%，既保证响应速度又控制成本。通过 nodeAffinity 将 Pod 调度到 A100 GPU 节点，避免调度到旧型号 GPU 节点导致性能下降。
3️⃣ Key Differences
Q13: 基于 Kubernetes 架构，如何设计并实现多租户 Agent 场景下的动态隔离与资源分配机制？¶
⭐⭐⭐（Pod 级别沙箱隔离、动态 Pod 创建、NetworkPolicy 网络隔离、沙箱生命周期管理）
1️⃣ Common Answer
使用 Docker 容器为每个 Agent 实例创建独立的运行环境，通过容器隔离技术确保不同 Agent 之间互不干扰。每个 Agent 启动时拉取对应的 Docker 镜像，运行在独立的容器中，容器销毁后自动清理资源。这种方式简单直接，能够满足基本的隔离需求。
2️⃣ Impressive Answer
在 Kubernetes 中为每个 Agent 实例动态分配独立沙箱环境，需要从架构设计、隔离策略、生命周期管理和性能优化四个维度系统化设计。
- 沙箱分配架构
我们采用 Agent Controller + Sandbox Pod 的架构。当收到 Agent 请求时，Controller 通过 Kubernetes API 动态创建一个短生命周期的 Sandbox Pod。每个 Agent 请求对应一个独立的 Pod，Pod 执行完任务后自动销毁。这种方式既保证了隔离性，又具备弹性伸缩能力。
-
四层隔离策略
-
计算隔离：独立 Pod + ResourceQuota 限制 CPU/内存，防止单个 Agent 耗尽集群资源
-
网络隔离：NetworkPolicy 限制 Pod 间通信，只允许 Agent Pod → Sandbox Pod 单向通信，禁止 Sandbox Pod 访问外部网络
-
存储隔离：emptyDir 临时卷，Pod 销毁时自动清理，避免数据残留
-
安全隔离：SecurityContext 多维度加固——runAsNonRoot、readOnlyRootFilesystem、drop ALL capabilities
NetworkPolicy 配置示例：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: sandbox-network-policy
namespace: agent-system
spec:
podSelector:
matchLabels:
app: sandbox-agent
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: agent-controller
ports:
- protocol: TCP
port: 8080
egress: [ ] # 禁止所有出站流量
-
生命周期管理
-
TTL Controller：自动回收超时的 Sandbox Pod
-
activeDeadlineSeconds：设置硬超时时间，防止任务无限期运行
-
preStop hook：优雅终止，确保正在执行的任务能够完成清理工作
-
性能优化
-
Pod 预热池：提前创建一批待命 Sandbox Pod，收到请求时直接复用，冷启动延迟从 15 秒降到 2 秒
-
镜像预拉取：DaemonSet + 预热 Job 在所有节点提前拉取常用镜像
Java K8s Client 创建 Sandbox Pod 的核心代码：
public String createSandboxPod(String agentId, String agentType) {
Pod pod = new PodBuilder()
.withNewMetadata()
.withName("sandbox-" + agentId)
.withNamespace("agent-system")
.addToLabels("app", "sandbox-agent")
.addToLabels("agent-type", agentType)
.endMetadata()
.withNewSpec()
.withContainers(new ContainerBuilder()
.withName("sandbox")
.withImage("sandbox-agent:" + agentType)
.withResources(new ResourceRequirementsBuilder()
.withRequests(Map.of(
"cpu", new Quantity("500m"),
"memory", new Quantity("512Mi")))
.withLimits(Map.of(
"cpu", new Quantity("1000m"),
"memory", new Quantity("1Gi")))
.build())
.withSecurityContext(new SecurityContextBuilder()
.withRunAsNonRoot(true)
.withReadOnlyRootFilesystem(true)
.withCapabilities(new CapabilitiesBuilder()
.withDrop("ALL").build())
.build())
.withVolumeMounts(new VolumeMountBuilder()
.withName("workspace")
.withMountPath("/workspace").build())
.build())
.withVolumes(new VolumeBuilder()
.withName("workspace")
.withNewEmptyDir().endEmptyDir().build())
.withActiveDeadlineSeconds(300L)
.withRestartPolicy("Never")
.endSpec()
.build();
Pod createdPod = kubernetesClient.pods()
.inNamespace("agent-system").create(pod);
return createdPod.getMetadata().getUid();
}
我的实践：电商导购 Clawd Agent 桌面端项目中，我们实现了完整的沙箱隔离体系。通过 NetworkPolicy 限制网络访问，SecurityContext 提升安全性，Pod 预热池将冷启动时间从 15 秒降到 2 秒。同时实现了沙箱资源监控，当 Sandbox Pod 资源使用异常时自动触发告警并强制终止。这套方案支撑了每天 10 万+ 的 Agent 执行任务，资源利用率提升 40%，安全事件降低 90%。
3️⃣ Key Differences
Q14: 在同一个 Kubernetes 集群中混合部署多种类型的 Agent 时，如何设计资源隔离与调度策略？¶
⭐⭐⭐（架构设计类：多 Agent 混合部署、资源隔离、优先级调度、灰度发布、多模型共存）
1️⃣ Common Answer
将不同类型的 Agent 部署到不同的 Namespace 中，通过 Namespace 实现基本的资源隔离。每个 Namespace 有独立的资源配额，避免相互影响。部署时用不同的 Deployment 管理各自的副本数。
2️⃣ Impressive Answer
在同一个 K8s 集群部署多个不同类型的 Agent，需要从资源隔离、调度策略、发布策略和多模型共存四个方面系统化设计。
-
资源隔离方案——三层防护
-
Namespace 隔离：按 Agent 类型划分——
agent-chat（对话型）、agent-code（代码执行型）、agent-data（数据分析型），每个 Namespace 有独立的配额和策略 -
ResourceQuota：为每个 Namespace 设置 CPU/内存/GPU 硬性上限，核心的 agent-chat 分配 50% 资源，实验性的 agent-code 分配 20%
-
LimitRange：限制单个 Pod 的资源范围，避免某个 Agent 实例申请过多资源
-
调度策略——四维调度
-
PriorityClass 优先级调度：核心 Agent（如客服）高优先级，实验性 Agent 低优先级，资源紧张时低优先级 Pod 被抢占
-
节点亲和性：GPU Agent 调度到 GPU 节点，CPU Agent 调度到 CPU 节点，避免资源浪费
-
Pod 反亲和性：同类型 Agent 分散到不同节点，提高高可用性
-
拓扑分布约束（topologySpreadConstraints）：跨可用区均匀分布，提升容灾能力
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: agent-high-priority
value: 1000
globalDefault: false
description: "核心 Agent 高优先级，资源紧张时优先保障"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: agent-low-priority
value: 100
globalDefault: false
description: "实验性 Agent 低优先级，可被抢占"
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: agent-chat-quota
namespace: agent-chat
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
limits.cpu: "40"
limits.memory: 80Gi
nvidia.com/gpu: "4"
pods: "100"
-
发布策略——独立发布、安全上线
-
独立发布、独立回滚：每个 Agent 类型有独立的 Deployment 和 HPA，互不影响
-
金丝雀发布：Argo Rollouts 按比例切流，新版本先发布 10% 流量，观察指标正常后逐步提升到 50%、100%
-
A/B 测试：基于 Header 路由到不同版本（如
X-Agent-Version: v2），并行测试多个版本 -
多模型共存——服务分离
-
模型服务与 Agent 服务分离：Agent → Model Service → 具体模型，多个 Agent 共享同一个模型实例，减少资源占用
-
模型热加载/热切换：通过 API 触发模型更新，更新过程中无缝切换，对业务无感知
我的实践：在实际项目中，我们部署了对话型、桌面操作型、数据分析型三种 Agent。通过 Namespace + ResourceQuota 实现资源隔离，PriorityClass 确保核心对话型 Agent 的优先调度。GPU Agent 使用节点亲和性调度到 A100 节点，CPU Agent 调度到通用节点，资源利用率提升 30%。发布策略采用 Argo Rollouts 金丝雀发布，新版本发布时间从 2 小时缩短到 30 分钟。模型服务分离后，10+ 个 Agent 共享模型资源，模型切换时间从 5 分钟降到 10 秒，系统稳定性提升 50%，资源成本降低 25%。
3️⃣ Key Differences
Q15: Agent 服务的弹性伸缩如何设计？冷启动问题怎么解决？¶
⭐⭐⭐（HPA 自定义指标、KEDA 事件驱动扩缩、冷启动优化、Pod 预热池、缩容保护）
1️⃣ Common Answer
我们会用 Kubernetes 的 HPA 做自动扩缩容，根据 CPU 使用率来调整 Pod 数量。当请求量增加时，HPA 会自动增加副本数，减少时自动缩容。冷启动问题可以通过设置一个最小副本数来缓解，避免完全缩容到零。另外可以优化镜像大小，加快 Pod 启动速度。我们也会用 readiness probe 确保只有完全就绪的 Pod 才会接收流量。
2️⃣ Impressive Answer
Agent 服务的弹性伸缩设计需要从水平扩缩、垂直扩缩、事件驱动、冷启动优化四个维度系统考虑。
- HPA 自定义指标设计
Agent 服务不能用 CPU 做 HPA，因为瓶颈在 GPU、推理延迟和队列深度。我们通过 Prometheus Adapter 暴露自定义指标，包括：QPS、GPU 利用率、请求队列深度、P99 延迟。比如当队列深度超过阈值时触发扩容，P99 延迟过高时提前扩容。
- KEDA 事件驱动扩缩
对于基于消息队列的异步 Agent 任务，用 KEDA 基于 Kafka/RabbitMQ 的积压量触发扩容，比 HPA 更精准。比如 Kafka 消费组 lag 超过 1000 时，KEDA 自动增加 consumer Pod。
- VPA 垂直扩缩
动态调整单 Pod 的 CPU/内存 requests，避免资源浪费。但 VPA 和 HPA 同时使用时要注意冲突，一般建议 HPA 管水平扩缩，VPA 只在非关键环境使用。
-
冷启动优化——四层方案
-
模型预加载：在 readiness probe 中做模型加载，只有加载完成才标记 Ready
-
Pod 预热池（Warm Pool）：维护一批已加载模型的待命 Pod，收到请求直接复用
-
镜像预拉取：用 DaemonSet 在所有节点预拉取镜像，减少镜像下载时间
-
模型缓存：用 PVC 或 hostPath 缓存模型文件，避免每次启动都从 OSS 下载
-
缩容保护
-
cooldownPeriod：避免频繁扩缩
-
minReplicas：保证最小副本数
-
PDB（PodDisruptionBudget）：保护关键 Pod 不被意外驱逐
HPA + Prometheus Adapter 配置示例：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: agent-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: agent-server
minReplicas: 3
maxReplicas: 20
metrics:
- type: Pods
pods:
metric:
name: request_queue_depth
target:
type: AverageValue
averageValue: 50
- type: Pods
pods:
metric:
name: inference_latency_p99
target:
type: AverageValue
averageValue: 500m
behavior:
scaleUp:
stabilizationWindowSeconds: 30
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 10
periodSeconds: 60
我的实践：在 Agent 服务中用 HPA + KEDA 混合扩缩，同步请求用 HPA 基于 P99 延迟扩容，异步任务用 KEDA 基于 Kafka lag 扩容。冷启动方面，用 Warm Pool 维持 3 个最小副本，新 Pod 启动时从 PVC 缓存加载模型，启动时间从 2 分钟降到 20 秒。PDB 保护保证升级时至少 2 个 Pod 可用，避免服务中断。
3️⃣ Key Differences
Q16: Agent 的模型服务部署与推理引擎选型（vLLM / TGI / Triton），你会怎么选？¶
⭐⭐⭐（原理分析类：推理框架对比、Continuous Batching、PagedAttention、模型量化部署、模型并行）
1️⃣ Common Answer
我们会用 vLLM 来部署模型服务，因为它的吞吐量最高。vLLM 支持 PagedAttention 和 Continuous Batching，可以高效处理并发请求。我们也会考虑模型量化，比如用 GPTQ 或 AWQ 来减少显存占用。部署在 Kubernetes 上，用 GPU 节点调度。如果模型太大，可以用 Tensor Parallel 进行模型并行。
2️⃣ Impressive Answer
推理引擎选型需要从核心技术、适用场景、性能优化、部署复杂度四个维度对比分析。
- 三大推理框架对比
-
核心优化技术
-
Continuous Batching：动态合并不同请求的 batch，避免 padding 浪费，提升 GPU 利用率
-
PagedAttention：将 KV cache 分页管理，像虚拟内存一样动态分配，避免内存碎片，显存利用率提升 2-4 倍
-
Speculative Decoding：用小模型预测，大模型验证，加速生成 2-3 倍
-
模型量化
-
GPTQ：4-bit 量化，精度损失小，但推理速度提升有限
-
AWQ：Activation-aware Weight Quantization，4-bit 量化，速度快精度好
-
GGUF：llama.cpp 格式，适合 CPU/边缘部署，精度损失较大
权衡：生产环境推荐 AWQ 4-bit，精度损失 <1%，显存节省 75%，推理速度提升 2-3 倍。
-
模型并行
-
Tensor Parallel：模型层内切分，每个 GPU 存一部分权重，适合大模型（70B+）
-
Pipeline Parallel：模型层间切分，不同层在不同 GPU，适合超长序列
-
选型决策树
-
纯 LLM 推理，追求吞吐 → vLLM
-
快速原型开发，HF 生态 → TGI
-
企业级多模型服务，多模态 → Triton
-
边缘/低资源部署 → GGUF + llama.cpp
vLLM K8s Deployment YAML 示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-agent
spec:
replicas: 3
selector:
matchLabels:
app: vllm-agent
template:
metadata:
labels:
app: vllm-agent
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- --model=meta-llama/Llama-2-7b-chat-hf
- --quantization=awq
- --tensor-parallel-size=1
- --max-model-len=4096
- --gpu-memory-utilization=0.9
resources:
limits:
nvidia.com/gpu: 1
memory: 24Gi
requests:
nvidia.com/gpu: 1
memory: 16Gi
ports:
- containerPort: 8000
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 60
periodSeconds: 10
nodeSelector:
accelerator: nvidia-tesla-a100
我的实践：Agent 服务用 vLLM 部署 Llama-2-7B，AWQ 4-bit 量化，单卡 A100 可支持 200+ 并发，P99 延迟 <500ms。对于多模态 Agent（图像+文本），用 Triton 部署，一个服务同时支持 LLM 和 CLIP 模型。整体架构上，vLLM 处理纯文本推理，Triton 处理多模态任务，通过 API Gateway 统一路由。
3️⃣ Key Differences
Q17: Agent 部署中如何实现零停机发布与回滚？¶
⭐⭐（实战经验类：滚动更新、蓝绿部署、金丝雀发布、Prompt+模型+代码联合发布、自动回滚）
1️⃣ Common Answer
零停机发布主要是用滚动更新，Kubernetes 默认的 Deployment 就支持。配置 maxSurge 和 maxUnavailable 参数，比如 maxSurge=1、maxUnavailable=0，这样每次升级一个 Pod，旧的 Pod 还在运行，新 Pod 启动成功后再杀掉旧的，就能保证服务一直可用。如果发布出问题，手动回滚到上一个版本就行。
2️⃣ Impressive Answer
Agent 的零停机发布比传统服务更复杂，因为涉及三个维度的联合变更：Prompt 模板、模型版本、代码逻辑。任何一个维度出问题都会影响 Agent 的输出质量，所以需要精细的发布策略和自动回滚机制。
- Agent 发布的特殊挑战
传统服务只发布代码，但 Agent 发布需要同步更新 Prompt 模板、模型版本和代码。比如你优化了 Prompt，但模型还是旧版本，效果可能更差；或者代码改了工具调用逻辑，但 Prompt 没适配，会导致工具调用失败。这三个维度必须联合发布、版本绑定。
-
发布策略对比
-
滚动更新：maxSurge/maxUnavailable 控制升级步长，最基础，但新版本有问题时影响面逐步扩大
-
蓝绿部署：两套完整环境切换，回滚快（直接切回蓝环境），但资源占用翻倍
-
金丝雀发布（推荐）：Argo Rollouts 按比例切流 5%→25%→50%→100%，指标异常自动回滚
-
流量镜像：复制生产流量到新版本但不影响实际响应，适合模型效果验证
-
自动回滚机制
Agent 的关键指标：错误率（HTTP 5xx、LLM API 调用失败率 > 5%）、响应延迟（P99 > 3s）、Token 消耗异常飙升。Argo Rollouts 的 AnalysisRun 持续监控这些指标，连续 3 次采样超标就触发自动回滚。
-
Prompt+模型+代码联合发布
-
Prompt 版本化：Git 管理 Prompt 模板，ConfigMap 挂载到 Pod
-
模型版本化：Model Registry（MLflow/HF Hub）管理模型版本
-
发布编排顺序：先更新 Prompt ConfigMap → 再发布代码 Deployment → 最后切换模型版本
-
GitOps：ArgoCD 一次 PR 同时更新三个维度，发布原子化
-
优雅关闭
preStop hook 停止接受新请求 → SIGTERM 信号处理，等待正在处理的请求完成 → 主动关闭连接池、释放资源。
Argo Rollouts 金丝雀 + AnalysisRun YAML 示例：
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: agent-service
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 5
- pause: {duration: 5m}
- analysis:
templates:
- templateName: success-rate
- setWeight: 25
- pause: {duration: 10m}
- setWeight: 50
- pause: {duration: 10m}
- setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
metrics:
- name: success-rate
interval: 1m
count: 5
successCondition: result[0] >= 0.95
failureLimit: 3
provider:
prometheus:
address: http://prometheus.monitoring.svc:9090
query: |
sum(rate(http_requests_total{status=~"2..",service="agent-service"}[5m]))
/
sum(rate(http_requests_total{service="agent-service"}[5m]))
我的实践：之前用滚动更新发布时，新版本 Prompt 漏掉了关键指令，影响了 50% 的 Pod，手动回滚花了 10 分钟。后来改用 Argo Rollouts 金丝雀发布，配置了 HTTP 错误率和 Token 成本两个 AnalysisTemplate。最近一次发布，新模型版本导致 P99 从 2s 涨到 5s，AnalysisTemplate 在 5% 阶段就检测到超标，自动回滚，用户几乎无感知。Prompt 和代码通过 ArgoCD 一次 PR 联合发布，回滚时也一起回滚，避免版本不匹配。
3️⃣ Key Differences
Q18: 如何在 K8s 中部署一个支持长连接/流式输出的 Agent 服务？¶
⭐⭐⭐（实战经验类：SSE/WebSocket 长连接部署、Ingress 超时配置、会话保持、优雅关闭与连接排空）
1️⃣ Common Answer
在 K8s 中部署长连接服务，主要使用 WebSocket 协议。因为 WebSocket 支持双向通信，适合实时交互场景。部署时需要注意配置 Ingress 的超时时间，避免连接被中断。Service 使用 ClusterIP 类型，Deployment 配置多个副本。主要就是确保 WebSocket 连接能够稳定保持，不会因为网络波动或负载均衡策略而频繁断开。
2️⃣ Impressive Answer
在 K8s 中部署支持长连接/流式输出的 Agent 服务，需要从协议选型、Ingress 配置、会话保持、连接管理、优雅关闭五个维度系统设计。
-
流式输出协议选型
-
SSE（Server-Sent Events）：单向推送，适合 LLM token 流式输出，基于 HTTP，穿透性好，浏览器原生支持
-
WebSocket：双向通信，适合交互式 Agent（如用户打断、实时反馈），需要额外处理连接状态
-
gRPC Streaming：内部服务间流式调用，性能高，基于 HTTP/2
对于 LLM 场景，优先选择 SSE，简单且足够；需要用户实时交互的 Agent，使用 WebSocket。
- Ingress 超时配置（关键！）
Nginx Ingress 默认超时 60s，必须显式配置：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: agent-ingress
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
nginx.ingress.kubernetes.io/proxy-buffering: "off"
nginx.ingress.kubernetes.io/proxy-request-buffering: "off"
nginx.ingress.kubernetes.io/websocket-services: "agent-service"
spec:
rules:
- host: agent.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: agent-service
port:
number: 8080
关键注解：
-
proxy-read-timeout：读取后端响应超时，流式输出必须设置 600s+
-
proxy-buffering: off：关闭缓冲，确保流式数据实时推送
-
websocket-services：声明支持 WebSocket 的 Service
-
负载均衡会话保持
长连接需要会话保持，避免请求分发到不同 Pod 导致状态丢失：
apiVersion: v1
kind: Service
metadata:
name: agent-service
spec:
sessionAffinity: ClientIP
sessionAffinityConfig:
clientIP:
timeoutSeconds: 10800
ports:
- port: 8080
targetPort: 8080
selector:
app: agent
-
连接数限制与背压
-
单 Pod 最大连接数限制（如 1000），防止 OOM
-
当连接数达到上限时，返回 503 触发 LB 流量切换
-
通过 Prometheus 监控连接数，超过 800 时触发 HPA 自动扩容
-
优雅关闭
spec:
terminationGracePeriodSeconds: 300
containers:
- name: agent
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 15 && curl -X POST http://localhost:8080/stop"]
优雅关闭流程：
-
K8s 发送 SIGTERM → preStop hook 执行（sleep 15s 等待 Ingress 规则更新）
-
应用标记为不可用，停止接受新连接
-
等待活跃连接完成或超时（GRACEFUL_SHUTDOWN_TIMEOUT）
-
超时后强制退出（terminationGracePeriodSeconds 最长 300s）
我的实践：在 Agent 对话服务中，初期遇到连接频繁断开，排查发现是 Nginx Ingress 默认 60s 超时导致。配置 proxy-read-timeout 为 600s、proxy-buffering: off 后解决。应用层实现心跳机制，30s 无数据自动重连。滚动更新时配置 terminationGracePeriodSeconds 300s 和 preStop hook，实测 99% 的对话能平滑迁移，用户无感知。单 Pod 最大连接数 1000，配合 HPA 自动扩容，连接数超 800 时自动扩容。
3️⃣ Key Differences
Q19: Agent 服务的多环境部署与配置管理（Dev/Staging/Prod）如何设计？¶
⭐⭐（最佳实践类：Helm Chart 模板化、Kustomize 多环境 overlay、ConfigMap/Secret 管理、GitOps）
1️⃣ Common Answer
我们为不同环境准备了不同的配置文件。开发环境用 application-dev.yaml，预发布环境用 application-staging.yaml，生产环境用 application-prod.yaml。每个环境配置不同的数据库连接、Redis 地址和日志级别。部署时通过环境变量或者启动参数指定使用哪个配置文件。K8s 里也会用不同的 ConfigMap 来挂载这些配置文件。
2️⃣ Impressive Answer
Agent 服务的多环境部署有它的特殊性，我主要从环境差异、配置管理、部署流程和模型一致性四个方面设计。
- Agent 多环境的特殊性
和普通微服务不同，Agent 在不同环境需要配置的内容更多元：
-
模型 endpoint 不同：dev 用小模型（GPT-3.5）快速迭代节省成本，prod 用大模型（GPT-4）保证质量
-
Prompt 模板不同：dev 可以用简化版快速验证，prod 用经过 A/B 测试验证的优化版
-
API Key 不同：不同厂商、不同账号的 key 要隔离管理
-
工具列表不同：dev 可以开启调试工具，prod 要关闭并开启安全护栏
-
Helm Chart 模板化部署
templates/ 目录放 Deployment、Service、HPA、ConfigMap 等模板，values/ 目录分环境放 values 文件。一套 Chart，不同环境只要用不同的 values 文件就能部署。
# values-dev.yaml
image:
repository: my-registry.com/agent-service
tag: v1.2.3-dev
replicaCount: 1
config:
modelEndpoint: https://api.openai.com/v1
modelName: gpt-3.5-turbo
enableDebugTools: true
logLevel: DEBUG
# values-prod.yaml
image:
repository: my-registry.com/agent-service
tag: v1.2.3
replicaCount: 3
config:
modelEndpoint: https://api.openai.com/v1
modelName: gpt-4
enableDebugTools: false
logLevel: INFO
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
- Kustomize 多环境 overlay
base/ 放通用 YAML，overlays/dev/staging/prod/ 分别放环境差异：
# overlays/prod/kustomization.yaml
namespace: prod
bases:
- ../../base
patchesStrategicMerge:
- replica-count-patch.yaml
- config-patch.yaml
-
配置管理——三类分治
-
ConfigMap：Prompt 模板、模型 endpoint、Feature Flag（非敏感，可提交 Git）
-
Secret：API Key、数据库密码（敏感，不提交 Git）
-
External Secrets Operator：从 Vault/AWS Secrets Manager 自动同步 Secret 到 K8s
-
GitOps（ArgoCD）
Git 仓库是配置的唯一真实来源。所有环境的配置变更通过 PR 提交，审批通过后合并，ArgoCD 自动检测变更并同步到目标 K8s 集群。prod 环境额外加人工审批 gate。
- 环境间模型版本一致性
Model Registry（MLflow/HF Hub）管理模型版本。dev 验证通过的模型版本打 tag 后 promote 到 staging，staging 验证后再 promote 到 prod，确保每个环境使用的模型版本可追溯。
我的实践：用 Helm + ArgoCD 实现多环境管理。dev 环境自动部署（PR 合并后自动触发），staging 手动触发用于 QA 验证，prod 需要团队 Lead 审批。曾遇到 dev 的 Prompt 更新后忘记同步到 prod 导致线上效果下降，后来引入 ConfigMap 版本管理，用 Git commit hash 作为版本号，部署时强制指定版本，避免了配置不一致。从代码提交到 prod 部署约 30 分钟，大部分时间在等待审批和自动化测试。
3️⃣ Key Differences
Claude Code¶
Claude Code 是什么？和 GitHub Copilot 这类 AI 编程助手有什么本质区别？¶
⭐⭐（Coding Agent 定义、Agentic Loop、工具调用）
Claude Code 是 Anthropic 开发的 AI Coding Agent，不是代码补全工具。
核心区别在于自主性：Copilot 是被动响应——你写代码它补全；Claude Code 是主动执行——它能理解整个代码库上下文、自主规划多步骤任务、调用文件读写/终端命令等高权限工具。
底层跑的是 Agentic Loop：感知（读文件/搜索代码）→ 规划（拆解任务）→ 工具调用（执行操作）→ 观察结果 → 再规划 → 循环直到完成
说白了，Copilot 是"你说一句它说一句"，Claude Code 是"你说目标它自己想怎么做"。
Claude Code 的架构设计哲学是什么？为什么选择"极简架构"？¶
⭐⭐⭐（架构设计、System Prompt 工程、工具驱动）
1️⃣ Common Answer
Claude Code 架构很简单，主要靠提示词驱动，用 TypeScript 写的，通过工具调用来操作文件和终端。
2️⃣ Impressive Answer
我会从三个角度来回答：设计哲学、实现方式、为什么这样选择。
设计哲学是"保持简单"。Anthropic 认为，任何额外的编排层都会让本就难以调试的 LLM 系统更难排查问题。所以 Claude Code 没有复杂的中间件，没有多层 Agent 框架，核心就是一个 CLI 工具直接调 Claude API。
实现方式是"万字 System Prompt + 工具驱动"。大量工程约束、行为规范、边界条件都写进 System Prompt，而不是硬编码成逻辑分支。工具层面提供 Bash 执行、文件读写、代码搜索等原子能力，LLM 自己决定怎么组合。整个代码库约 1884 个 TypeScript 文件，但核心逻辑出奇地薄。
为什么这样选择？因为 LLM 本身就是最好的"编排器"——它能理解自然语言指令、能推理任务依赖、能处理异常情况。把编排逻辑放进 Prompt 比放进代码更灵活，也更容易迭代。
这个设计思路和很多"过度工程化"的 Agent 框架形成了鲜明对比，反而取得了更好的效果。
3️⃣ Key Differences
Claude Code 的 Sub-agent 机制是怎么工作的？如何防止子 Agent 越权？¶
⭐⭐⭐（Sub-agent、任务分解、权限隔离）
1️⃣ Common Answer
Claude Code 可以启动子 Agent 来并行处理任务，主 Agent 负责协调，子 Agent 负责执行具体操作。防止越权就是在 Prompt 里告诉它不能做什么。
2️⃣ Impressive Answer
我从工作机制和安全边界两个角度来说。
工作机制：主 Agent 接到任务后先做分解，识别出哪些子任务是相互独立的，然后并行启动多个 Sub-agent。每个 Sub-agent 是无状态的——它不知道其他 Sub-agent 在做什么，所有上下文都通过 Prompt 传入，结果返回给主 Agent 汇总。这个设计让并行变得安全，因为子 Agent 之间没有共享状态，不会互相干扰。
防止越权的核心是"最小权限 + 明确约束"。在给子 Agent 的 Prompt 里，必须明确写清楚：
-
必须做什么（任务范围）
-
绝对不能做什么（禁止操作，比如不能修改配置文件、不能删除数据）
-
遇到边界情况怎么处理（停下来报告，而不是自行决策）
工具层面也可以做限制——给子 Agent 只开放它需要的工具，比如只读任务就不给写权限的工具。
实际工程中，越权问题最常见的原因不是模型"故意"越权，而是 Prompt 写得不够清晰，子 Agent 在边界情况下"自由发挥"了。
3️⃣ Key Differences
1.2 OpenClaw¶
说说你对 OpenClaw 的理解？¶
简单了解就行，一般不咋问
OpenClaw 是一个开源、本地优先的自主 AI Agent 框架，由 Peter Steinberger 开发，让大模型从"只会聊天"升级为"真正能干活"的智能执行体。它要解决的问题是：
大语言模型只能思考但没法动手干活的问题。OpenClaw 做的事，就是给这个大脑配上完整的"身体"：
-
手脚：操作电脑、调用 API、执行脚本
-
记忆：记住用户偏好和历史会话
-
眼睛：感知环境、抓取网页
-
通讯工具：接入各种消息平台
OpenClaw 的多 Agent 协作模式是怎么设计的？Skill 和 Tool 有什么区别？¶
⭐⭐⭐（Multi-Agent、角色分工、Skill vs Tool）
1️⃣ Common Answer
多 Agent 就是多个 Agent 一起工作，各自负责不同的任务。Skill 是封装好的能力，Tool 是具体的工具调用。
2️⃣ Impressive Answer OpenClaw 的多 Agent 协作模式是一个精心设计的、从“单兵作战”到“团队协作”的范式跃迁，其核心在于通过精细的角色分工和能力扩展机制来解决复杂系统任务。
多 Agent 协作模式设计¶
OpenClaw 的多 Agent 协作并非简单的任务分发，而是基于一套成熟的架构，让多个专业化的 Agent 像一个高效的团队一样工作。
1、核心架构：主从调度 (Orchestrator-Worker) 这是 OpenClaw 多 Agent 协作的核心。系统会设立一个“总指挥”（Orchestrator Agent），它负责理解用户的复杂指令，将其拆解成多个子任务，然后分派给不同的“执行者”（Worker Agent）。
2、 角色分工与职责隔离 每个 Agent 都被赋予特定的角色和职责，并绑定专属的 Skill 集和知识域，避免了能力混杂和冲突。
-
Orchestrator Agent (总指挥): 负责意图解析、任务拆解、分配、结果校验与汇总。
-
Data Agent (数据员): 只负责数据处理，安装了数据查询、清洗、统计等 Skill。
-
Writer Agent (文案): 负责报告生成，安装了摘要、写作、排版等 Skill。
-
Executor Agent (执行员): 负责落地执行，安装了文件操作、邮件发送等 Skill。
3、 协作流程与通信 整个协作过程是高度自动化的：
-
任务编排: 用户发出指令后，Orchestrator 解析并拆解任务。
-
并行执行: 各子任务被分配给对应的 Worker Agent，它们可以并行启动，各自调用专属 Skill 执行。
-
通信机制: Agent 之间通过标准化的消息通道进行通信，OpenClaw 原生支持
sessions_send（向现有会话发送消息）和sessions_spawn（动态创建新 Agent 实例）两种模型，实现了灵活的任务委派和动态扩展。 -
结果汇总: Worker Agent 将执行结果反馈给 Orchestrator，由其进行校验、整合，最终输出给用户。
Skill 与 Tool 的核心区别¶
理解 Skill 和 Tool 最核心的区别在于：Tool 决定“能不能做”，而 Skill 决定“怎么做”。
举个例子： 当用户发出“查询未读邮件”的指令时：
-
SKILL.md它是一份指导文件，告诉 Agent：“遇到查邮件的需求，应该执行list –folder INBOX –unread这条命令”。 -
Tool 是
exec，它是真正去执行这条命令的底层能力。
简单来说，Tool 是能力层，提供了基础的执行单元；Skill 是方法层，通过组合和编排 Tool，赋予了 Agent 解决特定场景问题的智能。
3️⃣ Key Differences
1.3 Hermes Agent¶
Hermes Agent 最大的创新点是什么？Skills 闭环系统是怎么工作的？¶
⭐⭐⭐（自我进化、Skills 闭环、经验积累）
1️⃣ Common Answer
Hermes 最大的特点是能自我进化，它会把做过的任务保存成 Skill，下次遇到类似任务就直接用，不用从头开始。
2️⃣ Impressive Answer
我会从"解决了什么问题"和"怎么解决的"两个角度来说。
解决的问题：传统 Agent 有个根本缺陷——每次执行任务都从零开始，没有记忆，没有积累。做了 100 次部署，第 101 次还是一样慢。Skill 需要人工手写，维护成本高，而且人工写的 Skill 往往覆盖不了真实场景的边界情况。
Hermes 的解法是 Skills 闭环系统，整个流程是：
核心是 7 个模块：经验提取 → Skill 生成 → 向量索引 → 条件激活 → 渐进式加载 → 自改进 → 知识沉淀。
"渐进式加载"是个工程细节，值得单独说：不是把所有 Skill 都塞进上下文，而是按任务语义按需加载，避免上下文爆炸。
3️⃣ Key Differences
Hermes 和 OpenClaw 是什么关系？实际项目里怎么融合使用？¶
⭐⭐⭐（框架融合、定位差异、工程实践）
两者定位不同，可以互补：
-
OpenClaw 是编排框架，解决"多个 Agent 怎么协作"的问题
-
Hermes 是自进化引擎，解决"Agent 怎么从经验中学习"的问题
融合使用的思路：OpenClaw 负责任务编排和 Agent 间协作，Hermes 的 Skills 闭环系统负责把 OpenClaw 执行过的成功路径自动沉淀成 Skill，下次 OpenClaw 编排时直接复用这些 Skill，不用重新规划。
说白了，OpenClaw 是"公司的组织架构"，Hermes 是"公司的知识库系统"——组织架构决定谁做什么，知识库让每个人越做越快。
1.7 综合场景设计题¶
让你从零设计一个"自进化的 Coding Agent"，你会怎么做？¶
⭐⭐⭐⭐（系统设计、Hermes 思想、Claude Code 架构、工程落地）
1️⃣ Common Answer
用 LLM 做核心，加上代码执行工具，让它能读写文件、运行代码。然后把做过的任务记录下来，下次参考。
2️⃣ Impressive Answer
我会从架构分层、核心机制、工程挑战三个角度来设计。
架构分层：
核心机制：
-
Orchestrator：极简架构（Claude Code 思想），核心逻辑放进 System Prompt，不做过度编排
-
Sub-agent 分工：Coding / Test / Review 三个角色化 Agent，各自有专属 System Prompt
-
Skill 提炼引擎：每次任务完成后，自动分析成功路径，提炼成 Markdown Skill 文件（Hermes 思想）
-
渐进式加载：Skill 知识库按语义相关度排序，只加载 Top-K 个，控制上下文长度
工程挑战和解法：
3️⃣ Key Differences