Personal Prompts
技术理解
技术名片
markdown
# 技术名片
请用一段不超过 200 字的话介绍 **{{技术点}}**，要求：
- 先准确解释其核心概念；
- 再简要说明它的主要用途或重要性；
- 语言简洁流畅，兼具专业性和可读性；
- 直接输出介绍，不要添加任何多余说明。核心概念
markdown
请围绕 **{{ 技术点 }}** 原理，系统整理其核心概念与必要性。
### 1. 信息来源约束
基于该技术的官方文档、标准规范或权威资料（如 RFC、官方手册、白皮书等）进行归纳，避免主观扩展或非主流解释。
### 2. 核心概念定义
- 通过列表罗列构成该技术原理所必需的核心概念（控制在 3–15 个，根据技术特性可适当增减）；
- 每个概念需满足：1. 是理解该技术不可或缺的组成部分；2. 具有明确边界（避免过于宽泛或过细）。
建议按维度组织（如：结构 / 流程 / 机制等）。
### 3. 必要性说明（逐项）
对每个核心概念，分别说明：
- 其在整体原理中的作用；
- 若缺失该概念，会导致什么问题或能力缺失（即“不可替代性”）。
### 4. 典型场景案例（概念协同演示）
引用一个典型场景（优先参考官方示例，尽量**经典**）来介绍上述核心概念，要求：
- 明确目标；
- 明确参与角色（如客户端 / 服务端 / 调度器等）；
- 按步骤描述执行流程（步骤 1, 步骤 2...），关键流程步骤尽量完整表达原理，不宜过粗，也不能太细节；
- 每个步骤标注：当前涉及的核心概念及具体作用，确保能够体现各核心概念如何协同工作，而非孤立存在。
### 6. 不确定性处理
若对技术点理解和“核心概念”选取存在歧义，暂停任务，提示用户补充限定条件后再继续。极简示例
markdown
请生成一个 **精简可运行示例**，用于演示技术点 **{{ 技术点 }}** 的核心原理。示例应直接展示核心概念，不引入额外复杂逻辑或多余文件。
## 工作流程
1. 列出上述技术点的核心概念。
2. 生成对应的示例步骤，说明每步必要性。
3. 询问用户是否接受或补充信息，等待用户确认。
4. 用户确认后生成完整可运行示例及代码。
## 生成要求
- **依赖**：仅引入必要库；
- **功能**：示例尽量精简、聚焦核心概念（优先参考官方示例），保证原理清晰；
- **元素**：示例必须体现 **核心概念元素** 并注释说明；
- **代码**：代码完整，必须可直接运行；
- **注释**：模块和核心流程都应有清晰注释；
- **日志**：增加必要打印，展示调用流程和关键决策。
## 代码要求
- 优先 Python；
- 优先使用 Flask 实现 HTTP Server；
- 需要发起测试请求时，单独写一个 client.py；
- 需要接入**实际大模型**时，默认使用用户配置好的自定义模型环境变量 MODEL_BASE_URL、MODEL_NAME、API_KEY；
- 变量名清晰有意义（如 `user_input`）；
- 忽略错误处理和边界情况；
- 输入输出精简，突出核心逻辑。
如果上述要求不匹配该场景示例，请在生成代码前和用户确认。
## 用户内容要求（重要）
{{ 可选，根据实际情况由用户自行补充，举例如下： }}
- 1 个主调用程序 main，1 个 registry，1 个 calculator，2 个 **对等** Agent（分别具备加法和减法）；
- 每个 Agent 独立脚本运行，由用户在不同终端启动，Agent 内部 Client、Server 边界鲜明；
- 每个 Agent 都要起作用：main → calculator → agent_add/agent_sub；
- 支持 Agent 动态发现（Well-Known URI）；
- 需要 Agent LLM 决策，动态发现其他 Agent 而不是硬编码；
- 体现 Agent Card、Task、Message、Artifact 概念。一图阐述
markdown
请生成一张 PlantUML 格式的流程图阐述上述示例，要求：
1. **风格：** 使用默认样式（如非必要，禁止自定义样式），不使用渐变、阴影、emoji 或装饰性图标；
2. **流程：** 拆解关键步骤，采用“数字 + 动宾短语”方式标注（如 1. 发起请求，2. 验证权限）；
3. **内容：** 核心概念角色和流程关系清晰明了，尽量减少干扰元素，不包含异常处理路径；
4. **注释：** 关键模块或流程可以添加 `note` 进行说明，每处说明不超过 20 字，根据必要性不宜过多。