本文从已有面试准备笔记中提取所有 Agent 应用开发相关的高频面试题，剔除过时信息后重新整理作答。涵盖多 Agent 架构、记忆系统、RAG、安全、评估、优化等 12 个主题。

更新日期：2026-07-20

一、多 Agent 系统设计

Q1: 多 Agent 系统如何设计？

多 Agent 系统的核心挑战不是"让多个 Agent 跑起来"，而是如何保证它们协作产出的质量超过单 Agent。如果设计不当，多 Agent 反而会因为上下文割裂、信息衰减和协调开销导致质量下降。

1. 基于 RFC 的任务分解（DAG 化）

入口是一份 RFC/PRD 文档。由 Orchestrator Agent 读取后，将任务拆解为有向无环图（DAG）中的工作单元：

• id + name：唯一标识
• deps：显式依赖关系（只有真实代码依赖才建边，不做虚假依赖）
• acceptance：可验证的验收标准
• tier：复杂度分级（trivial / small / medium / large）

分解铁律：

• 优先产出更少但更聚合的单元（降低 merge 冲突概率）
• 最小化跨单元文件重叠（两个 Agent 不碰同一个文件）
• 测试和实现必须在同一个单元内（绝不分拆"实现 X"+“测试 X”）

2. 分层编排与并行隔离

DAG 决定执行顺序——同层无依赖的单元并行执行，有依赖的等待上游完成后串行推进。每个工作单元运行在独立 worktree 中，保证文件系统级别隔离。

3. 按复杂度分级走质量流水线

4. 消除作者偏差——分窗 Agent

每个阶段跑在独立的 Agent 上下文窗口中。Research、Plan、Implement、Test、Review 各由不同的 Agent 完成，Reviewer 绝不看到 Implementer 的上下文。这从根本上消除"自己写的代码自己审"的盲区。

5. Agent 合并队列

1. Rebase 到 main → 有冲突？捕获完整冲突上下文，驱逐回 implementer
2. 运行全量 build + test → 失败？捕获失败日志，驱逐
3. 通过 → Fast-forward 合入

驱逐不是盲重试——每次都携带完整冲突上下文做智能修复。

6. 跨迭代上下文桥接

通过 SHARED_TASK_NOTES.md 在迭代间传递进度、已知陷阱和下一步方向。

Q2: 多 Agent 协作有哪些主流架构模式？如何选型？

四种协作架构

Agent 间通信

Agent 间传递结构化消息（sender/receiver/msg_type/task/payload/constraints），不传自由文本。推荐使用共享状态池（SharedState）：所有 Agent 读写同一状态对象，各 Agent 只读需要的字段、只写负责的字段。

拆多少 Agent？

• 拆分甜区：3~5 个。超过 7 个要警惕通信开销 > 分工收益
• 工具 < 5 个、流程固定、同领域 → 单 Agent + 多工具足够
• 工具 > 10 个、需要交叉验证、中间结果多 → 多 Agent

Q3: 多 Agent MVP 项目怎么开发？

四个阶段

Phase 0：范围收敛（最关键） 对每个 feature 问：“没有这个，用户无法完成核心任务吗？” → 砍到只剩 YES。输出 MVP_SPEC.md。

Phase 1：任务分解 大模块 → 子任务（2-4 小时粒度）→ 依赖关系图。每个任务必须独立可验证。输出 PLAN.md。

Phase 2：Subagent-Driven 执行循环

1
2
3
4
5
6

[主控 Controller]
  └─ 读 PLAN.md → 串行执行每个任务：
       ① 实现 Agent（TDD + 自我 review + commit）
       ② Spec 检查 Agent（spec 合规，不多不少）
       ③ 质量检查 Agent（仅在 Spec ✅ 后）
       ④ 任务标记完成 → 下一任务

Phase 3：收尾与验收 最终 Code Review Agent 全局 review + 完整测试。

关键规则

• 绝对不并行实现任务 —— 并发写同模块必然冲突
• 实现 Agent 不读历史会话 —— Controller 精确注入，不继承脏历史
• Spec 检查放在质量检查前 —— 顺序不能乱
• 每个子 Agent 独立超时 + 降级策略，一个挂了不拖垮全局

二、Agent 记忆系统

Q4: Agent 知识闭环中，如何决定哪些信息进入向量数据库（长期记忆）、上下文窗口（短期记忆）、模型权重（元记忆）？

三层记忆的决策维度

短期记忆（上下文窗口）

• 准入：当前轮直接输入 / 正在执行的 CoT 暂存 / 工具调用中间结果 / RAG 召回的 Top-K 片段
• 移出：对话轮次超阈值或任务结束 → 交由记忆管理器提炼

长期记忆（向量数据库）

• 准入：历史对话归档（经 Summarization 后向量化）/ 用户偏好与实体 / 高频事实知识点
• 工程要点：需配合知识图谱或混合检索（向量+关键词），解决单纯向量检索的逻辑断层

元记忆（模型权重）

• 准入：通用推理范式 / 工具调用语法 / 领域基座知识 / 价值观与语气
• 更新机制：当高频调用的知识或高质量交互轨迹积累到足够量级 → 触发持续微调（如 LoRA）

动态流转闭环

1
2
3
4
5
6

上下文窗口（完成任务）
  → 异步抽取事实 + 压缩对话
  → 向量数据库（积累知识）
  → 监控检索频率：高频知识触发微调
  → 模型权重（内化为本能）
  → 释放上下文窗口空间

Q5: Agent 记忆系统工程上如何设计？短期记忆和长期记忆各自存在哪？

记忆分层架构

工作记忆管理

• 滑动窗口：保留最近 N 轮，最简单但会丢关键上下文
• 摘要压缩：超过阈值时用 LLM 将旧对话压缩为摘要，压缩比约 5:1~10:1
• 分层注入：System Prompt（常驻）+ 摘要（半常驻）+ 最近 K 轮原文（滑动）+ 检索结果（按需）
• Attention Sink 保护：System Prompt 的前几个 token 是注意力锚点，绝不可被截断。推荐策略为首尾保留 + 中间压缩（Head + Tail + Compressed Middle）

短期记忆（Session Memory）

• 存储位置：简单方案用内存 List[Message]，工程方案用 Redis/DynamoDB/SQLite，以 session_id 为 key
• Scratchpad（草稿板）：Agent 内部推理区域，存放中间推理、子目标分解、工具调用计划
• 任务栈：跟踪当前任务、子任务、已完成步骤，防止 Agent 迷失方向
• 压缩触发：Token 计数 > 0.7 × context_window 或每 N 轮
• 关键坑：压缩前必须做 fact extraction，用户硬约束单独存储不参与压缩

长期记忆（Persistent Memory）

• 存储选型：PostgreSQL + pgvector（中小规模）、专用向量库（Qdrant/Milvus/Weaviate）+ KV Store
• 写入时机：会话结束时提取摘要 + facts / 用户显式指令 / 隐式学习（检测到反复纠正 → 提取经验规则）
• 更新与清理：覆盖更新 + 矛盾检测 + TTL 过期 + LRU 淘汰 + 语义去重（embedding 相似度 > 0.95 合并）+ LLM 定期整理
• 检索注入：用户新消息 → 向量化 → 长期记忆检索 top-K → 注入 Context → LLM 推理

设计原则

• 记忆有成本——不是越多越好
• 写入要克制，检索要精准
• 压缩 ≠ 丢弃——硬约束不能丢
• 矛盾检测必须有——否则 Agent 新旧信息冲突
• Letta（前 MemGPT）将 Context Window 类比虚拟内存，Agent 自主决定记忆换入换出，这是一种值得参考的设计范式

三、Agent 安全与稳定性

Q6: Agent 的安全护栏怎么做？安全模型如何选型？

分层防御架构

安全模型选型原则

• 轻量分类器（<1ms，精度~85%）：适合超高 QPS + 预算受限场景
• 专用安全模型（_{20ms GPU，精度}95%）：推荐方案——专为安全分类训练，推荐使用 MLCommons 标准对齐的模型
• 外部 API（~100ms）：不想自建时使用
• 主模型自审（+500ms~2s）：语境理解最深，适合高风险领域（医疗/金融）

关键设计原则

• 每一层独立防御，不依赖其他层
• 安全模型必须和主模型异构——同模型做审查，被 jailbreak 后审查也失效
• 输入审查 + 输出审查缺一不可
• Agent 最大风险不是"说错话"而是**“做错事”**——工具调用审计（L4）是 Agent 区别于 chatbot 的最关键安全层
• 未知工具默认最高风险级别
• 常见踩坑：只靠 System Prompt = 裸奔；做了输入审查漏了输出审查；安全模型和主模型同源

Q7: Agent 循环终止条件怎么设计？如何避免死循环？

根因分类

• 工具幻觉循环：反复调用同一工具但输出不变，无限 retry
• 目标漂移循环：每轮生成新子目标，永远无法收敛
• 自我验证循环：修复→验证失败→再修复，陷入振荡

四层防御体系

1. 硬性计数器：MAX_STEPS / MAX_TOOL_CALLS / MAX_SAME_TOOL，兜底红线，不可软化
2. 语义去重检测：对 (action, observation) 做 embedding 相似度检测，连续 3 步相似度 > 0.95 → 强制打断
3. 目标收敛性验证：每 N 步让 LLM 自评进展是否有效，stuck → replanning（不是 retry）
4. 时间熔断：asyncio.timeout，超时返回 partial_result 而非空结果

特殊 Case：代码修复振荡

模式：修复 test_A → 破坏 test_B → 修复 test_B → 破坏 test_A → 无限循环

解法：引入变更集去重——检测文件版本的回滚模式（v0 → v1 → v0），一旦检测到，强制从"单点修复"升级为"全量依赖图分析"策略。

设计原则

• 硬限制不可协商，MAX_STEPS 是红线不是建议
• stuck ≠ retry，stuck = replan（换方向，不是加力推同一面墙）
• 语义层面去重比计数更有效
• 熔断时返回 partial_result，优于空手而回

Q8: 工具调用失败时如何优雅降级？

失败类型拆分

降级方式

1. 换备选工具
2. 缩小目标：拿不到完整数据，返回已确认的部分数据
3. 改用已有信息回答：坦白"查不到"，基于上下文给出有限回答
4. 改查询策略再试一次：换参数、改关键词、改过滤条件

工程侧关键设计

结构化错误返回：

1
2
3
4
5
6

ToolResult {
  status: success|warning|error
  error_message: 可操作的错误描述
  fallback_hint: "建议改用 X 工具或缩小查询范围"
  retry_allowed: true|false
}

分级重试策略：按工具配置 max_retries + 指数退避 + fallback 工具链。

幂等性保障：有副作用的操作（send_email/delete/write）绝不重试，或引入幂等键防重复执行。

Prompt 侧预编程降级

• 硬失败：最多重试 2 次 → 尝试备选 → 坦诚告知 + 基于已有信息回答
• 空值：不重试同参数 → 改写查询再试一次 → 仍空则如实反馈
• 部分成功：使用已有数据，标注哪些已验证/哪些是推测

最大坑

• 把"空值"当"失败"处理 → 无意义重试循环
• 非幂等操作重试 → 重复发邮件/重复下单

Q9: Agent 系统如何实现可观测性？

Agent 可观测性的特殊挑战

传统系统：输入/逻辑/输出确定。Agent 系统：四重不确定（输入 × 决策 × 工具调用 × 输出），“bug"不是代码报错而是决策质量下降。

可观测性体系

Metrics（指标）：

• 运维指标：延迟 p50/p95/p99、Token 消耗、工具调用次数和错误率、推理循环次数、单次成本
• 质量指标（Agent 专属）：幻觉率、引用准确率、工具选择正确率、回答相关性、检索空结果率

Structured Event Log：

• 结构化事件序列（非文本日志），每个事件为 JSON
• 关键：decision_made 事件记录 Agent 每个决策点的推理和备选方案

Agent Trace（决策链追踪）：

• 追踪完整思考和行动链：query_understanding → retrieval → decision_point → action → answer_generation → validation
• 推荐工具：Langfuse（轻量开源）、Phoenix/Arize（通用）、OpenTelemetry（自建）

稳定性五道防线

1. 输入防御：长度限制 + Prompt Injection 检测 + 速率限制 + 意图可行性预判
2. 执行熔断：max_steps / max_tool_calls / max_llm_calls / max_tokens_total / timeout
3. 输出校验：安全审查 + 幻觉检测 + 引用一致性 + 置信度标注
4. 降级策略矩阵：LLM 不可用→缓存/降级模型，检索不可用→纯结构化查询，全不可用→静态 FAQ
5. 灰度发布 + 回滚：Prompt 版本管理，5% 流量灰度，指标异常一键回滚

可观测性成熟度

• L0：基础日志——“在运行吗？”
• L1：结构化事件+指标——“哪个环节慢？”
• L2：Agent Trace+决策审计——“为什么做了这个决策？”
• L3：质量指标+告警——“回答质量是否下降？”
• L4：Session Replay+根因分析——“这个 case 为什么错？同类有多少？”
• 生产至少 L2，目标 L3，L4 是竞争优势

四、RAG 系统

Q10: 混合检索中 BM25 与向量检索如何融合？权重怎么设定？

为什么要混合

BM25 擅长精确关键词/专有名词匹配，向量检索擅长同义词/语义意图理解。两者信号正交互补。

三种融合方式

1. Score-level 加权融合：final = α × norm(bm25) + (1-α) × norm(vector)，需要分数归一化
2. RRF（Reciprocal Rank Fusion）：score = Σ 1/(k + rank_i)，k 通常取 60。不依赖分数分布，工业界最稳方案
3. Learned 融合：BM25 top-K ∪ Vector top-K → Cross-Encoder Rerank，权重由模型隐式学习

权重设定方法

• 经验起点：α ∈ [0.3, 0.5]（BM25 权重），语义占主导
• 有标注数据时 Grid Search 扫 α
• 无标注数据时 RRF 是最佳选择，对超参不敏感
• Query-adaptive：按 query 类型动态调权（关键词型 → BM25 高，自然语言型 → 向量高）

关键结论

• RRF 是"懒人最优解”，主流向量数据库（Elasticsearch 8.x+、Qdrant、Weaviate、Milvus）都内置支持
• α 最优值高度依赖 query 分布，无万能值
• 精度要求高 + latency 允许 → Cross-Encoder Rerank 是最终答案

Q11: Cross-Encoder 在 Rerank 中的作用？相比 Bi-Encoder 优劣势？

核心区别

• Bi-Encoder（双塔）：Query 和 Doc 独立编码为向量，做点积/余弦相似度。Doc 向量可离线预计算，速度极快。但所有语义压到一个向量，丢失细粒度交互。
• Cross-Encoder（交叉编码器）：Query 和 Doc 拼接后联合编码，每层 self-attention 都做 query-doc token 级交互。语义理解深，但每个 pair 都要完整 forward，不可预计算。

Cross-Encoder 精度更高的根因

• Bi-Encoder 的信息瓶颈：所有语义压到一个固定维度向量
• Cross-Encoder 无瓶颈：token 级全交叉注意力，能理解否定语义、条件约束、细粒度匹配
• 示例：查询"室温下抗拉强度超过 500MPa 的铝合金"时，Cross-Encoder 能区分温度条件不匹配的文档，Bi-Encoder 很难做到

代价对比

检索-重排 Pipeline

全库 → Stage 1 粗召回（BM25 + Bi-Encoder, top-100）→ Stage 2 精排（Cross-Encoder, top-10）→ Stage 3 业务规则/多样性过滤 → 最终 Top-K

选型原则

• 候选数控制在 20~50 个是甜区
• 各 pair 独立，天然可 GPU 并行 batch 推理
• Late Interaction（ColBERT 思路）是精度与速度的折中方案

Q12: 召回效果怎么测试？优化优先级是什么？

召回测试指标

• Recall@K：top-K 覆盖了多少相关文档（召回阶段核心指标）
• Hit Rate@K：至少命中 1 个相关文档的 query 占比
• 召回阶段追求 Recall（不漏），不是 Precision（不错）——漏召了 Rerank 救不回来

测试集构建（三类难度）

• 精确查询 → 关键词精确匹配
• 语义改写 → 同义词理解
• 跨表述 → 泛化 + 领域知识

召回问题诊断（逐层排查）

原始文档 → 切分 → 编码 → 索引 → 检索策略，每层有对应诊断方法。

优化优先级（ROI 从高到低）

1. Chunk 切分策略（ROI 最高）：切分是后续所有步骤的基础。推荐 512 tokens + 12.5% 重叠 + 结构感知切分（表格整表不切）
2. Query 改写/扩展：同义词扩展、HyDE（假想答案向量检索）、多路查询
3. Embedding 模型升级：领域微调用 5000~10000 对数据 + MultipleNegativesRankingLoss
4. 索引参数调优：通常不是瓶颈，快速检查即可

设计原则

• Recall 是召回阶段唯一目标——漏召不可逆
• 先诊断再优化——不要上来就换模型
• 先修数据 → 再调策略 → 最后换模型——ROI 递减
• Bad Case 驱动优化——线上真实失败 case 最有价值

Q13: RAG 工程最大的坑是什么？

问题严重度排名

1. 幻觉（最致命）：引用格式正确但内容失真，用户无法分辨
2. 召回沉默失败：系统不报错但答案基于错误文档，比"我不知道"更危险
3. 上下文污染：多文档矛盾时 LLM 随机选择或错误合并
4. 延迟不可控：LLM 生成占 90%+ 延迟
5. 数据新鲜度：知识库腐烂，返回过时信息

幻觉防御（三层）

• Prompt 硬约束：数值必须标注来源、不同来源数据禁止跨条件组合
• 结构化输出 + 溯源：每个声明关联 source_id + raw_sentence，可自动比对
• 输出校验：自动检查来源是否存在、原文是否在文档中、数值是否一致

召回沉默失败防御

• 检索结果整体相关性自检（max_sim < threshold → 触发"我不知道"）
• Query-Doc 关键实体对齐
• Prompt 嵌入自检指令

RAG 工程"铁三角"

数据质量（地基）→ 检索精度（管道）→ 生成可控性（龙头）

优先级永远是：数据 > 检索 > 生成。大部分团队在生成端调 Prompt 投入过多，回头修数据和检索的 ROI 高得多。

Q14: Rerank 效果怎么评估？NDCG 和 MRR 的区别？

核心指标对比

NDCG@K 详解

• DCG@K = Σ (2^rel_i - 1) / log₂(i+1)，位置越靠前权重越大
• NDCG@K = DCG@K / IDCG@K，归一化到 [0,1]
• 支持多级相关性标注（0-3 分），区分粒度远优于二值指标

评估数据集构建

• 人工标注（金标准）：200~500 条 query，每条 top-50 候选，0-3 级打分
• LLM 辅助标注（降本）：必须人工抽检 10~20%
• 隐式反馈（零成本）：用户点击行为，适合线上持续评估，噪声大

Rerank 前后典型提升

• BM25 only → NDCG@10 ~0.35
• • Vector hybrid → ~0.42
• • Cross-Encoder Rerank → ~0.50

使用 paired t-test 或 Wilcoxon signed-rank test 验证显著性（p < 0.05）。

端到端评估

离线排序指标好 ≠ 最终回答好。需同时评估 Answer Faithfulness / Relevance（LLM-as-Judge）、Context Precision / Recall。推荐框架：ragas。

五、工具与协议

Q15: MCP 与传统 Agent Skills 的区别？

MCP（Model Context Protocol）由 Anthropic 提出，已逐渐成为 Agent 工具交互的行业标准。核心区别：

跨协议工具动态发现与注册

核心架构：Agent Tool Registry & Gateway

1. 适配层（Universal Tool Gateway）：将 REST/gRPC/GraphQL 等异构协议统一转换为 MCP 或标准 Function Calling 格式
2. 注册层（Tool Registry）：工具元数据（name/description/schema/tags）+ Embedding 向量化存入向量数据库
3. 发现层（Dynamic Discovery）：Agent 收到复杂 Query → 向 Registry 发语义搜索 → 动态匹配相关工具 → 热加载 Schema → 调用
4. 执行与反馈层：跨 Agent 调用可封装为黑盒 API、工具健康度监控与降级

核心思想：Agent 不预装所有工具，而是按需发现和加载。一个模糊的用户请求（如"预算 5000 给老婆买礼物，她在玩单机大作"）→ Agent 语义搜索 Registry → 动态发现"游戏设备推荐 + 库存查询 + 物流时效"三个工具 → 加载并执行。

六、Agent 评估与优化

Q16: Agent 的评估流怎么设计？

遵循 Eval-First Loop 方法论：在写代码之前，先定义"什么叫做完"和"什么叫做对了"。

双层 Eval

• Capability Eval：针对新功能的验收用例（正常路径 + 边界条件 + 异常输入）
• Regression Eval：所有已有功能的测试套件（防止回退）

执行流程

1. 跑基线，记录失败签名（失败类型 + 根因假设 + 最小复现步骤）
2. 实现 Agent 按计划执行，每次变更后自动触发 eval 重跑
3. Delta 分析：修复了哪些 regression？引入了哪些？
4. 结构化观察：每个工具调用返回 status + summary + next_actions + artifacts

核心追踪指标

• completion rate（任务完成率）
• pass@1 / pass@3（一次/三次内通过率）
• retries per task
• cost per successful task
• failure class distribution（用于定位系统性问题）

Q17: 如何优化 Agent，提高任务完成率？

优化 Agent 不是调 prompt 玄学，是按四个维度系统性排查：

维度一：Action Space（动作空间）

• 粒度调优：高风险操作用 micro-tool，中频操作用 medium-tool，只在 round-trip 开销成为瓶颈时用 macro-tool
• 消除语义重叠：两个名字不同但能力相似的 tool 会让 Agent 犹豫
• 输出确定性：每个 tool 的返回 shape 必须稳定

维度二：Observation Quality（观察质量）

• 所有工具输出统一为 status + summary + next_actions + artifacts
• 错误返回必须包含可操作的恢复信息，不是只抛 error code
• 减少噪音：日志输出只保留对决策有用的信息

维度三：Error Recovery（错误恢复）——最大杠杆

• 建立失败模式分类体系，每个分类有预设恢复策略
• **自省调试（Introspection Debugging）**四阶段：
  1. Failure Capture：精确记录错误类型、最后成功步骤、环境假设
  2. Root-Cause Diagnosis：匹配已知失败模式
  3. Contained Recovery：用最小的可逆操作验证诊断
  4. 三次尝试仍无进展 → 止损升级，向人类报告完整诊断链
• 每种重试都有明确的停止条件

维度四：Context Budget（上下文预算）

• 系统 prompt 最小化且不变，大段指导放到按需加载的 skill
• Phase 边界做上下文压缩
• 大文件用 reference 而非 inline
• Lost-in-the-middle 效应是真实存在的，信息密度比信息量重要

进阶手段

• 模型路由：按任务复杂度选择合适模型（简单分类用小模型，架构分析用强模型），不在简单任务上浪费昂贵模型
• De-Sloppify 模式：Implementer 充分实现 + Cleanup Agent 专门精简，两个聚焦的 Agent 胜过三个被约束的 Agent
• Verification Loop：每次变更后自动跑构建+lint+测试，验证结果作为下一个步骤的输入

实战思路

不是从"改 prompt"开始，而是先看数据：哪类任务完成率最低？失败集中在哪个阶段？工具调用错误、逻辑推理错误还是环境问题？数据定位瓶颈，再用针对性手段解决。这是工程师的做法，不是 prompt engineer 的做法。

Q18: Critical Agent（评价 Agent）怎么设计？

模型选择 —— 不能省

LLM-as-Judge 的系统性偏差：

• Sycophancy bias：较弱模型倾向于认为输出"看起来不错"而通过
• Verbosity bias：更长的输出被认为更好
• Self-enhancement bias：同模型评价自己产出时倾向于赞同

结论：便宜 Judge = 质量门失效。实现 Agent 可以省，评价 Agent 不能省。

Prompt 设计原则

核心：把判断转化为核查清单，不要开放式评价。

• 提供 Spec + 实现 + 证据三件套，缺一不可
• 强制先推理后结论（CoT before verdict）
• 显式校准语：“保守判断”、“需要证据” —— 对抗 sycophancy
• 维度分离：Spec 合规 vs 质量是两个独立评价

四层评价体系（层级越高越可靠）

失败分类与响应

1
2
3
4
5

SPEC_MISMATCH    → 重新澄清 spec，重派实现 Agent
INCOMPLETE       → 把缺失部分拆成新任务
QUALITY_FAILURE  → 派 fix Agent 针对性修复
PROCESS_FAILURE  → 修复流程违规
EXECUTION_FAILURE → 升级模型 or 人工介入，不盲目重试

七、Harness Engineering

Q19: 给 Agent 加约束应该"多多益善"还是"只设必要边界"？

不应该多多益善。约束叠加边际效益递减，但复杂度成本是乘法的。

两种失败模式决定边界

结构性失败（来自架构本身，scaling 无法消除）

• Attention sink、lost-in-middle、entropy collapse
• 这类约束是合理的 —— 有明确物理意义

能力性不足（训练/数据不足，随模型迭代改善）

• 不会用工具、不会拆步骤、不会自我纠错
• 很多 Agent 框架填补的是这类 gap
• 模型进化后，这些 harness 就成了技术债

边界判断标准

该加约束：

• 针对不会随 scaling 消失的结构性失败
• 有可观测、量化的信号驱动
• 约束是 adaptive 的，不干涉模型本身的泛化能力

不该加约束：

• 在修补症状而非根因
• 约束是静态的，不随 context 动态调整
• 多个约束互相干涉，制造新的脆弱点

实操原则

1. 先测基线 —— 去掉 harness 之后 delta 是否值得其复杂度？
2. 信号驱动 —— 约束触发必须有量化信号，不要凭直觉硬编码
3. 保留卸载路径 —— 每个约束加入时就想好"如何移除"
4. 最少惊喜原则 —— 约束不能比模型原生行为更不可预测

Q20: Skill 开发有什么方法论？

Skill 的本质

Skill 是契约（输入契约、行为契约、输出契约），不是 Prompt 堆砌。决定 Agent 上限的是边界设计，不是步骤数量。

五大设计原则

1. 单一触发、单一职责：一个 Skill 做一件事
2. 触发条件可判定：像正则一样明确
3. 显式声明 DO NOT：不做什么比做什么更重要
4. 输出格式刚性约束：不写死格式，下游没法可靠消费
5. 上下文最小充分：指导精准获取，不贪婪加载

开发工作流

1. 用例故事先行：写 3-5 个正例 + 反例，反例定义边界
2. 最小可用版本：先 20 行跑一遍，别上来就写 200 行
3. 失败驱动迭代：根据症状定位根因
4. 反测试验证：喂不该触发的输入，验证确实不激活

Skill 成熟度模型

• L0 原始 → L1 结构化 → L2 边界清晰 → L3 可组合 → L4 生产级
• 大多数卡在 L1→L2：因为画边界不如加功能有成就感

核心认知

Skill 设计 = 微服务设计：高内聚、低耦合、显式契约、明确边界。唯一区别：微服务靠代码强制边界，Skill 靠语言描述——执行者是会自由发挥的 LLM，所以必须写得更精确。

Q21: 大模型辅助开发效率提升有哪些实践？

使用场景 ROI 排序

• ⭐⭐⭐⭐⭐ 样板代码生成（数据类/CRUD/测试用例）5~10x
• ⭐⭐⭐⭐⭐ Debug 辅助（报错信息→修复方案）3~5x
• ⭐⭐⭐⭐ 代码理解（读陌生代码库）3~5x
• ⭐⭐⭐⭐ 文档/注释生成 3x
• ⭐⭐⭐ 架构讨论（当橡皮鸭）2x
• ⭐⭐ 复杂算法实现（框架可用但细节需审）1.5x
• ⭐ 核心业务逻辑（不理解业务上下文）1x 甚至负

高效使用模式

1. 给现有代码风格 + 新需求 → LLM 生成初版 → review 修改
2. 报错信息直接喂 LLM：附带上下文（代码片段 + 环境 + 已试方案）
3. 代码审查辅助：重点关注边界条件、空值处理、并发安全
4. 测试用例生成：给实现代码 → 生成覆盖 happy path + edge case 的测试
5. Meta-prompting：用 LLM 帮优化 Prompt

教训和红线

• 盲信 LLM 代码是最大的坑 —— 必须 100% review，尤其边界条件和并发
• LLM 做不了需要权衡的架构决策 —— 它是执行工具不是决策者
• 上下文给太少 → 输出质量差；Prompt 太长 → LLM 选择性忽略。拆成多步更好
• 红线：安全代码、线上 DB 操作、不理解就用、替代人工审查

核心认知

• LLM 是放大器不是替代器——放大已有能力，不替代缺失知识
• ROI 最高：“结构清楚但写起来无聊"的代码
• ROI 最低：“需要深度领域知识和权衡判断"的工作
• LLM 生成的代码 = 初级工程师的初稿——需要 senior review

附录：本文与原文对照

本文整合自以下笔记，剔除了过时内容并重新作答：

主要剔除/更新的过时内容：

1. Context Window 上限从 “200K” 更新为反映 2026 年主流模型普遍支持 128K~1M+ tokens 的现状
2. 具体模型版本号（如 “Llama Guard 3 (1B)"、“bge-m3”、“Cohere Rerank v3”）→ 泛化为原理性选型指导
3. “MemGPT” → 更新为 Letta 的发展现状
4. 部分时间敏感的框架引用 → 替换为更稳定的架构描述