AIGC环境生态：
| 应用 |
APPLICATIONS |
AI |
| 模型 |
MODELS |
IS A |
| 基础设施 |
INFRASTRUCTURE |
FIVE |
| 芯片 |
CHIPS |
LAYER |
| 能源 |
ENERGY |
CAKE |
从0到1设计一个Agent智能体：
明确核心问题→拆解核心能力→做分层架构→打磨设计细节→快速MVP验证效果→根据数据持续迭代优化
1.熟悉具体公司业务流程，根据业务确定核心问题，锁定具体清晰的场景。如自动处理客服工单，按需生成周报，聚焦问题，明确设计主体
2.拆解Agent要具备的核心能力，按感知、决策、执行、闭环来思考。感知是用户输入，确定是纯文本还是多模态的能力，决策是任务规划，选React模式还是规划式，执行是确定可调用的工具和API，如能不能调用搜索数据库生成文件。
3.分层的架构设计，最底层是大模型作为核心大脑，然后就是工具层，封装后让Agemt能和外部交互。
再往上就是记忆层，短期记忆存上下文，长期记忆用向量数据库存知识。
最上层就是编排层，把控整个任务流程，
分层的架构设计好处是让各层职责清晰，后续迭代调整更加方便。
4.考虑关键的设计细节，比如决策逻辑简单的任务用Flow就可以，需要灵活应变地设计React循环，能根据反馈调整策略。
工具设计要标准化，每个工具入参、出参的描述都要清晰，让模型能够正确调用。做好容错机制，针对调用失败，决策错误的情况，设置重试机制和人工接入点
5.做MVP最小可用版本验证，先搭建简单版本，用真实数据跑通，重点关注任务完成率，平均轮次，工具调用准确率，用户满意度等核心指标，根据数据反馈持续迭代。比如调整工具设计，优化提示词，增加逻辑判断。
6.做好上线的闭环和持续优化。上线后持续收集数据，分析失败案例，整理用户反馈，再针对性优化，比如微调模型，调整提示词，扩充工具集
写代码三个步骤：
1.和cloud ops讨论需求（其他中端模型也行）
2.让Cloud ops写设计文档的文案（其他中端模型也行）
3.让Cloudx去执行（或者cc）
一。多Agent系列
1.单Agent or 多Agent？
基于Anthropic核心原则：“简单优先”，默认从单agent架构开始，如果引入复杂性能够显著”提高效果“时，才考虑。
当Agent遇到无法解决的瓶颈时，就升级为复杂的多Agent
如何判断？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 1.上下文的容量瓶颈
例子：一个上下文窗口，遇到几十个网页分析
2.单一路径依赖带来的高失败风险
例子：有其中一个任务失败时，如遇到API失效等，就会任务流卡死
3.效率瓶颈
例子：要求时效性的任务，就直接上多Agent
|
验证是否真的适合多Agent
1
2
3
4
5
6
7
8
9
10
11
12
|
1.技术可行性
例如：任务能否被拆分成多个独立可并行的子任务。如分析市场分析报告可以，如写代码就不行，因为是强依赖上下文，同时修改一个复杂的代码库不冲突
2.商业价值
多Agent任务是普通聊天的15倍价格
|
如果不行，就优化单agent或者寻找其他方案
2.搭建高效Agent：
代理式系统Agentc systems→工作流
→智能体
差异：决策权在哪里，流程是否固定
技术选项：
|
第三层（高级）：智能体
应用开放性、无法预测步骤 的任务 |
第二层（中级）：工作流
流程固定、追求高质量和可靠性 |
第一层（基础）：优化单个LLM调用
优先尝试！通姑婆RAG和Few-shot解决 |
何时使用或不使用框架：
复杂场景时，需要嗑底层细节，极致的模型优化，产品性能时，就能不使用框架尽量不使用框架
3.Workflows工作流选择
1.Prompt Chaining 基于Prompt的穿行流水线
1
2
3
4
5
6
7
8
| 定义：独立节点：串行工作流、显式流：处理前不输出，避免黑盒操作
适用情形：任务可以拆分子任务，步骤固定且稳定。不关重要的场景节点用便宜的模型，重要决策的场景节点才用贵的
牺牲：调用次数与延迟、 收益：准确率与稳定性高
|
2.Routing 精准分类分发 、如退款纠纷，退款需要高准确度与多重校验，寒暄需要速度与廉价
1
2
3
4
5
6
7
8
9
10
|
核心定义：在任务真正开始之前，对输入进行分类，并将其引导到不同处理器路径的系统结构
核心价值：关注点分离：避免为了优化A而伤害b的结构性冲突，让每一条路径只为负责问题而极致优化
使用前提：输入可以被清晰、可靠地分类，不同类别的处理逻辑存在本质区别，合并路径会产生明显的“目标冲突”
实现方法：LLM判定：利用大模型语义理解，传统模型：专用的分类模型或算法，规则系统：基于关键词或业务逻辑判定
|
3.Sectionning 并行协作/聚合
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 定义与价值：是吧一个大任务拆成多个彼此独立的子任务，并行执行，最后进行结果回报
价值：用并行换效率
适用前提：独立性：子任务间无中间结果依赖，固定性：子任务类型固定（区别于multiagent的子任务动态规划），可以拆分成多个子任务
核心决策点：效率优先vs成本优先（不用）
效率优先：延迟敏感如：安全护栏并行
（不用）成本优先：吞吐瓶颈：自动化测评，通过并发对冲海量数据
|
4.Voting（投票机制）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
核心定义：对同一个判断任务进行多次独立运行，通过程序化规则聚合结果
目的：提高整体置信度与系统鲁棒性
结构直觉：承认波动：非确定性是LLM的客观属性
拒绝博彩：不把安全性建立在单次输出上
并行定位：这是可靠性并型，而非效型
核心决策点：“如果判断错了，业务能否承受代价”
不可容错：如代码安全审查，一次报警即刻拦截
可容错：内容审核，通过阈值权衡假阳性和假阴性
|
5.Orchestrator-workers 动态编排调度
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| 核心定义：动态并行：在运行中根据输入动态拆解子任务
任务规划：orchestrator 决定接下来做什么，worker负责执行
目标：解决无法提前预设固定步骤的效率挑战
对比：Sectioning
Sectioning 子任务是提前固定好的步骤
Orchestrator拆分是动态根据执行进展实事派发任务
什么时候用该模式？
广度优先：覆盖大量对象或信息源
超长上下文：整体信息量已超过单一Prompt承载上限
可拆分独立子任务：子任务需在执行中不断发现，调整和补充
|
6.Eval-Opt 循环评价优化
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| 核心定义：单点打磨：围绕同一结果反复修改而非横向选优
标准驱动：根据明确标注提供反馈
闭环迭代：直到满足标准或达到停止条件
核心前提：掌握改进权
1.标准极其明确：是否清楚滴知道什么是好
2.改进方向清晰是否能支出哪里不好，并知道怎么改
与voting对比：
voting ：不知道答案，选多个里最好的投票（逻辑：多版本的横向对比，场景：没有唯一正确答案，而且单次判断不稳定，目标：见底单次判断失误带来的系统性风险）
Eval-opt：讲一个答案向质量上限迭代（逻辑：单点迭代+反馈驱动迭代，场景：对语气、准确性、风格有明确指标，目标：一个答案向质量上限迭代）
|
** 核心决策逻辑维度：质量（准确率与容错率）、成本（模型选择与调用量）、速度（响应时间与吞吐量）**
3.多智能体A2A
1.传统脚本（硬编码路劲）→2.单智能体（动态转向）→3.多智能体（Agent并行协作）
1
2
3
4
5
6
| 核心定义：Agent在循环自主使用工具的LLM
Multi-Agent：通过分工突破个体极限的协作系统
上下文工程终极策略：隔离lsolation
|
1.核心架构（Architecture）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| 指挥官-工人模式
2.核心优势：并行化：同时处理多任务，效率up
隔离性：独立上下文窗口，降低噪音
压缩：提炼洞见，而非堆砌数据
3.适用场景：
广度优先：需要同时探索多个方向。如调研
任务可并行：子任务间无强依赖。如50家公司财报
效果验证：Token缩放定律
实战数据：标普500董事成员查询
单体：失败
多提：90.2%准确率
物理原理：推理时计算80%性能差异源于Token使用量，需要堆智力
能力边界：
成本与局限：15倍代价
|
| 维度 |
说明 |
|
| 成本（cost） |
Token消耗约为普通对话的15倍，仅仅适合高价值任务 |
|
| 使用（Pro） |
重阅读：研究，分析。
特点独立可并行 |
|
| 不适用（Con） |
重写入：复杂编程。特点：高耦合，强依赖 |
|
4.高级架构概览（High-level Architecture）
|
|
|
| citations |
Lead agent(主智能体)
用户请求传进来主智能体，主智能体分发后最终生成报告 |
Memory |
Search
subagent |
Search
sybagent |
Search
subagent |
|
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| 1.用户请求传进来主智能体，指挥官接单
2.指挥官开始思考和规划
3.指挥官根据规划向下方派出多个工人
4.各工人把结果返回指挥官，进行汇总与初稿
5.添加引用来源并且生成最终报告输出回用户
主Agent分发原理：
深度思考（Think&Plan）：插接需求，列出维度：1.硬件2.算法3.市场
↓
确定人设（Define Personas）：决定生成3个工人，并分别定义其topic
↓
工具调用（Tool Call）：发起Function Call
↓
现场实例化（Instantiation）：后台启动新Session System Prompt
|
范式对比：静态RAGvs动态智能体
| 维度 |
传统RAG |
多智能体 |
| 机制（Mechanism） |
静态检索（static Retrieval）一次抓取 |
动态搜索（Dynamic Search）（多步迭代） |
| 行为（Behavior） |
图书馆管理员（搬书） |
资深研究员（适应与修正） |
| 可信度（Trust） |
隐式信任（容易幻觉） |
显式审计Citation Agent（独立验证层） |
5.多Agent提示词工程
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
1.管理层原则：心智与授权（要做到“可控”，“高效”，“可靠”）
1.像智能体一样思考：行动：简历模拟器，观察失败步骤
避免黑盒操作
2.教会指挥官权限：四要素：目标+格式+工具+边界
3.匹配力度（Scale effort）规则：简单任务（1agent），普通任务（5agent），复杂任务（10 agent）
.在prompt中嵌入明确的缩放规则。
根据任务复杂度匹配投入力度，避免简单任务过度投入，复杂任务投入不足问题
4.工具设计至关重要
1.工具描述= 用户手册
2.必须提供显式启发法：“优先使用专用工具”
3.糟糕的描述=错误的路径
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
5.让智能体自我进化
试用工具→报错→重写文档
Result：任务耗时减少40%
如何帮助智能体自我进化？
“测试所以可用工具，思考工具的描述有没有存在缺陷，观察报错原因、分析失败模式，是否能补充，自动生成新的工具描述来避免未来的错误”
6.先宽后窄策略（Start Wide）
策略：先搜宽泛概念→再聚焦细节（drill down）
起步：1.短、宽泛的查询词，再进行评估，2.看看信息是否足够，3.最终逐步收窄范围、进入细节
7.引导思维过程（Thinking）
工具：Extended Thinking作为草稿纸
循环：Search → Interleacved Thinking →Next Act
工具结果→思考评估→ 再搜索（循环进行）
让模型输出可见思考轨迹，帮助主Agent规划查询步骤，决定用哪些工具，判断查询复杂度，明确子智能体角色，子智能体使用交错石思维
8.并行工具调用（parallel）
速度来源：宏观并行（多Agent）+微观并行（每个字Agent内部同时使用多个工具）
Impact：研究时间缩短90%
|
6.Lead Agent提示词
1.核心人设（Persona）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
核心能力：战略（Strategy）、规划（planing）、委派（Delegation）
定位：像课题组长一样思考“怎么解题最高效”?你是专业研究负责人，专注于高层研究战略、规划、高效派委subagent以及报告撰写
核心目标：
定义:领导一个流程（lead a process）
交付：产出卓越的研究报告（Produce 按excellentresearch report）
|
2.研究过程：四步思考循环
1
2
3
4
5
6
7
8
9
10
|
1.评估Assessment →2.分类Query Type→3.计划Plan→4.执行Execution
2.多方案：需要探索至少三种不同的应答方法，最终选择最优方案（思维发散）
避免了模型即使错了也要走到黑的毛病
|
一.评估与分解（Assessment）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
深度解构（Breakdown）
实体与关系（concepts&Emtotoes）：谁是主角？有什么关联？
数据锚点（Facts&Data）：需要哪些具体数字
约束条件（Constraints）：时间、上下文
What matters most？用户最在意是什么
Desired format？是一份详细报告、实体列表、还是视觉分析？
|
二.查询类别判定（Query Type）
1.深度优先
depath-first |
特征：多视角（Multiple Perspectives、深挖单一话题）
策略：平行Agent探索不同观点/方法论 |
2.广度优先
Breadth-furst |
特征：独立子问题（Distinct Sub-questions）、“Ging wide”
策略：平行Agent分头抓取数据包，再汇报 |
3.直截了当
Straightforward |
特征：聚焦、定义明确、单次调查即可
策略：单一Sub-agent高效执行 |
三.基于分类的计划制定
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
For Depth-first
定义3--5个具体的方法论或者视角，列出具体的专家观点或者证据源，Synthesis Plan：规划如何融合不同的观点。
For Breadth-furst
枚举所有子任务
划定清晰的边界（Crisp Boundaries）以防重叠
按重要顺序排序
对每一步都自我评价：
这一步能并行吗？
这一步真的有必要吗？
|
四.执行
1
2
3
4
5
6
7
8
| 有条不紊的动态闭环
动态监控：持续监控进度，跟进智能体的结果“更新搜索计划”
贝叶斯推理：更新先验指示表知识，方向错了立刻掉头，发现线索立刻追中。
时间管理： 若时间不够停止部署，立刻开始撰写报告（避免超时）
|
3.兵力部署：Sub-agent数量法则
More Subagents = More overhead
| 简单任务 |
1个（即使简单任务也要派一个，确保隔离） |
| 标准任务 |
2-3个（多视角验证） |
| 高复杂度 |
5-10个（海量信息收集，超过20个需要重构） |
4.委派指令：部署与分配
1
2
3
4
5
6
| 工具落地：必须调用run_blocking_subagent+ 清晰Prompt
时效性：马上部署，优先跑“”阻塞任务“。
空窗期：“Use time effciently”等待分析已经有结果
|
5.任务分配原则：
1
2
3
4
5
6
7
8
| 深度优先：按顺序部署（验证假设→补充视角）
广度优先：按重要性排序（核心实事→边缘细节）
直接查询：单个综合子智能体
Ruler：避免重叠（No overlap） &即使简单也要委派
|
4.3为Sub-agent提供明确指引
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
Sub-agent Prompt 必须包含：
1.核心目标（Objective）：最好每个Agent只专注一个核心目标
2.输出格式（Format）：列表？报告？还是特定答案？
3.背景上下文（Context）：让下属知道为什么要做这个。
4.工具与范围（Tool &Scope）：指定用什么工具，划定边界
5.推荐/黑名单信源（Sources）：“Use SEC EDGAR，avoid news aggregators”
|
4.4综合协调职责（Synthesis Responsibility）
1
2
3
4
5
6
7
8
9
10
11
12
|
Lead Agent：
Negative Constraints ：不要自己做初级搜索（除非非常简单）、不要为了琐碎任务开Sub-Agent
Positive Responsibility：Coordinate：协调、同步，Synthesize：整合不同来源的信息，Fill Gaps：发现缺漏根据需要增派人手
|
5.答案格式（Answer Formatting）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
交付三部曲：
1.Review:重新审查所有事实清单
2.Reflect：深度反思-“这些事实真的能充分回答用户的问题吗？”
3.Output：只有确认无误后，才生成Markdown格式的最终答案
特殊禁令：
不要在报告里加md引用，因为后面会有专门的Citation Agent来处理。
|
6.进阶：如何使用内部工具？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
链接Slack，Jira，Drive等企业数据
探索模式（Read-only First）
在委派之前，自己先用read-only tools（如“slack_search”）试探一下
目的：了解数据结构，确认信息是否存在，以便写出更好的指令
专用Sub-Agent模式
对于特定数据源，创建Specialized Sub-agents。
Example：“Asana Subagent”，“Slack Subagent”
明确指示他们仅用特定工具，避免公网干扰
|
7.并行工具调用
1
2
3
4
5
6
7
8
9
10
|
串行（Sequentia）：Call A→Wait→CallB
并行（Parallel）：Call A+CallB+CallC
标准：启动阶段默认并行运行3个子智能体（获取足够信息面）
|
8.核心规则（7 Guidelines）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
1.沟通：极高信息密度。用最少字说清楚
2.事实审查：日期、数字、量化数据。Lead Agent必须定期回顾核心事实
3.冲突解决：新近度（Recency）&一致性。不同来源信息打架时
4.审慎思考：对新奇信息“Thinkcarefully”
5.及时止损：边际收益递减→Stop
6.边界：Lead必须亲自写报告
7.安全红线：严禁研究仇恨/暴力内容？
|
AIGC往后发展个人预期：
2026Q1-2月：
养虾热潮，聚集大量用户关注者
2026Q2-3月：
极简部署与运行形成生态化
社区与虾粉互动生态
本地化插件生态
2026Q2-5月
沉淀优质资产，打造中国开发的SKills生态圈与杀手级应用
打造中国Skills本地生态
Killer Apps杀手级落地
如Coze的工作流被Skills代替
大模型评估&红队测试：Promptfoo
交付安全可靠的人工智能应用，被openAI收购并入功能
AIAgent架构
Skills决定上限
skills架构
1.skill.md：必须的（Required，核心大脑）教用户如何使用
2.references：参考内容、知识库
3.scripts：脚本工具箱
4.templates：模板输出库
5.LICENSE.txt
为什么Skill比工作流强：
1.降低模型幻觉
2.复用性强，移植性强
3.自由度，边界，可以更好做复杂的工作流
- OpenClaw 蓝皮书 / Claude Skill 构建指南
- 国内 Skill 构建指南（WorkBuddy / Claude Code 中文生态）
OpenClaw架构
UI/命令符
↓
多Agent（外层封装）
↓
本地推理引擎如：
↓
Agent智能体
↓（包含模块）模块流程：
1,感知模块接收用户输入(如“生成行业报告” )
↓
2.Agent大脑模型（决策模块LLM）：
**Qwen3-Coder (7B/14B)**：目前开源界最适合处理代码和逻辑指令的模型之一。
DeepSeek-R1-Distill-Llama-8B：推理能力强，适合处理复杂任务拆解。
**Llama-3.2 (8B)**：综合性能均衡，响应速度快。
下载命令示例（以 Ollama 为例）：
ollama pull qwen2.5-coder:7b
↓
3.调用工具模块执行(搜索引擎+数据分析工具)
调用工具模块属于Skills,本质是Tools的流程化封装
底层执行通过 Function Calling 和 MCP 协议实现
↓
4.记忆模块记录中间结果
↓
- 最终输出报告
文档著者：GT / github:morniakr.git.io