人工智能 AI 大语言模型 多模态 — 从 API 调用到 Agent 实战
服务器: 华为云 FlexusX ecs-d2c2-0001 (8vCPU/16GiB, Ubuntu 24.04)
Python: 3.12.3 | Flask: 3.1.3 | Markdown: 3.10.2
实验总数: 26 个 | 实战环境: 真实服务器上机执行
实验架构总览
┌─────────────────────────────────────────────────────────┐
│ AI 大语言模型 实战全景图 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 文生文 (23 实验) │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ LLM基础 │ │ 角色人设 │ │ Flask/前端/渲染 │ │ │
│ │ │ (1-3) │ │ (4-6) │ │ (8-10) │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ History │ │ Context │ │ Function Call │ │ │
│ │ │ (11-12) │ │ (13-14) │ │ (15-17) │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ Agent │ │ 记忆 │ │ 提示词工程 │ │ │
│ │ │ (18-20) │ │ (21) │ │ (22-23) │ │ │
│ │ └──────────┘ └──────────┘ └──────────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────┐ ┌────────────────────────┐ │
│ │ 文生图 (1 实验) │ │ 环境与趋势 (2 实验) │ │
│ │ API调用 + 6模型 │ │ 新媒体融合 + 定价模型 │ │
│ └──────────────────────┘ └────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
第一部分：文生文（实验 1-23）
实验 1：大语言模型调用 — API 请求格式
目的
理解 LLM API 的标准请求/响应格式（OpenAI 兼容接口）。
OpenAI 兼容 API 请求体
{
"model": "hunyuan-lite",
"messages": [
{"role": "system", "content": "你是腾讯混元大模型，一个乐于助人的AI助手。"},
{"role": "user", "content": "请用一句话介绍你自己"}
],
"temperature": 0.7,
"max_tokens": 200,
"stream": false
}
响应体结构
{
"id": "chatcmpl-abc123",
"object": "chat.completion",
"created": 1783061050,
"model": "hunyuan-lite",
"choices": [{
"index": 0,
"message": {
"role": "assistant",
"content": "你好！我是腾讯混元大模型，一个支持多轮对话、代码生成、知识问答的AI助手。"
},
"finish_reason": "stop"
}],
"usage": {"prompt_tokens": 32, "completion_tokens": 18, "total_tokens": 50}
}
关键参数解读
| 参数 |
类型 |
说明 |
典型值 |
model |
string |
模型名称 |
hunyuan-lite, gpt-4o, claude-3.5-sonnet |
messages |
array |
消息列表（含system/user/assistant角色） |
最少1条user消息 |
temperature |
float |
随机性（0=确定，2=高随机） |
编程:0.1, 聊天:0.7, 创意:1.2 |
max_tokens |
int |
最大输出token数 |
短答:200, 代码:2000 |
stream |
bool |
是否流式输出 |
聊天:true, 批处理:false |
实验 2：OpenAI 创始故事 — 关键人物时间线
背景
OpenAI 成立于 2015 年 12 月，定位为非营利 AI 研究机构。十年间经历了从非营利→利润上限→商业化的完整转型。
完整时间线
| 时间 |
事件 |
说明 |
| 2015-12 |
OpenAI 成立 |
Sam Altman + Elon Musk + Greg Brockman + Ilya Sutskever 等联合创立 |
| 2018-02 |
Musk 退出董事会 |
因与 Tesla AI 利益冲突 |
| 2019-03 |
OpenAI LP 成立 |
从非营利转为 capped-profit（利润上限）模式，微软投资 10 亿美元 |
| 2019-07 |
Dario Amodei 在职 |
时任研究副总裁，负责 GPT-2 安全研究 |
| 2020-06 |
GPT-3 发布 |
1750 亿参数，Dario 是核心贡献者 |
| 2020-12 |
Anthropic 成立 |
Dario + Daniela Amodei 离职创立，聚焦 AI Safety |
| 2022-11 |
ChatGPT 发布 |
2 个月破 1 亿用户，引发全球 AI 浪潮 |
| 2023-01 |
微软追加投资 |
数十亿美元多年期投资，深度绑定 |
| 2023-03 |
Claude 发布 |
Anthropic 发布，主打 Constitutional AI |
| 2023-11 |
Altman 被董事会解雇 |
5 天后回归，董事会重组 |
| 2024-03 |
Musk 起诉 OpenAI |
指控背离非营利使命，后撤回 |
| 2024-06 |
Dario 谈 AI Safety |
国会听证会强调监管必要性 |
| 2025-02 |
Musk 收购提议 |
提出 974 亿美元收购，被 Altman 拒绝 |
核心人物关系图
Elon Musk (联合创始人)
├── 2015: 共同创立 OpenAI
├── 2018: 退出董事会 (利益冲突)
├── 2023: 创立 xAI (Grok)
├── 2024: 起诉 OpenAI
└── 2025: 提出收购 → 被拒
Sam Altman (CEO)
├── 2015: 联合创立
├── 2019: 出任 CEO, 推动商业化
├── 2023.11: 被解雇 → 5天后回归
└── 代表: "加速派" (产品驱动)
Ilya Sutskever (联合创始人/首席科学家)
├── 2015: 联合创立
├── 2024.05: 离职
└── 创立: Safe Superintelligence Inc.
Dario Amodei (前研究副总裁)
├── 2020.12: 离职
└── 创立: Anthropic (Claude)
实验 3：微软入股与 OpenAI 斗争 — 安全派离场
关键节点
| 时间 |
事件 |
细节 |
| 2023-11 |
Altman 被解雇 |
董事会以"沟通不坦诚"为由解雇 CEO |
| 2023-11 |
员工联名信 |
770 名员工（占总数 95%）签署要求董事会辞职 |
| 2023-11 |
Altman 回归 |
Bret Taylor + Larry Summers + Adam D’Angelo 组成新董事会 |
| 2024-05 |
安全团队解散 |
Ilya Sutskever 离职，Superalignment 团队解散 |
| 2024-05 |
Jan Leike 离职 |
对齐负责人公开批评"重产品轻安全" |
| 2024-05 |
多名安全研究员离职 |
Gretchen Krueger 等相继离开 |
| 2024-08 |
John Schulman 离职 |
联合创始人加入 Anthropic |
| 2024-09 |
Mira Murati 离职 |
CTO 宣布离开 |
| 2024-09 |
Bob McGrew + Barret Zoph 离职 |
首席研究官和研究副总裁同日离职 |
安全派 vs 加速派
┌─────────────────────────┬─────────────────────────┐
│ 安全派 (Leave) │ 加速派 (Stay) │
├─────────────────────────┼─────────────────────────┤
│ Ilya Sutskever │ Sam Altman │
│ Jan Leike │ Greg Brockman │
│ Dario Amodei │ │
│ Daniela Amodei │ │
├─────────────────────────┼─────────────────────────┤
│ 主张: AI 安全第一 │ 主张: 快速迭代 + 产品驱动 │
│ 去向: Anthropic, SSI │ 方向: ChatGPT/GPT-4/Sora │
│ 策略: 谨慎部署，强监管 │ 策略: 通过部署收集反馈 │
└─────────────────────────┴─────────────────────────┘
实验 4：角色扮演 — System Prompt 系统设定
核心概念
system 角色的消息是对话的最高优先级指令，定义 AI 的身份、能力和行为边界。
五种角色对比
| 角色 |
System Prompt 设计要点 |
回答风格 |
| 翻译专家 |
精通中英互译 + 术语标注原文 + 信达雅 |
专业、准确、注明术语原文 |
| 代码导师 |
Python 3.12+ 语法 + 先思路后代码 + 逐行注释 |
教学式、分步走、可运行 |
| 心理咨询师 |
CBT 取向 + 非评判性语言 + 开放式提问 |
倾听、共情、引导 |
| 历史学家 |
宋史专家 + 引用史料注明出处 + 学术规范 |
严谨、有据、学科范 |
| 默认助手 |
You are a helpful assistant. |
通用、中性 |
System Prompt 设计原则
1. 角色定义: 你是什么、擅长什么、不做什么
2. 输出格式: 回答的结构要求（JSON/MD/分步骤）
3. 行为约束: 边界和限制（"不知道就说不知道"）
4. 风格指南: 语言风格、详细程度、术语偏好
5. 示例引导: 用 Few-shot 展示期望的输出格式
实验 5：对话人设 — 孙悟空 / 猪八戒 / 三年级数学老师
人设 Prompt 设计
孙悟空：自称"俺老孙"，口头禅"俺老孙来也"“妖精哪里跑”，动作描写标签 [舞动金箍棒][腾云驾雾]
[追问: 前面有妖怪挡路怎么办？]
呔！俺老孙来也！[舞动金箍棒] 什么妖怪敢挡你孙爷爷的道？
待俺老孙火眼金睛一瞧——[抓耳挠腮] 这厮不过是只小妖，
看俺老孙一棒下去，管教他现出原形！
猪八戒：自称"俺老猪"，贪吃好色，经典台词"散伙回高老庄"，市井气息
[追问: 前面有妖怪挡路怎么办？]
哎哟喂，又碰上妖怪了！[摸着肚子] 俺老猪还没吃早饭呢，
这猴哥呢？让猴哥去打头阵，俺老猪在后面掠阵就好。
要不……干脆散伙吧，俺老猪回高老庄找高小姐去~
三年级数学老师：教龄 15 年，温柔耐心，用实物举例（苹果、糖果），鼓励为主 + 小星星奖励
[追问: 老师，12×13等于多少？]
好问题！我们来分步算一下：
第一步：12×10=120（十个12是120）
第二步：12×3=36（三个12是36）
第三步：120+36=156
所以 12×13=156 ★ 你真棒！奖励一颗小星星！
人设设计的三个层次
| 层次 |
内容 |
重要性 |
| 身份层 |
名称、来历、背景故事 |
⭐⭐⭐ 决定角色基调 |
| 语言层 |
自称、口头禅、句式、语气词 |
⭐⭐⭐ 最显性的角色特征 |
| 行为层 |
动作描写、推理方式、情感表达 |
⭐⭐ 增强沉浸感 |
实验 6：灵魂宪法 — 人格文件体系（user_soul.md）
核心思路
将 AI 的人格设定外部化、文件化、可持久化，每次对话前自动加载。
user_soul.md 模板
# 我的AI人格设定 (user_soul.md)
## 基本身份
- 姓名: 小明
- 角色: 个人AI助理
- 主人: 周亮 (AI研究员)
- 创建日期: 2026-07-03
## 核心原则 (不可违背)
1. **诚实原则**: 不知道就说不知道，不编造事实
2. **安全原则**: 绝不提供危险行为的指导
3. **简洁原则**: 默认回答精简，除非要求详细展开
4. **实用原则**: 优先给出可执行的方案而非理论
## 知识偏好
- 技术栈: Python > JavaScript > Go > Rust
- 框架: Flask > FastAPI > Django
- 数据库: PostgreSQL > SQLite > MySQL
- 工具: VS Code > Vim > Emacs
## 回答风格
- 先给结论，再展开细节
- 代码必须可运行，带注释
- 涉及版本号时标注最新稳定版
- 中文为主，技术术语保留英文
## 记忆策略
- 每次对话结束时总结要点
- 重要决定记录到 MEMORY.md
人格文件的三个作用
| 作用 |
说明 |
| 一致性 |
每次对话行为一致，不会出现"今天知道，明天忘了" |
| 可迁移性 |
换个 LLM 也能保持一致的行为风格 |
| 可迭代性 |
发现不足就修改文件，下一次对话立即生效 |
解析结果
核心原则: 诚实、安全、简洁、实用 (4条)
技术偏好: Python 优先, Flask > FastAPI > Django
数据库: PostgreSQL 优先
输出风格: 结论先行 + 可运行代码 + 中英混合
实验 7：LLM 分类 — Reasoner 推理者
大语言模型分类维度
┌──────────────┬──────────────────────────────────────┐
│ 维度 │ 分类 │
├──────────────┼──────────────────────────────────────┤
│ 规模 │ Small(<7B) / Medium(7-70B) / Large(70B+)│
│ 架构 │ Dense(GPT/Llama) / MoE(Mixtral/DeepSeek)│
│ 模态 │ Text-Only / Multimodal(Vision+Audio) │
│ 推理方式 │ Standard LLM / Reasoner(CoT) │
│ 部署方式 │ Cloud API / Local(Ollama/vLLM) │
│ 开源情况 │ Open(Llama/Qwen/DeepSeek) / Closed(GPT/Claude)│
│ 用途 │ General / Coding / Math / Role-Play │
└──────────────┴──────────────────────────────────────┘
Reasoner 推理者特征
| 特征 |
说明 |
| 代表模型 |
OpenAI o1/o3, DeepSeek-R1, Qwen-QwQ |
| 核心机制 |
Chain of Thought (CoT) 思维链 |
| 标记符号 |
<think>...</think> 标签包裹推理过程 |
| 优点 |
数学/逻辑/编程能力显著提升，可解释性更强 |
| 缺点 |
耗时更长，简单问题可能过度推理（overthinking） |
| 适用场景 |
数学证明、复杂代码、逻辑推理、科学分析 |
Standard LLM vs Reasoner 调用差异
Standard LLM:
User: 15 × 27 = ?
AI: 405
Reasoner (CoT):
User: 15 × 27 = ?
AI <think>:
15 × 27 = 15 × (20 + 7)
= 15 × 20 + 15 × 7
= 300 + 105
= 405
</think>
答案: 405
实验 8：Web 版 AI 对话 — Flask 后端
架构设计
from flask import Flask, request, jsonify, render_template_string
app = Flask(__name__)
chat_history = []
@app.route('/')
def index():
"""GET / — 返回聊天页面 HTML"""
return render_template_string(HTML_TEMPLATE)
@app.route('/api/chat', methods=['POST'])
def chat():
"""POST /api/chat — AI 对话接口"""
data = request.get_json()
user_msg = data.get('message', '')
messages = [
{"role": "system", "content": "你是混元助手"},
*chat_history[-10:],
{"role": "user", "content": user_msg}
]
reply = f"[AI回复] 收到你的消息: {user_msg[:30]}..."
chat_history.append({"role": "user", "content": user_msg})
chat_history.append({"role": "assistant", "content": reply})
return jsonify({"reply": reply, "history_len": len(chat_history)})
if __name__ == '__main__':
app.run(host='0.0.0.0', port=8080, debug=False)
API 路由表
| 方法 |
路径 |
输入 |
输出 |
说明 |
| GET |
/ |
- |
HTML 页面 |
聊天界面 |
| POST |
/api/chat |
{"message": "用户问题"} |
{"reply": "AI回答", "history_len": N} |
对话接口 |
实验 9：单文件纯前端 AI 对话 — fetch API 直连
架构特点
| 特点 |
说明 |
| 零后端 |
无 Flask/Node，HTML 静态文件即可 |
| 直连 API |
前端 fetch() 直接调用 OpenAI 兼容接口 |
| 部署简单 |
扔到 Nginx/CDN/GitHub Pages 就能用 |
| 局限性 |
API Key 暴露在前端，仅适用于 Demo/内部工具 |
核心 fetch 调用
async function send() {
const msg = document.getElementById('user-input').value.trim();
if (!msg) return;
const resp = await fetch('https://api.example.com/v1/chat/completions', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer YOUR_API_KEY'
},
body: JSON.stringify({
model: 'hunyuan-lite',
messages: [{role: 'user', content: msg}],
temperature: 0.7,
max_tokens: 500
})
});
const data = await resp.json();
addMsg('ai', data.choices[0].message.content);
}
实验 10：Markdown 渲染 — Python markdown 库
测试数据
输入 Markdown（548 字符），渲染为 HTML（2003 字符），压缩比 3.7x。
支持的 Markdown 扩展
| 扩展 |
功能 |
状态 |
fenced_code |
代码块 ``` 语法 |
✅ OK |
tables |
表格渲染 |
✅ OK |
codehilite |
代码语法高亮 |
✅ OK |
toc |
自动目录生成 [TOC] |
✅ OK |
nl2br |
换行自动转 <br> |
✅ OK |
sane_lists |
智能列表嵌套 |
✅ OK |
smarty |
智能引号（直引号→弯引号） |
✅ OK |
实践代码
import markdown
md_text = """
```python
print("hello")
html = markdown.markdown(md_text, extensions=[
‘fenced_code’, ‘tables’, ‘codehilite’, ‘toc’,
‘nl2br’, ‘sane_lists’, ‘smarty’
])
---
## 实验 11：LLM → Agent — 对话历史 Session
### ConversationSession 实现
```python
class ConversationSession:
"""管理对话历史的 Session 类"""
def __init__(self, system_prompt: str, max_history: int = 20):
self.system_prompt = system_prompt
self.max_history = max_history
self.messages = [{"role": "system", "content": system_prompt}]
self.session_id = datetime.datetime.now().strftime("%Y%m%d-%H%M%S")
def add_user(self, text: str):
self.messages.append({"role": "user", "content": text})
def add_assistant(self, text: str):
self.messages.append({"role": "assistant", "content": text})
def get_context(self) -> list:
"""获取发送给 API 的消息列表（自动截断）"""
system = [self.messages[0]] # 始终保留 system prompt
recent = self.messages[1:][-self.max_history:]
return system + recent
多轮对话演示
[session_id: 20260703-144410] [turns: 5] [total_messages: 10]
User: 我叫周亮
AI: 你好周亮！很高兴认识你。
User: 我刚才说我叫什么？
AI: 你刚才说你叫周亮。 ← 上下文记忆生效
User: 帮我写个Hello World
AI: print('Hello, World!')
User: 用Java呢？
AI: System.out.println("Hello, World!"); ← 还记得上下文
User: 你记得第一次对话是什么吗？
AI: 第一次对话时你告诉我你叫周亮，这是我们的第3轮对话。
实验 12：记忆的持久化 — Memory & Context Window
持久化记忆系统
class PersistentMemory:
def __init__(self, filepath="/tmp/ai_memory.json"):
self.short_term = []
self.long_term = self._load()
def remember(self, key: str, value: str):
"""存储长期记忆，自动去重更新"""
def recall(self, key=None):
"""按关键词检索记忆"""
def context_window_stats(self):
"""分析 context window 占用"""
记忆数据示例
用户姓名: 周亮
用户职业: 腾讯AI研究员
技术栈: Python, K8s, Docker, PostgreSQL, Flask, FastAPI
偏好: 先实操后文档，分步交互式指导
Context Window 占用分析
| 指标 |
值 |
| 记忆条数 |
5 |
| 总字符数 |
436 |
| 估算 Token |
109 |
| 占 128K 窗口 |
0.1% |
| 占 8K 窗口 |
1.3% |
结论: 结构化的外部记忆占用极少 token，但能大幅提升对话一致性。5 条关键记忆仅占 128K 窗口的 0.1%。
实验 13：上下文压缩 — Context Engineering
五种压缩策略
| 策略 |
Token 估算 |
优点 |
缺点 |
适用 |
| 无压缩 |
~2500 |
信息完整，不丢失上下文 |
成本高，小窗口装不下 |
128K+ 窗口模型 |
| 截断(Truncation) |
~800 |
简单高效 |
丢失早期重要信息 |
简单问答 |
| 摘要压缩 |
~500 |
保留关键信息，96% 压缩率 |
需要额外 API 调用 |
长对话续接 |
| 滑动窗口+摘要 |
~1000 |
兼顾细节和要点 |
实现较复杂 |
Agent 持续运行 |
| RAG 检索 |
~600/次 |
海量对话精准检索 |
需要向量数据库 |
知识库场景 |
摘要压缩效果
原始 15 轮对话（~2500 tokens）→ 压缩后摘要（~100 tokens）→ 96% 压缩率
摘要内容: “用户询问了 Kubernetes 基础知识，包括 K8s 与 Docker 区别、核心组件(API Server/etcd 等)、Pod/Service/Deployment、基本操作(创建/暴露/日志/进入容器)、ConfigMap vs Secret、Helm 包管理。”
实验 14：输出格式约束 — System Prompt 模板
四种输出约束
| 模板 |
System 指令关键点 |
效果 |
| JSON 输出 |
“始终以纯 JSON 格式回答，不要有任何额外文字” |
结构化数据，可直接 json.loads() |
| Markdown 表格 |
“对比类问题必须使用 Markdown 表格格式” |
对比清晰，视觉友好 |
| 分步骤 |
“使用 ### Step N 格式，每步间用 --- 分隔” |
操作步骤标准化 |
| 字典格式 |
“输出必须是 Python 字典格式: {"实体": [...], "关系": [...]}” |
知识图谱提取 |
JSON 输出示例
System: 你是一个数据提取助手。始终以纯JSON格式回答，不要有任何额外文字。
输出格式: {"result": ..., "confidence": float}
User: 今天北京天气怎么样？
Output: {"result": "晴转多云，温度25-32°C，湿度60%", "confidence": 0.85}
模板设计原则
- 明确格式 — 不给模型留猜测空间
- 给出示例（One-shot/Few-shot）— 让模型有参照
- 错误处理指令 — “如果无法确定，输出
null”
- 字段说明 — 列出所有必需和可选字段
实验 15：当前时间日期 — Time Aware LLM
实现方式
now = datetime.datetime.now()
time_aware_prompt = f"""你是时间感知助手。当前时间为 {now.strftime('%Y年%m月%d日 %H:%M')} (北京时间)。
在回答涉及时间的问题时，请基于这个时间点。"""
服务器实时数据
服务器当前时间: 2026-07-03 14:44:22 (UTC+8)
星期: 五
Unix 时间戳: 1783061062
2026年剩余: 181 天
时间相关问答
| 问题 |
答案 |
| 今天星期几？ |
星期五 (2026-07-03) |
| 现在是几点？ |
北京时间 14:44 |
| 2026 年还剩多少天？ |
181 天（不含今天） |
| 下周一是什么日期？ |
2026-07-06 |
实验 16：让大模型使用工具 — Function Calling
工具定义（OpenAI Function Calling Schema）
{
"type": "function",
"function": {
"name": "get_time",
"description": "获取当前日期时间",
"parameters": {
"type": "object",
"properties": {
"timezone": {
"type": "string",
"description": "时区，如 Asia/Shanghai, America/New_York"
}
}
}
}
}
三个内置工具
| 工具 |
功能 |
参数 |
get_time |
获取当前时间 |
timezone: 时区字符串 |
run_shell |
执行 shell 命令 |
command: 命令字符串 |
calculate |
安全数学计算 |
expression: 仅支持 +-*/()% |
实际执行结果
get_time() → 2026-07-03T14:44:22 (Asia/Shanghai)
calculate('2**10+3*5') → 1039
calculate('1234*5678') → 7006652
run_shell('echo "Hello..."') → Hello from ecs-d2c2-0001! (6.8.0-106-generic)
Function Calling 工作流
User: 帮我算 1234×5678，然后告诉我现在几点
→ LLM 分析: 需要两个工具
→ tool_calls: [
{function: "calculate", args: {expression: "1234*5678"}},
{function: "get_time", args: {timezone: "Asia/Shanghai"}}
]
→ 工具执行: 7006652, 2026-07-03T14:44:22
→ LLM 汇总: "1234×5678 = 7006652，当前时间是 2026年7月3日14:44"
实验 17：能力泛化 — 智能体使用终端能力
TerminalAgent 实现
class TerminalAgent:
def __init__(self):
self.tools = {
"date": self._cmd_date,
"uptime": self._cmd_uptime,
"df": self._cmd_df,
"free": self._cmd_free,
"ps": self._cmd_ps,
"ls": self._cmd_ls,
"whoami": self._cmd_whoami,
}
实际查询结果
[当前时间] 2026-07-03 14:44:22 CST
[系统运行时间] up 42 min, 1 user, load average: 0.00
[磁盘使用] /dev/vda1 40G / 4.1G used / 34G free (11%)
[内存使用] Mem: 14Gi total, 564Mi used, 13Gi available
[当前用户] root
能力泛化原理
自然语言指令 → 命令映射 → 执行结果
"帮我看看服务器负载" → uptime → 系统负载数据
"检查磁盘还有多少空间" → df -h → 磁盘使用率
"哪些进程占用内存最多" → ps aux → 进程列表
实验 18：OpenClaw / Manus — 大模型使用工具
架构对比
┌──────────────┬──────────────────┬────────────────────┐
│ 组件 │ OpenClaw │ Manus │
├──────────────┼──────────────────┼────────────────────┤
│ 核心语言 │ Python │ Python │
│ LLM 后端 │ 混元/Claude/GPT │ Claude (默认) │
│ 工具扩展 │ MCP Protocol │ 内置 Tool Set │
│ 文件操作 │ 本地 + 远程 SSH │ 沙箱环境 │
│ 浏览器控制 │ Playwright │ Chrome DevTools │
│ 代码执行 │ subprocess │ Python Interpreter│
│ 部署方式 │ 本地 CLI │ Web + CLI │
│ 开源 │ 是 │ 部分开源 │
│ 记忆系统 │ MEMORY.md │ 向量数据库 │
└──────────────┴──────────────────┴────────────────────┘
共同点
- 都可以调用 LLM 进行推理
- 都可以执行代码/Shell 命令
- 都可以读写文件
- 都通过 Function Calling 扩展工具
- 都支持多轮对话和任务分解
OpenClaw 配置示例
llm:
provider: custom-tokenhub
model: hy3-preview
api_base: https://api.tokenhub.example.com/v1
context_window: 131072
tools:
- shell
- file_write / file_read
- browser
- web_search
memory:
type: markdown
path: ~/.openclaw/memory.md
实验 19：自然语言操作系统管理
自然语言 → Shell 命令映射（实际执行）
| 自然语言指令 |
生成命令 |
执行结果 |
| 帮我看看系统是什么版本 |
cat /etc/os-release | head -2 |
Ubuntu 24.04.4 LTS ✅ |
| 检查有没有 python 进程 |
ps aux | grep -i python |
unattended-upgrades 进程 ✅ |
| 看看最近谁登录过系统 |
last -5 |
reboot 记录 ✅ |
| 检查 /var/log 最大文件 |
ls -lhS /var/log/ | head -4 |
syslog 279K ✅ |
| 查看网络监听端口 |
ss -tlnp | head -5 |
LISTEN 端口列表 ✅ |
LLM 自然语言系统管理流程
用户: "帮我清理 /var/log 下超过 7 天的日志文件"
→ LLM 解析意图: 清理日志文件
→ LLM 生成命令: find /var/log -name "*.log" -mtime +7 -delete
→ 用户确认: [Y/n]
→ Agent 执行命令
→ 返回结果: 已删除 12 个文件，释放 340MB 空间
实验 20：网络工具 — 智能体联网搜索
WebTools 实现
class WebTools:
@staticmethod
def search(query: str, engine="web"):
"""搜索接口 — 返回标题 + URL + 摘要"""
@staticmethod
def fetch_url(url: str):
"""URL 内容获取 — 返回状态码 + 内容信息"""
搜索结果示例
Query: Python asyncio 教程
Results: 3 条
[1] Python asyncio 教程 - 官方文档
→ https://docs.example.com/Python asyncio 教程
→ 关于Python asyncio 教程的官方文档和API参考...
[2] Python asyncio 教程 教程 - CSDN
→ https://blog.csdn.net/Python asyncio 教程
→ 详细介绍Python asyncio 教程的使用方法和最佳实践...
[3] Python asyncio 教程 GitHub
→ https://github.com/Python asyncio 教程
→ Python asyncio 教程的开源代码仓库，含示例和文档...
实验 21：大模型的记忆
四层记忆体系
┌─────────────────────────────────────────────────────┐
│ Layer 1: 训练记忆 (Training Memory) │
│ 来源: 预训练阶段 特征: 静态、不可修改 │
│ 示例: "北京是中国的首都"、"Python 的创始人叫 Guido" │
├─────────────────────────────────────────────────────┤
│ Layer 2: 上下文记忆 (Context Memory) │
│ 来源: 当前对话窗口 特征: 动态、受窗口大小限制 │
│ 示例: 记住用户刚才说的名字和偏好 │
├─────────────────────────────────────────────────────┤
│ Layer 3: 外部记忆 (External Memory) │
│ 来源: 文件/数据库/向量存储 特征: 持久化、可检索 │
│ 示例: MEMORY.md, ChromaDB, Pinecone │
├─────────────────────────────────────────────────────┤
│ Layer 4: 工具记忆 (Tool Memory) │
│ 来源: Function Calling 获取的实时数据 │
│ 示例: 当前时间、天气、数据库查询结果 │
└─────────────────────────────────────────────────────┘
记忆冲突解决优先级
Layer 4 (工具) > Layer 3 (外部) > Layer 2 (上下文) > Layer 1 (训练)
记忆管理策略
| 记忆类型 |
策略 |
适用场景 |
| 短期记忆 |
保留最近 N 轮对话（Sliding Window） |
单次会话 |
| 长期记忆 |
重要信息摘要 + RAG 检索 |
跨会话续接 |
| 情境记忆 |
按会话/项目隔离（Session ID） |
多项目切换 |
| 遗忘策略 |
TTL 过期 + 重要性评分 + LRU 淘汰 |
记忆空间管理 |
实验 22：经典提示词分析
七大提示词技术总览
| 技术 |
核心思路 |
Prompt 示例 |
适用场景 |
| Zero-Shot |
不给示例，直接要求 |
“将以下英文翻译成中文: …” |
简单任务 |
| Few-Shot |
给 2-3 个示例 |
“Hello→你好\nThank you→谢谢\nGoodbye→” |
格式固定任务 |
| CoT |
要求显式推理步骤 |
“请一步一步推理…” |
数学/逻辑 |
| Role Prompting |
设定专业角色 |
“你是一位 20 年经验的 Python 架构师…” |
专业问答 |
| Self-Consistency |
多次推理取共识 |
“请用 3 种不同方法计算…” |
数学验证 |
| ReAct |
交替推理+行动 |
“Thought→Action→Observation→…” |
Agent 任务 |
| ToT |
探索多路径选最优 |
“列出所有可能→评估优劣→选择最佳” |
策略规划 |
提示词设计黄金法则
1. 明确角色和任务范围
2. 给出输出格式要求
3. 提供 1-3 个示例（Few-Shot）
4. 复杂任务要求分步推理
5. 用"不要...""禁止..."排除不期望的行为
6. 关键信息放在提示词末尾（近因效应）
实验 23：文生文 — 有趣的例子
五大创意场景
| 场景 |
Prompt 技巧 |
效果展示 |
| 藏头诗 |
明确格式(五言/七言) + 藏头字序列 |
人立高楼望，工期日渐忙。智从书里取，能向语中藏。 |
| 文言文翻译 |
指定文言风格(先秦/唐宋/明清) |
“今晨，余啖二包子，饮豆漿一盂。” |
| 代码 Review |
限定评审角度(性能/安全/可读性) + 问题数量 |
函数名→语义化 + 类型提示 + docstring |
| 菜谱生成 |
给约束条件(材料/工具/时间) |
番茄蛋炒饭 + 火腿蛋饼 + 番茄蛋花汤 |
| Emoji 猜谜 |
创意输入信号 |
🐎🐎🐯🐯 → 马马虎虎 |
创意 Prompt 设计原则
1. 角色 + 约束 + 格式 = 精准输出
2. 越具体越好的约束（不是"写首诗"而是"五言绝句+藏头+押韵"）
3. 用示例锚定期望（Few-shot 效果远超 Zero-shot）
4. 负面约束同样重要（"不要现代词汇""不要超过4行"）
第二部分：文生图（实验 24）
实验 24：文生图 — API 调用
DALL-E 格式 API 请求
{
"model": "dall-e-3",
"prompt": "一只可爱的橘猫坐在窗台上看日落，宫崎骏风格，暖色调，油画质感",
"n": 1,
"size": "1024x1024",
"quality": "standard",
"response_format": "url"
}
六大主流文生图模型对比
| 模型 |
厂商 |
分辨率 |
类型 |
特点 |
价格 |
| DALL-E 3 |
OpenAI |
1024² |
闭源/API |
理解力强，文字渲染好 |
$0.040/image |
| Stable Diffusion 3 |
Stability AI |
1024² |
开源 |
可控性强，社区生态丰富 |
免费/本地 |
| Midjourney v6 |
Midjourney |
2048² |
闭源/Discord |
艺术感最强，画质顶级 |
$10-60/月 |
| FLUX.1 |
Black Forest Labs |
1024² |
开源 |
文字渲染最佳，人体结构好 |
免费/本地 |
| 混元文生图 |
腾讯 |
1024² |
闭源/API |
中文理解好，国风风格 |
按量计费 |
| CogView4 |
智谱 |
2048² |
闭源/API |
支持中文提示词，速度快 |
按量计费 |
文生图 Prompt 设计六要素
1. 主体描述 → 谁/什么? 在做什么? (一只猫/坐着/看日落)
2. 风格指定 → 画风/艺术家/技法 (宫崎骏风格/油画/水彩)
3. 色彩光线 → 色调/光源/氛围 (暖色调/黄金时刻/柔光)
4. 构图视角 → 镜头角度/景别 (特写/中景/广角/俯视)
5. 质量参数 → 精细度/渲染方式 (4K/照片级真实/概念艺术)
6. 负面提示 → 不要什么 (--no blurry, deformed, extra fingers)
第三部分：环境与趋势（实验 25-26）
实验 25：传统行业与新媒体的结合 — 发展趋势
行业融合矩阵
┌────────────────┬──────────────────┬──────────────────┐
│ 传统行业 │ 新媒体赋能方式 │ AI 加持 │
├────────────────┼──────────────────┼──────────────────┤
│ 教育 │ 在线课程/短视频 │ AI 个性化辅导 │
│ 医疗 │ 在线问诊/科普 │ AI 辅助诊断 │
│ 农业 │ 直播带货/溯源 │ AI 病虫害识别 │
│ 制造业 │ 工业直播/品牌IP │ AI 质量检测 │
│ 餐饮 │ 探店视频/外卖 │ AI 智能推荐 │
│ 法律 │ 普法短视频/咨询 │ AI 合同审查 │
│ 金融 │ 财经博主/投教 │ AI 量化交易 │
│ 建筑 │ BIM可视化/VR看房 │ AI 方案生成 │
│ 出版 │ 电子书/有声书 │ AI 辅助写作 │
│ 艺术 │ NFT/数字藏品 │ AI 生成艺术 │
└────────────────┴──────────────────┴──────────────────┘
六大关键趋势
| 趋势 |
说明 |
影响 |
| 内容民主化 |
AI 降低创作门槛，人人可成为内容生产者 |
内容供给暴增，质量分化加剧 |
| 交互升级 |
图文→视频→直播→VR/AR→AI 对话 |
沉浸式体验成为新标准 |
| 个性化 |
AI 推荐算法让"千人千面"成为现实 |
精准营销，用户黏性提升 |
| 去中心化 |
Web3/区块链重塑内容分发和版权 |
创作者收益模型重构 |
| AI Native |
新一代产品从设计之初就内置 AI 能力 |
传统产品面临降维打击 |
| 虚实融合 |
数字孪生 + AIGC 重塑行业工作流 |
效率革命，新职业涌现 |
实验 26：新媒体内容产品的价格决定因素
内容定价模型
┌─────────────────────────────────────────────────────┐
│ 内容价值 = f(质量, 稀缺性, 时效性, 品牌) │
├─────────────────────────────────────────────────────┤
│ P = (Q × α + S × β + T × γ + B × δ) × M │
│ │
│ P = 最终价格 │
│ Q = 内容质量 (0-10) α = 质量权重 (30%) │
│ S = 稀缺性 (0-10) β = 稀缺性权重 (25%) │
│ T = 时效性 (0-10) γ = 时效性权重 (15%) │
│ B = 品牌溢价 (0-10) δ = 品牌权重 (20%) │
│ M = 市场规模系数 │
└─────────────────────────────────────────────────────┘
六大定价因素详解
| 因素 |
权重 |
关键指标 |
| 内容质量 |
30% |
原创性、深度、专业性、信息密度、可落地性 |
| 稀缺性 |
25% |
独家信息、一手数据、技术壁垒、行业门槛 |
| 品牌溢价 |
20% |
个人IP/机构品牌、粉丝规模、历史口碑 |
| 时效性 |
15% |
热点首发、技术迭代速度、季节需求 |
| 分发渠道 |
5% |
平台分成、流量成本、付费转化率 |
| 市场需求 |
5% |
受众购买力、竞品定价、替代品可得性 |
AI 对定价的冲击
AI 生成内容 → 边际成本趋近于零
├── 基础内容价格将大幅下降（模板化、可 AI 替代）
├── 高价值内容溢价空间反而扩大（人类经验/情感/创意 不可替代）
└── 内容筛选和策展能力成为新的价值点
实验总结
核心知识点地图
┌─────────────────────────────────────────────────────────┐
│ AI LLM 知识体系 │
├─────────────────────────────────────────────────────────┤
│ │
│ [基础层] API调用 → Role/Message → Temperature/MaxTokens│
│ ↓ │
│ [提示词] System Role → 角色人设 → 人格文件 → 输出约束 │
│ ↓ │
│ [对话层] History → Session → Memory → Context Window │
│ ↓ │
│ [工程层] Flask后端 → 纯前端 → Markdown渲染 → 时间感知 │
│ ↓ │
│ [Agent层] Function Calling → Tool Use → Shell → 联网 │
│ ↓ │
│ [进阶层] Context Engineering → Prompt Engineering │
│ ↓ │
│ [应用层] 文生图 API → 新媒体融合 → 内容定价 │
└─────────────────────────────────────────────────────────┘
踩坑记录
| # |
问题 |
原因 |
解决 |
| 1 |
blinker 安装冲突 |
Debian 预装 blinker 1.7.0 与 pip 冲突 |
pip install --ignore-installed blinker |
| 2 |
Flask __version__ 弃用警告 |
Flask 3.2 移除此属性 |
改用 importlib.metadata.version("flask") |
| 3 |
timedelta 运算符错误 |
timedelta % int 不合法 |
括号调整: timedelta(days=(7 - wkday) % 7) |
| 4 |
混元 API 免费额度耗尽 |
TokenHub 免费试用到期 |
代码使用模拟输出，标注真实 API 格式 |
| 5 |
Markdown 渲染时中文引号问题 |
直引号与弯引号冲突 |
使用扩展 smarty 统一处理 |
实验数据总览
| 指标 |
数据 |
| 实验总数 |
26 个 |
| 实际执行 |
全部在服务器 ecs-d2c2-0001 上机 |
| 代码总量 |
2 个 Python 脚本（~62KB） |
| 服务器 |
华为云 FlexusX (8vCPU/16GiB, Ubuntu 24.04) |
| 依赖环境 |
Python 3.12.3 / Flask 3.1.3 / Markdown 3.10.2 |
| 核心产出 |
API 请求/响应格式、6 种提示词技术、5 种 Context 策略、Function Calling 工作流、文生图 API 请求体 |
下一篇预告: 继续深挖 AI Agent 实战 — 从 Function Calling 到多 Agent 协作
服务器: 华为云 FlexusX ecs-d2c2 系列 | 环境: Ubuntu 24.04 + Python 3.12 + Flask
1
0
已为社区贡献17条内容
所有评论(0)