LLM 使用能力提升（通用向）：由浅入深与完整 Agent 维度

Posted on In Word count in article: 6.6k Reading time ≈ 6 mins.

本文从底层约束出发，系统整理日常对话中的 Prompt 设计、完整 Agent 维度模型（说明为何仅有 Soul / Memory / Skill 仍不足）、多 Agent 编排与编码 Agent 的实战技巧，并补充知识库与文档组织的通用原则。适用于产品、研发与个人使用者，不绑定某一款 IDE 或编排框架。

English abstract: A systematic playbook for LLM and agent use: why techniques work under limited context, prompt design by depth, a ten-dimension agent model (beyond persona/memory/skills), multi-agent orchestration patterns and contracts, coding-agent practices, and documentation layout tradeoffs—framework-agnostic.

1. 底层约束：为什么这些技巧真的有用

大模型在交互中近似满足三条硬约束，理解它们能避免“玄学化”提示词。

1.1 上下文有限且近似线性

模型主要依赖本轮注入的文本（用户输入、系统提示、检索片段、工具返回等）。上下文窗口再大，也不是对整个世界或整个代码库的随机访问器；远距离的关键指令若被大量中间内容包围，被遵循的概率会下降。因此技巧的核心之一是信噪比：把硬约束放在稳定可见的位置，把噪声（无关历史、重复全文）压下去。

1.2 知识有边界，需要接地

预训练知识会过期（库版本、API、法规、事实）。可靠输出依赖 grounding（接地）：权威文档、运行结果、锁文件、工单、用户提供的片段等。没有接地时，模型会“合理编造”，这在开放聊天里尚可接受，在工具调用、合规、工程变更里往往是事故源。

1.3 Agent 不只是“更会聊天的模型”

Agent ≈ 模型 + 控制循环 + 环境接口。仅有好的人设、记忆词条、流程说明，若缺少目标与停止条件、工具权限、观测与验收，仍会出现：不知道何时停、重复无效尝试、越权调用、长任务漂移等问题。

小结（技巧目标）：提高信噪比与可检索性；让结论可验证；把“说明书层、运行时层、治理层”分开设计（后文展开）。

2. 由浅入深：日常对话与 Prompt 设计

2.1 基础：立刻能用的结构

  • 任务三元组：目标（要达成什么）+ 输入（已知材料、范围）+ 成功标准（怎样算完成）。例：总结附件中的三点风险；输入是三页 PDF；成功标准是每条风险有页码依据且不超过 200 字。
  • 约束显式化：输出语言、长度、格式（表格/列表）、是否允许推测、是否必须引用原文。
  • 复杂任务分相：先 对齐理解与计划（或只分析不改），再进入执行。可显著减少“一上来就改错方向”的沉没成本。

2.2 进阶：提高稳定性

  • 规范优于空泛角色：“你是资深架构师”不如“输出必须包含：假设、方案对比表、推荐项与理由、风险与回滚”。可执行规则比人设标签更稳。
  • 结构化输入：用标题、编号、示例；边界情况单独列出（“若数据缺失则……”）。
  • 失败时升级信息：不要只写“不对”；提供完整错误信息、已尝试步骤、相关片段。模型在信息不足时只能猜，猜错会表现为“自信胡说”。

2.3 高阶：多轮与协作

  • 阶段切换时重申目标：长对话中人类也会忘，模型更容易丢线程；每进入新阶段用三句话复述剩余目标与约束。
  • 显式优先级：当约束冲突时谁优先（常见顺序：安全 / 合规 > 正确性 > 可用性 > 成本 > 篇幅），写清楚可避免模型在中间摇摆。
  • 自检清单：要求列出假设、风险、待你确认的问题再动手，适合大改动或不可逆操作前。

3. Soul、Memory、Skill 是否足够定义一个 Agent？

3.1 结论：不够，但三者很重要

在许多产品或社区讨论里，会用近似概念描述静态配置：

概念 常见含义 典型内容
Soul（人格 / 原则） 稳定的语气、价值排序、协作风格 简洁/详尽偏好、礼貌边界、输出语言策略、写作风格
Memory（记忆） 跨会话仍应成立的事实与偏好 用户职业、常用技术栈、项目约定、禁忌
Skill（技能） 可重复的 SOP、检查单、模板 发布流程、代码评审清单、某类文档的结构模板

它们覆盖了 Agent 的静态说明书中很大一块，但一个可依赖的 Agent 系统还需要：

  • 目标与完成定义（何时停、验收标准）
  • 策略与安全（能做什么、预算、隐私、权限——与“语气”不同）
  • 工作记忆与上下文策略（本轮笔记、摘要、窗口管理）
  • 工具与环境（可调用的动作、错误形态、状态可见性）
  • 接地与知识源治理（RAG、文档版本、与 Memory 的边界）
  • 控制循环（计划—执行—观测—修正、重试与退避）
  • 评估与反馈（自动校验、人审、失败反哺文档或技能）

缺少这些，常见失败模式包括：能做但不知何时停、工具越权、把检索片段当唯一真理、长任务失忆或口径漂移。

可粗略分成三层：

  • 说明书层：Soul、Memory、Skills、部分 Policies 的成文描述
  • 运行时层：Goals、Context、Control Loop、Tools 的实际调用序列
  • 治理层：Policies、Evaluation、审计与变更管理

3.2 十维模型（通用清单，可按项目裁剪）

维度 含义 设计要点 实用技巧
Goals 要完成什么 可验证的完成条件；子目标 写清 Definition of Done；里程碑；全局停止条件
Policies 允许 / 禁止 / 合规 与 Soul 分离 高危能力用允许列表；敏感操作二次确认；最小权限工具
Soul 怎么说、重视什么 少而硬 Soul 管风格与价值表达，Policies 管能不能做
Memory 长期稳定事实 SSOT；失效与冲突策略 用户事实 vs 世界知识分轨；短期结论不进长期库
Skills 流程与模板 触发条件、输入输出 一技一事；长流程拆子技能；附验收步骤
Grounding 权威知识从哪来 版本与时间 多源交叉验证；标注知识截止日期
Tools & Environment 动作与观测 Schema、错误、状态 返回结构利于解析；沙箱与日志回放
Context & Working State 本轮可见信息 压缩与摘要策略 结构化 scratchpad；摘要保留决策与开放问题
Control Loop 计划—执行—观测 重试上限、退避 最大步数/费用；同错不重试超过 N 次除非有新证据
Evaluation & Feedback 谁判对错、如何改进 自动 + 人工 测试与规则校验；开放题用 rubric；失败案例反哺 Skills

合并为八维时：可将 Goals 与 Policies、Control 与 Evaluation 各并为一维，视团队习惯而定。

3.3 关系示意（静态配置驱动运行时循环）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
flowchart TB
  subgraph governance [Governance_static]
    soul[Soul_principles]
    policies[Policies_safety]
    memory[Memory_long_term]
    skills[Skills_procedures]
  end
  subgraph runtime [Runtime_loop]
    goals[Goals_success_criteria]
    context[Context_working_state]
    grounding[Grounding_sources]
    tools[Tools_environment]
    control[Control_plan_act_observe]
    eval[Evaluation_feedback]
  end
  governance --> runtime
  goals --> control
  context --> control
  grounding --> control
  tools --> control
  control --> eval
  eval -->|"update_skills_memory_docs"| governance

3.4 纯对话（无工具）时哪些仍然适用？

无工具时，Tools/Environment 维度退化，但 Goals、Policies（用户侧约束）、Soul（可选）、Grounding（你粘贴的材料）、Context（长度与分段）、Evaluation（你如何验收） 仍全部成立。技巧：材料分段给出，并明确本轮只回答哪一个子问题，避免“一次塞一本书然后问摘要”导致后半截丢失重点。

4. 各维度横向技巧（速查清单）

  • Goals：复杂任务列出中间可交付物；全局 Done 写进第一条消息或系统层。
  • Policies：生产场景默认对高危工具 deny-by-default；保留审计日志。
  • Memory：写入长期记忆前问一句：六个月后仍成立吗？
  • Skills：每个技能写明触发语与反模式（何时不要用）。
  • Grounding：同一结论尽量 文档 + 运行结果 双源；标明版本。
  • Tools：参数名与真实 API 一致；错误信息可被模型解析（字段稳定、少嵌套）。
  • Context：周期性压缩时保留：已做决策、未决问题、硬约束、工件链接。
  • Control：设置费用与轮次上限；避免无新信息的重复重试。
  • Evaluation：能自动验的不要只靠“看起来对”；开放输出用评分量表（rubric）。

5. 多 Agent 编排：模式、边界与技巧

5.1 为什么要单独谈编排

多 Agent 把任务并行化、专业化或分责；代价是协调成本、上下文重复、指令冲突、终止困难。设计目标是在 延迟、成本、正确性、可审计性 之间权衡，而不是堆更多实例。实例过多而合同不清时，常见结果是重复劳动、互相打架、合并地狱。

5.2 常见拓扑与取舍

模式 结构 适用 风险
Supervisor 中央调度 需要统一验收与权限的复杂任务 编排器瓶颈；单点口径错误被放大
Pipeline A→B→C 固定阶段加工（提取→校对→汇总） 错误逐级放大；需可追溯或可逆
Peer swarm 并行再合并 多假设、头脑风暴、竞优 必须定义合并策略，否则结论冲突
Handoff 交接 + 状态包 前台→专家、调研→写作 状态包不全 = 失忆
Blackboard 共享工件（文档/DB/工单） 长周期、人类介入 需锁 / 版本 / 所有权 
1
2
3
4
5
6
7
8
9
flowchart LR
  sup[Supervisor]
  a[WorkerA]
  b[WorkerB]
  bb[Shared_blackboard]
  sup --> a
  sup --> b
  a --> bb
  b --> bb

5.3 跨 Agent 的“合同”设计（高杠杆）

  • 固定消息模式：建议每条传递至少包含：Goal、Constraints、Artifacts（路径/工单 ID）、OpenQuestions、DoneDefinition。减少纯闲聊式传递。
  • Single Writer：对同一共享状态（主文档、配置、数据库）明确唯一写入者；他人只读或提“建议补丁”，降低冲突。
  • SSOT 外置：真相在 Git、Wiki、工单、表结构，不在某个 Agent 的上下文里；Agent 之间同步指针与短摘要。
  • 幂等与可重试：子任务失败可重跑；工具设计 idempotent；用 run_id 串联日志。
  • 模型分层：分类、检索、格式化用小模型；架构裁决、冲突合并、安全决策用强模型或人。
  • 预算与停止：全局限制轮次、费用、并行度；达到 Done 或无可行动作即停。
  • 审计与回放：记录谁、何时、依据哪些工件做了什么，便于复盘与合规。

5.4 典型反模式

  • 多个 Agent 角色重叠，反复改同一文件。
  • Swarm 无合并策略，产出互相矛盾的长文。
  • 凭据在 Agent 间明文传递。
  • 只有聊天没有工件：上下文截断后全盘失忆。

5.5 与十维模型的关系

多 Agent 把 Goals、Policies、Memory、Context、Evaluation 上升为系统级：共享记忆还是隔离？全局策略如何下发？谁对合并结果验收？这些必须在编排层显式设计，而不能指望每个子 Agent 自发对齐。

English note: Treat orchestration as explicit contracts + shared artifacts + single writer where it matters; avoid chat-only shared state for long tasks.

6. 编码 Agent：使用技巧与常见坑

6.1 编码场景的特殊性

源代码是结构化、可执行、可测试的接地物。瓶颈往往在仓库规模、依赖与环境、团队隐式约定，而不是语法本身。策略重心：缩小变更面、强化验证闭环、减少隐式假设。

6.2 任务与上下文

  • 范围钉死：哪些模块改、哪些绝对不动；Definition of Done（测试、lint、行为不变量）。
  • 先读后写：大改前让助手列出将阅读的文件清单，避免未读代码上的“想象式重构”。
  • 精准引用：路径、符号名、测试名；长文件用章节或行范围，避免无意义的全文堆砌。
  • 地图先行：根 README、架构说明或目录职责表，降低探索成本。

6.3 验证闭环（把 Evaluation 做实）

  • 写清如何安装依赖、跑测试、跑类型检查，减少环境猜测。
  • 指令上坚持小步可验证：先测后重构、或按逻辑步骤拆分。
  • 失败时提供完整栈与复现路径，要求复现后再改。

6.4 仓库与协作

  • 将风格、分支策略、提交规范写进 CONTRIBUTING 或项目规则，做到人与机器同读。
  • 秘密不进上下文：用占位符与环境变量说明代替真实令牌。
  • 大仓按边界拆任务：优先单包或单服务；跨边界时显式列出接口契约。

6.5 常见坑与对策

坑 对策
幻觉 API / 版本 以锁文件与官方文档片段接地；要求对齐仓库内已有用法
静默扩大范围 重复非目标列表与禁止大范围重构
测试未跑或假绿 要求粘贴本地或 CI 命令输出
与人类 diff 冲突 小变更、单议题；助手给出变更摘要 + 风险点

6.6 与多 Agent 结合的流水线示例

一种稳妥拆法：探索 Agent（只读，输出模块地图与风险点）→ 实现 Agent（按范围改代码）→ 审查 Agent（只读，输出 checklist 式审查意见）→ 人类合并与发布。关键仍是 分支/PR/CI 作为共享工件 与 单写入者 规则。

7. 知识载体与文档组织（通用）

7.1 平铺目录 vs 分层目录

按语义边界分层通常优于为了“让模型一眼看完”而强行平铺：文件一多，平铺目录列表本身就会成为噪声。模型更依赖检索、过滤与按需读取；清晰的目录结构有利于路径过滤与命中。根目录或 docs/ 入口应用 README 或索引说明每块职责。

7.2 多个 Markdown 还是单一长文

  • 多主题、多读者：默认 多文件 + 索引页。
  • 强线性教程：可用单文件，或主文 + 附录拆分。
  • 原则：SSOT（同一事实一处权威）、他处链接；避免多份全文拷贝导致指令冲突。
  • 长文件：用好标题层级，便于截取与引用。

8. 结语

大模型能力的“提升”在工程上很大程度是上下文工程与控制面设计：在有限窗口内组织高信噪比信息，用接地与验收约束幻觉，用清晰的 Agent 维度与多 Agent 合同约束协作。Soul / Memory / Skill 是重要构件，但不是完整定义；把目标、安全、工具、循环与评估一并设计，系统才更可能在真实任务中稳定落地。

Closing (English): Improving LLM outcomes is largely context engineering and control design: higher signal-to-noise, grounding, verifiable completion criteria, and explicit multi-agent contracts. Persona, memory, and skills help—but goals, policies, tools, loops, and evaluation complete the picture.

参考与延伸阅读（概念向）

  • ReAct 式 推理—行动循环与停止条件设计
  • RAG 与 Memory 的边界：检索语料 vs 用户长期偏好
  • ADRs（Architecture Decision Records） 作为人类与 Agent 共享的接地物

本文整理自个人学习与项目实践，具体产品（IDE Agent、编排框架）可在各节基础上对照其术语做一张映射表即可。