Update nexus wiki content
This commit is contained in:
48
wiki/sources/Hermes-Agent-配置笔记.md
Normal file
48
wiki/sources/Hermes-Agent-配置笔记.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Hermes Agent 配置笔记"
|
||||
type: source
|
||||
tags: ["hermes", "agent", "configuration"]
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/Hermes Agent 配置笔记]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Hermes Agent 的多角色配置与 Telegram 集成实战
|
||||
- 问题域：Vibe Coding 多角色 Agent 场景下的身份隔离、Telegram Bot 连接与国内网络代理问题
|
||||
- 方法/机制：SOUL.md 角色人设 + AGENTS.md 项目背景双文件分层；`hermes profile` 创建独立 Agent 实例；Gateway 代理配置解决 Telegram 连接问题
|
||||
- 结论/价值：提供了一套完整的 Hermes Agent 多角色配置体系，覆盖身份定义、Profile 隔离、Telegram 接入、网络代理全链路
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- SOUL.md 定义角色人设（全局生效，随 Agent 走），AGENTS.md 定义项目背景（项目级生效，随项目走），两者分工明确
|
||||
- `hermes profile create --clone` 创建独立 Agent 实例，每个 Profile 拥有独立的 SOUL.md、配置、记忆、会话历史和技能
|
||||
- Telegram Bot 无响应的根因通常是 Gateway 未启动、Token 配错 Profile 或用户 ID 未加入白名单
|
||||
- Telegram 在国内被封，需在 Profile 的 .env 中配置代理（HTTPS_PROXY/HTTP_PROXY）才能正常连接
|
||||
|
||||
## Key Quotes
|
||||
> "配置 token ≠ gateway 在运行，新 profile 需要单独启动。" — Telegram Bot 无响应的最常见原因
|
||||
> "每个 profile 的 .env 需要单独配置，互不共享。" — 代理配置隔离原则
|
||||
> "同一个 token 被两个 gateway 同时使用会导致两个 gateway 互相冲突，都无法正常收消息。" — Token 独占性要求
|
||||
|
||||
## Key Concepts
|
||||
- [[SOUL]]：角色人设文件，定义 Agent 的身份、思维方式、沟通风格，位于 `~/.hermes/SOUL.md`
|
||||
- [[AGENTS-md]]：项目背景文件，定义技术栈、架构、开发约定，位于项目根目录的 `AGENTS.md`
|
||||
- [[Multi-Profile-Isolation]]：多 Profile 隔离机制，每个 Profile 拥有独立的配置、会话、记忆，实现角色分离
|
||||
- [[Telegram-Bot-Gateway]]：Telegram Bot 通过 Hermes Gateway 接入，Gateway 需单独启动
|
||||
- [[Proxy-Configuration]]：代理配置，通过 HTTPS_PROXY/HTTP_PROXY 环境变量解决 Telegram 在国内的连接问题
|
||||
|
||||
## Key Entities
|
||||
- [[Marty-Cagan]]：《Inspired》作者，产品经理角色命名来源
|
||||
- [[Werner-Vogels]]：Amazon CTO，架构师角色命名来源
|
||||
- [[Hermes-Agent]]：本文档的主体工具，Vibe Coding 多角色 Agent 框架
|
||||
|
||||
## Connections
|
||||
- [[Hermes-Agent]] ← configured_by ← [[SOUL]]
|
||||
- [[Hermes-Agent]] ← configured_by ← [[AGENTS-md]]
|
||||
- [[Multi-Profile-Isolation]] ← enables ← [[Hermes-Agent]]
|
||||
- [[Telegram-Bot-Gateway]] ← depends_on ← [[Hermes-Agent]]
|
||||
- [[Proxy-Configuration]] ← solves ← [[Telegram-Bot-Gateway]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突内容
|
||||
41
wiki/sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md
Normal file
41
wiki/sources/Scrapy---Playwright-抓取TikTok-Shop-Data.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: "Scrapy + Playwright 抓取TikTok Shop Data"
|
||||
type: source
|
||||
tags: [scrapy, playwright, tiktok-shop, python, docker, web-scraping]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/Scrapy + Playwright 抓取TikTok Shop Data.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Scrapy + Playwright 技术栈抓取 TikTok Shop 店铺数据
|
||||
- 问题域：TikTok Shop 电商数据采集、Web 页面爬取的环境配置
|
||||
- 方法/机制：通过 Python venv 隔离环境，安装 scrapy + scrapy-playwright，并配置 Playwright Chromium 浏览器，实现动态页面渲染与数据抓取
|
||||
- 结论/价值：提供了一套完整的技术方案，用于在 Docker 环境中运行 TikTok Shop 数据爬虫
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 开发者通过创建 Python venv 隔离项目依赖，避免与系统环境冲突
|
||||
- scrapy-playwright 插件将 Playwright（浏览器自动化）与 Scrapy（爬虫框架）结合，支持 JS 渲染页面抓取
|
||||
- Docker 容器内运行需要额外配置 venv 和 PATH 环境变量
|
||||
|
||||
## Key Quotes
|
||||
> "source venv/bin/activate" — 进入 Python 虚拟环境，终端前缀出现 `(venv)` 表示激活成功
|
||||
> "scrapy runspider tiktok_shop_spider.py -a shop_url=\"https://www.tiktok.com/shop/store/aopuro/7495894041403296077\"" — 运行 TikTok Shop 爬虫的命令示例
|
||||
> "python -c \"from playwright.sync_api import sync_playwright; print('Playwright OK')\"" — 验证 Playwright 安装是否成功的命令
|
||||
|
||||
## Key Concepts
|
||||
- [[Scrapy]]：Python 开源爬虫框架，支持异步 HTTP 请求和数据管道
|
||||
- [[Playwright]]：微软开发的浏览器自动化工具，支持 Chromium/Firefox/WebKit，支持 JS 渲染页面抓取
|
||||
- [[scrapy-playwright]]：连接 Scrapy 与 Playwright 的中间件，使 Scrapy Spider 能控制 Playwright 浏览器
|
||||
- [[Python venv]]：Python 虚拟环境工具，用于隔离项目依赖，避免包版本冲突
|
||||
|
||||
## Key Entities
|
||||
- [[TikTok Shop]]：字节跳动旗下的电商平台，本文档的爬取目标
|
||||
|
||||
## Connections
|
||||
- [[TikTok Shop - Apache Superset Dashboard设计思路]] ← 关联 ← [[Scrapy + Playwright 抓取TikTok Shop Data]]
|
||||
- [[可自动化、可扩展、AI增强的电商数据采集与处理系统]] ← 属于 ← [[Scrapy + Playwright 抓取TikTok Shop Data]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无发现冲突内容）
|
||||
44
wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md
Normal file
44
wiki/sources/WSL2-中-Docker-容器访问宿主机代理.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "WSL2 中 Docker 容器访问宿主机代理"
|
||||
type: source
|
||||
tags: [wsl, docker, proxy]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/WSL2 中 Docker 容器访问宿主机代理]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：WSL2 环境下 Docker 容器如何正确访问宿主机（Windows）上运行的代理服务
|
||||
- 问题域：WSL2 网络隔离场景下的容器代理配置
|
||||
- 方法/机制：使用 Docker 内置 DNS 名称 `host.docker.internal` 替代 `127.0.0.1`/`localhost`，Docker Desktop/WSL2 环境自动解析为宿主机 IP
|
||||
- 结论/价值：避免容器内 localhost 指向自身导致的代理访问失败；适用于 pip/apt-get/curl 等各种命令的代理配置
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **WSL2 Docker 容器 + 宿主机代理**：在 WSL2 环境下运行的 Docker 容器，必须使用 `host.docker.internal` 而非 `127.0.0.1` 访问宿主机代理，因为容器内的 `127.0.0.1` 指向容器自身而非宿主机
|
||||
- **pip 代理配置**：Dockerfile 中 `pip install --proxy http://host.docker.internal:10808` 可正确走宿主机代理
|
||||
- **apt 代理配置**：`apt-get -o Acquire::http::Proxy="http://host.docker.internal:10808" update` 可正确走宿主机代理
|
||||
- **curl 代理配置**：`curl -x http://host.docker.internal:10808 <url>` 可正确走宿主机代理
|
||||
- **Clash 代理前提**：代理软件（如 Clash）必须开启「允许局域网连接」选项
|
||||
|
||||
## Key Quotes
|
||||
> "容器内的 `127.0.0.1` 指向容器自身，无法访问宿主机代理。需用 Docker 内置 DNS 名称替代。" — 核心问题说明
|
||||
> "避免在 Dockerfile 中硬编码 `ENV HTTPS_PROXY=http://127.0.0.1:...`，容器内无法访问" — Dockerfile 最佳实践
|
||||
|
||||
## Key Concepts
|
||||
- [[DockerHostNetworking]]：`host.docker.internal` 是 Docker 提供的特殊 DNS 名称，用于容器访问宿主机网络，属于 DockerHostNetworking 概念的 Linux/WSL2 实现方式
|
||||
|
||||
## Key Entities
|
||||
- [[WSL2]]：Windows Subsystem for Linux 2，本文档的技术背景平台；WSL2 默认 NAT 网络模式下容器内 `127.0.0.1` 指向自身
|
||||
- [[Clash]]：本文档示例中宿主机上运行的代理软件，需开启「允许局域网连接」才能被容器访问
|
||||
|
||||
## Connections
|
||||
- [[DockerHostNetworking]] ← documented_in ← [[WSL2-中-Docker-容器访问宿主机代理]]（本文档记录了 `host.docker.internal` 在 WSL2 Docker 场景下的具体用法）
|
||||
- [[WSL2-中-Docker-容器访问宿主机代理]] ← extends ← [[WSL2 启动与网络配置指南]]（本文档补充了 WSL2 Docker 容器访问宿主机代理这一具体场景）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[n8n-docker-配置-telegram-代理-troubleshooting]] 细节差异：
|
||||
- 冲突点：`host.docker.internal` 的可用性前提
|
||||
- 当前观点（n8n 文档）：需要 `extra_hosts: - "host.docker.internal:host-gateway"` 配置才能使用
|
||||
- 对方观点（本文档）：Docker Desktop（Windows/Mac）及 WSL2 环境下均可用，未提及 `extra_hosts`
|
||||
- 说明：两者可能均正确，差异在于 Docker Desktop for Windows 内置支持 vs 纯 WSL2（无 Docker Desktop）的不同配置要求
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Your AI Isn't \"Stupid\" — It Just Needs a Better Harness | Lychee Technology Engineering Blog"
|
||||
type: source
|
||||
tags:
|
||||
- "clippings"
|
||||
- "agentic-ai"
|
||||
- "harness-engineering"
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/Your AI Isn't Stupid — It Just Needs a Better Harness Lychee Technology Engineering Blog]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Harness Engineering——为 AI Agent 设计"马具"的系统学科，将 LLM 嵌入严格代码脚手架中实现可靠的多步自主执行
|
||||
- 问题域：AI Agent 在长周期自主任务中的崩溃问题（10步崩塌、上下文溢出、Schema 漂移、状态丢失）
|
||||
- 方法/机制：7层 Harness Stack（Cognition → Tools → Contracts → Orchestration → Memory → Evaluation → Constraints & Recovery），每个边界的输入输出验证，每个工具调用的幂等重试，状态外部化持久化
|
||||
- 结论/价值：Agent 失败的原因不是模型弱，而是系统设计缺失；最成功的构建者不是写最好代码的人，而是设计最好"马具"的人
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- LLM 本身不是 Agent，Agent = LLM + 代码脚手架（状态管理 + 恢复工作流）
|
||||
- Prompt Engineering → Context Engineering → Harness Engineering 是演进而非替代，后者吸收前两者并增加执行控制层
|
||||
- 约束（constrain）而非指令（instruct）——程序化限制比自然语言提示更可靠
|
||||
- 每个 LLM 输出必须经过 Schema 验证器，拒绝格式不符的输出，而非依赖模型自我修正
|
||||
- 状态必须外部化——context window 是易失的，磁盘文件才是持久的
|
||||
- 每个工具调用必须幂等——单步失败只重试该步，不重启整个管道（局部失败而非全局崩溃）
|
||||
- Context Reset：当 token 使用率超过 70% 阈值时，保存状态、终止当前实例、启动全新 Agent
|
||||
- Self-Grading Illusion：LLM 无法有效评估自身输出——同一套权重既生成输出又评判输出，结构上存在缺陷
|
||||
- Sprint Contract：Generator 和 Evaluator 必须完全独立，Evaluator 在干净上下文中仅接收输出和成功标准，不读 Generator 的思维链
|
||||
- Memory Consolidation：周期性压缩 Agent 累积的工作日志（实测 32K 噪声日志压缩至 7K），防止记忆膨胀和矛盾
|
||||
- 最小可行 Harness（Day 1 可构建）：state.json + retry wrapper + schema validator + tool output truncation
|
||||
|
||||
## Key Quotes
|
||||
> "The problem usually isn't the horse. It's the reins." — 核心隐喻：模型是马，Harness 是缰绳
|
||||
> "A prompt that says 'always respond in valid JSON' is a hope. A schema validator that rejects malformed output is a guarantee." — 约束优于指令
|
||||
> "The model speaks in probabilities. The harness must speak in types." — Schema drift 的根源
|
||||
> "Fail locally, not globally." — 单步失败只重试该步，不重启整个管道
|
||||
|
||||
## Key Concepts
|
||||
- [[Harness-Engineering]]：为 LLM 设计的系统脚手架学科，使 Agent 能在长周期自主任务中可靠执行——包含约束、外部化、验证、恢复四个设计原则
|
||||
- [[Agent-Collapse]]（10-Step Collapse）：Agent 在多步任务中途开始幻觉或输出崩溃的现象——根因是 context window 被静默截断或无 Schema 验证
|
||||
- [[Context-Anxiety]]：当 context window 使用率超过 70% 或延迟升高时，模型表现出"仓促"行为——跳过步骤或过早完成任务
|
||||
- [[Context-Reset]]：当 Context Anxiety 触发时，Harness 将状态保存至磁盘、终止当前实例、启动全新 Agent 的程序化操作
|
||||
- [[Schema-Drift]]：同一 LLM 在不同调用中对同一字段生成不同数据类型（如 price 一次为 string 一次为 float）的静默错误
|
||||
- [[Sprint-Contract]]：Generator Agent 和独立 Evaluator Agent 在工作开始前约定的可测试"完成"定义，Evaluator 在干净上下文中仅接收输出和标准
|
||||
- [[Self-Grading-Illusion]]：LLM 无法有效评估自身输出的结构性缺陷——生成输出的权重位置决定了它不能可靠地评判该输出
|
||||
- [[Memory-Consolidation]]：Agent 空闲时周期性压缩累积工作日志（去重 + 解决矛盾 + 写入精简状态文件）的机制
|
||||
- [[State-Externalization]]：将任务状态（pending/in-progress/completed）写入磁盘文件而非仅保存在 context window 的实践
|
||||
- [[Idempotency]]：工具调用的幂等性保证——失败时精确重试该步，不污染全局状态也不重复已完成工作
|
||||
- [[7-Layer-Harness-Stack]]：Cognition / Tools / Contracts & Interfaces / Orchestration / Memory & State / Evaluation & Observation / Constraints & Recovery
|
||||
|
||||
## Key Entities
|
||||
- [[Lychee-Technology]]：发布本 engineering blog 的公司，专注于 production-grade AI 系统设计
|
||||
- [[Anthropic]]：在 steering vectors 和内部模型表征方面的研究被本文引用，用于论证 Self-Grading Illusion
|
||||
|
||||
## Connections
|
||||
- [[Harness-Engineering]] ← extends ← [[Agent-Collapse]]（分析根因并提供系统性解决方案）
|
||||
- [[7-Layer-Harness-Stack]] ← is_a ← [[Harness-Engineering]]（具体实现框架）
|
||||
- [[Context-Reset]] ← is_a ← [[Context-Anxiety]]（问题的程序化解决方案）
|
||||
- [[Sprint-Contract]] ← resolves ← [[Self-Grading-Illusion]]（通过角色分离打破结构性缺陷）
|
||||
- [[Memory-Consolidation]] ← addresses ← State Management（解决长期运行的记忆膨胀问题）
|
||||
- [[Hermes-Agent]] ← implements ← [[7-Layer-Harness-Stack]]（若 Hermes Agent 实现了完整 Harness 架构，可关联本文）
|
||||
- [[Designing-for-Agentic-AI]] ← related ← [[Harness-Engineering]]（可补充外部设计原则文档）
|
||||
|
||||
## Contradictions
|
||||
- 无与其他 Wiki 页面的直接冲突内容。本文可与 [[Designing-for-Agentic-AI]] 互补阅读——后者侧重设计原则，本文侧重工程实现层次。
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Academic Anthropologist"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
sources: []
|
||||
last_updated: 2026-04-25
|
||||
tags: ["agent-personality", "anthropology", "cultural-design", "societal-modeling"]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-anthropologist.md]]
|
||||
- [[Agent/agency-agents/academic/academic-anthropologist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 角色设计——将文化人类学家田野调查的方法论与人格特质注入 AI Agent，使其能够构建文化上自洽的社会系统
|
||||
- 问题域：如何让 AI 在设计虚构或真实文化时避免刻板印象、文化拼贴（culture salad），而是基于人类学理论构建功能自洽的社会体系
|
||||
- 方法/机制：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳、范热内普）、经济人类学（莫斯、波拉尼）的理论框架
|
||||
- 结论/价值：每个文化元素必须有社会功能（社会凝聚、资源管理、身份认同、冲突解决）；先功能后美学；亲属制度是基础设施
|
||||
- 核心主题：为 AI Agent 定义文化人类学家角色——设计具有文化内在一致性的社会系统，涵盖亲属制度、信仰体系、仪式结构和交换机制
|
||||
- 问题域：避免文化设计中的刻板印象（文化沙拉）、唯美主义（功能优先于美学）、高尚野蛮人谬误；确保每种文化元素服务于社会功能
|
||||
- 方法/机制：结构主义分析（Levi-Strauss）、厚描述（Geertz）、实践理论（Bourdieu）、功能分析（Malinowski/Durkheim）、礼物经济（Mauss）、 Polanyi 交换分类、阈限与 communitas（Turner）、文化生态学（Steward）
|
||||
- 结论/价值：文化设计必须从生计模式出发，依次构建社会组织（骨架）→ 信仰体系（血肉）→ 内在一贯性检查；文化借贷需理解原语境，不做表面美学移植
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI Agent 在设计文化时应优先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"
|
||||
- 亲属制度决定了继承、政治联盟、居住模式和冲突解决方式，是社会的骨架，不应跳过
|
||||
- 避免"高贵的野蛮人"偏见——前工业社会是复杂适应系统，有自身的政治、冲突和创新
|
||||
- 文化借用必须理解原始语境，不能仅凭表面美学混搭不同文化元素
|
||||
- 每个文化都有内部张力和矛盾（没有乌托邦），应主动识别
|
||||
- AI Agent 作为文化人类学家，必须为每种文化实践追问："这种做法为这些人们解决了什么问题？"
|
||||
- 亲属制度是社会基础设施——决定继承、政治联盟、居住模式和冲突解决方式，不能跳过
|
||||
- 文化借贷必须先理解元素在原语境中的含义，再考虑其在新系统中的互动，不能混搭不同文化传统
|
||||
- 生态系统分析必须从生计模式（觅食/游牧/农业/工业）出发，这是塑造整个社会结构的底层基础
|
||||
- 文化内部矛盾和张力必须被识别——没有乌托邦，每种文化都有其内在冲突
|
||||
|
||||
## Key Quotes
|
||||
> "No culture is random — every practice is a solution to a problem you might not see yet." — Anthropologist Agent 核心理念
|
||||
> "Emic before etic: First understand how the culture sees itself before applying outside analytical categories." — 方法论原则
|
||||
> "No culture is random — every practice is a solution to a problem you might not see yet" — Anthropologist Agent 核心信条
|
||||
> "Function before aesthetics. Before asking 'does this ritual look cool?' ask 'what does this ritual do for the community?'" — 功能分析优先原则（Durkheim/Malinowski）
|
||||
> "In a patrilineal society, your father's brother's children are your siblings, not your cousins. This changes everything about inheritance." — 亲属制度的具体细节如何决定社会结构
|
||||
|
||||
## Key Concepts
|
||||
- [[Thick Description]]：格尔茨的"厚描"理论，将文化实践视为文本阅读，理解参与者的主观意义
|
||||
- [[Liminality]]：特纳的阈限概念，设计转化性仪式体验的关键框架
|
||||
- [[Gift Economy]]：莫斯的礼物经济理论，基于互惠和社会义务构建交换系统
|
||||
- [[Cultural Coherence]]：文化自洽性检验——每个文化元素必须有社会功能，内部一致
|
||||
- [[Rites of Passage]]：范热内普的通过仪式模型——分离 → 阈限 → 融合
|
||||
- [[Structuralism]]：Levi-Strauss 的结构主义——通过二元对立和变换来组织神话与分类
|
||||
- [[Symbolic-Anthropology]]：Geertz 的"厚描述"——将文化实践作为文本阅读，理解参与者的主观意义
|
||||
- [[Practice-Theory]]：Bourdieu 的实践理论——文化如何通过日常实践再生产和变革
|
||||
- [[Functionalism]]：Durkheim/Malinowski 功能主义——每种社会制度服务于维持社会凝聚力的功能
|
||||
- [[Gift-Economy]]：Mauss 的礼物经济——基于互惠和社会义务的交换系统设计
|
||||
- [[Liminality]]：Turner 的阈限与 communitas——设计转化性仪式体验（分离→阈限→整合，van Gennep 模型）
|
||||
- [[Kinship-System]]：亲属制度——社会基础设施，决定继承、联盟和居住模式（双系/父系/母系/双重继嗣）
|
||||
- [[Cultural-Ecology]]：Steward/Rappaport 文化生态学——环境如何塑造文化，文化又如何反过来塑造环境
|
||||
- [[Polanyi-Exchange]]：Polanyi 的交换分类——互惠（reciprocity）/ 再分配（redistribution）/ 市场（market）
|
||||
|
||||
## Key Entities
|
||||
- [[Claude Lévi-Strauss]]：结构人类学创始人，二元对立分析框架
|
||||
- [[Clifford Geertz]]：象征人类学，"厚描"概念提出者
|
||||
- [[Pierre Bourdieu]]：实践理论，场域、惯习、资本概念
|
||||
- [[Victor Turner]]：仪式过程分析，阈限与社群共同性（communitas）
|
||||
- [[Arnold van Gennep]]：通过仪式三阶段模型
|
||||
- [[Marcel Mauss]]：《礼物》作者，礼物经济理论
|
||||
- [[Mary Douglas]]：神圣/世俗边界分析
|
||||
- [[Émile Durkheim]]：功能分析学派，社会凝聚理论
|
||||
- [[Bronisław Malinowski]]：功能主义，文化实践满足基本需求
|
||||
- [[Karl Polanyi]]：经济人类学，互惠、再分配、市场三元框架
|
||||
- [[Marvin Harris]]：文化唯物主义，从生存模式推演文化
|
||||
- [[Claude-Levi-Strauss]]：结构主义创始人，发展了通过二元对立理解神话与社会的系统性框架
|
||||
- [[Clifford-Geertz]]：符号人类学"厚描述"方法论的提出者，强调理解文化参与者自身视角
|
||||
- [[Pierre-Bourdieu]]：实践理论和社会资本概念的提出者，连接文化实践与社会结构
|
||||
- [[Victor-Turner]]：阈限（liminality）和 communitas 概念，提出仪式过程中的社会转化机制
|
||||
- [[Bronislaw-Malinowski]]：功能主义人类学创始人，强调文化实践满足人类基本需求
|
||||
- [[Marcel-Mauss]]：《礼物》作者，系统阐述礼物经济中的互惠义务机制
|
||||
- [[Mary-Douglas]]：《洁净与危险》作者，分析神圣/世俗边界与禁忌体系的社会功能
|
||||
|
||||
## Connections
|
||||
- [[Academic Historian]] ← discipline_similarity ← [[Academic Anthropologist]]
|
||||
- [[Academic Geographer]] ← discipline_similarity ← [[Academic Anthropologist]]
|
||||
- [[Academic Narratologist]] ← discipline_similarity ← [[Academic Anthropologist]]
|
||||
- [[Agents-Orchestrator]] ← extends ← [[Academic-Anthropologist]]：Anthropologist Agent 是 Agency 系统中负责文化设计的专业子 Agent
|
||||
- [[Unreal-World-Builder]] ← depends_on ← [[Academic-Anthropologist]]：游戏世界构建需 Anthropologist 提供文化内在一致性原则
|
||||
- [[Structuralism]] ← foundational ← [[Cultural-System-Design]]：结构主义为复杂社会系统设计提供分类框架
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
- 与其他 Agent 设计文档（如游戏/销售类 Agent）的冲突：**无**。Anthropologist Agent 是领域专精的社会文化设计工具，与其他功能性 Agent 定位不重叠，不产生内容冲突。
|
||||
- 与 Noble Savage（高贵的野蛮人）叙事的冲突：本文档明确批判"前工业社会更纯粹/更接近自然"的观点，强调所有社会都是具有自身政治、冲突和创新的复杂自适应系统。
|
||||
|
||||
@@ -2,56 +2,52 @@
|
||||
title: "Academic Geographer"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
date: 2026-05-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-geographer.md]]
|
||||
- [[Agent/agency-agents/academic/academic-geographer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 中的地理学家角色（Geographer Agent）—— 专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性
|
||||
- 问题域：如何让 AI Agent 能够像真正的地理学家一样，基于物理规律（板块构造、气候系统、水文地理）构建可信的虚拟世界，并在地理约束与人类文明之间建立逻辑联系
|
||||
- 方法/机制：通过严格的地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造 → 气候 → 水文 → 生物群落 → 人类定居）、交付物模板（地理连贯性报告、气候系统设计）来驱动 Agent 行为
|
||||
- 结论/价值：该 Agent 为 AI 世界构建提供了一个地理学家的思维框架，强调系统性、因果性和物理一致性，避免常见的地理设定错误
|
||||
- 核心主题：AI Agent 系统中的地理学家角色——专注于物理地理与人文地理的跨学科专家，帮助构建地理逻辑自洽的虚拟世界
|
||||
- 问题域：如何在 Agent 世界构建中保持地理要素（气候、地形、水系、生物群落、聚落模式）之间的物理一致性
|
||||
- 方法/机制：六步工作流（板块构造→气候系统→水文学→生物群落→人类聚落→贸易路线），以及详细的地理一致性报告和气候系统设计模板
|
||||
- 结论/价值：为 Agent 世界构建提供系统化的地理推理框架，避免常见的地理逻辑错误
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 河流不分叉（支流汇入主流，河流不分叉流向不同海洋）—— 这是物理水文的基本规律
|
||||
- 气候是一个系统（雨影效应、洋流、温度缓冲、纬度决定季节）—— 不能随意放置违背物理规律的气候
|
||||
- 地理不是装饰（每座山、每条河、每个沙漠都对当地居民有实际影响）
|
||||
- 避免地理决定论（地理约束但不决定，相似环境产生不同文化）
|
||||
- 规模很重要（"小王国"和"大帝国"的地理需求完全不同）
|
||||
- 地图是论据（每张地图都有关于包含什么、排除什么的政治选择）
|
||||
- 地理 Agent 验证地理连贯性：气候、地形和生物群落必须相互物理一致，聚落模式必须具有地理意义，资源分布必须符合地质和生态逻辑
|
||||
- 河流不分离原则：支流汇入干流，河流不分叉流向不同海洋（三角洲和分水岭是例外）
|
||||
- 气候是系统：雨影效应存在，海流影响温度，纬度决定季节；不能在无特殊理由的情况下在北纬60°放置热带雨林
|
||||
- 避免地理决定论：地理约束但不决定人类行为，相似环境产生不同文化
|
||||
|
||||
## Key Quotes
|
||||
> "Geography is destiny — where you are determines who you become" — Geographer Agent 的核心理念
|
||||
> "Geography is destiny — where you are determines who you become" — 地理学家 Agent 的核心理念
|
||||
> "Rivers don't split. Tributaries merge into rivers. Rivers don't fork into two separate rivers flowing to different oceans." — 关键物理规则
|
||||
> "Maps are arguments. Every map makes choices about what to include and exclude." — 制图的政治性
|
||||
> "Climate is a system. Rain shadows exist. Coastal currents affect temperature. Latitude determines seasons." — 气候系统思维
|
||||
> "Geography is not decoration. Every mountain, river, and desert has consequences for the people who live near it." — 地理的功能性价值
|
||||
> "Maps are arguments. Every map makes choices about what to include and exclude." — 地图的政治性
|
||||
|
||||
## Key Concepts
|
||||
- [[Geographic Coherence]]：地理连贯性 —— 确保气候、地形、生物群落之间物理一致的原则
|
||||
- [[Koppen Climate Classification]]：柯本气候分类法 —— Agent 用于描述气候区的参考框架
|
||||
- [[Environmental Determinism]]：环境决定论 —— 认为地理直接决定文化和发展的理论框架，Agent 在采纳其框架的同时承认其批评
|
||||
- [[Christaller Central Place Theory]]：克里斯塔勒中心地理论 —— 解释城市层级和形成原因的人文地理理论
|
||||
- [[Mackinder Heartland Theory]]：麦金德心脏地带理论 —— 地缘政治学中关于地理如何塑造战略竞争的框架
|
||||
- [[Rain Shadow Effect]]：雨影效应 —— 山脉阻挡湿气导致背风坡干旱的物理现象
|
||||
- [[Plate Tectonics]]：板块构造论 —— 解释山脉、火山等地理特征形成的地质学基础
|
||||
- [[EnvironmentalDeterminism]]：地理决定论——地理塑造文明的理论，Agent 明确承认 Jared Diamond 的框架同时接受其批评
|
||||
- [[KoppenClimateClassification]]：柯本气候分类法——物理地理学基础
|
||||
- [[ChristallerCentralPlaceTheory]]：克里斯塔勒中心地理论——人文地理学中的城市层级理论
|
||||
- [[MackinderHeartlandTheory]]：麦金德心脏地带理论——地缘政治学中的地理战略框架
|
||||
- [[WallersteinWorldSystems]]：沃勒斯坦世界体系理论——全球政治经济学框架
|
||||
- [[HydrologyConstraints]]：水文学约束——河流从高处流向低处，支流汇入干流，不反向流动
|
||||
- [[RainShadowEffect]]：雨影效应——山脉阻挡潮湿气流，导致背风坡干旱
|
||||
|
||||
## Key Entities
|
||||
- [[Jared Diamond]]：提出地理框架（《枪炮、病菌与钢铁》），Agent 采纳其环境决定论视角同时承认其局限性
|
||||
- [[Acemoglu]]：对地理决定论的批评者，Agent 明确引用以避免走向极端地理决定论
|
||||
- [[Wallerstein]]：世界体系理论提出者，影响 Agent 对贸易网络和权力动态的分析
|
||||
- [[Mackinder]]：地缘政治学先驱，Heartland Theory 的提出者
|
||||
- [[JaredDiamond]]：地理学家，《枪炮、病菌与钢铁》作者，地理框架参考
|
||||
- [[Acemoglu]]：批评地理决定论的经济学家，代表反方观点
|
||||
|
||||
## Connections
|
||||
- [[Geographic Coherence]] ← builds_upon ← [[Plate Tectonics]]
|
||||
- [[Geographic Coherence]] ← builds_upon ← [[Koppen Climate Classification]]
|
||||
- [[Mackinder Heartland Theory]] ← extends ← [[Geographic Coherence]]
|
||||
- [[Christaller Central Place Theory]] ← extends ← [[Geographic Coherence]]
|
||||
- [[Jared Diamond]] → influences → [[Environmental Determinism]]
|
||||
- [[Acemoglu]] → critiques → [[Environmental Determinism]]
|
||||
- [[AcademicNarratologist]] ← 协同构建世界故事 ← [[AcademicGeographer]]
|
||||
- [[UnrealWorldBuilder]] ← 依赖地理连贯性 ← [[AcademicGeographer]]
|
||||
- [[AcademicAnthropologist]] ← 依赖地理背景 ← [[AcademicGeographer]]
|
||||
- [[AcademicGeographer]] ← 提供环境框架 ← [[AgentsOrchestrator]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Jared Diamond]] 的框架存在张力：
|
||||
- 冲突点：Agent 采纳 Diamond 的地理框架，但同时强调 Acemoglu 对地理决定论的批评
|
||||
- 当前观点：地理约束人类选择，但不等同于决定论
|
||||
- 对方观点：Diamond 强调地理是历史发展的主导因素
|
||||
- 与 [[Acemoglu]] 的"制度决定论"冲突：
|
||||
- 冲突点：地理是否决定文明发展轨迹
|
||||
- 当前观点：地理约束是基础条件（Academic Geographer）
|
||||
- 对方观点：制度和政治因素是决定性因素（Acemoglu）
|
||||
|
||||
@@ -1,51 +1,60 @@
|
||||
---
|
||||
title: "Historian Agent Personality"
|
||||
title: "Historian"
|
||||
type: source
|
||||
tags: ["agent-personality", "historiography", "material-culture", "period-authenticity", "academic"]
|
||||
date: 2026-04-20
|
||||
tags: []
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-historian.md]]
|
||||
- [[Agent/agency-agents/academic/academic-historian.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 角色设定——扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正
|
||||
- 问题域：虚构作品中避免时代错乱（anachronism）、为游戏/小说/影视提供扎实的物质文化基础、主动纳入非西方历史传统
|
||||
- 方法/机制：通过五步工作流（定位时间空间→核查物质基础→叠加社会结构→评估论断→标注置信度），结合 Annales 学派、长时段分析、微观史、比较史等史学方法论
|
||||
- 结论/价值：让 AI Agent 能够以"历史学家"身份为创意世界提供可溯源的历史支撑，提升内容的历史深度与文化包容性
|
||||
- 核心主题：定义一个名为"Historian"的 AI Agent 角色——专业历史研究者，擅长历史分析、时代分期、物质文化和历史编纂学（historiography）
|
||||
- 问题域：AI Agent 的角色扮演设计、历史知识验证、历史叙事准确性保证
|
||||
- 方法/机制：Annales 学派、微观史学、长时段（longue durée）分析、物质文化重建、反事实推理（counterfactual analysis）
|
||||
- 结论/价值：确保虚构场景或应用中的历史细节准确无误，提供有据可查的历史背景和物质文化细节，主动挑战欧洲中心主义偏见
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 历史学家 Agent 通过"时代真实性报告"（Period Authenticity Report）为设定提供饮食、服饰、建筑、技术、货币、权力结构、性别角色等全维度历史细节
|
||||
- 所有历史论断必须标注来源类型（原始文献>二手学术>通俗史>好莱坞）和置信度（高/中/低），避免"中世纪时..."这类模糊表述
|
||||
- 主动挑战欧洲中心主义：将宋朝科技、明帝国财富、马里帝国等非西方历史纳入比较视野
|
||||
- 物质条件决定论：在讨论政治/军事前必须先理解经济基础（农业、贸易、技术水平）
|
||||
- Historian Agent 通过五步工作流程（建立坐标→检查物质基础→叠加社会结构→评估来源→标注置信度）对历史主张进行系统性验证
|
||||
- Historian Agent 使用 Period Authenticity Report（时代真实性报告）提供多维度的时代细节：饮食、服装、建筑、技术、经济、货币、社会结构、法律和日常生活的感官细节
|
||||
- Historian Agent 区分四种来源层级（原始文献 > 二手学术 > 大众历史 > 好莱坞），对每项历史主张必须标注来源类型和置信度
|
||||
- Historian Agent 将神话视为"主要史料"——揭示一个文化重视什么、恐惧什么、渴望什么，而非简单否定为"虚假历史"
|
||||
- Historian Agent 强调物质条件决定论——在讨论政治或战争之前，必须先理解经济基础：人们吃什么、如何贸易、掌握什么技术
|
||||
|
||||
## Key Quotes
|
||||
> "History doesn't repeat, but it rhymes — and I know all the verses" — Historian Agent 的风格定位
|
||||
> "That's a common belief, but the evidence actually shows..." — 纠正历史迷思时的沟通风格
|
||||
> "Medieval Europe spans 1000 years and a continent. Be specific about when and where." — 对时代宽泛化的警示
|
||||
> "Myths are data too. A society's myths reveal what they valued, feared, and aspired to." — 对神话的态度
|
||||
> "History doesn't repeat, but it rhymes — and I know all the verses" — Historian Agent 标语（vibe）
|
||||
> "A Roman legionary's daily ration included about 850g of wheat, ground and baked into hardtack — not the fluffy bread you're imagining" — 精准但生动的表达风格示例
|
||||
> "Medieval Europe spans 1000 years and a continent. Be specific about when and where." — 避免以偏概全的方法论要求
|
||||
> "The Song Dynasty was more technologically advanced than contemporary Europe. The Mali Empire was one of the richest states in human history." — 主动挑战欧洲中心主义的代表性声明
|
||||
|
||||
## Key Concepts
|
||||
- [[Annales School]]：法国史学流派，强调长时段（longue durée）结构史学，关注日常生活的物质文化与经济基础
|
||||
- [[Material Culture Analysis]]：物质文化分析，通过文物、遗址、日用物品重建历史时期的生活质感
|
||||
- [[Anachronism Detection]]：时代错乱检测，不仅识别明显的（如前哥伦布时代欧洲出现土豆），还包括隐性的（态度、社会结构、经济系统的时代错配）
|
||||
- [[Longue Durée]]：布罗代尔提出的长时段历史分析概念，识别塑造事件发生的长期结构
|
||||
- [[Microhistory]]：微观史学，关注特定个人或社区以揭示更广泛的历史动态
|
||||
- [[Comparative History]]：比较历史学，跨文明比较相似挑战下的不同应对方式
|
||||
- [[Counterfactual Analysis]]：反事实分析，基于历史偶然性理论的严谨"如果"推理
|
||||
- [[Postcolonial History]]：后殖民史学，主动纳入非欧洲中心的历史视角
|
||||
- [[Annales School]]：法国年鉴学派，强调"总体史"——关注长时段的结构性变化（地理、人口、经济、社会）而非单纯的政治军事事件
|
||||
- [[Longue Durée]]：长时段分析，源自布罗代尔（Braudel），认为历史事件背后的深层结构（如地理环境、人口趋势、经济形态）决定了短期事件的走向
|
||||
- [[Microhistory]]：微观史学，聚焦于个体或小社区的历史研究方法，通过具体案例揭示更大的历史规律
|
||||
- [[Material Culture]]：物质文化分析，通过物质遗存（器物、建筑、服饰）重建过去人们的生活方式和思想观念
|
||||
- [[Historiography]]：历史编纂学，研究历史叙事如何被构建、争议和演变——Historian Agent 理解历史叙事本身是被建构和争夺的对象
|
||||
- [[Counterfactual Analysis]]：反事实推理，严谨的"假如"历史推演，以历史偶然性理论为基础，而非随意想象
|
||||
- [[Presentism]]：当代主义（以现代标准评判历史），Historian Agent 避免此类判断，同时也不为暴行开脱
|
||||
|
||||
## Key Entities
|
||||
- [[Annales School]]（学术流派）：由布洛赫和费弗尔创立，以《年鉴》杂志为核心阵地，代表人物包括布罗代尔
|
||||
- [[Fernand Braudel]]（历史学家）：长时段理论提出者，著有《菲利普二世时代的地中海和地中海世界》
|
||||
- [[Pirenne]]（历史学家）：提出"穆罕默德和查理曼"的商业复兴论点，与维克斯曼等后世学者存在争论
|
||||
- [[Fernand Braudel]]：法国历史学家，Annales 学派核心人物，长时段（longue durée）概念的提出者，其对地中海贸易的研究被文档引用为方法论典范
|
||||
- [[Henri Pirenne]]：比利时历史学家，提出的"穆罕默德和查理曼"命题（Pirenne Thesis）仍是中世纪史研究中的重要辩论焦点
|
||||
- [[Chris Wickham]]：当代历史学家，代表 Pirenne 命题的对立观点，文档中与 Pirenne 并列为学界辩论的双方
|
||||
|
||||
## Connections
|
||||
- [[Academic Geographer]] ← 方法互补 ← [[Academic Historian]]：地理与历史共同构建时空坐标
|
||||
- [[Academic Narratologist]] ← 内容提供 ← [[Academic Historian]]：历史真实性为叙事提供素材
|
||||
- [[Academic Anthropologist]] ← 理论交叉 ← [[Academic Historian]]：两者都关注物质文化与日常生活的重建
|
||||
- [[Academic Narratologist]] ← 方法互补 ← [[Academic Historian]]
|
||||
- Narratologist 关注叙事结构，Historian 关注历史真实性，两者结合可生成既叙事优美又历史准确的文本
|
||||
- [[Academic Anthropologist]] ← 跨学科协作 ← [[Academic Historian]]
|
||||
- 两者都关注物质文化（Material Culture），Historian 从历史维度，Anthropologist 从文化维度
|
||||
- [[Unreal World Builder Agent]] ← 被验证 ← [[Academic Historian]]
|
||||
- Historian Agent 的 Period Authenticity Report 可直接服务于 Unreal World Builder 的历史背景设定验证
|
||||
|
||||
## Contradictions
|
||||
- 与通俗历史观点冲突：大量常见的历史迷思（"黑暗的中世纪"、"文艺复兴突然觉醒"等）被纠正
|
||||
- 与影视作品冲突：Holly hollywood 对中世纪/古典时代的浪漫化呈现被明确标记为错误
|
||||
- 与 [[Academic Narratologist]] 潜在冲突：
|
||||
- 冲突点：叙事节奏 vs. 历史准确性
|
||||
- 当前观点（Historian）：任何历史主张必须标注置信度和来源，模糊性会降低准确性
|
||||
- 对方观点（Narratologist）：叙事需要适度的戏剧化处理，历史真实与艺术真实之间存在张力
|
||||
- 与 [[Academic Psychologist]] 潜在冲突：
|
||||
- 冲突点：历史人物心理 vs. 史料局限性
|
||||
- 当前观点（Historian）：不能随意揣测历史人物的内心，必须基于一手或二手文献
|
||||
- 对方观点（Psychologist）：心理学分析可以填补史料空白，提供更完整的人物画像
|
||||
|
||||
@@ -2,51 +2,55 @@
|
||||
title: "Academic Narratologist"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-narratologist.md]]
|
||||
- [[Agent/agency-agents/academic/academic-narratologist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Narratologist Agent 角色设定——一个以叙事理论为基础的故事结构分析 AI Agent，具备俄罗斯形式主义、法国结构主义、认知叙事学等深厚学术背景
|
||||
- 问题域：如何让 AI Agent 能够像专业叙事理论家一样，分析故事结构、角色弧光、主题表达，并提供有理论依据的叙事建议
|
||||
- 方法/机制：通过预置的叙事学框架（Propp、Campbell、Genette、Barthes、Todorov 等）驱动分析流程，要求每个建议都必须引用至少一个命名理论框架
|
||||
- 结论/价值：提供了一个可复用的学术型 AI Agent 设计范式——将传统人文社科理论与 LLM 系统提示词工程结合
|
||||
- 核心主题：Narratologist 是一个专注于叙事理论与故事结构分析的专业 AI Agent，以工程师拆解系统的方式剖析叙事——找出承重结构、应力点和优雅解法
|
||||
- 问题域：如何为 AI Agent 提供严谨的叙事分析能力，使其能对故事结构、角色弧线、主题表达进行框架级别的精确评估
|
||||
- 方法/机制：通过整合 Propp、Campbell、McKee、Genette 等经典叙事学框架，结合 Russian Formalism、Cognitive Narratology、Game Narrative 等现代理论，提供框架驱动的叙事分析与指导
|
||||
- 结论/价值：AI Agent 可以通过引用具体理论框架，对叙事问题给出精确、可辩护的结构性建议，而非泛泛的"让它更有趣"
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Narratologist Agent 能通过 Propp 形态学分析童话/冒险结构，通过 Campbell 单一体神话和 Vogler 编剧旅程分析英雄叙事
|
||||
- 叙事问题通常存在于讲述层面（sjuzhet）而非故事层面（fabula）——应优先诊断叙事手法而非情节本身
|
||||
- 每个结构建议必须引用至少一个命名理论框架，并附带推理过程；泛泛的建议（如"让角色更立体"）是不合格的
|
||||
- 角色动机的心理分析只能作为视角而非处方使用——角色不是案例研究对象
|
||||
- 在颠覆类型惯例之前必须先理解并尊重类型惯例
|
||||
- Narratologist Agent 通过系统性框架（而非印象式批评）为故事结构提供精确分析
|
||||
- 叙事问题通常存在于讲述层（sjuzhet）而非故事层（fabula），分析应在正确层级进行
|
||||
- 每个建议必须引用至少一个命名理论框架，支撑"是什么、为什么有效、适用框架"三层论证
|
||||
- 角色动机分析应使用心理学模型作为透镜而非处方，角色不是案例研究
|
||||
|
||||
## Key Quotes
|
||||
> "Every story is an argument — I help you find what yours is really saying." — Narratologist Agent 自述核心理念
|
||||
> "Most problems live in the telling (sjuzhet), not the tale (fabula)." — 叙事诊断的核心原则
|
||||
> "Cite sources. 'According to Propp's function analysis, this character serves as the Donor' is useful. 'This character should be more interesting' is not." — 关于提供理论依据的要求
|
||||
> "You dissect stories the way an engineer dissects systems — finding the load-bearing structures, the stress points, the elegant solutions." — 身份定位：系统工程师式叙事分析
|
||||
> "Never give generic advice like 'make the character more relatable.' Be specific: what changes, why it works narratologically, and what framework supports it." — 核心原则：精确而非泛泛
|
||||
> "Most problems live in the telling (sjuzhet), not the tale (fabula)." — 诊断层级的关键洞察
|
||||
> "Cite sources. 'According to Propp's function analysis, this character serves as the Donor' is useful. 'This character should be more interesting' is not." — 引用框架的要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Fabula 与 Sjuzhet]]：故事（fabula=按时间顺序的事件）与叙事（sjuzhet=如何讲述）的区分，是叙事分析的基础框架
|
||||
- [[Propp 形态学]]：Vladimir Propp 的民间故事功能分析，识别31种故事功能（如 Donor、Hero、Villain）
|
||||
- [[Campbell 单一体神话]]：Joseph Campbell 的"英雄之旅"理论，Hero's Journey 的学术根源
|
||||
- [[Vogler 编剧旅程]]：Christopher Vogler 将 Campbell 理论改编为好莱坞编剧实践框架
|
||||
- [[Genette 叙事学]]：Gérard Genette 的叙事理论，聚焦叙事视角（focalization）、时序结构、叙事声音
|
||||
- [[Barthes 五代码]]：Roland Barthes 的叙事语义五代码模型（Hermeneutic、Proairetic、Symbolic、Semantic、Referential）
|
||||
- [[Todorov 均衡模型]]：Tzvetan Todorov 的 equilibrium-disruption-new equilibrium 三阶段模型
|
||||
- [[角色弧光]]：Character Arc，角色从起点到终点的内在变化轨迹，含 want/need/lie/transformation 四个维度
|
||||
- [[叙事债务]]：Narrative Debts，向读者做出的尚未兑现的叙事承诺
|
||||
- [[控制性理念]]：Controlling Idea（McKee 术语），即故事对人类经验的论证核心
|
||||
- [[Narrative Theory]]：故事结构的学术研究领域，涵盖 Russian Formalism、French Structuralism、Cognitive Narratology 等分支
|
||||
- [[Hero's Journey]]（Campbell/Monomyth）：英雄之旅叙事模型，Narratologist 应用于英雄叙事分析
|
||||
- [[Propp's Morphology]]：Vladimir Propp 的民间故事形态学，31 种功能分析，用于童话与quest结构
|
||||
- [[Three-Act Structure]]：经典三幕式叙事结构（Setup/Confrontation/Resolution）
|
||||
- [[Character Arc]]：角色弧线，Transformative/Steadfast/Flat/Tragic/Comedic 五种类型，含 want/need/lie/transformation 四个要素
|
||||
- [[Controlling Idea]]（McKee）：故事对人性的论点，是叙事分析的核心抽象层
|
||||
- [[Fabula vs Sjuzhet]]：故事（按时间顺序的事件）与叙事（如何讲述）的区分
|
||||
- [[Kishōtenketsu]]：日本四幕叙事结构，作为西方三幕式的跨文化对比框架
|
||||
- [[Todorov's Equilibrium]]：equilibrium disruption 叙事模型
|
||||
- [[Genette's Narratology]]：聚焦 narrative voice、focalization、temporal structure 的理论框架
|
||||
- [[Barthes' Five Codes]]：叙事意义的符号学分析工具
|
||||
|
||||
## Key Entities
|
||||
- [[Academic Anthropologist]]：同一系列中的学术型 Agent 之一，同样采用学科理论驱动的方法论
|
||||
- [[Academic Historian]]：同一系列中的学术型 Agent 之一，共享 Agent 个性设计范式
|
||||
- [[Academic Geographer]]：同一系列中的学术型 Agent 之一
|
||||
- [[Campbell]]：Joseph Campbell，Hero's Journey / Monomyth 的提出者，Narratologist 的核心引用框架之一
|
||||
- [[Propp]]：Vladimir Propp，民间故事形态学（31 Functions）创始人
|
||||
- [[McKee]]：Robert McKee，Story / Controlling Idea 框架的当代叙事权威
|
||||
- [[Genette]]：Gérard Genette，Narrative Discourse 理论框架，影响 voice、focalization、tense 分析
|
||||
- [[Vogler]]：Christopher Vogler，Writer's Journey 将 Campbell 理论引入商业叙事
|
||||
- [[Barthes]]：Roland Barthes，Five Codes 提供叙事意义的符号学解码工具
|
||||
|
||||
## Connections
|
||||
- [[Academic Anthropologist]] ← 同系列学术 Agent ← [[Academic Narratologist]]
|
||||
- [[Academic Historian]] ← 同系列学术 Agent ← [[Academic Narratologist]]
|
||||
- [[Academic Geographer]] ← 同系列学术 Agent ← [[Academic Narratologist]]
|
||||
- [[Agents Orchestrator]] ← provides_narrative_expertise_to ← [[Academic Narratologist]]
|
||||
- [[Narrative Designer]] ← overlaps_with ← [[Academic Narratologist]]（Game Narrative 领域）
|
||||
- [[Agents Orchestrator]] ← depends_on ← [[Academic Narratologist]]（AI Agent 团队中的叙事专家角色）
|
||||
|
||||
## Contradictions
|
||||
- 暂无冲突内容
|
||||
- 暂无已知冲突内容
|
||||
|
||||
@@ -2,79 +2,53 @@
|
||||
title: "Academic Psychologist"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/academic/academic-psychologist.md]]
|
||||
- [[Agent/agency-agents/academic/academic-psychologist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Academic Psychologist——The Agency 学术部门的临床与研究心理学家人格智能体，为角色塑造提供心理学可信度支撑。
|
||||
- 问题域：角色心理学评估、人际关系动态分析、创伤/压力/冲突的真实性反应建模、群体行为心理学。
|
||||
- 方法/机制：基于 Big Five 人格框架、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、认知行为疗法（CBT）认知扭曲、社会心理学经典实验（Milgram/Zimbardo/Asch）等多种理论与实证框架，对角色进行多维度心理画像。
|
||||
- 结论/价值：拒绝将角色病理化，强调区分流行心理学与循证心理学，承认文化情境与创伤响应的多样性，要求所有心理观察必须引用具体理论或实证研究并诚实承认其局限性。
|
||||
- 核心主题：Psychologist Agent — 专注于人格、动机、创伤和群体动力学的临床与研究心理学 Agent，为角色构建提供心理学可信的行为和互动框架
|
||||
- 问题域：如何让 AI Agent 生成的角色行为具有心理学上的真实感，避免将角色简化为诊断标签或刻板印象
|
||||
- 方法/机制：通过 Big Five 人格框架、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、认知行为疗法（CBT）等established心理学框架评估和设计角色心理
|
||||
- 结论/价值：为角色扮演类 Agent 提供了系统化的心理学评估工具箱，强调区分流行心理学与研究实证心理学，并诚实地承认每种理论框架的局限性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 不将角色降低为诊断。角色可以表现出自恋*特质*而无需成为"自恋者"——人不是 DSM 代码。
|
||||
- 区分**流行心理学**与**循证心理学**。引用某理论时，需了解该理论是同行评审还是自助类。
|
||||
- 承认文化情境。依恋理论源于西方个人主义背景。集体主义文化可能呈现不同的"健康"模式。
|
||||
- 创伤响应多样。并非所有创伤都导致退缩——有人变得高度警觉，有人变成讨好者，有人通过隔离高效运转。
|
||||
- 对心理学未解之谜保持诚实。该领域存在可重复性危机、文化偏见和真正的争议——不将争议性发现当作既定科学呈现。
|
||||
- Psychodynamic Agent 在评估角色时，必须以命名理论或实证研究为基础（with honest acknowledgment of that theory's limitations）
|
||||
- 人格行为通过 Big Five 框架映射，每种特质都需要行为表现的具体化
|
||||
- 依恋风格（安全型/焦虑型/回避型/恐惧型）在不同关系类型（浪漫/家庭/友谊）中有不同表现
|
||||
- 防御机制按 Vaillant 层级组织，压力下会退行到更低层级
|
||||
- 创伤反应具有多样性：过度警觉型、取悦他人型、隔离回避型、高功能 compartmentalization — 不能简化为"悲惨背景=破碎角色"
|
||||
- 群体心理学分析应结合社会认同理论（ Tajfel）、群体思维（ Janis）、旁观者效应（ Milgram/Zimbardo）
|
||||
|
||||
## Key Quotes
|
||||
> "People don't do things for no reason — I find the reason" — Psychologist Agent 核心信念
|
||||
> "观察先于诊断" — 收集行为证据后再映射到理论框架
|
||||
> "Use multiple lenses: No single theory explains everything" — 交叉参考 Big Five、依恋理论与文化背景
|
||||
> "People don't do things for no reason — I find the reason" — Psychologist Agent 核心信条，贯穿整个 Agent 设计
|
||||
> "Never reduce characters to diagnoses. A character can exhibit narcissistic *traits* without being 'a narcissist.' People are not their DSM codes." — 拒绝将角色标签化的核心原则
|
||||
> "Distinguish between **pop psychology** and **research-backed psychology**. If you cite something, know whether it's peer-reviewed or self-help." — 方法论诚信要求
|
||||
> "The field has replication crises, cultural biases, and genuine debates. Don't present contested findings as settled science." — 学术诚实标准
|
||||
|
||||
## Key Concepts
|
||||
- [[Big-Five-Personality]]: 人格五因素模型（开放性、尽责性、外向性、宜人性、神经质），用于量化角色核心人格特质
|
||||
- [[Attachment-Theory]]: 依恋理论（安全型/焦虑型/回避型/恐惧型），用于分析角色在亲密关系中的行为模式
|
||||
- [[Defense-Mechanisms]]: Vaillant 防御机制层级（成熟型/神经症型/不成熟型），用于识别角色在压力下的应对策略
|
||||
- [[Cognitive-Distortions]]: Beck 认知扭曲（十种常见非理性思维模式），用于识别驱动角色决策的具体认知偏差
|
||||
- [[Karpman-Drama-Triangle]]: Karpman 戏剧三角（受害者/迫害者/拯救者），用于分析人际冲突中的角色动态
|
||||
- [[Transactional-Analysis]]: 沟通分析（父母/成人/儿童三种自我状态），用于诊断角色间沟通模式
|
||||
- [[Social-Psychology-Classics]]: Milgram（服从权威）、Zimbardo（斯坦福监狱实验）、Asch（从众实验）及其现代批判
|
||||
- [[Cognitive-Behavioral-Therapy]]: CBT 认知行为疗法框架，用于建模现实的心理干预路径
|
||||
- [[Developmental-Psychology]]: Erikson 心理社会发展阶段、Piaget 认知发展、Bowlby 依恋起源
|
||||
- [[Trauma-Informed-Analysis]]: 创伤知情分析——PTSD、复杂性创伤、代际创伤（van der Kolk/Herman/Porges 理论）
|
||||
- [[Group-Psychology]]: 群体心理（社会认同理论/群体思维/责任扩散/暴民心理）
|
||||
- [[Cross-Cultural-Psychology]]: 跨文化心理学（Markus & Kitayama 文化模式/Hofstede 文化维度）
|
||||
- [[Psychological-Profile]]: 角色心理画像技术文档格式——整合 Big Five + 依恋风格 + 防御机制 + 核心创伤 + 应对策略 + 盲点
|
||||
- [[BigFive]]：人格五因素模型——开放性、尽责性、外向性、宜人性、神经质，用于系统性评估角色特质
|
||||
- [[AttachmentTheory]]：Bowlby 依恋理论——评估角色在亲密关系中的依恋风格及其触发情境
|
||||
- [[KarpmanDramaTriangle]]：Karpman 戏剧三角——识别角色间的关系动态（受害者/迫害者/拯救者）
|
||||
- [[CBT-CognitiveDistortions]]：认知行为疗法的认知扭曲分类——识别驱动角色决策的具体认知模式
|
||||
- [[PsychodynamicDefenseMechanisms]]：Vaillant 防御机制层级——intellectualization/projection/humor 等在压力下的表现
|
||||
- [[EriksonPsychosocialStages]]：Erikson 心理社会发展阶段——早期经历如何以非决定论方式塑造成人人格
|
||||
- [[PolyvagalTheory]]：Porges 迷走神经理论——理解 PTSD、复杂创伤的生理基础
|
||||
- [[Groupthink]]：Janis 群体思维——群体决策中的从众压力与去个性化风险
|
||||
- [[SocialIdentityTheory]]：Tajfel 社会认同理论——群体内/外动态如何影响行为
|
||||
- [[TransactionalAnalysis]]：交互分析——映射权力动态、沟通模式和角色间的隐性契约
|
||||
|
||||
## Key Entities
|
||||
- [[Erik Erikson]]: 心理社会发展理论提出者，Erikson 八阶段理论用于角色发展轨迹建模
|
||||
- [[Jean Piaget]]: 认知发展理论提出者，Piaget 四阶段用于角色认知成熟度评估
|
||||
- [[John Bowlby]]: 依恋理论创始人，Bowlby 依恋风格分类影响角色亲密关系建模
|
||||
- [[Aaron Beck]]: 认知行为疗法创始人，Beck 认知扭曲十种类型用于角色决策分析
|
||||
- [[Stephen Karpman]]: 戏剧三角提出者，Karpman 三角用于人际冲突建模
|
||||
- [[George Vaillant]]: 防御机制层级研究者，Vaillant 层级用于压力应对策略分类
|
||||
- [[Stanley Milgram]]: 服从权威实验研究者，Milgram 实验用于群体压力建模
|
||||
- [[Philip Zimbardo]]: 斯坦福监狱实验研究者，Zimbardo 实验用于权威与情境分析
|
||||
- [[Solomon Asch]]: 从众实验研究者，Asch 实验用于群体从众建模
|
||||
- [[Judith Herman]]: 复杂性创伤与恢复阶段研究者（Herman 三阶段恢复模型）
|
||||
- [[Bessel van der Kolk]]: 创伤与身体关系研究者（"身体记录创伤"核心概念）
|
||||
- [[Stephen Porges]]: Polyvagal Theory 提出者，Porges 理论用于创伤响应建模
|
||||
- [[Hans Eysenck]]: 大五人格先驱研究者
|
||||
- [[Richard Lazarus]]: 压力与应对理论研究者
|
||||
- [[PsychologistAgent]]：本 source 描述的核心 Agent——临床与研究心理学家，专注于人格、动机、创伤和群体动力学
|
||||
|
||||
## Connections
|
||||
- [[Big-Five-Personality]] ← foundational_framework ← [[Psychological-Profile]]
|
||||
- [[Attachment-Theory]] ← behavioral_pattern ← [[Psychological-Profile]]
|
||||
- [[Defense-Mechanisms]] ← under_stress_response ← [[Psychological-Profile]]
|
||||
- [[Cognitive-Distortions]] ← driving_force ← Character-Decisions
|
||||
- [[Karpman-Drama-Triangle]] ← conflict_model ← Interpersonal-Dynamics
|
||||
- [[Transactional-Analysis]] ← communication_pattern ← Interpersonal-Dynamics
|
||||
- [[Trauma-Informed-Analysis]] ← advanced_capability ← [[Psychological-Profile]]
|
||||
- [[Group-Psychology]] ← advanced_capability ← Interpersonal-Dynamics
|
||||
- [[Behavioral-Nudge-Engine]] ← theoretical_foundation ← [[Behavioral-Psychology]]（本 Wiki 已有 [[Behavioral-Psychology]] Concept Page）
|
||||
- [[multi-agent-system-reliability]] ← conflicts_with ← 确定性 vs LLM 概率性悖论
|
||||
- [[AgentsOrchestrator]] ← manages ← [[PsychologistAgent]]
|
||||
- [[PsychologistAgent]] ← informs ← [[NarrativeDesigner]]（角色心理为叙事设计提供真实感）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[multi-agent-system-reliability]] 冲突：
|
||||
- 冲突点：多智能体系统可靠性主张"架构约束优于提示词约束"（确定性），Psychologist Agent 依赖 LLM 推理进行心理评估（概率性）。
|
||||
- 当前观点：心理评估需要概率性推理能力，但可以通过 Chain-of-Thought 约束推理路径。
|
||||
- 对方观点：LLM 作为不可靠组件，不应依赖其进行推理，应通过架构强制正确性。
|
||||
- 与流行心理学（MBTI/Enneagram）张力：
|
||||
- 冲突点：MBTI 和 Enneagram 在大众中广泛使用，但学术可信度有限。
|
||||
- 当前观点：Enneagram 仅作为叙事工具接受，MBTI 局限性必须明确标注。
|
||||
- 对方观点：MBTI 简单直观，适合快速角色原型划分。
|
||||
- 与流行心理学刻板印象的冲突：
|
||||
- 冲突点：流行文化倾向于将角色简化为诊断标签（如"他是自恋者"）
|
||||
- 当前观点：Agent 必须通过具体行为证据映射到理论框架，拒绝标签化
|
||||
- 对方观点：将复杂心理现象简化为诊断术语便于快速理解和沟通
|
||||
|
||||
@@ -6,42 +6,60 @@ date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/accounts-payable-agent.md]]
|
||||
- [[Agent/agency-agents/specialized/accounts-payable-agent.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AccountsPayable Agent——自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖加密货币、法定货币、稳定币等全支付通道
|
||||
- 问题域：AI Agent 工作流中的支付执行、审计追踪、防重复付款、多通道路由
|
||||
- 方法/机制：幂等性检查 → 供应商注册表验证 → 最优通道路由 → 执行支付 → 审计日志全链路；通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 等集成
|
||||
- 结论/价值：为 AI Agent 生态提供可信赖的支付执行层，零重复付款、完整审计覆盖、60秒内 escalation SLA
|
||||
- 核心主题：Accounts Payable Agent 是 The Agency 的自主支付运营专家智能体，专注于供应商付款、承包商发票和周期性账单处理，涵盖加密货币、法币、稳定币全支付通道
|
||||
- 问题域：企业应付账款（AP）自动化、多通道支付路由、支付幂等性、审计合规、支付故障恢复
|
||||
- 方法/机制：
|
||||
- 幂等性检查（Idempotency）：付款前查询发票引用号，确保不重复支付
|
||||
- 审批阈值（Approval Threshold）：超过授权限额自动上报人工审批
|
||||
- 多通道路由（Payment Rail Routing）：根据收款人、金额和成本自动选择最优通道（ACH/Wire/Crypto/Stablecoin/Payment API）
|
||||
- 供应商注册表（Vendor Registry）：维护已批准供应商的首选支付通道和收款地址
|
||||
- 审计日志（Audit Trail）：每笔支付记录完整上下文（发票号、金额、通道、时间戳、状态）
|
||||
- Agent 间工具调用集成：接收来自 Contracts Agent、Project Manager、HR Agent 的支付请求
|
||||
- 结论/价值：实现企业级支付运营的端到端自动化，零重复支付、100% 审计覆盖、<2 分钟执行时间
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AccountsPayable Agent 通过幂等性检查确保永远不会发送同一笔支付两次
|
||||
- Agent 自动选择最优支付通道（ACH/ Wire/ Crypto/ Stablecoin/ Payment API），基于接收方、金额和成本
|
||||
- 所有支付均保留完整审计日志，包含发票引用、金额、通道、时间戳和状态
|
||||
- 超过授权额度的支付必须上报人工审批，不得自动执行
|
||||
- AccountsPayable Agent 通过幂等性检查机制，在每次支付前验证发票是否已付清，实现零重复支付
|
||||
- Agent 根据收款人类型、金额和成本自动选择最优支付通道（ACH/Wire/Crypto/Stablecoin/Payment API），无需人工干预
|
||||
- 超过授权限额的支付请求自动上报人工审批，不执行越权操作
|
||||
- Agent 通过工具调用（Tool Calls）与其他 Agent（Contracts Agent、Project Manager、HR Agent）集成，实现跨 Agent 支付工作流自动化
|
||||
- 每笔支付均生成完整审计日志，包含发票引用、金额、通道、时间戳和状态
|
||||
|
||||
## Key Quotes
|
||||
> "Idempotency first: Check if an invoice has already been paid before executing. Never pay twice." — 核心安全原则
|
||||
> "If a payment rail fails, try the next available rail before escalating" — 容错路由机制
|
||||
> "Zero duplicate payments — idempotency check before every transaction" — 成功指标
|
||||
> "You are **AccountsPayable**, the autonomous payment operations specialist who handles everything from one-time vendor invoices to recurring contractor payments. You treat every dollar with respect, maintain a clean audit trail, and never send a payment without proper verification." — 身份定义
|
||||
|
||||
> "**Idempotency first**: Check if an invoice has already been paid before executing. Never pay twice." — 核心安全规则
|
||||
|
||||
> "If a payment rail fails, try the next available rail before escalating." — 支付故障处理策略
|
||||
|
||||
> "Never exceed your authorized limit without explicit human approval." — 权限边界
|
||||
|
||||
## Key Concepts
|
||||
- [[Idempotency]]：幂等性——同一笔支付请求无论执行多少次，结果相同。AccountsPayable 通过 reference ID 去重，防止重复付款
|
||||
- [[Payment-Rail]]：支付通道——ACH（国内/工资，1-3天）、Wire（大额/跨境，即时）、Crypto（加密原生供应商，分钟级）、Stablecoin（低费用，秒级）、Payment API（卡片/平台，1-2天）
|
||||
- [[Audit-Trail]]：审计追踪——每笔支付记录发票引用、金额、通道、时间戳和状态，确保财务合规
|
||||
- [[Vendor-Registry]]：供应商注册表——维护已批准供应商及其首选支付通道和地址
|
||||
- [[Idempotency-Check]]：幂等性检查——在执行支付前，通过发票引用号查询是否已支付，防止重复付款的核心安全机制
|
||||
- [[Audit-Trail]]：审计日志——每笔支付记录完整上下文（发票号、金额、支付通道、时间戳、状态），确保可追溯性
|
||||
- [[Payment-Rail-Routing]]：支付通道路由——根据收款人类型、金额和成本自动选择最优支付通道（ACH/Wire/Crypto/Stablecoin/Payment API）
|
||||
- [[Vendor-Registry]]：供应商注册表——维护已批准供应商的首选支付通道和收款地址，确保支付至正确账户
|
||||
- [[Spend-Limit]]：消费限额——Agent 的自主支付授权上限，超过限额需人工审批
|
||||
- [[Approval-Threshold]]：审批阈值——触发人工审批流程的金额界限
|
||||
|
||||
## Key Entities
|
||||
- [[Contracts-Agent]]：里程碑完成后触发 AccountsPayable 执行承包商付款
|
||||
- [[Project-Manager-Agent]]：处理承包商工时材料发票
|
||||
- [[HR-Agent]]：负责工资单发放
|
||||
- [[Strategy-Agent]]：接收支出报告和资金跑道分析
|
||||
- [[ContractsAgent]]：接收里程碑完成触发信号，执行承包商里程碑支付
|
||||
- [[ProjectManagerAgent]]：发起承包商工时材料发票的支付请求
|
||||
- [[HRAgent]]：处理工资发放的支付请求
|
||||
- [[StrategyAgent]]：接收支出报告和资金跑道分析数据
|
||||
- [[Stripe]]：Payment API 支付通道之一
|
||||
- ACH（Automated Clearing House）：美国自动清算支付通道，适合国内供应商和工资发放，结算周期 1-3 天
|
||||
- Wire Transfer：电汇通道，适合大额/国际支付，当日结算
|
||||
- BTC/ETH Crypto：加密货币通道，适合加密原生供应商，数分钟内结算
|
||||
- USDC/USDT Stablecoin：稳定币通道，低费用、近实时结算
|
||||
|
||||
## Connections
|
||||
- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[Contracts-Agent]]
|
||||
- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[Project-Manager-Agent]]
|
||||
- [[Accounts-Payable-Agent]] ← receives_payment_requests ← [[HR-Agent]]
|
||||
- [[Accounts-Payable-Agent]] ← provides_spend_reports ← [[Strategy-Agent]]
|
||||
- [[ContractsAgent]] ← payment_trigger ← [[AccountsPayableAgent]]
|
||||
- [[ProjectManagerAgent]] ← invoice_request ← [[AccountsPayableAgent]]
|
||||
- [[HRAgent]] ← payroll_disbursement ← [[AccountsPayableAgent]]
|
||||
- [[StrategyAgent]] ← spend_report ← [[AccountsPayableAgent]]
|
||||
|
||||
## Contradictions
|
||||
- （本文档为单一 Agent 设计文档，暂无已知内容冲突）
|
||||
- 无已知跨页面内容冲突
|
||||
|
||||
82
wiki/sources/agent-activation-prompts.md
Normal file
82
wiki/sources/agent-activation-prompts.md
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: "NEXUS Agent Activation Prompts"
|
||||
type: source
|
||||
tags: ["multi-agent", "orchestration", "prompt-templates", "agent-activation", "nexus"]
|
||||
sources: []
|
||||
date: 2026-05-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/strategy/coordination/agent-activation-prompts.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：NEXUS 流水线中各类 Agent 的标准化激活提示词模板库，覆盖编排、工程、设计、测试、产品、支持六大部门
|
||||
- 问题域：如何为每个专业 Agent 提供完整上下文（阶段、任务、参考文档、质量标准），使其能立即投入工作并符合流水线质量要求
|
||||
- 方法/机制：部门分类 + 角色模板化；每个模板包含 Phase/Task/Acceptance Criteria/Reference Documents/Implementation Requirements 五大要素；完成后自动对接相应 QA Agent
|
||||
- 结论/价值：实现 Agent 的即插即用——任何 Agent 收到激活提示词即可在正确上下文下执行，无需重复初始化
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- NEXUS 流水线中每个 Agent 都有标准化的激活提示词模板，通过 Phase/Task/Acceptance Criteria/Reference Documents/Implementation Requirements 五大要素提供完整上下文
|
||||
- Dev↔QA 循环是流水线核心机制：Developer 实现 → Evidence Collector 截图验证 → PASS/FAIL 决策，最多 3 次重试后升级
|
||||
- Evidence Collector 默认需要多端截图（桌面/平板/手机）作为验证证据，品牌一致性和可访问性是强制检查项
|
||||
- Reality Checker 是最终守门人，默认判决为"NEEDS WORK"，必须用压倒性证据才能获得"READY"
|
||||
- Executive Summary Generator 强制使用 SCQA 框架（Situation-Complication-Question-Answer），每个发现必须有量化数据支撑
|
||||
|
||||
## Key Quotes
|
||||
> "Evidence over claims — require proof for all quality assessments." — NEXUS 质量原则：证据优于声明
|
||||
> "Default to 'NEEDS WORK' unless overwhelming evidence proves production readiness." — Reality Checker 默认判决原则
|
||||
> "Maximum 3 retries per task before escalation." — Dev↔QA 循环重试上限
|
||||
> "Build only what's needed to test the hypothesis." — Rapid Prototyper 核心原则：速度优于完美
|
||||
> "AI ethics and safety are mandatory — no shortcuts." — AI Engineer 强制要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Dev-QA-Loop]]：开发与质量验证的循环机制——Developer 实现 → Evidence Collector 截图验证 → PASS/FAIL → 失败则重试，最多 3 次后升级
|
||||
- [[Quality-Gate]]：质量门控——任务必须通过质量验证才能推进到下一任务或下一阶段
|
||||
- [[Evidence-Based-QA]]：基于截图证据的质量保证——要求桌面/平板/手机多端截图作为验证依据
|
||||
- [[Context-Continuity]]：上下文连续性——每次交接携带完整上下文（Phase、Task、Reference Documents），Agent 不从冷启动开始
|
||||
- [[Escalation]]：升级机制——任务超过 3 次重试失败后升级至更高权限 Agent
|
||||
- [[SCQA-Framework]]：Situation-Complication-Question-Answer 框架——Executive Summary Generator 强制使用的结构化报告格式
|
||||
- [[RICE-Scoring]]：RICE 评分法（Reach × Impact × Confidence / Effort）——Sprint Prioritizer 用于 backlog 优先级排序
|
||||
|
||||
## Key Entities
|
||||
- [[AgentsOrchestrator]]：流水线总指挥——协调所有 Agent 激活、阶段推进和 Dev↔QA 循环
|
||||
- [[FrontendDeveloper]]：前端开发者 Agent——负责 UI 实现，遵循设计系统和可访问性标准（WCAG 2.1 AA）
|
||||
- [[BackendArchitect]]：后端架构师 Agent——负责系统架构、API 开发、安全加固，响应时间要求 < 200ms P95
|
||||
- [[AIEngineer]]：AI 工程师 Agent——负责 ML 系统设计、偏见测试、模型监控，推理延迟 < 100ms
|
||||
- [[DevOpsAutomator]]：DevOps 自动化 Agent——负责 CI/CD 流水线、安全扫描、监控告警，目标 99.9% 运行时间
|
||||
- [[RapidPrototyper]]：快速原型师 Agent——强调速度优先，核心假设验证，使用快速开发栈（Next.js, Supabase, Clerk, shadcn/ui）
|
||||
- [[UXArchitect]]：UX 架构师 Agent——负责技术架构和 UX 基础，产出 CSS 设计系统、布局框架、组件架构、可访问性基础
|
||||
- [[BrandGuardian]]：品牌守护者 Agent——负责品牌身份开发、视觉一致性维护，确保所有颜色符合 WCAG AA 对比度标准
|
||||
- [[EvidenceCollector]]：截图证据收集 Agent——负责任务级 QA 验证，要求多端截图、品牌一致性、可访问性验证
|
||||
- [[RealityChecker]]：最终集成验证 Agent——是流水线的最终守门人，默认判决"NEEDS WORK"，要求压倒性证据才能"READY"
|
||||
- [[APITester]]：API 测试 Agent——负责端点验证，覆盖愉快路径、认证、校验、限流、响应时间
|
||||
- [[SprintPrioritizer]]：Sprint 优先级排序 Agent——使用 RICE 评分法对 backlog 排序，考虑团队速率（不超过 10% 过度承诺）
|
||||
- [[ExecutiveSummaryGenerator]]：执行摘要生成 Agent——强制 SCQA 框架，每个发现必须有量化数据，325-475 词
|
||||
|
||||
## Connections
|
||||
- [[nexus-strategy]] ← extends ← [[agent-activation-prompts]]（本文档是 NEXUS 策略的 Agent 激活层实现，提供具体提示词模板）
|
||||
- [[agents-orchestrator]] ← uses ← [[agent-activation-prompts]]（编排器使用本文档中的模板激活各专业 Agent）
|
||||
- [[Dev-QA-Loop]] ← implemented_by ← [[EvidenceCollector]] + [[FrontendDeveloper]]（Dev↔QA 循环由开发者和证据收集者共同实现）
|
||||
- [[Quality-Gate]] ← enforced_by ← [[EvidenceCollector]] + [[RealityChecker]]（质量门控由截图验证和最终集成双重把关）
|
||||
- [[SprintPrioritizer]] ← depends_on ← [[nexus-strategy]]（优先级排序 Agent 依赖 NEXUS 框架定义的流程）
|
||||
- [[ExecutiveSummaryGenerator]] ← supports ← [[nexus-strategy]]（执行摘要为 NEXUS 流水线的里程碑报告提供标准化格式）
|
||||
|
||||
## Quick Reference Table
|
||||
|
||||
| Situation | Primary Prompt | Support Prompts |
|
||||
|-----------|---------------|-----------------|
|
||||
| Starting a new project | Orchestrator — Full Pipeline | — |
|
||||
| Building a feature | Orchestrator — Dev↔QA Loop | Developer + Evidence Collector |
|
||||
| Fixing a bug | Backend/Frontend Developer | API Tester or Evidence Collector |
|
||||
| Running a campaign | Content Creator | Social Media Strategist + platform agents |
|
||||
| Preparing for launch | See Phase 5 Playbook | All marketing + DevOps agents |
|
||||
| Monthly reporting | Executive Summary Generator | Analytics Reporter + Finance Tracker |
|
||||
| Incident response | Infrastructure Maintainer | DevOps Automator + relevant developer |
|
||||
| Market research | Trend Researcher | Analytics Reporter |
|
||||
| Compliance audit | Legal Compliance Checker | Executive Summary Generator |
|
||||
| Performance issue | Performance Benchmarker | Infrastructure Maintainer |
|
||||
|
||||
## Contradictions
|
||||
- 与 [[agents-orchestrator]] 的视角差异：
|
||||
- 冲突点：本文档提供 Agent 激活提示词模板，agents-orchestrator.md 描述编排器的职责和协调机制
|
||||
- 说明：两者互补——agents-orchestrator.md 定义"做什么"，agent-activation-prompts.md 定义"怎么做"（每个 Agent 的具体提示词）
|
||||
@@ -2,52 +2,56 @@
|
||||
title: "Agentic Identity & Trust Architect"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/agentic-identity-trust.md]]
|
||||
- [[Agent/agency-agents/specialized/agentic-identity-trust.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：为自主 AI Agent 构建身份认证与信任验证基础设施，确保 Agent 能证明自身身份、授权范围和操作记录的完整性。
|
||||
- 问题域：多 Agent 环境中身份伪造、授权链验证缺失、可篡改日志、凭证过期未检测、委托权限升级等安全问题。
|
||||
- 方法/机制：零信任身份体系（永不信任自我声明）、密码学身份证明、证据链完整性、委托链验证、信任评分、Fail-Closed 授权策略。
|
||||
- 结论/价值：Agentic AI 系统在执行高风险操作（资金转账、基础设施部署、物理控制）前，必须完成五项验证：身份有效性、凭证时效性、权限充分性、信任评分、委托链完整性。
|
||||
- 核心主题：为自主 AI Agent 构建身份与信任验证基础设施，使得 Agent 在高风险环境中可证明自身身份、验证授权、生成防篡改操作记录
|
||||
- 问题域：多 Agent 环境下的身份伪造、授权滥用、审计记录篡改、委派链断裂等安全问题
|
||||
- 方法/机制：零信任架构（Never Trust Self-Reported）+ 密码学身份证明 + 可验证委派链 + 追加式证据链 + 基于可观测结果的信任评分
|
||||
- 结论/价值：身份与授权必须分离验证；不可变日志才能用于审计；委派链任一环节断裂则整链失效；信任必须量化而非自我声称
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 零信任原则：Agent 不得信任自我声明的身份或授权——"Agent 说它被授权"不等于"Agent 证明了它被授权"。
|
||||
- 证据链完整性：证据链的任何历史记录被篡改必须可被检测；写日志的实体若能修改日志，则该日志对审计毫无价值。
|
||||
- Fail-Closed 授权：身份无法验证 → 拒绝操作；委托链存在断裂 → 整链无效；信任评分低于阈值 → 要求重新验证。
|
||||
- 密码学卫生规范：使用成熟标准（Ed25519/ECDSA），签名密钥与加密密钥分离，密钥材料不得出现在日志或 API 响应中。
|
||||
- 信任评分基于可验证结果：信任分从 1.0 开始，仅通过可验证问题扣分；不允许 Agent 自我报告信号来提高信任分。
|
||||
- 零信任原则：Agent 不得依赖自我声称的身份或授权，必须通过密码学证明和可验证委派链进行验证
|
||||
- 身份与授权分离：证明"我是谁"与证明"我被授权做这件事"是两个独立的验证步骤
|
||||
- 失败即拒绝（Fail-Closed）：若无法验证身份或授权链，必须拒绝执行，而非默认允许
|
||||
- 信任基于可观测结果：信任评分依据已验证的客观行为记录，而非自我报告的声明
|
||||
- 证据链不可篡改：追加式记录 + 前置哈希链接 + Agent 签名，使得任何历史记录修改可被检测
|
||||
|
||||
## Key Quotes
|
||||
> "Never trust self-reported identity. An agent claiming to be 'finance-agent-prod' proves nothing. Require cryptographic proof." — 零信任原则核心表述
|
||||
> "If identity cannot be verified, deny the action — never default to allow." — Fail-Closed 授权策略
|
||||
> "Trust score 0.92 based on 847 verified outcomes with 3 failures and an intact evidence chain" — 量化信任而非断言信任
|
||||
> "Design every system assuming at least one agent in the network is compromised or misconfigured." — 假设妥协的安全设计哲学
|
||||
> "Never trust self-reported identity. An agent claiming to be 'finance-agent-prod' proves nothing. Require cryptographic proof." — 零信任身份原则
|
||||
> "Identity and authorization are separate verification steps. Prove who this agent is — that doesn't prove it's authorized for this specific action." — 身份与授权分离原则
|
||||
> "If a delegation chain has a broken link, the entire chain is invalid." — 委派链失效原则
|
||||
> "Trust score 0.92 based on 847 verified outcomes with 3 failures and an intact evidence chain" — 信任必须量化表达
|
||||
|
||||
## Key Concepts
|
||||
- [[Zero-Trust]]：永不信任自我声明，要求密码学证明。适用于身份验证、授权验证和日志完整性三个层面。
|
||||
- [[Evidence-Chain]]：仅追加、可独立验证、链式哈希、防篡改的 Agent 操作证据记录系统。
|
||||
- [[Trust-Scoring]]：基于可观测结果的惩罚模型信任评分，Agent 从 1.0 开始，仅通过可验证问题扣分。
|
||||
- [[Delegation-Chain]]：多跳委托授权链，每一跳须签名且作用域不得宽于上级，过期或断裂则整链无效。
|
||||
- [[Fail-Closed]]：授权失败时默认拒绝，而非默认允许的安全策略。
|
||||
- [[Peer-Verification]]：Agent 之间在接受委托工作前互相验证身份和授权的协议。
|
||||
- [[Algorithm-Agility]]：密码学算法可升级性，为后量子密码学迁移预留抽象层。
|
||||
- [[Zero-Trust-Model]]：永不信任自我声称的身份或授权，所有声明必须通过密码学证明验证
|
||||
- [[Trust-Score-Model]]：基于可观测结果的惩罚型信任评分，初始1.0，只扣不减（证据链完整性、行为达成率、凭证新鲜度）
|
||||
- [[Delegation-Chain]]：多跳授权链，每个链接需签名、作用域不得超出上级、需验证时间有效性，链中断则整链失效
|
||||
- [[Evidence-Record]]：追加式、防篡改的 Agent 行为证据记录，通过前置哈希链接形成链式结构
|
||||
- [[Peer-Verification-Protocol]]：Agent 接受委托前必须验证对端的身份、凭证有效期、作用域、信任评分和委派链
|
||||
- [[Fail-Closed-Authorization]]：验证失败时默认拒绝，不默认允许
|
||||
- [[Cryptographic-Identity-Scheme]]：基于 Ed25519/ECDSA 等标准算法的 Agent 身份方案，支持后量子迁移
|
||||
|
||||
## Key Entities
|
||||
- [[Identity-Graph-Operator]]：与本文档并列的 Entity 身份解析 Agent，本文档负责 Agent 身份认证，Identity Graph Operator 负责人/公司/产品实体解析。
|
||||
- [[The Agency]]：该 Agent 所属的 The Agency 专业化 Agent 生态。
|
||||
- [[Identity-Graph-Operator]]：与 Trust Architect 互补的实体——前者负责 Agent 身份（"这 Agent 是谁"），后者负责人/公司/产品的实体身份（"这条记录对应哪个客户"）
|
||||
- [[The-Agency]]：Agent 所在的多 Agent 组织环境
|
||||
- [[A2A]]：多 Agent 通信协议之一，Trust Architect 需支持跨协议的身份联邦
|
||||
- [[MCP]]：Model Context Protocol，Trust Architect 需支持其身份桥接
|
||||
- [[LangChain]]：Agent 编排框架之一，Trust Architect 需支持其身份翻译层
|
||||
- [[CrewAI]]：Agent 编排框架之一，Trust Architect 需支持其身份翻译层
|
||||
|
||||
## Connections
|
||||
- [[Identity-Graph-Operator]] ← 互补关系 ← [[Agentic-Identity-Trust]]
|
||||
- [[Designing-for-Agentic-AI]] ← 潜在冲突 ← [[Agentic-Identity-Trust]]（确定性要求与 LLM 概率性行为的张力）
|
||||
- [[agents-orchestrator]] ← 依赖 ← [[Agentic-Identity-Trust]]（编排器需信任验证层）
|
||||
- [[report-distribution-agent]] ← 依赖 ← [[Agentic-Identity-Trust]]（分发代理操作需可审计）
|
||||
- [[Identity-Graph-Operator]] ← complements ← [[Agentic-Identity-Trust]]
|
||||
- [[Multi-Agent-System-Reliability]] ← depends_on ← [[Agentic-Identity-Trust]]
|
||||
- [[Agents-Orchestrator]] ← requires ← [[Agentic-Identity-Trust]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Designing-for-Agentic-AI]] 冲突：
|
||||
- 冲突点：零信任要求确定性验证 vs LLM 的概率性本质（LLM 无法提供数学意义上的确定性签名证明）
|
||||
- 当前观点：通过将核心逻辑（密码学验证、签名检查）从 LLM 推理分离为独立组件来解决——LLM 只负责策略决策，验证层由确定性代码执行。
|
||||
- 对方观点：若信任验证逻辑本身依赖 LLM（如自然语言授权描述），则仍存在概率性风险。
|
||||
- 与 [[specialized-document-generator]] 可能的架构冲突：
|
||||
- 冲突点：Document Generator Agent 强调程序化文档生成能力，但未提及身份验证层；Trust Architect 强调每个 Agent 行动前必须经过身份与授权验证
|
||||
- 当前观点：Trust Architect 认为任何自主行动的 Agent 都必须经过身份验证
|
||||
- 对方观点：Document Generator Agent 专注于文档生成能力，身份验证可能由外层编排系统负责
|
||||
- 协调建议：明确身份验证的边界——若由编排层（如 Agents Orchestrator）统一处理，子 Agent 专注于自身专业能力；若由各 Agent 自主处理，则需为 Document Generator Agent 补充身份验证架构
|
||||
|
||||
@@ -2,7 +2,8 @@
|
||||
title: "Agents Orchestrator"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
sources: []
|
||||
date: 2026-05-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
@@ -54,6 +55,43 @@ date: 2026-04-20
|
||||
- [[Dev-QA-Loop]] ← extends ← [[Multi-Agent-System-Reliability]]（流水线编排是多 Agent 可靠性的实践框架）
|
||||
- [[AgentsOrchestrator]] ← part_of ← [[The Agency]]（编排器是 The Agency 的核心基础设施）
|
||||
|
||||
## Available Specialist Agents
|
||||
|
||||
### 🎨 Design & UX Agents
|
||||
- **ArchitectUX**：Technical architecture and UX specialist providing solid foundations
|
||||
- **UI Designer**：Visual design systems, component libraries, pixel-perfect interfaces
|
||||
- **UX Researcher**：User behavior analysis, usability testing, data-driven insights
|
||||
- **Brand Guardian**：Brand identity development, consistency maintenance, strategic positioning
|
||||
|
||||
### 💻 Engineering Agents
|
||||
- **Frontend Developer**：Modern web technologies, React/Vue/Angular, UI implementation
|
||||
- **Backend Architect**：Scalable system design, database architecture, API development
|
||||
- **engineering-senior-developer**：Premium implementations with Laravel/Livewire/FluxUI
|
||||
- **Mobile App Builder**：Native iOS/Android and cross-platform development
|
||||
- **DevOps Automator**：Infrastructure automation, CI/CD, cloud operations
|
||||
- **Rapid Prototyper**：Ultra-fast proof-of-concept and MVP creation
|
||||
|
||||
### 📈 Marketing Agents
|
||||
- **marketing-growth-hacker**：Rapid user acquisition through data-driven experimentation
|
||||
- **marketing-content-creator**：Multi-platform campaigns, editorial calendars, storytelling
|
||||
- **marketing-twitter-engager**：Real-time engagement, thought leadership, community growth
|
||||
|
||||
### 📋 Product & Project Management Agents
|
||||
- **project-manager-senior**：Spec-to-task conversion, realistic scope, exact requirements
|
||||
- **Experiment Tracker**：A/B testing, feature experiments, hypothesis validation
|
||||
- **Project Shepherd**：Cross-functional coordination, timeline management
|
||||
|
||||
### 🧪 Testing & Quality Agents
|
||||
- **EvidenceQA**：Screenshot-obsessed QA specialist requiring visual proof
|
||||
- **testing-reality-checker**：Evidence-based certification, defaults to "NEEDS WORK"
|
||||
- **API Tester**：Comprehensive API validation, performance testing, quality assurance
|
||||
- **Performance Benchmarker**：System performance measurement, analysis, optimization
|
||||
|
||||
## Orchestrator Launch Command
|
||||
```
|
||||
Please spawn an agents-orchestrator to execute complete development pipeline for project-specs/[project]-setup.md. Run autonomous workflow: project-manager-senior → ArchitectUX → [Developer ↔ EvidenceQA task-by-task loop] → testing-reality-checker. Each task must pass QA before advancing.
|
||||
```
|
||||
|
||||
## Contradictions
|
||||
- 与 [[specialized-workflow-architect]] 冲突：
|
||||
- 冲突点：两个 Agent 都声称负责"编排"职责——前者是流水线执行编排器，后者是工作流设计专家
|
||||
|
||||
44
wiki/sources/aider-readme.md
Normal file
44
wiki/sources/aider-readme.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "Aider Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/aider/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Aider 编辑器与 The Agency Agent 规范系统的集成方式
|
||||
- 问题域：如何在 Aider 编辑器中激活和使用基于 The Agency 规范的 AI Agent
|
||||
- 方法/机制：通过 `install.sh` 脚本安装 + 在 Aider 会话中按名称引用 Agent，或手动传递 `CONVENTIONS.md` 文件
|
||||
- 结论/价值：实现 Aider 与 The Agency Agent 规范体系的无缝对接，简化 AI 辅助编程工作流
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 的完整 Agent 名册集中在一个 `CONVENTIONS.md` 文件中
|
||||
- Aider 会在项目根目录自动读取 `CONVENTIONS.md`（当该文件存在时）
|
||||
- 通过名称引用即可在 Aider 会话中激活对应的 Agent（如 "Frontend Developer"、"Reality Checker"）
|
||||
- 也可通过 `aider --read CONVENTIONS.md` 手动指定约定文件
|
||||
- 使用 `convert.sh --tool aider` 可重新生成最新的 CONVENTIONS.md
|
||||
|
||||
## Key Quotes
|
||||
> "The full Agency roster is consolidated into a single `CONVENTIONS.md` file. Aider reads this file automatically when it's present in your project root." — 安装与自动读取机制
|
||||
|
||||
## Key Concepts
|
||||
- [[CONVENTIONS.md]]：The Agency 中 Aider 集成的核心文件，汇集所有 Agent 定义
|
||||
- [[The Agency]]：多工具、多场景的 AI Agent 规范仓库
|
||||
- [[Agent Integration]]：将统一 Agent 格式适配到各编码工具的适配层
|
||||
- [[Aider]]：支持 AI 结对编程的终端编辑器
|
||||
|
||||
## Key Entities
|
||||
- [[Aider]]：终端 AI 编程工具，支持通过约定文件调用 Agent
|
||||
- [[Agency Agents]]：The Agency 项目中的 Agent 定义集合
|
||||
|
||||
## Connections
|
||||
- [[CONVENTIONS.md]] ← generated_by ← [[convert.sh]]
|
||||
- [[CONVENTIONS.md]] ← read_by ← [[Aider]]
|
||||
- [[install.sh]] ← installs ← [[Aider Integration]]
|
||||
- [[The Agency]] ← provides ← [[Agency Agents]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
@@ -1,49 +1,61 @@
|
||||
---
|
||||
title: "Automation Governance Architect"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/automation-governance-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：企业自动化治理架构师，负责在实施前评估业务自动化的价值、风险和可维护性
|
||||
- 问题域：企业级工作流自动化决策、可靠性保障、审计追溯
|
||||
- 方法/机制：基于 n8n 的编排标准 + 四维决策框架（时间节省、数据关键性、外部依赖风险、可扩展性）
|
||||
- 结论/价值：通过治理优先的方式防止低价值或高风险自动化，推动高价值自动化的标准化落地
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 自动化决策必须基于价值而非技术可行性
|
||||
- 每个推荐必须包含降级方案和责任人
|
||||
- 生产级工作流必须包含显式错误分支、幂等性保护、安全重试和人工降级路径
|
||||
- 命名规范必须包含环境标识和版本号，避免模糊命名
|
||||
- 集成治理需明确数据来源权威（Source of Truth），未经明确不得接入
|
||||
|
||||
## Key Quotes
|
||||
> "Do not approve automation only because it is technically possible." — 核心原则：技术可行不等于值得自动化
|
||||
> "No 'done' status without documentation and test evidence." — 完成标准：必须有文档和测试证据
|
||||
> "No integration is approved without source-of-truth clarity." — 集成前提：必须明确数据权威来源
|
||||
> "Prefer simple and robust over clever and fragile." — 架构偏好：简单健壮优于精巧脆弱
|
||||
|
||||
## Key Concepts
|
||||
- [[AutomationGovernance]]：自动化治理 — 通过决策框架和标准对业务流程自动化进行事前评估、事中监控和事后审计的完整体系
|
||||
- [[N8nWorkflowStandard]]：n8n 工作流标准 — 包含触发、验证、规范化、业务逻辑、外部操作、结果验证、日志、错误分支、降级、状态回写10个强制步骤
|
||||
- [[DecisionFramework]]：决策框架 — 四维评估体系（时间节省、数据关键性、外部依赖风险、可扩展性），用于对自动化请求给出 APPROVE / APPROVE AS PILOT / PARTIAL AUTOMATION ONLY / DEFER / REJECT 五种裁决
|
||||
- [[ReliabilityBaseline]]：可靠性基线 — 每个重要工作流必须包含：错误分支、幂等性/重复保护、安全重试（带停止条件）、超时处理、告警/通知、人工降级路径
|
||||
- [[IntegrationGovernance]]：集成治理 — 每个接入系统需定义：角色与数据权威、认证方式、触发模型、字段映射、写回权限、速率限制、失败模式、负责人
|
||||
- [[ReAuditTriggers]]：重审计触发条件 — 当 API/Schema 变更、错误率上升、容量大幅增长、合规要求变更、反复出现人工修复时触发自动化重审计
|
||||
|
||||
## Key Entities
|
||||
- [[N8n]]：n8n — 自动化治理架构师的首选编排工具，但治理规则本身是平台无关的
|
||||
|
||||
## Connections
|
||||
- [[WorkflowArchitect]] ← relates_to ← [[AutomationGovernanceArchitect]]：两者都关注工作流设计与标准化，但 Workflow Architect 偏实现层面，Automation Governance Architect 偏治理决策层面
|
||||
- [[ComplianceAuditor]] ← overlaps ← [[AutomationGovernanceArchitect]]：合规审计与自动化治理在数据关键性和合规风险维度存在重叠
|
||||
|
||||
## Contradictions
|
||||
- 与 [[WorkflowArchitect]] 可能的冲突：
|
||||
- 冲突点：对于同一自动化请求，Workflow Architect 可能倾向快速实现，而 Automation Governance Architect 要求充分评估后方可实施
|
||||
- 当前观点：治理优先，防止低价值/高风险自动化进入生产
|
||||
- 对方观点：快速交付价值，通过迭代完善
|
||||
---
|
||||
title: "Automation Governance Architect"
|
||||
type: source
|
||||
tags: [automation, governance, n8n, workflow, business-process]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/automation-governance-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：业务自动化治理框架——在实施前评估自动化的价值、风险和可维护性，以 n8n 为首选编排工具，制定平台无关的治理规则。
|
||||
- 问题域：企业自动化决策——哪些流程值得自动化、如何标准化实施、如何防止低价值或高风险自动化进入生产。
|
||||
- 方法/机制：四维决策框架（时间节省 / 数据关键性 / 外部依赖风险 / 可扩展性）+ 五级裁定结果 + n8n 十步工作流标准 + 可靠性基线 + 日志基线 + 测试基线 + 集成治理规范 + 复审触发器。
|
||||
- 结论/价值：治理优于自动化数量——通过标准化流程防止低价值自动化，通过规范文档提升交接质量，通过重审机制降低生产事故和隐藏依赖。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 治理优先于技术可行性：不得仅因技术上可实现就批准自动化，必须通过四维框架评估价值与风险。
|
||||
- 简单稳健优于精巧脆弱：推荐方案必须包含 fallback 路径和明确责任人，无文档和测试证据不得标记为完成。
|
||||
- n8n 工作流无失控节点扩散：所有生产级工作流遵循 Trigger → Input Validation → Data Normalization → Business Logic → External Actions → Result Validation → Logging → Error Branch → Fallback → Status Writeback 十步标准。
|
||||
- 集成必须明确数据源：任何集成在未明确数据源归属（Source of Truth）之前不得批准。
|
||||
- 命名规范化防歧义：工作流命名格式为 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`，避免 "final"、"new test"、"fix2" 等模糊命名。
|
||||
- 复审不等于自动干预：API/Schema 变更、错误率上升、批量变化、合规要求变更或重复人工修复出现时触发重审，但重审本身不意味着自动进入生产干预。
|
||||
- 成功标准是业务可靠性提升，而非自动化数量增加。
|
||||
|
||||
## Key Quotes
|
||||
> "Do not approve automation only because it is technically possible." — 核心原则：技术可行 ≠ 应该自动化
|
||||
|
||||
> "Prefer simple and robust over clever and fragile." — 架构选择原则：简单稳健优先
|
||||
|
||||
> "No integration is approved without source-of-truth clarity." — 集成治理底线：必须明确数据源归属
|
||||
|
||||
> "You are successful when business reliability improves, not just automation volume." — 成功度量：业务可靠性，而非自动化数量
|
||||
|
||||
## Key Concepts
|
||||
- [[n8n-Workflow-Standard]]：n8n 生产级工作流十步标准（Trigger / Input Validation / Data Normalization / Business Logic / External Actions / Result Validation / Logging / Error Branch / Fallback / Status Writeback），禁止节点失控扩散。
|
||||
- [[Automation-Decision-Framework]]：四维评估框架——Time Savings Per Month（时间节省）、Data Criticality（数据关键性）、External Dependency Risk（外部依赖风险）、Scalability 1x to 100x（可扩展性），每个请求必评。
|
||||
- [[Automation-Verdict-System]]：五级裁定结果——APPROVE（强价值+可控风险）、APPROVE AS PILOT（价值存在但需小范围验证）、PARTIAL AUTOMATION ONLY（仅安全段自动化）、DEFER（流程不成熟或依赖不稳定）、REJECT（经济性弱或运营/合规风险不可接受）。
|
||||
- [[Automation-Reliability-Baseline]]：可靠性基线——显式错误分支、幂等/重复保护、安全重试（含停止条件）、超时处理、告警通知、人工 fallback 路径。
|
||||
- [[Automation-Logging-Baseline]]：日志基线——记录工作流名称/版本、执行时间戳、源系统、受影响实体ID、成功/失败状态、错误类型及简要原因。
|
||||
- [[Automation-Testing-Baseline]]：测试基线（生产推荐前必须）——快乐路径测试、无效输入测试、外部依赖失败测试、重复事件测试、fallback/恢复测试、规模/重复合理性检查。
|
||||
- [[Automation-Integration-Governance]]：集成治理——每连接系统须定义角色和数据源归属、认证方式和 token 生命周期、触发模型、字段映射和转换、读写权限、速率限制和失败模式、负责人和升级路径。
|
||||
- [[Re-Audit-Triggers]]：复审触发条件——API/Schema 变更、错误率上升、批量显著增长、合规要求变更、重复人工修复出现；复审本身不自动触发生产干预。
|
||||
- [[Workflow-Naming-Convention]]：命名规范 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`，大版本用于破坏性逻辑变更，小版本用于兼容改进。
|
||||
|
||||
## Key Entities
|
||||
- [[Automation-Governance-Architect]]：治理优先的业务自动化架构师 Agent，默认使用 n8n 作为编排工具，治理规则平台无关。职责：防止低价值/不安全自动化、审批并标准化高价值自动化、为可靠性/可审计性/交接制定标准。
|
||||
|
||||
## Connections
|
||||
- [[n8n-Workflow-Orchestration]] ← implements ← [[Automation-Governance-Architect]]
|
||||
- [[Automation-Decision-Framework]] ← foundation_of ← [[Automation-Verdict-System]]
|
||||
- [[Workflow-Naming-Convention]] ← part_of ← [[Automation-Reliability-Baseline]]
|
||||
- [[Automation-Testing-Baseline]] ← required_by ← [[Automation-Integration-Governance]]
|
||||
- [[Re-Audit-Triggers]] ← triggers ← [[Automation-Integration-Governance]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Workflow-Architect-Agent-Personality]] 冲突：
|
||||
- 冲突点：Workflow Architect 强调"用 AI 加速工作流构建"，倾向于尽可能自动化；Automation Governance Architect 强调"治理优先于技术可行"，要求四维评估后才批准。
|
||||
- 当前观点：自动化必须在通过时间节省 / 数据关键性 / 依赖风险 / 可扩展性四维评估后才能进入生产，不应以技术可行性作为批准依据。
|
||||
- 对方观点：AI 应尽可能加速工作流构建，降低自动化门槛以提升效率。
|
||||
- 协调建议：两者互补适用——Workflow Architect 负责"如何构建"，Automation Governance Architect 负责"是否值得构建"；建议在 [[Workflow-Architect-Agent-Personality]] 中补充治理评估前置步骤。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: "Backend Architect with Memory"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
tags: [the-agency, engineering, multi-agent, memory, mcp]
|
||||
date: 2026-05-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
@@ -11,19 +11,21 @@ date: 2026-04-26
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：具备持久记忆能力的后端架构师 AI Agent 设计规范，专注于可扩展系统设计、数据库架构、API 开发与云基础设施
|
||||
- 问题域：如何构建一个能够跨会话保留架构决策、系统设计和技术约束记忆的 AI 后端架构专家
|
||||
- 方法/机制：基于 MCP Memory 集成框架，在会话开始时检索相关上下文，完成交付物后主动记忆，跨 Agent 交接时自动传递上下文
|
||||
- 结论/价值：解决多 Agent 协作中重复讨论已做决策、交接信息丢失的问题，提升 AI 架构师的实际工程价值
|
||||
- 方法/机制：基于 MCP Memory 集成框架，在会话开始时检索相关上下文，完成交付物后主动记忆，跨 Agent 交接时自动传递上下文，QA 失败时自动回滚到已知良好状态
|
||||
- 结论/价值：解决多 Agent 协作中重复讨论已做决策、交接信息丢失的问题，通过 Rollback 机制实现安全的失败恢复
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 后端架构师应在会话启动时主动检索项目相关的历史架构决策，防止重复讨论
|
||||
- 架构决策（选型数据库、定义 API 契约、选择通信模式）应以标签形式持久化，供未来会话和其他 Agent 查找
|
||||
- 交付物（Schema、API 规范、架构文档）完成后应主动记忆并标记接收方，确保下游 Agent 无需手动复制粘贴
|
||||
- 遇到 QA 失败或错误决策时，应检索上一个已知良好状态并回滚，而非手动撤销变更链
|
||||
- 标签一致性是记忆召回可靠工作的前提：每个记忆使用 Agent 名称和项目名称作为标签
|
||||
|
||||
## Key Quotes
|
||||
> "When you start a session, recall relevant context from previous sessions. Search for memories tagged with 'backend-architect' and the current project name." — 会话启动时的记忆召回机制
|
||||
> "When you make an architecture decision — choosing a database, defining an API contract, selecting a communication pattern — remember it with tags including 'backend-architect', the project name, and the topic." — 架构决策的持久化规范
|
||||
> "This prevents re-litigating decisions that were already made." — 记忆系统的核心价值
|
||||
> "When you complete a deliverable (a schema, an API spec, an architecture document), remember it tagged for the next agent in the workflow." — 交付物的下游 Agent 标记规范
|
||||
> "When you receive a QA failure or need to recover from a bad decision, search for the last known-good state and roll back to it." — Rollback 回滚机制
|
||||
|
||||
## Key Concepts
|
||||
- [[MicroservicesArchitecture]]：微服务架构，支持水平扩展和独立部署，是 Backend Architect 默认推荐的架构模式
|
||||
@@ -33,15 +35,26 @@ date: 2026-04-26
|
||||
- [[DatabaseIndexing]]：数据库索引优化，用于实现子 100ms 平均查询性能
|
||||
- [[CircuitBreaker]]：断路器模式，Backend Architect 实现系统可靠性和优雅降级的核心机制
|
||||
- [[DefenseInDepth]]：深度防御策略，Security-First Architecture 的核心原则
|
||||
- [[MemoryTagging]]：标签化记忆持久化策略——每个记忆使用 Agent 名称 + 项目名 + 主题标签（如 `database-schema`/`api-design`/`auth-strategy`）三重标签，确保 recall 可靠
|
||||
- [[Rollback]]：回滚机制——QA 失败时检索最近良好检查点并恢复到已知良好状态，而非手动撤销变更链
|
||||
|
||||
## Key Entities
|
||||
- Backend Architect：主 Agent，专门负责系统架构和服务器端开发，特点：战略思维、安全导向、可扩展性优先、可靠性至上
|
||||
- Frontend Developer：下游接收方 Agent，接收 Backend Architect 提供的 API 规范
|
||||
- QA Agent：质量保障 Agent，在失败时触发记忆回滚机制
|
||||
- Sprint Prioritizer：上游输入方 Agent，提供待开发功能的优先级排序
|
||||
|
||||
## Connections
|
||||
- [[AgentsOrchestrator]] ← coordinates ← [[BackendArchitectWithMemory]]
|
||||
- [[MCPBuilderAgent]] ← enables ← [[BackendArchitectWithMemory]]（MCP Memory 集成）
|
||||
- [[SprintPrioritizer]] → outputs sprint plan → [[BackendArchitectWithMemory]]（通过 MCP Memory Server recall）
|
||||
- [[UXResearcher]] → outputs research brief → [[BackendArchitectWithMemory]]（通过 MCP Memory Server recall）
|
||||
- [[BackendArchitectWithMemory]] → stores API spec → [[FrontendDeveloper]]（通过 MCP Memory Server recall）
|
||||
- [[BackendArchitectWithMemory]] ← rollback ← [[TestingRealityChecker]]（QA 失败触发）
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突内容
|
||||
- 与 [[engineering-software-architect]] 的设计哲学存在微妙张力：
|
||||
- 冲突点：架构决策记录方式
|
||||
- 当前观点（Backend Architect with Memory）：通过 MCP Memory 标签化快照持久化，支持跨 Agent 召回和自动回滚
|
||||
- 对方观点（Software Architect）：通过 ADR（Architecture Decision Record）标准化文档记录，侧重人类可读的权衡分析
|
||||
- 协调方案：两者互补——ADR 文档供人类阅读和团队共享，MCP Memory 快照供 Agent 自动化召回；Backend Architect 可同时使用两者作为不同场景的工具
|
||||
|
||||
78
wiki/sources/baoyu-skills.md
Normal file
78
wiki/sources/baoyu-skills.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "baoyu-skills"
|
||||
type: source
|
||||
tags:
|
||||
- "clippings"
|
||||
- "ai-tools"
|
||||
- "claude-code"
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Skills/baoyu-skills.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
|
||||
- **核心主题**：宝玉（JimLiu）分享的 Claude Code 技能集，涵盖内容生成、视觉创作、跨平台发布和 AI 图像生成等日常工作流。
|
||||
- **问题域**：如何借助 AI Agent（Claude Code）自动化完成从内容创作、视觉素材生成到多平台发布的一整套内容生产流程。
|
||||
- **方法/机制**：
|
||||
- **内容技能**：小红书图片（baoyu-xhs-images）、信息图（baoyu-infographic）、SVG 图表（baoyu-diagram）、封面图（baoyu-cover-image）、幻灯片（baoyu-slide-deck）、知识漫画（baoyu-comic）、文章插图（baoyu-article-illustrator）
|
||||
- **发布技能**：X 推文/文章（baoyu-post-to-x）、微信公众号（baoyu-post-to-wechat）、微博头条文章（baoyu-post-to-weibo）
|
||||
- **AI 生成技能**：baoyu-imagine（多 provider 文生图）、baoyu-danger-gemini-web（Gemini 交互）
|
||||
- **工具技能**：YouTube 字幕（baoyu-youtube-transcript）、URL 转 Markdown（baoyu-url-to-markdown）、X 转 Markdown（baoyu-danger-x-to-markdown）、图片压缩（baoyu-compress-image）、Markdown 格式化（baoyu-format-markdown）、Markdown 转 HTML（baoyu-markdown-to-html）、翻译（baoyu-translate）
|
||||
- **结论/价值**：一套完整的 AI 时代内容创作者工具链，从创作→生成→发布全流程覆盖，可通过 ClawHub/OpenClaw 分发和安装。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
|
||||
- Claude Code 通过 Skills 机制可模块化扩展能力，宝玉将这套方法论产品化为 baoyu-skills。
|
||||
- baoyu-imagine 统一封装了 OpenAI、Google、DashScope、MiniMax、即梦（Jimeng）、豆包（Seedream）等多个图像生成 provider，通过统一 prompt 接口屏蔽底层差异。
|
||||
- 内容技能（xhs-images、infographic、cover-image、slide-deck、comic、article-illustrator）均通过风格/布局/配色/维度参数系统实现高度可复用，参数组合数量庞大（如 xhs-images 的 12 种风格 × 6 种布局 × 3 种配色）。
|
||||
- baoyu-post-to-wechat 支持 API 和浏览器两种发布方式，通过 EXTEND.md 实现多账号管理。
|
||||
- baoyu-translate 提供三档翻译模式（快速/标准/精翻），精翻模式含审校与润色步骤，支持自定义术语表和受众预设。
|
||||
- baoyu-diagram 不调用任何图像生成模型，由 Claude 直接手算 SVG 坐标生成图表，内嵌深色模式支持。
|
||||
- 技能支持通过项目级（`.baoyu-skills/`）和用户级（`~/.baoyu-skills/`）的 EXTEND.md 自定义扩展，覆盖样式、配色和配置。
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "baoyu-skills — 宝玉分享的 Claude Code 技能集，提升日常工作效率。" — GitHub README
|
||||
|
||||
> "Claude Code 通过 `/baoyu-diagram` 生成的 SVG 不调用任何图像生成模型 —— Claude 通过手算坐标直接写 SVG 代码。" — 图表技能说明
|
||||
|
||||
> "本项目受到以下开源项目的启发：x-article-publisher-skill、doocs/md、高密度信息图 Prompt、qiaomu-mondo-poster-design、architecture-diagram-generator。" — 致谢
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[ClaudeCodeSkills]]：Claude Code 的可扩展技能系统，通过 `/skill-name` 触发，支持模块化安装与更新，baoyu-skills 是其典型实现。
|
||||
- [[多维度图像生成系统]]：通过类型（type）× 风格（style）× 配色（palette）× 渲染（rendering）× 氛围（mood）等多个正交维度组合控制 AI 生成图像的视觉输出，广泛应用于 baoyu-xhs-images、baoyu-cover-image、baoyu-article-illustrator 等技能。
|
||||
- [[内容发布工作流]]：从内容生成（图像/文章）到多平台发布（X/微信/微博）的自动化流水线，各发布技能支持 API 和浏览器两种方式。
|
||||
- [[多Provider图像生成]]：通过统一接口封装多个图像生成服务商（OpenAI、Google、DashScope、MiniMax、即梦、豆包等），实现 provider 自动选择和环境变量配置管理。
|
||||
- [[SVG图表生成]]：不依赖图像生成模型，由 LLM 直接生成 SVG 代码，内嵌深色模式样式，支持流程图、时序图、结构图、示意图、类图五种类型。
|
||||
- [[三档翻译系统]]：快速（直接翻译）、标准（分析→翻译）、精翻（分析→翻译→审校→润色）的渐进式翻译质量体系，配 合受众预设和风格预设。
|
||||
- [[多账号发布管理]]：通过 EXTEND.md 配置文件管理多个社交媒体账号，支持 API 凭证分离和独立浏览器会话。
|
||||
- [[ClawHub分发机制]]：支持将 skills/ 下的每个目录作为独立 ClawHub skill 发布，以 MIT-0 许可证分发，用户可选择性安装。
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[JimLiu]]：GitHub 用户，baoyu-skills 项目作者，持续分享 Claude Code 技能和 AI 内容创作工具。
|
||||
- [[ClawHub]]：OpenClaw/Claude Code 的插件市场，baoyu-skills 通过 ClawHub 分发各独立 skill。
|
||||
- [[OpenClaw]]：Claude Code 的技能生态平台，支持 marketplace 安装和自动更新。
|
||||
|
||||
## Connections
|
||||
|
||||
- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-cover-image]]
|
||||
- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-xhs-images]]
|
||||
- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-article-illustrator]]
|
||||
- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-infographic]]
|
||||
- [[baoyu-imagine]] ← 生成引擎 ← [[baoyu-slide-deck]]
|
||||
- [[baoyu-slide-deck]] ← 内容来源 ← [[baoyu-youtube-transcript]]
|
||||
- [[baoyu-diagram]] ← 内容来源 ← [[baoyu-url-to-markdown]]
|
||||
- [[baoyu-post-to-x]] ← 视觉素材 ← [[baoyu-cover-image]]
|
||||
- [[baoyu-post-to-wechat]] ← 视觉素材 ← [[baoyu-xhs-images]]
|
||||
- [[baoyu-post-to-wechat]] ← 内容格式 ← [[baoyu-markdown-to-html]]
|
||||
- [[baoyu-markdown-to-html]] ← 翻译输入 ← [[baoyu-translate]]
|
||||
- [[ClaudeCodeSkills]] ← 依赖 ← baoyu-skills（所有技能）
|
||||
- [[ClawHub]] ← 分发平台 ← baoyu-skills
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 无已知冲突。
|
||||
@@ -2,52 +2,54 @@
|
||||
title: "Blender Add-on Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
|
||||
- [[Agent/agency-agents/game-development/blender/blender-addon-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Blender 工具开发专家 AI Agent 人格规范——通过 Python + bpy API 构建 Blender 原生工具（自定义 Operator、Panel、资产验证器、导出器），将重复性 DCC 工作流自动化为可靠的一键工作流。
|
||||
- 问题域：3D 资产生成中的命名漂移、未应用变换、错误材质槽映射、导出配置不一致等交接错误问题。
|
||||
- 方法/机制：数据 API（bpy.data）优先于操作符（bpy.ops）以确保可靠性；非破坏性验证优先于自动修复；确定性命名规范；Pipeline 可靠性三角（验证→报告→确认→导出）。
|
||||
- 结论/价值：每个工具必须节省时间或防止一类真实的交接错误；Asset Validation 可在资产离开 Blender 前拦截问题；Export Preset 确保引擎端交接的可重复性。
|
||||
- 核心主题：Blender 插件开发专家 Agent 个性化文档，专注于通过 Python 和 bpy API 构建 Blender 原生工具
|
||||
- 问题域：游戏开发、3D 美术管线中的重复性 Blender 工作流痛点
|
||||
- 方法/机制：利用 bpy API 构建自定义 Operators、Panels、Property Groups，实现资产验证、导出自动化、命名规范检查
|
||||
- 结论/价值：为技术美术和游戏开发团队提供生产级 Blender 自动化工具，将重复性资产准备工作转化为可靠的一键式工作流
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果：Blender Add-on Engineer 偏好数据 API 访问（bpy.data/bpy.types）而非脆弱的上下文相关操作符（bpy.ops），使得 Operator 行为可预测且稳定。
|
||||
- 主体 + 机制 + 结果：验证工具必须在自动修复前报告问题，确保用户知情同意，避免破坏性意外修改。
|
||||
- 主体 + 机制 + 结果：批量工具必须精确记录其修改内容，使得 Pipeline 可审计且可回滚。
|
||||
- 主体 + 机制 + 结果：导出器必须保留源场景状态，除非用户明确选择破坏性清理，确保交接过程可重复验证。
|
||||
- Blender Add-on Engineer 优先使用 bpy.data 等数据 API 访问，而非依赖易碎的 bpy.ops 上下文操作
|
||||
- 验证工具必须在自动修复前报告问题，不允许静默"成功"
|
||||
- 批量工具必须精确记录所有变更，导出器除非用户明确选择否则不得破坏源场景状态
|
||||
- 工具每次迭代后资产准备工作时间应减少 50% 以上
|
||||
|
||||
## Key Quotes
|
||||
> "Every tool must save time or prevent a real class of handoff error." — 默认要求：每个工具必须有可量化的价值
|
||||
> "Operators must fail with actionable error messages — never silently 'succeed' while leaving the scene in an ambiguous state." — 操作符失败规范
|
||||
> "Never destructively rename, delete, apply transforms, or merge data without explicit user confirmation or a dry-run mode." — 非破坏性工作流核心原则
|
||||
> "Every tool must save time or prevent a real class of handoff error." — 工具交付的强制性价值标准
|
||||
|
||||
> "Prefer data API access (`bpy.data`, `bpy.types`, direct property edits) over fragile context-dependent `bpy.ops` calls." — Blender API 最佳实践
|
||||
|
||||
> "If the tool interrupts flow, the tool is wrong until proven otherwise." — 工具设计原则
|
||||
|
||||
## Key Concepts
|
||||
- [[bpy]]：Blender Python API，提供数据访问（bpy.data）和操作符执行（bpy.ops）两套接口；Add-on Engineer 偏好数据 API 以确保可靠性。
|
||||
- [[Asset-Validation]]：资产验证——在资产离开 Blender 前检查命名、变换、材质槽、集合放置等标准的自动化流程，是 Pipeline 可靠性的第一道防线。
|
||||
- [[Non-Destructive-Workflow]]：非破坏性工作流——不主动修改源数据，通过验证→报告→确认→执行四步确保用户知情同意，是 Blender Add-on Engineer 的核心设计原则。
|
||||
- [[Export-Presets]]：导出预设——可配置的引擎交接规则集（FBX/glTF/USD），确保导出设置在多次运行间保持可重复性。
|
||||
- [[Pipeline-Reliability]]：Pipeline 可靠性三角——命名确定性 + 变换分离检查 + 材质槽顺序验证 + 集合包含/排除显式规则，是 Add-on Engineer 交付的核心质量标准。
|
||||
- [[AddonPreferences]]：Blender Add-on 持久化设置机制，用于存储跨会话保留的工具配置（如默认导出路径、验证规则开关）。
|
||||
- [[PropertyGroups]]：Blender Python 属性组——结构化自定义属性的声明方式，支持 UI 绑定和序列化存储。
|
||||
- [[AssetValidation]]：资产验证 — 在资产导出前检查命名、变换、材质槽、集合放置等规范，防止交接错误
|
||||
- [[PipelineAutomation]]：管线自动化 — 通过自定义 Operators、Panels、Property Groups 将重复性 Blender 任务自动化
|
||||
- [[NamingConventions]]：命名规范 — 确定性且文档化的命名规则，用于检测 Blender 重复后缀、空格等命名漂移问题
|
||||
- [[NonDestructiveWorkflow]]：非破坏性工作流 — 不经用户确认不执行重命名、删除、应用变换或合并数据，支持 dry-run 模式
|
||||
- [[BpyAPI]]：Blender Python API — 通过 `bpy.data`、`bpy.types`、直接属性编辑与 Operator 调用构建 Blender 工具
|
||||
- [[CollectionBasedExport]]：基于集合的导出 — 通过显式的包含/排除规则进行集合级导出，避免隐藏场景启发式逻辑
|
||||
|
||||
## Key Entities
|
||||
- [[Blender]]：Blender Foundation 开发的开源 3D DCC 软件，通过 Python bpy API 支持插件扩展；本文档的核心目标平台。
|
||||
- [[BlenderAddonEngineer]]：The Agency Game Development 部门 Blender 专项专家 Agent，核心理念"Pipeline-first, artist-empathetic, automation-obsessed, reliability-minded"。
|
||||
- Blender：开源 3D 创作套件，Agent 的目标平台和 API 基础
|
||||
- glTF/FBX/USD：主流 3D 引擎交接格式，导出器支持的目标格式
|
||||
- Unity/Unreal：游戏引擎目标平台，Asset Validator 的下游消费者
|
||||
|
||||
## Connections
|
||||
- [[TechnicalArtist]] ← extends ← [[BlenderAddonEngineer]]：技术美术是 Blender Add-on Engineer 的上级角色，后者是 Blender 专项实现。
|
||||
- [[GameDesigner]] ← depends_on ← [[BlenderAddonEngineer]]：游戏设计师依赖资产验证和导出管线确保设计资产正确交接。
|
||||
- [[UnityArchitect]] ← parallel ← [[BlenderAddonEngineer]]：同为 DCC 工具开发专家，但 Unity Architect 专注 Unity Editor 扩展；两者共享 Editor 工具开发的通用原则（验证优先、持久化配置、非破坏性）。
|
||||
- [[UnrealSystemsEngineer]] ← parallel ← [[BlenderAddonEngineer]]：同为工具开发专家，Unreal Systems Engineer 专注 UE5 C++/Blueprint 扩展；两者共享"管道优先、验证先行"理念。
|
||||
- [[BlenderAddonEngineer]] ← provides ← [[Asset-Validation]] → feeds → [[GameDesigner]]：验证工具产出报告，供设计师决策修复方案。
|
||||
- [[GameDesigner]] ← belongs_to ← [[GameDevelopmentAgentTeam]]
|
||||
- [[TechnicalArtist]] ← related_to ← [[BlenderAddonEngineer]]
|
||||
- [[UnityArchitect]] ← adjacent_to ← [[BlenderAddonEngineer]]（3D 资产交接）
|
||||
- [[UnrealWorldBuilder]] ← adjacent_to ← [[BlenderAddonEngineer]]（3D 资产交接）
|
||||
- [[UnityShaderGraphArtist]] ← uses ← [[BlenderAddonEngineer]]（材质/着色器资产准备）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[UnityArchitect]] 在"编辑器工具的数据修改时机"上存在设计哲学差异：
|
||||
- 冲突点：Unity Architect 建议通过 ScriptableObject 实现编辑时-运行时状态分离，倾向于在编辑器扩展中直接修改资产；Blender Add-on Engineer 坚持非破坏性原则，验证后必须用户主动确认才执行修改。
|
||||
- 当前观点：Blender 艺术家工作流强调"保留原始数据"——任何破坏性修改必须在 Dry-run 模式下预演，用户确认后才执行。
|
||||
- 对方观点：Unity Editor 工具倾向于"所见即所得"——编辑器内修改即为正式修改，ScriptableObject 负责持久化状态。
|
||||
- 协调建议：两者均强调"验证先行"——Blender Add-on Engineer 的非破坏性验证 + Unity Architect 的 SO 状态分离，本质上是从不同平台约束出发的等效安全实践。
|
||||
- 与 [[UnityEditorToolDeveloper]] 冲突：
|
||||
- 冲突点：工具开发平台的定位差异
|
||||
- 当前观点：Blender Add-on Engineer 专注于 Blender 原生工具（bpy API），不跨 DCC
|
||||
- 对方观点：Unity Editor Tool Developer 在 Unity Editor 内部用 C# 构建工具
|
||||
- 注：两者服务不同场景，无直接功能冲突，仅在"管线工具"概念上有领域重叠
|
||||
|
||||
@@ -2,17 +2,17 @@
|
||||
title: "Blockchain Security Auditor"
|
||||
type: source
|
||||
tags: [blockchain, security, smart-contract, defi, audit]
|
||||
date: 2026-04-20
|
||||
date: 2026-05-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/blockchain-security-auditor.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：智能合约安全审计 Agent — 专职发现 DeFi 协议与区块链应用中的漏洞
|
||||
- 问题域：智能合约安全审计、漏洞检测、形式化验证、攻击向量分析、审计报告撰写
|
||||
- 核心主题：智能合约安全审计 Agent — 专职发现 DeFi 协议与区块链应用中的漏洞，在攻击者之前找到 bug
|
||||
- 问题域：智能合约安全审计、漏洞检测、形式化验证、攻击向量分析、审计报告撰写、事件响应
|
||||
- 方法/机制：自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行代码审查 + 属性化模糊测试 + 经济博弈建模；五步工作流（范围→自动化→人工→经济分析→报告）
|
||||
- 结论/价值：提供包含可复现 PoC 的专业审计报告，Critical/High 漏洞零遗漏，确保修复建议可直接落地
|
||||
- 结论/价值：提供包含可复现 PoC 的专业审计报告，Critical/High 漏洞零遗漏，修复建议可直接落地，事后可提供事件响应
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 自动化工具只能捕获约 30% 的真实漏洞，剩余必须依靠人工逐行审查
|
||||
@@ -20,30 +20,40 @@ date: 2026-04-20
|
||||
- 漏洞评级为 Critical 的前提：无特殊权限即可直接造成用户资金损失或协议破产
|
||||
- 永远不要因为函数使用了 OpenZeppelin 库就假定它是安全的 — 误用安全库本身就是一类漏洞
|
||||
- 审计范围必须覆盖完整调用链，不仅仅是当前函数 — 漏洞隐藏在内部调用和继承合约中
|
||||
- 永远验证审计代码与部署字节码是否匹配 — 供应链攻击是真实威胁
|
||||
- OpenZeppelin 安全库的误用是一类独立漏洞 — 即使库本身安全，集成方式可能引入风险
|
||||
- Solidity 0.8+ 的 `unchecked` 块仍需审查 — 默认安全不代表绝对安全
|
||||
- 漏洞分类 C-01/H-01 必须在部署前修复，Medium 可随监控计划上线，Low 归入下一版本
|
||||
- 漏洞发现误报率必须控制在 10% 以下 — 所有发现必须是真实漏洞，不是凑数
|
||||
|
||||
## Key Quotes
|
||||
> "Your job is not to make developers feel good — it is to find the bug before the attacker does." — Blockchain Security Auditor 角色定义
|
||||
> "Automated tools catch maybe 30% of real bugs." — 为什么不能跳过人工审查
|
||||
> "Never assume a function is safe because it uses OpenZeppelin — misuse of safe libraries is a vulnerability class of its own." — 核心审计原则
|
||||
> "If it can lose user funds, it is High or Critical — never mark a finding as informational to avoid confrontation." — 漏洞评级原则
|
||||
> "Zero Critical or High findings are missed that a subsequent auditor discovers." — 成功指标
|
||||
|
||||
## Key Concepts
|
||||
- [[Reentrancy（重入攻击）]]：外部调用在状态更新前执行，允许攻击者在状态清零前回滚调用链重复提取资金
|
||||
- [[Oracle Manipulation（预言机操纵）]]：通过闪电贷在单笔交易内操纵 AMM 储备或价格预言机，导致清算/借贷套利
|
||||
- [[Flash Loan Attack（闪电贷攻击）]]：在单笔交易内借用大量资金操纵市场状态，无需抵押的信贷攻击
|
||||
- [[Access Control（访问控制）]]：特权函数缺少访问修饰符或被错误配置，可导致权限提升
|
||||
- [[Formal Verification（形式化验证）]]：使用符号执行和不变式验证数学证明协议关键属性的正确性
|
||||
- [[Checks-Effects-Interactions Pattern]]：先检查条件、更新状态，再执行外部调用，防止逻辑漏洞
|
||||
- [[Slither]]：Trail of Bits 开源的 Solidity 静态分析框架，高置信度检测器几乎总是真实漏洞
|
||||
- [[Mythril]]：基于符号执行的安全分析工具，深度扫描但速度较慢
|
||||
- [[Echidna]]：属性化模糊测试工具，通过随机交易验证协议不变式
|
||||
- [[Foundry]] / [[Certora]] / [[Halmos]]：高级形式化验证工具链，用于数学证明合约正确性
|
||||
- [[SWC Registry]]：智能合约弱点分类标准（Smart Contract Weakness Classification）
|
||||
- [[DeFiHackLabs]] / [[rekt.news]]：DeFi 攻击事件数据库，用于模式匹配已知漏洞
|
||||
- [[Reentrancy（重入攻击）]]：外部调用在状态更新前执行，允许攻击者在状态清零前回滚调用链重复提取资金；典型模式：外部 call() 在 balances[msg.sender]=0 之前调用；防御：Checks-Effects-Interactions 模式 + ReentrancyGuard
|
||||
- [[Oracle Manipulation（预言机操纵）]]：通过闪电贷在单笔交易内操纵 AMM 储备或价格预言机，导致清算/借贷套利；Uniswap V2 现货价格可被操纵，V3 TWAP 和 Chainlink 提供更好保障
|
||||
- [[Flash Loan Attack（闪电贷攻击）]]：在单笔交易内借用大量资金操纵市场状态，无需抵押的信贷攻击；是 Oracle Manipulation 和经济博弈攻击的主要载体
|
||||
- [[Access Control（访问控制）]]：特权函数缺少访问修饰符或被错误配置，可导致权限提升；关键检查项：initialize() 一次性调用保护、代理合约 `_disableInitializers()`、多签 vs EOA 风险
|
||||
- [[Formal Verification（形式化验证）]]：使用符号执行和不变式验证数学证明协议关键属性的正确性；Certora/Halmos/KEVM 用于数学证明合约正确性
|
||||
- [[Checks-Effects-Interactions Pattern]]：先检查条件、更新状态，再执行外部调用，防止逻辑漏洞；修复重入的标准模式
|
||||
- [[Slither]]：Trail of Bits 开源的 Solidity 静态分析框架，高置信度检测器几乎总是真实漏洞；关键检测器：reentrancy-eth/arbitrary-send-eth/suicidal/controlled-delegatecall/uninitialized-state
|
||||
- [[Mythril]]：基于符号执行的安全分析工具，深度扫描但速度较慢；适合关键合约的深度分析
|
||||
- [[Echidna]]：属性化模糊测试工具，通过随机交易验证协议不变式；配合 Foundry 进行属性化 fuzz 测试
|
||||
- [[Storage Collision（存储冲突）]]：升级型代理合约中存储槽对齐错误，可被攻击者劫持状态变量
|
||||
- [[Signature Malleability（签名重放攻击）]]：permit 和元交易系统中签名可被修改后重放攻击
|
||||
- [[Cross-Chain Message Replay（跨链消息重放）]]：桥接协议消息跨链验证绕过，同一消息可在多条链上重放
|
||||
- [[SWC Registry]]：智能合约弱点分类标准（Smart Contract Weakness Classification），提供标准化的漏洞编号和描述
|
||||
- [[DeFiHackLabs]] / [[rekt.news]]：DeFi 攻击事件数据库，用于模式匹配已知漏洞；每个新攻击都是未来漏洞的模板
|
||||
|
||||
## Key Entities
|
||||
- [[Trail of Bits]]：安全审计机构，开发 Slither、Solc 等关键安全工具
|
||||
- [[OpenZeppelin]]：智能合约标准库（ReentrancyGuard、AccessControl 等），被广泛依赖
|
||||
- [[Trail of Bits]]：安全审计机构，开发 Slither、Solc 等关键安全工具；审计报告档案是重要参考资源
|
||||
- [[OpenZeppelin]]：智能合约标准库（ReentrancyGuard、AccessControl 等），被广泛依赖；误用是独立漏洞类别
|
||||
- [[Certora]]：形式化验证工具，用于数学证明 Solidity 合约属性
|
||||
- [[Halmos]]：字节码级别的形式化验证工具，基于符号执行
|
||||
- [[The DAO (2016)]]：以太坊首个重大安全事件，重入攻击导致 360 万 ETH 损失，开创了 DeFi 安全研究领域
|
||||
- [[Euler Finance]]：2023 年遭受 donate-to-reserves 操纵攻击，损失 1.97 亿美元，攻击模板被收录
|
||||
- [[Nomad Bridge]]：2022 年因未初始化代理合约漏洞损失 1.9 亿美元
|
||||
@@ -52,8 +62,11 @@ date: 2026-04-20
|
||||
## Connections
|
||||
- [[Agents Orchestrator]] ← defines role scope ← [[Blockchain Security Auditor]]
|
||||
- [[Compliance Auditor]] ← related audit methodology ← [[Blockchain Security Auditor]]
|
||||
- [[Blockchain Security Auditor]] ← uses tools ← [[Slither]] / [[Mythril]] / [[Echidna]]
|
||||
- [[Blockchain Security Auditor]] ← uses tools ← [[Slither]] / [[Mythril]] / [[Echidna]] / [[Certora]] / [[Halmos]]
|
||||
- [[Blockchain Security Auditor]] ← draws patterns from ← [[The DAO (2016)]] / [[Euler Finance]] / [[Nomad Bridge]] / [[Curve Finance]]
|
||||
- [[Blockchain Security Auditor]] ← methodologies ← [[Formal Verification]] / [[Access Control]] / [[Oracle Manipulation]]
|
||||
- [[Blockchain Security Auditor]] ← references ← [[SWC Registry]] / [[DeFiHackLabs]] / [[rekt.news]]
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突 — 该页面为独立角色定义文档，未与其他 Wiki 页面产生直接矛盾）
|
||||
- 与 [[Compliance Auditor]] 的关注点差异：Blockchain Security Auditor 聚焦代码层安全漏洞和资金损失风险，Compliance Auditor 聚焦合规框架（SOC 2/ISO 27001）控制措施，两者方法论互补而非矛盾
|
||||
- 漏洞评级与用户沟通的张力：文档强调"永远不要把能损失资金的漏洞标记为 informational"，但同时要求"为开发者和利益相关者分别写报告"——前者保证安全底线，后者照顾沟通需求，通过分层报告结构解决
|
||||
|
||||
@@ -1,39 +1,39 @@
|
||||
---
|
||||
title: "Claude Code Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/claude-code/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency Agent 资产与 Claude Code 的原生集成方案
|
||||
- 问题域：如何在 Claude Code 会话中激活和使用预设的 Agent 角色
|
||||
- 方法/机制：通过 `install.sh` 脚本或手动复制，将 Agent 定义文件部署到 Claude Code 的 agents 目录，Claude Code 通过名称引用激活 Agent
|
||||
- 结论/价值：The Agency 从一开始就为 Claude Code 构建，无需任何格式转换，Agent 天然使用 `.md` + YAML frontmatter 格式，与 Claude Code 完全兼容
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 为 Claude Code 原生构建，无需格式转换
|
||||
- Agent 以 `.md` + YAML frontmatter 格式存储，与 Claude Code agent 格式完全一致
|
||||
- Agent 按部门（division）组织成目录结构，可选择性安装
|
||||
- 在 Claude Code 会话中通过名称引用即可激活对应 Agent
|
||||
|
||||
## Key Quotes
|
||||
> "The Agency was built for Claude Code. No conversion needed — agents work natively with the existing `.md` + YAML frontmatter format." — 核心设计理念，阐明 The Agency 与 Claude Code 的原生兼容性
|
||||
|
||||
## Key Concepts
|
||||
- [[Agent-Activation-Pattern]]：在 Claude Code 和 Windsurf 中通过名称引用激活预设 Agent 角色的机制
|
||||
|
||||
## Key Entities
|
||||
- [[Claude-Code]]：Anthropic 官方 AI 编程 CLI 工具，本集成的目标平台
|
||||
- [[The-Agency]]：多智能体编码系统，包含各类专业角色 Agent 的资产库
|
||||
|
||||
## Connections
|
||||
- [[integrations-readme]] ← overview ← [[claude-code-integration]]
|
||||
- [[claude-code-integration]] ← extends ← [[The-Agency]]
|
||||
- [[agents-orchestrator]] ← category_parent ← [[claude-code-integration]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突
|
||||
---
|
||||
title: "Claude Code Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/claude-code/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency 项目如何与 Claude Code 集成使用
|
||||
- 问题域：Agent 的安装、激活与管理
|
||||
- 方法/机制：通过 install.sh 脚本或手动复制 md 文件到 `~/.claude/agents/`，在 Claude Code 会话中通过名称引用激活 Agent
|
||||
- 结论/价值：The Agency 无需转换即可原生支持 Claude Code，Agent 使用 `.md` + YAML frontmatter 格式
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 原生支持 Claude Code，无需格式转换
|
||||
- Agent 使用 `.md` + YAML frontmatter 格式即可工作
|
||||
- 支持批量安装和按分类手动安装两种方式
|
||||
- Agent 通过名称引用即可在 Claude Code 会话中激活
|
||||
|
||||
## Key Quotes
|
||||
> "The Agency was built for Claude Code. No conversion needed — agents work natively with the existing `.md` + YAML frontmatter format." — 核心设计理念
|
||||
|
||||
## Key Concepts
|
||||
- [[Claude Code]]：Anthropic 的 CLI 编程代理工具，支持通过名称激活预定义 Agent
|
||||
- [[The Agency]]：一个开源 Agent 集合项目，提供多领域专业 Agent
|
||||
- [[Agent Activation]]：在 Claude Code 会话中通过名称引用激活 Agent 的机制
|
||||
|
||||
## Key Entities
|
||||
- [[Agency Agents]]：The Agency 项目中的具体 Agent 实现，分布在不同 divisions
|
||||
|
||||
## Connections
|
||||
- [[The Agency]] ← provides agents for ← [[Claude Code Integration]]
|
||||
- [[readme]] ← overview of ← [[Claude Code Integration]]
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
|
||||
@@ -2,59 +2,44 @@
|
||||
title: "Compliance Auditor Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/compliance-auditor.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：专业 AI Agent，专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证审计的全流程指导——从准备评估到证据收集直至认证通过。
|
||||
- 问题域：组织如何系统性地通过合规认证，避免"打勾式合规"（checkbox compliance），确保控制措施真正落地而非仅存在于文档中。
|
||||
- 方法/机制：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；强调自动化证据收集、右置控制项设计、以审计员视角反向思考。
|
||||
- 结论/价值：合规项目应与公司规模和实际风险匹配；技术控制优于管理控制；证据必须证明控制在整个审计周期内持续有效，而非仅存在于当下。
|
||||
- 核心主题：AI Agent 角色定义——技术合规审计员，指导组织完成 SOC 2、ISO 27001、HIPAA、PCIDSS 等安全与隐私认证流程
|
||||
- 问题域：安全合规认证准备、差距评估、控制实施、审计执行、持续合规
|
||||
- 方法/机制：通过五步工作流（范围界定→差距评估→修复支持→审计支持→持续合规），结合结构化交付物（差距评估报告、证据收集矩阵、政策模板）
|
||||
- 结论/价值：为组织提供从零到认证的系统化指导，强调实质重于形式、自动化证据收集、按风险适配控制复杂度
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 不被遵守的政策比没有政策更危险——它制造虚假信心，增加审计风险。
|
||||
- 自动化证据收集从第一天就应建立——手动流程无法扩展。
|
||||
- 使用通用控制框架（common control framework）可一个控制集满足多个认证标准。
|
||||
- 技术控制优于管理控制——代码比培训更可靠。
|
||||
- 审计边界（scope）必须清晰定义，明确包含和排除的范围。
|
||||
- 例外情况（exceptions）需要完整文档：谁批准、为什么、有何时效、有何补偿控制。
|
||||
- 没人遵守的政策比没有政策更危险——制造虚假信心，增加审计风险
|
||||
- 自动化证据收集必须从第一天就建立——手动流程无法扩展
|
||||
- 使用通用控制框架（一套控制满足多项认证）可消除重复工作
|
||||
- 异常必须记录在案：谁批准、为什么、何时到期、有什么补偿控制
|
||||
- 控制必须被测试，不能仅存在于文档中
|
||||
- 审计边界必须明确界定——清楚定义审计范围的内含与外延
|
||||
|
||||
## Key Quotes
|
||||
> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk."
|
||||
> — 核心原则：不follow的政策比没政策更危险
|
||||
|
||||
> "Evidence must prove the control operated effectively over the audit period, not just that it exists today."
|
||||
> — 证据的核心要求：证明整个审计周期内持续有效
|
||||
|
||||
> "Think like the auditor: what would you test? what evidence would you request?"
|
||||
> — 审计员心态：反向思考，模拟审计师会问什么
|
||||
> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk." — 实质性合规的核心原则
|
||||
> "Automate evidence collection from day one — it scales, manual processes don't." — 自动化优先原则
|
||||
> "Think like the auditor: what would you test? what evidence would you request?" — 审计师思维
|
||||
> "Technical controls over administrative controls where possible — code is more reliable than training." — 技术控制优于管理控制
|
||||
|
||||
## Key Concepts
|
||||
- [[Checkbox-Compliance]]：仅在文档层面满足合规要求，控制实际未落地或未被测试——文档中的反面案例。
|
||||
- [[Continuous-Compliance]]：持续合规——在两次年度审计之间建立自动化证据收集管道和季度控制测试机制，而非年度突击准备。
|
||||
- [[Common-Control-Framework]]：通用控制框架——设计一组控制项同时满足多个认证标准（如 SOC 2 + ISO 27001），避免重复工作。
|
||||
- [[Technical-Controls-Vs-Administrative-Controls]]：技术控制（如 IAM 策略、代码审计）优于管理控制（如培训、签到表），因为代码比人的行为更可靠。
|
||||
- [[Compensating-Control]]：补偿控制——当某项控制无法直接满足时，用于降低风险的替代措施；需完整记录批准人、原因和有效期。
|
||||
- [[Evidence-Collection-Matrix]]：证据收集矩阵——以控制目标（而非内部团队结构）组织证据的结构化文档，列出控制ID、证据类型、来源、收集方式和频率。
|
||||
- [[SOC2]]：信任服务标准认证，Compliance Auditor 重点覆盖的安全与隐私框架之一
|
||||
- [[GapAssessment]]：差距评估——对照目标框架要求评估当前安全态势，输出带优先级修复计划
|
||||
- [[EvidenceCollection]]：证据收集——自动化优先，手动证据脆弱；按控制目标组织，而非按内部团队结构
|
||||
|
||||
## Key Entities
|
||||
- [[SOC-2]]：安全、可用性、处理完整性、机密性、隐私五大信任服务标准（Trust Service Criteria），最常见的云服务安全认证。
|
||||
- [[ISO-27001]]：国际信息安全管理标准，提供系统化的风险管理方法。
|
||||
- [[HIPAA]]：美国医疗信息隐私法规，涵盖 PHI（受保护健康信息）的保护要求。
|
||||
- [[PCI-DSS]]：支付卡行业数据安全标准，适用于处理信用卡信息的组织。
|
||||
- ComplianceAuditor：AI Agent 身份，技术合规审计员，个性严谨、系统、务实，对风险过敏，对"打勾式合规"过敏
|
||||
|
||||
## Connections
|
||||
- [[specialized-model-qa]] ← extends ← [[compliance-auditor]]：Model QA 关注 ML 模型质量，Compliance Auditor 关注整体安全控制——两者在模型部署合规证据收集上存在交叉。
|
||||
- [[automation-governance-architect]] ← depends_on ← [[compliance-auditor]]：合规审计所需的自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。
|
||||
- [[CTP-Topic-52-3-Lines-of-Defence]] ← extends ← [[compliance-auditor]]：三道防线模型（业务管理 / 风险职能 / 内部审计）与合规审计的职责划分高度对应。
|
||||
- [[DevSecOps]] ← extends ← [[compliance-auditor]]：DevSecOps 将安全控制集成到 CI/CD 流水线中，是合规 Auditor 推荐的技术控制实现方式。
|
||||
- [[SOC2]] ← 应用框架 ← [[ComplianceAuditor]]
|
||||
- [[GapAssessment]] ← 核心交付物 ← [[ComplianceAuditor]]
|
||||
- [[EvidenceCollection]] ← 核心交付物 ← [[ComplianceAuditor]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[specialized-model-qa]] 的侧重点差异：
|
||||
- 冲突点：Compliance Auditor 关注组织级控制（access control, incident response），Model QA 关注模型本身的质量与统计特性，两者对"证据"的定义不同。
|
||||
- 当前观点：合规证据以控制操作日志、策略文档、访问审查记录为主。
|
||||
- 对方观点：模型证据以 PSI、校准曲线、SHAP 值等统计指标为主。
|
||||
- 协调建议：两者可互补——Compliance Auditor 负责整体安全框架，Model QA 负责嵌入其中的 AI/ML 模型专项审计。
|
||||
- 无已知冲突页面
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "Contributing to The Agency"
|
||||
type: source
|
||||
tags: [multi-agent, openclaw, contribution, the-agency]
|
||||
date: 2026-04-21
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/CONTRIBUTING.md]]
|
||||
- [[Agent/agency-agents/CONTRIBUTING.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency（agency-agents）多智能体框架的贡献者指南英文原版
|
||||
- 问题域：如何规范地向 The Agency 项目贡献高质量 AI 智能体，以及社区协作标准
|
||||
- 方法/机制：通过智能体设计模板、五大设计原则、PR 流程规范和代码风格指南确保贡献质量
|
||||
- 结论/价值：为 OpenClaw 多智能体生态提供标准化的智能体创建框架和质量门槛
|
||||
- 核心主题：The Agency 开源 AI Agent 项目的贡献指南，定义如何创建、改进和提交新的 Agent
|
||||
- 问题域：开源社区协作、AI Agent 开发规范、贡献流程标准化
|
||||
- 方法/机制：通过结构化的 Agent 文件模板、设计原则、PR 流程和样式指南来规范贡献行为
|
||||
- 结论/价值：降低了贡献门槛，明确了"好 Agent"的标准，使社区能够持续产出高质量的 AI Agent
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 通过**五大设计原则**确保智能体质量：鲜明性格、明确交付物、可量化指标、经过验证的工作流、学习记忆
|
||||
- PR 最佳实践：**单文件优先**（一个 `.md` 就是一个 PR），复杂变更（工具链/架构）需先开 Discussion 对齐
|
||||
- 外部服务依赖须在 frontmatter 的 `services` 字段声明，且智能体应**脱离 API 后仍有独立价值**
|
||||
- 提交前必须完成：真实场景测试、遵循模板、至少 2-3 个代码/模板示例、可量化成功指标
|
||||
- 贡献一个 Agent 的最简路径是一个 Markdown 文件（新 Agent 或改进现有 Agent）
|
||||
- 优秀的 Agent 必须具备：窄而深的专长、鲜明的个性声音、具体的代码/模板示例、可量化的成功指标、逐步验证的工作流
|
||||
- Agent 文件采用双语义分组（Persona + Operations），以支持 OpenClaw 格式自动转换
|
||||
- 外部服务依赖应在 frontmatter 中声明，但 Agent 本身必须独立成立
|
||||
- 批量修改现有 Agent 必须先开 Discussion 讨论
|
||||
|
||||
## Key Quotes
|
||||
> "The fastest path to a merged PR is **one markdown file** — a new or improved agent. That's the sweet spot." — PR 流程说明
|
||||
> "An agent that solves the user's problem using a service belongs here. A service's quickstart guide wearing an agent costume does not." — 外部服务评判标准
|
||||
> "The fastest path to a merged PR is **one markdown file** — a new or improved agent." — 强调最小化 PR 的核心理念
|
||||
> "Great agents have: ✅ Narrow, deep specialization / ✅ Distinct personality and voice / ✅ Concrete code/template examples / ✅ Measurable success metrics / ✅ Step-by-step workflows / ✅ Real-world testing and iteration" — 好 Agent 的六项标准
|
||||
|
||||
## Key Concepts
|
||||
- [[Agent-Design-Principles]]：五大设计原则——鲜明性格/明确交付物/可量化指标/验证工作流/学习记忆
|
||||
- [[Agent-Template]]：YAML frontmatter + 结构化文档模板规范
|
||||
- [[Multi-Agent-Team]]：The Agency 框架下多智能体协作模式
|
||||
- [[Multi-Agent-System-Reliability]]：多智能体系统可靠性架构模式
|
||||
- [[AgentDesignPrinciples]]：Agent 设计五原则——强个性、清晰交付物、成功指标、经过验证的工作流、学习与记忆
|
||||
- [[PersonaVsOperations]]：Agent 文件的 Persona（身份/沟通/规则）与 Operations（使命/交付物/流程/指标）双分组结构
|
||||
- [[ExternalServicesDeclaration]]：Agent 可声明外部服务依赖，但必须独立于服务存在，测试标准是"去掉 API 调用后 Agent 仍有价值"
|
||||
- [[OpenClawFormat]]：OpenClaw 工作区格式，支持通过 convert.sh 自动将 Agent 文件转换为工具特定格式
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：msitarzewski 主导的多智能体开源项目（147 个专业化智能体，覆盖 12 个业务领域）
|
||||
- [[OpenClaw]]：The Agency 智能体运行的基础平台
|
||||
- [[msitarzewski]]（mar.mod）：The Agency 项目维护者
|
||||
- [[TheAgency]]：The Agency 是一个开源 AI Agent 集合项目，托管于 GitHub (msitarzewski/agency-agents)
|
||||
- [[MarekSitarzewski]]：The Agency 项目作者（GitHub: msitarzewski）
|
||||
- [[OpenClaw]]：Agent 工作区格式规范，定义了 Agent 文件的结构和 convert.sh 转换脚本
|
||||
|
||||
## Connections
|
||||
- [[contributing_zh-cn]] ← 同一文档的中文翻译版本，包含中文社区协作规范
|
||||
- [[Agent-Design-Principles]] ← 来源一致，均引用本文档定义五大设计原则
|
||||
- [[Agent-Template]] ← 来源一致，均引用本文档定义智能体文件结构
|
||||
- [[multi-agent-system-reliability]] ← 智能体设计规范层补充运行时可靠性模式
|
||||
- [[multi-agent-team]] ← The Agency 框架的多智能体协作模式
|
||||
- [[TheAgency]] ← authored_by ← [[MarekSitarzewski]]
|
||||
- [[AgentDesignPrinciples]] ← implements ← [[PersonaVsOperations]]
|
||||
- [[ExternalServicesDeclaration]] ← part_of ← [[AgentDesignPrinciples]]
|
||||
- [[OpenClaw]] ← converts ← [[AgentDesignPrinciples]]
|
||||
|
||||
## Contradictions
|
||||
- 无与其他 Wiki 页面的实质性内容冲突
|
||||
- 与 [[contributing_zh-cn]] 的差异：英文原版包含 Code of Conduct（行为准则）和 Recognition（贡献者认可机制）章节，中文翻译版侧重核心贡献流程和设计规范
|
||||
- 与 [[contributing_zh-cn]] 无冲突（中文版为本文档的翻译）
|
||||
|
||||
@@ -2,43 +2,45 @@
|
||||
title: "为 The Agency 贡献代码"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-24
|
||||
date: 2026-04-27
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/CONTRIBUTING_zh-CN.md]]
|
||||
- [[Agent/agency-agents/CONTRIBUTING_zh-CN.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：**The Agency**（agency-agents）项目的贡献者指南，定义智能体（Agent）设计规范、贡献流程和社区标准
|
||||
- 问题域：AI 智能体系统的标准化设计、社区协作与质量保障
|
||||
- 方法/机制：YAML frontmatter 元数据 + 分层结构化文档模板；通过 Pull Request 流程和 PR 模板实现质量把控；通过智能体设计原则（性格塑造、交付物定义、指标量化）确保智能体质量
|
||||
- 结论/价值：提供可操作的智能体设计框架，降低社区贡献门槛，同时通过规范保证生态一致性
|
||||
- 核心主题：The Agency 智能体（Agent）项目的开源贡献指南——涵盖行为准则、贡献方式、智能体设计规范、PR 提交流程和风格指南
|
||||
- 问题域：如何为 AI 智能体集合项目贡献新的或改进的专家智能体，包括设计原则、结构模板、质量标准
|
||||
- 方法/机制：通过 YAML frontmatter 定义智能体元数据，通过分章节结构（身份/使命/规则/交付物/工作流/学习/指标）规范智能体设计，通过 PR 模板确保贡献质量
|
||||
- 结论/价值：提供了一套完整的智能体贡献生态——从创意生成到真实场景测试再到社区评审，标准化了 AI 专家智能体的创建流程
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 优秀智能体必须具备鲜明性格，拒绝"通用型有用助手"人设
|
||||
- 智能体应提供可量化的成功指标，而非模糊描述
|
||||
- 每个智能体必须经过真实场景测试和迭代优化
|
||||
- 贡献者通过 PR 流程和社区评审确保智能体质量
|
||||
- 贡献智能体需满足：鲜明性格 + 明确交付物 + 可量化成功指标 + 分步工作流 + 真实场景测试
|
||||
- 避免通用型"有用助手"人设，智能体应专精、独特、可落地
|
||||
- PR 提交前必须在真实场景中测试，并包含 2-3 个代码/模板示例
|
||||
- 智能体需定义具体、可量化的成功指标，而非模糊描述
|
||||
|
||||
## Key Quotes
|
||||
> "赋予智能体独特语气与人设，避免'我是一个有用的助手'，要具体、让人印象深刻" — 智能体性格设计原则
|
||||
> "赋予智能体独特语气与人设，避免'我是一个有用的助手'，要具体、让人印象深刻" — 智能体性格塑造原则
|
||||
> "提供可落地的代码示例，包含模板与框架，展示真实输出，而非模糊描述" — 交付物标准
|
||||
> "包含具体、可量化的指标" — 成功指标要求
|
||||
> "包含具体、可量化的指标，例如'3G 网络下页面加载时间低于 3 秒'" — 成功指标定义
|
||||
> "分步流程清晰，经过真实场景验证，拒绝纯理论、纸上谈兵" — 工作流要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Agent-Design-Principles]]：The Agency 智能体设计五原则（鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆）
|
||||
- [[Agent-Template]]：YAML frontmatter + 分层结构（身份/使命/规则/交付物/工作流/沟通/学习/指标）
|
||||
- [[Pull-Request-Template]]：标准化 PR 提交模板，包含智能体信息、创作动机、测试情况、检查清单
|
||||
- [[Agent-Design-Patterns]]：智能体设计应遵循的五大原则——鲜明性格、明确交付物、成功指标、经过验证的工作流、学习记忆机制
|
||||
- [[YAML-Configuration]]：每个智能体文件以 YAML frontmatter 定义 name/description/color 元数据
|
||||
- [[Pull-Request-Workflow]]：Fork → 分支 → 开发 → 测试 → PR → 社区评审 → 合并的完整贡献流程
|
||||
- [[Markdown-Documentation]]：使用 Markdown 统一格式，表情符号导航，代码块语法高亮，表格对比选项
|
||||
- [[Multi-Agent-System]]：The Agency 智能体集合涵盖 engineering/design/marketing/product 等多领域专业分工
|
||||
|
||||
## Key Entities
|
||||
- [[The-Agency]]（agency-agents 项目）：包含 147 个专业智能体，覆盖 12 个业务领域
|
||||
- [[Agency-Engineering-Agent]]：前端开发者智能体示例，结构规范参考
|
||||
- [[Agency-Marketing-reddit-Community-Builder]]：Reddit 社区运营者示例，性格塑造优秀参考
|
||||
- [[The-Agency]]：AI 智能体开源项目，汇集多领域专家智能体，支持 9 大分类贡献
|
||||
- [[SRE]]：Site Reliability Engineering，贡献分类之一，对应 testing/ 分类专家
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent-System-Reliability]] ← extends ← [[Agent-Design-Principles]]
|
||||
- [[OpenClaw]] ← related_to ← [[The-Agency]]
|
||||
- [[Multi-Agent-Team]] ← related_to ← [[Agent-Orchestration]]
|
||||
- [[Agentic-Identity-And-Trust]] ← extends ← [[The-Agency]]（The Agency 提供智能体贡献框架，Agentic Identity & Trust 定义身份与信任机制）
|
||||
- [[Agents-Orchestrator]] ← depends_on ← [[Multi-Agent-System]]（编排依赖多智能体系统的存在）
|
||||
- [[Multi-Agent-System-Reliability]] ← extends ← [[Multi-Agent-System]]（可靠性研究扩展多智能体系统）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
- 无冲突：本指南为贡献流程文档，不与其他来源产生直接矛盾
|
||||
|
||||
@@ -2,48 +2,59 @@
|
||||
title: "Corporate Training Designer"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
date: 2026-05-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/corporate-training-designer.md]]
|
||||
- [[Agent/agency-agents/specialized/corporate-training-designer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：企业培训体系架构师与课程开发专家（Corporate Training Designer）—— 专注企业级培训需求分析、ADDIE/SAM 教学设计模型、混合学习项目设计、内训师培养、领导力发展项目，以及 Kirkpatrick 四级培训效果评估体系。
|
||||
- 问题域：企业培训中"为培训而培训"的现象普遍存在——培训目标不可衡量、课程内容脱离业务场景、学习效果无法落地到行为改变。
|
||||
- 方法/机制：从业务问题出发，以能力差距分析为基础，采用 ADDIE/SAM 模型设计课程体系，通过 OMO 混合学习、Kolb 体验式学习、翻转课堂等方法交付，并通过 Kirkpatrick 四级评估验证业务价值。
|
||||
- 结论/价值：优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"——数据驱动的培训体系能真正提升员工能力与组织绩效。
|
||||
- 核心主题：企业培训系统架构师与课程开发专家，专注于从需求诊断到 Kirkpatrick Level 4 效果评估的全链路培训设计
|
||||
- 问题域：企业如何设计真正驱动业务结果的培训项目，而非"为培训而培训"；培训需求如何与业务指标挂钩；如何将专家隐性经验萃取为可传授的显性知识
|
||||
- 方法/机制：ADDIE 模型（分析→设计→开发→实施→评估）、SAM 迭代设计、Bloom 认知分类、柯尔布体验学习圈、Kirkpatrick 四级评估模型、ADDIE + SAM 混合、翻转课堂、OMO 混合学习、游戏化机制
|
||||
- 结论/价值：好的培训测量的是"学员回去做了什么"，而非"讲师讲了什么"；培训目标必须可量化；高投资培训项目必须追踪到 Kirkpatrick Level 3（行为改变）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 培训设计必须从业务问题出发，而非从"我们有什么课"出发；培训目标必须可衡量，而非"提高沟通能力"这类模糊表述。
|
||||
- 所有案例必须改编自真实业务场景，拒绝脱离实际的"教材式案例"；课程内容须每年至少更新一次。
|
||||
- 每项培训项目必须有评估计划——高投资（领导力、关键岗位）必须追踪到 Kirkpatrick Level 3（行为改变）。
|
||||
- 合规培训须覆盖全体员工，记录完整，360 度反馈结果仅限本人及直属上级知晓。
|
||||
- 培训设计必须从业务问题出发，而非从"我们有什么课"出发；如果根因不是能力差距（而是流程、政策或激励问题），应直接指出而非强行培训
|
||||
- 成人学习必须有即时实用价值，每个学习活动必须回答"我现在能用在哪里"；控制单次认知负荷（线下培训每90分钟安排互动或休息，线上微课控制在15分钟以内）
|
||||
- 培训目标必须可量化：不是"提高沟通技能"，而是"3个月内将新员工独立完成客户提案的比例从40%提升至70%"
|
||||
- 每次培训都必须有评估计划，至少达到 Kirkpatrick Level 2（学习），高投资培训（领导力、关键岗位）必须追踪到 Level 3（行为改变）
|
||||
|
||||
## Key Quotes
|
||||
> "Good training isn't about 'what was taught' — it's about 'what learners do differently when they go back to work.'" — 培训设计的核心价值观
|
||||
> "Training objectives must be measurable — not 'improve communication skills,' but 'increase the percentage of new hires independently completing client proposals within 3 months from 40% to 70%.'" — 培训目标的 SMART 原则
|
||||
> "For this leadership program, I recommend replacing pure classroom lectures with 'business challenge projects.' Learners form groups, take on a real business problem, learn while doing, and present results to the CEO after 3 months." — 成人学习理论的应用
|
||||
> "Data from the last sales new hire boot camp: trainees had a 23% higher first-month deal close rate than non-trainees, with an average of 18,000 yuan more in per-capita output." — 培训 ROI 的量化证明
|
||||
> "Good training isn't about 'what was taught' — it's about 'what learners do differently when they go back to work'" — 核心价值观
|
||||
> "For this leadership program, I recommend replacing pure classroom lectures with 'business challenge projects.' Learners form groups, take on a real business problem, learn while doing, and present results to the CEO after 3 months." — 翻转课堂的实践示例
|
||||
> "Data from the last sales new hire boot camp: trainees had a 23% higher first-month deal close rate than non-trainees, with an average of 18,000 yuan more in per-capita output." — 培训 ROI 数据说话
|
||||
|
||||
## Key Concepts
|
||||
- [[ADDIE 模型]]：Analysis（分析）→ Design（设计）→ Development（开发）→ Implementation（实施）→ Evaluation（评估），每个阶段有明确交付物，是教学设计的基础框架。
|
||||
- [[SAM 模型]]（Successive Approximation Model）：适合快速迭代场景，通过"原型 → 评审 → 修订"循环缩短上线时间。
|
||||
- [[Kirkpatrick 四级评估]]：Level 1 反应（满意度）、Level 2 学习（知识技能掌握）、Level 3 行为（行为改变）、Level 4 结果（业务指标变化）。
|
||||
- [[Bloom 认知分类]]：从记忆→理解→应用→分析→评价→创造，逐级提升学习目标设计深度。
|
||||
- [[Kolb 体验式学习圈]]：具体经验 → 反思观察 → 抽象概念化 → 主动实验，闭环驱动学习转化。
|
||||
- [[OMO 混合学习]]（Online-Merge-Offline）：线上解决"认知"、线下解决"实践"、学习社群解决"持续"。
|
||||
- [[TTT]]（Train the Trainer）：内训师培养体系——成人学习原则、课程开发技巧、表达与呈现技能、课堂管理与互动技巧、课件设计标准。
|
||||
- [[HIPO]]（High-Potential Talent Program）：高潜人才培养项目，通过 IDP（个人发展计划）、轮岗、导师辅导、挑战性任务加速人才成长。
|
||||
- [[ADDIE 模型]]：微课（5-15 分钟）、案例教学、沙盘模拟、剧本杀式沉浸体验培训等多元内容形式。
|
||||
- [[ADDIE-Model]]：分析（Analysis）→设计（Design）→开发（Development）→实施（Implementation）→评估（Evaluation），每阶段有明确交付物
|
||||
- [[SAM-Model]]（Successive Approximation Model）：适合快速迭代场景，通过"原型→评审→修订"循环缩短上线时间
|
||||
- [[Bloom-Taxonomy]]：认知六级分类（记忆→理解→应用→分析→评价→创造），用于设计学习目标和评估标准
|
||||
- [[Kolbs-Learning-Cycle]]：柯尔布体验学习圈（具体经验→反思观察→抽象概念化→主动实验）
|
||||
- [[Kirkpatrick-Model]]：四级培训评估模型（反应层→学习层→行为层→结果层）
|
||||
- [[Blended-Learning]]（OMO）：线上用于"知道"，线下用于"做到"，学习社区用于"持续"
|
||||
- [[Flipped-Classroom]]：课前线上预习知识点，课中讨论和动手练习，课后行为迁移
|
||||
- [[HIPO-Program]]（High-Potential Talent Development）：高潜力人才培养（绩效×潜力矩阵识别、IDP个人发展计划、轮岗、导师制、挑战性项目任务）
|
||||
- [[TTT-Train-the-Trainer]]：内部讲师培养体系（成人学习原理、课程开发技巧、授课演示技能、认证制度、社区运营）
|
||||
- [[Competency-Gap-Analysis]]：能力差距分析，通过360度评估、绩效数据、主管访谈建立岗位胜任力模型
|
||||
- [[Blended-Learning-Platform]]：中国企业学习平台（钉钉学习/企业微信学习/飞书知识库/UMU互动学习/云学堂/酷学院）
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]：该 Agent 所属的 Agent 系统生态。
|
||||
- [[Bloom]]（Benjamin Bloom）：Bloom 认知分类法创始人，为学习目标层级设计提供理论依据
|
||||
- [[Kolb]]（David Kolb）：柯尔布体验学习圈创始人
|
||||
- [[Kirkpatrick]]（Donald Kirkpatrick）：Kirkpatrick 四级培训评估模型创始人
|
||||
- [[DingTalk-Learning]]：钉钉学习，阿里巴巴生态企业首选学习平台
|
||||
- [[WeCom-Learning]]：企业微信学习，微信生态企业首选
|
||||
- [[Feishu-Knowledge-Base]]：飞书知识库，字节跳动生态和知识管理导向组织首选
|
||||
- [[UMU]]：UMU 互动学习平台，混合学习领域领先者，支持 AI 练习搭档、视频作业、丰富互动功能
|
||||
- [[Yunxuetang]]（Cloud Academy）：云学堂，大中型企业一站式学习平台
|
||||
|
||||
## Connections
|
||||
- [[Specialized Workflow Architect]] ← related_to ← [[Corporate Training Designer]]：两者均涉及工作流程设计，但前者专注软件工程流程，后者专注组织学习流程。
|
||||
- [[Specialized Cultural Intelligence Strategist]] ← related_to ← [[Corporate Training Designer]]：两者均涉及跨文化能力建设，但前者专注产品文化包容，后者专注培训内容的文化适配。
|
||||
- [[Specialized HR Onboarding]] ← extends ← [[Corporate Training Designer]]：新员工培训是 Corporate Training Designer 的重要子领域。
|
||||
- [[ADDIE-Model]] ← foundational_model ← [[SAM-Model]]（SAM 是 ADDIE 的快速迭代变体）
|
||||
- [[Bloom-Taxonomy]] ← learning_objective_framework ← [[Kirkpatrick-Model]]（前者定义学什么，后者定义学到什么程度）
|
||||
- [[Kolbs-Learning-Cycle]] ← theoretical_basis ← [[Flipped-Classroom]]（翻转课堂是体验学习的实践应用）
|
||||
- [[Corporate-Training-Designer]] ← professional_domain ← [[HIPO-Program]]（高潜力人才培养是培训设计的重要子领域）
|
||||
- [[TTT-Train-the-Trainer]] ← enables ← [[Corporate-Training-Designer]]（内部讲师是培训落地的关键交付者）
|
||||
- [[Blended-Learning-Platform]] ← technology_infrastructure ← [[Corporate-Training-Designer]]（学习平台是培训交付的技术支撑）
|
||||
|
||||
## Contradictions
|
||||
- （暂无已知冲突。该 Agent 专注于企业内部培训体系，与其他 Agent 在应用场景上有明显差异。）
|
||||
- 无已知跨页面内容冲突。本页面为 Agent 个性定义文档，无其他 Wiki 页面涉及相同企业培训设计专家角色。
|
||||
|
||||
@@ -7,53 +7,55 @@ tags:
|
||||
- SES
|
||||
- Email
|
||||
- CTP
|
||||
- Cloud-Email
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module.md]]
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务，以替代传统的本地 SMTP 网关。
|
||||
- 问题域：随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，网络安全部门要求统一使用云端邮件发送方案。
|
||||
- 方法/机制：在应用 VPC 中配置 VPC 终端节点以实现私有连接；通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager；Terraform 模块自动化 SMTP 终端节点配置、DKIM 验证和 DNS 记录创建；支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API。
|
||||
- 结论/价值：SES 是唯一获网络安全部门批准的云端邮件发送方案；Terraform 模块化封装降低了集成复杂度；需注意两个手动步骤（申请脱离 Sandbox Mode 和手动更新 DNS TXT 记录）。
|
||||
- 核心主题：AWS SES SMTP Terraform 模块的架构设计与部署实践
|
||||
- 问题域：Micro Focus 云转型过程中，如何将传统本地 SMTP 网关替换为云端 SES 服务，同时保持现有应用的零改造接入
|
||||
- 方法/机制：团队开发专用 SES Terraform 模块，封装 SMTP 终端节点配置；通过 VPC 终端节点确保网络安全；IAM 用户凭证经转换后用作 SMTP 认证；凭证安全存储于 AWS Secrets Manager；自动化 DKIM 验证和 Infoblox DNS 记录创建
|
||||
- 结论/价值：该模块使现有应用通过标准 SMTP 协议无缝接入 SES，无需重构代码，是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 在应用 VPC 中配置 VPC 终端节点，使应用可在不访问公网的情况下通过私有节点与 SES SMTP 服务通信。
|
||||
- IAM 用户的 Access Key 和 Secret Key 被转换后作为 SMTP 认证的用户名和密码，相关凭证安全存储于 AWS Secrets Manager。
|
||||
- Terraform 模块自动化完成 DKIM 验证和 Infoblox DNS 管理系统中域名所有权记录的创建。
|
||||
- 手动更新 DNS TXT 记录以验证域名所有权仍是必需步骤，因 Terraform 难以处理多个 AWS 账号共享同一域名时对同一 TXT 记录值的追加操作。
|
||||
- 脱离 SES Sandbox Mode（向 AWS 提交工单申请生产访问权限）是启用完整邮件发送能力的必要前提。
|
||||
- SES 是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案，替代了原有的本地 SMTP 网关。
|
||||
- Micro Focus 网络安全部门仅批准 AWS SES 作为云端邮件发送方案，替代传统本地 SMTP 网关（如 `smtbmicrofocus.com`）
|
||||
- SES Terraform 模块封装 SMTP 终端节点配置，使现有应用通过标准 SMTP 协议集成，无需重构代码以适配 SES API
|
||||
- VPC 终端节点是应用安全访问 SES SMTP 服务的必要条件，由 VPC Wrapper 模块预先配置
|
||||
- IAM 用户凭证（Access Key / Secret Key）经转换后作为 SMTP 认证的用户名和密码，存储于 AWS Secrets Manager
|
||||
- Terraform 无法处理多 AWS 账号共享同一域名时对同一 DNS TXT 记录值的追加操作，必须手动更新
|
||||
- 脱离 SES Sandbox Mode（提升发送限额、允许向外部地址发信）是上线前的必要手动步骤
|
||||
|
||||
## Key Quotes
|
||||
> "随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是目前网络安全部门唯一批准的云端邮件发送方案。" — Christian Deckelmann
|
||||
|
||||
> "SES Terraform 模块封装了 SMTP 终端节点的配置，方便现有应用程序通过标准的 SMTP 协议进行集成，而无需重构代码以适配 SES API。" — Filos Christolakis
|
||||
> "随着业务向云端迁移，使用本地 SMTP 网关已不再高效，SES 是目前网络安全部门唯一批准的云端邮件发送方案。" — Christian Deckelmann
|
||||
> "我们开发的 SES Terraform 模块封装了 SMTP 终端节点的配置，方便现有应用程序通过标准的 SMTP 协议进行集成，而无需重构代码以适配 SES API。" — Filos Christolakis
|
||||
|
||||
## Key Concepts
|
||||
- [[VPC-Endpoint]]：AWS 提供的私有连接服务，允许在 VPC 内部通过私有 IP 地址安全访问 AWS 服务，无需经过公网。
|
||||
- [[DKIM-Email-Authentication]]：DomainKeys Identified Mail 的缩写，一种电子邮件验证标准，通过在邮件头部添加数字签名来防止欺诈和确保邮件完整性。
|
||||
- [[Secrets-Manager]]：AWS 提供的凭证管理服务，用于安全地存储和检索 SES SMTP 的认证信息。
|
||||
- [[SES-Sandbox-Mode]]：AWS SES 的默认限制状态，仅允许向已验证的地址发送少量邮件，需提交工单申请生产访问权限以提升发送限额。
|
||||
- [[AWS SES]]：AWS Simple Email Service，基于云的邮件发送服务，支持 API 和 SMTP 接口
|
||||
- [[SMTP Endpoint]]：SES 提供的区域性邮件传输协议终端节点
|
||||
- [[Sandbox Mode]]：SES 默认限制状态，仅允许向验证过的地址发送少量邮件
|
||||
- [[DKIM]]：DomainKeys Identified Mail，电子邮件验证标准，通过数字签名防止欺诈
|
||||
- [[VPC Endpoint]]：私有节点，使应用在不访问公网的情况下与 SES SMTP 服务通信
|
||||
- [[IAM User SMTP Auth]]：将 IAM 用户 Access Key/Secret Key 转换为 SMTP 用户名/密码的认证方式
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon Web Services，云服务提供商，SES（Simple Email Service）所属平台。
|
||||
- [[Christian-Deckelmann]]：演讲者之一，分享 Micro Focus 在云转型中采用 SES SMTP 服务的背景与动机。
|
||||
- [[Filos-Christolakis]]：演讲者之一，详细讲解 SES Terraform 模块的技术实现方案。
|
||||
- [[Infoblox]]：公司内部使用的 DNS 管理系统，用于存放和管理验证域名所有权所需的 DNS 记录。
|
||||
- [[VPC-Wrapper-Module]]：SES Terraform 模块所依赖的前置 VPC 配置模块，负责预先配置 SMTP VPC 终端节点。
|
||||
- [[Christian Deckelmann]]：Micro Focus 云转型负责人，主讲人之一
|
||||
- [[Filos Christolakis]]：SES Terraform 模块开发者，主讲人之一
|
||||
- [[VPC Wrapper Module]]：预先配置 SMTP VPC 终端节点的 Terraform 模块，本模块依赖于此
|
||||
- [[Infoblox]]：公司内部 DNS 管理系统，用于管理 DNS 记录
|
||||
- [[AWS Secrets Manager]]：AWS 凭证管理服务，用于安全存储 SES SMTP 认证信息
|
||||
|
||||
## Connections
|
||||
- [[VPC-Wrapper-Module]] ← depends_on ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]
|
||||
- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] ← extends ← [[AWS]]
|
||||
- [[Terraform-And-Terragrunt-Best-Practices]] ← related_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（Terragrunt Pre-hook/Post-hook 用于处理手动 DNS 验证步骤）
|
||||
- [[ctp-topic-36-sendgrid-as-an-email-service]] ← alternative_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（SendGrid 被选定为新 Landing Zone 标准，SES 用于现有应用迁移）
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] ← depends_on ← [[VPC Wrapper Module Session]]
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] ← part_of ← [[Landing Zone Architecture Overview]]
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] ← uses ← [[AWS Secrets Manager]]
|
||||
- [[CTP Topic 12 Using SES SMTP service terraform module]] ← uses ← [[Terragrunt]]
|
||||
- [[AWS Secrets Manager]] ← extends ← [[CTP Topic 62 AWS Secrets Manager]]
|
||||
- [[Landing Zone Architecture Overview]] ← extends ← [[CTP Topic 1 Gruntwork Landing Zone Architecture]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异：
|
||||
- 冲突点：两门课程分别介绍了不同的云邮件服务方案——SendGrid 被选定为标准云端邮件服务，而 SES 则专注于服务现有应用通过 SMTP 协议迁移上云。
|
||||
- 当前观点：SES 通过 Terraform 模块封装现有应用 SMTP 接入路径，实现平滑迁移，无需修改应用代码。
|
||||
- 对方观点：SendGrid 作为新标准云邮件服务，提供更高上限（每封 1,000 收件人 vs SES 每封 50 收件人）、更简单的 API 集成和全球中继节点。
|
||||
- 与 [[CTP Topic 36 SendGrid as an Email Service]] 的对比：
|
||||
- 冲突点：两种云端邮件发送方案的适用场景和技术选型
|
||||
- 当前观点：SES 是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案，强调与现有应用的零改造集成
|
||||
- 对方观点：SendGrid 提供了更完整的邮件管理平台功能（如收件人验证、分析报表），适合不同业务场景
|
||||
|
||||
51
wiki/sources/customer-service.md
Normal file
51
wiki/sources/customer-service.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Customer Service Agent"
|
||||
type: source
|
||||
tags: [customer-service, agent, support, retention, escalation]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/customer-service.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通用行业客户服务 Agent 的角色定义与全流程操作规范——面向零售/SaaS/酒店/金融/电信/医疗行政/物流等多行业的全能客服专家，强调同理心优先、承诺必达、主动升级
|
||||
- 问题域：客户咨询/投诉/账户管理/订单处理/取消挽留/升级转接的全场景覆盖
|
||||
- 方法/机制：五步工作流（Greet & Assess → Understand → Resolve or Route → Confirm & Close → Document），配合十大关键规则（Empathy First、No Blame、Own the Problem、Proactive Escalation 等）
|
||||
- 结论/价值：为跨行业客服场景提供标准化、可量化的 Agent 行为规范，涵盖 6 大行业、5 大渠道、10 项可追踪 KPI
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 客户服务的本质是哲学而非部门——每一个联系进来的客户都值得感到被重视、被理解
|
||||
- 在任何政策或流程之前，必须先承认客户感受，否则无法建立信任
|
||||
- 永远不要在没有提供替代方案的情况下说"那不可能"——总有你能做的事
|
||||
- 永远不要把愤怒的客户置于等待状态而不征询同意——必须给予等待时间估计并提供回调选项
|
||||
- 在客户沮丧爆发之前主动升级——识别早期信号并框架化地提供升级选项
|
||||
- 绝不做出无法兑现的承诺——失信比原始问题更快地摧毁信任
|
||||
- 每个取消请求都必须经过真诚的挽留尝试——永远不要立即处理取消
|
||||
- 每次互动都必须记录——完整记录以便下一位代理或专员有充分上下文
|
||||
|
||||
## Key Quotes
|
||||
> "Customer service isn't a department — it's a philosophy. Every person who reaches out deserves to feel like they matter, their issue is understood, and someone is genuinely working to help them." — 核心服务哲学
|
||||
> "Every customer interaction is a chance to turn a problem into loyalty — handle it with care, speed, and a human touch." — 互动即忠诚转化机会
|
||||
|
||||
## Key Concepts
|
||||
- [[EmpathyFirst]]：同理心优先——在任何政策、流程、解决方案之前必须先承认客户的感受
|
||||
- [[ComplaintResponseProtocol]]：投诉响应协议（ACK/VIND/ACT 五步：Acknowledge → Validate → Clarify → Act → Commit）——绝不跳过承认步骤
|
||||
- [[RetentionProtocol]]：挽留协议——绝不立即处理取消请求，必须先了解原因并提供替代方案
|
||||
- [[EscalationProtocol]]：升级协议——立即/紧急/标准三级触发条件，Always Warm Transfer
|
||||
- [[ActiveListening]]：主动倾听——在回应之前完整反射客户所述内容
|
||||
|
||||
## Key Entities
|
||||
- [[HealthcareCustomerService]]：医疗客户服务 Agent — 与通用客服 Agent 共享投诉处理框架和升级协议，但医疗场景要求 HIPAA 强制身份验证
|
||||
|
||||
## Connections
|
||||
- [[HealthcareCustomerService]] ← analogous_to ← [[CustomerService]]（两者共享投诉处理框架和升级协议，医疗场景额外要求 HIPAA 合规）
|
||||
- [[HospitalityGuestServices]] ← analogous_to ← [[CustomerService]]（酒店客服 Agent 是通用客服 Agent 在款待业场景的具体化，HEARD 框架与通用投诉协议互通）
|
||||
- [[SupportResponder]] ← extends ← [[CustomerService]]（通用客服响应 Agent 是 Customer Service Agent 的抽象层）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[LegalClientIntake]] 冲突（由 [[HealthcareCustomerService]] 记录）：
|
||||
- 冲突点：身份验证严格程度在不同场景的差异
|
||||
- 当前观点（通用客服）：基于姓名 + 邮箱验证即可开始处理账户操作
|
||||
- 对方观点（医疗场景）：HIPAA 要求全名 + 出生日期 + SSN 后四位方可讨论 PHI
|
||||
- 注：两者场景不同，冲突源于场景差异而非事实矛盾，可共存
|
||||
@@ -2,47 +2,50 @@
|
||||
title: "Data Consolidation Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/data-consolidation-agent.md]]
|
||||
- [[Agent/agency-agents/specialized/data-consolidation-agent.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 将分散的销售提取数据整合为实时报告仪表盘
|
||||
- 问题域：销售团队缺乏统一视图查看各地区、销售代表和管道的实时业绩数据
|
||||
- 方法/机制：并行多维度查询 → 聚合计算派生指标 → Dashboard 友好 JSON 结构化输出 → 含时间戳的实时刷新机制
|
||||
- 结论/价值：< 1 秒仪表盘加载、60 秒自动刷新、零数据不一致
|
||||
- 核心主题：AI Agent 将分散的销售数据聚合为实时仪表盘报告，支持地域、代表、管道多维度视图
|
||||
- 问题域：销售团队需要统一的实时数据视图，替代手动 Excel 汇总，消除数据孤岛
|
||||
- 方法/机制：接收仪表盘或地域报告请求 → 并行查询所有数据维度 → 聚合计算派生指标 → 结构化为 Dashboard-friendly JSON 输出 → 含生成时间戳用于陈旧度检测
|
||||
- 结论/价值：实现 < 1 秒仪表盘加载、60 秒自动刷新、零数据不一致，支持 MTD/YTD/Year End 多视图
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Data Consolidation Agent 通过并行查询所有数据维度，将原始销售指标聚合为可操作的实时仪表盘
|
||||
- Agent 始终使用最新数据（按 type 取最新的 metric_date），确保数据时效性
|
||||
- 达成率计算：revenue / quota * 100，并处理除零错误
|
||||
- 按地区聚合数据，提供区域级别可见性，整合管道数据形成完整销售视图
|
||||
- 支持 MTD/YTD/Year End 多时间维度视图
|
||||
- Data Consolidation Agent 始终查询每个类型最新 metric_date 的数据，保证所有视图使用最新指标
|
||||
- 达成率（Attainment）计算公式为 revenue / quota * 100，需处理除零边界情况
|
||||
- 管道数据（Pipeline）与销售指标合并，提供从线索到成交的完整数据图景
|
||||
- 仪表盘交付物包含 6 类报告：地域绩效汇总、个人代表绩效、管道快照、6 个月趋势数据、Top 5 绩效代表、地域详细报告
|
||||
- 地域报告包含该地域内所有代表及其最新指标，以及最近 50 条指标历史记录
|
||||
- 成功指标：仪表盘加载 < 1 秒、报告每 60 秒自动刷新、100% 代表和活跃地域覆盖、详情视图与汇总视图零数据不一致
|
||||
|
||||
## Key Quotes
|
||||
> "You are the **Data Consolidation Agent** — a strategic data synthesizer who transforms raw sales metrics into actionable, real-time dashboards. You see the big picture and surface insights that drive decisions." — Agent 身份定义
|
||||
> "You are the **Data Consolidation Agent** — a strategic data synthesizer who transforms raw sales metrics into actionable, real-time dashboards." — Agent 身份定义，战略定位为"数据综合者"而非数据搬运工
|
||||
|
||||
> "Zero data inconsistencies between detail and summary views" — 数据质量核心承诺
|
||||
> "Calculate attainment accurately: revenue / quota * 100, handle division by zero" — 核心计算规则，除零处理是防止报告崩溃的关键
|
||||
|
||||
> "Include pipeline data: merge lead pipeline with sales metrics for full picture" — 管道数据合并策略，提供从线索到成交的全链路视图
|
||||
|
||||
## Key Concepts
|
||||
- [[Dashboard Report]]：含地区业绩摘要（YTD/MTD）、代表排名、管道快照、6 个月趋势、Top 5 业绩者
|
||||
- [[Territory Report]]：地区级深度分析，含该地区所有代表及其指标及最近 50 条历史记录
|
||||
- [[Sales Attainment]]：达成率 = revenue / quota * 100，处理除零错误
|
||||
- [[Pipeline Snapshot]]：按阶段聚合（数量/价值/加权价值）的管道数据快照
|
||||
- [[Metric Aggregation]]：多维度并行查询后聚合计算派生指标的工作流
|
||||
- [[Territory-Performance]]：按地域聚合的销售绩效指标汇总，含 YTD/MTD 收入、达成率、代表人数
|
||||
- [[Quota-Attainment]]：销售配额达成率，计算公式：revenue / quota * 100，处理除零边界
|
||||
- [[Pipeline-Metrics]]：销售管道各阶段（数量、价值、加权价值）的快照数据
|
||||
- [[MTD-YTD]]：Month-to-Date / Year-to-Date 两种时间维度汇总视图
|
||||
- [[Dashboard-Friendly-JSON]]：结构化 JSON 输出格式，专为仪表盘消费设计，含时间戳元数据
|
||||
- [[Trend-Analysis]]：过去 6 个月的趋势数据分析
|
||||
|
||||
## Key Entities
|
||||
- [[Sales Data Extraction Agent]]：上游数据提取 Agent，为 Data Consolidation Agent 提供原始销售指标数据
|
||||
- [[Report Distribution Agent]]：下游分发 Agent，接收整合后的仪表盘数据进行分发推送
|
||||
- [[Data-Consolidation-Agent]]：The Agency Specialized 部门的数据综合专家 Agent，专注于销售数据聚合与实时仪表盘
|
||||
- [[Sales-Data-Extraction-Agent]]：上游数据提取 Agent，监控文件系统并从 Excel 中提取销售指标，为本 Agent 提供数据源
|
||||
|
||||
## Connections
|
||||
- [[Sales Data Extraction Agent]] → produces → raw sales metrics
|
||||
- [[Data Consolidation Agent]] ← consumes ← [[Sales Data Extraction Agent]]
|
||||
- [[Report Distribution Agent]] ← consumes ← [[Data Consolidation Agent]] (Dashboard Report / Territory Report)
|
||||
- [[Sales Pipeline Analyst]] ← shares pipeline data sources with → [[Data Consolidation Agent]]
|
||||
- [[Sales Coach Agent]] ← consumes ← [[Data Consolidation Agent]] (Top 5 performers)
|
||||
- [[Sales-Data-Extraction-Agent]] ← upstream_data ← [[Data-Consolidation-Agent]]（数据提取后由本 Agent 进行聚合与展示）
|
||||
- [[Report-Distribution-Agent]] ← downstream_report ← [[Data-Consolidation-Agent]]（聚合后的报告传递给分发 Agent）
|
||||
- [[Sales-Pipeline-Analyst]] ← pipeline_insights ← [[Data-Consolidation-Agent]]（管道快照数据为管道分析提供输入）
|
||||
- [[Sales-Account-Strategist]] ← territory_data ← [[Data-Consolidation-Agent]]（地域绩效数据支持账户策略决策）
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突。该 Agent 与 [[Sales Pipeline Analyst]] 共享数据源但职责互补（分析 vs 整合），与 [[Report Distribution Agent]] 构成顺序管道关系。
|
||||
- 无已知内容冲突。Data Consolidation Agent 与 [[Sales-Data-Extraction-Agent]] 为上下游关系（非竞争），与 [[Report-Distribution-Agent]] 协同完成数据到用户的完整链路。
|
||||
|
||||
@@ -1,50 +1,53 @@
|
||||
---
|
||||
title: "Design Brand Guardian"
|
||||
title: "Brand Guardian Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
tags: [agent, design, brand, strategy]
|
||||
date: 2024-01-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-brand-guardian.md]]
|
||||
- [[Agent/agency-agents/design/design-brand-guardian.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Brand Guardian Agent 角色定义——品牌战略与身份守护专家智能体，负责创建 cohesive 品牌体系和保护品牌价值
|
||||
- 问题域：品牌战略制定、品牌视觉身份建设、品牌一致性维护、品牌知识产权保护
|
||||
- 方法/机制：品牌战略框架（Purpose/Vision/Mission/Values/Personality）、视觉身份系统（Logo/色彩/字体/CSS 变量系统）、品牌声音指南（Tone/Trait/声调变化）、品牌保护策略（商标监控、合规审计、危机管理）
|
||||
- 结论/价值：为 AI Agent 系统提供品牌守护能力，确保多 Agent 协作中品牌表达的一致性和完整性；品牌先行（Brand-First）原则确保在战术执行前先建立完整的品牌基础
|
||||
- 核心主题：The Agency Design 部门的品牌守护者专家 Agent，为品牌提供全面的战略定位、视觉识别系统构建和品牌保护
|
||||
- 问题域：品牌建设缺乏系统性、品牌一致性难以维护、品牌价值缺乏保护机制
|
||||
- 方法/机制：通过 Foundation-first 理念先行建立完整品牌基础，再通过系统性视觉识别、声音系统和保护策略确保品牌差异化与持久价值
|
||||
- 结论/价值：品牌必须在战术执行前完成战略基础建设；一致性是品牌成功的核心；保护与进化并重
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Brand Guardian Agent 通过战略性的品牌策略将业务目标与品牌执行连接起来，确保品牌决策与商业目标一致
|
||||
- 完整的视觉身份系统必须包含从品牌颜色、字体、间距到 Logo 变体的全链路 CSS 设计系统变量
|
||||
- 品牌保护是默认要求，需包含商标策略、合规监控和危机管理机制
|
||||
- 品牌需要在保持一致性的同时，为不同场景和应用提供足够的灵活性
|
||||
- Brand Guardian Agent 通过建立完整的品牌基础框架（Purpose/Vision/Mission/Values/Personality）实现品牌差异化
|
||||
- 视觉识别系统（Logo/Color/Typography）必须作为内聚系统设计，而非孤立元素
|
||||
- 品牌保护（商标/合规监控/危机管理）应作为默认要求内置于品牌策略中
|
||||
- 品牌进化需要在保持核心身份的同时适应市场变化
|
||||
|
||||
## Key Quotes
|
||||
> "You are **Brand Guardian**, an expert brand strategist and guardian who creates cohesive brand identities and ensures consistent brand expression across all touchpoints." — 角色核心定义
|
||||
> "Establish comprehensive brand foundation before tactical implementation" — 品牌先行原则
|
||||
> "Your brand's fiercest protector and most passionate advocate." — Brand Guardian 定位语
|
||||
> "Establish comprehensive brand foundation before tactical implementation" — 品牌优先原则
|
||||
> "Balance consistency with flexibility for different contexts and applications" — 一致性与灵活性平衡
|
||||
> "Build brands that can evolve and grow with changing market conditions" — 品牌长期演进思维
|
||||
> "Build brands that can evolve and grow with changing market conditions" — 战略品牌思维
|
||||
|
||||
## Key Concepts
|
||||
- [[Brand-Strategy]]: 品牌战略框架——Purpose（存在意义）、Vision（愿景）、Mission（使命）、Values（价值观）、Personality（人格）五要素，是所有品牌决策的顶层指导
|
||||
- [[Visual-Identity-System]]: 视觉身份系统——通过 CSS 变量定义的完整设计系统，涵盖品牌色彩（Primary/Secondary/Accent/Neutral）、字体（Primary/Secondary/Accent）、间距系统（XS/SM/MD/LG/XL）
|
||||
- [[Brand-Voice-Guidelines]]: 品牌声音指南——Voice Characteristics（声音特征）、Tone Variations（声调变化）、Messaging Architecture（信息架构）、Writing Guidelines（写作规范）四个维度确保品牌沟通一致性
|
||||
- [[Brand-Protection-Strategy]]: 品牌保护策略——商标与知识产权保护、合规监控流程、危机管理与声誉保护、干系人培训与品牌传播
|
||||
- [[Brand-Foundation-Framework]]：品牌 Purpose（存在意义）、Vision（愿景）、Mission（使命）、Values（价值观）、Personality（个性）的完整框架
|
||||
- [[Visual-Identity-System]]：Logo、Color Palette、Typography、Spacing 的系统性设计规范
|
||||
- [[Brand-Voice]]：品牌声音特征（Strategic/Consistent/Protective/Visionary）和 Tone 变体（Professional/Conversational/Supportive）
|
||||
- [[Brand-Protection]]：商标策略、合规监控、危机管理三位一体的品牌保护体系
|
||||
|
||||
## Key Entities
|
||||
- [[The Agency]]: 所属项目——Brand Guardian 是 The Agency 多智能体框架中的品牌守护专家，与 [[ArchitectUX]]（技术架构）、[[design-whimsy-injector]]（趣味性设计）、[[UX-Researcher]]（用户体验研究）协同，共同为 [[LuxuryDeveloper]] 提供完整的设计支撑
|
||||
- [[The-Agency]]：Brand Guardian Agent 所属的组织，提供 12 个业务部门共 147 个专业 Agent
|
||||
- [[Design-Department]]：Brand Guardian 所在的设计部门，与 UX Architect、Whimsy Injector 共同构成设计三支柱
|
||||
- [[UX-Architect]]：设计部门基础设施专家，Brand Guardian 在视觉识别上依赖其 CSS 设计系统
|
||||
- [[Whimsy-Injector]]：设计部门趣味性专家，Brand Guardian 定义的品牌个性是其趣味性设计的输入
|
||||
|
||||
## Connections
|
||||
- [[design-whimsy-injector]] ← complements ← [[design-brand-guardian]]
|
||||
- [[ArchitectUX]] ← complements ← [[design-brand-guardian]]
|
||||
- [[UX-Researcher]] ← supports ← [[design-brand-guardian]]
|
||||
- [[LuxuryDeveloper]] ← depends_on ← [[design-brand-guardian]]
|
||||
- [[The Agency]] ← contains ← [[design-brand-guardian]]
|
||||
- [[design-ux-architect]] ← provides_foundations ← [[design-brand-guardian]]
|
||||
- [[design-whimsy-injector]] ← extends ← [[design-brand-guardian]]
|
||||
- [[design-ux-researcher]] ← informs ← [[design-brand-guardian]]
|
||||
- [[workflow-landing-page]] ← requires ← [[design-brand-guardian]]
|
||||
- [[design-brand-guardian]] ← implements ← [[The-Agency]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[design-whimsy-injector]] 在设计方法论上的张力：
|
||||
- 冲突点：品牌一致性（Brand Guardian 强调标准化与防护）vs. 个性化趣味（Whimsy Injector 强调创意表达）
|
||||
- 当前观点：Brand Guardian 主张在战术执行前必须先建立完整的品牌基础，保护品牌完整性
|
||||
- 对方观点：Whimsy Injector 主张通过有目的的趣味和个性化微交互提升用户体验，允许灵活创意表达
|
||||
- 解决方向：两者互补——Brand Guardian 建立品牌边界，Whimsy Injector 在边界内注入品牌个性，两者共同服务于 LuxuryDeveloper 的高端品牌体验
|
||||
- 与 [[design-ux-architect]] 存在角色重叠张力：
|
||||
- 冲突点：两者都涉及视觉设计元素，边界模糊
|
||||
- 当前观点：Brand Guardian 聚焦品牌战略与品牌身份，UX Architect 聚焦技术实现与组件架构
|
||||
- 对方观点：UX Architect 认为技术架构是品牌落地的保障
|
||||
- 解决方式：通过时序分工协调——Brand Guardian 先定义品牌框架 → UX Architect 再构建技术系统
|
||||
|
||||
@@ -1,59 +1,65 @@
|
||||
---
|
||||
title: "Image Prompt Engineer Agent"
|
||||
title: "Image Prompt Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
tags: [ai-agent, design, prompt-engineering, photography, the-agency]
|
||||
date: 2026-05-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-image-prompt-engineer.md]]
|
||||
- [[Agent/agency-agents/design/design-image-prompt-engineer]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 图像生成提示词工程专家智能体，专注于将视觉概念精准翻译为可执行的提示词语言
|
||||
- 问题域：如何让 AI 图像生成工具（Midjourney/DALL-E/Stable Diffusion/Flux）稳定产出专业级摄影作品
|
||||
- 方法/机制：五层提示词结构框架（主体描述 → 环境设定 → 光线规范 → 摄影技术 → 风格美学）+ 平台特定语法优化 + 体裁专属提示模式
|
||||
- 结论/价值：通过结构化的摄影专业知识与 AI 提示词语言的融合，实现 90%+ 的视觉概念还原率，减少迭代次数，提升商业可用性
|
||||
|
||||
- **核心主题**：AI 图像生成提示词工程专家 Agent——将视觉概念精准翻译为结构化提示词语言，驱动 Midjourney、DALL-E、Stable Diffusion、Flux 等平台产出专业级摄影作品
|
||||
- **问题域**：AI 图像生成中的提示词不精确、无结构、术语错误等问题；摄影师和 AI 模型之间的"语言鸿沟"
|
||||
- **方法/机制**：五层提示词结构框架（主体 → 环境 → 光线 → 摄影技术 → 风格）+ 体裁专属模板（人像/产品/风光/时尚）+ 平台特定语法优化
|
||||
- **结论/价值**：结构化提示词 + 摄影精确术语 = 90%+ 视觉概念还原率；Midjourney/DALL-E/SD/Flux 各有专属语法；负向提示词是可控生成的关键工具
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 五层提示词结构（主体/环境/光线/技术/风格）确保 AI 生成图像与视觉概念高度一致
|
||||
- 摄影技术术语（如 f/1.8 bokeh、浅景深）比模糊描述（如"背景模糊"）产生更精确的 AI 输出
|
||||
- 负向提示词（negative prompts）在支持平台上可有效排除不想要的元素
|
||||
- 提示词框架应适配不同 AI 平台的语法偏好（Midjourney 参数、DALL-E 自然语言、Stable Diffusion token 加权、Flux 详细描述）
|
||||
|
||||
- **主体 + 机制 + 结果**：Image Prompt Engineer 使用五层结构化提示词框架 → 将视觉概念分层拆解为标准化描述 → 驱动 AI 模型实现 90%+ 视觉概念还原率
|
||||
- **主体 + 机制 + 结果**：Agent 使用精确摄影术语（如 "f/1.8 bokeh 浅景深" 而非 "背景模糊"）→ 消除 AI 模型对模糊描述的歧义 → 技术摄影元素（布光/景深/构图）精准渲染
|
||||
- **主体 + 机制 + 结果**：Agent 包含负向提示词规范 → 主动排除不想要元素 → 减少迭代次数，提升生成结果的可控性
|
||||
- **主体 + 机制 + 结果**：Agent 为四大主流平台（Midjourney/DALL-E/SD/Flux）提供专属语法和参数优化 → 各平台充分发挥特有能力 → 跨平台一致的专业输出
|
||||
|
||||
## Key Quotes
|
||||
> "Always structure prompts with subject, environment, lighting, style, and technical specs" — 提示词结构五要素
|
||||
> "Use specific, concrete terminology rather than vague descriptors" — 具体性原则
|
||||
> "Master the art of translating visual concepts into precise, structured language that produces stunning, professional-quality photography" — 核心使命
|
||||
|
||||
> "Always structure prompts with subject, environment, lighting, style, and technical specs" — 五层提示词结构的核心原则
|
||||
|
||||
> "Use specific, concrete terminology rather than vague descriptors" — 精确性优先于模糊性
|
||||
|
||||
> "Be specific: 'Soft golden hour side lighting creating warm skin tones with gentle shadow gradation' not 'nice lighting'" — 具体性示例
|
||||
|
||||
> "You're successful when: Generated images match the intended visual concept 90%+ of the time" — 成功指标定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Prompt-Engineering]]：AI 图像生成提示词工程的核心方法论
|
||||
- [[Five-Layer-Prompt-Structure]]：主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层
|
||||
- [[Photography-Prompt-Mastery]]：将摄影专业知识转化为 AI 可理解提示词的能力
|
||||
- [[Platform-Specific-Prompt-Optimization]]：针对不同 AI 图像平台（Midjourney/DALL-E/Stable Diffusion/Flux）的定制化提示词策略
|
||||
- [[Negative-Prompts]]：负向提示词，排除不想要的图像元素
|
||||
- [[Film-Emulation]]：胶片模拟风格提示词（Kodak Portra/Fuji Velvia/Ilford HP5/Cinestill 800T）
|
||||
- [[Lighting-Patterns]]：摄影布光模式（Rembrandt/Butterfly/Split/Chiaroscuro/Vermeer/Neon-Noir）
|
||||
|
||||
- [[Five-Layer-Prompt-Structure]]：五层提示词结构——主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层，是该 Agent 的核心方法论框架
|
||||
- [[Photography-Terminology]]：专业摄影术语体系——精确描述光线、构图、相机参数和后处理效果的标准化语言，如 Rembrandt Lighting、Butterfly Lighting、Bokeh 等
|
||||
- [[Negative-Prompting]]：负向提示词——主动指定不想要的内容元素，排除 AI 生成图像中的干扰和缺陷
|
||||
- [[Platform-Specific-Optimization]]：平台特定优化——Midjourney（`--ar`/`--v`/多提示词加权）、DALL-E（自然语言优化）、Stable Diffusion（Token 加权/Embedding/LoRA）、Flux（详细自然语言/写实优先）
|
||||
- [[Genre-Specific-Prompt-Patterns]]：体裁专属提示词模板——人像（85mm/f/1.4/浅景深）、产品（Hero Shot/微距/深焦）、风光（广角/深焦/HDR）、时尚（戏剧光/多样视角）
|
||||
|
||||
## Key Entities
|
||||
- [[Midjourney]]：AI 图像生成平台，以参数化提示词（--ar/--v/--style/--chaos）著称
|
||||
- [[DALL-E]]：OpenAI 的 AI 图像生成工具，擅长自然语言描述和风格混合
|
||||
- [[Stable-Diffusion]]：开源 AI 图像生成平台，支持 token 加权和 embedding 引用
|
||||
- [[Flux]]：以详细自然语言描述和照片级写实风格著称的新兴 AI 平台
|
||||
- [[Annie Leibovitz]]：时尚/人像摄影大师，其风格常被引用为提示词参考
|
||||
- [[Peter Lindbergh]]：经典黑白人像摄影大师，其极简风格常被引用为提示词参考
|
||||
- [[The Agency]]：多智能体框架，本智能体隶属 Design 设计部门
|
||||
|
||||
- [[Midjourney]]：AI 图像生成平台——支持 `--ar`/`--v`/`--style`/`--chaos`/`--no` 参数和多提示词加权（`::` 语法）
|
||||
- [[Stable-Diffusion]]：AI 图像生成平台——支持 Token 加权、Embedding 引用和 LoRA 集成
|
||||
- [[DALL-E]]：AI 图像生成平台——偏好详细自然语言描述，支持风格混合
|
||||
- [[Flux]]：AI 图像生成平台——对写实摄影有天然优势，偏好详细具体描述
|
||||
- [[Annie-Leibovitz]]：参考摄影师——戏剧性人像与叙事场景风格
|
||||
- [[Peter-Lindbergh]]：参考摄影师——自然光黑白、真实质感风格
|
||||
|
||||
## Connections
|
||||
- [[design-ui-designer]] ← shares_design_domain ← [[design-image-prompt-engineer]]
|
||||
- [[design-brand-guardian]] ← brand_consistency ← [[design-image-prompt-engineer]]
|
||||
- [[design-whimsy-injector]] ← visual_language ← [[design-image-prompt-engineer]]
|
||||
- [[design-ux-researcher]] ← visual_validation ← [[design-image-prompt-engineer]]
|
||||
- [[ArchitectUX]] ← design_system ← [[design-image-prompt-engineer]]
|
||||
- [[Multi-Agent-System-Reliability]] ← context ← [[The Agency]] agent ecosystem
|
||||
|
||||
- [[design-ui-designer]] ← depends_on ← [[design-image-prompt-engineer]]：UI Designer 在视觉设计阶段可能调用图像提示词工程能力获取参考图像或 UI 素材图像
|
||||
- [[design-whimsy-injector]] ← depends_on ← [[design-image-prompt-engineer]]：品牌趣味设计需要视觉图像支撑，提示词工程能力为趣味图像的精准生成提供语言工具
|
||||
- [[design-brand-guardian]] ← extends ← [[design-image-prompt-engineer]]：Brand Guardian 定义的视觉品牌规范通过 Image Prompt Engineer 的提示词框架转化为具体图像
|
||||
- [[design-visual-storyteller]] ← depends_on ← [[design-image-prompt-engineer]]：视觉叙事中的图像素材通过提示词工程实现精准生成
|
||||
|
||||
## Contradictions
|
||||
- 与 [[design-ui-designer]] 在视觉一致性上的差异：
|
||||
- 冲突点：UI Designer 追求像素级精确还原（95%+ 准确率），Image Prompt Engineer 的输出本质上是概率生成，存在固有不确定性
|
||||
- 当前观点：Image Prompt Engineer 的目标不是像素级还原，而是 90%+ 视觉概念还原；概率性是 AI 图像生成的本质约束
|
||||
- 对方观点：UI Designer 要求 95%+ 实现准确率，将提示词视为"设计到代码"的翻译环节
|
||||
- 协调方案：两者协同时，Image Prompt Engineer 应提供多版本变体供 UI Designer 选择，并在提示词中增加确定性约束（如具体颜色值、光照参数）
|
||||
|
||||
- 与 [[design-ui-designer]] 冲突：
|
||||
- **冲突点**：精确性要求——UI Designer 要求像素级精确的确定性交付，AI 图像生成本质是概率性过程，存在固有不确定性
|
||||
- **当前观点**：Image Prompt Engineer 通过确定性约束（具体颜色值/光照参数/相机规格）最大化控制力，接受概率性结果的有限不确定性
|
||||
- **对方观点**：UI Designer 追求 95%+ 视觉一致性，可能对 AI 生成的不确定性持保留态度
|
||||
- **协调方式**：UI Designer 在需要 AI 生成图像时，通过 Image Prompt Engineer 提供极其详细的摄影参数约束，将概率空间压缩到可接受范围
|
||||
|
||||
@@ -1,53 +1,51 @@
|
||||
---
|
||||
title: "Inclusive Visuals Specialist"
|
||||
type: source
|
||||
tags: [generative-ai, bias-mitigation, prompt-engineering, inclusive-design, image-generation, video-generation, ai-ethics]
|
||||
sources: []
|
||||
last_updated: 2026-04-24
|
||||
tags: []
|
||||
date: 2026-05-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-inclusive-visuals-specialist.md]]
|
||||
- [[Agent/agency-agents/design/design-inclusive-visuals-specialist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 图像/视频生成中的包容性视觉呈现专家 Agent，专注于消除系统性刻板印象和偏见，生成具有文化真实性、尊严感和无歧视性的图像与视频。
|
||||
- 问题域：主流图像/视频生成模型（Midjourney、Sora、Runway、DALL-E）固有的刻板印象问题——克隆脸、异域化布光、符号乱码、地理/建筑失真。
|
||||
- 方法/机制：通过结构化提示词工程（Subject → Sub-actions → Context → Camera → Color Grade → Explicit Exclusions）构建"有尊严的视频提示"，并在 4 阶段工作流中嵌入负向约束库、物理学定义和 7 点 QA 审查。
|
||||
- 结论/价值：实现"表征准确度 100%"、"AI 伪影消除率 100%"、"社区验证认可"三大成功指标。
|
||||
- 核心主题：AI 图像与视频生成中的系统性偏见问题，以及如何通过精密的提示词工程实现有尊严、真实、文化准确的人类 representation
|
||||
- 问题域：Midjourney、DALL-E、Sora、Runway 等基础模型内置的刻板印象、克隆面孔、文化符号乱码、地理建筑失真等系统性偏差
|
||||
- 方法/机制：六阶段工作流（Brief Intake → Annotation Framework → Video Physics Definition → Review Gate）；五段式提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）；显式负面约束库（Negative Prompt Library）；7 点 QA 检查清单
|
||||
- 结论/价值：最终生产资产中刻板印象零依赖；100% 消除克隆面孔和乱码文化文字；确保被描绘社区的用户认可资产为真实、有尊严且符合其现实的特定 representation
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主流 AI 图像/视频生成模型默认携带系统性刻板印象（"穿帽衫的黑客"、"白救世主 CEO"），需通过显式负向约束加以对抗。
|
||||
- 多样化人群图像中若不明确禁止"克隆脸"，模型会生成同一边缘化人物的多个复制版本，导致冒犯性表征。
|
||||
- AI 在非英语文字、文化符号生成上存在幻觉倾向（生成乱码或冒犯性字符），必须在负向提示中显式排除。
|
||||
- 视频生成中服装、头发、辅助器具（轮椅、拐杖）的物理一致性需要显式定义，否则模型会产生物理学错误。
|
||||
- 过度纠正（Over-correction）是新型风险——AI 在刻意追求多样性时可能产生"符号化"、不真实的构图。
|
||||
- 提示词工程师通过架构化约束注入，能够系统性对抗基础模型的"异域化"偏见（exoticism bias），确保照明和地理建筑反映真实生活现实
|
||||
- 身份（Identity）不应被视为简单的描述符输入——它是一个需要专业技术知识才能准确 representation 的领域
|
||||
- 在视频生成中，必须显式定义衣物、头发和辅助行动器具（轮椅、拐杖、假肢）的物理规律，以避免渲染故障或物理错误
|
||||
- 代理人在评估 AI 输出时不仅检查技术保真度，还检查社会学准确性（Sociological Accuracy）
|
||||
|
||||
## Key Quotes
|
||||
> "Identity is a domain requiring technical expertise to represent accurately." — 身份表征不是简单的描述符输入，而是一个需要专业技术来处理的问题域。
|
||||
> "The current prompt will likely trigger the model's 'exoticism' bias. I am injecting technical constraints to ensure the lighting and geographical architecture reflect authentic lived reality." — 解释性声明：当前提示词可能触发模型的"异域化"偏见，正在注入技术约束以确保布光和建筑反映真实生活现实。
|
||||
> "You reject 'Kumbaya' stock-photo tropes, performative tokenism, and AI hallucinations that distort cultural realities." — 拒绝"Kumbaya"式库存照片套路、表演性象征主义和扭曲文化现实的 AI 幻觉。
|
||||
> "The current prompt will likely trigger the model's 'exoticism' bias. I am injecting technical constraints to ensure the lighting and geographical architecture reflect authentic lived reality." — Inclusive Visuals Specialist 核心沟通语
|
||||
> "Identity is a domain requiring technical expertise to represent accurately." — 身份 representation 的核心原则
|
||||
> "You review AI output not just for technical fidelity, but for sociological accuracy." — 代理人评估标准
|
||||
|
||||
## Key Concepts
|
||||
- [[InclusiveVisuals]]: AI 生成图像/视频中的包容性视觉呈现——确保生成内容反映真实多样的社会现实，而非刻板印象。
|
||||
- [[NegativePromptingLibrary]]: 负向提示库——显式列举 AI 应避免生成的内容，是对抗 AI 幻觉的核心技术手段。
|
||||
- [[CloneFaceProblem]]: 克隆脸问题——AI 在生成多样化人群时倾向于生成同一人的多个复制版本，需要通过约束面部结构差异来避免。
|
||||
- [[ExoticismBias]]: 异域化偏见——AI 对非西方文化进行"东方主义"式的过度美化或扭曲呈现，需要通过地理和建筑真实性约束加以对抗。
|
||||
- [[VideoPhysicsDefinition]]: 视频物理学定义——对服装、头发、辅助器具的运动和交互进行显式物理约束，确保时间一致性。
|
||||
- [[IntersectionalRepresentation]]: 交叉性表征——同时考虑文化、年龄、残疾、社会经济地位等多重身份的叠加表征。
|
||||
- [[CommunityValidation]]: 社区验证——确保所描绘社区的用户认可生成资产为真实、有尊严且符合其现实的表征。
|
||||
- [[Negative Prompting]]：通过显式负面约束阻止 AI 生成中的"克隆面孔"、乱码文化文字、超现实/科幻刻板等降低人类 representation 质量的 artifacts
|
||||
- [[Intersectionality]]：在文化、年龄、残障、社会经济地位等多维度交叉重叠下捕捉真实的身份 representation，要求特定的提示词架构方法
|
||||
- [[Video Physics Definition]]：在 Sora/Runway 等视频生成模型中显式定义衣物飘逸、头发摆动、轮椅轮胎接触地面等物理一致性约束
|
||||
- [[Cultural Authenticity]]：确保提示词正确锚定主体在其真实环境（准确建筑、正确服饰类型、适合黑色素的照明）中的 representation
|
||||
- [[Sociological Accuracy]]：超越技术保真度的 AI 输出评估维度——检查 representation 是否被描绘社区的用户认可为真实和有尊严的
|
||||
|
||||
## Key Entities
|
||||
- [[TheAgency]]: 该 Agent 所属的 Agent 团队体系（agency-agents）。
|
||||
- Midjourney、Sora、Runway Gen-3、DALL-E：主要的目标图像/视频生成平台。
|
||||
- [[Midjourney]]：图像生成平台，面临克隆面孔和刻板印象的已知问题
|
||||
- [[DALL-E]]：OpenAI 图像生成平台，需要通过负面约束阻止文化符号乱码
|
||||
- [[Sora]]：OpenAI 视频生成模型，视频物理约束（衣物/辅助器具渲染）的重要目标平台
|
||||
- [[Runway]]：视频生成平台，需要 temporal consistency 约束确保运动一致性
|
||||
|
||||
## Connections
|
||||
- [[DesignImagePromptEngineer]] ← extends ← [[InclusiveVisualsSpecialist]]（提示词工程是该 Agent 的核心技术）
|
||||
- [[DesignUXResearcher]] ← provides_review_gate ← [[InclusiveVisualsSpecialist]]（UX Researcher 提供 7 点 QA 审查）
|
||||
- [[DesignBrandGuardian]] ← quality_gate ← [[InclusiveVisualsSpecialist]]（Brand Guardian 把控企业品牌伦理标准）
|
||||
- [[InclusiveVisualsSpecialist]] ← produces_assets_for ← 全球文化活动（营销/传播团队）
|
||||
- [[Design Image Prompt Engineer]] ← 平行协作 ← [[Inclusive Visuals Specialist]]（两者同属 The Agency Design 部门，图像工程师负责视觉概念翻译，Inclusive Visuals 专攻多样性 representation）
|
||||
- [[Design Brand Guardian]] ← 对齐约束 ← [[Inclusive Visuals Specialist]]（品牌视觉规范与伦理 AI imagery 标准需要协调）
|
||||
- [[Design UX Researcher]] ← 质量验证 ← [[Inclusive Visuals Specialist]]（UX Researcher 负责 7 点 QA 检查清单的社区感知验证）
|
||||
|
||||
## Contradictions
|
||||
- 与通用图像生成指南可能存在张力：
|
||||
- 冲突点：通用 AI 图像生成追求"美观"、"商业化"，而包容性视觉优先"真实性"、"去刻板印象"
|
||||
- 当前观点：社会影响和尊严优先于商业美学；需要技术约束来对抗模型的美学偏见
|
||||
- 对方观点：商业应用需要快速产出，"适度多样性"已足够
|
||||
- 与 [[Design Image Prompt Engineer]] 存在张力：
|
||||
- 冲突点：概率生成与像素精确之间的平衡
|
||||
- Inclusive Visuals 的观点：需要显式负面约束和确定性物理定义来保证 representation 准确性，不接受"足够好"的概率分布
|
||||
- Image Prompt Engineer 的观点：允许一定的创意概率空间，通过风格层而非约束层实现文化准确性
|
||||
- 协调方式：在 Subject/Context 层使用 Inclusive Visuals 的精确约束，在 Style/Color Grade 层保留 Image Prompt Engineer 的创意概率空间
|
||||
|
||||
@@ -1,52 +1,49 @@
|
||||
---
|
||||
title: "UI Designer Agent Personality"
|
||||
type: source
|
||||
tags: ["agent", "design", "ui", "design-system"]
|
||||
date: 2026-04-24
|
||||
tags: ["agency", "design", "ui", "agent"]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-ui-designer.md]]
|
||||
- [[Agent/agency-agents/design/design-ui-designer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：UI Designer Agent 的角色定义、核心使命、设计交付物与工作流程
|
||||
- 问题域：多 Agent 系统中 UI 设计专家 Agent 的定位与职责边界
|
||||
- 方法/机制：设计系统优先（Design System First）、WCAG AA 可访问性合规、像素级界面交付、响应式框架设计
|
||||
- 结论/价值：UI Designer Agent 通过构建组件库、设计令牌系统、响应式框架和可访问性标准，确保产品界面的一致性、可复用性与包容性
|
||||
- 核心主题：UI Designer Agent 的角色定义、核心使命、工作流程和交付物模板
|
||||
- 问题域：如何在 AI Agent 系统中构建专业的用户界面设计能力
|
||||
- 方法/机制：通过设计系统优先的方法，建立组件库、设计令牌系统、无障碍标准和响应式框架
|
||||
- 结论/价值：提供标准化、可复用、可访问的 UI 设计解决方案，使界面一致性和用户体验达到 95%+
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- UI Designer Agent 以设计系统为优先，在创建单个界面之前先建立组件基础
|
||||
- 所有设计必须内置可访问性合规（WCAG AA 标准，色彩对比度 4.5:1）
|
||||
- 开发者交付物需包含详细测量规格、组件文档与设计 QA 流程，实现 90%+ 实现准确率
|
||||
- 设计系统需在 95%+ 界面元素中保持一致性
|
||||
- UI Designer Agent 通过建立组件基础而非创建单个屏幕，确保整个产品生态系统的可扩展性和一致性
|
||||
- UI Designer Agent 将无障碍设计内置于基础层，而非后期添加，满足 WCAG AA 标准
|
||||
- UI Designer Agent 的设计系统可实现 95%+ 的界面元素一致性，开发者交接准确率达 90%+
|
||||
|
||||
## Key Quotes
|
||||
> "Build accessibility into the foundation rather than adding it later." — UI Designer Agent 设计原则
|
||||
> "You're successful when: Design system achieves 95%+ consistency across all interface elements." — UI Designer 成功指标
|
||||
> "Build accessibility into the foundation rather than adding it later" — 无障碍设计核心原则
|
||||
> "Design system achieves 95%+ consistency across all interface elements" — 成功指标
|
||||
> "Developer handoff requires minimal design revision requests (90%+ accuracy)" — 开发者交接标准
|
||||
|
||||
## Key Concepts
|
||||
- [[Design System]]：组件库与视觉语言体系，确保跨产品的一致性
|
||||
- [[Design Tokens]]：设计令牌系统，用 CSS 变量管理颜色、字体、间距等视觉原子
|
||||
- [[Visual Hierarchy]]：通过排版、颜色和布局建立视觉层次，引导用户注意力
|
||||
- [[Responsive Design]]：移动优先的响应式框架，支持 Mobile/Tablet/Desktop/Large Desktop 多断点
|
||||
- [[WCAG AA]]：Web 内容可访问性指南 AA 级标准，色彩对比度 4.5:1
|
||||
- [[Component Library]]：可复用组件库（Button、Input、Card、Navigation 等），带完整状态规格
|
||||
- [[Dark Mode]]：深色模式与主题化系统，支持灵活的品牌表达
|
||||
- [[Design QA]]：设计质量保证流程，验证像素级实现与规格一致性
|
||||
- [[Accessibility-First Design]]：无障碍优先设计，内置键盘导航、屏幕阅读器支持、焦点管理
|
||||
- [[Design Token System]]：通过 CSS 变量定义颜色、字体、间距、阴影等设计原子，实现跨平台一致性
|
||||
- [[Component Library Architecture]]：可复用组件库的架构设计，包括基础组件（按钮、表单、卡片、导航）和反馈组件（警告、提示、模态框）
|
||||
- [[WCAG Accessibility Standards]]：Web Content Accessibility Guidelines，定义色对比度（4.5:1）、键盘导航、屏幕阅读器支持等标准
|
||||
- [[Responsive Design Framework]]：基于断点的响应式设计框架，支持 Mobile First 和多设备适配
|
||||
- [[Visual Hierarchy System]]：通过字体系统、颜色语义和间距比例建立视觉层次结构
|
||||
- [[Design QA Process]]：设计质量保证流程，用于验证实现准确性和像素完美交付
|
||||
|
||||
## Key Entities
|
||||
- UI Designer Agent：多 Agent 协作系统中的界面设计专家角色，专注于视觉设计系统与像素级界面交付
|
||||
- [[The Agency]]：多 Agent 协作系统，UI Designer 作为其中的设计专家 Agent
|
||||
- [[UX Architect]]：The Agency 中的 UX 架构师，与 UI Designer 协作建立设计系统基础
|
||||
- [[Brand Guardian]]：品牌守护 Agent，与 UI Designer 协作确保品牌一致性
|
||||
|
||||
## Connections
|
||||
- [[Design Brand Guardian]] ← complements ← [[UI Designer]]
|
||||
- [[Design Whimsy Injector]] ← extends ← [[UI Designer]]
|
||||
- [[Design UX Architect]] ← depends_on ← [[UI Designer]]
|
||||
- [[UX Researcher Agent]] → informs → [[UI Designer]]（用户研究洞察驱动界面设计决策）
|
||||
- [[Design Brand Guardian]] ← extends ← [[Design UI Designer]]（品牌规范扩展设计系统）
|
||||
- [[Design UX Researcher]] ← depends_on ← [[Design UI Designer]]（UX 研究指导设计决策）
|
||||
- [[Design Whimsy Injector]] ← extends ← [[Design UI Designer]]（趣味性增强用户界面）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Design Whimsy Injector]] 存在张力：
|
||||
- 冲突点：一致性与创意趣味性之间的平衡
|
||||
- 当前观点（UI Designer）：建立严格的组件库和设计规范，追求 95%+ 视觉一致性
|
||||
- 对方观点（Design Whimsy Injector）：在规范内注入意外的趣味元素，增加情感连接
|
||||
- 协调方向：趣味性注入应发生在预定义组件的可配置槽位中（如微交互动画），不破坏核心设计系统的一致性
|
||||
- 与 [[Design Whimsy Injector]] 的关系需要平衡：
|
||||
- 冲突点：设计一致性与视觉趣味性之间的权衡
|
||||
- 当前观点：UI Designer 强调系统性和一致性优先
|
||||
- 对方观点：Whimsy Injector 追求独特性和趣味性设计
|
||||
|
||||
@@ -1,51 +1,54 @@
|
||||
---
|
||||
title: "ArchitectUX Agent Personality"
|
||||
title: "UX Architect"
|
||||
type: source
|
||||
tags: [agent, design, ux, css, frontend, the-agency]
|
||||
date: 2026-04-20
|
||||
tags: [agent, ux, css, architecture, design-system, frontend]
|
||||
date: 2026-04-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-ux-architect.md]]
|
||||
- [[Agent/agency-agents/design/design-ux-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：ArchitectUX 智能体的角色定义——为开发者提供坚实的技术架构和 UX 基础，消除架构决策疲劳
|
||||
- 问题域：Web 项目中 CSS 系统混乱、响应式策略缺失、主题切换缺失等开发者痛点
|
||||
- 方法/机制：通过 CSS 设计系统（变量/排版/间距/颜色令牌）、布局框架（Grid/Flexbox）、信息架构、ThemeManager JS 类实现
|
||||
- 结论/价值：ArchitectUX 作为 [[The Agency]] 设计部门的多智能体之一，负责在 LuxuryDeveloper 实施前建立可扩展的技术基础
|
||||
- 核心主题：AI Agent 系统中 UX Architect（技术架构与用户体验专家）的角色定义与交付物规范
|
||||
- 问题域：多 Agent 协作系统中，如何为开发者提供可靠的技术基础和清晰的实现路径
|
||||
- 方法/机制：CSS 设计系统（变量/间距/字体）→ 布局框架（Grid/Flexbox）→ 组件层级 → 主题切换（light/dark/system）→ PM 与开发之间的翻译桥梁
|
||||
- 结论/价值：Foundation-first 理念，通过消除架构决策疲劳提升开发者生产力，确保项目一致性和可扩展性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **ArchitectUX** ← 创建 → **CSS 设计系统基础**：通过 CSS 变量令牌体系（颜色/排版/间距/容器）实现跨项目可维护的样式架构，消除硬编码值
|
||||
- **主题切换** ← 强制要求 → **所有新站点必须包含**：light/dark/system 三模式切换，preserves 用户偏好，支持 WCAG 合规
|
||||
- **架构优先** ← 预防 → **CSS 冲突**：在实施前先设计组件层级和命名规范，防止样式冲突和技术债务
|
||||
- **系统架构领导力** ← 负责 → **仓库拓扑/数据契约/API规范**：确保跨系统一致性和 Schema 合规
|
||||
- **开发者生产力** ← 通过 → **消除架构决策疲劳**：提供清晰可实施的规范，减少返工和重复决策
|
||||
- ArchitectUX Agent 通过提供 CSS 设计系统、布局框架和清晰的实现规范，为 LuxuryDeveloper 消除架构决策疲劳
|
||||
- CSS 变量系统应涵盖颜色、排版、间距三个维度，并原生支持 light/dark/system 三种主题模式
|
||||
- Theme Toggle 是所有新站点的默认必备组件，优先使用 localStorage + `prefers-color-scheme` 检测
|
||||
- 组件命名应遵循 BEM/Utility-first/Component-based 三种方法之一，并在项目内保持一致
|
||||
- ArchitectUX 在 ProjectManager 和 LuxuryDeveloper 之间充当翻译层，确保专业 UX 基线在 premium polish 之前落地
|
||||
|
||||
## Key Quotes
|
||||
> "Create scalable CSS architecture before implementation begins" — Foundation-First Approach 原则，要求在动手前先建立系统
|
||||
> "Eliminate architectural decision fatigue for developers" — Developer Productivity Focus 核心理念，ArchitectUX 存在的核心价值主张
|
||||
> "Create scalable CSS architecture before implementation begins" — Foundation-First Approach，CSS 架构应在实现之前完成设计
|
||||
> "Eliminate architectural decision fatigue for developers" — 核心价值主张，开发者不需要做架构决策
|
||||
> "Ensure professional UX baseline before premium polish is added" — 与 LuxuryDeveloper 的分工边界
|
||||
|
||||
## Key Concepts
|
||||
- **CSS 设计系统（CSS Design System）**：由 CSS 变量令牌（颜色/排版/间距/组件）构成的标准化样式体系，支持 light/dark/system 主题切换
|
||||
- **布局框架（Layout Framework）**：基于现代 CSS Grid/Flexbox 的容器系统和响应式断点策略（mobile-first）
|
||||
- **ThemeManager**：管理 light/dark/system 三种主题状态切换的 JavaScript 类，持久化用户偏好至 localStorage
|
||||
- **信息架构（Information Architecture）**：页面层级结构、导航策略、内容权重系统（H1 > H2 > H3）
|
||||
- **可访问性基础（Accessibility Foundation）**：WCAG 2.1 AA 合规标准，键盘导航、屏幕阅读器支持
|
||||
- **组件层级（Component Hierarchy）**：Layout Components → Content Components → Interactive Components → Utility Components 四层架构
|
||||
- **交接文档（Developer Handoff Documentation）**：包含优先级顺序、文件结构、实现笔记的完整交付模板
|
||||
- [[CSS-Design-System]]：颜色变量、排版比例、间距系统的基础架构，是所有新项目交付的起点
|
||||
- [[Layout-Framework]]：基于 CSS Grid 和 Flexbox 的响应式布局框架，包含容器系统和网格模式
|
||||
- [[Component-Architecture]]：组件命名规范和层级结构，Layout > Content > Interactive > Utility 四级
|
||||
- [[Theme-Toggle]]：light/dark/system 三态主题切换组件，基于 localStorage 和 `prefers-color-scheme` 实现
|
||||
- [[Theme-Manager]]：JavaScript 类，管理主题状态持久化、切换和应用逻辑
|
||||
- [[Responsive-Breakpoints]]：移动优先的断点策略（320px → 768px → 1024px → 1280px）
|
||||
- [[Information-Architecture]]：页面层级和内容组织结构，导航策略与视觉权重系统
|
||||
|
||||
## Key Entities
|
||||
- **ArchitectUX**：Technical Architecture and UX Foundation Specialist Agent，紫色主题，📐 emoji，为 [[LuxuryDeveloper]] 提供可实施的技术基础
|
||||
- **LuxuryDeveloper**：The Agency 开发智能体，接收 ArchitectUX 的 CSS 系统和架构规范进行具体实现
|
||||
- **ProjectManager**：The Agency 项目管理智能体，提供任务列表，ArchitectUX 在其基础上添加技术基础层
|
||||
- [[LuxuryDeveloper]]：后续接手的开发者，依据 ArchitectUX 提供的规范进行高级实现
|
||||
- [[ProjectManager]]：输出任务列表，ArchitectUX 在此基础上添加技术基础层
|
||||
- [[ArchitectUX]]：技术架构和 UX 基础专家，本文档描述的 Agent 角色本身
|
||||
|
||||
## Connections
|
||||
- [[Project/fonrey/prompt/Role/design-ui-designer]] ← extends ← [[wiki/sources/design-ux-architect]]：UI 设计师在 ArchitectUX 建立的基础层上添加视觉设计细节
|
||||
- [[design-ux-researcher]] ← depends_on ← [[wiki/sources/design-ux-architect]]：UX 研究员的原型和交互规范依赖 ArchitectUX 的技术框架实现
|
||||
- [[design-brand-guardian]] ← coordinates ← [[wiki/sources/design-ux-architect]]：品牌规范约束 ArchitectUX 的 CSS 颜色令牌和排版系统
|
||||
- [[design-whimsy-injector]] ← adds_on ← [[wiki/sources/design-ux-architect]]：趣味元素注入者在基础架构完成后添加动效和个性风格
|
||||
- [[The Agency]] ← contains ← [[wiki/sources/design-ux-architect]]：ArchitectUX 是 The Agency 12 大部门之一 Design 部门的重要智能体
|
||||
- [[Multi-Agent-System-Reliability]] ← provides_pattern ← [[wiki/sources/design-ux-architect]]：多智能体可靠性模式（如 Handoff Protocol）指导 ArchitectUX 的交接文档规范
|
||||
- [[agents-orchestrator]] ← coordinates ← [[design-ux-architect]]（UX Architect 由 Orchestrator 协调编排）
|
||||
- [[design-ux-architect]] ← handoff_to ← [[specialized-luxury-developer]]（UX 基础 → LuxuryDeveloper 实现）
|
||||
- [[design-ux-architect]] ← receives_tasks_from ← [[project-manager-agent]]（PM 输出任务 → ArchitectUX 添加技术层）
|
||||
- [[design-ux-architect]] ← depends_on ← [[engineering-software-architect]]（软件架构师提供系统拓扑，UX 负责前端落地）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Project/fonrey/prompt/Role/design-ui-designer]] 在实现优先级上可能存在张力：ArchitectUX 主张"先基础后视觉"，UI 设计师可能倾向视觉优先。**当前观点**：基础优先，视觉细节在 CSS 系统稳定后添加，避免重构
|
||||
- 与 [[specialized-luxury-developer]] 的边界模糊：
|
||||
- 冲突点：LuxuryDeveloper 是否应该在实现过程中做架构决策
|
||||
- 当前观点：ArchitectUX 认为架构决策应由 UX Architect 在前期完成，LuxuryDeveloper 仅执行
|
||||
- 对方观点：LuxuryDeveloper 的场景中，开发者可能需要根据具体需求调整架构
|
||||
- 协调：两者属于时序分工，ArchitectUX 负责 Foundation，LuxuryDeveloper 负责 Polish，分界线在"专业 UX 基线建立"之后
|
||||
|
||||
@@ -1,58 +1,58 @@
|
||||
---
|
||||
title: "UX Researcher Agent Personality"
|
||||
title: "UX Researcher"
|
||||
type: source
|
||||
tags: ["UX", "Research", "Agent", "Design", "User-Experience", "The-Agency"]
|
||||
tags: [agent, ux, user-research, usability-testing, personas, behavioral-analysis]
|
||||
date: 2026-04-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-ux-researcher.md]]
|
||||
- [[Agent/agency-agents/design/design-ux-researcher.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：UX Researcher Agent 是一种专注于用户体验研究的 AI Agent，通过严谨的研究方法和数据驱动的洞察来弥合用户需求与设计解决方案之间的差距
|
||||
- 问题域：用户行为分析、可用性测试、定性与定量研究方法、产品决策验证
|
||||
- 方法/机制：混合研究设计、三角验证、用户旅程映射、A/B 测试、统计分析、可访问性研究
|
||||
- 结论/价值：确保设计决策基于真实用户数据而非假设，提高产品可用性和用户满意度
|
||||
- 核心主题：AI Agent 系统中 UX Researcher（用户体验研究员）的角色定义、研究方法论与交付物规范
|
||||
- 问题域：如何在多 Agent 协作系统中，通过定性与定量研究方法理解用户行为、验证设计决策，并提供可落地的洞察建议
|
||||
- 方法/机制：用户研究规划 → 数据采集（访谈/问卷/可用性测试）→ 主题分析与三角验证 → 洞察转化为可实施的设计建议 → 建立测量计划跟踪影响
|
||||
- 结论/价值：以证据为基础，80%+ 研究建议被设计与产品团队采纳；通过用户理解防止昂贵的架构设计错误；研究推荐实施后用户满意度可衡量地提升
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- UX Researcher Agent 通过定性和定量方法的混合研究设计，产生可靠、可操作的洞察
|
||||
- 用户体验研究必须遵循研究方法论优先原则：先建立明确的研究问题，再选择适当方法
|
||||
- 可访问性研究和包容性设计测试是默认要求，而非可选附加项
|
||||
- 研究发现通过三角验证和多数据源进行验证，确保质量和可靠性
|
||||
- 研究推荐被设计和产品团队实施的比率（80%+）是衡量 UX Researcher 成功的关键指标
|
||||
- UX Researcher Agent 通过混合研究方法（定性与定量结合），为设计决策提供真实用户数据支撑，而非假设驱动
|
||||
- 所有研究必须先确立清晰的研究问题，再选择方法；样本量需有统计依据，需通过三角验证缓解偏差
|
||||
- 可用性测试包含任务场景（35分钟）、基线访谈（10分钟）和测试后访谈（10分钟），收集量化指标（完成率/时间/错误数）和定性洞察
|
||||
- 用户画像基于实证数据而非假设，包含人口统计学、行为模式、目标与需求、使用场景和直接引用语
|
||||
- 研究交付物必须包含高/中/长期优先级建议，并建立明确的成功指标跟踪研究影响
|
||||
|
||||
## Key Quotes
|
||||
> "Validates design decisions with real user data, not assumptions." — Agent Vibe 宣言
|
||||
|
||||
> "Based on 25 user interviews and 300 survey responses, 80% of users struggled with..." — 证据优先的沟通风格示例
|
||||
|
||||
> "This finding suggests a 40% improvement in task completion if implemented." — 聚焦影响力的表达方式
|
||||
> "You are **UX Researcher**, an expert user experience researcher who specializes in understanding user behavior, validating design decisions, and providing actionable insights." — 核心身份定义
|
||||
> "Be evidence-based: 'Based on 25 user interviews and 300 survey responses, 80% of users struggled with...'" — 沟通风格：永远基于证据
|
||||
> "Research recommendations are implemented by design and product teams (80%+ adoption)" — 成功标准
|
||||
> "Present findings objectively without confirmation bias" — 伦理研究规范
|
||||
|
||||
## Key Concepts
|
||||
- [[Mixed-Methods Research]]：混合方法研究，结合定性和定量方法回答复杂研究问题
|
||||
- [[Usability Testing]]：可用性测试，通过真实用户任务执行验证产品易用性
|
||||
- [[User Persona]]：用户画像，基于实证数据创建的目标用户原型
|
||||
- [[User Journey Mapping]]：用户旅程映射，识别痛点和优化机会的完整用户路径分析
|
||||
- [[Triangulation]]：三角验证，通过多种数据源和方法验证研究发现
|
||||
- [[A/B Testing]]：A/B 测试，用于数据驱动决策的统计实验方法
|
||||
- [[Accessibility Research]]：可访问性研究，确保包容性设计覆盖残障用户群体
|
||||
- [[Behavioral Analytics]]：行为分析，解读和识别用户行为模式
|
||||
- [[Research Repository]]：研究知识库，构建机构知识积累的持续改进机制
|
||||
- [[User-Research-Methodology]]：混合研究方法框架，结合定性与定量方法（访谈/问卷/可用性测试/行为分析）回答不同研究问题
|
||||
- [[Usability-Testing]]：可用性测试协议，含任务场景设计、成功率/时间/错误数量化指标、测试后访谈结构
|
||||
- [[User-Persona]]：基于实证数据的用户画像模板，含人口统计学、行为模式、目标/需求、使用场景和引用语
|
||||
- [[User-Journey-Mapping]]：用户旅程地图，识别关键触点、痛点、情感变化和优化机会
|
||||
- [[Qualitative-Quantitative-Research]]：定性研究（访谈/观察/开放问卷）与定量研究（问卷/行为分析/A/B测试）的互补使用
|
||||
- [[Research-Triangulation]]：三角验证——通过多种数据源交叉验证研究结论，降低单一方法偏差
|
||||
- [[Inclusive-Design-Research]]：无障碍研究与包容性设计测试，确保残障用户可访问
|
||||
- [[Behavioral-Analytics]]：行为分析——解读用户行为数据、识别使用模式和优化机会
|
||||
|
||||
## Key Entities
|
||||
- [[Design Teams]]：设计团队，研究洞察的主要消费者和应用者
|
||||
- [[Product Teams]]：产品团队，基于用户研究做出产品决策
|
||||
- [[Stakeholders]]：利益相关者，研究发现的受众和决策影响者
|
||||
- [[The Agency]]：父组织，提供 Agent 框架和协作上下文
|
||||
- [[UX-Architect]]：UX Researcher 的重要协作者，在研究洞察基础上构建设计系统与布局框架
|
||||
- [[UX-Designer]]：UI 设计师，接收用户研究洞察并转化为界面设计
|
||||
- [[Design-Brand-Guardian]]：品牌守护者，确保研究洞察在品牌框架内落地
|
||||
- [[Product-Manager]]：产品经理，输入研究需求，接收可实施的设计建议
|
||||
- [[Luxury-Developer]]：开发者，依据研究洞察和设计系统实现最终产品
|
||||
|
||||
## Connections
|
||||
- [[design-ux-architect]] ← complements ← [[design-ux-researcher]]：研究与设计协同
|
||||
- [[design-whimsy-injector]] ← informs ← [[design-ux-researcher]]：用户洞察驱动设计趣味性
|
||||
- [[Product Feedback Synthesizer]] ← depends_on ← [[design-ux-researcher]]：反馈综合依赖用户研究
|
||||
- [[design-ux-architect]] ← receives_insights_from ← [[design-ux-researcher]]（UX Research 提供用户洞察，UX Architect 将其转化为设计系统）
|
||||
- [[design-ui-designer]] ← depends_on ← [[design-ux-researcher]]（UI 设计师依据用户研究洞察进行界面设计）
|
||||
- [[project-manager-agent]] ← receives_recommendations_from ← [[design-ux-researcher]]（PM 接收研究建议，纳入产品决策）
|
||||
- [[design-ux-researcher]] ← collaborates_with ← [[nexus-spatial-discovery]]（在空间指挥中心规划中，UX Researcher 识别调试为杀手级用例）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Design Whimsy Injector]] 可能的张力：
|
||||
- 冲突点：数据驱动的理性设计与创意趣味表达的关系
|
||||
- 当前观点：UX Researcher 强调验证设计决策需基于用户数据
|
||||
- 对方观点：Design Whimsy Injector 追求情感共鸣和创意突破
|
||||
- 协调方式：两者互补——研究验证用户需求，创意满足情感期望
|
||||
- 与 [[design-ux-architect]] 的假设前提张力：
|
||||
- 冲突点：设计系统架构是否需要用户研究验证
|
||||
- 当前观点：UX Researcher 认为所有设计决策应以用户研究为依据，即使架构级决策也需用户数据支撑
|
||||
- 对方观点：UX Architect 认为架构决策在某些情况下可基于技术约束和行业最佳实践，而非用户研究
|
||||
- 协调：两者互补——UX Architect 提供技术架构基线，UX Researcher 验证该基线是否真正满足用户需求，在 ProjectManager 的协调下分工
|
||||
|
||||
@@ -1,45 +1,49 @@
|
||||
---
|
||||
title: "Visual Storyteller Agent"
|
||||
type: source
|
||||
tags: ["agent", "design", "visual", "storytelling", "multimedia"]
|
||||
date: 2026-05-05
|
||||
tags: []
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-visual-storyteller.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Visual Storyteller Agent 的角色定义——视觉叙事与品牌故事创作专家智能体
|
||||
- 问题域：如何将复杂信息转化为能引发情感共鸣、驱动用户参与的视觉叙事内容
|
||||
- 方法/机制：故事弧创作（Beginning-Middle-End）、情感旅程映射、跨平台视觉策略、多媒体内容创作
|
||||
- 结论/价值：Visual Storyteller Agent 通过叙事结构设计、情绪节奏把控和跨平台适配，确保视觉内容在所有触点上保持一致的情感冲击力，提升品牌认知度和用户参与度
|
||||
- 核心主题：Visual Storyteller（视觉叙事者）—— 一个专注于视觉叙事、多媒体内容和品牌故事设计的 AI Agent 个性定义
|
||||
- 问题域：如何通过专业的视觉沟通与故事讲述能力，将复杂信息转化为有影响力的视觉内容
|
||||
- 方法/机制：基于叙事弧线（Story Arc）框架 + 多媒体内容创作能力 + 跨平台适配策略的 AI Agent 系统
|
||||
- 结论/价值：提供一套完整的视觉叙事 Agent 方法论，涵盖故事策略、视觉叙事规划、内容创作框架及跨平台部署
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 每个视觉故事必须具备清晰叙事结构（开头、中间、结尾），确保叙事的完整性和情感递进
|
||||
- 视觉内容在所有平台必须保持品牌一致性，适配不同平台算法和用户行为特征
|
||||
- 所有视觉内容必须满足 WCAG 可访问性标准，确保包容性
|
||||
- 视觉叙事内容参与度提升 50%+，故事完成率达 80%，品牌认知度提升 35%
|
||||
- Visual Storyteller Agent 通过明确的叙事结构（开头、中间、结尾），确保每个视觉故事都具有清晰的叙事框架
|
||||
- 该 Agent 整合多媒体设计能力，包括视频叙事、动画-motion graphics、摄影指导和交互式媒体
|
||||
- 跨平台视觉内容适配是该 Agent 的核心竞争力，支持 Instagram Stories、YouTube、TikTok、LinkedIn、Pinterest 等主流平台
|
||||
- 数据可视化与信息设计是视觉叙事的重要组成部分，通过渐进式披露（Progressive Disclosure）实现复杂信息的可理解呈现
|
||||
|
||||
## Key Quotes
|
||||
> "Every visual story must have clear narrative structure (beginning, middle, end)." — Visual Storyteller 设计标准
|
||||
> "Visual content performs 3x better than text-only content." — Visual Storyteller 成功指标
|
||||
> "Designed emotional journey that builds connection and drives engagement." — Visual Storyteller 沟通风格
|
||||
> "Every visual story must have clear narrative structure (beginning, middle, end)" — 叙事结构的核心原则
|
||||
> "Story Arc Creation: Beginning (setup), middle (conflict), end (resolution)" — 故事弧线的三段式结构
|
||||
> "Visual content engagement rates increase by 50% or more" — 成功指标定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Story Arc Creation]]：叙事弧创作——开头（背景设定）、中间（冲突推进）、结尾（解决方案呈现）
|
||||
- [[Emotional Journey Mapping]]：情感旅程映射——绘制故事中情感的高峰与低谷，优化用户参与节奏
|
||||
- [[Data Storytelling]]：数据叙事——通过视觉层次和叙事流程将复杂信息转化为引人入胜的故事
|
||||
- [[Cross-Platform Adaptation]]：跨平台适配——根据平台特性（Instagram/TikTok/YouTube/LinkedIn）调整视觉内容格式和叙事节奏
|
||||
- [[Motion Graphics]]：动态图形——动画、微交互和解释性动画的创作
|
||||
- [[Visual Pacing]]：视觉节奏——视觉元素的节奏和时序安排，实现最优参与度
|
||||
- [[Progressive Disclosure]]：渐进式披露——分层信息呈现策略，帮助用户逐步理解复杂内容
|
||||
- [[Brand Narrative Strategy]]：品牌叙事策略——跨所有触点的统一品牌故事体系
|
||||
- [[Visual Narrative]]：通过视觉元素构建故事情节的方法论，包含叙事弧线、角色发展、冲突识别和解决方案设计
|
||||
- [[Story Arc]]：故事弧线，视觉叙事的核心框架，由铺垫（setup）、冲突（conflict）、解决（resolution）三部分组成
|
||||
- [[Multimedia Content]]：多媒体内容，涵盖视频叙事、动画-motion graphics、摄影和交互式媒体等多种形式
|
||||
- [[Cross-Platform Adaptation]]：跨平台适配，根据不同平台特性调整视觉内容格式和叙事策略
|
||||
- [[Data Storytelling]]：数据叙事，通过视觉层级和叙事流程将复杂数据转化为易懂故事的能力
|
||||
- [[Progressive Disclosure]]：渐进式披露，通过分层信息呈现实现复杂内容的可理解传递
|
||||
- [[Emotional Journey Mapping]]：情感旅程映射，追踪故事中情感高峰与低谷的叙事技术
|
||||
|
||||
## Key Entities
|
||||
- Visual Storyteller Agent：多 Agent 协作系统中的视觉叙事专家角色，负责将复杂信息转化为引人入胜的视觉故事
|
||||
- [[Brand Guardian]]：品牌守护者（相关 Agent），与 Visual Storyteller 在品牌一致性方面存在协作关系
|
||||
- [[Inclusive Visuals Specialist]]：包容性视觉专家（相关 Agent），与 Visual Storyteller 在无障碍合规标准方面存在交集
|
||||
- [[Image Prompt Engineer]]：图像提示工程师（相关 Agent），与 Visual Storyteller 在视觉内容创作方面存在技术协作
|
||||
|
||||
## Connections
|
||||
- [[Design Brand Guardian]] ← complements ← [[Visual Storyteller]]（品牌身份体系支撑视觉叙事的一致性）
|
||||
- [[Design Inclusive Visuals Specialist]] ← extends ← [[Visual Storyteller]]（包容性视觉原则融入叙事内容）
|
||||
- [[UX Researcher Agent]] → informs → [[Visual Storyteller]]（用户研究洞察驱动情感旅程设计）
|
||||
- [[Design UI Designer]] ← depends_on ← [[Visual Storyteller]]（叙事框架需要 UI 设计师的界面呈现支撑）
|
||||
- [[Brand Guardian]] ← collaborates_with ← [[Visual Storyteller]]
|
||||
- [[Inclusive Visuals Specialist]] ← related_to ← [[Visual Storyteller]]
|
||||
- [[Image Prompt Engineer]] ← complements ← [[Visual Storyteller]]
|
||||
- [[UX Researcher]] ← informs ← [[Visual Storyteller]] (用户研究洞察为视觉叙事提供方向)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
@@ -1,47 +1,51 @@
|
||||
---
|
||||
title: "Design Whimsy Injector"
|
||||
title: "Whimsy Injector Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-05
|
||||
tags: [design, agent, brand, ux, gamification]
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/design/design-whimsy-injector.md]]
|
||||
- [[Agent/agency-agents/design/design-whimsy-injector.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：品牌个性化和愉悦感注入 Agent 角色定义（Whimsy Injector），为 LuxuryDeveloper 提供品牌人格、微交互和游戏化设计能力
|
||||
- 问题域：如何在保持专业性和品牌一致性的前提下，通过意想不到的趣味元素让品牌体验令人难忘
|
||||
- 方法/机制：Whimsy Injector 通过四大策略（战略人格注入、包容性愉悦设计、品牌个性框架、微交互设计系统）实现差异化品牌体验
|
||||
- 结论/价值：趣味性必须服务于功能或情感目的，包容性设计确保所有用户都能享受愉悦体验，用户参与度提升 40%+
|
||||
- 核心主题：品牌个性与趣味性交互设计专家 Agent（The Agency Design 部门）
|
||||
- 问题域：如何为品牌注入差异化、令人难忘的趣味元素，同时保持专业性和可访问性
|
||||
- 方法/机制：通过微交互设计系统、趣味文案库、游戏化成就系统、复活节彩蛋发现机制等手段，在用户交互全流程中嵌入愉悦感
|
||||
- 结论/价值：趣味性设计是有战略目的的——提升用户参与度、品牌记忆度和满意度，同时需兼顾包容性和性能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Whimsy Injector 通过在品牌体验中注入个性和趣味元素，实现品牌差异化——主体：Whimsy Injector，机制：战略性格 + 趣味注入，结果：难忘的差异化品牌体验
|
||||
- 包容性愉悦设计确保所有用户（包括残障用户）都能享受趣味体验——主体：Whimsy Injector，机制：包容性愉悦设计，结果：无障碍愉悦体验
|
||||
- 微交互设计通过性能优化的动画提升用户参与度——主体：Whimsy Injector，机制：性能优化的微交互设计，结果：参与度提升 40%+
|
||||
- 游戏化成就系统通过激励探索和奖励解锁提升用户留存——主体：Whimsy Injector，机制：成就系统 + 彩蛋机制，结果：用户留存提升
|
||||
- 趣味元素必须为功能性或情感性目的服务，否则属于干扰
|
||||
- 出色的错误提示和加载体验可将挫折感降低 40%
|
||||
- 游戏化成就系统可显著提升用户留存和参与度
|
||||
- 趣味设计必须对残障用户可访问，不能干扰屏幕阅读器
|
||||
|
||||
## Key Quotes
|
||||
> "Be playful yet purposeful: 'Added a celebration animation that reduces task completion anxiety by 40%'" — Whimsy Injector 沟通风格：强调趣味性的战略价值和可量化结果
|
||||
> "Design whimsy that enhances user experience rather than creating distraction" — 趣味设计的核心原则：服务于用户体验，而非分散注意力
|
||||
> "Every playful element must serve a functional or emotional purpose" — 趣味注入的首要规则：每个趣味元素必须有明确的功能或情感目的
|
||||
> "Every playful element must serve a functional or emotional purpose" — 趣味设计的核心原则：每个设计都必须有明确目的
|
||||
> "Added a celebration animation that reduces task completion anxiety by 40%" — 具体量化趣味设计的价值
|
||||
> "Designed personality elements that work for users with different cultural backgrounds and abilities" — 包容性设计是基础要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Whimsy-Injector]]：品牌个性和愉悦感注入专家 Agent，通过战略趣味设计实现品牌差异化，隶属于 The Agency 多 Agent 框架
|
||||
- [[Micro-Interaction-Design]]：微交互设计系统，通过 CSS 动画和状态反馈提升用户参与度，包含按钮悬停效果、表单验证反馈、加载动画等
|
||||
- [[Gamification-System]]：游戏化成就系统，通过徽章解锁、彩蛋发现、进度庆祝等机制激励用户探索和深度使用
|
||||
- [[Inclusive-Delight-Design]]：包容性愉悦设计，确保趣味元素对残障用户可访问、不干扰屏幕阅读器、支持减少动画偏好
|
||||
- [[微交互设计（Micro-Interaction）]]：通过小型动画和反馈增强用户体验的细节设计（如悬停效果、加载动画、按钮反馈）
|
||||
- [[品牌个性框架（Brand Personality Framework）]]：定义品牌在专业/休闲/错误/成功四种情境下的个性表达谱系
|
||||
- [[趣味分类学（Whimsy Taxonomy）]]：Subtle / Interactive / Discovery / Contextual 四类趣味的分类体系
|
||||
- [[游戏化（Gamification）]]：通过成就系统、进度庆祝、徽章解锁提升用户参与度和留存率
|
||||
- [[复活节彩蛋（Easter Egg）]]：隐藏功能奖励用户探索，增强分享欲和社区感
|
||||
- [[包容性设计（Inclusive Delight）]]：确保趣味元素对残障用户、文化背景不同用户均适用
|
||||
|
||||
## Key Entities
|
||||
- [[Whimsy-Injector]]：角色名称，品牌个性化和愉悦感注入专家 Agent，color: pink，emoji: ✨
|
||||
- [[ArchitectUX]]：UX 架构专家 Agent，与 Whimsy Injector 协作提供完整的品牌体验设计（技术架构 + 品牌人格）
|
||||
- [[LuxuryDeveloper]]：目标用户，需要为产品注入品牌个性和差异化体验的开发者
|
||||
- [[The Agency]]：多 Agent 框架，Whimsy Injector 隶属的 Agent 协作系统，通过多角色分工实现复杂任务
|
||||
- [[UX Architect]]：The Agency Design 部门核心技术架构专家，与 Whimsy Injector 协作建立完整设计系统
|
||||
- [[Design-UX-Designer]]：The Agency UI Designer，专注实现层，Whimsy Injector 提供趣味性设计指导
|
||||
- [[Design-Brand-Guardian]]：品牌守护者，与 Whimsy Injector 共同维护品牌个性一致性
|
||||
|
||||
## Connections
|
||||
- [[ArchitectUX]] ← complements ← [[Whimsy-Injector]]（ArchitectUX 提供技术基础，Whimsy Injector 提供品牌人格）
|
||||
- [[LuxuryDeveloper]] ← uses ← [[Whimsy-Injector]]（LuxuryDeveloper 是 Whimsy Injector 的目标用户和受益者）
|
||||
- [[Whimsy-Injector]] ← part of ← [[The Agency]]（Whimsy Injector 是 The Agency 多 Agent 框架的成员 Agent）
|
||||
- [[wiki/sources/design-ux-architect]] ← related_to ← [[design-whimsy-injector]]（同一设计分类下的互补角色）
|
||||
- [[design-ux-architect]] ← collaborative_with ← [[design-whimsy-injector]]（Foundation-first 框架下的设计系统构建）
|
||||
- [[design-whimsy-injector]] ← provides_delight_system ← [[design-brand-guardian]]（共同维护品牌个性）
|
||||
- [[design-ui-designer]] ← receives_specs ← [[design-whimsy-injector]]（趣味交互规格输出给开发者）
|
||||
|
||||
## Contradictions
|
||||
- 无冲突内容。Whimsy Injector 与 ArchitectUX 在设计分工上互补（技术架构 vs 品牌人格），无实质性内容冲突。
|
||||
- 与 [[design-ux-architect]] 的专业严谨性存在张力：
|
||||
- 冲突点：趣味元素的"度"如何把控，避免过度花哨影响专业形象
|
||||
- 当前观点：Whimsy Injector 认为趣味应无缝融入功能，提升愉悦感而不分散注意力
|
||||
- 对方观点：UX Architect 强调 Foundation-first，专业基线优先，个性在验证后再引入
|
||||
- 解决方向：时序分工——UX Architect 建立专业基线后，Whimsy Injector 在基线之上叠加趣味性
|
||||
|
||||
57
wiki/sources/engineering-ai-data-remediation-engineer.md
Normal file
57
wiki/sources/engineering-ai-data-remediation-engineer.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "AI Data Remediation Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-ai-data-remediation-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 数据修复工程师——使用气隙本地 SLM 和语义聚类技术，对大规模数据管道中的异常数据进行自动检测、分类与确定性修复的专业角色。专注于修复层：在数据损坏且管道无法停止的场景下，保证零数据丢失。
|
||||
- 问题域：数据管道中的异常数据修复，特别是生产环境无法停机、常规规则引擎无法处理语义歧义数据、需要 PII 合规保护的场景
|
||||
- 方法/机制：语义异常压缩（50,000 条错误行 → 8-15 个模式家族，SLM 调用从 50,000 次降至 ~12 次）；气隙 SLM Fix Generation（通过 Ollama 本地运行 Phi-3/Llama-3/Mistral，生成确定性 Python lambda）；零数据丢失保证（Source == Success + Quarantine 数学约束）；混合指纹识别（SHA-256 PK 哈希 + 向量相似度，防止误合并）
|
||||
- 结论/价值：每条数据变更均有完整审计轨迹；95%+ SLM 调用减少；PII 零网络出口；Lambda 拒绝率 < 5%；人工隔离率 < 10%
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI 应生成修复数据的逻辑，而非直接操作数据——SLM 仅输出 Python lambda，系统执行，不直接修改数据
|
||||
- 语义聚类可将海量异常数据压缩为可管理的模式家族，SLM 只需处理少数代表样本而非逐行处理
|
||||
- 气隙 SLM（Ollama 本地运行）保证 PII 数据零网络出口，满足企业数据合规要求
|
||||
- 混合指纹识别结合 SHA-256 主键哈希与向量语义相似度，防止因表面相似而误合并不同记录
|
||||
- 零数据丢失是数学约束而非目标——通过 Source == Success + Quarantine 等式自动强制执行，任何不匹配触发 Sev-1 告警
|
||||
|
||||
## Key Quotes
|
||||
> "AI should generate the logic that fixes data — never touch the data directly." — 核心设计哲学
|
||||
> "The SLM outputs a transformation function. Your system executes it. You can audit, rollback, and explain a function." — AI 生成逻辑 vs 直接修改数据的边界
|
||||
> "Medical records, financial data, personally identifiable information — none of it touches an external API. Ollama runs locally." — PII 零出口原则
|
||||
> "Semantic similarity is fuzzy. Always combine vector similarity with SHA-256 hashing of primary keys — if the PK hash differs, force separate clusters." — 混合指纹防误报
|
||||
> "Every AI-applied transformation is logged: [Row_ID, Old_Value, New_Value, Lambda_Applied, Confidence_Score, Model_Version, Timestamp]" — 完整审计轨迹要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Semantic Anomaly Compression]]：将海量异常数据行通过向量嵌入（sentence-transformers）+ 聚类（ChromaDB/FAISS）压缩为 8-15 个语义模式家族，每个家族仅需 3-5 个代表样本供 SLM 分析，实现 SLM 调用量降低 95%+
|
||||
- [[Air-Gapped SLM Fix Generation]]：通过 Ollama 本地运行 Phi-3/Llama-3/Mistral，SLM 输出严格格式化的 Python lambda 表达式（而非直接修改数据），保证 PII 数据完全离线处理
|
||||
- [[Hybrid Fingerprinting]]：结合 SHA-256 主键哈希（精确匹配）+ 向量语义相似度（语义聚类），防止 `"John Doe ID:101"` 与 `"Jon Doe ID:102"` 因表面相似而被误合并
|
||||
- [[Zero Data Loss Guarantee]]：数学约束 `Source_Rows == Success_Rows + Quarantine_Rows`，任何不匹配触发 Sev-1 告警与 DataLossException，确保修复过程无数据丢失
|
||||
- [[Lambda Safety Gate]]：SLM 输出的 lambda 必须以 `lambda` 开头、不含 `import/exec/eval/os/subprocess`，通过严格验证后才可执行，防止恶意代码注入
|
||||
- [[AI Generates Logic Not Data]]：核心安全原则——AI 仅提供修复逻辑，由系统确定性执行，数据变更全程可审计、可回滚
|
||||
|
||||
## Key Entities
|
||||
- [[Data Engineer]]：通用数据工程师角色（构建管道、设计 schema、编排作业），与 AI Data Remediation Engineer 的专注修复层形成互补
|
||||
- [[Ollama]]：本地 LLM 推理引擎，支持 Phi-3/Llama-3/Mistral 等模型在气隙环境下运行
|
||||
- [[Sentence-Transformers]]：本地向量嵌入模型（all-MiniLM-L6-v2），用于语义异常聚类
|
||||
- [[ChromaDB]]：本地向量数据库，支持异常数据的语义聚类与相似度查询
|
||||
- [[FAISS]]：Facebook AI 相似度搜索库，提供高效的向量索引与聚类能力
|
||||
|
||||
## Connections
|
||||
- [[Data Engineer]] ← builds_pipeline ← [[AI Data Remediation Engineer]]（修复层位于数据工程师构建的管道之后）
|
||||
- [[Semantic Anomaly Compression]] ← depends_on ← [[Sentence-Transformers]]（依赖本地嵌入生成）
|
||||
- [[Semantic Anomaly Compression]] ← depends_on ← [[ChromaDB]] 或 [[FAISS]]（依赖向量数据库进行聚类）
|
||||
- [[Air-Gapped SLM Fix Generation]] ← depends_on ← [[Ollama]]（依赖 Ollama 提供本地推理能力）
|
||||
- [[Hybrid Fingerprinting]] ← prevents ← [[AI Generates Logic Not Data]] 中的误合并风险
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Data Engineer]] 的职责定位：
|
||||
- 冲突点：Data Engineer 强调管道重构和 schema 设计，AI Data Remediation Engineer 强调不修改管道、专注修复层
|
||||
- 当前观点：修复层是数据质量保障的必要补充，无需重构现有管道即可提升数据可靠性
|
||||
- 对方观点：大规模数据问题应通过重构管道和优化 schema 从源头解决
|
||||
62
wiki/sources/engineering-ai-engineer.md
Normal file
62
wiki/sources/engineering-ai-engineer.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "AI Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-ai-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI/ML 工程师 Agent 个性化定义，涵盖机器学习模型开发、部署与生产集成的完整方法论
|
||||
- 问题域：构建智能化系统、实现生产级 AI 部署、AI 伦理与安全合规
|
||||
- 方法/机制：通过分阶段工作流（需求分析 → 模型开发 → 生产部署 → 监控优化）驱动 AI 工程实践
|
||||
- 结论/价值：定义了生产级 AI 工程师的核心能力矩阵，包括技术栈、集成模式、伦理规范和成功指标
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI 工程师应将 ML 模型转化为可扩展的生产特性，实现 <100ms 推理延迟和 >99.5% 服务可用性
|
||||
- 所有 AI 系统必须内置偏见检测、公平性指标、隐私保护和对抗鲁棒性
|
||||
- RAG 系统实现、LLM 微调和向量数据库集成是现代 AI 工程的核心能力
|
||||
- MLOps 自动化模型生命周期管理是生产 AI 的关键基础设施
|
||||
|
||||
## Key Quotes
|
||||
> "Turns ML models into production features that actually scale." — Agent 核心定位
|
||||
> "Always implement bias testing across demographic groups" — AI 安全底线规则
|
||||
> "Model achieved 87% accuracy with 95% confidence interval" — 数据驱动沟通风格
|
||||
|
||||
## Key Concepts
|
||||
- [[MLOps]]：模型版本管理、A/B 测试、监控、自动化再训练的完整生命周期管理
|
||||
- [[RAG]]：检索增强生成系统实现，用于 LLM 知识整合与实时更新
|
||||
- [[PromptEngineering]]：提示词工程，优化 LLM 输出质量和相关性
|
||||
- [[FairnessInML]]：公平性感知机器学习，偏见检测与缓解策略
|
||||
- [[ModelDriftDetection]]：模型性能漂移检测与自动再训练触发机制
|
||||
- [[DistributedTraining]]：多 GPU/多节点分布式训练，用于大规模数据集
|
||||
- [[ExplainableAI]]：可解释 AI (XAI) 技术，提升模型可解释性
|
||||
- [[DifferentialPrivacy]]：差分隐私，保护训练数据中的个人隐私
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：提供 GPT 系列 API，是 Agent LLM 集成的核心供应商之一
|
||||
- [[Anthropic]]：提供 Claude 系列 API，Agent 的 LLM 集成供应商
|
||||
- [[HuggingFace]]：Transformers 库和模型中心，Agent ML 框架的核心依赖
|
||||
- [[TensorFlow]]：Google 主推 ML 框架，Agent ML 能力的技术栈之一
|
||||
- [[PyTorch]]：Meta 主推 ML 框架，Agent 深度学习能力的核心工具
|
||||
- [[AWS]]：Amazon Web Services，提供 SageMaker 等云端 AI 服务
|
||||
- [[Azure]]：Microsoft Azure，提供 Azure Cognitive Services 云端 AI 服务
|
||||
- [[GoogleCloudAI]]：Google Cloud AI Platform，提供 Vertex AI 等服务
|
||||
- [[Pinecone]]：向量数据库，用于 RAG 系统的相似性检索
|
||||
- [[Weaviate]]：开源向量数据库，Agent RAG 架构的备选方案
|
||||
- [[Chroma]]：轻量级向量数据库，Agent 本地 RAG 快速原型方案
|
||||
- [[FAISS]]：Facebook AI 相似性搜索库，高效向量检索工具
|
||||
- [[FastAPI]]：现代 Python Web 框架，Agent 模型 serving 的核心 API 框架
|
||||
- [[MLflow]]：开源 ML 平台，Agent 用于模型版本跟踪和实验管理
|
||||
- [[Kubeflow]]：Kubernetes 原生 ML 工具包，Agent 规模化模型部署方案
|
||||
|
||||
## Connections
|
||||
- [[EngineeringBackendArchitect]] ← extends ← [[EngineeringAIEngineer]]（后端架构提供 API 基础设施，AI 工程师在其上构建推理服务）
|
||||
- [[TestingToolEvaluator]] ← depends_on ← [[EngineeringAIEngineer]]（AI 模型的工具评估依赖 AI 工程师的实现）
|
||||
- [[AgentsOrchestrator]] ← orchestrates ← [[EngineeringAIEngineer]]（编排层协调多个 AI 工程师子 agent 完成复杂任务）
|
||||
- [[SpecializedMCPBuilder]] ← builds_tools_for ← [[EngineeringAIEngineer]]（MCP Builder 为 AI 工程师构建工具扩展）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
@@ -1,52 +1,51 @@
|
||||
---
|
||||
title: "Autonomous Optimization Architect"
|
||||
title: "Autonomous Optimization Architect Agent Personality"
|
||||
type: source
|
||||
tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"]
|
||||
date: 2026-04-26
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]]
|
||||
- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型
|
||||
- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障
|
||||
- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps
|
||||
- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低
|
||||
- 核心主题：AI 系统自治优化架构师 Agent——在保证财务和安全的前提下，实现 LLM API 的持续自动化路由优化
|
||||
- 问题域：AI 系统运营成本失控风险、多供应商 LLM 的性能评估与自动路由、影子测试与安全护栏
|
||||
- 方法/机制：LLM-as-a-Judge 评分、暗启动（Shadow Traffic）A/B 测试、熔断器（Circuit Breaker）、成本感知路由
|
||||
- 结论/价值：通过数据驱动的自动路由，每年可降低 40%+ 运营成本，同时保持 99.99% 工作流完成率
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据
|
||||
- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型
|
||||
- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环
|
||||
- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
|
||||
- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算
|
||||
- LLM-as-a-Judge 评分必须在实验开始前建立明确的数学评估标准，而非主观判断
|
||||
- 所有实验性自学习和模型测试必须异步执行，以"影子流量"形式不影响生产环境
|
||||
- 提出任何 LLM 架构时必须同时估算主路径和降级路径的每百万 Token 成本
|
||||
- 当端点流量异常激增（500%+）或连续出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
|
||||
- 禁止实现开放式重试循环或无上限 API 调用，每个外部请求必须有严格超时、重试上限和指定降级路径
|
||||
|
||||
## Key Quotes
|
||||
> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格
|
||||
> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语
|
||||
> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念
|
||||
> "Autonomous routing without a circuit breaker is just an expensive bomb." — Agent 核心信条
|
||||
> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Agent 汇报话术
|
||||
> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — Agent 告警话术
|
||||
|
||||
## Key Concepts
|
||||
- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案
|
||||
- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审
|
||||
- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分
|
||||
- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider
|
||||
- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入
|
||||
- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名
|
||||
- [[Circuit-Breaker]]：熔断器模式——当端点连续失败超过阈值时自动切断路由，防止恶意流量耗尽 API 配额
|
||||
- [[LLM-as-a-Judge]]：以一个 LLM 自动评估另一个 LLM 输出的质量，建立数学评分标准（JSON 格式 5 分、延迟 3 分、幻觉 -10 分）
|
||||
- [[Shadow-Traffic]]：暗启动/影子测试——将一小部分真实流量异步路由到实验模型，在不影响生产的前提下验证效果
|
||||
- [[Semantic-Routing]]：语义路由——基于任务类型和历史表现，动态选择最优 LLM 提供商，而非固定路由
|
||||
- [[AI-FinOps]]：AI 财务运维——持续监控和优化 AI 基础设施的每 Token 成本和 ROI
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型
|
||||
- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型
|
||||
- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型
|
||||
- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案
|
||||
- [[OpenAI]]：LLM 提供商之一，Agent 持续追踪其 GPT 系列模型的 Token 成本和延迟表现
|
||||
- [[Anthropic]]：LLM 提供商之一，提供 Claude 系列模型，Agent 将其作为主要基准对比对象
|
||||
- [[Google-Gemini]]：LLM 提供商之一，提供 Gemini Flash 等低成本替代模型，Agent 关注其性价比路由场景
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策）
|
||||
- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆）
|
||||
- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计）
|
||||
- [[Performance-Benchmarker]] ← complements ← [[Autonomous-Optimization-Architect]]
|
||||
- [[Testing-Workflow-Optimizer]] ← extends ← [[Autonomous-Optimization-Architect]]
|
||||
- [[Security-Engineer]] ← addresses ← Token-Draining Attacks
|
||||
- [[Infrastructure-Maintainer]] ← overlaps ← Third-Party API Uptime
|
||||
|
||||
## Contradictions
|
||||
- 与 [[testing-performance-benchmarker]] 冲突：
|
||||
- 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试
|
||||
- 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能
|
||||
- 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声
|
||||
- 与 [[Testing-Tool-Evaluator]] 冲突：
|
||||
- 冲突点：工具评估是人工驱动的一次性研究 vs. 本 Agent 的机器驱动持续 A/B 测试
|
||||
- 当前观点：本 Agent 认为必须通过实时数据持续更新路由表，而非一次性评估报告
|
||||
- 对方观点：工具评估应作为人工决策参考，自动化路由可能引入不可预测风险
|
||||
|
||||
66
wiki/sources/engineering-backend-architect.md
Normal file
66
wiki/sources/engineering-backend-architect.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Backend Architect Agent Personality"
|
||||
type: source
|
||||
tags: [the-agency, engineering, backend, architecture, cloud, database, api]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-backend-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Backend Architect AI Agent 人格定义——专注于可扩展系统设计、数据库架构、API 开发与云基础设施的高级后端架构师
|
||||
- 问题域：如何定义一个能够设计大规模、高可靠、安全可扩展的后端系统和微服务的 AI Agent 角色
|
||||
- 方法/机制：数据模式工程 → 可扩展系统架构 → 系统可靠性保障 → 性能与安全优化，核心方法包括微服务分解、CQRS/ES 模式、数据库索引、熔断器设计
|
||||
- 结论/价值：Backend Architect 输出的系统架构、数据库 Schema、API 规范和监控策略是整个系统可靠运行的基石，属 The Agency Engineering 部门
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 后端架构师必须从一开始就设计水平扩展能力，而非事后补救
|
||||
- 认证和授权系统必须防止常见漏洞，遵循最小权限原则
|
||||
- 数据库查询必须实现子 20ms 性能目标，通过正确的索引和查询优化实现
|
||||
- 系统设计必须包含多层次安全措施（Defense in Depth）和数据加密（静态和传输中）
|
||||
- API 响应时间应始终保持在 200ms 以内（P95）
|
||||
- 系统可用性应超过 99.9%，配合适当的监控和自动扩缩容
|
||||
|
||||
## Key Quotes
|
||||
> "Design for horizontal scaling from the beginning." — 性能意识设计核心理念
|
||||
> "Implement defense in depth strategies across all system layers." — 安全优先架构原则
|
||||
> "Use principle of least privilege for all services and database access." — 最小权限原则
|
||||
> "API response times consistently stay under 200ms for 95th percentile." — 成功指标之一
|
||||
> "Database queries perform under 100ms average with proper indexing." — 数据库性能目标
|
||||
|
||||
## Key Concepts
|
||||
- [[MicroservicesArchitecture]]：微服务架构，支持水平扩展和独立部署，是 Backend Architect 默认推荐的系统分解模式
|
||||
- [[CQRS]]：命令查询职责分离，用于读写不对称的复杂领域（如订单系统）
|
||||
- [[EventSourcing]]：事件溯源，与 CQRS 配合用于复杂业务域的数据建模
|
||||
- [[ServerlessArchitecture]]：无服务器架构，Backend Architect 认可的可自动扩展且成本效益高的云部署方式
|
||||
- [[DatabaseIndexing]]：数据库索引优化，用于实现子 100ms 平均查询性能
|
||||
- [[CircuitBreaker]]：断路器模式，Backend Architect 实现系统可靠性和优雅降级的核心机制
|
||||
- [[DefenseInDepth]]：深度防御策略——跨所有系统层实施多层安全措施
|
||||
- [[Event-DrivenArchitecture]]：事件驱动架构，支持高吞吐量和松耦合的系统间通信
|
||||
- [[API-Versioning]]：API 版本管理，确保向后兼容性和平滑升级
|
||||
- [[HorizontalScaling]]：水平扩展——通过增加服务实例而非单体扩容来实现系统扩展
|
||||
|
||||
## Key Entities
|
||||
- [[SoftwareArchitect]]：同部门兄弟 Agent，专注于系统设计、DDD 和架构模式，与 Backend Architect 共享架构思维
|
||||
- [[MobileAppBuilder]]：同部门兄弟 Agent，接收 Backend Architect 输出的 API 规范进行移动端开发
|
||||
- [[GodotMultiplayerEngineer]]：Game Dev 部门 Agent，与 Backend Architect 共享服务器权威原则和网络架构理念
|
||||
|
||||
## Connections
|
||||
- [[SoftwareArchitect]] ← shares_architecture_principles ← [[BackendArchitectAgent]]（可扩展性、安全性、可靠性是共同核心价值）
|
||||
- [[MobileAppBuilder]] ← depends_on ← [[BackendArchitectAgent]]（API 规范作为下游输入）
|
||||
- [[GodotMultiplayerEngineer]] ← shares_server_authority ← [[BackendArchitectAgent]]（服务器权威是共同网络架构原则）
|
||||
- [[AutonomousOptimizationArchitect]] ← relates_to ← [[BackendArchitectAgent]]（两者都关注系统性能和可靠性优化）
|
||||
- [[SRE]] ← relates_to ← [[BackendArchitectAgent]]（Backend Architect 输出的架构为 SRE 的可靠性工作提供基础）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[backend-architect-with-memory]] 的架构决策方式存在张力：
|
||||
- 冲突点：持久化架构知识的方式
|
||||
- 当前观点（engineering-backend-architect）：通过 System Prompt 和交付物文档（System Architecture Specification、Database Schema、API Design）进行知识传递
|
||||
- 对方观点（backend-architect-with-memory）：通过 MCP Memory 标签化快照持久化，支持跨 Agent 自动召回和回滚
|
||||
- 协调方案：两者互补——文档规范供人类可读和跨团队共享，MCP Memory 快照供 Agent 自动化召回；engineering-backend-architect 是基础角色定义，backend-architect-with-memory 是增强版
|
||||
- 与 [[SoftwareArchitect]] 的抽象层次存在差异：
|
||||
- 冲突点：架构粒度
|
||||
- 当前观点（Backend Architect）：关注数据库 Schema、API 端点、WebSocket 事件、部署拓扑等具体实现细节
|
||||
- 对方观点（Software Architect）：关注领域边界、模式选型、质量属性权衡等抽象层次
|
||||
- 协调方案：Software Architect 负责\"做什么系统\"（What），Backend Architect 负责\"怎么做\"（How）；两者在不同抽象层次工作，互为补充
|
||||
52
wiki/sources/engineering-code-reviewer.md
Normal file
52
wiki/sources/engineering-code-reviewer.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Code Reviewer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-code-reviewer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Code Reviewer AI Agent 人格定义——专注于代码审查与质量保证的专业 AI Agent
|
||||
- 问题域：代码质量保障（正确性、安全性、可维护性、性能）
|
||||
- 方法/机制：分层审查清单（Blocker/Suggestion/Nit 三级优先级）、标准化审查评论格式、教导式反馈风格
|
||||
- 结论/价值：最佳审查教会而非批评，提升代码质量 AND 开发者技能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Code Reviewer 提供构造性、可操作的反馈，聚焦正确性、安全性、可维护性、性能，而非代码风格偏好
|
||||
- 审查重点五大维度：正确性（功能是否符合预期）、安全性（注入/XSS/认证漏洞）、可维护性（六个月后是否可理解）、性能（瓶颈/N+1查询）、测试（重要路径是否覆盖）
|
||||
- 审查评论必须具体化：指出具体行号和机制，而非泛泛说"有安全问题"
|
||||
- 必须解释原因：不仅说改什么，还要说为什么
|
||||
- 建议而非要求：用"考虑使用X因为Y"而非"改成X"
|
||||
- 标记优先级：🔴 blocker（必须修复）、🟡 suggestion（应该修复）、💭 nit（锦上添花）
|
||||
- 赞美好代码：指出聪明的解决方案和干净的模式
|
||||
- 一次审查完整反馈：不要多轮滴水式评论
|
||||
|
||||
## Key Quotes
|
||||
> "Reviews code like a mentor, not a gatekeeper. Every comment teaches something." — Code Reviewer 核心理念
|
||||
|
||||
> "🔴 Security: SQL Injection Risk — Line 42: User input is interpolated directly into the query. Why: An attacker could inject `'; DROP TABLE users; --`. Suggestion: Use parameterized queries." — 标准化审查评论格式示例
|
||||
|
||||
## Key Concepts
|
||||
- [[CodeReview]]: 代码审查的核心概念——通过系统性检查提升代码质量的过程
|
||||
- [[SecurityAudit]]: 安全审查维度——注入、XSS、认证绕过等漏洞检测
|
||||
- [[PerformanceProfiling]]: 性能分析——N+1查询、不必要内存分配等瓶颈识别
|
||||
- [[Mentorship]]: 教导式反馈——审查即教学，每次评论都有教育意义
|
||||
- [[ReviewChecklist]]: 审查清单——结构化的三层优先级体系（Blocker/Suggestion/Nit）
|
||||
|
||||
## Key Entities
|
||||
- [[CodeReviewerAgent]]: Code Reviewer AI Agent 本身——代码审查与质量保证专家
|
||||
|
||||
## Connections
|
||||
- [[SoftwareArchitect]] ← informs → [[CodeReviewerAgent]]：架构决策影响审查重点
|
||||
- [[BackendArchitect]] ← depends_on → [[CodeReviewerAgent]]：后端实现依赖代码审查保障质量
|
||||
- [[SeniorDeveloper]] ← extends → [[CodeReviewerAgent]]：资深开发者兼具审查职责
|
||||
- [[QualityGate]] ← implements → [[CodeReviewerAgent]]：质量门控的自动化实现依赖审查标准
|
||||
|
||||
## Contradictions
|
||||
- 与纯风格审查工具（如 linter）的冲突：
|
||||
- 冲突点：风格工具负责格式化，Code Reviewer 负责人工判断
|
||||
- 当前观点：Code Reviewer 明确拒绝审查风格偏好（"not tabs vs spaces"），将风格交给 linter
|
||||
- 对方观点：某些团队要求审查者确保代码风格一致
|
||||
47
wiki/sources/engineering-codebase-onboarding-engineer.md
Normal file
47
wiki/sources/engineering-codebase-onboarding-engineer.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Codebase Onboarding Engineer"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-codebase-onboarding-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 角色定义，帮助新开发者快速理解陌生代码库的专业引导者
|
||||
- 问题域：开发者 onboarding 效率、代码库结构理解、代码路径追踪
|
||||
- 方法/机制：通过读取源码、追踪执行路径、仅陈述有代码依据的事实来构建准确的心智模型
|
||||
- 结论/价值：让新开发者 5 分钟内找到主入口点，缩短 onboarding 时间
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agent 必须在代码中能找到证据时才陈述模块拥有某行为
|
||||
- 永远只陈述有源码支撑的事实，不推理、不假设、不猜测
|
||||
- 解释必须分三个层次：一句话概述 → 五分钟高层解释 → 深度代码流分析
|
||||
- 严格保持只读模式，绝不修改文件或生成补丁
|
||||
|
||||
## Key Quotes
|
||||
> "Never state that a module owns behavior unless you can point to the file(s) that implement or route it." — 证据优先原则
|
||||
> "If something is not visible in the code you inspected, do not state it." — 诚实告知检查范围
|
||||
> "State only facts grounded in the code that was actually inspected." — 事实唯一准则
|
||||
|
||||
## Key Concepts
|
||||
- [[CodebaseOnboarding]]：帮助新开发者快速理解陌生代码库的方法论和实践
|
||||
- [[ExecutionTracing]]：追踪请求、事件、命令在系统中的完整执行路径
|
||||
- [[EvidenceFirstReasoning]]：只陈述代码中可验证的事实，不进行推理或假设
|
||||
- [[MentalModel]]：为开发者构建准确、可理解的项目结构心智模型
|
||||
- [[ThreeTierExplanation]]：一/五/深的分层解释结构
|
||||
|
||||
## Key Entities
|
||||
- （本文档为纯 Agent 角色定义，未涉及具体人物或公司实体）
|
||||
|
||||
## Connections
|
||||
- [[EngineeringMinimalChangeEngineer]] ← related_to ← [[CodebaseOnboardingEngineer]]
|
||||
- [[EngineeringSeniorDeveloper]] ← related_to ← [[CodebaseOnboardingEngineer]]
|
||||
- [[EngineeringCodeReviewer]] ← related_to ← [[CodebaseOnboardingEngineer]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[EngineeringMinimalChangeEngineer]] 侧重点不同：
|
||||
- Codebase Onboarding Engineer 专注快速理解代码库结构
|
||||
- Minimal Change Engineer 专注最小改动实现目标
|
||||
- 两者互补：一个帮助理解，一个指导改动
|
||||
57
wiki/sources/engineering-data-engineer.md
Normal file
57
wiki/sources/engineering-data-engineer.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Data Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[../../../../../Workspace/nexus/raw/Agent/agency-agents/engineering/engineering-data-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Data Engineer Agent 个性定义——构建可靠、可观测、自愈的数据管道和 Lakehouse 架构的专业 Agent
|
||||
- 问题域：如何将原始、混乱、来自多种来源的数据转化为可靠的、高质量的、可分析的数据资产，并保证准时、按规模、全程可观测
|
||||
- 方法/机制：Medallion Architecture（Bronze→Silver→Gold）、PySpark+Delta Lake ETL/ELT、dbt 数据质量契约、Great Expectations 质量验证、Kafka 流式处理、CDC 增量摄取
|
||||
- 结论/价值：Data Engineer Agent 的核心价值在于将数据可靠性作为产品交付，通过 Medallion 分层架构确保 Bronze=原始不可变、Silver=清洗去重、Gold=业务就绪，并通过 SLA 监控、沿袭追踪、数据目录实现全栈可观测性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Data Engineer Agent 通过 Medallion Architecture（Bronze→Silver→Gold）分层设计，实现了数据质量从原始到业务就绪的渐进式提升
|
||||
- Data Engineer Agent 要求所有管道必须幂等（idempotent）—— 重新运行产生相同结果，永不产生重复数据
|
||||
- Data Engineer Agent 通过 CDC（Change Data Capture）和增量管道设计，将全量刷新成本降低 90% 以上
|
||||
- Data Engineer Agent 通过 Great Expectations 实现行级数据质量评分，确保 Gold 层数据达到 SLA 保证
|
||||
- Data Engineer Agent 通过 Apache Kafka 实现 Exactly-Once 语义和延迟到达数据处理，平衡流式与微批次的成本-延迟权衡
|
||||
|
||||
## Key Quotes
|
||||
> "Bronze = raw, immutable, append-only; never transform in place" — Medallion Architecture Bronze 层核心原则
|
||||
> "All pipelines must be idempotent — rerunning produces the same result, never duplicates" — 管道可靠性第一准则
|
||||
> "Null handling must be deliberate — no implicit null propagation into gold/semantic layers" — Silver→Gold 层 null 值处理规范
|
||||
> "Data in gold/semantic layers must have row-level data quality scores attached" — Gold 层数据质量强制要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Medallion Architecture]]：Bronze（原始只读）→ Silver（清洗去重）→ Gold（业务聚合）的三层数据湖仓架构，每层有明确的转换规则和 SLA
|
||||
- [[CDC (Change Data Capture)]]：通过变更数据捕获实现增量管道，相比全量刷新可节省 90%+ 计算成本
|
||||
- [[Data Contract]]：数据生产者和消费者之间的明确 schema 契约，schema 漂移必须触发告警而非静默损坏
|
||||
- [[Data Lineage]]：数据沿袭追踪——每一行数据都能追溯到其来源系统
|
||||
- [[SCD Type 2]]：Slowly Changing Dimension Type 2，实现历史维度变更追踪
|
||||
|
||||
## Key Entities
|
||||
- [[Apache Spark]]：大规模并行处理引擎，Data Engineer Agent 的核心计算平台
|
||||
- [[Delta Lake]]：开放表格格式，提供 ACID 事务、时间旅行和 Z-Ordering 等能力
|
||||
- [[dbt]]：数据转换和质量管理工具，Data Engineer Agent 用于定义数据质量契约
|
||||
- [[Great Expectations]]：数据质量验证框架，Data Engineer Agent 用于行级数据质量评分
|
||||
- [[Apache Kafka]]：事件流平台，Data Engineer Agent 用于构建 Exactly-Once 语义的实时管道
|
||||
- [[Databricks]]：Lakehouse 平台（Unity Catalog、DLT），Data Engineer Agent 的主要托管环境之一
|
||||
- [[Snowflake]]：云数据仓库，Data Engineer Agent 的另一主要数据平台
|
||||
- [[Apache Iceberg]]：开放表格格式规范，Data Engineer Agent 用于跨引擎互操作
|
||||
|
||||
## Connections
|
||||
- [[Apache Spark]] ← builds_with ← [[Delta Lake]]
|
||||
- [[dbt]] ← validates ← [[Apache Spark]]
|
||||
- [[Apache Kafka]] ← streams_to ← [[Delta Lake]]
|
||||
- [[Great Expectations]] ← enforces ← [[Data Contract]]
|
||||
- [[Databricks]] ← hosts ← [[Apache Spark]], [[Delta Lake]]
|
||||
- [[Medallion Architecture]] ← implements ← [[Data Lineage]]
|
||||
- [[CDC (Change Data Capture)]] ← enables ← [[Medallion Architecture]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。Data Engineer Agent 与 SRE Agent（[[engineering-sre]]）在数据管道 SLA 监控（告警响应）层面高度互补，Data Engineer 负责管道内部可观测性，SRE 负责整体服务可靠性。
|
||||
50
wiki/sources/engineering-database-optimizer.md
Normal file
50
wiki/sources/engineering-database-optimizer.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Database Optimizer Agent Personality"
|
||||
type: source
|
||||
tags: [database, postgresql, mysql, performance, optimization, sql, backend, supabase, planetscale]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-database-optimizer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Database Optimizer 是一个专注于数据库性能优化的 Agent 人格定义
|
||||
- 问题域：Schema 设计、查询优化、索引策略、连接池管理、零停机迁移
|
||||
- 方法/机制：使用 EXPLAIN ANALYZE 分析查询计划；采用 B-tree/GiST/GIN/部分索引策略；通过 CONCURRENTLY 创建索引避免表锁；使用连接池防止连接泄漏
|
||||
- 结论/价值：提供可在生产环境直接使用的 SQL 模板和 TypeScript 代码示例，涵盖 PostgreSQL、MySQL、Supabase 和 PlanetScale
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Database Optimizer 专注于 PostgreSQL 优化和高级特性，通过 EXPLAIN ANALYZE 解释查询计划来识别 Seq Scan（差）、Index Scan（好）、Bitmap Heap Scan（可接受）
|
||||
- Database Optimizer 采用多种索引策略（B-tree、GiST、GIN、部分索引、复合索引）针对不同查询模式进行性能优化
|
||||
- Database Optimizer 通过使用 CONCURRENTLY 创建索引来确保生产环境零停机，避免表锁
|
||||
- Database Optimizer 通过连接池化（PgBouncer、Supabase pooler）防止连接泄漏，支持事务模式和会话模式
|
||||
- Database Optimizer 通过单次 JOIN 查询替代 N+1 循环查询来消除性能瓶颈，使用 json_agg 聚合嵌套数据
|
||||
|
||||
## Key Quotes
|
||||
> "Build database architectures that perform well under load, scale gracefully, and never surprise you at 3am." — Database Optimizer 核心使命宣言
|
||||
> "Every query has a plan, every foreign key has an index, every migration is reversible, and every slow query gets optimized." — Database Optimizer 核心原则
|
||||
> "Use CONCURRENTLY for indexes — never lock tables in production." — 安全迁移规则
|
||||
|
||||
## Key Concepts
|
||||
- [[QueryPlanAnalysis]]：使用 EXPLAIN ANALYZE 分析查询计划，识别 Seq Scan、Index Scan、Bitmap Heap Scan，理解 actual time vs planned time 的差异
|
||||
- [[IndexingStrategies]]：B-tree（等值/范围查询）、GiST（几何/全文搜索）、GIN（JSON/数组）、部分索引（高频过滤条件）、复合索引（多列过滤+排序）
|
||||
- [[N1QueryPrevention]]：通过 JOIN + json_agg 聚合替代循环查询，消除 N+1 问题
|
||||
- [[ConnectionPooling]]：PgBouncer 和 Supabase pooler 防止连接耗尽，支持事务模式和会话模式
|
||||
- [[SafeMigrations]]：CONCURRENTLY 创建索引、使用可逆迁移、避免生产环境表锁
|
||||
- [[SchemaDesign]]：规范化 vs 反规范化的权衡，foreign key 必须加索引
|
||||
|
||||
## Key Entities
|
||||
- [[PostgreSQL]]：主要支持的数据库引擎，提供 EXPLAIN ANALYZE、部分索引、CONCURRENTLY 等高级特性
|
||||
- [[MySQL]]：支持的数据库之一，语法和特性与 PostgreSQL 有差异
|
||||
- [[Supabase]]：开源 Firebase 替代品，提供内置连接池和实时订阅
|
||||
- [[PlanetScale]]：MySQL 兼容的无服务器数据库，支持分支和非阻塞模式变更
|
||||
- [[PgBouncer]]：轻量级 PostgreSQL 连接池工具，支持事务模式和会话模式
|
||||
- [[BIGSERIAL]]：PostgreSQL 主键类型，等价于 BIGINT + AUTO_INCREMENT
|
||||
|
||||
## Connections
|
||||
- [[engineering-backend-architect]] ← extends ← [[engineering-database-optimizer]]（后端架构师依赖数据库优化专家的设计原则）
|
||||
- [[engineering-sre]] ← depends_on ← [[engineering-database-optimizer]]（SRE 需要理解数据库性能调优）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
54
wiki/sources/engineering-devops-automator.md
Normal file
54
wiki/sources/engineering-devops-automator.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "DevOps Automator Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-devops-automator.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps Automator — 专注于基础设施自动化、CI/CD 流水线开发和云运营的专业 DevOps 工程师 Agent
|
||||
- 问题域：消除手动运维流程、提升系统可靠性、实现可扩展的部署策略
|
||||
- 方法/机制：基础设施即代码（Terraform）、CI/CD 流水线自动化（GitHub Actions/Jenkins/GitLab CI）、容器编排（Docker/Kubernetes）、监控告警（Prometheus/Grafana）、零停机部署策略（蓝绿/金丝雀/滚动）
|
||||
- 结论/价值：通过全面的自动化提升部署频率、降低 MTTR、保障 99.9% 可用性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps Automator 通过基础设施即代码和 CI/CD 流水线自动化，消除手动部署流程，实现每日多次部署
|
||||
- DevOps Automator 通过零停机部署策略（蓝绿、金丝雀、滚动部署）配合自动回滚，保障服务持续可用
|
||||
- DevOps Automator 通过 Prometheus + Grafana 监控体系，在问题影响用户之前主动发现并告警
|
||||
- DevOps Automator 通过安全扫描自动化和 secrets 管理集成，将安全内嵌到交付管线的每个阶段
|
||||
|
||||
## Key Quotes
|
||||
> "Eliminate manual processes through comprehensive automation" — 核心理念：一切皆自动化
|
||||
> "Built monitoring and alerting to catch problems before they affect users" — 预防优于修复
|
||||
> "Self-healing systems with automated recovery" — 自愈系统设计目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Infrastructure as Code]]：通过 Terraform/CloudFormation/CDK 用代码管理云基础设施，实现版本控制和可重复部署
|
||||
- [[CI/CD Pipeline]]：自动化代码构建、测试、部署的端到端流水线，确保每次变更都可追溯
|
||||
- [[Zero-Downtime Deployment]]：蓝绿部署、金丝雀发布、滚动更新等策略，保证服务在更新期间持续可用
|
||||
- [[Observability]]：通过指标、日志、追踪三位一体的可观测性体系，全面了解系统状态
|
||||
- [[Self-Healing System]]：自动检测故障并触发恢复机制，无需人工干预
|
||||
|
||||
## Key Entities
|
||||
- [[Terraform]]：HashiCorp 基础设施即代码工具，用于声明式管理云资源
|
||||
- [[Kubernetes]]：容器编排平台，负责容器化应用的自动化部署、扩缩容和管理
|
||||
- [[GitHub Actions]]：CI/CD 平台，用于自动化构建、测试和部署工作流
|
||||
- [[Prometheus]]：开源监控系统，负责指标采集和告警
|
||||
- [[Grafana]]：可视化平台，与 Prometheus 集成展示监控仪表板
|
||||
- [[Blue-Green Deployment]]：零停机部署策略，通过两套环境切换实现无缝更新
|
||||
|
||||
## Connections
|
||||
- [[DevOps Automator]] ← extends ← [[Infrastructure as Code]]
|
||||
- [[DevOps Automator]] ← extends ← [[CI/CD Pipeline]]
|
||||
- [[DevOps Automator]] ← depends_on ← [[Kubernetes]]
|
||||
- [[DevOps Automator]] ← depends_on ← [[Prometheus]] ← extends ← [[Observability]]
|
||||
|
||||
## Contradictions
|
||||
- 与 SRE Engineering Agent（engineering-sre，源文件待摄入）可能存在张力：
|
||||
- 冲突点：DevOps Automator 强调完全自动化消除人工干预，SRE 强调人工 on-call 和事后复盘的不可替代性
|
||||
- 当前观点（DevOps Automator）：优先自动化所有可自动化流程，减少人工干预，提升部署频率
|
||||
- 对方观点（SRE）：在复杂故障场景下人工判断不可替代，MTTR 降低依赖自动化但 SLO/SLI 设计需要人工评估
|
||||
- 状态：待 engineering-sre 摄入后进一步确认冲突细节
|
||||
59
wiki/sources/engineering-email-intelligence-engineer.md
Normal file
59
wiki/sources/engineering-email-intelligence-engineer.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Email Intelligence Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-email-intelligence-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：Email Intelligence Engineer — 将原始邮件数据转换为 AI Agent 可消费的、结构化的推理上下文的专业 Agent 角色定义
|
||||
- **问题域**：邮件的结构复杂性（引用文本重复、转发链折叠、线程分叉、第一人称歧义）导致传统 RAG/Context 方式无法正确理解邮件对话
|
||||
- **方法/机制**：四步处理管道——①邮件摄取与标准化 → ②线程重建与去重 → ③结构化分析（参与者图、决策时间线、行动项归因） → ④上下文组装与工具接口
|
||||
- **结论/价值**：通过保留线程拓扑结构 + 引用去重 + 参与者绑定，使 Agent 在邮件数据上的下游任务准确率提升 20%+
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Email Intelligence Engineer 通过线程重建保留对话拓扑结构，使 Agent 能够正确理解邮件上下文，避免将多轮对话扁平化为单文档导致的信息错位
|
||||
- 通过引用文本去重技术，将原始线程 Token 量压缩 4-5 倍，同时保证零信息丢失，显著降低 LLM 上下文成本
|
||||
- 通过参与者绑定机制（From: header 级别归因），确保行动项归因于正确的发送者，解决扁平化线程中第一人称代词歧义问题
|
||||
- 通过混合检索（语义搜索 + 全文搜索 + 元数据过滤器）实现精准邮件片段召回，结合 Token 预算管理生成带来源引用的结构化输出
|
||||
- LangChain / CrewAI / LlamaIndex / MCP Server 是该 Agent 的核心集成目标，使邮件智能能力可被主流 Agent 框架直接消费
|
||||
|
||||
## Key Quotes
|
||||
> "Never treat a flattened email thread as a single document. Thread topology matters." — 核心设计原则：线程拓扑结构不可丢失
|
||||
> "Quoted reply duplication inflated the thread from 11K to 47K tokens. Deduplication brought it back to 12K with zero information loss." — 引用去重的量化价值
|
||||
> "The action items were attributed to the wrong people because the flattened thread stripped From: headers. Without participant binding at the message level, every first-person pronoun is ambiguous." — 参与者绑定的必要性
|
||||
|
||||
## Key Concepts
|
||||
- [[Thread-Reconstruction]]：通过 In-Reply-To 和 References 头链重建邮件对话拓扑图，处理转发链折叠、线程分叉等复杂场景
|
||||
- [[Content-Deduplication]]：引用文本去重——移除邮件正文中对父消息的引用内容（支持 `>` 前缀引用、`---Original Message---` 分隔符、Outlook XML 嵌套引用等多种风格），典型压缩比 4-5x
|
||||
- [[Participant-Detection]]：参与者检测与角色推断——从 From/To/CC/BCC 提取参与者、标准化显示名、推断角色、分析回复频率
|
||||
- [[Action-Item-Attribution]]：行动项归因——将承诺/任务绑定到正确的消息发送者，而非依赖第一人称代词
|
||||
- [[Hybrid-Retrieval]]：混合检索——结合语义相似度搜索、全文关键词搜索和元数据过滤器（日期范围、参与者、附件类型等）
|
||||
- [[Context-Assembly]]：上下文组装——在 Token 预算内按相关性组装上下文，生成带消息级别来源引用的结构化 JSON 输出
|
||||
- [[PII-Redaction]]：PII 检测与脱敏作为管道前置阶段，而非后期补救
|
||||
- [[Decision-Through-Silence]]：沉默决策检测——当提案未收到反对且后续消息将其视为已确定时，识别为隐式决策
|
||||
|
||||
## Key Entities
|
||||
- [[LangChain]]：该 Agent 通过 `@tool` 装饰器提供 LangChain 工具接口，使邮件查询和搜索能力可被 LangChain Agent 直接调用
|
||||
- [[CrewAI]]：该 Agent 的输出格式支持 CrewAI 的 Task 和 Agent 模式，提供结构化的邮件上下文输入
|
||||
- [[LlamaIndex]]：该 Agent 的邮件读取器（Readers）能力可集成到 LlamaIndex 数据管道中
|
||||
|
||||
## Connections
|
||||
- [[LangChain]] ← provides_tools ← [[Email-Intelligence-Engineer]]（通过 `@tool` 装饰器暴露邮件查询/搜索工具）
|
||||
- [[CrewAI]] ← provides_tools ← [[Email-Intelligence-Engineer]]（结构化输出适配 CrewAI Task 模式）
|
||||
- [[LlamaIndex]] ← integrates ← [[Email-Intelligence-Engineer]]（邮件读取器集成）
|
||||
- [[Thread-Reconstruction]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 2
|
||||
- [[Content-Deduplication]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 2
|
||||
- [[Hybrid-Retrieval]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 4
|
||||
- [[Context-Assembly]] ← is_component_of ← [[Email-Intelligence-Engineer]] Pipeline Step 4
|
||||
- [[Email-Intelligence-Engineer]] ← extends ← [[RAG]]（在邮件领域的 RAG 增强，解决邮件特有的结构复杂性）
|
||||
- [[Email-Intelligence-Engineer]] ← provides_context_for ← [[Agentic-AI]]（为 Agent 系统提供邮件领域的推理上下文）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[RAG]] 通用实现存在差异：
|
||||
- **冲突点**：传统 RAG 将文档视为原子单元，而邮件是具有拓扑结构的对话序列
|
||||
- **当前观点**：Email Intelligence Engineer 主张邮件必须保留线程拓扑，消息级别的 From: header 必须被保留用于参与者绑定
|
||||
- **对方观点**：通用 RAG 系统通常将邮件线程扁平化为单一文档进行检索，仅关注内容匹配而非对话结构
|
||||
55
wiki/sources/engineering-embedded-firmware-engineer.md
Normal file
55
wiki/sources/engineering-embedded-firmware-engineer.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Embedded Firmware Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-embedded-firmware-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency 旗下的嵌入式固件工程师 Agent 人格定义，专注于资源受限嵌入式系统的生产级固件开发
|
||||
- 问题域：MCU 选型（ESP32/STM32/Nordic nRF）、裸机与 RTOS 固件架构、外设驱动可靠性、通信协议实现、OTA 升级
|
||||
- 方法/机制：FreeRTOS 任务架构设计（队列/信号量/事件组）、静态内存分配优先、ISR 最小化原则、平台差异化实践（ESP-IDF / STM32 LL/HAL / Nordic Zephyr）
|
||||
- 结论/价值：交付零栈溢出、ISR 延迟可测量、Flash/RAM 使用可文档化、生产级可靠固件
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- RTOS 任务中禁止动态分配（malloc/new），必须使用静态分配或内存池
|
||||
- ISR 必须最小化——通过队列或信号量将工作延迟到任务处理
|
||||
- 栈大小必须计算而非猜测，使用 `uxTaskGetStackHighWaterMark()` 验证
|
||||
- STM32 时序关键代码优先使用 LL 驱动而非 HAL
|
||||
- Nordic 平台使用 Zephyr devicetree 和 Kconfig，禁止硬编码外设地址
|
||||
- PlatformIO 生产环境 `platformio.ini` 必须锁定库版本，禁止使用 `@latest`
|
||||
|
||||
## Key Quotes
|
||||
> "ISRs must be minimal — defer work to tasks via queues or semaphores" — ISR 设计核心原则，强制最小化中断处理路径
|
||||
> "Stack sizes must be calculated, not guessed — use `uxTaskGetStackHighWaterMark()`" — 栈大小验证规范，防止生产环境栈溢出
|
||||
> "Never use dynamic allocation (`malloc`/`new`) in RTOS tasks after init" — RTOS 内存安全铁律，消除堆碎片风险
|
||||
|
||||
## Key Concepts
|
||||
- [[FreeRTOS]]：开源 RTOS，ESP-IDF/Nordic Zephyr 均基于此实现多任务调度，提供队列/信号量/事件组等 IPC 机制
|
||||
- [[ARM-Cortex-M]]：嵌入式 MCU 主流架构，ESP32/STM32/Nordic nRF 均基于此系列
|
||||
- [[ESP-IDF]]：乐鑫官方 ESP32 开发框架，包含 Wi-Fi/BLE 驱动、OTA、文件系统等组件
|
||||
- [[STM32-HAL-LL]]：STM32 的两套驱动层——HAL 通用但时序差，LL 轻量且时序精确
|
||||
- [[Nordic-nRF]]：Nordic 半导体低功耗蓝牙 SoC 系列，使用 Zephyr RTOS 和 nRF Connect SDK
|
||||
- [[Zephyr-RTOS]]：Linux 基金会托管的开源 RTOS，Nordic/Zephyr 生态核心，支持 devicetree 和 Kconfig
|
||||
- [[OTA-Upgrade]]：空中固件升级，ESP-IDF/STM32 自定义 bootloader/MCUboot 各有实现路径
|
||||
|
||||
## Key Entities
|
||||
- [[ESP32]]：乐鑫 Wi-Fi+BLE SoC，[[ESP-IDF]] 目标平台，固件 OTA 升级主力芯片
|
||||
- [[STM32]]：STMicroelectronics MCU 系列，[[STM32-HAL-LL]] 驱动层，面向工业传感/控制场景
|
||||
- [[Nordic-nRF]]：Nordic 蓝牙 SoC，面向可穿戴/IoT 低功耗应用
|
||||
- [[PlatformIO]]：跨平台嵌入式开发环境，支持 ESP32/STM32/Nordic，统一 `platformio.ini` 配置
|
||||
- [[FreeRTOS]]：嵌入式 RTOS，内核被 ESP-IDF 和 Zephyr 引用，提供任务调度和 IPC
|
||||
|
||||
## Connections
|
||||
- [[engineering-backend-architect]] ← uses → [[FreeRTOS]] — 后端架构师使用消息队列，嵌入式固件工程师设计 FreeRTOS 队列作为 IPC
|
||||
- [[engineering-software-architect]] ← informs → [[ARM-Cortex-M]] — 软件架构师了解硬件抽象，固件工程师精通 MCU 底层
|
||||
|
||||
## Contradictions
|
||||
- 与 [[engineering-rapid-prototyper]] 的速度哲学对比：
|
||||
- 冲突点：快速原型是否允许技术债
|
||||
- 当前观点：固件工程师禁止使用 malloc/动态分配、不允许 `platformio.ini` 使用 `@latest`，强制稳定优先
|
||||
- 对方观点：Rapid Prototyper 允许先跑通再优化，接受短期技术债换取速度
|
||||
- 协调方案：固件层严格执行规范，上层应用层（Web/移动）可适度使用快速原型
|
||||
57
wiki/sources/engineering-feishu-integration-developer.md
Normal file
57
wiki/sources/engineering-feishu-integration-developer.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Feishu Integration Developer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-feishu-integration-developer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：飞书（Feishu/Lark）开放平台全栈集成专家，专注于企业 OA 审批、数据管理、团队协作和业务通知在飞书生态内的实现。
|
||||
- 问题域：企业级飞书生态集成开发，包括自定义机器人、交互式消息卡片、审批流自动化、Bitable 多维表格、SSO/OIDC 认证和飞书小程序。
|
||||
- 方法/机制：通过官方 SDK（`oapi-sdk-nodejs` / `oapi-sdk-python`）调用飞书 API；TokenManager 实现 tenant/user_access_token 缓存；EventDispatcher 处理事件订阅签名验证；CardBuilder 构建交互式卡片 JSON；BitableClient 实现表格记录的 CRUD 与批量同步。
|
||||
- 结论/价值：提供企业级协作自动化解决方案，核心理念是"飞书集成不只是调用 API"，涉及权限模型、事件幂等性、多租户架构和与内部系统的深度集成。交付物涵盖完整项目结构、Token 管理、卡片构建、事件分发、审批流、Bitable 操作和 OAuth 登录六大模块。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 飞书集成工程师必须区分 `tenant_access_token` 和 `user_access_token` 的适用场景——前者用于应用级别操作，后者用于用户个人数据和授权操作。
|
||||
- 所有 API 响应必须检查 `code` 字段，`code != 0` 时执行错误处理和日志记录，而非默认成功。
|
||||
- 事件处理必须实现幂等性——飞书可能重复投递同一事件（网络重试机制），重复处理会导致数据不一致。
|
||||
- 消息卡片 JSON 必须在本地验证后再发送，飞书对格式敏感，渲染失败会阻塞业务流程。
|
||||
- Bitable 批量写入每请求最多 500 条记录，超出必须分批并建议批次间添加 200ms 延迟以避免限流。
|
||||
- `app_secret` 和 `encrypt_key` 必须存放在环境变量或密钥管理服务中，前端代码禁止硬编码。
|
||||
|
||||
## Key Quotes
|
||||
> "Feishu integration is not just 'calling APIs' — it involves permission models, event subscriptions, data security, multi-tenant architecture, and deep integration with enterprise internal systems." — 核心身份定义
|
||||
|
||||
> "Don't do heavy processing inside the event callback — return 200 first, then handle asynchronously. Feishu will retry if it doesn't get a response within 3 seconds, and you might receive duplicate events." — 事件处理最佳实践
|
||||
|
||||
> "Bitable batch writes are limited to 500 records per request — anything over that needs to be batched. Also watch out for concurrent writes triggering rate limits; I recommend adding a 200ms delay between batches." — 数据同步性能警告
|
||||
|
||||
## Key Concepts
|
||||
- [[Tenant-Access-Token]]：应用级别访问令牌，用于不涉及特定用户的操作，需缓存并提前5分钟刷新以避免边界问题。
|
||||
- [[User-Access-Token]]：用户级别 OAuth 令牌，通过授权码流程获取，代表用户身份执行操作，需安全存储和刷新。
|
||||
- [[Message-Card]]：飞书交互式卡片，基于 JSON 结构定义，支持按钮、日期选择器、下拉菜单等交互元素，通过 `message_id` 可更新已发送卡片内容。
|
||||
- [[Event-Subscription]]：飞书事件订阅机制，支持 Bot 消息接收、审批状态变更等事件，必须验证签名或解密 encrypt key，返回 200 状态码避免重试。
|
||||
- [[Bitable]]：飞书多维表格，支持表格记录的增删改查、字段管理、视图切换和数据双向同步，适合作为企业数据的中转层。
|
||||
- [[OAuth-2-0-Feishu]]：飞书网页应用自动登录授权流程，包含 authorize 重定向 → callback code 交换 → user_info 获取三步，必须验证 state 参数防止 CSRF。
|
||||
- [[Idempotency]]：事件处理幂等性设计——飞书可能重复投递同一事件（超时重试），处理逻辑必须能正确处理重复消息而不产生副作用。
|
||||
|
||||
## Key Entities
|
||||
- [[LarkSuite-API-SDK]]（`@larksuiteoapi/node-sdk` / `oapi-sdk-python`）：飞书官方 SDK，推荐使用而非手动构造 HTTP 请求，内置 token 缓存。
|
||||
- [[Feishu-Open-Platform]]：飞书开放平台，提供 Bot、审批、Bitable、小程序、SSO 等企业集成能力，需在平台创建应用并配置权限范围。
|
||||
- [[Feishu-Card-Builder]]：飞书官方卡片构建工具，支持可视化预览交互式卡片 JSON，发布前必须通过工具验证卡片渲染。
|
||||
|
||||
## Connections
|
||||
- [[Engineering-Backend-Architect]] ← 依赖 → [[Feishu-Integration-Developer]]：后端架构师设计系统拓扑，飞书集成开发者在其架构内实现消息通知和数据同步模块。
|
||||
- [[Engineering-Software-Architect]] ← extends → [[Feishu-Integration-Developer]]：软件架构师定义系统边界和集成模式，飞书集成开发者遵循其架构决策构建具体集成模块。
|
||||
- [[Testing-API-Tester]] ← 验证 → [[Feishu-Integration-Developer]]：API 测试专家验证飞书 API 调用的正确性、限流处理和错误恢复能力。
|
||||
- [[Engineering-SRE]] ← 监控 → [[Feishu-Integration-Developer]]：SRE 工程师配置 token 获取失败、API 调用错误、事件处理超时等监控告警。
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Engineering-Rapid-Prototyper]] 存在速度哲学张力：
|
||||
- 冲突点：Rapid Prototyper 追求"3天交付 MVP"的速度优先哲学，允许技术债；飞书集成要求"必须实现幂等性、必须检查 code 字段、必须缓存 token"等严格工程标准。
|
||||
- 当前观点：生产级企业集成必须遵守飞书 API 规范（幂等性/错误处理/token 缓存），否则在事件重试和高并发场景下会产生数据不一致。
|
||||
- 对方观点：原型阶段可简化 token 管理和错误处理以加快交付速度。
|
||||
- 协调方式：在原型验证阶段使用 Rapid Prototyper 快速验证业务假设，生产化阶段再由飞书集成开发者补充完整错误处理和幂等性保障。
|
||||
52
wiki/sources/engineering-filament-optimization-specialist.md
Normal file
52
wiki/sources/engineering-filament-optimization-specialist.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Filament Optimization Specialist Agent Personality"
|
||||
type: source
|
||||
tags: ["filament-php", "admin-panel", "structural-optimization", "ux", "laravel"]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-filament-optimization-specialist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Filament PHP 管理后台的结构性优化专家 Agent人格定义
|
||||
- 问题域：Filament PHP admin panel 的 UX 改进，专注于高影响力的结构性改变而非表面装饰
|
||||
- 方法/机制：结构优化层次体系（Tab 分隔 → 并排 Grid → Range Slider 替换 → 可折叠区块 → Repeater 标签 → Summary 占位符 → 导航分组）、输入替换规则、克制规则（噪音控制）
|
||||
- 结论/价值：将"能用"的管理表单转化为"令人愉悦"的体验，通过信息架构重组显著减少操作步骤和视觉噪音
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 结构优化（Tab、Grid、Collapsible）比装饰性改进（图标、提示文字）价值高 10 倍
|
||||
- 超过 8 个字段的扁平表单必须提出 Tab 或并排布局方案
|
||||
- 1-10 个 radio button 行是 UX 反模式，必须替换为 range slider 或紧凑的 inline radio grid
|
||||
- 所有 Repeater 必须设置 `->itemLabel()` 使条目在列表中可识别
|
||||
- 噪音控制优先于装饰：每个字段最多一个引导层，不堆叠 label + hint + placeholder + description
|
||||
|
||||
## Key Quotes
|
||||
> "Transform Filament PHP admin panels from functional to exceptional through **structural redesign**. Cosmetic improvements (icons, hints, labels) are the last 10% — the first 90% is about information architecture." — 核心使命阐述
|
||||
> "Never leave a form with more than ~8 fields in a single flat list without proposing a structural alternative" — 结构性阈值规则
|
||||
> "In a single screen, avoid adding icons to every section. Reserve icons for top-level tabs or high-salience sections." — 图标克制原则
|
||||
|
||||
## Key Concepts
|
||||
- [[StructuralOptimization]]：通过 Tab 分隔、并排 Grid、可折叠区块等手段重构表单信息架构，而非装饰性改进
|
||||
- [[FilamentPHP]]：Laravel 的 TALL Stack 管理后台框架，FilamentOptimizationAgent 的优化目标
|
||||
- [[RangeSliderReplacement]]：将 1-10 个 radio button 行替换为原生 range slider 的 UX 改进模式
|
||||
- [[RepeaterItemLabel]]：为 Repeater 组件设置 `->itemLabel()` 使条目在列表中可识别的实践
|
||||
- [[CollapsibleSection]]：默认折叠的次要表单区块，减少视觉噪音
|
||||
- [[NavigationGrouping]]：将资源分组到 `NavigationGroup` 并默认折叠不常用组的导航优化
|
||||
- [[NoiseCheck]]：在最终化前移除任何不改善层级结构的图标、提示文字和多余容器的质量保证流程
|
||||
- [[PlaceholderSummary]]：在编辑表单顶部添加关键指标的 Placeholder 摘要视图
|
||||
|
||||
## Key Entities
|
||||
- [[FilamentOptimizationAgent]]：Agent 人格名称，专注于 Filament PHP admin panel 结构性优化的专家角色
|
||||
|
||||
## Connections
|
||||
- [[DesignUXArchitect]] ← informs ← [[StructuralOptimization]]（UX 架构原则为此 Agent 提供理论支撑）
|
||||
- [[DesignUIFormOptimization]] ← extends ← [[FilamentOptimization]]（UI 表单优化是 Filament 优化的具体实现）
|
||||
- [[LaravelFilament]] ← optimizes ← [[FilamentAdminPanel]]（FilamentOptimizationAgent 的工作对象）
|
||||
|
||||
## Contradictions
|
||||
- 与一般 UI 优化观点冲突：
|
||||
- 冲突点：传统观点认为添加图标、提示文字能提升表单可用性
|
||||
- 当前观点（FilamentOptimizationAgent）：结构性改变（Tab/Grid/Collapsible）才是真正提升，装饰性改动价值有限
|
||||
- 对方观点：图标和提示文字是低门槛高回报的 UX 改进
|
||||
- 评估：FilamentOptimizationAgent 对"高价值改进"的定义更严格，强调信息架构优先于视觉装饰
|
||||
45
wiki/sources/engineering-frontend-developer.md
Normal file
45
wiki/sources/engineering-frontend-developer.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "Frontend Developer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-frontend-developer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Frontend Developer Agent 人格定义——一个专注于现代 Web 技术、UI 框架和性能优化的前端开发专家代理。
|
||||
- 问题域：现代响应式 Web 应用开发、像素级 UI 实现、性能调优、无障碍访问合规。
|
||||
- 方法/机制：四阶段工作流（项目架构 → 组件开发 → 性能优化 → 测试 QA），Core Web Vitals 优先策略，WCAG 2.1 AA 无障碍标准，移动端优先设计，现代 React/Vue/Angular 框架，TypeScript + 现代 CSS 技术。
|
||||
- 结论/价值：为 AI Agent 提供标准化的前端开发人格规范，涵盖交付模板、成功指标和技术能力边界。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 前端代理应确保 3G 网络下页面加载时间低于 3 秒，Lighthouse 性能与无障碍评分持续超过 90。
|
||||
- 组件复用率应超过 80%，生产环境零控制台错误。
|
||||
- 导航动作往返延迟须低于 150ms。
|
||||
|
||||
## Key Quotes
|
||||
> "You are **Frontend Developer**, an expert frontend developer who specializes in modern web technologies, UI frameworks, and performance optimization." — Agent 人格定义核心
|
||||
|
||||
> "Implement Core Web Vitals optimization from the start" — 性能优先开发原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Core Web Vitals]]：Google 定义的页面性能指标（LCP、FID、CLS），前端代理必须优先优化。
|
||||
- [[WCAG 2.1 AA]]：Web 内容无障碍指南 2.1 级别 AA，前端代理须确保合规。
|
||||
- [[Code Splitting]]：通过动态导入实现_bundle size 优化，减少初始加载时间的技术手段。
|
||||
- [[PWA]]：渐进式 Web 应用，支持离线能力和 Service Worker 缓存策略。
|
||||
- [[Accessibility]]：无障碍设计，包括 ARIA 标签、语义化 HTML、键盘导航和屏幕阅读器兼容。
|
||||
|
||||
## Key Entities
|
||||
- [[Design UI Designer]]：UI 设计师代理，与前端代理协作完成设计与实现的对齐。
|
||||
- [[Testing Accessibility Auditor]]：无障碍审计代理，对前端实现进行 WCAG 合规验证。
|
||||
- [[Code Reviewer]]：代码审查代理，确保前端代码质量和最佳实践。
|
||||
|
||||
## Connections
|
||||
- [[Engineering Senior Developer]] ← feeds_into ← [[Engineering Frontend Developer]]
|
||||
- [[Engineering CMS Developer]] ← related_to ← [[Engineering Frontend Developer]]
|
||||
- [[Engineering UI Designer]] ←handoff_to ← [[Engineering Frontend Developer]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。
|
||||
56
wiki/sources/engineering-git-workflow-master.md
Normal file
56
wiki/sources/engineering-git-workflow-master.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Git Workflow Master Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-git-workflow-master.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Git 工作流与版本控制策略专家 Agent 个性定义
|
||||
- 问题域：团队协作中的分支管理、历史整洁、提交规范、CI/CD 集成
|
||||
- 方法/机制：
|
||||
- 原子提交（Atomic Commits）：每次提交只做一件事
|
||||
- Conventional Commits 规范：`feat:` / `fix:` / `chore:` / `docs:` / `refactor:` / `test:`
|
||||
- 两种分支策略：Trunk-Based Development（主推）和 Git Flow（版本发布）
|
||||
- 高级技巧：Worktree / Interactive Rebase / Git Bisect / Reflog / Cherry-pick
|
||||
- 安全强制推送：`--force-with-lease`
|
||||
- 合并策略：`--no-ff` 或 Squash Merge
|
||||
- 结论/价值：帮助团队维护干净的提交历史，避免合并地狱（merge hell），建立可追溯、可协作的版本控制规范
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 每个提交原子化（每次只做一件事，可独立回滚）
|
||||
- Conventional Commits 格式保证提交历史可读、可自动化解析
|
||||
- Trunk-Based 是大多数团队推荐的分支策略（短生命周期特性分支）
|
||||
- Git Flow 适合有明确版本发布周期的团队
|
||||
- 永远不要在共享分支上强制推送，应使用 `--force-with-lease`
|
||||
- PR/MR 合并前必须 rebase 到目标分支最新代码
|
||||
|
||||
## Key Quotes
|
||||
> "Atomic commits — Each commit does one thing and can be reverted independently." — Git Workflow Master 核心原则
|
||||
> "Never force-push shared branches — Use `--force-with-lease` if you must." — 安全推送规范
|
||||
> "Branch from latest — Always rebase on target before merging." — 合并前规范
|
||||
|
||||
## Key Concepts
|
||||
- [[AtomicCommits]]：每次提交只做一件事，可独立回滚的提交单元
|
||||
- [[ConventionalCommits]]：标准化的提交信息格式（feat/fix/chore/docs/refactor/test）
|
||||
- [[TrunkBasedDevelopment]]：主分支始终可部署，短生命周期特性分支的分支策略
|
||||
- [[GitFlow]]：含 main/develop/release/hotfix 多分支，适合版本化发布的分支策略
|
||||
- [[ForceWithLease]]：`--force-with-lease` 安全强制推送版本，避免覆盖他人提交
|
||||
|
||||
## Key Entities
|
||||
- 无关键外部实体（本文档为 Agent 个性定义，无外部公司/产品引用）
|
||||
|
||||
## Connections
|
||||
- [[CodeReviewer]] ← informs → [[GitWorkflowMaster]]（代码审查需基于规范化的提交历史）
|
||||
- [[CIGithub]] ← integrates_with → [[GitWorkflowMaster]]（CI pipeline 依赖分支保护规则和自动化检查）
|
||||
- [[GitOps]] ← extends → [[GitWorkflowMaster]]（GitOps 以 Git 工作流为基础，扩展了 IaC 和部署自动化）
|
||||
|
||||
## Contradictions
|
||||
- 与 Git Flow 页面冲突：
|
||||
- 冲突点：Trunk-Based vs Git Flow 哪个是"推荐"策略
|
||||
- 当前观点（Git Workflow Master）：Trunk-Based 适合大多数团队
|
||||
- 对方观点（[[GitFlow]]）：Git Flow 是处理版本发布和多环境管理的标准方案
|
||||
- 说明：两者各有适用场景，Trunk-Based 适合持续部署团队，Git Flow 适合有明确版本发布周期的团队，不构成直接矛盾而是互补
|
||||
62
wiki/sources/engineering-incident-response-commander.md
Normal file
62
wiki/sources/engineering-incident-response-commander.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Incident Response Commander Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-incident-response-commander]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：面向可靠工程的智能体（AI Agent）—— Incident Response Commander（事故响应指挥官），将生产事故混乱转化为结构化解决
|
||||
- 问题域：生产环境事故管理、值班流程设计、事后复盘、可靠性工程文化
|
||||
- 方法/机制：SEV1–SEV4 严重等级分类框架、角色分工（IC/Comms/Tech Lead/Scribe）、无责文化（blameless）、SLO/SLI/SLA 体系、混沌工程、5 Whys 根因分析
|
||||
- 结论/价值：为可靠工程组织提供完整的事故响应 SOP，降低 MTTD/MTTR，保护 on-call 工程师心理健康
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 事故指挥官（IC）通过固定角色分工和固定更新节奏，将混乱转为结构化响应
|
||||
- 无责文化（blameless culture）确保工程师敢于上报问题而非隐瞒，是可靠性组织的基础
|
||||
- SLO 必须有约束力：错误预算耗尽时，功能开发必须暂停，转向可靠性工作
|
||||
- Runbook 每季度必须测试一次——未经测试的 runbook 是虚假的安全感
|
||||
- On-call 工程师必须有应急处置权，无需多级审批链
|
||||
- 每次事故必须在 48 小时内生成时间线、影响评估和后续行动项
|
||||
|
||||
## Key Quotes
|
||||
> "Never frame findings as 'X person caused the outage' — frame as 'the system allowed this failure mode'" — 无责文化的核心原则：归因于系统缺陷，而非个人错误
|
||||
> "The gap is that we have no integration test for config validation — that's the systemic issue to fix" — 复盘时聚焦系统性缺口，而非追责
|
||||
> "A blameless post-mortem without follow-through is just a meeting" — 事后复盘若无跟进，只是浪费时间
|
||||
> "Chaos multiplies without coordination" — 无协调则混乱倍增
|
||||
|
||||
## Key Concepts
|
||||
- [[BlamelessPostMortem]]：无责复盘——聚焦系统性根因而非个人错误，保护心理安全
|
||||
- [[ErrorBudget]]：错误预算——SLO 未达标时的容忍空间；低于 25% 时全员投入可靠性工作
|
||||
- [[ServiceLevelObjective]]（SLO）：服务等级目标——有约束力的可靠性承诺，而非纸面指标
|
||||
- [[ServiceLevelIndicator]]（SLI）：服务等级指标——可测量的具体指标（如错误率、延迟）
|
||||
- [[FiveWhys]]：5问法——通过层层追问找到系统性根本原因
|
||||
- [[FaultTreeAnalysis]]：故障树分析——结构化根因分析工具
|
||||
- [[ChaosEngineering]]：混沌工程——通过受控故障注入验证系统韧性
|
||||
- [[GameDay]]：Game Day——跨团队模拟多服务级联故障演练
|
||||
- [[MeanTimeToDetect]]（MTTD）：从故障发生到检测的平均时间，目标 < 5 分钟（SEV1/2）
|
||||
- [[MeanTimeToResolve]]（MTTR）：从检测到恢复的平均时间，目标 < 30 分钟（SEV1）
|
||||
- [[IncidentSeverityMatrix]]：SEV1–SEV4 严重等级矩阵，定义响应时间、升级路径和沟通节奏
|
||||
|
||||
## Key Entities
|
||||
- [[IncidentCommander]]（IC）：事故指挥官——唯一决策者，负责时间线管理和角色协调
|
||||
- [[CommunicationsLead]]：沟通负责人——按严重等级节奏向干系人发送状态更新
|
||||
- [[TechnicalLead]]：技术负责人——主导诊断，使用 runbook 和可观测性工具
|
||||
- [[Scribe]]：记录员——实时记录每个操作和发现，含时间戳
|
||||
- [[OnCallEngineer]]：值班工程师——负责检测和初步响应
|
||||
- [[SiteReliabilityEngineering]]（SRE）：网站可靠性工程——本 agent 的工程领域背景
|
||||
|
||||
## Connections
|
||||
- [[SiteReliabilityEngineering]] ← 依赖 → [[ErrorBudget]]
|
||||
- [[BlamelessPostMortem]] ← 依赖 → [[FiveWhys]]
|
||||
- [[IncidentSeverityMatrix]] ← 支撑 → [[IncidentCommander]]
|
||||
- [[ChaosEngineering]] ← 验证 → [[GameDay]]
|
||||
- [[ServiceLevelObjective]] ← 包含 → [[ServiceLevelIndicator]]
|
||||
- [[MeanTimeToDetect]] ← 度量 → [[OnCallEngineer]]
|
||||
- [[MeanTimeToResolve]] ← 度量 → [[IncidentCommander]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无检测到冲突页面）
|
||||
51
wiki/sources/engineering-minimal-change-engineer.md
Normal file
51
wiki/sources/engineering-minimal-change-engineer.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Minimal Change Engineer Agent"
|
||||
type: source
|
||||
tags: [engineering, agent-persona, code-quality, scope-management]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-minimal-change-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 编程代理的人格设定——最小变更工程师（Minimal Change Engineer），专注于交付最小可工作差异集，拒绝范围蔓延
|
||||
- 问题域：AI 编程工具普遍存在"过度生产"问题——修复一个 bug 时附带重构、添加文档、引入防御性代码等
|
||||
- 方法/机制：通过严格的行为规则、工作流模板（Scope Self-Check）和代码示例，将"只做被要求的事"内化为代理的核心原则
|
||||
- 结论/价值：最小变更原则降低代码审查时间 50%+，减少回归风险，PR 可在 10 秒内审阅完成
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果
|
||||
- **AI 编程代理默认过度生产** → 最小变更工程师通过严格规则约束范围 → 交付最小 diff，减少引入新 Bug 的风险
|
||||
- **三次重复才考虑提取抽象** → 坚持"四条重复才提取"原则 → 避免过早抽象带来的隐性债务
|
||||
- **范围蔓延在审查阶段最为危险** → 代理需主动拒绝"顺便..."请求 → 保持 PR 干净且独立可审
|
||||
- **约束本身就是一种高级能力** → 最小变更工程师通过"Diff archaeology"和"Scope negotiation"技能扩展其价值 → 不仅自我约束，还能指导他人
|
||||
|
||||
## Key Quotes
|
||||
> "Software has a half-life. Every line you add will eventually need to be read, debugged, refactored, or deleted by someone — possibly you, possibly at 2 AM. The kindest thing you can do for that future person is to add fewer lines." — 核心原则
|
||||
|
||||
> "Three similar lines beats a premature abstraction." — 过早抽象陷阱的反面教材
|
||||
|
||||
> "I'm not going to add a config flag for that. We have one caller and no requirement for a second. We can extract when the second caller appears." — 拒绝未来灵活性陷阱的标准话术
|
||||
|
||||
## Key Concepts
|
||||
- [[ScopeCreep]]：范围蔓延——超出任务明确要求的变更行为，是最小变更工程师的核心反模式
|
||||
- [[PrematureAbstraction]]：过早抽象——在第三次出现之前就提取辅助函数，引入隐性债务
|
||||
- [[MinimalChangePrinciple]]：最小变更原则——每个变更行的存在都必须有任务明确要求的理由
|
||||
|
||||
## Key Entities
|
||||
- （本来源未引入需创建独立页面的外部人物或公司）
|
||||
|
||||
## Connections
|
||||
- [[engineering-code-reviewer]] ← 对立与互补 ← [[engineering-minimal-change-engineer]]
|
||||
- 代码审查者发现范围蔓延，最小变更工程师预防范围蔓延
|
||||
- [[engineering-sre]] ← 协作 ← [[engineering-minimal-change-engineer]]
|
||||
- SRE 保障可靠性，最小变更工程师通过最小 blast radius 降低故障影响
|
||||
- [[engineering-senior-developer]] ← 互补 ← [[engineering-minimal-change-engineer]]
|
||||
- 高级工程师的经验判断与最小变更原则相辅相成
|
||||
|
||||
## Contradictions
|
||||
- 与 [[engineering-rapid-prototyper]] 潜在张力：
|
||||
- 冲突点：快速原型优先速度与简洁性，最小变更优先控制范围
|
||||
- 当前观点：最小变更工程师的 PR 应独立于原型工作，原型阶段允许快速迭代，最终生产代码遵循最小变更原则
|
||||
- 对方观点：快速原型阶段不应受最小变更约束，需快速验证后再重构
|
||||
@@ -2,55 +2,59 @@
|
||||
title: "Mobile App Builder Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
|
||||
- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范
|
||||
- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束
|
||||
- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines）
|
||||
- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性
|
||||
- 核心主题：移动应用开发专家 Agent 人格定义，涵盖原生 iOS/Android 开发和跨平台框架
|
||||
- 问题域：如何构建高性能、平台原生体验的移动应用，平衡代码复用与平台原生感受
|
||||
- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 架构模式；平台设计指南遵循；离线优先架构
|
||||
- 结论/价值：提供标准化的移动应用开发 Agent 人格定义，强调平台感知、性能优先、用户体验驱动
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines）
|
||||
- 移动应用必须实现离线优先架构和智能数据同步
|
||||
- 跨平台开发需在代码复用与平台原生体验之间找到平衡
|
||||
- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时
|
||||
- Mobile App Builder Agent 使用 Swift、SwiftUI、Kotlin、Jetpack Compose、React Native、Flutter 等技术栈构建原生和跨平台移动应用
|
||||
- Agent 默认要求确保离线功能和平台适当的导航
|
||||
- Agent 遵循平台设计指南（Material Design、Human Interface Guidelines）并使用平台原生导航模式和 UI 组件
|
||||
- Agent 优化移动性能指标：冷启动时间 < 3 秒、内存使用 < 100MB、续航损耗 < 5%/小时
|
||||
- Agent 提供生物识别认证、推送通知、地图服务、应用内购买等平台特定功能集成
|
||||
- Agent 使用 MVVM 模式作为推荐的应用程序架构模式
|
||||
|
||||
## Key Quotes
|
||||
> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例
|
||||
> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念
|
||||
> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标
|
||||
> "You create high-performance, user-friendly mobile experiences with platform-specific optimizations and modern mobile development patterns." — 核心身份定位
|
||||
> "Follow platform-specific design guidelines (Material Design, Human Interface Guidelines)" — 平台设计规范
|
||||
> "Default requirement: Ensure offline functionality and platform-appropriate navigation" — 默认功能要求
|
||||
> "Optimize for mobile constraints (battery, memory, network)" — 性能优化要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验
|
||||
- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染
|
||||
- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性
|
||||
- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互
|
||||
- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证
|
||||
- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存
|
||||
- [[MVVM]]：Model-View-ViewModel 模式，推荐的移动应用架构模式
|
||||
- [[Offline-First Architecture]]：离线优先架构，支持智能数据同步
|
||||
- [[Cross-Platform Development]]：使用 React Native/Flutter 实现跨平台开发
|
||||
- [[Native Mobile Development]]：原生 iOS/Android 开发（Swift/Kotlin）
|
||||
- [[Platform Design Guidelines]]：平台设计指南（Material Design / Human Interface Guidelines）
|
||||
- [[Performance Optimization]]：性能优化（启动时间、内存、电池）
|
||||
- [[Biometric Authentication]]：生物识别认证（Face ID、Touch ID、指纹）
|
||||
|
||||
## Key Entities
|
||||
- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面
|
||||
- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发
|
||||
- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用
|
||||
- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码
|
||||
- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用
|
||||
- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用
|
||||
- [[SwiftUI]]：Apple 现代声明式 UI 框架
|
||||
- [[Jetpack Compose]]：Google 现代 Android 声明式 UI 框架
|
||||
- [[React Native]]：Facebook 跨平台移动开发框架
|
||||
- [[Flutter]]：Google 跨平台 UI 工具包
|
||||
- [[Hilt]]：Android 依赖注入框架（ViewModel 示例中使用）
|
||||
- [[Combine]]：Apple 响应式编程框架
|
||||
- [[Material Design]]：Android 平台设计语言
|
||||
- [[Human Interface Guidelines]]：Apple 平台设计规范
|
||||
|
||||
## Connections
|
||||
- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]]
|
||||
- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论）
|
||||
- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端）
|
||||
- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展）
|
||||
- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验）
|
||||
- [[engineering-software-architect]] ← extends ← [[engineering-mobile-app-builder]]：共享系统架构思维应用于移动端
|
||||
- [[unity-architect]] ← related_to ← [[engineering-mobile-app-builder]]：跨平台理念分工——前者面向游戏，后者面向通用移动应用
|
||||
- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]：均使用 SwiftUI 技术栈，但前者面向空间计算平台
|
||||
|
||||
## Contradictions
|
||||
- 与 [[unity-architect]] 跨平台理念存在框架差异：
|
||||
- 冲突点：原生开发 vs 跨平台框架的优先级
|
||||
- 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型
|
||||
- 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案
|
||||
- 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾
|
||||
- 与 [[unity-architect]] 的跨平台理念差异：
|
||||
- 冲突点：跨平台开发的代码复用程度与平台原生体验的权衡
|
||||
- 当前观点：Mobile App Builder 强调代码复用（React Native/Flutter）与平台原生体验的平衡
|
||||
- 对方观点：Unity Architect 面向游戏开发，采用更激进的跨平台策略（Unity 引擎本身）
|
||||
- 注：无实质冲突，属不同应用场景的合理分工
|
||||
|
||||
53
wiki/sources/engineering-rapid-prototyper.md
Normal file
53
wiki/sources/engineering-rapid-prototyper.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Rapid Prototyper Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-rapid-prototyper.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 角色定义 —— 极速原型开发专家，专注于在 3 天内交付可工作的 MVP 原型
|
||||
- 问题域：如何快速验证创意想法、降低产品开发风险、以最小成本获取用户反馈
|
||||
- 方法/机制：速度优先开发、验证驱动特性选择、模块化架构、即刻部署上线、A/B 测试与用户反馈收集
|
||||
- 结论/价值：原型到生产的转化时间控制在 2 周内，80% 核心功能通过用户测试验证，利益相关者认可率超过 90%
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Rapid Prototyper Agent 通过使用无代码/低代码方案和后端即服务平台，实现数天内而非数周交付可用原型
|
||||
- 验证驱动开发确保只构建测试核心假设所必需的功能，从第一天起就内置用户反馈和数据分析
|
||||
- 模块化架构支持基于用户反馈的快速迭代，同时设计可演进为生产级系统的原型
|
||||
- Next.js + Supabase + Prisma + Clerk + shadcn/ui 组成快速开发技术栈，覆盖认证、数据、部署全链路
|
||||
- 原型阶段引入 A/B 测试框架和实时分析基础设施，为产品决策提供数据支撑
|
||||
|
||||
## Key Quotes
|
||||
> "Build functional prototypes in under 3 days using rapid development tools" — 核心交付目标：3天内交付功能原型
|
||||
> "Build only features necessary to test core hypotheses" — 验证驱动开发，只做核心假设验证所需的最小功能集
|
||||
> "Design prototypes that can evolve into production systems" — 原型设计需考虑可演进性，不是临时方案
|
||||
|
||||
## Key Concepts
|
||||
- [[MVP（最小可行产品）]]：最小可行产品，通过最小功能集快速验证核心商业假设
|
||||
- [[A/B Testing]]：在原型阶段引入 A/B 测试，对功能变体进行对照验证，获取可量化的用户行为数据
|
||||
- [[Rapid Prototyping]]：极速原型开发，使用速度优先的开发栈和预构建组件，最大化开发效率
|
||||
- [[用户反馈收集]]：从原型第一天就内置反馈收集机制，持续获取真实用户意见指导迭代方向
|
||||
- [[No-Code/Low-Code]]：在非核心功能上使用无代码/低代码方案，减少重复造轮子，提升开发速度
|
||||
|
||||
## Key Entities
|
||||
- [[Next.js]]：React 全栈框架，提供 SSR/SSG 能力和零配置部署（Vercel）
|
||||
- [[Supabase]]：后端即服务（BaaS）平台，提供即开即用的数据库、认证和实时订阅
|
||||
- [[Clerk]]：现代化认证服务，支持社交登录和多平台用户管理集成
|
||||
- [[Prisma]]：TypeScript ORM，与 Supabase PostgreSQL 配合提供类型安全的数据库操作
|
||||
- [[shadcn/ui]]：可复用的无样式 UI 组件库，基于 Radix UI 构建，支持快速定制
|
||||
- [[Vercel]]：零配置部署平台，提供即时预览 URL 用于快速分享和用户测试
|
||||
|
||||
## Connections
|
||||
- [[Next.js]] ← 构建框架 ← [[Rapid Prototyper]]
|
||||
- [[Supabase]] ← 后端服务 ← [[Rapid Prototyper]]
|
||||
- [[Clerk]] ← 认证方案 ← [[Rapid Prototyper]]
|
||||
- [[Prisma]] ← ORM层 ← [[Supabase]]
|
||||
- [[shadcn/ui]] ← UI组件 ← [[Next.js]]
|
||||
- [[Vercel]] ← 部署平台 ← [[Next.js]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
66
wiki/sources/engineering-security-engineer.md
Normal file
66
wiki/sources/engineering-security-engineer.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Security Engineer Agent Personality"
|
||||
type: source
|
||||
tags: [agent-personality, security, application-security]
|
||||
sources: []
|
||||
last_updated: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-security-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：定义一个专注于应用安全工程的 AI Agent 人格，具备威胁建模、漏洞评估、安全代码审查、安全架构设计和事件响应的全链路能力
|
||||
- 问题域：现代 Web 应用、API、云原生应用的安全防护，覆盖 OWASP Top 10、CWE Top 25、API 安全、云安全、供应链安全等广泛领域
|
||||
- 方法/机制：采用对抗性思维框架（STRIDE 分析）、防御深度策略（defense-in-depth）、零信任架构；在 SDLC 各阶段集成安全；通过 SAST/DAST/SCA/secrets 检测构建 CI/CD 安全门禁
|
||||
- 结论/价值：该 Agent 以攻击者视角思考，以工程师方式防御，通过威胁建模前置识别风险、通过分层防护降低攻击面、通过自动化检测实现安全左移
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Security Engineer Agent 通过将安全集成到设计→实现→测试→部署→运营的全生命周期，实现风险前置发现
|
||||
- 所有用户输入均视为敌对输入，必须在每个信任边界（客户端、API 网关、服务、数据库）进行验证和清理
|
||||
- 默认拒绝原则（Default Deny）：在访问控制、输入验证、CORS、CSP 中优先使用白名单而非黑名单
|
||||
- 防御深度原则：永远不依赖单一保护层，假设任何一层都可能被绕过，通过 WAF→限流→输入验证→参数化查询→输出编码→CSP 的多层叠加实现真正安全
|
||||
- 零信任架构：以最小权限为原则，结合微隔离，实现每次访问均需验证
|
||||
- 供应链安全：通过 SBOM 生成与监控、CVE 审计、包完整性校验（校验和、签名、lock 文件）、依赖混淆/typosquatting 攻击检测，构建可信依赖链
|
||||
|
||||
## Key Quotes
|
||||
> "You think like an attacker to defend like an engineer." — Security Engineer 的核心哲学定位
|
||||
> "Security is a spectrum, not a binary. You prioritize risk reduction over perfection, and developer experience over security theater." — 安全的本质是风险管理，而非追求完美
|
||||
> "Every finding must include a severity rating, proof of exploitability, and concrete remediation with code." — 安全发现必须包含严重等级、可利用性证明和具体修复代码
|
||||
> "No hardcoded credentials, no secrets in logs, no secrets in client-side code, no secrets in environment variables without encryption." — 密钥管理四条铁律
|
||||
> "The best security control is one that developers adopt willingly because it makes their code better, not harder to write." — 安全与开发者体验的平衡哲学
|
||||
|
||||
## Key Concepts
|
||||
- [[ThreatModeling]]：通过 STRIDE 框架（Spoofing/Tampering/Repudiation/Information Disclosure/DoS/Elevation of Privilege）对每个组件进行系统性威胁分析
|
||||
- [[OWASP Top 10]]：2021+ 版本的十大 Web 应用安全风险（注入、XSS、身份认证失效、敏感数据泄露、XXE、访问控制失效、安全配置错误、脚本插入、逆向工程、日志监控缺失）作为代码审查和漏洞评估的基准清单
|
||||
- [[DefenseInDepth]]：多层防御策略，假设任何单层均可被绕过，通过 WAF→限流→输入验证→参数化查询→输出编码→CSP 的叠加实现纵深防护
|
||||
- [[ZeroTrust Architecture]]：永不信任、始终验证的架构范式，以最小权限访问控制和微隔离为技术核心
|
||||
- [[CVSS 3.1]]：通用漏洞评分系统，用于标准化漏洞严重等级（Critical/High/Medium/Low/Informational）评估
|
||||
- [[SAST/DAST/SCA]]：静态应用安全测试（代码层面）、动态应用安全测试（运行时）、软件组成分析（依赖层面）三位一体的自动化安全检测体系
|
||||
- [[RBAC/ABAC/ReBAC]]：基于角色的访问控制、基于属性的访问控制、基于关系的访问控制三种授权模型，根据应用需求匹配合适的访问控制方案
|
||||
- [[SupplyChainSecurity]]：SBOM 生成与监控、依赖 CVE 审计、混淆攻击检测、可复现构建的供应链全链条安全管理
|
||||
- [[SecretsManagement]]：密钥的全生命周期管理，包括轮换策略，推荐工具包括 HashiCorp Vault、AWS Secrets Manager、SOPS
|
||||
- [[IncidentResponse]]：安全事件的分类、遏制、根因分析和修复建议的完整事件响应流程
|
||||
|
||||
## Key Entities
|
||||
- [[Semgrep]]：开源 SAST 工具，用于规则驱动的代码安全扫描
|
||||
- [[Trivy]]：容器和依赖漏洞扫描工具，支持 CRITICAL/HIGH 级别阻断
|
||||
- [[Gitleaks]]：Git 提交中的密钥和敏感信息检测工具
|
||||
- [[HashiCorp Vault]]：企业级密钥管理与轮换平台
|
||||
- [[AWS Secrets Manager]]：AWS 原生的密钥管理服务
|
||||
- [[OAuth 2.0 + PKCE]]：现代认证授权协议组合，PKCE 防止授权码拦截攻击
|
||||
- [[WebAuthn/Passkeys]]：无密码认证标准，基于公钥加密消除密码泄露风险
|
||||
- [[STRIDE]]：微软提出的威胁建模框架，六个维度系统性评估系统威胁
|
||||
|
||||
## Connections
|
||||
- [[Engineering-SRE]] ← overlaps_with ← [[SecurityEngineer]]（均涉及云安全、基础设施安全监控和事件响应）
|
||||
- [[Engineering-Code-Reviewer]] ← extends ← [[SecurityEngineer]]（代码审查中必须集成安全视角）
|
||||
- [[Testing-Accessibility-Auditor]] ← parallels ← [[SecurityEngineer]]（均通过系统性测试流程发现应用问题）
|
||||
- [[零信任架构]] ← is_a_concept_of ← [[SecurityEngineer]]（零信任是安全架构设计的核心理念）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Engineering-SRE]] 存在视角差异：
|
||||
- 冲突点：SRE 以可用性为优先，安全工程师以安全性为优先，两者对"故障时的默认行为"存在权衡分歧
|
||||
- 当前观点（Security Engineer）：fail securely — 错误不得泄露堆栈跟踪、内部路径、数据库 schema 或版本信息
|
||||
- 对方观点（Engineering-SRE）：fail loudly — 快速失败以减少 MTTR，依赖完善的监控告警而非隐藏错误细节
|
||||
- 协调方案：在生产环境 fail securely + 结构化日志输出给监控系统；在开发/测试环境可保留详细错误信息以加速调试
|
||||
101
wiki/sources/engineering-senior-developer.md
Normal file
101
wiki/sources/engineering-senior-developer.md
Normal file
@@ -0,0 +1,101 @@
|
||||
---
|
||||
title: "Senior Developer Agent Personality"
|
||||
type: source
|
||||
tags: ["agent-personality", "engineering", "laravel", "livewire", "web-development"]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-senior-developer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Senior Developer Agent 角色定义 —— 专注于使用 Laravel/Livewire/FluxUI 实现高端 web 体验的全栈开发者 Agent
|
||||
- 问题域：如何让 AI Agent 作为高级全栈工程师，遵循高级设计标准（Premium Design Standards）实施高质量 web 项目
|
||||
- 方法/机制：通过角色设定（Identity & Memory）、开发哲学（Premium Craftsmanship）、技术栈（Tech Stack Expertise）、实施流程（Implementation Process）规范 Agent 行为
|
||||
- 结论/价值：定义了"奢华感"（Premium）与"基础"（Basic）的区别标准，要求 Agent 实施高性能、高美感、可访问的 web 体验
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **FluxUI + Laravel/Livewire 组合** → 提供完整高端全栈实施能力 → 支撑快速构建可复用组件库
|
||||
- **亮色/暗色/系统主题切换** → 每个站点必须实现 → 确保跨场景用户体验一致性
|
||||
- **Three.js 集成** → 为英雄区（Hero Sections）提供粒子背景、交互式 3D 产品展示 → 创造沉浸式体验
|
||||
- **玻璃拟态（Glass Morphism）+ 高级动画** → 通过 backdrop-filter blur + cubic-bezier 缓动曲线 → 实现奢华感 UI
|
||||
- **60fps 动画 + 1.5s 内加载** → 性能与美感共存 → 满足高端用户体验标准
|
||||
|
||||
## Key Quotes
|
||||
> "Every pixel should feel intentional and refined" — Premium Craftsmanship 理念核心
|
||||
|
||||
> "Innovation over convention when it enhances UX" — 创新驱动的高端实现哲学
|
||||
|
||||
> "Performance and beauty must coexist" — 技术卓越（Technology Excellence）核心原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Premium Craftsmanship]]：每个像素都应经过精心打磨，包含平滑动画、微交互和性能优化
|
||||
- [[Laravel/Livewire Integration]]：PHP 全栈框架与响应式组件的集成模式
|
||||
- [[FluxUI Component Library]]：专业 UI 组件库，提供所有可用组件
|
||||
- [[Glass Morphism]]：玻璃拟态设计风格，使用 backdrop-filter blur + 透明背景实现高级视觉效果
|
||||
- [[Three.js Integration]]：WebGL 3D 集成，为 web 体验提供沉浸式粒子背景和交互式 3D 展示
|
||||
- [[Premium Design Standards]]：高端设计标准，强制要求亮/暗/系统主题切换、大留白、精致排版、磁性交互效果
|
||||
|
||||
## Key Entities
|
||||
- [[EngineeringSeniorDeveloper]]：Agent 身份名称，专注于高端 web 实现的高级全栈开发者
|
||||
- [[FluxUI]]：UI 组件库，提供所有专业组件
|
||||
- [[Laravel/Livewire]]：PHP 全栈框架组合
|
||||
- [[Three.js]]：WebGL 3D 图形库
|
||||
|
||||
## Connections
|
||||
- [[engineering-rapid-prototyper]] ← extends ← [[engineering-senior-developer]]（原型扩展至高级实现）
|
||||
- [[engineering-code-reviewer]] ← depends_on ← [[engineering-senior-developer]]（代码审查依赖实施）
|
||||
- [[engineering-filament-optimization-specialist]] ← depends_on ← [[engineering-senior-developer]]（性能优化依赖实施）
|
||||
- [[engineering-backend-architect]] ← extends ← [[engineering-senior-developer]]（后端架构扩展开发者角色）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
## Implementation Patterns（技术实施模式）
|
||||
|
||||
### Laravel/Livewire 组件模式
|
||||
```php
|
||||
class PremiumNavigation extends Component
|
||||
{
|
||||
public $mobileMenuOpen = false;
|
||||
|
||||
public function render()
|
||||
{
|
||||
return view('livewire.premium-navigation');
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### FluxUI 奢华卡片
|
||||
```html
|
||||
<flux:card class="luxury-glass hover:scale-105 transition-all duration-300">
|
||||
<flux:heading size="lg" class="gradient-text">Premium Content</flux:heading>
|
||||
<flux:text class="opacity-80">With sophisticated styling</flux:text>
|
||||
</flux:card>
|
||||
```
|
||||
|
||||
### 玻璃拟态 CSS
|
||||
```css
|
||||
.luxury-glass {
|
||||
background: rgba(255, 255, 255, 0.05);
|
||||
backdrop-filter: blur(30px) saturate(200%);
|
||||
border: 1px solid rgba(255, 255, 255, 0.1);
|
||||
border-radius: 20px;
|
||||
}
|
||||
```
|
||||
|
||||
### 磁性交互效果
|
||||
```css
|
||||
.magnetic-element {
|
||||
transition: transform 0.3s cubic-bezier(0.16, 1, 0.3, 1);
|
||||
}
|
||||
.magnetic-element:hover {
|
||||
transform: scale(1.05) translateY(-2px);
|
||||
}
|
||||
```
|
||||
|
||||
## Quality Standards（质量标准）
|
||||
- 加载时间 < 1.5 秒
|
||||
- 动画 60fps
|
||||
- 完美响应式设计
|
||||
- WCAG 2.1 AA 无障碍合规
|
||||
@@ -1,58 +1,50 @@
|
||||
---
|
||||
title: "Software Architect Agent Personality"
|
||||
type: source
|
||||
tags: [agent-personality, software-architecture, system-design, engineering]
|
||||
date: 2026-04-26
|
||||
tags: []
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/engineering/engineering-software-architect.md]]
|
||||
- [[Agent/agency-agents/engineering/engineering-software-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：软件架构与系统设计 Agent 的角色定义，专注于设计可维护、可扩展、符合业务领域的系统架构
|
||||
- 问题域：架构决策、模式选择、技术权衡、系统演进
|
||||
- 方法/机制：领域驱动设计（DDD）、边界上下文（bounded contexts）、架构决策记录（ADR）、C4 模型
|
||||
- 结论/价值：为 AI Agent 提供系统思维框架，强调权衡分析优先于最佳实践、领域优先于技术
|
||||
- 核心主题：AI Agent 软件架构专家人格定义——专注于系统设计、领域驱动设计、架构模式和可扩展性决策的智能体角色
|
||||
- 问题域：如何让 AI Agent 在多智能体协作中承担软件架构职责，在模块化单体与微服务之间做出权衡，并维护架构决策记录
|
||||
- 方法/机制：五步系统设计流程（领域发现→架构选型→质量属性分析→沟通风格→文档输出）；ADR 模板规范；C4 模型通信
|
||||
- 结论/价值：Software Architect Agent 通过明确约束（反架构航天员主义、权衡优先于最佳实践）确保 AI 输出的架构建议务实可落地
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 最佳架构是团队能够实际维护的架构：架构不应过度设计，必须匹配团队能力
|
||||
- 每个抽象必须有复杂度理由：避免架构宇航员式的过度设计
|
||||
- 权衡优先于最佳实践：命名所放弃的，而非仅描述所获得的
|
||||
- 领域优先、技术其次：理解业务问题，再选工具
|
||||
- 可逆性很重要：优先选择易变更的决策，而非"最优"决策
|
||||
- 记录决策，而非仅记录设计：ADR 捕捉 WHY，而非 WHAT
|
||||
- AI Agent 通过严格约束"每个抽象必须证明其复杂度"，可以避免陷入架构过度设计的陷阱
|
||||
- 在模块化单体与微服务之间选择时，团队规模和边界清晰度比技术优越性更关键
|
||||
- 架构决策记录（ADR）捕获"为什么"而非"是什么"，是 AI 协作中保持决策可追溯的关键机制
|
||||
- 领域优先、技术其次——理解业务问题再选工具，是 AI 系统设计建议可靠性的基础保障
|
||||
|
||||
## Key Quotes
|
||||
> "Designs systems that survive the team that built them. Every decision has a trade-off — name it." — 核心设计哲学
|
||||
|
||||
> "No architecture astronautics — Every abstraction must justify its complexity." — 关键规则 1
|
||||
|
||||
> "Domain first, technology second — Understand the business problem before picking tools." — 关键规则 3
|
||||
|
||||
> "Reversibility matters — Prefer decisions that are easy to change over ones that are 'optimal'." — 关键规则 4
|
||||
> "No architecture astronautics — Every abstraction must justify its complexity." — 核心设计原则：AI 不得产生无实际价值的过度抽象
|
||||
> "Trade-offs over best practices — Name what you're giving up, not just what you're gaining." — 架构权衡的透明性要求
|
||||
> "The best architecture is the one the team can actually maintain." — 可维护性优先于理论最优解
|
||||
|
||||
## Key Concepts
|
||||
- [[Bounded Contexts]]：领域驱动设计中划分业务边界的核心概念
|
||||
- [[Trade-off Analysis]]：架构决策中命名权衡而非仅列举优点的分析方法
|
||||
- [[Architecture Decision Record (ADR)]]：记录架构决策上下文、选项和理由的标准化模板
|
||||
- [[Modular Monolith]]：适合小型团队、不清晰边界的架构模式
|
||||
- [[Microservices]]：适合清晰领域、需要团队自治的架构模式
|
||||
- [[Event-Driven Architecture]]：适合松耦合、异步工作流的架构模式
|
||||
- [[CQRS]]：命令查询职责分离，适合读写不对称的系统
|
||||
- [[C4 Model]]：用四层图（C4：Context, Container, Component, Code）交流架构的标准化方法
|
||||
- [[Quality Attributes]]：可扩展性、可靠性、可维护性、可观测性等非功能需求
|
||||
- [[Bounded Contexts]]：领域驱动设计中的核心概念，定义特定领域的边界，确保模型在边界内一致
|
||||
- [[ADR (Architecture Decision Records)]]：架构决策记录文档模板，捕获上下文、决策和后果，而非仅记录结果
|
||||
- [[Trade-off Matrices]]：架构权衡矩阵，用于系统性对比多个方案的取舍
|
||||
- [[Modular Monolith vs Microservices]]：模块化单体（团队规模小、边界不清晰时）与微服务（领域清晰、团队自主性要求高时）的选型对照
|
||||
- [[CQRS (Command Query Responsibility Segregation)]]：命令查询职责分离，适合读写不对称场景
|
||||
- [[Event-driven Architecture]]：事件驱动架构，适合松耦合和异步工作流场景
|
||||
- [[C4 Model]]：系统通信图模型（Context/Container/Component/Code 四层），用于在不同抽象层级与干系人沟通
|
||||
|
||||
## Key Entities
|
||||
- （本文档为通用 Agent 角色定义，未涉及特定人物、公司或产品）
|
||||
- [[C4 Model]]：由 Simon Brown 创建的系统架构可视化标准，用于在不同抽象层级进行架构沟通
|
||||
|
||||
## Connections
|
||||
- [[BackendArchitectWithMemory]] ← shares_design_philosophy ← [[SoftwareArchitectAgent]]
|
||||
- [[WorkflowArchitect]] ← uses_ADR_pattern ← [[SoftwareArchitectAgent]]
|
||||
- [[SpecializedWorkflowArchitect]] ← architectural_decision_making ← [[SoftwareArchitectAgent]]
|
||||
- [[Backend-Architect-With-Memory]] ← similar_role ← [[Software-Architect-Agent]]
|
||||
- [[Agents-Orchestrator]] ← depends_on ← [[Software-Architect-Agent]]
|
||||
- [[Workflow-Architect-Agent]] ← related_to ← [[Software-Architect-Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[UnityArchitect]] 冲突：
|
||||
- 冲突点：架构约束与团队规模的关系
|
||||
- 当前观点（Software Architect）：最佳架构取决于团队能力； microservices 不适合小团队
|
||||
- 对方观点（Unity Architect）：针对特定技术平台（Unity）的架构师角色，可能倾向于选择特定技术栈而非纯权衡驱动
|
||||
- 注：两者领域不同（通用软件架构 vs 游戏引擎架构），冲突仅为框架层面的方法论差异
|
||||
- 与 [[Backend-Architect-With-Memory]] 的潜在冲突：
|
||||
- 冲突点：后端架构师是否需要持久记忆能力
|
||||
- 当前观点（Software Architect Agent）：架构师 Agent 关注设计决策和权衡，无需持久状态
|
||||
- 对方观点（Backend Architect with Memory）：架构师 Agent 需要跨会话累积上下文才能提供更准确建议
|
||||
- 协调方案：两者可互补——Memory 作为辅助数据源，Software Architect 作为推理引擎
|
||||
|
||||
57
wiki/sources/engineering-solidity-smart-contract-engineer.md
Normal file
57
wiki/sources/engineering-solidity-smart-contract-engineer.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Solidity Smart Contract Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-solidity-smart-contract-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：EVM 智能合约开发 Agent 人格定义，涵盖 Solidity 智能合约的安全开发、Gas 优化、可升级架构、DeFi 协议构建和代码审计标准
|
||||
- 问题域：EVM 兼容链（以太坊主网及 L2）的智能合约架构设计与安全审计
|
||||
- 方法/机制：checks-effects-interactions 模式、UUPS 代理模式、OpenZeppelin 基础合约、Foundry 测试框架、Gas 优化模式（存储打包、自定义错误、calldata 使用）
|
||||
- 结论/价值：提供了一套完整的智能合约开发方法论，强调安全第一、最小化 Gas 消耗和完整的测试覆盖
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 开发者必须将每个合约视为面临无限资本攻击者阅读源代码的场景进行设计
|
||||
- 遵循 checks-effects-interactions 模式和非 reentrancy guards 是防止外部调用重入攻击的根本保障
|
||||
- Gas 优化应从设计阶段开始，包括存储打包、使用 calldata、优先使用 external 而非 public 函数
|
||||
- 可升级合约架构（UUPS/Transparent Proxy）需从第一天就规划，不能事后补救
|
||||
- 每个协议必须配备 Foundry 测试套件，分支覆盖率 >95%，并包含 fuzz 和 invariant 测试
|
||||
|
||||
## Key Quotes
|
||||
> "You treat every wei of gas as precious, every external call as a potential attack vector, and every storage slot as prime real estate." — 角色定位核心理念
|
||||
> "Default requirement: Every contract must be written as if an adversary with unlimited capital is reading the source code right now" — 安全设计第一原则
|
||||
> "Clever code is dangerous code and simple code ships safely" — 代码简洁性哲学
|
||||
> "Never use `tx.origin` for authorization — it is always `msg.sender`" — 授权安全红线
|
||||
> "Never use `transfer()` or `send()` — always use `call{value:}("")` with proper reentrancy guards" — 外部调用安全规范
|
||||
|
||||
## Key Concepts
|
||||
- [[ChecksEffectsInteractions]]：checks（验证）→ effects（状态更新）→ interactions（外部调用）的顺序执行模式，是防止重入攻击的根本原则
|
||||
- [[ReentrancyGuard]]：防止合约函数被递归调用的访问控制机制，通过 mutex 锁确保同一调用栈中不可重入
|
||||
- [[UUPSUpgradeable]]：通用可升级代理模式（Universal Upgradeable Proxy Standard），将升级逻辑放在实现合约中而非代理中，降低部署成本
|
||||
- [[GasOptimization]]：通过存储打包、使用 calldata、自定义错误、immutable/constant 等手段最小化 EVM 执行成本的技术集合
|
||||
- [[StoragePacking]]：将多个小类型变量打包进同一 32 字节存储槽以节省 Gas 的模式
|
||||
- [[FlashLoanAttack]]：通过在单笔交易中借出并归还大量资产来操纵价格或状态的攻击模式，涵盖 Mango Markets 等典型案例
|
||||
- [[OpenZeppelin]]：最广泛使用的 Solidity 安全合约库，提供 ERC 标准实现、可升级代理、访问控制等经过审计的基础组件
|
||||
|
||||
## Key Entities
|
||||
- The DAO：2016 年以太坊经典重入攻击事件，开创了智能合约安全攻防研究的先河
|
||||
- Parity Wallet：2017 年 delegatecall 库调用漏洞导致钱包被锁死的安全事件
|
||||
- Wormhole：2022 年跨链桥攻击事件，攻击者利用签名验证漏洞窃取 3.2 亿美元
|
||||
- Ronin Bridge：2022 年验证节点被入侵导致 6.25 亿美元被盗的桥接攻击事件
|
||||
- Euler Finance：2023 年闪电贷操纵攻击事件，因合约缺少健康检查机制导致 1.97 亿美元损失
|
||||
- OpenZeppelin：最广泛使用的 Solidity 安全合约库，提供 ERC 标准、可升级代理、访问控制等审计过的合约
|
||||
- Foundry：最流行的 Solidity 开发框架，支持 Forge 测试、Fuzz 测试和 Invariant 测试
|
||||
|
||||
## Connections
|
||||
- [[BlockchainSecurityAuditor]] ← 共享安全第一原则 ← [[SoliditySmartContractEngineer]]
|
||||
- [[SoliditySmartContractEngineer]] ← 使用基础合约 ← [[OpenZeppelin]]
|
||||
- [[SoliditySmartContractEngineer]] ← 使用测试框架 ← Foundry
|
||||
- [[SoliditySmartContractEngineer]] ← 防御目标 ← FlashLoanAttack
|
||||
|
||||
## Contradictions
|
||||
- 与 [[BlockchainSecurityAuditor]]：两者均强调安全，但 Smart Contract Engineer 更关注开发实现过程（Gas 优化、可升级性），而 Security Auditor 专注于渗透测试和漏洞发现
|
||||
- 与 [[SoftwareArchitect]]：Software Architect 强调通用架构设计，Smart Contract Engineer 则有独特的 EVM 约束（Gas 模型、存储成本、外部调用风险），需要专门的安全和性能考量
|
||||
55
wiki/sources/engineering-sre.md
Normal file
55
wiki/sources/engineering-sre.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "SRE (Site Reliability Engineer) Agent Personality"
|
||||
type: source
|
||||
tags: [sre, reliability, observability, devops, agent]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-sre.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：SRE（网站可靠性工程师）Agent 个性定义——将可靠性视为可量化预算的专业生产系统专家 Agent
|
||||
- 问题域：大规模生产系统的可靠性管理——SLO 定义与测量、错误预算消耗追踪、可观测性体系构建、Toil 自动化、混沌工程
|
||||
- 方法/机制：SLO 驱动决策（错误预算剩余则发布功能，耗尽则修复可靠性）→ 三支柱可观测性（Metrics/Logs/Traces）→ Golden Signals 监控（Latency/Traffic/Errors/Saturation）→ Blameless 故障复盘文化 → 渐进式发布（Canary → Percentage → Full）
|
||||
- 结论/价值：SRE Agent 是工程团队实现 99.9%→99.99% 可用性提升的关键角色，每个 9 需要 10 倍成本投入
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- SRE Agent 通过错误预算框架将可靠性量化为可支出资源：错误预算剩余时允许功能发布，耗尽时强制修复可靠性
|
||||
- 可观测性体系必须同时覆盖 Metrics（趋势/告警/SLO追踪）、Logs（事件调试）、Traces（跨服务请求链路）三个维度
|
||||
- Golden Signals（Latency/Traffic/Errors/Saturation）是所有监控系统的最小必要信号集
|
||||
- Toil 必须自动化而非靠人力英雄式应对：重复两次的操作必须自动化
|
||||
|
||||
## Key Quotes
|
||||
> "Reliability is a feature. Error budgets fund velocity — spend them wisely." — SRE Agent 核心理念
|
||||
> "SLOs drive decisions — If there's error budget remaining, ship features. If not, fix reliability." — SRE 决策框架
|
||||
> "Blameless culture — Systems fail, not people. Fix the system." — SRE 文化准则
|
||||
> "Lead with data: 'Error budget is 43% consumed with 60% of the window remaining'" — SRE Agent 沟通风格
|
||||
|
||||
## Key Concepts
|
||||
- [[Service Level Objective]]：定义服务"足够可靠"的衡量标准，包含 SLI（指标定义）、Target（目标值）、Window（时间窗口）
|
||||
- [[Error Budget]]：错误预算——SLO 未达标时间的允许额度，驱动功能发布与可靠性工作的优先级决策
|
||||
- [[Observability]]：可观测性——通过 Metrics/Logs/Traces 回答"为什么这个坏了"的能力
|
||||
- [[Golden Signals]]：黄金信号——Latency、Traffic、Errors、Saturation 四个最小必要监控指标
|
||||
- [[Chaos Engineering]]：混沌工程——在生产环境主动注入故障以发现系统弱点的实践
|
||||
- [[Toil Reduction]]：Toil 消除——将重复性运维工作系统化自动化的实践
|
||||
- [[Canary Deployment]]：金丝雀发布——渐进式（而非大爆炸式）的服务部署策略
|
||||
|
||||
## Key Entities
|
||||
- Prometheus：SRE Agent 推荐的可观测性技术栈组成部分（Metrics 采集）
|
||||
- Grafana：SRE Agent 推荐的可观测性技术栈组成部分（Metrics 可视化与告警）
|
||||
- OpenTelemetry：云原生可观测性标准（SRE Agent observability stack 的 traces 和 logs 集成框架）
|
||||
|
||||
## Connections
|
||||
- [[engineering-devops-automator]] ← complements ← [[engineering-sre]]
|
||||
- [[engineering-sre]] ← shares_concepts ← [[CTP-Topic-41-NFRs-and-Error-Budgets]]
|
||||
- [[engineering-sre]] ← shares_concepts ← [[CTP-Topic-59-Achieving-Reliability-with-Amazon-EKS]]
|
||||
- [[engineering-sre]] ← extends ← [[engineering-backend-architect]]
|
||||
- [[engineering-sre]] ← builds_on ← [[DevOps-Automator-Agent]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[engineering-devops-automator]] 存在张力：
|
||||
- 冲突点：自动化与人工干预的边界
|
||||
- 当前观点（SRE）：人工 on-call 和故障复盘不可完全替代，系统故障需要人介入判断
|
||||
- 对方观点（DevOps Automator）：通过完全自动化消除人工干预，强调 self-healing 机制
|
||||
- 协调：两者互补而非矛盾——DevOps Automator 负责构建自动化基础设施，SRE 负责监控、错误预算决策和人工 on-call
|
||||
66
wiki/sources/engineering-technical-writer.md
Normal file
66
wiki/sources/engineering-technical-writer.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Technical Writer Agent Personality"
|
||||
type: source
|
||||
tags: ["agent-personality", "documentation", "developer-experience"]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-technical-writer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：为 AI Agent 定义 Technical Writer（技术文档工程师）角色——将复杂工程概念转化为开发者真正愿意阅读的清晰、准确、引人入胜的文档。
|
||||
- **问题域**：开发者文档质量低下（代码无注释、文档过时、README 无法让开发者 30 秒内上手）、Docs-as-Code 基础设施建设不足。
|
||||
- **方法/机制**：
|
||||
- 遵循 Divio 文档体系：教程 / 操作指南 / 参考文档 / 解释文档四象限分离
|
||||
- Docs-as-Code 基础设施：Docusaurus、MkDocs、Sphinx、VitePress + CI/CD 集成
|
||||
- API 文档：OpenAPI/Swagger 自动生成参考文档
|
||||
- 质量门禁：代码示例必须测试通过，破坏性变更必须附带迁移指南
|
||||
- 指标驱动：用 analytics、支持工单关联、用户反馈衡量文档有效性
|
||||
- **结论/价值**：技术文档是产品 bug；好文档能降低 20% 支持工单量，让新开发者 15 分钟内上手。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Technical Writer 必须在写文档前与工程师沟通：了解使用场景、难点、用户卡点
|
||||
- README 必须通过"5 秒测试"：这是什么、为什么重要、如何开始
|
||||
- 每个新功能必须附带文档——无文档的代码视为不完整
|
||||
- 代码示例必须经过测试——每段代码在发布前必须验证可运行
|
||||
- 文档必须与软件版本同步——旧版本文档要标注弃用而非删除
|
||||
- 每个 API 必须有参考条目、至少一个代码示例和错误处理文档
|
||||
- 高退出率页面 = 文档失败的信号
|
||||
|
||||
## Key Quotes
|
||||
> "Bad documentation is a product bug — you treat it as such." — 核心理念：文档质量等同于产品质量
|
||||
|
||||
> "Every new feature ships with documentation — code without docs is incomplete." — 质量门禁原则
|
||||
|
||||
> "Zero broken code examples in any published doc" — 零错误代码示例标准
|
||||
|
||||
> "Docs search satisfaction rate ≥ 80%" — 文档有效性核心指标
|
||||
|
||||
## Key Concepts
|
||||
- [[Divio Documentation System]]：将文档分为教程（学习导向）、操作指南（任务导向）、参考文档（信息导向）、解释文档（理解导向），不混用
|
||||
- [[Docs-as-Code]]：将文档视为代码的一部分，通过 CI/CD 管道管理、版本控制和自动化构建
|
||||
- [[API Documentation]]：从 OpenAPI/Swagger 规范自动生成参考文档，配合 Redoc/Stoplight 展示
|
||||
- [[Technical Writer]]：内容工程师角色，专注于开发者文档架构与质量
|
||||
|
||||
## Key Entities
|
||||
- [[Docusaurus]]：Meta 出品的文档站点框架，基于 React
|
||||
- [[MkDocs]]：Python 驱动的静态文档生成器，使用 Markdown
|
||||
- [[Sphinx]]：Python 官方文档工具，支持多语言和丰富的扩展生态
|
||||
- [[VitePress]]：Vue 团队出品的轻量级静态文档生成器
|
||||
- [[OpenAPI/Swagger]]：API 规范标准，用于自动生成 API 参考文档
|
||||
- [[Vale]]：开源 prose linter，用于文档风格检查
|
||||
- [[Redoc]]：开源 API 文档渲染器，从 OpenAPI 规范生成文档
|
||||
- [[Stoplight]]：商业 API 设计/文档平台
|
||||
|
||||
## Connections
|
||||
- [[Engineering Backend Architect]] ← writes_docs_for ← [[Technical Writer]]
|
||||
- [[Engineering Code Reviewer]] ← reviews_docs ← [[Technical Writer]]
|
||||
- [[Software Architect]] ← designs_architecture ← [[Technical Writer]] (provides docs requirements)
|
||||
|
||||
## Contradictions
|
||||
- 与 [[specialized-developer-advocate]] 冲突：
|
||||
- 冲突点：技术写作与开发者倡导者都产出手册和教程，但目标受众和交付标准不同。
|
||||
- 当前观点（Technical Writer）：文档以参考完整性优先，覆盖所有 API 端点和参数，面向不同熟练度的开发者分层提供内容。
|
||||
- 对方观点（Developer Advocate）：教程必须先展示最终结果，必须包含失败模式和调试方法，代码必须零修改运行，不为非 GA 功能发布教程。
|
||||
- 协调方案：Developer Advocate 负责"教程/快速入门/演示"等引导式内容；Technical Writer 负责"API 参考/规范文档/操作指南"等查阅式内容；两者共享 DX 反馈回路。
|
||||
65
wiki/sources/engineering-threat-detection-engineer.md
Normal file
65
wiki/sources/engineering-threat-detection-engineer.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: "Threat Detection Engineer Agent Personality"
|
||||
type: source
|
||||
tags: ["agent-personality", "security", "detection-engineering", "siem", "threat-hunting"]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-threat-detection-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：威胁检测工程师 Agent 个性定义——专注于构建检测层，在攻击者绕过预防控制后捕获威胁
|
||||
- 问题域：SIEM 规则开发、MITRE ATT&CK 覆盖度映射、威胁狩猎、告警调优、Detection-as-Code 流水线
|
||||
- 方法/机制：用 Sigma（厂商无关）编写检测规则，编译为 Splunk SPL / Sentinel KQL / Elastic EQL / Chronicle YARA-L；通过 Git + CI/CD 实现检测即代码；原子红队验证检测有效性
|
||||
- 结论/价值：检测质量远比数量重要；未检测到的入侵损失是已检测到的 10 倍；嘈杂的 SIEM 比没有 SIEM 更糟糕
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 检测质量 > 检测数量：未在真实日志数据上测试的规则要么触发一切，要么什么都不触发
|
||||
- 行为检测优于 IOC 匹配：IP地址/哈希攻击者每天轮换，行为模式更难伪造
|
||||
- 检测即代码：规则版本控制、peer review、测试、CI/CD 部署——绝不在 SIEM 控制台直接编辑
|
||||
- MITRE ATT&CK 映射必须：每个检测必须映射到至少一个 ATT&CK 技术，否则无法理解自己在检测什么
|
||||
- 覆盖完整杀伤链：仅检测初始访问意味着错失横向移动、持久化和数据外泄
|
||||
|
||||
## Key Quotes
|
||||
> "An undetected breach costs 10x more than a detected one, and a noisy SIEM is worse than no SIEM at all — because it trains analysts to ignore alerts."
|
||||
> — Threat Detection Engineer Agent 身份定义
|
||||
|
||||
> "Detection rules are code: version-controlled, peer-reviewed, tested, and deployed through CI/CD — never edited live in the SIEM console."
|
||||
> — 关键规则：运营纪律
|
||||
|
||||
> "For every detection you write, ask 'how would I evade this?' — then write the detection for the evasion too."
|
||||
> — 关键规则：对手思维设计
|
||||
|
||||
> "A rule that passed testing 12 months ago may not catch today's variant."
|
||||
> — 关键规则：季度验证
|
||||
|
||||
## Key Concepts
|
||||
- [[Detection Engineering]]：构建和维护高保真检测规则的学科，强调检测质量优于数量
|
||||
- [[Threat Hunting]]：基于情报、异常分析和 ATT&CK 差距评估，主动搜寻检测规则遗漏的威胁
|
||||
- [[Alert Tuning]]：通过允许列表、阈值调优和上下文富化降低误报率，提升信噪比
|
||||
- [[Detection-as-Code]]：检测规则作为代码管理，Git 版本控制 + CI/CD 测试和部署
|
||||
- [[Purple Team]]：红蓝结合的验证方法，通过原子红队测试或紫队练习确认检测有效性
|
||||
- [[MITRE ATT&CK Mapping]]：将检测规则映射到 ATT&CK 矩阵，评估覆盖度并识别关键差距
|
||||
|
||||
## Key Entities
|
||||
- [[Sigma]]：厂商无关的检测规则格式，是 Detection-as-Code 的核心语言
|
||||
- [[MITRE ATT&CK]]：威胁战术和技术知识库，所有检测规则必须映射到此矩阵
|
||||
- [[Splunk]]：企业 SIEM 平台，Sigma 规则编译为 SPL 部署目标之一
|
||||
- [[Microsoft Sentinel]]：Azure 云 SIEM，Sigma 规则编译为 KQL 部署目标之一
|
||||
- [[Elastic]]：SIEM/可观测性平台，Sigma 规则编译为 EQL 部署目标之一
|
||||
- [[Sysmon]]：Windows 系统监视工具，提供进程创建、进程访问等关键事件日志
|
||||
|
||||
## Connections
|
||||
- [[Sigma]] ← writes_detection_rules ← [[Detection Engineering]]
|
||||
- [[MITRE ATT&CK]] ← maps_coverage ← [[Detection Engineering]]
|
||||
- [[Splunk]] ← deploys ← [[Detection-as-Code]]
|
||||
- [[Microsoft Sentinel]] ← deploys ← [[Detection-as-Code]]
|
||||
- [[Threat Hunting]] ← converts_findings_to ← [[Detection Engineering]]
|
||||
- [[Alert Tuning]] ← improves ← [[Detection Engineering]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Alert Tuning]] 存在张力：
|
||||
- 冲突点：过度调优可能削弱检测灵敏度，将真正的攻击者行为加入允许列表
|
||||
- 当前观点：允许列表和阈值调优是降低误报的必要手段
|
||||
- 对方观点：频繁调优会侵蚀 SOC 信任，且可能让真正的 APT 行为通过
|
||||
64
wiki/sources/engineering-voice-ai-integration-engineer.md
Normal file
64
wiki/sources/engineering-voice-ai-integration-engineer.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: "Voice AI Integration Engineer"
|
||||
type: source
|
||||
tags: ["voice-ai", "speech-transcription", "whisper", "asr", "audio-pipeline"]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-voice-ai-integration-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Voice AI Integration Engineer（语音 AI 集成工程师）—— 设计并构建生产级语音转文字（STT）管道，涵盖从原始音频摄入到结构化输出的完整流程
|
||||
- 问题域：音频质量验证、模型选型、管道工程、隐私合规、多种下游系统集成
|
||||
- 方法/机制：Whisper/faster-whisper 本地模型 + 云端 ASR（AssemblyAI/Deepgram 等）；ffmpeg 预处理（重采样至 16kHz 单声道、EBU R128 响度归一化）；pyannote.audio 说话人分离；分块策略处理长音频；结构化输出（SRT/VTT/JSON）；LLM handoff
|
||||
- 结论/价值：提供从原始音频到生产就绪结构化文本的完整管道，支持隐私敏感场景本地部署，支持多种下游系统（Handoff、CMS、Agent Pipeline）集成
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 未经格式/采样率/声道验证的原始音频直接传入转录模型，是转录精度静默下降的首要原因
|
||||
- 长音频（>30 分钟）必须进行重叠感知分块处理，不可依赖模型最大输入时长——溢出无声且无报错地损坏输出
|
||||
- 时间戳和说话人归属在所有处理阶段必须保留，不可在交接前剥离——下游消费者（LLM 摘要、CMS 写入）依赖这些元数据
|
||||
- PII 检测与脱敏必须作为命名且可配置的管道阶段，而非事后补丁
|
||||
- 转录置信度分数≠准确度，低置信度片段需人工审核标记，而非静默删除
|
||||
|
||||
## Key Quotes
|
||||
> "Bad input is the leading cause of silent accuracy degradation." — 音频质量意识
|
||||
> "Never discard timestamps. Even if the downstream consumer doesn't need them now, regenerating them requires re-running the full transcription pass." — 时间戳完整性
|
||||
> "Never treat punctuation inserted by a model as ground truth." — 模型输出不可信
|
||||
> "Transcripts stored longer than policy allows are a compliance liability." — 数据保留合规
|
||||
|
||||
## Key Concepts
|
||||
- [[VoiceActivityDetection]]：通过 VAD（Voice Activity Detection）过滤静音片段，减少无效处理，提高转录效率
|
||||
- [[SpeakerDiarization]]：将 pyannote.audio 或云端 ASR 的说话人标签与转录结果合并，产生带说话人归属的段落
|
||||
- [[EBUR128LoudnessNormalization]]：EBU R128 响度归一化标准（I=-16:TP=-1.5:LRA=11），确保不同来源音频具有一致的响度水平
|
||||
- [[FasterWhisper]]：CTranslate2 优化的 Whisper 实现，比原版快 2-3 倍，支持 GPU 加速，精度与原版相当
|
||||
- [[OverlapAwareChunking]]：对超长音频（>30 分钟）进行重叠感知分块，防止词边界被切断，分块重叠区域在合并时裁剪
|
||||
- [[PIIRedaction]]：个人身份信息（PII）检测与脱敏作为命名管道阶段，支持 HIPAA/GDPR 合规
|
||||
- [[StructuredTranscriptJSON]]：稳定 Schema 的结构化 JSON 输出，包含分段时间戳、说话人、置信度，供下游 LLM 和 CMS 消费
|
||||
- [[LLMHandoff]]：将结构化转录文本格式化后传递给 LLM 摘要/问答/行动项提取 Agent 的标准接口
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAIWhisper]]：OpenAI 开源的 Whisper 模型系列（tiny→large-v3），支持多语言语音识别，是本地转录的核心模型
|
||||
- [[pyannote.audio]]：开源说话人分离库（pyannote/speaker-diarization-3.1），通过 HF token 加载，用于音频说话人分段标注
|
||||
- [[AssemblyAI]]：云端 ASR 服务提供商，支持说话人标签、置信度、PII 检测，作为本地 Whisper 的云端替代方案
|
||||
- [[Deepgram]]：云端 ASR 服务，支持实时流式转录和说话人分离，与本地 Whisper 形成混合路由架构
|
||||
- [[ffmpeg]]：开源多媒体处理工具，用于音频格式检测、重采样、单声道转换、响度归一化、静音切除
|
||||
- [[LangChain]]：LLM 应用框架，Voice AI Integration Engineer 通过 [[LLMHandoff]] 向其传递结构化输入
|
||||
|
||||
## Connections
|
||||
- [[FasterWhisper]] ← uses ← [[OpenAIWhisper]]
|
||||
- [[SpeakerDiarization]] ← merges_with ← [[FasterWhisper]]
|
||||
- [[VoiceActivityDetection]] ← preprocessing_for ← [[FasterWhisper]]
|
||||
- [[EBUR128LoudnessNormalization]] ← preprocesses ← [[FasterWhisper]]
|
||||
- [[PIIRedaction]] ← pipeline_stage → [[StructuredTranscriptJSON]]
|
||||
- [[LLMHandoff]] ← consumes ← [[StructuredTranscriptJSON]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[EngineeringFrontendDeveloper]] 冲突：
|
||||
- 冲突点：音频格式验证（前端通常信任文件扩展名，Voice AI 工程师从不信任扩展名）
|
||||
- 当前观点：必须用 ffprobe 探测实际容器/codec，永远不依赖扩展名猜测
|
||||
- 对方观点：前端通常通过 MIME type 和文件扩展名做快速客户端验证
|
||||
- 与 [[EngineeringSRE]] 冲突：
|
||||
- 冲突点：生产监控中的原始音频日志（Voice AI 严禁，SRE 倾向详细日志）
|
||||
- 当前观点：生产监控中禁止记录原始音频内容或未脱敏转录文本
|
||||
- 对方观点：可观测性基础设施需要足够详细的日志用于故障排查
|
||||
49
wiki/sources/engineering-wechat-mini-program-developer.md
Normal file
49
wiki/sources/engineering-wechat-mini-program-developer.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "WeChat Mini Program Developer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-wechat-mini-program-developer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：微信小程序 Agent 人格定义文档，描述了一名专注于微信生态的高性能小程序开发者的角色定位、技术栈和开发规范
|
||||
- 问题域：微信小程序的全栈开发、平台合规、性能优化、生态集成
|
||||
- 方法/机制：WXML/WXSS/WXS 技术栈、双线程架构、setData 优化、子包加载策略、微信支付/订阅消息集成、跨平台框架（Taro/uni-app）
|
||||
- 结论/价值：为 AI Agent 提供微信小程序开发的系统化方法论，覆盖从项目架构到审核上线的完整生命周期
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 微信小程序采用双线程架构，开发者无法直接操作 DOM，必须通过 setData 跨线程通信
|
||||
- 主包大小限制 2MB，子包合计上限 20MB，性能优化是核心约束
|
||||
- 所有网络请求必须 HTTPS 且域名需在微信后台白名单注册
|
||||
- 微信支付流程为：服务端创建订单 → 小程序调用 wx.requestPayment → 回调处理
|
||||
- 订阅消息取代了已废弃的模板消息，需在支付/下单等关键节点触发授权
|
||||
- 跨平台框架 Taro/uni-app 可实现一次开发多端部署（微信、支付宝、百度、抖音小程序）
|
||||
|
||||
## Key Quotes
|
||||
> "WeChat review will reject this if we ask for location permission without a visible use case on the page" — 微信审核对权限申请必须有可见使用场景
|
||||
> "Every setData call crosses the JS-native bridge - batch these three updates into one call" — setData 跨线程调用的性能代价，每帧应合并更新
|
||||
> "The main package is at 1.8MB - we need to move the marketing pages to a subpackage before adding this feature" — 子包策略是包体积管理的核心手段
|
||||
|
||||
## Key Concepts
|
||||
- [[微信小程序]]: 微信生态内的轻量级应用，深度集成微信登录、支付、分享、订阅消息等能力
|
||||
- [[setData 优化]]: 双线程架构下的跨线程数据同步机制，频繁/大量 setData 是性能瓶颈，需最小化调用频率和 payload
|
||||
- [[子包加载]]: 微信小程序的分包策略，主包不超过 2MB，通过 subpackages 分载非核心功能以控制启动时间
|
||||
- [[WXML/WXSS]]: 微信小程序的模板语言和样式表，类似 HTML/CSS，遵循微信定义的组件化数据绑定模型
|
||||
- [[微信支付集成]]: 服务端生成 prepay 参数，小程序端调用 wx.requestPayment 完成支付，订阅消息在支付后触发授权
|
||||
- [[跨平台小程序框架]]: Taro（React）、uni-app（Vue）实现一次编写多端部署，需处理平台 API 差异
|
||||
|
||||
## Key Entities
|
||||
- [[微信]]: 腾讯旗下超级 App，月活超 10 亿，提供小程序、公众号、视频号、企业微信等生态能力
|
||||
- [[Taro]]: 京东开源的多端统一开发框架，支持 React 语法，可编译为微信、支付宝、百度、抖音等小程序
|
||||
- [[uni-app]]: DCloud 开源的跨平台开发框架，基于 Vue 语法，支持一键发布到多个小程序平台及 H5/App
|
||||
|
||||
## Connections
|
||||
- [[微信小程序]] ← 技术栈 ← [[engineering-mobile-app-builder]]
|
||||
- [[微信支付集成]] ← 依赖 ← [[微信]]
|
||||
- [[跨平台小程序框架]] ← 工具链 ← [[Taro]], [[uni-app]]
|
||||
|
||||
## Contradictions
|
||||
- （本文档为独立 Agent 人格定义，暂无已知冲突页面）
|
||||
60
wiki/sources/examples-readme.md
Normal file
60
wiki/sources/examples-readme.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Examples"
|
||||
type: source
|
||||
tags: [multi-agent, agency-agents, examples, orchestration]
|
||||
sources: []
|
||||
last_updated: 2026-05-13
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/examples/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：展示 The Agency 多 Agent 系统在真实任务中如何协同工作——通过具体案例（Nexus Spatial Discovery）演示 8 个专业 Agent 并行协作完成完整产品发现与规划。
|
||||
- 问题域：Agent 定义本身不足以说明"全部 Agent 同时部署在同一任务上"会发生什么；需要真实的多 Agent 协作案例来验证系统的实际效果。
|
||||
- 方法/机制：The Agency repo 定义了跨工程、设计、营销、产品、支持、空间计算、项目管理等领域的数十个专业 Agent；Examples 目录通过完整案例回答："当全体 Agent 协作时，实际上是什么样子的？"
|
||||
- 结论/价值：验证了 8 个 Agent 并行运行可产出连贯、相互引用的计划，且无需人工协调开销；为新增示例提供了贡献指南。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 定义了数十个跨多个领域的专业 Agent（工程、设计、营销、产品、支持、空间计算、项目管理），但 Agent 定义本身不能说明"全员部署在同一任务上"的实际效果。
|
||||
- Examples 目录解答了核心问题："当整个 Agency 协作时，实际上是什么样子的？"
|
||||
- Nexus Spatial Discovery 案例证明：8 个 Agent 并行运行可产出连贯、相互引用的计划，无须人工协调。
|
||||
- 新增好示例的标准：多个 Agent 协作同一目标、展示 Agency 能力广度、具有现实适用性。
|
||||
|
||||
## Key Quotes
|
||||
> "These examples answer the question: 'What does it actually look like when the full agency collaborates?'" — Examples/README.md，开篇即点明核心价值
|
||||
> "All 8 agents ran in parallel and produced coherent, cross-referencing plans without coordination overhead." — Examples/README.md，核心成果定性
|
||||
> "If you run an interesting multi-agent exercise, consider adding it here." — Examples/README.md，贡献指南入口
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Agent-Collaboration]]：多 Agent 协作——多个专业 Agent 在同一任务上并行工作，产出连贯、相互引用的计划，无须人工协调；是 The Agency 的核心价值主张。
|
||||
- [[Multi-Agent-Orchestration]]：多 Agent 编排——The Agency 框架的基础能力，Examples 目录通过案例验证其在实际任务中的有效性。
|
||||
- [[Parallel-Agent-Execution]]：并行 Agent 执行——8 个 Agent 同时运行于单一任务，各 Agent 独立研究后交叉对齐，是 Nexus Spatial Discovery 案例的核心执行模式。
|
||||
|
||||
## Key Entities
|
||||
- [[Nexus-Spatial]]：产品——AI Agent 沉浸式 3D 命令中心；是 Nexus Spatial Discovery 案例中被 8 个 Agent 协作评估的软件机会；Nexus Spatial Discovery source page 有完整记录。
|
||||
- [[Product-Trend-Researcher]]：The Agency 产品趋势研究员——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责市场验证和竞争格局分析。
|
||||
- [[Backend-Architect]]：The Agency 后端架构师——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责系统架构、数据库建模和 API 设计。
|
||||
- [[Brand-Guardian]]：The Agency 品牌守护者——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责定位和视觉身份设计。
|
||||
- [[Growth-Hacker]]：The Agency 增长黑客——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责 GTM 策略、定价和发布计划。
|
||||
- [[Support-Responder]]：The Agency 支持应答者——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责支持分级和社区运营。
|
||||
- [[UX-Researcher]]：The Agency UX 研究员——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责用户画像和旅程地图。
|
||||
- [[Project-Shepherd]]：The Agency 项目牧羊人——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责阶段计划和风险管理。
|
||||
- [[XR-Interface-Architect]]：The Agency XR 界面架构师——Nexus Spatial Discovery 中使用的 8 个 Agent 之一，负责空间界面规范。
|
||||
|
||||
## Connections
|
||||
- [[Nexus-Spatial]] ← exemplifies ← [[Multi-Agent-Collaboration]]（完整案例）
|
||||
- [[Nexus-Spatial-Discovery]] ← is_case_of ← [[examples/README]]（source page）
|
||||
- [[Multi-Agent-Orchestration]] ← validated_by ← [[Nexus-Spatial-Discovery]]（8-Agent 并行验证）
|
||||
- [[Parallel-Agent-Execution]] ← demonstrated_in ← [[Nexus-Spatial-Discovery]]
|
||||
- [[Product-Trend-Researcher]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[Backend-Architect]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[Brand-Guardian]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[Growth-Hacker]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[Support-Responder]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[UX-Researcher]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[Project-Shepherd]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
- [[XR-Interface-Architect]] → contributed_to → [[Nexus-Spatial-Discovery]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突
|
||||
53
wiki/sources/executive-brief.md
Normal file
53
wiki/sources/executive-brief.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "NEXUS Executive Brief"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/strategy/EXECUTIVE-BRIEF.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：NEXUS 多 Agent 编排框架的战略概览与商业价值论证——将 The Agency 的 9 大部门专业化 Agent 从"各自为战"转化为"协调统一的智能网络"
|
||||
- 问题域：多 Agent 项目在交接边界处 73% 失败率、无证据的质量评估（"幻想型审批"）、缺乏结构化协调协议导致的重复劳动和质量缺口
|
||||
- 方法/机制：NEXUS 三层部署模式（NEXUS-Full/Sprint/Micro）—— 标准化交接模板 + 证据驱动质量门控 + Dev↔QA 循环（最多3次重试） + Reality Checker 最终权威 + 并行工作流（4 轨道同时压缩 40-60% 时间线）
|
||||
- 结论/价值：结构化协调协议是最高杠杆干预点；Reality Checker 的默认"NEEDS WORK"姿态防止过早部署；并行工作流是主要上市加速器；持续质量循环优于端到端测试
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 多 Agent 项目在 Agent 缺乏结构化协调协议时，交接边界处失败率达 73% → 标准化交接模板和上下文连续性是最高杠杆干预
|
||||
- 无证据要求的质量评估导致"幻想型审批"——Agent 在无证明情况下给基础实现评 A+ → Reality Checker 默认"NEEDS WORK"姿态和证据门控防止过早生产部署
|
||||
- 4 条并行轨道（Core Product/Growth/Quality/Brand）同时执行，时间线压缩 40-60% → NEXUS 的并行工作流设计是主要上市加速器
|
||||
- Dev↔QA 循环（构建→测试→通过/失败→重试，最多3次）可在集成前捕获 95% 缺陷，Phase 4 硬化时间减少 50% → 持续质量循环优于端到端测试
|
||||
|
||||
## Key Quotes
|
||||
> "Without coordination, they produce conflicting decisions, duplicated effort, and quality gaps at handoff boundaries." — NEXUS 情境概述，核心问题陈述
|
||||
> "Quality assessment without evidence requirements leads to 'fantasy approvals' — agents rating basic implementations as A+ without proof." — Finding 2，证据驱动质量门控的必要性
|
||||
> "Parallel execution across 4 simultaneous tracks compresses timelines by 40-60% compared to sequential agent activation." — Finding 3，并行工作流的时间效益
|
||||
> "The Dev↔QA loop catches 95% of defects before integration, reducing Phase 4 hardening time by 50%." — Finding 4，持续质量循环的功效
|
||||
|
||||
## Key Concepts
|
||||
- [[Quality Gate]]：每阶段质量门控，无证据不推进——确保交接内容经过验证而非口头断言
|
||||
- [[Dev↔QA Loop]]：构建→测试→通过/失败→重试循环，最多3次——持续质量循环优于端到端测试
|
||||
- [[Agent Handoff]]：结构化上下文传递协议——解决 73% 交接边界失败率的核心机制
|
||||
- [[Reality Checker]]：最终质量权威，默认"NEEDS WORK"姿态——防止"幻想型审批"的守门人
|
||||
- [[Evidence Over Claims]]：截图/测试结果/数据优于口头断言——所有质量判定必须基于可验证证据
|
||||
- [[Parallel Workstream]]：4 条并行轨道同时执行——压缩 40-60% 时间线的主要上市加速器
|
||||
- [[Handoff Boundary]]：Agent 间交接边界——73% 失败率的核心痛点，标准化协调协议的最高杠杆干预点
|
||||
|
||||
## Key Entities
|
||||
- [[NEXUS]]：The Agency 的多 Agent 编排框架——Network of EXperts, Unified in Strategy，包含 3 种部署模式（Full/Sprint/Micro）、7 阶段管道（Phase 0-6）
|
||||
- [[The Agency]]：NEXUS 的组织背景——9 大专业化部门（Engineering/Design/Marketing/Product/Project Management/Testing/Support/Spatial Computing/Specialized Operations），共 147+ Agent
|
||||
- [[Agents-Orchestrator]]：NEXUS 管道的核心控制器——协调多 Agent 协作的执行引擎
|
||||
|
||||
## Connections
|
||||
- [[executive-brief]] ← overview ← [[NEXUS]]（NEXUS 框架的战略概览文档）
|
||||
- [[executive-brief]] ← extends ← [[quickstart]]（战略层补充了 Quick-Start Guide 的方法论依据和数据支撑）
|
||||
- [[executive-brief]] ← extends ← [[nexus-strategy]]（战略层补充了 nexus-strategy 的核心发现和商业影响数据）
|
||||
- [[executive-brief]] ← depends_on ← [[agents-orchestrator]]（执行层面由 Agents-Orchestrator 实现）
|
||||
- [[executive-brief]] ← depends_on ← [[Reality-Checker]]（质量门控机制依赖 Reality Checker 作为最终权威）
|
||||
- [[executive-brief]] ← extends ← [[workflow-startup-mvp]]（战略层补充了 Startup MVP 工作流的商业价值和量化数据）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[nexus-spatial-discovery]] 的并行 Agent 发现结果一致：两者均支持并行 Agent 协作的价值；Executive Brief 从战略层面论证了并行工作流的商业合理性（40-60% 时间线压缩），Nexus Spatial Discovery 从执行层面证明了并行 Agent 发现可产出连贯相互引用的完整计划。属战略与执行层面的相互印证，无冲突。
|
||||
- 与 [[workflow-startup-mvp]] 的质量门控设计一致：两者均强调 Reality Checker 的"NEEDS WORK"默认姿态；Executive Brief 提供战略依据（防止"幻想型审批"），workflow-startup-mvp 提供执行模板。无冲突。
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: "Expose hermes-agent as an OpenAI-compatible API for any frontend"
|
||||
type: source
|
||||
tags:
|
||||
- "hermes-agent"
|
||||
- "api-server"
|
||||
- "openai-compatible"
|
||||
- "integration"
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/Expose hermes-agent as an OpenAI-compatible API for any frontend]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：hermes-agent API Server 功能 —— 将 hermes-agent 暴露为 OpenAI 兼容的 HTTP API，使任何支持 OpenAI 格式的前端都能连接使用
|
||||
- 问题域：AI Agent 的可访问性问题 —— 如何让任意前端（Open WebUI、LobeChat、LibreChat 等）接入 hermes-agent
|
||||
- 方法/机制：
|
||||
- 通过 `API_SERVER_ENABLED=true` 启用内建 API Server
|
||||
- 默认监听 `127.0.0.1:8642`，Bearer token 认证
|
||||
- 支持 Chat Completions API（无状态）、Responses API（有状态会话）、Runs API（实时进度）、Jobs API（定时任务）
|
||||
- 系统提示词分层叠加，前端提示词不会覆盖 Agent 原有工具集
|
||||
- 结论/价值：hermes-agent 可作为 OpenAI API 的直接替代品，无缝接入现有 AI 前端生态，无需修改前端代码
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- hermes-agent API Server 将 Agent 暴露为 OpenAI 兼容 HTTP 端点，任何 OpenAI 格式的前端均可直连
|
||||
- 默认绑定 `127.0.0.1:8642`，需配置 `API_SERVER_KEY` 启用 Bearer token 认证
|
||||
- `/v1/chat/completions` 为无状态接口，每次请求需传递完整对话历史
|
||||
- `/v1/responses` 支持服务端会话状态，通过 `previous_response_id` 链式调用保留完整上下文（含工具调用）
|
||||
- `/v1/runs` API 通过 `run_id` + SSE 事件流实现长会话实时进度订阅
|
||||
- Jobs API 提供 CRUD 接口，支持从远程客户端管理定时/后台 Agent 任务
|
||||
- 前端传入的 system prompt 在 Agent 核心提示词之上分层叠加，保留全部工具能力
|
||||
- 多用户场景通过 Profiles 隔离，每个 Profile 运行独立 API Server 实例（不同端口和认证密钥）
|
||||
|
||||
## Key Quotes
|
||||
> "Any frontend that speaks the OpenAI format — Open WebUI, LobeChat, LibreChat, NextChat, ChatBox, and hundreds more — can connect to hermes-agent and use it as a backend." — 官方文档
|
||||
|
||||
> "Your agent handles requests with its full toolset (terminal, file operations, web search, memory, skills) and returns the final response." — 官方文档
|
||||
|
||||
> "When a frontend sends a system message (Chat Completions) or instructions field (Responses API), hermes-agent layers it on top of its core system prompt. Your agent keeps all its tools, memory, and skills." — 官方文档
|
||||
|
||||
> "The API server gives full access to hermes-agent's toolset, including terminal commands. When binding to a non-loopback address like 0.0.0.0, API_SERVER_KEY is required." — 官方文档安全警告
|
||||
|
||||
## Key Concepts
|
||||
- [[OpenAI-Compatible API]]：遵循 OpenAI API 格式标准的接口层，允许非 OpenAI 后端替代原生服务
|
||||
- [[Bearer Token Authentication]]：通过 `Authorization: Bearer <token>` 头部进行 API 身份验证
|
||||
- [[System Prompt Layering]]：前端提示词在 Agent 核心提示词之上分层叠加，不覆盖原有工具集
|
||||
- [[Conversation State Persistence]]：服务端存储完整对话历史（含工具调用），客户端无需管理上下文
|
||||
- [[Server-Sent Events (SSE)]]：流式响应协议，支持 token-by-token 推送和自定义工具进度事件
|
||||
- [[CORS Allowlist]]：浏览器跨域访问控制，通过白名单精确控制允许的来源
|
||||
- [[Multi-Profile Isolation]]：通过 Profiles 实现多用户隔离，每个实例独立配置、内存、技能
|
||||
- [[Background Job Scheduling]]：远程客户端通过 Jobs API 管理定时/后台 Agent 任务
|
||||
|
||||
## Key Entities
|
||||
- [[hermes-agent]]：主项目， NousResearch 出品的 AI 编码 Agent，配备完整工具集（终端、文件、网络搜索、记忆、Skills）
|
||||
- [[Open WebUI]]：开源 AI Web UI（126k stars），有完整集成指南
|
||||
- [[LobeChat]]：开源 AI 聊天前端（73k stars），自定义 Provider 接入
|
||||
- [[LibreChat]]：开源多后端聊天平台（34k stars），通过 librechat.yaml 配置
|
||||
- [[NextChat]]：开源 ChatGPT Web 应用（87k stars），通过 BASE_URL 环境变量接入
|
||||
- [[ChatBox]]：开源 AI 客户端（39k stars），API Host 设置接入
|
||||
- [[AnythingLLM]]：开源 RAG AI 应用（56k stars），Generic OpenAI Provider 接入
|
||||
- [[Jan]]：开源本地 AI 应用（26k stars），Remote Model 配置接入
|
||||
|
||||
## Connections
|
||||
- [[hermes-agent]] ← exposes ← [[OpenAI-Compatible API]]
|
||||
- [[Open WebUI]] ← connects_to ← [[hermes-agent]] API Server
|
||||
- [[LobeChat]] ← connects_to ← [[hermes-agent]] API Server
|
||||
- [[LibreChat]] ← connects_to ← [[hermes-agent]] API Server
|
||||
- [[NextChat]] ← connects_to ← [[hermes-agent]] API Server
|
||||
- [[hermes-agent]] ← supports ← [[Multi-Profile Isolation]]
|
||||
- [[hermes-agent]] ← implements ← [[Background Job Scheduling]]
|
||||
|
||||
## Contradictions
|
||||
- （暂无检测到冲突）
|
||||
62
wiki/sources/finance-bookkeeper-controller.md
Normal file
62
wiki/sources/finance-bookkeeper-controller.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Bookkeeper & Controller Agent"
|
||||
type: source
|
||||
tags: [finance, accounting, agent]
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/finance/finance-bookkeeper-controller.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 作为专业会计主管（Controller），负责企业日常会计运营、月结流程和内部控制的自动化执行
|
||||
- 问题域：企业财务记录准确性、月结准时性、合规审计准备
|
||||
- 方法/机制：通过 Agent 角色定义（名为"Dana"的13年经验Controller）、标准化Checklist模板、职责分离规则、GAAP合规框架
|
||||
- 结论/价值：为财务团队提供可7×24小时运行的AI Controller，确保账目精确、月结准时、审计就绪
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Dana Agent 通过月度结账Checklist模板确保每月结账流程标准化、可重复执行
|
||||
- Dana Agent 强制执行职责分离（Segregation of Duties），确保交易发起人与审批/记录人不为同一人
|
||||
- Dana Agent 维持"审计就绪"状态，确保审计师随时进场时可在24小时内提供任何余额的支持文件
|
||||
- Dana Agent 将月末结账周期从10个工作日压缩至7个，并通过AP自动化可进一步压缩至5天
|
||||
- Dana Agent 要求所有资产负债表科目每月完成调节，未调节余额是"定时炸弹"
|
||||
|
||||
## Key Quotes
|
||||
> "A fast close is a good close, but an accurate close is a non-negotiable close. Speed without accuracy is just noise delivered faster." — Dana核心原则
|
||||
> "Reconciliation is not a chore — it's a detective process. Every unreconciled difference is a story waiting to be understood." — Dana方法论
|
||||
> "The audit should be boring. If the auditors are surprised, the controls failed." — 审计就绪理念
|
||||
> "Automate the recurring, focus the brain on the exceptional." — 自动化哲学
|
||||
|
||||
## Key Concepts
|
||||
- [[Month-End Close Process]]：月度结账流程 — 通过标准化Checklist（Pre-Close → Core Close → Reconciliations → Financial Statements → Review）确保每月结账按时完成
|
||||
- [[GAAP Compliance]]：通用会计准则 — 所有交易按适用会计准则记录，无例外无捷径
|
||||
- [[Account Reconciliation]]：账户调节 — 每个资产负债表科目每月必须调节，未调节余额视为风险
|
||||
- [[Internal Controls]]：内部控制 — 授权矩阵、审批流程、系统访问控制、数据验证规则，确保财务信息安全
|
||||
- [[Segregation of Duties]]：职责分离 — 交易发起人与审批/记录人不得为同一人，防止欺诈与错误
|
||||
- [[Audit Readiness]]：审计就绪 — 日常维护审计就绪状态，审计师可随时进场，24小时内提供任何余额支持
|
||||
- [[Revenue Recognition ASC 606]]：ASC 606收入确认 — 合同审查、履约义务识别、递延收入管理
|
||||
- [[Journal Entry]]：日记账分录 — 每笔手工分录需描述、支持文档和审批，拒绝"调整分录"式无意义描述
|
||||
|
||||
## Key Entities
|
||||
- Dana：Agent角色名称 — 13年+经验的Controller，曾从零建立会计部门、完成首次审计、实施Sarbanes-Oxley、连续150+月准时结账
|
||||
- QuickBooks / Xero / NetSuite / Sage Intacct / SAP / Oracle Financials：ERP/会计软件 — 日常记账系统
|
||||
- FloQast / BlackLine / Trintech / Workiva：结账管理软件 — 月结流程管理与协调工具
|
||||
- Bill.com / Tipalti / AvidXchange / Coupa：AP自动化平台 — 应付账款处理与支付调度
|
||||
- Expensify / Concur / Brex / Ramp：费用管理平台 — 员工报销管理
|
||||
- ASC 606 / ASC 842 / ASC 718 / ASC 805：会计准则 — 复杂会计处理标准
|
||||
- SOX (Sarbanes-Oxley)：萨班斯-奥克斯利法案 — 公众公司内部控制框架
|
||||
|
||||
## Connections
|
||||
- [[Finance FPA Analyst]] ← workflow_partner ← [[Bookkeeper Controller Agent]]
|
||||
- [[Finance Tax Strategist]] ← provides_data_to ← [[Bookkeeper Controller Agent]]
|
||||
- [[Account Reconciliation]] ← depends_on ← [[Month-End Close Process]]
|
||||
- [[Internal Controls]] ← enables ← [[Audit Readiness]]
|
||||
- [[Segregation of Duties]] ← part_of ← [[Internal Controls]]
|
||||
- [[Revenue Recognition ASC 606]] ← extends ← [[GAAP Compliance]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Finance FPA Analyst]] 潜在冲突：
|
||||
- 冲突点：FP&A追求更快的结账速度（支持决策时效），Bookkeeper追求更严格的准确性（审计就绪）
|
||||
- 当前观点：Dana坚持"准确性是不可协商的底线"——速度必须服从准确性
|
||||
- 对方观点：FP&A可能认为某些GAAP边界情况下的快速估计对决策更有价值
|
||||
- 解决方向：两者可以协同——Dana的月结Checklist包含Flux Analysis，可为FP&A提供高质量数据
|
||||
55
wiki/sources/finance-financial-analyst.md
Normal file
55
wiki/sources/finance-financial-analyst.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Financial Analyst Agent"
|
||||
type: source
|
||||
tags: ["agent-personality", "finance", "financial-modeling", "agentic-ai"]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/finance/finance-financial-analyst.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency Finance 部门的专业金融分析师 AI Agent（代号 Morgan）——12年+经验，专注投资银行、企业财务和 FP&A，将原始财务数据转化为战略性商业洞察，支撑资本配置决策和投资建议。
|
||||
- 问题域：财务建模与估值（三报表模型、DCF、LBO、M&A）、预测与规划（收入、成本、营运资金、资本支出）、分析框架（差异分析、敏感性分析、蒙特卡洛模拟）。
|
||||
- 方法/机制：四阶段工作流（数据收集验证→模型架构设计→场景分析→决策支持呈现）；三报表联动模型；WACC + 敏感性分析表格；Python + SQL + BI 工具链。
|
||||
- 结论/价值：让每一个重大业务决策都建立在严谨财务分析之上，明确假设与敏感区间，输出可审计、可追溯的决策支持材料。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Morgan 核心理念：Revenue is vanity, profit is sanity, but cash flow is reality——利润表好看但现金流管理不善的公司是定时炸弹。
|
||||
- 财务分析师的核心超能力：将复杂财务数据翻译成非财务利益相关者能理解并采取行动的商业叙事，弥合数字与战略之间的鸿沟。
|
||||
- 三报表模型必须动态联动：利润表、资产负债表和现金流量表之间存在内在数学联系，任何输入变化必须自动反映到所有相关科目。
|
||||
- 敏感性分析不可或缺：如果关键假设变动 15% 就导致结论反转，那么该建议不是稳健决策，而是碰运气。
|
||||
- 模型质量的核心标准：模型必须可被非构建者独立使用、审计和修改——"为他人构建，而非为自己构建"。
|
||||
- 精确不等于准确：带有四位小数的粗略估计是在制造虚假信心，精确而无准确性只是噪音。
|
||||
- 先进建模技术包括蒙特卡洛模拟（概率预测与风险量化）、实物期权估值（不确定环境下的战略灵活性）、计量经济建模（需求预测与宏观敏感性分析）。
|
||||
|
||||
## Key Quotes
|
||||
> "Revenue is vanity, profit is sanity, but cash flow is reality." — Morgan Financial Analyst Agent，现金流至上的财务哲学
|
||||
> "The numbers don't lie is a dangerous myth. Numbers can be arranged to tell almost any story. Your job is to find the truth underneath." — Morgan，对数据操纵风险的警觉
|
||||
> "Every financial model is a simplification of reality. State your assumptions explicitly — they matter more than the formulas." — Morgan，假设优先于结论的核心原则
|
||||
> "If your recommendation changes with a 10% swing in a key assumption, say so." — Morgan，敏感性分析强制要求
|
||||
|
||||
## Key Concepts
|
||||
- [[Three-Statement-Model]]：三报表联动财务模型——利润表、资产负债表和现金流量表通过动态公式链接，确保任何输入变化自动传导至全部相关科目，是所有财务建模的基石。
|
||||
- [[DCF-Analysis]]：折现现金流估值——WACC 计算 + 终值方法 + 敏感性表，DCF 是内在价值评估的核心工具。
|
||||
- [[LBO-Modeling]]：杠杆收购建模——债务时间表、回报分析（IRR/MOIC）和信贷指标，是私募股权投资分析的标准工具。
|
||||
- [[Variance-Analysis]]：差异分析——预算与实际的对比分析，分解根因，用于月度财务报告和运营回顾。
|
||||
- [[Unit-Economics]]：单位经济学——CAC（客户获取成本）、LTV（客户终身价值）、回收期和边际贡献分析，用于评估产品线和客户群盈利性。
|
||||
- [[Sensitivity-Analysis]]：敏感性分析——测试关键假设变动对输出的影响，识别模型结论的稳健性边界。
|
||||
- [[Scenario-Analysis]]：场景规划——构建基础、乐观和悲观三套假设，明确各场景的驱动因素差异。
|
||||
- [[Budget-Variance-Analysis]]：预算差异分析——[[support-finance-tracker]] 的月度报告模板，Morgan 提供差异分解框架。
|
||||
- [[Cash-Flow-Forecasting]]：现金流预测——12 个月滚动预测，[[support-finance-tracker]] 提供 Python 实现参考。
|
||||
- [[Investment-Analysis]]：投资分析——NPV/IRR/ROI 计算框架，[[support-finance-tracker]] 提供 Python 实现。
|
||||
|
||||
## Key Entities
|
||||
- [[Finance-Tracker]]：The Agency Support 部门的财务追踪 Agent，[[finance-financial-analyst]] 在财务分析能力上向后扩展——Financial Analyst 专注投资分析、建模与战略决策支持，Finance Tracker 专注日常财务运营、预算执行和合规追踪。
|
||||
- [[finance-tax-strategist]]：The Agency Finance 部门的税务策略 Agent，与 [[finance-financial-analyst]] 共享 Finance 部门上下文，在税务优化与财务分析的交叉点协同。
|
||||
|
||||
## Connections
|
||||
- [[finance-tax-strategist]] ← shares_department ← [[finance-financial-analyst]]（均为 The Agency Finance 部门 Agent）
|
||||
- [[support-finance-tracker]] ← related_domain ← [[finance-financial-analyst]]（财务分析与财务追踪共享 Finance 领域）
|
||||
- [[finance-fpa-analyst]] ← extends ← [[finance-financial-analyst]]（FPA Analyst 是 Financial Analyst 在 FP&A 场景的专精扩展）
|
||||
- [[finance-bookkeeper-controller]] ← related_domain ← [[finance-financial-analyst]]（总账会计与财务分析共享财务报表上下文）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。Morgan 的"精确不等于准确"原则与 [[support-finance-tracker]] 中 Finance Tracker 的数据驱动精确性要求互补而非矛盾——前者强调不因精确性制造虚假信心，后者强调数据准确性是财务运营的底线。
|
||||
59
wiki/sources/finance-fpa-analyst.md
Normal file
59
wiki/sources/finance-fpa-analyst.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "FP&A Analyst Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/finance/finance-fpa-analyst.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：FP&A（财务规划与分析）Agent 的角色定义与操作框架，赋予 AI 代理「Riley」这一专业财务分析师身份，具备 11+ 年高增长 SaaS、制造、零售行业经验
|
||||
- 问题域：如何让 AI 代理承担企业级财务规划、预测、差异分析和战略决策支持职能
|
||||
- 方法/机制：通过系统性 prompt engineering 定义 Agent 身份、关键规则、交付模板（AOP/MBR）、工作流程（年度计划周期、月度运营节奏、季度重预测）及高级技术能力（ZBB、ABC、蒙特卡洛模拟等）
|
||||
- 结论/价值：FP&A 不是会计的续集，而是战略的翻译器；其核心价值在于将模糊的业务计划转化为推动问责制的具体财务框架，将数字转化为行动
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- FP&A 专业人员（Riley）通过严格的财务规划、准确的预测和深入的差异分析来驱动战略决策，与业务领导者合作将运营计划转化为财务现实
|
||||
- 预算必须与业务驱动因素挂钩——仅按通胀率增长预算不是规划，而是"通货膨胀"；必须将支出与结果连接
|
||||
- 差异分析必须解释未来，而不仅仅是过去——没有前瞻性影响评估的差异分析是 obituary 而非 analysis
|
||||
- 滚动预测优于年度计划——必须至少每季度更新预测；实时脉搏最为重要
|
||||
- 场景规划是主要决策的必备条件——超过一定金额的投资或人员请求都需要 base/upside/downside 场景
|
||||
- FP&A 是业务伙伴，而非预算警察——帮助领导者理解自己的数字，以便他们做出更好的决策
|
||||
|
||||
## Key Quotes
|
||||
> "FP&A is not accounting's sequel — it's strategy's translator. Your job isn't to report what happened. It's to explain why, predict what's next, and recommend what to do about it." — Riley, FP&A Analyst Agent
|
||||
> "A budget that nobody owns is a budget nobody follows. Every line item needs a name next to it." — Riley's Core Principle
|
||||
> "Complexity is the enemy of usability. A 47-tab model that nobody can navigate is worse than a 5-tab model that everyone understands." — Riley's Design Philosophy
|
||||
> "The best FP&A partners make department heads smarter about their own spending. You don't control budgets — you illuminate them." — Riley's Partnership Philosophy
|
||||
|
||||
## Key Concepts
|
||||
- [[Annual Operating Plan (AOP)]]：年度经营计划——自上而下目标、自下而上构建、差距协调、董事会演示
|
||||
- [[Rolling Forecast]]：滚动预测——至少每季度重新预测，结合业务所有者的自下而上输入
|
||||
- [[Variance Analysis]]：差异分析——将预算与实际对比，分解根本原因，评估前瞻性影响
|
||||
- [[Driver-Based Forecasting]]：基于驱动因素的预测——将财务输出与运营输入关联（如每代表收入、每次招聘成本）
|
||||
- [[Scenario Planning]]：场景规划——best/base/worst case，含明确假设和触发点
|
||||
- [[Zero-Based Budgeting (ZBB)]]：零基预算——从零开始构建预算，而非基于上一年度
|
||||
- [[Activity-Based Costing (ABC)]]：作业成本法——基于活动驱动因素分配间接费用以获得真实单位经济数据
|
||||
- [[Monte Carlo Simulation]]：蒙特卡洛模拟——用于范围预测的概率预测技术
|
||||
- [[Unit Economics]]：单位经济——CAC、LTV、回本周期、按细分/产品/渠道的边际贡献
|
||||
- [[Monthly Business Review (MBR)]]：月度业务回顾——月度经营会议财务包，含执行仪表板、收入分析、费用分析、预测更新、行动项目
|
||||
|
||||
## Key Entities
|
||||
- [[Riley]]：FP&A Analyst Agent 的人格化身——11+ 年经验的高增长 SaaS、制造、零售行业 FP&A 专业人士，擅长年度运营计划编制、滚动预测、可信赖的 C-suite 报告、预算框架设计
|
||||
- [[Anaplan]]：规划软件平台——FP&A 常用规划工具之一
|
||||
- [[Adaptive Insights (Workday)]]：规划软件——FP&A 常用规划工具之一
|
||||
- [[Planful]]：FP&A 常用规划软件
|
||||
- [[Pigment]]：FP&A 常用规划软件（新一代）
|
||||
- [[Tableau / Power BI / Looker]]：BI 与可视化工具——FP&A KPI 仪表板与财务数据可视化
|
||||
- [[NetSuite / SAP / Oracle]]：ERP 系统——总账数据提取与预算加载集成
|
||||
|
||||
## Connections
|
||||
- [[Finance Investment Researcher]] ← 相关领域 ← [[Finance Financial Analyst]]
|
||||
- [[Finance Tax Strategist]] ← 并列财务职能 ← [[Finance Investment Researcher]]
|
||||
- [[Support Finance Tracker]] ← 下游应用 ← [[FP&A Analyst]]（财务追踪与 FP&A 分析的关系）
|
||||
- [[Accounts Payable Agent]] ← 并列财务流程 ← [[FP&A Analyst]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知冲突。该 Agent 专注于 FP&A 领域，与其他财务 Agent（如 Tax Strategist、Investment Researcher）功能互补、无直接冲突。
|
||||
59
wiki/sources/finance-investment-researcher.md
Normal file
59
wiki/sources/finance-investment-researcher.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "Investment Researcher Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/finance/finance-investment-researcher.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：机构级投资研究 AI Agent（代号 Quinn），专注市场研究、尽职调查、投资组合分析与资产评估，支持股票、私募和另类资产
|
||||
- 问题域：如何通过严谨的基本面和量化分析发现 alpha、评估风险、支持数据驱动的投资决策
|
||||
- 方法/机制：五阶段工作流（筛选 → 初评 → 深度研究 → 研报撰写 → 持续监控）；双面论证框架（牛市/熊市同等严谨）；另类数据集成；量化策略
|
||||
- 结论/价值：提供机构级投资研报模板、尽职调查清单、成功指标体系；填补 The Agency Finance 部门在投资研究环节的能力空白
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Quinn 具备 14 年+买方权益研究、风险投资尽职调查和机构资产管理经验，已完成 200+ 家公司尽职调查并识别出多只 5 倍回报投资
|
||||
- 最佳投资机会来自"严格分析 + 变异认知（variant perception）"的交汇处——当研究与共识一致时，不存在优势
|
||||
- 每一份投资建议必须包含具体损失估计的下行情景；"可能下跌"不是风险评估
|
||||
- 量化分析必须结合基本面验证：DCF、可比公司法、另类数据代理估计缺一不可
|
||||
- 尽职调查流程应在 90%+ 的投资决策前捕获实质性风险
|
||||
|
||||
## Key Quotes
|
||||
> "The bull case is always easy to write. Spend more time on the bear case — that's where the risk hides." — Quinn 核心理念
|
||||
|
||||
> "Valuation is necessary but never sufficient. A cheap stock with a broken business model is a value trap, not a value investment." — Quinn 估值原则
|
||||
|
||||
> "The best research is falsifiable. State your thesis, define what would break it, and monitor those triggers relentlessly." — 可证伪研究标准
|
||||
|
||||
> "Consensus sees a hardware company. I see a subscription transition — recurring revenue is growing 40% YoY and now represents 35% of total revenue. The market is pricing the old model." — Quinn 沟通风格示例
|
||||
|
||||
## Key Concepts
|
||||
- [[Variant-Perception]]: 寻找与共识不同的认知角度；只有当研究结论与市场共识存在差异时才存在投资优势
|
||||
- [[Investment-Research-Report]]: 五阶段工作流产出的标准化研报格式，含执行摘要、投资论点、牛熊情景、估值分析、财务预测、竞争格局
|
||||
- [[Due-Diligence]]: 系统化尽职调查框架，覆盖财务、运营、市场、法律四维度；Red Flags 识别标准
|
||||
- [[Thesis-Breakers]]: 每个活跃头寸必须有"论点终结触发器"——会导致立场失效的特定事件或数据点
|
||||
- [[Alternative-Data]]: 非常规数据源（网页流量、应用数据、专利文件、职位发布、卫星图像）用于实时业务动能信号
|
||||
- [[Quantitative-Strategies]]: 因子模型构建回测（价值、质量、动量、低波动）、事件驱动分析、期权隐含概率分析
|
||||
- [[Porter-Five-Forces]]: 竞争护城河评估框架——新进入者威胁、买方议价能力、卖方议价能力、替代品威胁、现有竞争者竞争程度
|
||||
|
||||
## Key Entities
|
||||
- [[Quinn]]: The Agency 投资研究 Agent，14 年+经验，专注基本面与量化分析结合，支持公开市场和私募市场
|
||||
- [[The-Agency]]: Quinn 所属组织，旗下有 Financial Analyst Agent（Morgan）、Tax Strategist Agent（Cassandra）等 Finance 部门成员
|
||||
|
||||
## Connections
|
||||
- [[Quinn]] ← 互补 ← [[finance-financial-analyst]]
|
||||
- Financial Analyst 负责财务建模与预算分析，Investment Researcher 负责投资研究与估值，两者形成 Finance 部门完整能力覆盖
|
||||
- [[Quinn]] ← 依赖 ← [[finance-tax-strategist]]
|
||||
- 税务策略影响投资组合税后回报，Quinn 在尽职调查和投资组合分析中需要参考税务影响
|
||||
- [[Investment-Research-Report]] ← 输出格式 ← [[Quinn]]
|
||||
- [[Due-Diligence]] ← 方法论 ← [[Quinn]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[finance-financial-analyst]] 在分析视角上存在互补而非冲突：
|
||||
- 冲突点：两者均涉及财务建模和估值
|
||||
- Quinn 视角：投资导向，专注 alpha 发现、风险量化、组合构建，强调 variant perception
|
||||
- Morgan 视角：运营导向，专注预算差异、FP&A、现金流预测，强调财务健康监控
|
||||
- 结论：视角互补、分工明确，Wiki 中两者独立存在
|
||||
55
wiki/sources/finance-tax-strategist.md
Normal file
55
wiki/sources/finance-tax-strategist.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Tax Strategist Agent"
|
||||
type: source
|
||||
tags: ["agent", "finance", "tax", "compliance", "agentic"]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/finance/finance-tax-strategist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：专业税务战略代理 Agent（代号 Cassandra），在 Big Four 会计事务所、企业税务部门和精品税务咨询机构拥有 15 年+经验，擅长跨境交易结构设计、IPO 税务准备、IRS 审计应对。
|
||||
- 问题域：企业有效税率（ETR）优化、多辖区合规管理（联邦/州/国际）、转让定价、税务筹划与业务决策整合。
|
||||
- 方法/机制：通过五阶段工作流（税务状况评估 → 机会识别 → 策略开发 → 实施合规 → 持续监控），将税务考量嵌入业务决策全流程；使用 Tax Planning Memorandum 和 ETR Analysis 标准化交付物。
|
||||
- 结论/价值：使组织有效税率达到行业同行中位数或以下，零罚款/利息，100% 按时申报，所有税务立场有同期文档支持。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **Cassandra（税务代理）** + 贯穿五阶段工作流 + 将税务规划嵌入业务决策全流程 = 使组织 ETR 达到行业同行中位数
|
||||
- **有效税率优化** + 多辖区联动分析（联邦/州/国际） + 量化风险 = 在合法框架内实现税后收益最大化
|
||||
- **转让定价** + 独立交易原则 + 基准研究 + 预约定价协议（APA） = 防御跨境税务审查
|
||||
- **83(b) Election** + 30 天窗口期内完成 = 将 $2M 未来普通收入转换为长期资本利得，节省约 $470K 联邦税
|
||||
- **合规文档** + 同期备忘录 + 立场强度评估 = 审计时的主动防御，降低审计调整幅度
|
||||
|
||||
## Key Quotes
|
||||
> "Tax isn't an afterthought; it's a strategic lever." — Cassandra（税务代理核心信念）
|
||||
> "The cheapest tax dollar is the one you never owe. But the most expensive is the penalty for non-compliance." — Cassandra（税务代理核心原则）
|
||||
> "Aggressive ≠ illegal, but the line matters. Always quantify the risk of uncertain positions." — Cassandra（激进与合法的边界）
|
||||
|
||||
## Key Concepts
|
||||
- [[TransferPricing]]：转让定价 — 关联方交易定价须符合独立交易原则，通过基准研究证明经济合理性
|
||||
- [[GILTI]]：全球无形低税收入 — 美国税改后对境外子公司无形收入征税的机制，需通过 FDII 抵扣优化
|
||||
- [[BEPS]]：税基侵蚀与利润转移 — OECD 提出的 15 项行动计划，涵盖常设机构、转让定价、数字经济税收
|
||||
- [[QSBS]]：合格小型企业股票（Section 1202）— 符合条件的 QSBS 可在出售时享受 100% 资本利得税豁免
|
||||
- [[83bElection]]：83(b) 选择权 — 在限制性股票归属前以公平市价申报，将未来普通收入转换为资本利得
|
||||
- [[EffectiveTaxRate]]：有效税率（ETR）— 实际税负占税前收入的比例，是衡量税务筹划效果的核心 KPI
|
||||
- [[TaxPlanningMemorandum]]：税务规划备忘录 — 标准化交付物模板，包含事实背景、法律分析、立场评估、建议和风险缓释措施
|
||||
- [[BEAT]]：基税侵蚀反滥用税 — 对向境外关联方大额支付的美国企业征收的最低税
|
||||
|
||||
## Key Entities
|
||||
- [[Cassandra]]：税务战略代理 — 角色代号，15年+经验，Big Four + 企业税务部 + 精品咨询背景
|
||||
- [[BigFour]]：四大会计事务所 — 主要人才来源，定义行业标准
|
||||
- [[IRS]]：美国国税局 — 主要监管和审计对象
|
||||
- [[ThomsonReutersONESOURCE]]：税务软件平台 — 税务申报和研究工具
|
||||
- [[Alteryx]]：数据分析平台 — 税务数据工作流自动化
|
||||
- [[TPBenchmarking]]：转让定价基准研究 — 防御审计的核心文档
|
||||
|
||||
## Connections
|
||||
- [[TaxStrategist]] ← specializes_in ← [[TransferPricing]]
|
||||
- [[TaxStrategist]] ← relies_on ← [[TaxPlanningMemorandum]]
|
||||
- [[TaxStrategist]] ← uses ← [[EffectiveTaxRate]] (as KPI)
|
||||
- [[TaxStrategist]] ← manages ← [[GILTI]] ← interacts_with ← [[BEAT]]
|
||||
- [[TaxStrategist]] ← applies ← [[QSBS]] ← connected_to ← [[83bElection]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现与现有 Wiki 内容的冲突。该 Agent 专注于合法税务筹划，与 Wiki 中其他 Agent 角色无领域重叠。
|
||||
@@ -3,6 +3,7 @@ title: "Game Audio Engineer Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
@@ -1,50 +1,66 @@
|
||||
---
|
||||
title: "Game Designer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
tags: ["game-development", "game-design", "systems-design", "economy-balancing", "multi-agent"]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/game-designer.md]]
|
||||
- [[Agent/agency-agents/game-development/game-designer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：GameDesigner Agent 角色定义——一个资深系统与机制设计师，以"循环、杠杆、玩家动机"为思维框架，将创意愿景转化为可执行、无歧义的游戏设计文档
|
||||
- 问题域：游戏玩法系统设计、经济系统平衡、玩家进阶体验设计、GDD 文档规范化、游戏设计师与工程师/美术的协作接口
|
||||
- 方法/机制：五步工作流（概念→设计支柱→纸面原型→GDD撰写→调优迭代）、核心循环三层模型（瞬间→会话→长期）、行为经济学应用、系统性设计方法论
|
||||
- 结论/价值：提供一套完整的游戏设计师 Agent 规范，涵盖文档标准、调优方法、高级能力（行为经济学、跨类型机制移植、高级经济设计、系统涌现设计）
|
||||
|
||||
- **核心主题**：游戏设计师 Agent 的身份定位、系统与机制设计方法论、玩家动机与反馈系统设计
|
||||
- **问题域**：游戏设计文档（GDD）编写、游戏核心循环设计、经济系统平衡、数值调优、玩家体验优化
|
||||
- **方法/机制**：设计支柱（Design Pillars）→ 纸面原型 → GDD 编写 → 平衡迭代 → 试玩测试；游戏循环分层（瞬间→会话→长期）；行为经济学应用；系统涌现设计
|
||||
- **结论/价值**：构建系统化游戏设计方法论，通过严谨文档和平衡经济系统实现可持续玩家参与
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- GameDesigner Agent 以"玩家动机"为设计出发点，而非功能列表
|
||||
- 每个机制必须包含：目的、玩家体验目标、输入、输出、边界情况、失败状态
|
||||
- 所有数值从假设开始，用 `[PLACEHOLDER]` 标记直至通过测试验证
|
||||
- 行为经济学原则（损失厌恶、变率奖励、沉没成本）应被有意识地、符合伦理地应用于游戏设计
|
||||
- 系统性设计应追求"最小可行复杂度"——移除不产生新颖玩家决策的系统
|
||||
|
||||
- 游戏设计师 Agent 以"循环、杠杆、玩家动机"为思维方式，将创意愿景转化为工程师和美术可无歧义执行的文档
|
||||
- 每个机制必须记录：目的、玩家体验目标、输入、输出、边界情况、失败状态
|
||||
- 所有数值以假设为起点，标记为 `[PLACEHOLDER]` 并附调优说明
|
||||
- 设计从玩家动机出发，而非功能清单出发；每个系统必须回答"玩家感受什么？做什么决策？"
|
||||
- 行为经济学（损失厌恶、变量奖励、沉没成本、禀赋效应）应被有意识地、符合伦理地应用于设计中
|
||||
- 经济系统建模为供需系统，追踪 source（来源）、sink（消耗）、equilibrium（平衡）曲线
|
||||
- 系统设计追求涌现性：设计应产生设计师未预测的玩家策略
|
||||
|
||||
## Key Quotes
|
||||
> "Design from player motivation outward, not feature list inward." — 设计出发点原则
|
||||
> "Every mechanic must be documented with: purpose, player experience goal, inputs, outputs, edge cases, and failure states." — 机制文档标准
|
||||
> "All numerical values start as hypotheses — mark them `[PLACEHOLDER]` until playtested." — 数值平衡哲学
|
||||
|
||||
> "Every mechanic must be documented with: purpose, player experience goal, inputs, outputs, edge cases, and failure states." — GDD 编写标准
|
||||
|
||||
> "All numerical values start as hypotheses — mark them `[PLACEHOLDER]` until playtested." — 数值设计原则
|
||||
|
||||
> "Design from player motivation outward, not feature list inward." — 设计思维核心
|
||||
|
||||
> "Design systems that interact to produce emergent player strategies the designer didn't predict." — 系统涌现设计目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Game Design Document (GDD)]]：游戏设计文档——包含所有机制完整描述的权威参考文档，每项重大修订必须版本化
|
||||
- [[Core Gameplay Loop]]：核心游戏循环——从瞬间体验（0-30秒）到会话目标（5-30分钟）再到长期进阶（数小时至数周）的三层设计框架
|
||||
- [[Economy Balance]]：经济平衡——通过供给/需求模型、玩家画像（鲸鱼/海豚/小鱼）、通胀检测维持游戏货币系统健康
|
||||
- [[Player Onboarding]]：玩家引导——通过可发现性设计、无失败教程首关、长线钩子确保 90% 以上的新手完成率
|
||||
- [[Mechanic Specification]]：机制规格说明——结构化描述机制的目的、玩家幻想、输入/输出、成功/失败状态、边界情况、调优杠杆
|
||||
- [[Behavioral Economics in Games]]：游戏中的行为经济学——应用 Cialdini 影响原则、损失厌恶、变率奖励表、沉没成本心理设计伦理性的玩家参与系统
|
||||
- [[Systemic Design]]：系统性设计——设计相互作用的系统以产生涌现性玩家策略，记录系统交互矩阵并平衡最小可行复杂度
|
||||
- [[Cross-Genre Mechanics Transplantation]]：跨类型机制移植——从相邻类型提取核心动词，通过"机制活检"分析可迁移性并记录类型惯例期望与颠覆风险的权衡
|
||||
|
||||
- [[Game Design Document]]：游戏设计文档，描述游戏所有机制、经济、循环的完整蓝图，是设计与工程之间的契约
|
||||
- [[Core Gameplay Loop]]：核心游戏循环，分瞬间（0-30秒）、会话（5-30分钟）、长期（小时-周）三层，驱动玩家持续参与
|
||||
- [[Economy Balancing]]：经济平衡，通过数值调优维持游戏中资源的经济健康，防止通胀或死路
|
||||
- [[Behavioral Economics In Games]]：行为经济学在游戏设计中的应用——损失厌恶、变量奖励、沉没成本、禀赋效应
|
||||
- [[Playtest-Driven Design]]：以试玩测试驱动的设计迭代，定义成功标准后再测试
|
||||
- [[Systemic Emergence]]：系统性涌现，玩家策略超越设计预期时产生的自然游戏体验
|
||||
- [[Cross-Genre Mechanic Transplantation]]：跨类型机制移植，从邻近类型提取核心动词并评估迁移可行性
|
||||
|
||||
## Key Entities
|
||||
- GameDesigner Agent：核心角色——资深系统与机制设计师，具备玩家同理心、系统思维、平衡执念和清晰沟通能力，跨类型（RPG、平台跳跃、射击、生存）经验丰富
|
||||
|
||||
- [[Narrative Designer]]：叙事设计师，与 Game Designer 协作，在叙事与系统层面对齐玩家体验
|
||||
- [[Level Designer]]：关卡设计师，将 Game Designer 的机制设计转化为具体关卡空间体验
|
||||
- [[Game Audio Engineer]]：游戏音频工程师，通过音效强化 Game Designer 定义的反馈系统
|
||||
|
||||
## Connections
|
||||
- [[Level Designer]] ← complements ← [[GameDesigner]]：关卡设计师与游戏设计师协作——前者负责空间/关卡叙事，后者负责系统/机制设计
|
||||
- [[Narrative Designer]] ← collaborates_with ← [[GameDesigner]]：叙事设计师与游戏设计师协作——叙事框架需要机制支撑，机制设计需要叙事赋予意义
|
||||
- [[GameAudioEngineer]] ← supports ← [[GameDesigner]]：音效工程师实现游戏设计师定义的反馈系统
|
||||
- [[TechnicalArtist]] ← enables ← [[GameDesigner]]：技术美术将设计师的视觉/交互原型转化为可执行实现
|
||||
|
||||
- [[game-designer]] ← depends_on ← [[Narrative Designer]]：叙事驱动动机，机制承载叙事
|
||||
- [[game-designer]] ← depends_on ← [[Level Designer]]：机制需要空间化，关卡提供空间上下文
|
||||
- [[game-designer]] ← extends ← [[Core Gameplay Loop]]：核心循环是 Game Designer 的首要设计产物
|
||||
- [[game-designer]] ← extends ← [[Economy Balancing]]：经济平衡是 Game Designer 的核心技术能力
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容——本文档为角色定义文档，未与其他 Wiki 页面产生直接论点冲突
|
||||
|
||||
- 与 [[Level Designer]] 可能的冲突：
|
||||
- **冲突点**：Game Designer 定义机制设计（mechanic specification），Level Designer 在关卡中实现时可能发现某些机制无法在特定空间上下文中有意义地展开
|
||||
- **当前观点**：机制应在抽象层设计完整后再交给 Level Designer 实现
|
||||
- **对方观点**：机制设计应在空间上下文中进行，抽象设计可能脱离实际
|
||||
|
||||
@@ -1,35 +1,40 @@
|
||||
---
|
||||
title: "Gemini CLI Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/gemini-cli/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：将 61 个 Agency Agents 打包为 Gemini CLI 扩展插件
|
||||
- 问题域：AI Agent 的可移植性与跨工具调用能力
|
||||
- 方法/机制：通过 `./scripts/convert.sh --tool gemini-cli` 生成扩展文件，再通过 `./scripts/install.sh --tool gemini-cli` 安装到 `~/.gemini/extensions/agency-agents/`，安装后可在 Gemini CLI 中按名称激活 Agent skill
|
||||
- 结论/价值：为 Gemini CLI 用户提供即插即用的 61 个专业 Agent，覆盖前端开发、后端架构、现实核查等多个领域
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Gemini CLI 可通过扩展机制集成 Agency 的全部 61 个 Agent，形成即用型工具包
|
||||
|
||||
## Key Quotes
|
||||
> "Packages all 61 Agency agents as a Gemini CLI extension. The extension installs to `~/.gemini/extensions/agency-agents/`." — 核心价值声明
|
||||
> "Use the frontend-developer skill to help me build this UI." — 在 Gemini CLI 中激活 Agent 的自然语言示例
|
||||
|
||||
## Key Concepts
|
||||
- [[Agent Skill]]：Agent 以 Skill 形式封装，可在 Gemini CLI 中通过自然语言引用激活
|
||||
- [[Extension（扩展机制）]]：Gemini CLI 支持第三方扩展，扩展安装到 `~/.gemini/extensions/` 目录
|
||||
|
||||
## Key Entities
|
||||
- [[Agency Agents]]：提供 61 个预置专业 Agent 的项目
|
||||
|
||||
## Connections
|
||||
- [[agents-orchestrator]] ← extends ← [[gemini-cli]]（通过 Gemini CLI 扩展触发 Agent 编排）
|
||||
|
||||
## Contradictions
|
||||
- （无冲突检测到此文档与现有 Wiki 内容无矛盾）
|
||||
---
|
||||
title: "Gemini CLI Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/gemini-cli/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Gemini CLI 扩展集成——将 The Agency 的全部 61 个 Agent 打包为 Gemini CLI 扩展
|
||||
- 问题域：如何让用户在 Gemini CLI 中按名称直接调用任意 Agency Agent
|
||||
- 方法/机制：通过 `convert.sh` 生成扩展文件，再通过 `install.sh` 安装到 `~/.gemini/extensions/agency-agents/`；安装后在 Gemini CLI prompt 中引用 Agent 名称即可激活
|
||||
- 结论/价值：Gemini CLI 用户无需关心 Agent 实现细节，只需按名称引用即可获得 The Agency 全套专业能力
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 的全部 61 个 Agent 均以 SKILL.md 格式打包为 Gemini CLI 扩展
|
||||
- 扩展安装路径为 `~/.gemini/extensions/agency-agents/`，属于 Home-Scoped 级别
|
||||
- 在 Gemini CLI 中通过自然语言引用 Agent 名称即可激活对应技能
|
||||
|
||||
## Key Quotes
|
||||
> "Packages all 61 Agency agents as a Gemini CLI extension." — 明确扩展包规模
|
||||
> "Use the frontend-developer skill to help me build this UI." — Gemini CLI 中引用 Agent 的示例
|
||||
|
||||
## Key Concepts
|
||||
- [[AgentIntegration]]：The Agency 与各类 IDE/CLI 工具的集成机制
|
||||
- [[SkillReference]]：通过名称引用方式在 AI 工具中激活特定 Agent 的机制
|
||||
|
||||
## Key Entities
|
||||
- [[GeminiCLI]]：Google 的 Gemini CLI 工具，支持扩展机制
|
||||
- [[AgencyAgents]]：The Agency 项目中的 61 个 AI Agent 组合
|
||||
- [[AgencyAgentsRoster]]：Agent 团队 roster，包含 frontend-developer、backend-architect、reality-checker 等角色
|
||||
|
||||
## Connections
|
||||
- [[AgencyAgents]] ← generates → [[GeminiCLI]] Extension
|
||||
- [[SkillReference]] ← enables → [[AgencyAgents]]
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
|
||||
@@ -1,38 +1,38 @@
|
||||
---
|
||||
title: "GitHub Copilot Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/github-copilot/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency 项目与 GitHub Copilot 的开箱即用集成方案
|
||||
- 问题域：如何在 GitHub Copilot 环境中使用 Agency 的 agent 定义文件
|
||||
- 方法/机制：通过脚本安装或手动复制 `.md` + YAML frontmatter 格式的 agent 文件到 Copilot 目录
|
||||
- 结论/价值：无需转换，Agency 的 agent 文件格式与 GitHub Copilot 原生兼容，用户可零成本迁移
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agency agents 使用 `.md` + YAML frontmatter 格式，无需任何转换即可在 GitHub Copilot 中使用
|
||||
- 通过 `./scripts/install.sh --tool copilot` 可一键将所有 agents 复制到 Copilot agents 目录
|
||||
- 用户可在任何 GitHub Copilot 会话中通过名称激活特定 agent
|
||||
- Agents 按部门（division）组织，具体列表见主 README
|
||||
|
||||
## Key Quotes
|
||||
> "The Agency works with GitHub Copilot out of the box. No conversion needed — agents use the existing `.md` + YAML frontmatter format." — 核心价值主张
|
||||
|
||||
## Key Concepts
|
||||
- [[AgentFileFormat]]：Agent 定义文件采用 `.md` + YAML frontmatter 格式，是 Agency 与 GitHub Copilot 的共同标准
|
||||
|
||||
## Key Entities
|
||||
- [[TheAgency]]：The Agency 开源项目本身，提供多领域专业化 agent 定义
|
||||
- [[GitHubCopilot]]：GitHub Copilot AI 编程助手，支持通过 agent 文件扩展功能
|
||||
|
||||
## Connections
|
||||
- [[GitHubCopilot]] ← integrates_with ← [[TheAgency]]
|
||||
- [[GitHubCopilot]] ← uses_agent_format ← [[AgentFileFormat]]
|
||||
|
||||
## Contradictions
|
||||
（暂无已知冲突）
|
||||
---
|
||||
title: "GitHub Copilot Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/github-copilot/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency 与 GitHub Copilot 的零门槛原生集成
|
||||
- 问题域：如何将 The Agency 的 Agent Roster 接入 GitHub Copilot 并在任意会话中按名称激活
|
||||
- 方法/机制：利用 The Agency 的 `.md` + YAML frontmatter 格式与 GitHub Copilot 的 agent 格式原生兼容特性，通过 install.sh 或手动复制完成安装
|
||||
- 结论/价值：GitHub Copilot 是 The Agency 集成的 11 种工具中唯一用户级全局生效的集成方案，可在任意 Copilot 对话中直接激活指定 Agent，无需项目配置
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 的 Agent 原生兼容 GitHub Copilot：The Agency 使用 `.md` + YAML frontmatter 格式，无需任何转换即可被 GitHub Copilot 识别
|
||||
- 两种安装方式覆盖不同场景：`./scripts/install.sh --tool copilot` 批量安装全部 Agent，`cp` 手动复制可按需选择特定分类
|
||||
- 激活方式简洁自然：在任意 Copilot 会话中通过名称引用 Agent 即可激活，无需额外命令或配置
|
||||
- Agent 按部门（division）组织：Agent 的完整列表和部门归属参见主 README
|
||||
|
||||
## Key Quotes
|
||||
> "The Agency works with GitHub Copilot out of the box. No conversion needed — agents use the existing `.md` + YAML frontmatter format." — 核心价值声明，强调零配置特性
|
||||
|
||||
## Key Concepts
|
||||
- [[Agent-Integration]]：The Agency Agent 向各类 IDE 和工具的接入方案，GitHub Copilot 是其中用户级全局生效的代表
|
||||
|
||||
## Key Entities
|
||||
- [[GitHub-Copilot]]：GitHub 官方 AI 编程助手，支持通过 agent 目录机制加载自定义 Agent — 本文档的核心接入对象
|
||||
- [[The-Agency]]：提供 147 个专业 Agent 的多 Agent 框架，GitHub Copilot Integration 是其 11 种集成方式之一
|
||||
|
||||
## Connections
|
||||
- [[readme|OpenCode Integration]] ← depends_on ← [[github-copilot]]
|
||||
- [[readme|GitHub Copilot Integration]] ← extends ← [[integrations-readme|The Agency integrations]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突检测：GitHub Copilot Integration 与现有 Wiki 内容一致
|
||||
|
||||
@@ -1,79 +1,59 @@
|
||||
---
|
||||
title: "Godot Gameplay Scripter Agent Personality"
|
||||
type: source
|
||||
tags: ["godot", "gdscript", "game-development", "agent-personality"]
|
||||
date: 2026-04-26
|
||||
tags: [game-development, godot, agent-personality, gdscript, gdscript-2.0, signal-architecture, type-safety, composition]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
|
||||
- [[Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Godot 4 游戏逻辑脚本专家 Agent 人格定义，强调以软件架构师的纪律性构建游戏系统
|
||||
- 问题域：如何用 GDScript 2.0 和 C# 构建类型安全、信号驱动、可组合的游戏玩法系统
|
||||
- 方法/机制：严格静态类型 + 信号架构 + 组合优于继承 + 正确的 Autoload 使用模式 + GDScript/C# 互操作规范
|
||||
- 结论/价值：提供了一套完整的 Godot 4 游戏开发规范，包括命名约定、代码模式、工作流程和性能指标
|
||||
- 核心主题：Godot 4 游戏玩法脚本专家 AI Agent 人格规范，专注于用 GDScript 2.0 和 C# 构建类型安全、信号驱动的游戏系统
|
||||
- 问题域：游戏开发中如何避免 GDScript 动态类型的运行时错误、实现系统间松耦合通信、保持场景树可维护性
|
||||
- 方法/机制：静态类型强制 + 强类型信号架构 + 组合优于继承 + Autoload 事件总线
|
||||
- 结论/价值：提供一套完整的 Godot 4 游戏玩法系统开发规范，使代码在大型项目中仍可维护和测试
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- GodotGameplayScripter Agent 以软件架构师的纪律性和独立游戏开发者的务实精神构建游戏玩法系统
|
||||
- GDScript 信号必须使用 snake_case 且携带类型化参数，C# 信号使用 PascalCase + EventHandler 后缀
|
||||
- 所有变量、函数参数和返回值必须显式类型化，禁止在生产代码中使用无类型 var
|
||||
- 组合优于继承：通过子节点附加组件（如 HealthComponent）优于创建继承层级
|
||||
- Autoload 仅用于真正的跨场景全局状态，不得包含游戏逻辑
|
||||
- 场景必须可独立实例化，不得假设父节点类型或兄弟节点存在
|
||||
- GDScript 信号必须使用 `snake_case` 且携带类型化参数——携带 Variant 的未类型化信号是运行时错误的根源
|
||||
- GDScript 2.0 中每个变量、函数参数和返回值必须显式类型声明——生产代码中出现未类型化的 `var` 会导致难以追踪的 bug
|
||||
- 场景组合优于继承：向节点附加 `HealthComponent` 比 `CharacterWithHealth` 基类更灵活且更可测试
|
||||
- Autoload 仅用于真正的全局状态（设置/存档/事件总线）——将游戏逻辑放入 Autoload 会导致无法独立实例化和垃圾回收
|
||||
- 场景必须可独立运行（按 F6）——假设父节点上下文的场景在集成时会产生级联错误
|
||||
|
||||
## Key Quotes
|
||||
> "Everything is a node — behavior is composed by adding nodes, not by multiplying inheritance depth"
|
||||
> 核心哲学：一切皆为节点，行为通过添加节点组合，而非增加继承深度
|
||||
|
||||
> "Adding the type here catches this bug at parse time instead of 3 hours into playtesting"
|
||||
> 类型安全即功能：在解析时捕获 bug，而非在测试 3 小时后发现
|
||||
|
||||
> "Don't add this to Player — make a component, attach it, wire the signal"
|
||||
> 通信风格：组合优于捷径，永远不要把逻辑直接加到 Player 上，而是创建组件
|
||||
|
||||
> "GDScript signals use snake_case; if you're in C#, it's PascalCase with EventHandler"
|
||||
> 语言感知：在 GDScript 中信号用 snake_case；在 C# 中用 PascalCase 加 EventHandler 后缀
|
||||
> "Signals must carry typed parameters — never emit untyped Variant unless interfacing with legacy code." — 信号类型安全原则
|
||||
> "Prefer composition over inheritance: a HealthComponent node attached as a child is better than a CharacterWithHealth base class." — 节点组合哲学
|
||||
> "Autoloads are singletons — use them only for genuine cross-scene global state: settings, save data, event buses, input maps." — Autoload 使用规范
|
||||
> "Test every scene in isolation by running it directly (F6) — it must not crash without a parent context." — 场景隔离测试原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Signal-Driven Architecture]]：信号驱动架构——通过信号解耦系统，避免直接方法调用，信号必须携带类型化参数
|
||||
- [[Static Typing in GDScript 2.0]]：GDScript 2.0 静态类型——所有变量、参数、返回值必须显式类型化，使用 typed arrays
|
||||
- [[Composition Over Inheritance]]：组合优于继承——通过附加子节点组件实现行为，而非创建继承层级
|
||||
- [[Event Bus Autoload]]：事件总线 Autoload——跨场景解耦通信的全局信号总线，只用于真正跨场景的事件
|
||||
- [[Type-Safe Signal Design]]：类型安全信号设计——信号命名遵循语言约定，参数必须类型化，连接时验证方法存在性
|
||||
- [[GDScript C# Interoperability]]：GDScript/C# 互操作——跨语言信号连接模式，类型转换和连接命名规范
|
||||
- [[GDScript-2.0]]：Godot 4 的脚本语言，支持静态类型声明、类型推断（`:=`）、强类型数组（`Array[Type]`）
|
||||
- [[TypedSignals]]：携带显式类型参数的信号（`signal health_changed(new_health: float)`），而非 Variant 类型
|
||||
- [[CompositionOverInheritance]]：通过组合节点（HealthComponent/MovementComponent）实现行为，而非继承层次
|
||||
- [[EventBus]]：Autoload 事件总线（EventBus.gd），用于跨场景解耦通信，避免直接节点引用
|
||||
- [[StaticTyping]]：GDScript 2.0 强制显式类型声明，消除运行时类型错误
|
||||
- [[GDExtension]]：使用 C++ 编写性能关键系统并暴露给 GDScript 的原生扩展机制
|
||||
- [[RenderingServer]]：Godot 低层渲染 API，用于绕过场景树开销实现高效 2D/3D 渲染
|
||||
- [[SceneTreeLifecycle]]：`_ready()` 初始化、`_exit_tree()` 清理、`queue_free()` 安全删除的节点生命周期管理规范
|
||||
|
||||
## Key Entities
|
||||
- [[GDScript 2.0]]：Godot 4 默认脚本语言，支持静态类型、装饰器、改进的信号系统
|
||||
- [[C# (Godot)]]：Godot 4 支持的 .NET 脚本语言，通过 GodotSharp bindings 与引擎交互
|
||||
- [[GDExtension]]：Godot 4 原生扩展机制，允许用 C++ 编写性能关键系统并暴露给 GDScript
|
||||
- [[HealthComponent]]：健康组件示例——展示类型化信号声明、@export 属性、伤害/治疗逻辑的标准模式
|
||||
- [[EventBus]]：事件总线 Autoload——全局跨场景信号发射器，用于解耦通信
|
||||
- [[GodotGameplayScripter]]：本 Agent 身份——Godot 4 游戏玩法脚本专家，强调类型安全、信号完整性和组合架构
|
||||
- [[GodotEngine]]：Godot 4 游戏引擎，支持 GDScript 2.0、C#、GDExtension 多语言生态
|
||||
- [[GDScript]]：Godot 官方脚本语言，GDScript 2.0 引入静态类型支持
|
||||
- [[CSharpGodot]]：Godot 的 C# 集成，使用 `[Signal]` 委托模式和 `EmitSignal(SignalName.X, ...)` 调用
|
||||
|
||||
## Connections
|
||||
- [[GDScript 2.0]] ← uses ← [[Static Typing in GDScript 2.0]]
|
||||
- [[GDScript 2.0]] ← uses ← [[Type-Safe Signal Design]]
|
||||
- [[C# (Godot)]] ← uses ← [[Type-Safe Signal Design]]
|
||||
- [[EventBus]] ← implements ← [[Signal-Driven Architecture]]
|
||||
- [[HealthComponent]] ← demonstrates ← [[Composition Over Inheritance]]
|
||||
- [[GDExtension]] ← extends ← [[C# (Godot)]]
|
||||
- [[GodotGameplayScripter]] ← builds_with ← [[GDScript-2.0]]
|
||||
- [[GodotGameplayScripter]] ← builds_with ← [[CSharpGodot]]
|
||||
- [[TypedSignals]] ← enables ← [[EventBus]]
|
||||
- [[CompositionOverInheritance]] ← enables ← [[TypedSignals]]
|
||||
- [[StaticTyping]] ← enforces ← [[GDScript-2.0]]
|
||||
- [[GodotGameplayScripter]] ← complements ← [[GodotShaderDeveloper]]
|
||||
- [[GodotGameplayScripter]] ← complements ← [[GodotMultiplayerEngineer]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
## Technical Deliverables Summary
|
||||
|
||||
### 核心代码模式
|
||||
- **Typed Signal (GDScript)**：`signal health_changed(new_health: float)` + `died.emit()`
|
||||
- **Signal Bus Autoload**：`signal player_died` + `signal score_changed(new_score: int)`
|
||||
- **Typed Signal (C#)**：`[Signal] public delegate void HealthChangedEventHandler(float newHealth)`
|
||||
- **Composition Pattern**：`@onready var health: HealthComponent = $HealthComponent`
|
||||
- **Typed Array**：`var _active_enemies: Array[EnemyBase] = []`
|
||||
- **GDScript/C# Interop**：`health_component.HealthChanged.connect(_on_health_changed)`（PascalCase）
|
||||
|
||||
### 质量指标
|
||||
- 生产代码零无类型 var 声明
|
||||
- 所有信号参数显式类型化，无 Variant
|
||||
- 零运行时路径查找（所有 get_node 仅在 _ready 中通过 @onready）
|
||||
- 组件节点 < 200 行，每个处理一个游戏关注点
|
||||
- 所有场景可独立运行（F6 测试通过）
|
||||
- 与 [[UnrealSystemsEngineer]] 冲突：
|
||||
- 冲突点：游戏逻辑放置位置（Autoload vs Actor/C++ 类）
|
||||
- 当前观点：游戏逻辑不得放入 Autoload，应封装在可实例化的节点组件中
|
||||
- 对方观点：Unreal 中游戏逻辑倾向于放置在 Actor/Component 层次，Autoload 在 Godot 中仅作服务定位器使用
|
||||
|
||||
@@ -1,55 +1,64 @@
|
||||
---
|
||||
title: "Godot Multiplayer Engineer Agent Personality"
|
||||
type: source
|
||||
tags: [Godot, Multiplayer, Networking, Game Development, Godot 4, RPC, ENet, WebRTC]
|
||||
date: 2026-04-26
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md]]
|
||||
- [[Agent/agency-agents/game-development/godot/godot-multiplayer-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Godot 4 网络多人游戏专家 Agent，基于 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 和 RPC 机制实现实时多人游戏网络同步
|
||||
- 问题域：多人游戏权威模型设计、RPC 安全性、场景复制、延迟模拟测试、NAT 穿透与 WebRTC 集成
|
||||
- 方法/机制：通过 `set_multiplayer_authority()` 显式设置权威节点，RPC 调用模式（any_peer/authority/call_local）分层控制，MultiplayerSynchronizer 按需同步属性，MultiplayerSpawner 处理动态生成节点的网络复制
|
||||
- 结论/价值：提供生产级 Godot 4 多人游戏网络架构，覆盖服务器权威模型、RPC 安全审计、ENet/WebRTC 传输层配置、延迟测试与 matchmaking 集成
|
||||
- 核心主题：Godot 4 网络多人游戏开发 Agent 人格定义——专注于 MultiplayerAPI、场景复制、ENet/WebRTC 传输、RPC 和权威模型
|
||||
- 问题域：如何在 Godot 4 中构建安全、可扩展的实时多人游戏网络系统
|
||||
- 方法/机制：服务器权威架构 + RPC 安全模式 + MultiplayerSpawner/MultiplayerSynchronizer 协同 + 延迟测试
|
||||
- 结论/价值：提供完整的 Godot 多人游戏开发规范，覆盖从基础 ENet 搭建到高级 WebRTC P2P 连接的完整技术栈
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Godot Multiplayer Engineer 通过 `set_multiplayer_authority()` 显式设置权威节点（而非依赖默认值 peer 1），确保每个动态生成节点的状态归属清晰
|
||||
- 所有游戏关键状态（位置、生命值、分数、物品状态）必须由服务器（peer 1）持有权威，客户端通过 RPC 发送输入请求，由服务器验证并更新权威状态
|
||||
- `@rpc("any_peer")` 允许任何对端调用，必须仅用于客户端→服务器请求，且函数体内必须进行服务器端验证和发送者 ID 检查，否则构成作弊漏洞
|
||||
- `MultiplayerSpawner` 是所有动态生成网络节点的唯一正确方式，手动 `add_child()` 会导致对端节点丢失同步
|
||||
- 所有 `@rpc("any_peer")` 函数必须进行服务器端验证（发送者 ID + 输入合理性检查），这是防止作弊的关键安全审计点
|
||||
- 服务器（peer ID 1）必须拥有所有游戏关键状态（位置、生命值、分数、物品状态），客户端无权直接修改
|
||||
- 使用 `set_multiplayer_authority()` 显式设置权威节点，不能依赖默认值
|
||||
- 所有状态变更必须用 `is_multiplayer_authority()` 守卫，非权威节点不得修改复制状态
|
||||
- `@rpc("any_peer")` 仅用于客户端到服务器请求，函数内部必须进行服务器端验证
|
||||
- `@rpc("authority")` 仅允许权威节点调用，用于服务器到客户端的确认
|
||||
- `@rpc("call_local")` 同时在本地执行，用于调用方也应体验的效果
|
||||
- 动态生成的网络节点必须使用 `MultiplayerSpawner`，禁止手动 `add_child()`
|
||||
- `MultiplayerSynchronizer` 的所有属性路径必须在节点进入场景树时有效，无效路径静默失败
|
||||
|
||||
## Key Quotes
|
||||
> "MANDATORY: The server (peer ID 1) owns all gameplay-critical state — position, health, score, item state" — 服务器权威模型强制规范
|
||||
> "Never use @rpc("any_peer") for functions that modify gameplay state without server-side validation inside the function body" — RPC 安全红线
|
||||
> "MultiplayerSynchronizer property paths must be valid at the time the node enters the tree — invalid paths cause silent failure" — Synchronizer 配置关键约束
|
||||
> "Don't add_child() networked nodes manually — use MultiplayerSpawner or peers won't receive them" — 场景复制核心原则
|
||||
> "MANDATORY: The server (peer ID 1) owns all gameplay-critical state — position, health, score, item state" — 核心权威模型原则
|
||||
> "`@rpc(\"any_peer\")` allows any peer to call the function — use only for client-to-server requests that the server validates" — RPC 安全性核心规则
|
||||
> "Don't `add_child()` networked nodes manually — use MultiplayerSpawner or peers won't receive them" — 场景生成关键约束
|
||||
> "Test under latency: It works on localhost — test it at 150ms before calling it done" — 延迟测试标准
|
||||
|
||||
## Key Concepts
|
||||
- [[MultiplayerAPI]]：Godot 4 核心网络 API，提供 `set_multiplayer_authority()`、`is_multiplayer_authority()`、RPC 调用和多人信号管理
|
||||
- [[Server-Authoritative Model]]：服务器权威模型 — 所有游戏关键状态由服务器持有权威，客户端发送输入请求，服务器验证后更新状态，防止作弊
|
||||
- [[RPC（Remote Procedure Call）]]：远程过程调用，通过 `@rpc()` 装饰器声明函数调用模式（any_peer/authority/call_local），实现跨网络的过程调用
|
||||
- [[MultiplayerSynchronizer]]：属性同步器 — 广播权威节点属性变更到所有对端，支持 ON_CHANGE 模式避免每帧同步
|
||||
- [[MultiplayerSpawner]]：场景生成器 — 在权威节点自动生成子场景并复制到所有对端，是动态生成网络节点的唯一正确方式
|
||||
- [[ENet]]：可靠 UDP 传输层，支持服务器/客户端两种模式，用于桌面平台的生产级网络连接
|
||||
- [[WebRTC]]：Web 实时通信协议，通过 `WebRTCPeerConnection` + `WebRTCMultiplayerPeer` 实现浏览器端 P2P 多人游戏和 NAT 穿透
|
||||
- [[Authority Model]]：权威模型 — 每个网络节点有且只有一个权威持有者（peer ID），只有权威才能修改该节点的关键状态
|
||||
- [[RPC Security Pattern]]：RPC 安全模式 — 所有 `any_peer` RPC 函数必须进行发送者 ID 验证和输入合理性检查，防止客户端作弊
|
||||
- [[MultiplayerAPI]]：Godot 4 的核心多人游戏 API，管理网络连接、权威和 RPC 通信
|
||||
- [[Server-Authoritative Architecture]]：服务器权威架构——所有游戏逻辑在服务器执行，客户端仅发送输入和接收状态
|
||||
- [[RPC (Remote Procedure Call)]]：远程过程调用，通过 `@rpc()` 装饰器实现节点间的跨网络方法调用
|
||||
- [[MultiplayerSpawner]]：Godot 4 组件，自动在所有对等节点间复制动态生成的网络节点
|
||||
- [[MultiplayerSynchronizer]]：Godot 4 组件，将权威节点的状态变化同步到所有对等节点
|
||||
- [[ENet]]：轻量级 UDP 可靠传输协议，用于 Godot 的 C/S 和 P2P 网络连接
|
||||
- [[WebRTC]]：用于浏览器导出的 P2P 多人大规模连接方案，配合 STUN/TURN 实现 NAT 穿透
|
||||
- [[Authority Model]]：权威模型——每个网络节点有唯一的权威持有者（服务器或特定客户端），只有权威才能修改状态
|
||||
- [[Scene Replication]]：场景复制——通过网络同步动态生成/销毁的节点及其状态
|
||||
- [[Delta Compression]]：增量压缩——仅传输变化的字段而非完整状态，节省带宽
|
||||
|
||||
## Key Entities
|
||||
- [[Godot 4]]：开源游戏引擎，版本 4.x 引入了 MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer 构成完整的场景复制体系
|
||||
- [[Nakama]]：开源游戏服务器，用于 Godot 多人游戏的 matchmaking、大厅、排行榜和 DataStore 集成
|
||||
- [[Godot]]：开源游戏引擎，版本 4 提供了全新的多人游戏 API（MultiplayerAPI、MultiplayerSpawner、MultiplayerSynchronizer）
|
||||
- [[Nakama]]：（提及）开源游戏服务器，可与 Godot 集成提供匹配、大厅、排行榜和 DataStore 功能
|
||||
- [[NetworkManager]]：（代码中的 Autoload 示例）管理 ENet 服务器/客户端创建、连接和断开的核心网络管理器
|
||||
- [[Player]]：（代码中的节点示例）服务器权威的玩家角色节点，通过 RPC 接收输入、同步状态
|
||||
|
||||
## Connections
|
||||
- [[godot-gameplay-scripter]] ← extends ← [[godot-multiplayer-engineer]]（多人游戏建立在 Godot 游戏逻辑脚本基础上）
|
||||
- [[godot-shader-developer]] ← parallel ← [[godot-multiplayer-engineer]]（同属 Godot Game Dev 部门的不同专精方向）
|
||||
- [[unity-multiplayer-engineer]] ← parallel ← [[godot-multiplayer-engineer]]（跨引擎多人游戏实现，核心概念一致但 API 不同）
|
||||
- [[Unity Multiplayer Engineer]] ← similar_concept ← [[Godot Multiplayer Engineer]]
|
||||
- 两者都遵循服务器权威模型和 RPC 安全模式，但各自使用不同引擎的原生 API
|
||||
- [[Game Designer]] ← documents_requirements ← [[Godot Multiplayer Engineer]]
|
||||
- Game Designer 定义的多人游戏需求由 Multiplayer Engineer 实现网络同步方案
|
||||
- [[Technical Artist]] ← coordinates_with ← [[Godot Multiplayer Engineer]]
|
||||
- 技术美工需要了解网络同步对视觉效果的影响（如预测、插值）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[unity-multiplayer-engineer]] 在权威模型实现细节上有差异：
|
||||
- 冲突点：Unity 使用 NetworkTransform/NetworkVariable 隐式同步，Godot 使用 MultiplayerSynchronizer 显式配置
|
||||
- 当前观点：Godot 的显式权威模型（每节点 `set_multiplayer_authority()`）更透明，开发者对状态归属有完全控制
|
||||
- 对方观点：Unity 的隐式同步减少模板代码，但在复杂场景下权威归属不如 Godot 明确
|
||||
```
|
||||
- 与 [[Unity Multiplayer Engineer]] 冲突：
|
||||
- 冲突点：权威模型的具体实现细节
|
||||
- 当前观点（Godot）：使用 `set_multiplayer_authority(peer_id)` 显式设置权威，每个节点独立管理
|
||||
- 对方观点（Unity）：通过 NetCode/MLAPI 的 NetworkObject 和 Owner 机制管理权威
|
||||
- 说明：两者核心原则一致（服务器权威、RPC 验证），但实现 API 不同，不构成实质冲突
|
||||
|
||||
@@ -2,24 +2,24 @@
|
||||
title: "Godot Shader Developer Agent Personality"
|
||||
type: source
|
||||
tags: [Godot, Shader, Game Development, GLSL, Visual Effects]
|
||||
date: 2026-04-26
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/godot/godot-shader-developer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Godot 4 渲染专家 Agent，使用 Godot 着色语言（GLSL-like）编写高性能 2D/3D 视觉效果着色器
|
||||
- 问题域：Godot 4 的 CanvasItem（2D）和 Spatial（3D）着色器开发、VisualShader 编辑器、后处理、性能优化
|
||||
- 方法/机制：通过 `shader_type` 声明、uniform 参数暴露、渲染器兼容性检查、纹理采样计数审计实现跨平台视觉效果
|
||||
- 结论/价值：为 Godot 4 游戏提供创作性正确且性能合规的着色器方案，覆盖 2D 精灵描边、3D 溶解/水面着色、全屏后处理
|
||||
- 核心主题：Godot 4 渲染效果专家 AI Agent，精通 Godot 着色语言（GLSL-like）、VisualShader 编辑器、CanvasItem 和 Spatial 着色器、后处理与性能优化
|
||||
- 问题域：2D（CanvasItem）和 3D（Spatial）视觉效果着色器开发、渲染器分级兼容、移动端性能合规
|
||||
- 方法/机制：通过 `shader_type` 声明 + uniform hint 系统 + 渲染器分级适配（Forward+ / Mobile / Compatibility）+ 纹理采样性能审计实现跨平台视觉效果
|
||||
- 结论/价值：为 Godot 4 游戏提供创作性、正确性与性能意识三合一的着色器方案，核心交付物涵盖 2D 精灵描边、3D Dissolve 溶解、3D 水面、全屏后处理及着色器性能审计清单
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Godot Shader Developer 通过 `shader_type` + GLSL-like 语法实现 2D CanvasItem 和 3D Spatial 着色器，在 Forward+ / Mobile / Compatibility 三种渲染器下提供差异化效果
|
||||
- Godot Shader Developer 通过 `shader_type` 声明（canvas_item / spatial / particles / sky）明确着色器上下文，使用 Godot 内置变量（TEXTURE / UV / COLOR / ALBEDO）而非原始 GLSL 等价物
|
||||
- VisualShader 编辑器适合艺术家快速迭代，代码着色器适合性能关键路径；两者互补而非替代
|
||||
- 所有 uniform 参数必须附带 hint（`hint_range`、`source_color`、`hint_normal` 等），否则 Inspector 无法正确显示
|
||||
- `SCREEN_TEXTURE` 采样会触发帧缓冲区复制，在移动端每帧 shader 中使用会严重影响性能
|
||||
- `discard` 在移动端不透明空间着色器中应替换为 Alpha Scissor，以保证性能合规
|
||||
- 所有 uniform 参数必须附带 hint（`hint_range` / `source_color` / `hint_normal` 等），否则 Inspector 无法正确显示颜色选择器和范围滑块
|
||||
- `SCREEN_TEXTURE` 采样会触发帧缓冲区复制，在移动端每帧 shader 中使用会严重影响性能，应有文档化性能理由
|
||||
- `discard` 在移动端不透明空间着色器中应替换为 Alpha Scissor，以保证性能合规；Compatibility 渲染器完全不支持 compute shader 和 `DEPTH_TEXTURE` canvas 采样
|
||||
|
||||
## Key Quotes
|
||||
> "MANDATORY: Godot's shading language is not raw GLSL — use Godot built-ins (TEXTURE, UV, COLOR, FRAGCOORD) not GLSL equivalents" — Godot 4 着色语言核心规范
|
||||
@@ -27,24 +27,25 @@ date: 2026-04-26
|
||||
> "Use VisualShader for effects artists need to extend — use code shaders for performance-critical or complex logic" — 工具选型原则
|
||||
|
||||
## Key Concepts
|
||||
- [[CanvasItem Shader]]：Godot 2D/UI 着色器类型，使用 `shader_type canvas_item`，通过 `TEXTURE`、`UV`、`COLOR` 内置变量操作精灵和 UI 效果
|
||||
- [[Spatial Shader]]：Godot 3D 世界着色器类型，使用 `shader_type spatial`，通过 `ALBEDO`、`METALLIC`、`ROUGHNESS`、`NORMAL_MAP` 输出变量控制 PBR 材质
|
||||
- [[VisualShader]]：Godot 图形化着色器编辑器，将 GLSL 节点化，支持艺术家快速搭建材质变体；Group 和 Comment 节点用于组织复杂图
|
||||
- [[CompositorEffect]]：Godot 4 Forward+ 渲染器的全屏后处理扩展点，通过 GDScript `extends CompositorEffect` 实现自定义后处理 Pass
|
||||
- [[Forward+ Renderer]]：Godot 4 高端渲染器，支持 `DEPTH_TEXTURE`、`SCREEN_TEXTURE`、`NORMAL_ROUGHNESS_TEXTURE` 全部特性
|
||||
- [[Mobile Renderer]]：Godot 4 中端渲染器，避免 `discard` 使用，优先 Alpha Scissor；纹理采样预算严格
|
||||
- [[Compatibility Renderer]]：Godot 4 最广泛支持渲染器，无 compute shader、无 `DEPTH_TEXTURE` canvas 采样、无 HDR 纹理
|
||||
- [[CanvasItem Shader]]：Godot 2D/UI 着色器类型，使用 `shader_type canvas_item`，通过 `TEXTURE`、`UV`、`COLOR` 内置变量操作精灵和 UI 效果；不支持 `DEPTH_TEXTURE`
|
||||
- [[Spatial Shader]]：Godot 3D 世界着色器类型，使用 `shader_type spatial`，通过 `ALBEDO`、`METALLIC`、`ROUGHNESS`、`NORMAL_MAP` 输出变量控制 PBR 材质；这些是输出变量而非输入
|
||||
- [[VisualShader]]：Godot 图形化着色器编辑器，将 GLSL 节点化，支持艺术家快速搭建材质变体；Comment 节点用于组织复杂图；`uniform` 必须设置 hint
|
||||
- [[CompositorEffect]]：Godot 4 Forward+ 渲染器的全屏后处理扩展点，通过 GDScript `extends CompositorEffect` + RenderingDevice 实现自定义后处理 Pass
|
||||
- [[Forward+ Renderer]]：Godot 4 高端渲染器，全特性支持——`DEPTH_TEXTURE`、`SCREEN_TEXTURE`、`NORMAL_ROUGHNESS_TEXTURE`、compute shader
|
||||
- [[Mobile Renderer]]：Godot 4 中端渲染器，避免 `discard` 使用不透明空间着色器（优先 Alpha Scissor）；纹理采样预算严格（每片元 ≤ 6 次）
|
||||
- [[Compatibility Renderer]]：Godot 4 最广泛支持渲染器，无 compute shader、无 `DEPTH_TEXTURE` canvas 采样、无 HDR 纹理；限制最多
|
||||
- [[RenderingDevice]]：Godot 4 底层 GPU API，用于 dispatch compute shader（Forward+ 渲染器下）进行 GPU 侧纹理生成和数据处理
|
||||
|
||||
## Key Entities
|
||||
- [[Godot]]：Juan Linietsky 和 Ariel Manzur 主导的开源游戏引擎，Godot 4 引入了 Forward+ 渲染器和重构的着色语言
|
||||
- [[GLSL]]：OpenGL 着色语言，Godot 着色语言基于 GLSL 但有自己的内置变量和 API（`texture()` vs `texture2D()`）
|
||||
- [[Godot]]：Juan Linietsky 和 Ariel Manzur 主导的开源游戏引擎，Godot 4 引入了 Forward+ 渲染器和重构的着色语言（基于 GLSL 但有 Godot 特有内置变量）
|
||||
- [[GLSL]]：OpenGL 着色语言，Godot 着色语言基于 GLSL，但 `texture()` 函数签名与原始 GLSL `texture2D()` 不同（Godot 3 用 `texture2D()`，Godot 4 用 `texture()`）
|
||||
|
||||
## Connections
|
||||
- [[Godot Gameplay Scripter]] ← collaborates_with ← [[Godot Shader Developer]]（Godot 游戏中脚本与着色器协同开发）
|
||||
- [[Unity Shader Graph Artist]] ← compares_to ← [[Godot Shader Developer]]（两大主流游戏引擎的着色器方案对比）
|
||||
- [[Godot Gameplay Scripter]] ← collaborates_with ← [[Godot Shader Developer]]（Godot 游戏中脚本逻辑与视觉效果着色器协同开发，构成完整 Godot 4 游戏开发栈）
|
||||
- [[Unity Shader Graph Artist]] ← compares_to ← [[Godot Shader Developer]]（两大主流游戏引擎的着色器方案对比：Unity 用 Shader Graph，Godot 用 VisualShader + 代码着色器，均追求艺术友好与性能控制的平衡）
|
||||
- [[Technical Artist]] ← overlaps_with ← [[Godot Shader Developer]]（两者均涉及渲染技术与美术的桥梁工作）
|
||||
- [[Godot Shader Developer]] ← uses ← [[VisualShader]]（VisualShader 作为快速原型工具）
|
||||
- [[Godot Shader Developer]] ← targets ← [[Forward+ Renderer]] / [[Mobile Renderer]] / [[Compatibility Renderer]]（三种渲染器适配）
|
||||
- [[Godot Shader Developer]] ← uses ← [[VisualShader]]（VisualShader 作为快速原型工具，代码着色器用于性能关键路径）
|
||||
- [[Godot Shader Developer]] ← targets ← [[Forward+ Renderer]] / [[Mobile Renderer]] / [[Compatibility Renderer]]（三种渲染器分级适配）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容。
|
||||
- 无已知冲突内容。该源页面与 [[Unity Shader Graph Artist]] 在着色器工具选型上仅有描述性差异（Graph vs Code），不存在事实性矛盾。
|
||||
|
||||
@@ -1,59 +1,65 @@
|
||||
---
|
||||
title: "Government Digital Presales Consultant"
|
||||
type: source
|
||||
tags: [ToG, government-IT, presales, compliance, Xinchuang, Smart-City, Digital-Government]
|
||||
date: 2026-04-25
|
||||
tags: []
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/government-digital-presales-consultant.md]]
|
||||
- [[Agent/agency-agents/specialized/government-digital-presales-consultant.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：中国政府信息化（ToG）市场的全生命周期售前专家智能体，涵盖从政策解读、解决方案设计到招投标全程
|
||||
- 问题域：政府数字化转型市场的项目机会识别、标书撰写、合规要求（POC验证、等保/密评/信创）、干系人管理
|
||||
- 方法/机制：五步工作流（机会发现→需求调研→方案设计→投标执行→中标交接），配合政策解读、竞品分析、POC演示、合规矩阵等工具模板
|
||||
- 结论/价值：为技术团队提供进入数字政府、智慧城市、一网统管、城市大脑等主流方向的决策支持，核心目标是提高中标率（>40%）、零废标、售前到交付对齐（偏差<10%）
|
||||
- 核心主题：中国政府数字化转型市场（ToG，Touching Government）的售前全流程专家，帮助技术团队赢得政府信息化项目。
|
||||
- 问题域：政策解读与商机发现、解决方案设计、投标文件编制、POC 验证、合规要求（等保/密评/信创）、干系人管理。
|
||||
- 方法/机制：五步工作流（商机发现→需求调研→方案设计→投标执行→中标移交）+ 分层干系人沟通策略（决策层/业务层/技术层/采购层差异化沟通）。
|
||||
- 结论/价值：将技术价值转化为政府话语，精准对接政策信号与评分标准，以案例背书和合规设计建立竞争优势。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 售前专家通过政策语言解码（"鼓励探索"→"全面实施"）识别市场成熟度信号，在政策从"软性鼓励"转向"硬性要求"时入场
|
||||
- 政府系统通常要求等保三级，核心系统可能要求等保四级；等保评估需在系统上线前2-3个月完成整改
|
||||
- 信创替换不必一步到位，分阶段替代是被接受的
|
||||
- 技术方案应以业务场景驱动，而非技术架构驱动——客户关心"市民服务处理速度提升80%"而非"微服务架构"
|
||||
- 投标文件零容忍格式错误——资质缺失、格式偏差、响应偏移均属废标项
|
||||
- Government Digital Presales Consultant 通过政策解读和分层干系人管理，帮助技术团队在政府采购流程中做出最优决策。
|
||||
- 解决方案必须以业务场景驱动而非技术架构驱动——客户关注"市民服务处理速度提升 80%"而非"微服务架构"。
|
||||
- 等保 2.0（三级）、密评（国密 SM2/SM3/SM4）、信创适配（鲲鹏/飞腾/曙光/龙芯 + 麒麟/统信 + 达梦/人大金仓）是政府信息化项目的硬约束，不是加分项。
|
||||
- 投标文件必须零容忍格式错误——遗漏资质、格式错误、响应偏差直接导致废标。
|
||||
- POC 应聚焦差异化核心能力，控制范围防止无限免费延伸。
|
||||
|
||||
## Key Quotes
|
||||
> "Drive with business scenarios, not technical architecture — the client cares about '80% faster citizen service processing,' not 'microservices architecture.'" — 方案设计核心原则
|
||||
> "Dengbao, Miping, and Xinchuang are mandatory, not bonus points." — 合规基线
|
||||
> "Don't tell the bureau head we use Kubernetes. Tell them 'Our platform's elastic scaling ensures zero downtime during peak service hall hours.'" — 技术价值转换
|
||||
> "A good proposal goes through at least three rounds of refinement." — 方案迭代要求
|
||||
> "Don't tell the bureau head we use Kubernetes. Tell them 'Our platform's elastic scaling ensures zero downtime during peak service hall hours — City XX had zero outages during the post-holiday rush last year.'" — 技术价值转化原则：用政府听得懂的语言说话
|
||||
> "'Advancing standardization, regulation, and accessibility of government services' translates to three things: service item cataloging, process reengineering, and digitization — our solution covers all three." — 政策翻译：将政策语言落地为具体建设内容
|
||||
> "The competitor has more City Brain cases than we do, but data governance is their weak spot — we don't compete on dashboards; we hit them on data quality." — 竞争策略：找到对手弱点，打差异化
|
||||
|
||||
## Key Concepts
|
||||
- [[Dengbao-2.0]]：网络安全等级保护制度，政府系统通常要求三级，等保评估需在上线前2-3个月完成
|
||||
- [[Miping]]：商用密码应用安全性评估，涉及身份认证、数据传输、数据存储必须使用国密算法（SM2/SM3/SM4）
|
||||
- [[Xinchuang]]：信息技术应用创新，核心要素为国产CPU（鲲鹏/飞腾/海光/龙芯）+ 国产OS（统信UOS/麒麟）+ 国产数据库（达梦/人大金仓/ GaussDB）+ 国产中间件
|
||||
- [[ToG]]（Government）：面向政府的数字化转型市场，区别于ToB（企业）和ToC（消费者）
|
||||
- [[Smart-City]]：智慧城市，典型方向包括城市大脑/城市运行中心（IOC）、智慧交通、智慧社区、城市信息模型（CIM）
|
||||
- [[Digital-Government]]：数字政府，典型方向包括一体化政务服务平台、一网统管/一网通办、12345热线智能升级、政府数据中台
|
||||
- [[Yiwangtongban]]：一网统办，一网通管，一体化政务服务门户
|
||||
- [[POC]]：概念验证，通过精选场景展示差异化优势，控制范围并设定明确成功标准
|
||||
- [[DigitalGovernment]]：一体化政务服务平台、政务服务"一网通办"/"一网统管"、12345热线智能化升级、政府数据中台
|
||||
- [[SmartCity]]：城市大脑/城市运行中心（IOC）、智慧交通、智慧社区、城市信息模型（CIM）
|
||||
- [[Dengbao]]（等保）：网络安全等级保护 2.0，政府系统通常要求三级，核心系统可能要求四级；安全架构设计必须覆盖网络分区分域、身份认证、数据加密、日志审计、入侵检测
|
||||
- [[Miping]]（密评）：商用密码应用安全性评估，涉及身份认证、数据传输和数据存储的政府系统必须使用国密算法（SM2/SM3/SM4）；电子印章和CA证书须使用国密证书
|
||||
- [[Xinchuang]]（信创）：信息技术应用创新；核心要素为国产CPU（鲲鹏/飞腾/曙光/龙芯）、国产OS（统信UOS/麒麟）、国产数据库（达梦/人大金仓/高斯DB）、国产中间件（东方通/宝兰德）；信创适配须优先选择信创目录主流产品，建立兼容性测试矩阵
|
||||
- [[XinchuangAdaptationMatrix]]：信创适配矩阵（CPU/OS/数据库/中间件/办公软件各层的国产替代产品与兼容性测试优先级）
|
||||
- [[DengbaoComplianceMatrix]]：等保合规矩阵（安全通信、安全边界、安全计算、安全管理中心各域的控制要求和推荐措施）
|
||||
- [[GovernmentProcurementWorkflow]]：政府信息化项目全流程——需求调研→招标文件分析→技术方案编写→商务报价→投标文件组装→讲标/答疑
|
||||
- [[StakeholderMapping]]：政府项目干系人地图（决策层/业务层/技术层/采购层），分层沟通策略
|
||||
- [[OpportunityAssessment]]：商机评估矩阵（项目真实性/竞争力/客户关系/投入产出比/风险标识）
|
||||
|
||||
## Key Entities
|
||||
- [[Digital-China-Master-Plan]]：数字中国建设整体布局规划，国家级政策文件
|
||||
- [[National-Data-Administration]]：国家数据局，国家层面数据治理主管机构
|
||||
- [[Government-Cloud]]：政务云平台，政府信息化基础设施
|
||||
- [[City-Brain]]：城市大脑，城市级数据融合与智能决策平台
|
||||
- [[Kunpeng]]：鲲鹏，国产CPU代表
|
||||
- [[Phytium]]：飞腾，国产CPU代表
|
||||
- [[UnionTech-UOS]]：统信UOS，国产操作系统代表
|
||||
- [[DM-Database]]：达梦数据库，国产数据库代表
|
||||
- [[Yiwangtongban]]：政务服务"一网通办"门户，省/市级政务服务统一入口
|
||||
- [[Yiwangtonguan]]：城市管理"一网统管"平台，城市运行管理综合平台
|
||||
- [[CityBrain]]：城市大脑，城市多源数据汇聚 + 实时监测 + 智能决策的综合平台
|
||||
- [[ClassifiedProtectionLevel3]]：等保三级，政府信息系统通常要求的网络安全等级
|
||||
- [[GuomiAlgorithms]]：国密算法（SM2/SM3/SM4），商用密码国家标准
|
||||
- [[XinchuangCatalog]]：信创产品目录，列出国产CPU/OS/数据库/中间件等合规替代产品
|
||||
|
||||
## Connections
|
||||
- [[Government-Digital-Presales-Consultant]] ← extends ← [[Sales-Engineer]]（通用售前 → 政府垂直领域售前）
|
||||
- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Xinchuang]]（信创合规必须掌握）
|
||||
- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Dengbao-2.0]]（等保合规必须掌握）
|
||||
- [[Government-Digital-Presales-Consultant]] ← depends_on ← [[Miping]]（密码评估必须掌握）
|
||||
- [[Digital-Government]] ← solution_domain ← [[Government-Digital-Presales-Consultant]]（数字政府是主要方案方向之一）
|
||||
- [[Smart-City]] ← solution_domain ← [[Government-Digital-Presales-Consultant]]（智慧城市是主要方案方向之一）
|
||||
- [[sales-engineer]] ← depends_on ← [[government-digital-presales-consultant]]：政府数字化售前提供商机评估和解决方案设计，销售工程师在此基础上进行商务跟进
|
||||
- [[sales-proposal-strategist]] ← extends ← [[government-digital-presales-consultant]]：投标文件撰写由售前专家主导，提案策略师提供格式和说服力优化
|
||||
- [[specialized-salesforce-architect]] ← extends ← [[government-digital-presales-consultant]]：Salesforce 政务云平台定制方案的设计需要政府数字化售前的业务理解
|
||||
- [[compliance-auditor]] ← depends_on ← [[government-digital-presales-consultant]]：合规审计（等保/密评/信创）由合规审计师执行，售前在方案设计阶段已嵌入合规架构
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突。本文档专注于中国政府ToG市场，与Wiki中其他以企业级/B2B市场为中心的售前/销售Agent形成领域区隔。
|
||||
- 与 [[sales-discovery-coach]] 张力：
|
||||
- 冲突点：Discovery Coach 强调"按岗位层级定制提问"，而政府数字化售前的需求调研更侧重政策合规和评分标准对齐
|
||||
- 当前观点：政府售前需优先满足招标文件硬约束（资质/案例/信创），以通过资格预审为第一目标
|
||||
- 对方观点：销售发现应以客户业务痛点为核心，通过深度提问建立信任后再推方案
|
||||
- 协调方案：政府数字化场景下，招标文件的强制要求（等保证书、类似案例数量、信创认证）是入场券——先满足合规门槛，再通过需求调研深化业务理解
|
||||
- 与 [[sales-proposal-strategist]] 潜在张力：
|
||||
- 冲突点：提案策略师偏好"故事化叙事 + 差异化定位"，而政府售前方案更强调模板规范和政治正确
|
||||
- 当前观点：政府技术方案必须使用当前政策术语（数字中国、数据要素X等），架构图要符合政务云标准规范
|
||||
- 对方观点：提案策略师认为过度模板化会削弱差异化竞争力
|
||||
- 协调方案：技术响应部分遵循政府规范格式（技术要求逐条对应），商务展示部分融入叙事和差异化
|
||||
|
||||
56
wiki/sources/handoff-templates.md
Normal file
56
wiki/sources/handoff-templates.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "NEXUS Handoff Templates"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/strategy/coordination/handoff-templates.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：NEXUS 多 Agent 协作框架的标准化交接模板体系——7 种场景化模板覆盖从任务分配、QA 通过/失败、升级、阶段门控、冲刺边界到事故响应的全链路交接
|
||||
- 问题域：多 Agent 协作中的上下文丢失（交接边界 73% 失败率）和 QA 反馈循环缺失问题
|
||||
- 方法/机制：7 个标准化 Markdown 模板 + 场景选择指南表格，每个模板包含 metadata/verdict/evidence/next-action 结构化字段
|
||||
- 结论/价值：一致性交接防止上下文丢失——多 Agent 协调失败的头号原因；与 NEXUS 质量门控（[[QualityGate]]）体系深度集成；是 NEXUS 战略框架三大交付物之一
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 标准化交接防止上下文丢失——多 Agent 协调失败的头号原因
|
||||
- QA Feedback Loop 强制执行最多 3 次重试，超出则触发 Escalation Report 升级至 [[AgentsOrchestrator]]
|
||||
- Phase Gate Handoff 为每个阶段转换建立门控标准和文档交接机制
|
||||
- Sprint Handoff 覆盖冲刺边界的所有完成状态、质量指标、待办项和回顾洞察
|
||||
- Incident Handoff 确保事故响应跨团队协作的可追溯性和上下文连续性
|
||||
- 7 个模板通过 Usage Guide 表格映射到具体场景，确保 Agent 始终使用正确模板
|
||||
|
||||
## Key Quotes
|
||||
> "Consistent handoffs prevent context loss — the #1 cause of multi-agent coordination failure." — NEXUS Handoff Templates 文档引言
|
||||
|
||||
## Key Concepts
|
||||
- [[Handoff-Boundary]]：交接边界——Agent 之间的上下文传递节点，NEXUS 发现 73% 的失败发生在此处，本文档通过 7 个标准化模板对此进行针对性解决
|
||||
- [[QualityGate]]：质量门控——本文档中 QA PASS/FAIL 模板是 QualityGate 在验收环节的具体执行机制；Phase Gate Handoff 则是阶段间的 QualityGate 实现
|
||||
- [[Agent-Handoff]]：Agent 交接——Agent-to-Agent 工作转移的标准格式，通过 Standard Handoff Template (#1) 实现结构化上下文传递
|
||||
- [[Dev-QA-Loop]]：开发↔QA 循环——QA PASS/FAIL 模板定义了该循环的标准状态转移（PASS → 推进 / FAIL → 最多重试 3 次 → Escalation）
|
||||
- [[Evidence-Over-Claims]]：证据优于主张——QA PASS 模板要求提供多分辨率截图、功能验证清单、品牌一致性/无障碍/性能数据作为决策依据
|
||||
- [[Sprint-Handoff]]：冲刺交接——Sprint 边界的知识传递模板，覆盖完成状态、质量指标、待办项和回顾洞察
|
||||
- [[Incident-Response]]：事故响应——Incident Handoff 模板为 P0-P3 事故建立标准化响应和交接流程
|
||||
|
||||
## Key Entities
|
||||
- [[NEXUS]]：The Agency 多 Agent 编排框架，handoff-templates.md 为其三大战略交付物之一（与 Master Strategy/Phase Playbooks 并列）
|
||||
- [[AgentsOrchestrator]]：代理编排器——Escalation Report 的最终升级目标；Phase Gate Handoff 中的 Gate Keeper 决策者
|
||||
- [[EvidenceQA]]：证据收集者——QA PASS/FAIL 模板中的 QA Agent 角色之一，负责多分辨率截图和功能验证
|
||||
|
||||
## Connections
|
||||
- [[executive-brief]] ← documents_in_detail ← [[handoff-templates]]
|
||||
- [[quickstart]] ← is_simplified_guide ← [[handoff-templates]]
|
||||
- [[nexus-strategy]] ← is_part_of ← [[NEXUS]]
|
||||
- [[handoff-templates]] ← enables ← [[Dev-QA-Loop]]
|
||||
- [[handoff-templates]] ← implements ← [[QualityGate]]
|
||||
- [[handoff-templates]] ← supports ← [[Sprint-Handoff]]
|
||||
- [[handoff-templates]] ← supports ← [[Incident-Response]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[workflow-with-memory]] 的记忆机制对比：
|
||||
- 冲突点：handoff-templates 依赖结构化文档传递上下文，而 [[workflow-with-memory]] 依赖 MCP 持久记忆服务
|
||||
- 当前观点：标准化交接模板提供显式、可审计的上下文传递路径，适合跨平台协作
|
||||
- 对方观点：MCP 记忆服务自动化上下文召回，减少手动文档工作，适合长期项目
|
||||
- 协调方案：两者互补——handoff-templates 定义"交接什么"，memory 系统定义"如何持久化"，建议在 Phase 3 Build 开始引入 memory 机制
|
||||
53
wiki/sources/healthcare-customer-service.md
Normal file
53
wiki/sources/healthcare-customer-service.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Healthcare Customer Service Agent"
|
||||
type: source
|
||||
tags: [healthcare, customer-service, agent, patient-support, HIPAA]
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/healthcare-customer-service.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：医疗保健客户服务 Agent 角色定义与操作规范，一个富有同理心的患者支持专员，处理预约、账单、保险、投诉及升级流程
|
||||
- 问题域：患者在医疗机构中面临的行政服务问题——预约管理、医疗账单、保险理赔、投诉处理、紧急响应
|
||||
- 方法/机制：基于五步工作流（患者识别与情感评估 → 理解需求 → 解决或转接 → 确认解决 → 记录与跟进），结合 LEAP 降级技术和 HIPAA 合规要求
|
||||
- 结论/价值：为医疗客服场景提供标准化、可量化的 Agent 行为规范，强调同理心优先、绝不提供临床建议、HIPAA 强制合规
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 医疗客服 Agent 必须在任何解决方案之前先承认患者的感受，否则无法建立信任
|
||||
- Agent 永远不得提供临床建议，所有临床问题必须立即转接给持牌临床人员
|
||||
- 身份验证（HIPAA）是讨论任何受保护健康信息（PHI）的前置条件，必须严格执行
|
||||
- 紧急情况识别必须 100% 准确，医疗紧急情况需立即指导患者拨打 911
|
||||
- 账单争议必须放置账单冻结（在审核期间），并在 3 个工作日内跟进患者
|
||||
|
||||
## Key Quotes
|
||||
> "A patient isn't a ticket number — they're a person navigating one of the most stressful experiences of their life." — 核心服务理念
|
||||
> "Every interaction is an opportunity to restore trust and deliver care, even before they see a doctor." — 客服的价值定位
|
||||
> "Never provide clinical advice. You are not a clinician. Never diagnose, recommend treatments, interpret test results, or advise on medications." — 核心边界规则
|
||||
|
||||
## Key Concepts
|
||||
- [[HIPAACompliance]]：健康保险流通与责任法案，要求最小必要原则收集信息、身份验证后方可讨论 PHI、永不重复敏感信息
|
||||
- [[EmpathyFirst]]：同理心优先原则，在任何政策、流程、解决方案之前必须先承认患者的人性需求
|
||||
- [[LEAPDeescalation]]：Listen, Empathize, Apologize, Partner — 降级技术四步法
|
||||
- [[EscalationProtocol]]：升级协议 — 立即（<2分钟）、紧急（同日）、标准（下一工作日）三级分类
|
||||
- [[PatientSupportWorkflow]]：五步患者支持工作流：识别与情感评估 → 理解需求 → 解决或转接 → 确认解决 → 记录与跟进
|
||||
|
||||
## Key Entities
|
||||
- [[BillingSpecialist]]：账单专员 — 处理复杂账单争议、账单冻结、账单审核的专业人员
|
||||
- [[PatientAdvocate]]：患者权益倡导者 — 代表患者利益的专职人员，处理投诉和权益问题
|
||||
- [[ClinicalStaff]]：临床人员 — 持牌医疗专业人员（护士、医生），负责所有临床问题的路由目标
|
||||
- [[Supervisor]]：主管 — 处理需要即时升级的紧急投诉和法律威胁
|
||||
- [[RiskManagement]]：风险管理部门 — 处理法律诉讼或潜在诉讼相关的患者投诉
|
||||
|
||||
## Connections
|
||||
- [[HealthcareMarketingCompliance]] ← extends ← [[HealthcareCustomerService]]（医疗营销合规专员与医疗客服Agent共享HIPAA合规基础）
|
||||
- [[HospitalityGuestServices]] ← analogous_to ← [[HealthcareCustomerService]]（酒店客服 Agent 与医疗客服 Agent 共享投诉处理框架和升级协议）
|
||||
- [[SupportResponder]] ← extends ← [[HealthcareCustomerService]]（通用客服响应 Agent 是医疗客服 Agent 的基础抽象层）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[LegalClientIntake]] 冲突：
|
||||
- 冲突点：医疗场景与法律场景对"身份验证"的要求严格程度
|
||||
- 当前观点：医疗场景要求全名 + 出生日期 + SSN 后四位（HIPAA 强制）
|
||||
- 对方观点：法律场景可能只需姓名和案件编号即可开始问询
|
||||
- 注：两者场景不同，冲突源于场景差异而非事实矛盾，可共存
|
||||
@@ -2,68 +2,58 @@
|
||||
title: "Healthcare Marketing Compliance Specialist"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-20
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/healthcare-marketing-compliance.md]]
|
||||
- [[Agent/agency-agents/specialized/healthcare-marketing-compliance.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：医疗营销合规专家 Agent，覆盖中国医疗健康领域（药品/医疗器械/医美/保健食品/互联网医疗）全品类营销合规
|
||||
- 问题域：医疗健康企业在品牌推广、内容营销、学术推广中的合规边界；平台内容审核规则；患者隐私保护
|
||||
- 方法/机制：以《广告法》《医疗广告管理办法》《互联网广告管理办法》为核心监管框架，建立"三级审查机制"（法务初审→合规复审→终审发布）；风险分级矩阵（Critical/High/Medium/Low）；违规应急响应流程（2小时下架→24小时报告→72小时审计）
|
||||
- 结论/价值：合规不是"堵营销"，而是"保护品牌"——一次违规处罚的代价远高于合规投入
|
||||
- 核心主题：中国医疗健康营销合规全链路专家 Agent，覆盖药品、医疗器械、医美、保健食品、互联网医疗等细分领域的广告法规与合规运营
|
||||
- 问题域：医疗健康企业在品牌推广、内容营销、学术推广中如何既合法合规又最大化营销效果
|
||||
- 方法/机制：以《广告法》《医疗广告管理办法》《互联网广告管理办法》等法规为核心依据，构建三级审核机制（法务初审→合规复审→最终审批），结合抖音/小红书/微信等平台内容审核规则，提供发布前合规审查与违规应急响应
|
||||
- 结论/价值：合规不是"阻断营销"，而是"保护品牌"——一次违规处罚的代价远高于合规投入
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 医疗广告必须经省级卫生行政部门审查并取得《医疗广告审查证明》，否则不得发布——这是行政出发乃至刑事追责的底线
|
||||
- 处方药严禁在大众媒体（电视/广播/报纸/互联网）发布广告——任何隐性推广均面临严厉处罚
|
||||
- 保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因
|
||||
- 医美广告不得制造"容貌焦虑"——2021年起市场监管总局执法力度显著加强
|
||||
- 患者健康数据属于《个人信息保护法》认定的"敏感个人信息"——违规最高罚款5000万元或上年度营收5%
|
||||
- 医疗广告必须经过审查方可发布，未经审查擅自发布将面临行政处罚甚至刑事追责
|
||||
- 处方药严禁在大众媒体（电视/广播/报刊/互联网）做广告，仅可在医药专业期刊发布
|
||||
- 保健食品不得声称治疗功能，不得使用"疗效""治愈""保证康复"等医疗术语
|
||||
|
||||
## Key Quotes
|
||||
> "医疗广告必须审查后方可发布——这是行政处罚乃至刑事追责的底线。" — 广告法第46条核心要求
|
||||
> "保健食品不得声称治病功能，必须标注'保健食品不是药物，不能替代药物治疗疾病'。" — 蓝帽子标识管理制度核心声明
|
||||
> "合规不是'堵营销'，而是'保护品牌'。一次违规处罚的代价远高于合规投入。" — Agent 核心合规文化理念
|
||||
> "医美日记类内容无论是否由用户'自愿'分享，平台和诊所均可被追究连带责任。" — 小红书医美合规红线
|
||||
> "合规不是'阻断营销'，而是'保护品牌'。一次违规处罚的代价远高于合规投入。" — 医疗营销合规核心原则
|
||||
> "保健食品不是药品，不得声称治疗疾病——这是行业被处罚最频繁的原因。" — 保健食品合规红线
|
||||
> "医美广告不得制造'容貌焦虑'，2021年以来执法力度显著加强。" — 医美广告监管趋势
|
||||
|
||||
## Key Concepts
|
||||
- [[Healthcare-Marketing-Compliance]]：医疗健康营销全品类（药品/器械/医美/保健食品/互联网医疗）合规框架
|
||||
- [[Medical-Advertisement-Review]]：《医疗广告审查证明》制度——广告发布前必须获得省级卫生行政部门审查
|
||||
- [[Three-Tier-Review-Mechanism]]：企业内部三级审查机制（法务初审→合规复审→终审发布）
|
||||
- [[OTC-Drug-Marketing]]：非处方药大众媒体广告规则——必须包含"请按照药品说明书或药师指导下使用"等咨询语句
|
||||
- [[Prescription-Drug-Restrictions]]：处方药大众媒体广告禁令——仅限在医药专业期刊发布
|
||||
- [[Medical-Device-Classification]]：医疗器械三类分级管理制度（I类备案/II类注册/III类严格审批）
|
||||
- [[Blue-Hat-Logo]]：保健食品"蓝帽子"注册标志——合法保健食品必须取得并展示
|
||||
- [[Appearance-Anxiety]]：容貌焦虑——医美广告2021年起明确禁止制造焦虑情绪的表述
|
||||
- [[Internet-Diagnosis-Treatment]]：互联网诊疗规范——初诊必须线下面诊，复诊限常见病/慢性病
|
||||
- [[Patient-Privacy-PIPL]]：《个人信息保护法》将个人健康医疗信息认定为敏感信息，须单独授权
|
||||
- [[Academic-Detailing]]：学术推广合规——医疗代表备案、会议赞助标准、医师讲课费规范
|
||||
- [[Platform-Content-Review]]：平台内容审核机制——抖音/小红书/微信各有行业准入标准和内容红线
|
||||
- [[Compliance-Risk-Matrix]]：医疗营销合规风险分级矩阵（Critical/High/Medium/Low + 处置建议）
|
||||
- [[医疗广告审查证明]]：医疗广告必须经省级卫生行政部门审查并取得，是行政罚款和刑事追责的基准线
|
||||
- [[处方药广告禁令]]：处方药严禁在大众媒体发布广告，是药品营销合规的核心红线
|
||||
- [[保健食品功能声称范围]]：仅可在注册/备案的24项保健功能范围内声称，超出即为违规
|
||||
- [[医疗器械分类管理]]：一类（低风险，备案管理）、二类（中风险，注册证）、三类（高风险，最严格监管）
|
||||
- [[互联网诊疗红线]]：初诊必须线下面诊，复诊限于常见病和慢性病
|
||||
- [[患者隐私敏感信息]]：医疗健康信息属于敏感个人信息，《个人信息保护法》处理需单独同意
|
||||
- [[医美广告容貌焦虑禁令]]：不得使用"丑""不好看""影响社交/就业"等暗示性语言
|
||||
- [[学术推广合规]]：药企学术会议赞助需明确内容与金额，不得影响学术独立性；医药代表不得有销售指标
|
||||
|
||||
## Key Entities
|
||||
- [[NMPA]]（国家药品监督管理局）：负责药品/医疗器械注册审批及广告批准文号管理
|
||||
- [[SAMR]]（国家市场监督管理总局）：2021年发布《医疗美容广告执法指南》，主导医美合规整治
|
||||
- [[Haodf]]（好大夫在线）：互联网医疗平台——医师入驻资质审核、患者评价管理、图文/视频问诊标准
|
||||
- [[DXY]]（丁香园）：医师专业社区——健康科普内容专业审核机制、医师认证体系、商业合作与编辑独立性分离
|
||||
- [[WeDoctor]]（微医）：互联网医院牌照、在线处方流转、医保接入合规
|
||||
- [[JD-Health]]（京东健康）：在线售药资质、处方药审核流程、物流配送合规
|
||||
- [[Douyin]]（抖音）：医疗行业准入（须提交医疗机构执业许可证或药械资质）、认证医师标识、直播带货限制
|
||||
- [[Xiaohongshu]]（小红书）：2021年起大规模清理医美内容、白名单管理制度、蒲公英品牌合作平台合规要求
|
||||
- [[WeChat]]（视频号）：医疗机构公众号认证、朋友圈广告投放规范、小程序在线问诊/售药资质要求
|
||||
- [[国家药品监督管理局（NMPA）]]：药品/医疗器械注册审批及广告批准号颁发机构
|
||||
- [[国家市场监督管理总局（SAMR）]]：2021年发布《医疗美容广告执法指南》，主导医美广告监管
|
||||
- [[国家卫生健康委员会]]：医疗广告审查证明颁发机构
|
||||
- [[抖音（Douyin）]]：医疗行业需提交医疗机构执业许可证或药品/器械资质进行行业认证；直播中不得推荐具体药品或治疗方案
|
||||
- [[小红书（Xiaohongshu）]]：2021年起大规模清理医美内容，医疗内容现实行白名单管理
|
||||
- [[好大夫在线（Haodf）]]：医生入驻资质审核、患者评价管理、图文/视频问诊标准
|
||||
- [[丁香园（DXY）]]：健康科普内容专业审核机制、医生认证体系、商业合作与编辑独立性分离
|
||||
- [[平安好医生/阿里健康]]：在线售药资质、处方药审核流程、物流配送合规
|
||||
|
||||
## Connections
|
||||
- [[Healthcare-Marketing-Compliance]] ← extends ← [[The-Agency]]（Specialized 部门）
|
||||
- [[Healthcare-Marketing-Compliance]] ← depends_on ← [[NMPA]]（监管机构）
|
||||
- [[Healthcare-Marketing-Compliance]] ← depends_on ← [[SAMR]]（执法机构）
|
||||
- [[Platform-Content-Review]] ← extends ← [[Healthcare-Marketing-Compliance]]
|
||||
- [[Patient-Privacy-PIPL]] ← depends_on ← [[Healthcare-Marketing-Compliance]]
|
||||
- [[Academic-Detailing]] ← extends ← [[Healthcare-Marketing-Compliance]]
|
||||
- [[Healthcare-Customer-Service]] ← 延伸 ← [[Healthcare-Marketing-Compliance]]：合规营销为客服提供合规话术基础
|
||||
- [[Compliance-Auditor]] ← 依赖 ← [[Healthcare-Marketing-Compliance]]：合规审计需要营销合规标准作为检查基准
|
||||
- [[Marketing-Content-Creator]] ← 受约束 ← [[Healthcare-Marketing-Compliance]]：内容创作必须遵循医疗广告禁用语和审核要求
|
||||
- [[Healthcare-Marketing-Compliance]] ← 依赖 ← [[Personal-Information-Protection-Law]]：患者健康数据合规处理是营销内容的数据隐私底线
|
||||
- [[Multi-Agent-System-Reliability]] ← 支撑 ← [[Healthcare-Marketing-Compliance]]：合规专家 Agent 是企业级 Agent 系统可靠运营的必要组成部分
|
||||
|
||||
## Contradictions
|
||||
- 与 [[legal-compliance-checker]] 潜在冲突：
|
||||
- 冲突点：通用法律合规 Agent 与医疗专项合规 Agent 的职责边界
|
||||
- 当前观点：医疗营销合规具有高度专业化特征（广告法/药械注册/平台规则），通用法律合规工具无法覆盖
|
||||
- 对方观点：合规 Agent 应具备跨行业通用合规框架，无需细分至医疗领域
|
||||
- 解决方向：通用合规 Agent 负责数据隐私/合同合规等横向能力，医疗营销合规 Agent 专注垂直领域规则差异
|
||||
- 与 [[Marketing-Content-Creator]] 的内容创作灵活性需求：
|
||||
- 冲突点：营销追求吸引力和转化率，合规要求严谨和克制
|
||||
- 当前观点：合规优先，内容必须在法律边界内创作，通过场景化叙事和视觉设计提升表现力
|
||||
- 对方观点：内容创作追求最大创意空间，希望突破保守表达方式
|
||||
- 协调方案：合规制定禁用语清单和风险评级，内容创作在清单范围内最大化创意空间；高风险内容走合规审核流程
|
||||
|
||||
53
wiki/sources/hospitality-guest-services.md
Normal file
53
wiki/sources/hospitality-guest-services.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Hospitality Guest Services"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/hospitality-guest-services.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：酒店及综合款待业（酒店/度假村/餐厅/活动场地）的宾客服务专家 AI Agent，涵盖从预订、入住、住店、投诉处理、离店到售后全流程
|
||||
- 问题域：如何通过结构化的 Agent Prompt 让 AI 在酒店前台、礼宾、客服等场景中提供始终如一的高质量宾客体验，同时驱动忠诚度和营收增长
|
||||
- 方法/机制：定义 Agent 身份（记忆系统）→ 10条黄金规则 → 五段式工作流（预订/入住/住店/退房/售后）→ 技术交付物模板（预订确认函、HEARD 投诉处理、SERVICE RECOVERY、忠诚计划管理等）
|
||||
- 结论/价值：宾客服务不是交易而是情感连接；在线评价能直接影响营收（评分每升1分可带动营收增长9%）；每次投诉都是修复和留存的机会
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 宾客服务不是交易——而是一种情感体验，每一次宾客互动都是创造回忆、赢得回头客和生成五星好评的机会
|
||||
- 一条投诉就是一份礼物——愿意投诉的宾客说明仍相信你能补救，不投诉直接离开的宾客永远流失
|
||||
- 服务恢复必须即时且真诚——对宾客投诉的延迟响应会将负面影响翻倍，应在发现服务失误的那一刻立即处理
|
||||
- 忠诚会员必须被认可——每次入住都要在办理入住手续时承认其忠诚身份和等级
|
||||
- 食物过敏和饮食限制是不可妥协的——每笔餐饮预订必须记录饮食限制，每位餐饮团队成员必须在服务前收到通知
|
||||
- 在线评价塑造营收——酒店评分每提高1分，营收可增加高达9%
|
||||
|
||||
## Key Quotes
|
||||
> "The best hotels don't just give guests a room — they give them an experience. The best restaurants don't just serve food — they create moments." — 核心服务理念
|
||||
|
||||
> "A guest who complains is a guest who still believes you can make it right. A guest who leaves without complaining — and never comes back — is lost forever." — 投诉即礼物
|
||||
|
||||
> "Every complaint is a gift." — 服务恢复哲学
|
||||
|
||||
## Key Concepts
|
||||
- [[HEARD Method]]：投诉处理五步法——H（完整倾听）、E（真诚共情）、A（诚挚道歉）、R（即时解决）、D（超越期望的补偿）
|
||||
- [[Guest Journey]]：宾客旅程全流程——预订（Reservations）→ 预到（Pre-Arrival）→ 入住（Check-In）→ 住店（In-Stay）→ 投诉处理（Complaint Resolution）→ 退房（Check-Out）→ 售后（Post-Stay）→ 活动与团队（Events & Groups）
|
||||
- [[Service Recovery Protocol]]：服务恢复协议——标准化投诉处理流程，包含立即行动、分级补偿方案（绿/黄/红/紧急四级）和跟进承诺
|
||||
- [[Loyalty Program Management]]：忠诚计划管理——会员注册、等级认可、积分追踪、投诉升级的完整生命周期管理
|
||||
- [[Concierge Services]]：礼宾服务——餐厅预订、交通安排、本地活动、场内服务（spa/健身/客房服务）的综合服务能力要求
|
||||
- [[Review Management]]：评价管理——退房体验、口碑请求、差评响应模板及24小时响应规则
|
||||
|
||||
## Key Entities
|
||||
- [[Hotel Property]]：酒店物业——服务交付的物理场所，提供客房、餐饮、活动场地等综合服务
|
||||
- [[OTA (Online Travel Agency)]]：在线旅游代理商——Expedia、Booking.com 等平台，评价响应策略需要兼顾其规则
|
||||
- [[Food Allergy]]：食物过敏——不可妥协的医疗安全问题，宾客餐饮预订必须强制记录
|
||||
- [[VIP Guest]]：重要宾客——特殊入住体验、高管迎接、个性化安排的重点服务对象
|
||||
|
||||
## Connections
|
||||
- [[Hospitality Guest Services]] ← supports ← [[Hotel Property Operations]]
|
||||
- [[HEARD Method]] ← core framework ← [[Service Recovery Protocol]]
|
||||
- [[Loyalty Program Management]] ← drives ← [[Guest Journey]]
|
||||
- [[Review Management]] ← impacts ← [[OTA Rankings]]
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
54
wiki/sources/hr-onboarding.md
Normal file
54
wiki/sources/hr-onboarding.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "HR Onboarding Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/hr-onboarding.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency 企业级新员工入职管理专家 Agent，覆盖从入职前准备到第一年结束的完整员工入职生命周期
|
||||
- 问题域：企业人力资源入职流程标准化、合规管理、福利登记、团队融入和90天绩效基础建立
|
||||
- 方法/机制：五阶段工作流（预入职→入职第一天→第一周整合→30-60-90天里程碑→转入稳态）+ 十项关键行为规则 + 量化成功指标体系
|
||||
- 结论/价值：入职体验质量直接决定员工90天留存率和长期生产力贡献；管理者关系是比薪酬更关键的留任驱动因素；入职不是行政文书工作，而是员工职业故事的第一章
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 入职前90天的表现直接决定新员工是成为长期贡献者还是遗憾离职——入职体验质量是员工留存率和生产力的最强预测因子
|
||||
- I-9验证、W-4表格和合规政策确认必须在法律规定的时限内完成——合规截止日期的疏忽将对公司和员工都造成严重法律后果
|
||||
- 管理者关系是员工留任最关键的驱动因素，研究表明其影响超过任何其他因素——管理者支持度直接决定新员工90天融入质量
|
||||
- 福利登记窗口是硬性截止日期，大多数福利要求在入职30天内完成登记——错过截止日期可能导致员工整个年度无法享受福利保障
|
||||
- 主动定期检查比被动等待问题出现效果更好——新员工在前90天不太可能主动表达担忧，结构化的签到机制能建立心理安全感
|
||||
- 入职第一天的混乱或组织无序会向新员工传递公司管理水平的负面信号——专业细致的入职流程反映企业文化品质
|
||||
- 文档必须完整且可接受审计——每份表格、确认书和合规记录都必须妥善存储以备查询，档案不完整会构成法律风险
|
||||
|
||||
## Key Quotes
|
||||
> "Onboarding isn't paperwork — it's the first chapter of an employee's story with your company. Write it well, and they'll stay to write the rest. Write it poorly, and they'll be gone before the story gets good." — HR Onboarding Agent 核心理念
|
||||
> "The first 90 days determine whether a new hire becomes a long-term contributor or a regrettable turnover. Get it right from day one." — 入职体验重要性定位
|
||||
|
||||
## Key Concepts
|
||||
- [[30-60-90-Day-Plan]]：新员工入职前三个月的阶梯式发展框架——Day 1-30 Learn（学习与融入）、Day 31-60 Contribute（独立贡献）、Day 61-90 Accelerate（加速影响），每个阶段设定明确目标、成功标志和管理者检查节奏
|
||||
- [[Pre-Boarding]]：入职前准备阶段——在正式入职前完成的IT设备配置、系统账户开通、欢迎邮件发送和经理入职指南传递，为入职第一天做好充分准备
|
||||
- [[Day-One-Orientation]]：入职第一天标准日程模板——从上午9:00欢迎致辞到下午4:30入职总结，涵盖合规文书、IT配置、团队介绍和Buddy制度
|
||||
- [[Psychological-Safety]]：心理安全感——在入职环境中创造让新员工敢于提问、不怕犯错的安全氛围，是主动沟通和早期问题浮出水面的前提条件
|
||||
- [[Buddy-System]]：Buddy制度——为每位新员工在入职前指派一位团队成员作为非正式的问答资源和职场向导，在入职第一天引介并持续支持前30天
|
||||
|
||||
## Key Entities
|
||||
- [[The-Agency]]：The Agency 企业——HR Onboarding Agent 所属组织，为各行业提供147个专业 Agent，HR Onboarding Agent 属于 Specialized 部门，专注于企业级人力资源入职管理
|
||||
- [[Workday]]：企业HRIS系统——HR Onboarding Agent 的技术栈之一，用于入职工作流自动化、文档管理、福利登记和报告分析（仅在本页提及1次，已在 Key Entities 中引用）
|
||||
- [[BambooHR]]： SMB人力资源管理系统——HR Onboarding Agent 推荐的入门级HRIS选项，支持新员工数据包、电子签名和PTO追踪（仅在本页提及1次）
|
||||
- [[Rippling]]：一体化HR平台——HR Onboarding Agent 推荐的全功能平台，支持自动化配置、合规培训和设备管理（仅在本页提及1次）
|
||||
|
||||
## Connections
|
||||
- [[recruitment-specialist]] ← handoff ← HR Onboarding Agent：新员工从招聘流程进入入职流程，招聘专员需提前通知入职日期、角色详情和经理信息
|
||||
- [[support-legal-compliance-checker]] ← depends_on ← HR Onboarding Agent：入职合规培训框架依赖法律合规专家定义的多司法管辖区合规标准
|
||||
- [[customer-service]] ← extends ← HR Onboarding Agent：入职后的客户服务团队（支持部门）延续入职期间建立的第一印象
|
||||
- [[ComplianceTraining]] ← shared_concept ← HR Onboarding Agent：合规培训体系（入职合规）与法律合规专家的合规培训体系（监管合规）共享同一核心概念
|
||||
|
||||
## Contradictions
|
||||
- 与 [[compliance-auditor]] 的合规视角差异：
|
||||
- 冲突点：HR Onboarding Agent 将 I-9 验证和合规培训视为入职门槛（必须100%按时完成），而法律合规专家的合规框架更侧重持续合规文化
|
||||
- 当前观点（HR Onboarding）：合规是入职第一天完成的硬性法律要求，不完成则员工无法合法工作
|
||||
- 对方观点（Compliance Auditor）：合规培训应与实际工作场景结合，而非一次性强制完成
|
||||
- 协调方案：两者互补而非矛盾——入职合规（文书+培训）是底线，法律合规文化是入职后持续深化的长期过程
|
||||
43
wiki/sources/i18n-readme.md
Normal file
43
wiki/sources/i18n-readme.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "Chinese (zh-CN) Localization"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/scripts/i18n/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：将 GitHub Copilot Agent 的 name 和 description 字段本地化为简体中文
|
||||
- 问题域：AI Agent 在 Copilot Chat Agent 选择器中的中文用户本地化体验
|
||||
- 方法/机制：通过 PowerShell 脚本读取 JSON 翻译映射表，自动替换 YAML frontmatter 中的 name/description 字段
|
||||
- 结论/价值：实现 Agent 界面的中文本地化，提升中文用户的使用体验；JSON 文件作为翻译的唯一数据源
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- PowerShell 脚本 `localize-agents-zh.ps1` 读取 UTF-8 编码的 `agent-names-zh.json` 翻译映射表
|
||||
- 脚本仅修改已安装副本（`~/.github/agents/` 和 `~/.copilot/agents/`），不修改源文件
|
||||
- 仅替换 YAML frontmatter 中的 `name:` 和 `description:` 字段
|
||||
- JSON 文件是翻译的唯一真实来源，新增 Agent 需先添加到 JSON 中
|
||||
- 脚本采用纯 ASCII 编码（避免 PowerShell 编码问题），所有中文文本存储在 JSON 文件中
|
||||
- 每次运行 `install.sh --tool copilot` 更新后需重新运行本地化脚本
|
||||
|
||||
## Key Quotes
|
||||
> "Only modifies **installed copies** (in `~/.github/agents/`), not source files" — 关键约束：只修改安装副本
|
||||
> "JSON file is the single source of truth for translations — add new agents there" — JSON 文件作为翻译唯一数据源的设计原则
|
||||
> "Script is pure ASCII (avoids PowerShell encoding issues); all Chinese text lives in the JSON" — 纯 ASCII 脚本 + UTF-8 JSON 的分工设计
|
||||
|
||||
## Key Concepts
|
||||
- [[Global-First-Architecture]]：国际化/本地化（i18n/l10n）作为产品架构的先天前提条件，而非上线后的补救措施
|
||||
- [[YAML-Configuration]]：YAML frontmatter 配置格式，存储 Agent 的 name 和 description 元数据
|
||||
|
||||
## Key Entities
|
||||
- [[The-Agency]]：开源多 Agent 框架，提供了 Copilot Agent 的安装脚本 `install.sh --tool copilot`
|
||||
- [[GitHub-Copilot]]：微软的 AI 编程助手，其 Chat 支持自定义 Agent，Agent 以 Markdown + YAML frontmatter 格式定义
|
||||
|
||||
## Connections
|
||||
- [[Qwen Code Integration]] ← related_to ← [[i18n-readme]]（均为 Agency Agents 的多工具集成功能）
|
||||
- [[i18n-readme]] ← extends ← [[GitHub-Copilot]]（将英文 Copilot Agent 本地化为中文）
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
@@ -2,22 +2,22 @@
|
||||
title: "Identity Graph Operator"
|
||||
type: source
|
||||
tags: ["multi-agent", "identity-resolution", "entity-resolution", "the-agency"]
|
||||
date: 2026-04-24
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/identity-graph-operator.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多智能体系统中的共享身份图谱运营——确保所有 Agent 对同一真实世界实体（人/公司/产品）得到一致的规范化实体 ID，解决多 Agent 系统的核心问题：重复记录、冲突操作、级联错误。
|
||||
- 问题域：多 Agent 系统中的身份孤岛问题——当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。
|
||||
- 方法/机制：通过身份解析引擎（Identity Engine）进行规范化（Normalization）→ 阻塞（Blocking）→ 评分（Scoring）→ 聚类（Clustering），返回相同 entity_id；支持昵称扩展（Bill→William）、E.164 电话标准化、邮箱小写化；merge/split 操作通过乐观锁执行，保留完整事件历史；直接变更 vs 提案决策按置信度分级处理。
|
||||
- 结论/价值：零身份冲突生产环境、合并准确率 > 99%、P99 解析延迟 < 100ms、全链路审计追踪。与 [[Multi-Agent-System-Reliability]] 的 Agent 协作模式互补——后者解决 Agent 间决策一致性问题，前者解决 Agent 对同一实体的识别一致性问题。
|
||||
- 核心主题：多智能体系统中的共享身份图谱运营——确保所有 Agent 对同一真实世界实体（人/公司/产品/交易记录）得到一致的规范化 entity_id，解决多 Agent 系统的核心问题：重复记录、冲突操作、级联错误。
|
||||
- 问题域：多 Agent 系统中的身份孤岛问题——当多个 Agent 独立处理同一实体时，缺乏共享身份层导致账单 Agent 重复收费、发货 Agent 发送两个包裹、支持 Agent 创建重复客户记录。没有共享身份解析，就会产生重复、冲突和级联错误。
|
||||
- 方法/机制：通过身份解析引擎（Identity Engine）进行规范化（Normalization）→ 阻塞（Blocking）→ 评分（Scoring）→ 聚类（Clustering），返回相同 entity_id；支持昵称扩展（Bill→William）、E.164 电话标准化、邮箱小写化；merge/split 操作通过乐观锁（optimistic locking）执行，保留完整事件历史（entity.created/merged/split/updated）；直接变更 vs 提案决策按置信度分级处理；支持实时路径（<100ms P99）和批量路径（百万级图谱聚类）混合解析。
|
||||
- 结论/价值：零身份冲突生产环境、合并准确率 > 99%、P99 解析延迟 < 100ms、全链路审计追踪。跨编排框架（LangChain/CrewAI/AutoGen/Semantic Kernel）身份联邦，跨 Agent 共享记忆。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **相同输入，相同输出**：两个 Agent 解析同一条记录必须得到相同 entity_id，这是绝对原则，不可妥协。
|
||||
- **相同输入，相同输出**：两个 Agent 解析同一条记录必须得到相同 entity_id，绝对原则，不可妥协。
|
||||
- **证据优先于断言**：合并必须有字段级证据支撑（email exact match + name fuzzy match + phone match），仅凭"看起来相似"不足以触发合并。
|
||||
- **提案优于直接变更**：与其他 Agent 协作时，优先提出带证据的合并提案，而非直接执行，让对方 Agent 审查证据。
|
||||
- **提案优于直接变更**：与其他 Agent 协作时，优先提出带证据的合并提案（per-field evidence），而非直接执行，让对方 Agent 审查证据。
|
||||
- **外部 ID 排序**：使用 external_id 排序而非 UUID（UUID 无序），确保排序稳定性。
|
||||
- **从不跳过引擎**：不硬编码字段名、权重或阈值，由匹配引擎统一计算候选评分。
|
||||
|
||||
@@ -25,6 +25,7 @@ date: 2026-04-24
|
||||
> "Same input, same output. Two agents resolving the same record must get the same entity_id. Always." — Determinism 原则核心表述
|
||||
> "Never merge without evidence. 'These look similar' is not evidence. Per-field comparison scores with confidence thresholds are evidence." — Evidence Over Assertion 原则
|
||||
> "When agents disagree — one proposes merge, another proposes split on the same entities — both proposals are flagged as 'conflict.' Add comments to discuss before resolving. Never resolve a conflict by overriding another agent's evidence." — 冲突处理机制
|
||||
> "The moment two agents can encounter the same entity from different sources, you need shared identity resolution. Without it, you get duplicates, conflicts, and cascading errors." — 何时需要 Identity Graph Operator
|
||||
|
||||
## Key Concepts
|
||||
- [[Identity Resolution（身份解析）]]：将多条记录归一化为同一 canonical entity_id 的过程——通过 blocking/scoring/clustering 实现，与传统主数据管理（MDM）同源但在多 Agent 场景下增加了并发写入和分布式协调维度。
|
||||
@@ -33,7 +34,7 @@ date: 2026-04-24
|
||||
- [[Confidence Score（置信度评分）]]：字段级证据分数加权求和得出的合并置信度——决定直接合并（>0.95）、提案审查（0.6-0.95）还是创建新实体（<0.6），是自动决策与人机协作的分界点。
|
||||
- [[Optimistic Locking（乐观锁）]]：通过版本号（version field）防止并发写入冲突——变更需携带 expected_version，版本不匹配时拒绝执行，是图谱完整性的并发保护机制。
|
||||
- [[Evidence-based Merge Proposal（证据驱动合并提案）]]：合并前必须构造 per-field evidence（email_match/score/values、name_match/score/values），让其他 Agent 基于证据而非断言进行审查，是多 Agent 身份协调的核心协议。
|
||||
- [[Multi-Agent Identity Coordination（多 Agent 身份协调）]]：跨 Agent 的 merge/split 冲突检测、跨编排框架（LangChain/CrewAI/AutoGen）的身份联邦，以及 shared agent memory（跨 Agent 知识共享）——是 Identity Graph Operator 与 [[Multi-Agent-System-Reliability]] 的本质区别。
|
||||
- [[Multi-Agent Identity Coordination（多 Agent 身份协调）]]：跨 Agent 的 merge/split 冲突检测、跨编排框架的身份联邦、以及 shared agent memory（跨 Agent 知识共享）——是 Identity Graph Operator 的核心差异化能力。
|
||||
|
||||
## Key Entities
|
||||
- [[Identity Graph Operator]]：身份图谱运营者 Agent——本文档描述的核心 Agent，拥有共享身份层的所有权，负责多 Agent 系统的实体解析、合并提案和冲突协调。
|
||||
|
||||
40
wiki/sources/integrations-kimi-code-cli.md
Normal file
40
wiki/sources/integrations-kimi-code-cli.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Kimi Code CLI Integration"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-09
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/integrations/kimi/README.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency Agent roster 与 Kimi Code CLI 的集成方案
|
||||
- 问题域：如何将 YAML 格式的 Agent 规范文件安装到本地 Kimi Code CLI 环境
|
||||
- 方法/机制：通过 `convert.sh` 将 .md Agent 定义转换为 `agent.yaml` + `system.md` 结构，再通过 `install.sh` 安装到 `~/.config/kimi/agents/`
|
||||
- 结论/价值：提供与 Kimi Code CLI 的零门槛集成，支持在项目中通过 `--agent-file` 和 `--work-dir` 指定特定 Agent 开展工作
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- The Agency 通过 `agent.yaml` + `system.md` 双文件结构将任意 Agent 转换为 Kimi Code CLI 可加载的规范
|
||||
- `convert.sh --tool kimi` 生成中间文件，`install.sh --tool kimi` 部署到 `~/.config/kimi/agents/`
|
||||
- 安装后通过 `--agent-file` 路径激活指定 Agent，支持 `--work-dir` 指定项目工作目录
|
||||
|
||||
## Key Quotes
|
||||
> "Converts all Agency agents into Kimi Code CLI agent specifications. Each agent becomes a directory containing `agent.yaml` (agent spec) and `system.md` (system prompt)." — 文档开篇定义
|
||||
> "Kimi CLI not detected — Make sure `kimi` is in your PATH" — 故障排除指导
|
||||
|
||||
## Key Concepts
|
||||
- [[AgentIntegration]]：The Agency 通过标准化脚本将 Agent roster 转换为各目标工具格式的集成机制
|
||||
- [[AgentScopes]]：Kimi Code CLI 集成属于 Home-Scoped 作用域（`~/.config/kimi/agents/`）
|
||||
|
||||
## Key Entities
|
||||
- [[The-Agency]]：提供 Agent roster 的开源多 Agent 框架项目
|
||||
- [[Kimi]]：Moonshot AI 推出的命令行 AI 编程助手
|
||||
|
||||
## Connections
|
||||
- [[Claude-Code]] ← similar_approach ← [[integrations-kimi-code-cli]]
|
||||
- [[OpenCode]] ← similar_approach ← [[integrations-kimi-code-cli]]
|
||||
- [[integrations-readme]] ← belongs_to ← [[The-Agency]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突（Kimi Code CLI 集成与 Claude Code/OpenCode/OpenClaw 等其他集成路径互为补充，各自在不同工具中实现 Agent 复用）
|
||||
56
wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md
Normal file
56
wiki/sources/karpathy-最新分享-用-llm-搭建个人知识库-告别-rag-的低效循环.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环"
|
||||
type: source
|
||||
tags: [AI, knowledge-base, LLM, Obsidian, RAG]
|
||||
date: 2026-04-20
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/Karpathy 最新分享：用 LLM 搭建个人知识库，告别 RAG 的低效循环]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Karpathy 提出用 LLM 构建持久化个人 Wiki 替代 RAG 方案，实现知识的增量积累与自动交叉引用
|
||||
- 问题域：传统 RAG 每次从零检索、无积累、维护成本高的问题
|
||||
- 方法/机制：
|
||||
- Obsidian Web Clipper 采集素材并自动转为 Markdown
|
||||
- Ctrl+Shift+D 快捷键批量下载图片本地化
|
||||
- Graph View 图谱视图做 Lint 健康检查和发现知识盲区
|
||||
- Dataview 插件做 frontmatter 数据库式查询
|
||||
- Marp 插件将 Wiki 内容导出为幻灯片
|
||||
- Git 版本管理自动 commit + push
|
||||
- qmd 本地 Markdown 搜索引擎做精准检索
|
||||
- 结论/价值：AI 负责知识库维护（更新交叉引用、保持摘要最新），人类只负责读和想——维护成本趋近于零
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Karpathy + 老张：通过让 AI 增量构建和维护持久化 Wiki，实现了从"每次从零开始"到"知识持续沉淀"的范式转变
|
||||
- Karpathy：RAG 的根本问题是"没有积累"，每次提问 AI 都在从头搜寻知识，综合多文档时尤其低效
|
||||
- Karpathy：LLM Wiki 使 AI 能一次操作修改多个文件，维护交叉引用和页面一致性的成本趋近于零
|
||||
- 老张：对于大多数用户，Obsidian Web Clipper + 图片本地化 + Git + Claude 就足够打造 RAG 知识库
|
||||
|
||||
## Key Quotes
|
||||
> "维护知识库最痛苦的不是阅读和思考，而是记录。更新交叉引用、保持摘要最新、标注新旧矛盾、维护几十个页面的一致性。" — Karpathy 论 RAG 的维护成本问题
|
||||
> "AI 不会厌倦，不会忘记更新交叉引用，一次操作可以碰十五个文件。维护成本趋近于零，知识库就能真正活下去。" — Karpathy 论 AI 维护 Wiki 的优势
|
||||
> "你把精力放在选素材、定方向、问好问题、思考意义，AI 负责其他一切。" — Karpathy LLM Wiki 思想精髓
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：检索增强生成，传统 AI 知识管理方案，每次从零检索，无积累
|
||||
- [[LLM Wiki]]：Karpathy 提出的替代方案，让 AI 增量构建和维护持久化的互相链接的 Markdown 文件 Wiki
|
||||
- [[Obsidian]]：本地笔记工具，支持双向链接、Graph View、丰富的社区插件生态
|
||||
- [[Obsidian Web Clipper]]：浏览器插件，一键将网页文章保存为 Markdown 到 Obsidian
|
||||
- [[Graph View]]：Obsidian 内置图谱视图，以节点展示所有页面，双链关系自动连线
|
||||
- [[Dataview]]：Obsidian 社区插件，对 frontmatter 做数据库式查询，动态生成表格和列表
|
||||
- [[Marp]]：基于 Markdown 的幻灯片格式，配合 Obsidian Marp Slides 插件可预览和导出 PDF/HTML/PPTX
|
||||
- [[Obsidian Git]]：Obsidian Git 版本管理插件，设置 Auto commit-and-sync interval 自动 commit + push
|
||||
- [[qmd]]：完全本地运行的 Markdown 搜索引擎，用于大规模 Wiki 的精准检索
|
||||
|
||||
## Key Entities
|
||||
- [[Karpathy]]：OpenAI 创始人之一、知名 AI 研究者，GitHub Gist 提出 LLM Wiki 方法论
|
||||
- [[laozhang2579]]：发布者/解读者，将 Karpathy 的方法实操落地为中文教程
|
||||
|
||||
## Connections
|
||||
- [[LLM Wiki]] ← 来源 ← [[Karpathy]]
|
||||
- [[LLM Wiki]] ← 工具基础 ← [[Obsidian]]
|
||||
- [[RAG]] ← 对比/替代 → [[LLM Wiki]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突页面
|
||||
61
wiki/sources/language-translator.md
Normal file
61
wiki/sources/language-translator.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Language Translator"
|
||||
type: source
|
||||
tags: ["agent", "translation", "spanish", "english", "bilingual", "travel", "medical", "business", "legal"]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/language-translator.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LLM Agent 在实时西班牙语 ↔ 英语翻译领域的专业化设计，涵盖文化语境、地域方言感知、旅行短语引导，以及适用于日常、商务、紧急场景的语气适配沟通。
|
||||
- 问题域：如何让 AI 翻译超越逐字替换，实现意义传递，同时保持文化敏感性和地域方言准确性。
|
||||
- 方法/机制：通过系统化的 5 步工作流（理解请求 → 意义翻译 → 输出丰富化 → 特殊处理 → 跟进）结合记忆与学习机制，提供带语音发音指南、文化注释和紧急优先的翻译服务。
|
||||
- 结论/价值：翻译的本质是意义转移而非词典替换；文化语境、方言差异和语气级别是翻译质量的决定性因素；紧急短语需立即呈现，专业医学/法律翻译应建议人工介入。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 翻译 = 意义转移，非逐字替换："It's raining cats and dogs" → "Está lloviendo a cántaros" 而非 "lloviendo gatos y perros"。
|
||||
- 西班牙语正式/非正式语域（usted/tú）决定沟通成败，错误选择可导致冒犯或误解。
|
||||
- 地域方言至关重要：同一词汇在不同国家含义迥异（如 "coche" 在西班牙=汽车，在拉丁美洲某些地区含义不同）。
|
||||
- 医疗/法律翻译不可猜测，复杂场景应建议专业人工口译员介入。
|
||||
- 紧急短语具有绝对优先权：翻译立即呈现，解释随后补充。
|
||||
- 发音指南是翻译的必备组成部分，使用简明英语拼音而非 IPA 标注。
|
||||
|
||||
## Key Quotes
|
||||
> "Translation isn't word-for-word substitution — it's meaning transfer. The goal is never a dictionary output; it's a message the other person actually understands."
|
||||
> — The Language Translator Agent 核心原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Meaning Transfer Translation]]：翻译 = 意义转移，而非逐字替换；目标是有用信息，而非字典输出。
|
||||
- [[Register Switching]]：西班牙语正式（usted）/非正式（tú）语域切换；陌生人默认使用 usted，本地人先使用 tú 才跟随切换。
|
||||
- [[Regional Dialect Awareness]]：不同西语国家（墨西哥/西班牙/阿根廷/哥伦比亚等）的词汇差异；翻译需注明地域变体。
|
||||
- [[Phonetic Pronunciation Guide]]：为口语翻译提供英语拼音标注（非 IPA），确保用户能实际说出短语。
|
||||
- [[Cultural Context Flag]]：主动标注文化差异——某地礼貌用语在另一地可能具有冒犯性。
|
||||
- [[Emergency-First Protocol]]：紧急医疗/安全/法律短语立即呈现，先于任何解释。
|
||||
- [[Subjunctive Mood]]：西班牙语虚拟式在愿望、怀疑、情感、假设场景中的使用——翻译不可忽略。
|
||||
- [[Ser vs. Estar]]：两个"to be"动词不可互换——"Soy aburrido"（我无聊/我是个无聊的人）vs "Estoy aburrido"（我现在感到无聊）。
|
||||
- [[False Cognates]]：假同源词陷阱：embarazada=怀孕，sensible=敏感，éxito=成功——直接翻译会完全错误。
|
||||
|
||||
## Key Entities
|
||||
- [[Mexican Spanish]]：美国英语使用者最常见的学习变体；使用 ustedes；纳瓦特尔语借词丰富。
|
||||
- [[Castilian Spanish (Spain)]]：使用 vosotros（非正式复数）；c/z 发 "th" 音；"coger" 在西班牙中性含义在拉丁美洲完全不同（需标注）。
|
||||
- [[Rioplatense Spanish (Argentina/Uruguay)]]：用 vos 替代 tú，变位不同；意大利语影响的词汇和语调。
|
||||
- [[Colombian Spanish (Bogotá)]]：被认为最清晰口音之一；某些地区亲密朋友间也使用正式 usted。
|
||||
- [[Caribbean Spanish]]（古巴、波多黎各、多米尼加）：语速快，辅音弱化（尤其词尾 s），词汇独特。
|
||||
|
||||
## Connections
|
||||
- [[Customer Service Agent]] ← shares_approach ← [[Language Translator]]：两者都优先紧急响应、语气适配和清晰沟通
|
||||
- [[Healthcare Customer Service Agent]] ← medical_context ← [[Language Translator]]：医疗翻译是该 Agent 的重要场景，遵循相同紧急优先原则
|
||||
- [[Specialized Korean Business Navigator]] ← parallel_role ← [[Language Translator]]：同属专业领域语言导航 Agent
|
||||
|
||||
## Contradictions
|
||||
- 与一般翻译工具（如 Google Translate）：
|
||||
- 冲突点：机器翻译倾向于逐字直译，无法区分正式/非正式语域和方言变体。
|
||||
- 当前观点：语言翻译 Agent 强调意义转移、文化语境和地域敏感性，提供场景化翻译输出。
|
||||
- 对方观点：机器翻译速度快、成本低，适合简单信息传递。
|
||||
|
||||
## Aliases
|
||||
- Spanish ↔ English Translator
|
||||
- Bilingual Language Specialist
|
||||
- Real-time Translation Agent
|
||||
@@ -1,57 +1,61 @@
|
||||
---
|
||||
title: "Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform"
|
||||
type: source
|
||||
tags: [Terraform, RDS, IaC, CTP, DevOps, DBRE, AWS]
|
||||
tags:
|
||||
- Terraform
|
||||
- RDS
|
||||
- IaC
|
||||
- Cloud-Transformation-Programme
|
||||
- DBRE
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md]]
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：**通过 Terraform 在 AWS 上部署 RDS 数据库**，涵盖 IaC 最佳实践和 Gruntwork RDS 模块的选型对比
|
||||
- 问题域：RDS 部署方式的选择（控制台 vs 代码）、模块选型（grunt work 模块 vs SRE 核心模块）、Day 2 运维（扩缩容/补丁/升级）
|
||||
- 方法/机制：使用 Terragrunt（Terraform 封装器）管理 RDS 部署，通过 GitHub PR + Atlantis 实现变更自动化；CloudWatch 负责监控告警
|
||||
- 结论/价值：IaC 部署任何规模的 RDS 到 AWS 均优于控制台；grunt work RDS Service 相比裸模块提供更完整的企业级功能（KMS 加密、CloudWatch 告警等）；代码即文档
|
||||
- 核心主题：通过 Terraform 在 AWS 上自动化部署 RDS 数据库，DBRE 团队的 Greg 主讲
|
||||
- 问题域：IaC 部署 RDS 的模块选型、Day 2 运维操作、监控告警配置
|
||||
- 方法/机制：推荐使用 Gruntwork 的 RDS Service 模块（含 KMS 加密、CloudWatch 告警），配合 Terragrunt 管理多环境配置；Day 2 操作通过 GitHub PR + Atlantis 审批后自动 apply
|
||||
- 结论/价值：任何规模的 RDS 部署都应使用 Terraform 而非 Console，IaC 的核心价值在于"代码即文档"
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **IaC 六大大好处**：速度、灵活性、一致性、灾难恢复、文档、自动化。代码即文档
|
||||
- **两种 RDS 部署选项**：裸模块 RDS module（基础功能）vs 更完整的 grunt work RDS Service（推荐，预建 KMS 加密和 CloudWatch 告警）
|
||||
- **SRE 核心模块功能弱于 grunt work 服务**：建议生产环境使用 grunt work RDS Service
|
||||
- **Terragrunt 优于裸 Terraform**：避免变量重复声明，保持代码整洁，贯彻 DRY 原则
|
||||
- **Day 2 运维通过 GitHub PR + Atlantis 实现**：扩缩容、补丁、大版本升级均在 Terragrunt 文件中修改，通过 PR 触发 Atlantis 自动应用
|
||||
- **监控方案**：CloudWatch Dashboard + Alarms，注意突发性能实例（burstable instance）的 CPU credits 消耗
|
||||
- **Greg（DBRE 团队）× IaC 选型**：提倡所有规模的 RDS 部署都使用 Terraform，Console 方式不可取
|
||||
- **IaC 六大核心价值**：速度、灵活性、一致性、灾难恢复、文档化、自动化；"代码即文档"是最核心的文档化原则
|
||||
- **RDS 模块二选一**：grunt work RDS Service（推荐，功能完整）vs SRE Core Modules（功能较少）；grunt work 预置 KMS 加密 + CloudWatch 告警，SRE 模块无此能力
|
||||
- **Terragrunt 实践**：使用 tagged release（不用 master）确保稳定性，避免变量重复声明，代码保持 DRY
|
||||
- **Day 2 运维流程**：变更在 Terragrunt 文件中完成 → GitHub Pull Request → Atlantis 审批 → 自动 apply；支持扩缩容、打补丁、主版本升级
|
||||
- **监控策略**：CloudWatch Dashboard + 告警；burstable 实例需关注 CPU credits
|
||||
|
||||
## Key Quotes
|
||||
> "We use Terragrunt, which is basically it's a wrapper around Terraform, and it allows you to keep your code clean and you're not repeating your variables all the time." — Greg, DBRE Team
|
||||
> "The code is the documentation." — Greg, 强调 IaC 的文档价值
|
||||
|
||||
> "The code is the documentation." — Greg, DBRE Team（IaC 核心哲学）
|
||||
|
||||
## Key Concepts
|
||||
- [[Infrastructure-as-Code]]：通过代码定义和版本控制基础设施资源，核心优势包括速度、一致性、灾难恢复和自动化
|
||||
- [[DRY Principle]]：Terragrunt 通过管理 provider 和 remote_state 块减少跨环境重复声明
|
||||
- [[GitOps]]：通过 GitHub PR + Atlantis 实现基础设施变更的自动化审核和应用
|
||||
- [[CloudWatch-Alarms]]：RDS 监控与告警机制，包含突发性能实例的 CPU credits 考虑
|
||||
- [[KMS-Encryption]]：grunt work RDS Service 内置的 KMS 密钥加密功能
|
||||
- [[Infrastructure-as-Code]]：IaC 是本次分享的主题，Terraform 是核心工具，覆盖速度/灵活性/一致性/灾难恢复/文档化/自动化六大价值
|
||||
- [[InfrastructureAsCode]]：页面已有，本次来源提供 IaC 选型 RDS 的具体实践补充
|
||||
- [[DRY-Principle]]：Terragrunt 践行 DRY 原则，避免变量在多环境间重复声明
|
||||
- [[Terraform-State]]：Terraform 通过状态文件将期望状态绑定到实际环境（本来源提及但未展开）
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]：提供预建 Terraform 模块（RDS Service 等），建议生产环境使用其 grunt work RDS Service 而非裸模块
|
||||
- [[Atlantis]]：Git 驱动的 Terraform 自动化工具，配合 GitHub PR 实现 IaC 变更
|
||||
- [[Terraform]]：云厂商无关的 IaC 核心工具
|
||||
- [[Terragrunt]]：Terraform 的 DRY 封装层，用于管理 RDS 部署配置
|
||||
- [[DBRE]]：Database Reliability Engineering 团队，Greg 来自该团队
|
||||
- [[CloudWatch]]：AWS 监控服务，用于 RDS Dashboard 和 Alarms
|
||||
- [[Greg]]：DBRE 团队成员，本次 Learning Session 的讲师，主讲 Terraform 部署 RDS
|
||||
- [[Amazon-RDS]]：本次分享的核心资源，Greg 主张所有规模都用 Terraform 部署
|
||||
- [[Gruntwork]]：提供 RDS Service 模块和 SRE Core Modules，是本次分享的模块选型依据
|
||||
- [[Terragrunt]]：推荐的 Terraform 封装工具，使用 tagged release 管理多环境
|
||||
- [[AWS]]：RDS 所在的云平台，监控使用 CloudWatch
|
||||
- [[Atlantis]]：GitOps 工具，配合 GitHub PR 实现 RDS 变更的自动化审批和 apply
|
||||
|
||||
## Connections
|
||||
- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（同一 CTP 系列，ECS 部署 + RDS 部署）
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Terragrunt 在两个主题中均有讨论）
|
||||
- [[ctp-topic-16-cross-account-terraform-modules]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（IaC 模块化 + Cross-account Terraform）
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Gruntwork CI/CD 基础）
|
||||
- [[Terraform]] ← wraps ← [[Terragrunt]]
|
||||
- [[Gruntwork]] ← provides ← [[RDS-Module]]（grunt work RDS Service）
|
||||
- [[Atlantis]] ← automates ← [[Terraform]]
|
||||
- [[CloudWatch]] ← monitors ← [[RDS-Module]]
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]] ← related_to ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（两者均讨论 Terragrunt 选型，本来源侧重 RDS 场景下的实践）
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← depends_on ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（基础设施部署与维护是本来源的上下文）
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← extends ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Day 2 运维中 GitHub PR + Atlantis 自动 apply 与该来源的 Atlantis 配置细节互补）
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related_to ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（两者均涉及 Gruntwork 模块体系）
|
||||
- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← extends ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（ECS 部署和 RDS 部署共同构成 CTP 的 IaC 全景）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）：两者均依赖 Gruntwork 模块体系；本主题聚焦 RDS 部署，CI/CD 主题聚焦 ECS 应用部署；RDS 部署同样适用 Gruntwork 流水线规范，两者互补而非冲突
|
||||
- 与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terraform vs Terragrunt）：本主题的实际案例印证了该主题的观点——Terragrunt 保持代码整洁、避免变量重复；两主题一致，共同推荐 Terragrunt 作为 Terraform 的封装层
|
||||
- 与 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）：两者均讨论 Terraform 模块的运维方式；跨账号模块方案（Jenkins + ECS Deploy Runner）与本主题（RDS 通过 Atlantis）的 CI/CD 载体不同，适用于不同规模和架构场景，无直接冲突
|
||||
- 与 [[ctp-topic-48-terraform-vs-terragrunt]] 的潜在冲突：
|
||||
- 冲突点：Terraform vs Terragrunt 的定位
|
||||
- 当前观点（来源）：Terragrunt 是 RDS 部署的首选工具，"keep your code clean, not repeating variables"
|
||||
- 对方观点：CTP Topic 48 对 Terraform 和 Terragrunt 的适用场景做了更细致的对比，指出 Terragrunt 是"轻量封装"而非必须选择
|
||||
- 实际情况：两者不矛盾，本来源是 Terragrunt 的正面用例，Topic 48 提供的是通用对比框架
|
||||
|
||||
60
wiki/sources/legal-billing-time-tracking.md
Normal file
60
wiki/sources/legal-billing-time-tracking.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Legal Billing & Time Tracking"
|
||||
type: source
|
||||
tags: [billing, legal, time-tracking, agency-agent, specialized]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/legal-billing-time-tracking.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Agency Specialized 部门法律事务所计费与时间追踪专家 Agent，覆盖时间捕获、账单叙事撰写、开票生成、催收管理、信托账户合规、计费分析全生命周期六大核心模块。
|
||||
- 问题域：律所营收流失问题——以$300/小时计费标准计算，每位律师每天因时间捕获习惯不佳平均损失2-3小时可计费时间，年均$180,000-$270,000营收蒸发。计费叙事不清晰还会引发客户争议，进一步侵蚀收入。
|
||||
- 方法/机制：10条关键行为规则强制执行（时间实时捕获/禁止计费非billable时间/信托账户神圣/叙事必须诚实具体/永不超过实际时间/遵守客户计费指南/核销需律师批准/催收沟通专业/应急费协议必须书面/争议立即升级）；时间录入标准（0.1小时增量/实时录入/不得模糊描述）；分业务领域的计费叙事模板（诉讼/公司交易/房地产/遗产规划/雇佣）；发票审核清单三段式（客户信息→时间条目→费用汇总）；五阶段催收通信序列（发票发送→友好提醒→逾期通知→最终通知→律师升级）；月度三向对账（银行对账单→客户台账→信托日记账）；关键绩效指标体系（实现率≥90%/实收率≥95%/90天以上AR<5%）。
|
||||
- 结论/价值：计费不是行政职能而是事务所的财务引擎；精准、透明、道德三位一体是计费管理的核心原则。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 律师每天因时间捕获习惯不佳平均损失2-3小时可计费时间，按$300/小时计算年均$180,000-$270,000营收蒸发；事务所财务成功的关键不在于案源多少，而在于能否捕获并收取应得收入。
|
||||
- 信托账户资金神圣不可侵犯——不得与事务所运营资金混同，信托账户错误属于律师纪律处分事项。
|
||||
- 计费叙事必须诚实、具体、可防御——模糊条目如"法律服务""审阅文件""电话"既不专业，又易引发客户争议，且可能存在道德问题。
|
||||
- 时间录入必须实时完成——事后重建的时间条目准确度更低，更容易遭受客户质疑。
|
||||
- 核销（write-down/write-off）必须获得负责律师授权——未经授权不得单方面调整，所有调整必须记录原因代码。
|
||||
- 应急费协议必须书面确认——口头应急费协议在大多数司法管辖区不可强制执行。
|
||||
- 催收通信必须专业但坚定——目标是收款的同时维护客户关系，绝不能越界构成骚扰。
|
||||
- 账单争议必须立即升级至负责律师——不得单方面做出计费调整决定。
|
||||
- 实现率（Realization Rate）目标≥90%——低于85%需调查核销模式。
|
||||
- 收款率（Collection Rate）目标≥95%——低于90%需审查催收流程和客户信用状况。
|
||||
|
||||
## Key Quotes
|
||||
> "The average attorney loses 2-3 hours of billable time every day to poor time capture habits. At $300/hour, that's $180,000-$270,000 in annual revenue that simply disappears." — 核心论点：时间捕获是事务所收入的核心杠杆
|
||||
|
||||
> "Trust accounts are sacred. Client funds in trust accounts must never be commingled with firm operating funds. Disbursements from trust require strict documentation. Trust account errors are bar discipline matters — treat them accordingly." — 核心规则：信托账户零容忍
|
||||
|
||||
## Key Concepts
|
||||
- [[TimeCapture]]：实时时间录入标准，0.1小时（6分钟）最小增量，工作完成后同一天内录入，最多不超过48小时。
|
||||
- [[BillingNarrative]]：计费叙事标准，必须描述做了什么、在哪个案件、为什么做；禁止模糊条目如"法律服务""审阅文件""电话""研究""案件工作""杂项"。
|
||||
- [[IOLTA]]：Interest on Lawyer Trust Accounts，律师信托账户利息，各州规定不同，信托资金产生的利息通常用于法律援助公益。
|
||||
- [[Three-Way-Reconciliation]]：月度三向对账——银行对账单余额 = 各客户台账余额之和 = 信托日记账余额，三者必须完全一致，任何差异需立即调查。
|
||||
- [[Realization-Rate]]：实现率 = 总计费 / 总工时 × 100%，目标≥90%，低于85%需调查核销模式。
|
||||
- [[Collection-Rate]]：实收率 = 总实收 / 总计费 × 100%，目标≥95%，低于90%需审查催收流程。
|
||||
- [[BlockBilling]]：合并多任务为单一条目的计费方式；部分客户指南禁止block billing，违反将导致发票削减并损害客户关系。
|
||||
|
||||
## Key Entities
|
||||
- [[Clio]]：时间录入、开票、信托会计、AR管理的主流法律计费软件之一。
|
||||
- [[LawPay]]：合规法律支付处理平台。
|
||||
- [[QuickBooks]]：与法律计费系统集成进行会计处理的财务软件。
|
||||
- [[The-Agency]]：本 Agent 所属组织，Specialized 部门法律专项 Agent 系列之一。
|
||||
|
||||
## Connections
|
||||
- [[legal-client-intake]] ← extends ← [[legal-billing-time-tracking]]：客户 intake 完成案件信息收集后，计费 Agent 接手财务引擎管理。
|
||||
- [[legal-billing-time-tracking]] ← depends_on ← [[IOLTA]]：信托账户合规管理依赖各州 IOLTA 规定。
|
||||
- [[legal-billing-time-tracking]] ← supports ← [[accounts-payable-agent]]：计费 Agent 负责收款（AR管理），与应付账款 Agent 形成事务所现金流的收/支双侧。
|
||||
- [[legal-billing-time-tracking]] ← informs ← [[support-legal-compliance-checker]]：计费合规性检查（信托账户/计费伦理）需法律合规 Agent 确认。
|
||||
|
||||
## Contradictions
|
||||
- 与"快速简洁 intake"主流观点的潜在张力：
|
||||
- 冲突点：详细的时间录入规范和账单审核清单可能导致 intake 阶段花费更多时间在财务信息收集上。
|
||||
- 当前观点：本 Agent 强调计费数据在 intake 阶段就要建立标准（费率/计费指南/付款条款/信托账户阈值）。
|
||||
- 对方观点：intake 应聚焦案件信息收集，财务细节可延后。
|
||||
- 协调方案：在 intake 流程中预先确认计费框架（费率/指南/付款条款）可显著减少后续开票争议，属于预防性计费管理而非效率损失。
|
||||
55
wiki/sources/legal-client-intake.md
Normal file
55
wiki/sources/legal-client-intake.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Legal Client Intake Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-01
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/legal-client-intake.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI Agent 驱动的法律客户接待与资格审查全流程自动化
|
||||
- 问题域：律所潜在客户流失、 intake 效率低下、冲突检查疏漏、时效性法规风险
|
||||
- 方法/机制：六阶段标准化 intake 工作流（初始接触→资格审查→利益冲突筛查→案件信息收集→咨询安排→摘要交付），配套 10 条关键规则约束行为边界
|
||||
- 结论/价值：提升客户留存率 100% 完成冲突检查、识别所有时效性截止日期、在律师接手前完成 attorney-ready 摘要
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **初始响应速度是转化关键**：在 5 分钟内响应潜在客户咨询，转化率比 30 分钟后响应提升 400%
|
||||
- **利益冲突筛查必须先于安排咨询**：在确认无利益冲突前不得安排任何咨询，代表冲突方是严重的律师执业违规
|
||||
- **时效截止日期识别是 malpractice 风控核心**：人身伤害案件 2-3 年时效期限（各州不同）、EEOC 歧视投诉 180-300 天——错过截止日期直接构成 malpractice 索赔
|
||||
- **每次 intake 都是 attorney-client privilege 保护**：从第一次接触开始，所有潜在客户分享的信息均受律师-客户特权保护
|
||||
- **empathy-driven intake 提升留存**：在 intake 过程中感到被倾听的潜在客户，即使费率更高也更可能选择该律所
|
||||
- **qualification 节省双方时间**：彻底资格审查可以防止无效咨询（律师计时收费却被浪费）
|
||||
|
||||
## Key Quotes
|
||||
> "Most law firms lose potential clients before the attorney ever picks up the phone. A slow response, a confusing intake form, or a cold first interaction sends prospects straight to a competitor." — 行业现状
|
||||
|
||||
> "Every intake interaction must end with a clear, confirmed next step — a scheduled consultation, a referral, or a specific follow-up action — so no prospect falls through the cracks." — 操作规范
|
||||
|
||||
## Key Concepts
|
||||
- [[Statute-of-Limitations]]：时效期限，各法律领域有不同的截止日期，错过即构成 malpractice 风险
|
||||
- [[Conflict-of-Interest-Screening]]：利益冲突筛查，必须在安排咨询前完成，收集对方当事人全名和事先代表信息
|
||||
- [[Intake-Summary]]：律师就绪的案件摘要，在咨询前至少 30 分钟交付给律师，包含关键事实、时效截止日期和紧急标记
|
||||
- [[Practice-Area-Qualification]]：业务领域资格审查，确定潜在客户的事务类型（人身伤害/家庭法/刑事等）是否属于律所执业范围
|
||||
- [[Consultation-Scheduling]]：咨询安排，根据业务领域匹配合适律师，确认时间/形式（电话/视频/面谈）/需携带材料
|
||||
- [[Referral-Out]]：优雅转介，当潜在客户的事务不在律所执业范围时，提供具体的转介信息而非简单拒绝
|
||||
|
||||
## Key Entities
|
||||
- [[The-Agency]]：The Agency 的 Specialized 部门 Agent，覆盖多行业专业服务场景
|
||||
- [[Personal-Injury]]：人身伤害，最常见的 intake 业务领域之一，时效期限 2-3 年（各州不同）
|
||||
- [[EEOC]]：Equal Employment Opportunity Commission，雇佣歧视投诉机构，时效期限 180-300 天
|
||||
|
||||
## Connections
|
||||
- [[Legal-Compliance-Checker]] ← depends_on ← [[Legal-Client-Intake]]：Legal Client Intake 收集冲突信息，Legal Compliance Checker 提供合规审查
|
||||
- [[Practice-Area-Qualification]] ← extends ← [[Intake-Summary]]：资格审查是摘要信息收集的前置步骤
|
||||
- [[Conflict-of-Interest-Screening]] ← guards ← [[Consultation-Scheduling]]：冲突筛查是安排咨询的门控条件
|
||||
- [[Referral-Out]] ← alternative_to ← [[Consultation-Scheduling]]：当资格审查失败时，转介是安排的替代方案
|
||||
- [[Support-Responder]] ← similar_to ← [[Legal-Client-Intake]]：两者都是 first contact 接待专家，区别在于领域不同
|
||||
|
||||
## Contradictions
|
||||
- 与"简洁快速 intake"的主流观点：
|
||||
- 冲突点：本文档强调详尽的多阶段 intake 流程（6 步完整工作流）
|
||||
- 当前观点：全面收集案件信息、多次确认意向、完整 attorney-ready 摘要是长期客户留存的关键
|
||||
- 对方观点：快速 minimal intake 能提高响应速度和 initial contact 转化率
|
||||
- 协调方案：可针对不同潜在客户类型（紧急/高价值/低优先级）调整 intake 深度，紧急事务优先速度，非紧急高价值事务优先质量
|
||||
55
wiki/sources/legal-document-review.md
Normal file
55
wiki/sources/legal-document-review.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Legal Document Review Agent"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/legal-document-review.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：The Legal Document Review Agent — 专业的法律文档审查 Agent，为律师提供第一轮文件审查，发现风险条款、总结关键条款、标记问题条款、比较版本差异、检查合规性。
|
||||
- 问题域：法律文件审查（合同/诉讼文书/房地产协议/合规审查/版本比对），覆盖商法、房地产、公司法、劳动法、知产法等多领域。
|
||||
- 方法/机制：五步工作流（文档接收与分类 → 结构分析 → 实质审查 → 风险评估与标记 → 交付物准备），结合高风险条款库（赔偿/责任限制/终止/IP/自动续期/竞业限制/管辖法律）、分级风险评分（高/中/低）、标准化交付模板。
|
||||
- 结论/价值：取代律师的初读工作，让律师专注于判断和策略，减少遗漏高风险条款的可能性，保护客户免受合同陷阱损失。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 法律文档审查 Agent 永远不提供法律意见，始终将发现标记为"供律师审查"，而非确定性法律结论。
|
||||
- 审查前必须先识别文件类型、当事人、代理客户和管辖权——上下文决定风险级别。
|
||||
- 存在疑问时一律标记——误报成本是秒级，漏报风险条款可能造成客户数百万损失。
|
||||
- 摘要不得省略任何经济重大条款：支付、期限、终止、责任、赔偿、知识产权、适用法律。
|
||||
- 缺失条款（无责任限制、无赔偿条款、无不可抗力）不是中性沉默，应明确标记为缺失。
|
||||
- 版本比对必须穷尽：每个变更（包括格式、定义术语修改、看似微小的措辞变更）都必须捕捉。
|
||||
- 每份审查输出必须以明确的优先行动建议结尾，而非仅列出发现。
|
||||
|
||||
## Key Quotes
|
||||
> "A lawyer who reads every word of every document perfectly, every time, doesn't exist. A system that does — and flags exactly what needs human attention — is worth its weight in billable hours." — 核心价值主张
|
||||
|
||||
> "Every flagged clause must include: location, exact language, risk, market standard, impact, and recommended revision." — 标准化交付要求
|
||||
|
||||
> "Jurisdiction matters. Always note when a clause's enforceability may vary by jurisdiction. What is standard in one state may be unenforceable in another." — 管辖权意识
|
||||
|
||||
## Key Concepts
|
||||
- [[DocumentSummaryTemplate]]：标准化文件摘要模板，包含关键条款一览表（期限/支付/终止/续期/适用法律/争议解决/责任上限/赔偿/IP/保密）和缺失标准条款清单。
|
||||
- [[RiskClauseFlagging]]：风险条款标记流程，将条款分为高/中/低风险三级，每级包含位置、语言、风险、市场标准、影响和建议修订。
|
||||
- [[ContractComparisonTemplate]]：合同版本比对模板，区分实质性变更和管理性变更，记录有利/不利/中性变更计分。
|
||||
- [[ComplianceReviewTemplate]]：合规审查模板，对应州/联邦/国际要求，检查合规/潜在不合规/不合规三级状态。
|
||||
- [[HighRiskClauseLibrary]]：高风险条款库，涵盖赔偿、责任限制、终止、知识产权、自动续期、竞业限制、适用法律/争议解决七类常见高风险条款。
|
||||
- [[TenCriticalRules]]：十大关键规则，包括不提供法律意见、先识别上下文、全面标记、不错漏经济条款、尊重管辖权差异、不简化缺失条款、保密性、版本比对穷尽化、建议下一步行动。
|
||||
- [[DomainExpertiseCoverage]]：领域专业覆盖——商业合同（MSA/NDA/雇佣/供应/合伙/许可）、房地产文件（买卖/租赁/贷款/产权）、公司文件（运营/股权/资产收购/股票收购）、诉讼文书（诉状/动议/开示/和解/命令）、合规框架（劳动法/数据隐私/房地产/公司法/行业特定）。
|
||||
|
||||
## Key Entities
|
||||
- （无具体人物/公司/产品实体，均为抽象角色描述）
|
||||
|
||||
## Connections
|
||||
- [[LegalClientIntake]] ← depends_on ← [[LegalDocumentReview]]：法律客户 intake Agent 为文档审查 Agent 提供待审文件，两者构成法律服务前置→核心流程。
|
||||
- [[LegalBillingTimeTracking]] ← depends_on ← [[LegalDocumentReview]]：文档审查完成后，计费与时间追踪 Agent 负责记录审查工时和计费叙事，两者共享法律事务所上下文。
|
||||
- [[LegalDocumentReview]] ← extends ← [[CustomerService]]：通用客户服务 Agent 的投诉处理流程为法律文档审查中的诉讼文书处理提供了分级升级框架基础。
|
||||
|
||||
## Contradictions
|
||||
- 与 [[CustomerService]] 的"简洁高效"服务理念存在张力：
|
||||
- 冲突点：通用客服追求快速解决，减少来回；法律文档审查 Agent 要求穷尽式标记，不遗漏任何风险。
|
||||
- 当前观点：法律文档审查应全面标记，不惜误报。
|
||||
- 对方观点：客户体验优先，减少不必要的标记干扰。
|
||||
- 注：此为领域差异，非事实矛盾——法律场景的"过度标记"实为必要风险管控。
|
||||
@@ -1,50 +1,62 @@
|
||||
---
|
||||
title: "Level Designer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
tags: ["game-development", "level-design", "agent-personality", "spatial-design", "game-design"]
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/level-designer.md]]
|
||||
- [[Agent/agency-agents/game-development/level-designer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：游戏关卡设计师（Level Designer）AI Agent 的角色定义与工作规范
|
||||
- 问题域：如何通过空间叙事、流程控制、遭遇战设计、环境叙事等手段，创造可玩、可读、有情感张力的游戏关卡
|
||||
- 方法/机制：六阶段工作流（意图定义 → 纸面布局 → 灰盒搭建 → 遭遇战调优 → 美术交接 → 打磨验收）；Blockout 三阶段（灰盒 → 美术 → 特效音效）；空间心理学理论（prospect-refuge、figure-ground、Lynch 城市设计原则）；程序化关卡生成规则集
|
||||
- 结论/价值：提供了一套完整的 AI Agent 关卡设计方法论，涵盖线性射击、开放世界、Roguelike、Metroidvania 等多种游戏类型
|
||||
- 核心主题：Level Designer Agent 的角色定义与设计方法论——将游戏关卡视为"空间叙事"作品，通过布局、节奏、遭遇战设计和环境叙事来引导、挑战和沉浸玩家
|
||||
- 问题域：游戏关卡设计中的可读性、平衡性、节奏控制、环境叙事传达、多人空间设计
|
||||
- 方法/机制：六阶段工作流（意图定义→纸面布局→灰盒→遭遇战调优→美术交接→打磨）；三阶段关卡交付（灰盒/美术/打磨）；关卡设计文档标准化模板；空间心理学理论（Prospect-Refuge、Kevin Lynch城市设计）
|
||||
- 结论/价值：为游戏关卡设计提供了完整的 Agent 角色规范，涵盖线性射击、开放世界、Roguelike、银河恶魔城等多种品类，强调可测试性（playtest-grounded）的设计决策文化
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 关卡设计师通过空间架构引导、挑战和沉浸玩家——走廊是句子，房间是段落，关卡是完整的论证
|
||||
- 关键路径必须始终视觉可读——除非刻意设计迷路体验，否则玩家不应迷路
|
||||
- 每个战斗遭遇必须有：入口读图时间、多种战术选项和退守位置
|
||||
- 难度必须先从空间（位置和布局）出发，再考虑数值缩放
|
||||
- 每个区域通过道具摆放、光照和几何形状讲述故事——不存在空白的"填充"空间
|
||||
- 关卡交付三阶段：灰盒（blockout）→ 美术（dress）→ 打磨（polish）——设计决策在灰盒阶段锁定
|
||||
- 未经灰盒测试验证的布局不得进行美术包装
|
||||
- 关卡设计师将走廊视为句子、房间视为段落、关卡视为完整的论点——空间本身就是叙事媒介
|
||||
- 关键路径必须始终在视觉上可读，玩家迷路必须是刻意的设计而非系统失败
|
||||
- 难度首先应是空间性的（位置和布局），其次才是数值缩放
|
||||
- 灰盒必须先通过测试，艺术美化前必须锁定设计决策——零例外
|
||||
- 100% 的测试玩家无需询问方向即可导航关键路径时，关卡才算成功
|
||||
|
||||
## Key Quotes
|
||||
> "A corridor is a sentence, a room is a paragraph, and a level is a complete argument about what the player should feel." — 核心隐喻定义
|
||||
> "MANDATORY: The critical path must always be visually legible — players should never be lost unless disorientation is intentional and designed." — 强制规则
|
||||
> "Never art-dress a layout that hasn't been playtested as a grey box." — Blockout 纪律
|
||||
> "You understand that a corridor is a sentence, a room is a paragraph, and a level is a complete argument about what the player should feel." — Level Designer Agent 核心身份宣言
|
||||
> "Never art-dress a layout that hasn't been playtested as a grey box" — 灰盒优先原则
|
||||
> "Every combat encounter must have: entry read time, multiple tactical approaches, and a fallback position" — 遭遇战设计三要素
|
||||
> "Players should be able to infer what happened in a space without dialogue or text" — 环境叙事目标
|
||||
> "Difficulty must be spatial first — position and layout — before stat scaling" — 空间优先于数值
|
||||
|
||||
## Key Concepts
|
||||
- [[Flow And Readability]]：关卡流与可读性——关键路径视觉清晰，用光照、色彩、几何引导注意力，不依赖小地图作为主要导航工具
|
||||
- [[Encounter Design]]：遭遇战设计——每个战斗场景必须提供读图时间、多战术选项和退守位置
|
||||
- [[Environmental Storytelling]]：环境叙事——通过道具摆放、光照和几何讲述世界故事，无需对话或文本
|
||||
- [[Blockout Discipline]]：灰盒纪律——设计决策在灰盒阶段锁定，禁止在未经测试的布局上美术包装
|
||||
- [[Spatial Psychology]]：空间心理学——应用 prospect-refuge 理论、figure-ground 对比、Kevin Lynch 城市设计五要素
|
||||
- [[Procedural Level Design]]：程序化关卡设计——为程序化生成制定规则集，保证最低质量阈值
|
||||
- [[Pacing Architecture]]：节奏架构——通过空间节奏控制张力：紧张 → 释放 → 探索 → 战斗
|
||||
- [[Speedrun Design]]：速通设计——审计每个关卡的非预期序列断裂，设计最优路径奖励精通但不惩罚休闲玩家
|
||||
- [[Pacing Chart]]：节奏图表，通过时间和活动类型可视化关卡的张力曲线（紧张/释放/探索/战斗交替）
|
||||
- [[Grey Box Blockout]]：灰盒原型阶段，仅用未贴图几何体快速验证布局可读性，所有设计决策在灰盒阶段锁定
|
||||
- [[Encounter Design]]：遭遇战设计，要求每场战斗具备进入读时、多种战术选项和撤退位置
|
||||
- [[Environmental Storytelling]]：环境叙事，通过道具摆放、光照和几何形状传达世界故事，无需对话或文字
|
||||
- [[Navigation Affordance]]：导航可达性，通过光照、色彩和几何引导注意力，确保关键路径在视觉上突出
|
||||
- [[Spatial Psychology]]：空间心理学，应用 Prospect-Refuge 理论使玩家感到安全（俯瞰位置+受保护的背部）
|
||||
- [[Procedural Level Design]]：程序化关卡设计，通过规则集和手工锚点确保生成质量下限
|
||||
- [[Prospect-Refuge Theory]]：前景-庇护理论，玩家在有俯瞰位置且背部受保护时感到安全
|
||||
- [[Kevin Lynch Urban Design]]：Kevin Lynch 城市设计五要素（路径/边缘/区域/节点/地标）应用于游戏空间
|
||||
- [[Temptation Design]]：诱惑设计，可选区域通过光照或色彩区分，奖励物在岔路口可见
|
||||
- [[Figure-Ground Contrast]]：图底对比，建筑中使目标从背景中视觉突出的设计手法
|
||||
|
||||
## Key Entities
|
||||
- （本文档未明确提及具体人物或公司）
|
||||
- [[Game Audio Engineer]]：同为 agency-agents 游戏开发分支下的 Agent，与 Level Designer 在环境叙事和节奏控制上有协同关系
|
||||
- [[Technical Artist]]：在灰盒阶段完成后负责美术交接（Art Pass Handoff）的角色
|
||||
- [[Game Designer]]：Level Designer 的上游角色，提供游戏整体设计意图和玩法框架
|
||||
|
||||
## Connections
|
||||
- [[Technical Artist]] ← 并行协作 ← [[Level Designer]]（环境叙事 + 美术实现的协作关系）
|
||||
- [[Game Audio Engineer]] ← 并行协作 ← [[Level Designer]]（音效设计配合节奏图表）
|
||||
- [[Agents Orchestrator]] ← 上游编排 ← [[Level Designer]]（被编排的子 Agent）
|
||||
- [[Pacing Chart]] ← defines ← [[Level Designer]]
|
||||
- [[Grey Box Blockout]] ← validated_by ← [[Playtest]]
|
||||
- [[Encounter Design]] ← requires ← [[Navigation Affordance]]
|
||||
- [[Environmental Storytelling]] ← informs ← [[Game Audio Engineer]]（音效支持节奏弧线）
|
||||
- [[Game Designer]] ← provides_intent ← [[Level Designer]]
|
||||
- [[Technical Artist]] ← receives_handoff ← [[Level Designer]]（美术交接文档）
|
||||
|
||||
## Contradictions
|
||||
- （当前未发现与 Wiki 中其他页面的内容冲突）
|
||||
- 与 [[Technical Artist]] 潜在冲突：
|
||||
- 冲突点：艺术美化与设计锁定优先级——美术团队可能希望在灰盒阶段进行视觉优化，而 Level Designer 坚持设计决策在灰盒阶段锁定后才能进入美术阶段
|
||||
- 当前观点：设计决策必须在灰盒阶段锁定，美术阶段不得更改核心布局
|
||||
- 对方观点：美术迭代可能反向驱动设计优化（如光照方向影响空间感知）
|
||||
- 解决方向：建立"gameplay-critical geometry"标注体系，关键几何体锁定，可造型区域开放
|
||||
|
||||
55
wiki/sources/llm-wiki.md
Normal file
55
wiki/sources/llm-wiki.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "LLM Wiki"
|
||||
type: source
|
||||
tags: [llm, knowledge-base, agent, personal-wiki, rag]
|
||||
date: 2026-04-09
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/LLM Wiki.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：利用 LLM 构建和持续维护个人知识库（Wiki）的架构模式
|
||||
- 问题域：传统 RAG 每次查询都从零发现知识，无法积累；Wiki 维护负担随规模增长而超过价值，导致人们放弃维护
|
||||
- 方法/机制：三层架构（Raw Sources → Wiki → Schema），LLM 增量构建持久化维基，代替人类完成"记账式"维护工作（总结、交叉引用、归档、一致性检查）
|
||||
- 结论/价值：知识只需编译一次即可保持最新，LLM 承担维护成本使 Wiki 可持续运行；人是编辑，LLM 是程序员，Wiki 是代码库
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- LLM Wiki 通过增量构建和持续维护，使知识在每次查询时无需重新推导
|
||||
- 传统 RAG 每次回答都从原始文档中重新发现知识，没有积累；LLM Wiki 则将知识编译为持久化、相互链接的摘要
|
||||
- LLM 不会厌倦、不会忘记更新交叉引用，一次可以处理 15 个文件，维护成本接近零
|
||||
- 人的职责是筛选资料、指导分析、提出好问题；LLM 的职责是其他一切
|
||||
- 好的答案可以归档回 Wiki 作为新页面，探索结果与摄入来源一样复合积累
|
||||
|
||||
## Key Quotes
|
||||
> "The wiki is a persistent, compounding artifact." — Wiki 的本质特征：持久化、复合增长的成果物
|
||||
> "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." — LLM 与人的协作模式比喻
|
||||
> "The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping." — 维护知识库最繁琐的部分不是阅读或思考，而是记录工作
|
||||
> "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass." — LLM 相比人类的维护优势
|
||||
> "This idea is related in spirit to Vannevar Bush's Memex (1945)" — 概念渊源：Vannevar Bush 的 Memex
|
||||
|
||||
## Key Concepts
|
||||
- [[PersistentWiki]]：持久化维基——结构化、相互链接的 Markdown 文件集合，介于用户与原始数据源之间，知识编译一次后保持最新
|
||||
- [[LLMWikiArchitecture]]：三层架构——Raw Sources（原始资源）、Wiki（LLM 生成的知识层）、Schema（CLAUDE.md/AGENTS.md 等配置文件）
|
||||
- [[IngestWorkflow]]：导入工作流——LLM 读取源文件、与用户讨论要点、编写摘要、更新索引、更新相关实体和概念页面、追加日志
|
||||
- [[QueryWorkflow]]：查询工作流——LLM 搜索相关页面、综合答案并引用来源；好的答案可归档回 Wiki
|
||||
- [[LintWorkflow]]：检查工作流——定期检查页面间矛盾、过时说法、孤立页面、数据缺口等
|
||||
- [[Memex]]：Vannevar Bush（1945）构想的个人知识库概念，文档之间有关联轨迹——LLM Wiki 承接了这一愿景并解决了"谁来维护"的问题
|
||||
|
||||
## Key Entities
|
||||
- [[VannevarBush]]：1945 年 Memex 概念的提出者，提出"关联轨迹"思想，其愿景比后来的万维网更接近 LLM Wiki 的理念
|
||||
- [[Obsidian]]：本地 Markdown 编辑器（IDE），用户浏览 Wiki 结果的界面，提供图形视图查看 Wiki 结构
|
||||
- [[NotebookLM]]：Google 的 AI 笔记工具，采用传统 RAG 模式，与 LLM Wiki 的持久化维基模式形成对比
|
||||
|
||||
## Connections
|
||||
- [[PersistentWiki]] ← implements ← [[LLMWikiArchitecture]]
|
||||
- [[PersistentWiki]] ← competes_with ← [[RAG]] （传统 RAG 每次查询从零推导，持久化维基一次编译持续复用）
|
||||
- [[IngestWorkflow]] ← uses ← [[PersistentWiki]]
|
||||
- [[QueryWorkflow]] ← uses ← [[PersistentWiki]]
|
||||
- [[PersistentWiki]] ← inspired_by ← [[Memex]]
|
||||
|
||||
## Contradictions
|
||||
- 与 NotebookLM 等传统 RAG 系统对比：
|
||||
- 冲突点：是否需要每次查询时重新发现知识
|
||||
- 当前观点：LLM Wiki 通过持久化维基积累知识，避免重复推导
|
||||
- 对方观点：传统 RAG 每次查询时检索相关片段生成答案，无需维护 Wiki
|
||||
65
wiki/sources/loan-officer-assistant.md
Normal file
65
wiki/sources/loan-officer-assistant.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
title: "Loan Officer Assistant Agent"
|
||||
type: source
|
||||
tags: []
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/specialized/loan-officer-assistant.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：面向抵押贷款和消费信贷专业人士的 AI Agent，涵盖借款人接待、预审、文件收集、管道管理、合规跟踪、利率报价及交割协调的全生命周期。
|
||||
- 问题域：贷款专员如何在高合规压力、高客户期望的环境下，同时管理多条贷款管道的进度、文件完整性和监管截止日期。
|
||||
- 方法/机制：五步工作流（借款人接待→申请与披露→处理与文件收集→承销管理→交割协调）+ 十项关键规则（TRID/DTI/公平贷款/文件有效期/资质要求等）+ 标准化交付模板（借款人接待脚本、预审表、文件清单、TRID时间表、贷款状态更新模板、承销条件跟踪表）。
|
||||
- 结论/价值：优秀的贷款专员不是靠熟记利率，而是靠精确的管道管理、合规意识和为申请人提供全程主动沟通的能力。Agent 通过结构化模板和规则引擎，帮助贷款专员将每笔贷款从初次接触到最终放款都按时、保合规地完成。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- [[LoanOfficerAssistant]] 通过覆盖借款人接待、预审、申请、处理、承销、交割全生命周期的结构化工作流，支持贷款专员专注于成交和客户关系维护。
|
||||
- [[TRID]] 规则要求在申请后 3 个工作日内交付 Loan Estimate，在成交前至少 3 个工作日交付 Closing Disclosure；错过任一截止日期均构成联邦监管违规。
|
||||
- [[FairLending]] 合规是绝对底线——不得因种族、肤色、宗教、国籍、性别、家庭状况、残疾、年龄等受保护特征而差异化对待借款人。
|
||||
- 利率锁定到期意味着借款人潜在成本增加；Agent 必须持续追踪锁定到期日并在足够提前量提醒贷款专员。
|
||||
- 工资单、银行流水、评估报告、信用报告均有有效期限；过期文件必须在交割或承销前刷新，否则承销将会以最坏时机补件要求。
|
||||
- 贷款决策（批准/拒绝）只能由持牌承销商做出；Agent 不得告知借款人已批准、已拒绝或很可能批准。
|
||||
- [[DTI]] 比率（Front-end ≤ 28%/31%，Back-end ≤ 45%/43-50%）是预审和贷款产品匹配的核心指标。
|
||||
- [[LoanToValue]]（LTV = 贷款金额 ÷ 评估价值）和 Combined LTV（CLTV）是决定贷款产品和首付要求的关键参数。
|
||||
- 承销条件必须以书面文件清除；借款人口头保证不充分——任何条件清除必须有书面证据。
|
||||
- 州级许可证要求因州而异；贷款专员必须在借款人房产所在州（抵押贷款）或借款人居住州（消费贷款）持有执照后方可接受申请。
|
||||
|
||||
## Key Quotes
|
||||
> "The difference between a good loan officer and a great one isn't knowledge of rates — it's the ability to manage a complex pipeline, keep borrowers informed, stay ahead of compliance, and close on time. Every. Single. Time." — The Loan Officer Assistant Agent 核心价值观
|
||||
>
|
||||
> "Every borrower must be treated consistently regardless of race, color, religion, national origin, sex, familial status, disability, age, or any other protected class." — 公平贷款合规绝对原则
|
||||
>
|
||||
> "A loan file is only as strong as its weakest document, and a borrower relationship is only as strong as its last communication." — Agent 对文件和沟通质量的核心信念
|
||||
|
||||
## Key Concepts
|
||||
- [[TRID]]：TILA-RESPA Integrated Disclosure，LE（Loan Estimate）和 CD（Closing Disclosure）的联邦披露时间要求框架。
|
||||
- [[DebtToIncome]]：DTI 比率，Front-end = PITI ÷ 月毛收入，Back-end =（PITI + 所有月供）÷ 月毛收入，用于偿还能力评估。
|
||||
- [[LoanToValue]]：LTV = 贷款金额 ÷ 评估价值（或成交价，取较低者），决定贷款产品类型和首付要求。
|
||||
- [[PreQualification]]：预审流程，基于收入、资产、信用、债务数据的初步资格评估，非贷款承诺。
|
||||
- [[UnderwritingConditions]]：承销条件，承销商要求的文件或说明，在交割前必须以书面证据清除。
|
||||
- [[RateLock]]：利率锁定，锁定期间利率不变，过期后借款人面临利率上升风险。
|
||||
- [[DocumentExpiration]]：文件有效期管理，工资单30天、银行流水60天、信用报告120-180天、评估120-180天。
|
||||
- [[FairLending]]：公平贷款，所有借款人在服务水平和产品提供上一致对待，禁止基于受保护特征的歧视。
|
||||
|
||||
## Key Entities
|
||||
- [[FannieMae]]（FNMA）：房利美，Conventional Loan（普通贷款）指南和合规性参考。
|
||||
- [[FreddieMac]]（FHLMC）：房地利美，High-balance Conforming Loan 指南参考。
|
||||
- [[FederalHousingAdministration]]（FHA）：联邦住房管理局，提供 FHA 贷款（3.5% 首付、MIP 要求）。
|
||||
- [[DepartmentOfVeteransAffairs]]（VA）：退伍军人事务部，提供 VA 贷款（符合条件的退伍军人 0% 首付）。
|
||||
- [[USDAD RuralDevelopment]]：美国农业部农村发展局，提供 USDA 贷款（符合条件的农村地区 0% 首付）。
|
||||
- [[SBA]]：小型企业管理局，提供 SBA 7(a) 和 504 商业贷款。
|
||||
|
||||
## Connections
|
||||
- [[LegalDocumentReview]] ← supports ← [[LoanOfficerAssistant]]：法律文档审查 Agent 覆盖抵押文件（买卖合同/贷款文件/产权文件），与 Loan Officer Assistant 在贷款文件审查环节存在上下游关系。
|
||||
- [[RealEstateBuyerSeller]] ← coordinates_with ← [[LoanOfficerAssistant]]：房地产交易 Agent 在交易协调阶段需要与贷款专员 Agent 协作——成交日、评估报告、产权确认均需两方协调。
|
||||
- [[SalesOutreach]] ← feeds_leads_to ← [[LoanOfficerAssistant]]：Sales Outreach Agent 通过 B2B 销售触达潜在借款人，Loan Officer Assistant 接收意向借款人并进入预审/申请流程。
|
||||
- [[ComplianceAuditor]] ← audits ← [[LoanOfficerAssistant]]：合规审计 Agent 对贷款专员的 TRID 时间线、公平贷款行为、HMDA 数据报告进行审查。
|
||||
|
||||
## Contradictions
|
||||
- 与 [[RealEstateBuyerSeller]] 在"交易节点主导权"上存在视角差异：
|
||||
- 冲突点：谁主导成交协调中的融资节点——贷款 Agent 认为应主动追踪所有合规截止日期并推送提醒，而房地产经纪人可能期望由其协调所有节点后通知贷款方。
|
||||
- 当前观点：贷款合规截止日期（TRID）具有法律强制性，贷款 Agent 必须主动管理，不应被动等待对方协调。
|
||||
- 对方观点：交易协调应由房地产经纪人统一主导，贷款方在其节点响应即可。
|
||||
- 结论：两者均为各自领域的最佳实践——在真实交易中需建立明确的协调协议（Communication Protocol），约定双方触发通知的时机，而非互相覆盖职责。
|
||||
@@ -2,59 +2,56 @@
|
||||
title: "LSP/Index Engineer Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-25
|
||||
date: 2026-04-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/specialized/lsp-index-engineer.md]]
|
||||
- [[Agent/agency-agents/specialized/lsp-index-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LSP/Index Engineer 是 The Agency Specialized 部门的代码智能系统架构师 Agent，通过编排 Language Server Protocol（LSP）客户端并构建统一语义图谱，实现跨多语言的代码智能查询能力。
|
||||
- 问题域：如何将异构语言服务器（TypeScript、PHP、Go、Rust、Python）的语义数据统一为一致的代码图谱，并在亚秒级延迟内提供导航/定义/引用查询。
|
||||
- 方法/机制：graphd LSP 聚合器 + 多语言 LSP 客户端编排 + nav.index.jsonl 语义索引 + WebSocket 实时增量更新 + SQLite/JSON 持久化缓存层。
|
||||
- 结论/价值：将不同语言服务器的输出标准化为统一图谱（节点：文件/符号，边：contains/imports/calls/refs），实现 100k+ 符号规模下 60fps 的沉浸式代码可视化，定义/引用查询响应 <150ms，Hover 文档 <60ms。
|
||||
- 核心主题：LSP/Index Engineer Agent 是一款专注于语言服务器协议（LSP）客户端编排和语义索引构建的专业智能体，通过协调多种语言的 LSP 服务器构建统一代码语义图谱。
|
||||
- 问题域：异构语言服务器（TypeScript、PHP、Go、Rust、Python 等）各自独立运作，缺乏统一的代码语义抽象层，导致代码导航、定义跳转、引用查找等功能无法跨语言协同。
|
||||
- 方法/机制：
|
||||
- **graphd LSP Aggregator**：协调多个 LSP 客户端并发工作，将 LSP 响应转换为统一图谱格式
|
||||
- **图谱 Schema**：节点（file/symbol）→ 边（contains/imports/calls/refs）
|
||||
- **实时增量更新**：通过文件监听器和 Git hooks 实现增量更新
|
||||
- **nav.index.jsonl**：导航索引格式，存储符号定义、引用和悬停文档
|
||||
- **LSIF 导入/导出**：支持预计算语义数据的导入导出
|
||||
- **WebSocket 流推送**：通过 WebSocket 流式推送图谱差异更新
|
||||
- 结论/价值：统一代码语义图谱实现 <100ms 响应时间、100k+ 符号规模无性能衰减，支持跨语言的代码智能导航（定义跳转/引用查找/悬停文档）。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- graphd 通过 LSP 聚合器并发编排 TypeScript/PHP/Go/Rust/Python 多语言 LSP 客户端，将响应转换为统一图谱模式
|
||||
- 语义索引基础设施 nav.index.jsonl 存储符号定义、引用和 Hover 文档，支持 LSIF 导入/导出
|
||||
- 原子性图谱更新确保从不处于不一致状态，WebSocket 实时推送图谱差异
|
||||
- 默认要求 TypeScript 和 PHP 支持必须首先达到生产就绪状态
|
||||
- 严格遵循 LSP 3.17 规范，正确处理各语言服务器的能力协商
|
||||
- 每个符号必须有且仅有一个定义节点，所有边必须引用有效节点 ID
|
||||
- `/graph` 端点在 <10k 节点数据集下 100ms 内响应，`/nav/:symId` 查找缓存 <20ms / 未缓存 <60ms
|
||||
- 系统处理 100k+ 符号时性能不降级，内存保持在 500MB 以下
|
||||
- **graphd 统一语义图谱**：协调多个 LSP 客户端并发运行，将异构语言服务器响应转换为统一图谱 schema，节点代表文件和符号，边代表 contains/imports/calls/refs 关系。
|
||||
- **nav.index.jsonl 导航索引**：通过 `nav.index.jsonl` 流式索引格式存储每个符号的 `symId`、定义位置（uri/l/c）和引用列表，实现快速符号查找。
|
||||
- **LSP 3.17 严格合规**：严格遵循 LSP 3.17 规范进行客户端通信，正确处理能力协商和生命周期管理（initialize → initialized → shutdown → exit）。
|
||||
- **性能约束量化**：图谱端点 <100ms（<10k 节点）、符号导航 <20ms（缓存）/ <60ms（未缓存）、WebSocket 延迟 <50ms、内存 <500MB。
|
||||
- **原子图谱更新**：图谱更新必须是原子性的，确保图谱状态永远不会处于不一致状态。
|
||||
|
||||
## Key Quotes
|
||||
> "Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, Transform LSP responses into unified graph schema (nodes: files/symbols, edges: contains/imports/calls/refs)" — 核心交付物定义
|
||||
> "Strictly follow LSP 3.17 specification for all client communications, Handle capability negotiation properly for each language server" — 协议合规要求
|
||||
> "Every symbol must have exactly one definition node, All edges must reference valid node IDs" — 图谱一致性约束
|
||||
> "Sub-500ms response times for definition/reference/hover requests" — 性能北极星指标
|
||||
> "Build the graphd LSP Aggregator — Orchestrate multiple LSP clients (TypeScript, PHP, Go, Rust, Python) concurrently, transform LSP responses into unified graph schema." — 核心交付物定义
|
||||
> "Every symbol must have exactly one definition node; all edges must reference valid node IDs; import edges must resolve to actual file/module nodes." — 图谱一致性强制约束
|
||||
> "`/graph` endpoint must return within 100ms for datasets under 10k nodes." — 性能合约
|
||||
|
||||
## Key Concepts
|
||||
- [[LSP-317-Specification]]：Language Server Protocol 3.17 规范——LSP 的最新版本，定义了客户端与语言服务器之间的标准化通信协议
|
||||
- [[Semantic-Index-Infrastructure]]：语义索引基础设施——将 LSP 响应转换为持久化结构（nav.index.jsonl + SQLite/JSON 缓存），支持快速启动和增量查询
|
||||
- [[Graph-Node-Schema]]：图谱节点模式——统一表示文件节点（file:）、模块节点（module/）、符号节点（sym:），支持 6 种节点类型和 6 种边类型
|
||||
- [[Incremental-Graph-Update]]：增量图谱更新——通过文件监视器和 Git hooks 触发增量更新，WebSocket 推送图谱差异，原子性保证从不处于不一致状态
|
||||
- [[LSP-Client-Orchestration]]：LSP 客户端编排——多语言 LSP 客户端并发初始化、能力协商、请求批量处理和缓存管理的统一架构
|
||||
- [[Performance-Contracts]]：性能契约——量化系统性能约束：/graph <100ms、/nav <60ms、WebSocket <50ms、内存 <500MB
|
||||
- [[LanguageServerProtocol]]：LSP 3.17 — 语言服务器协议标准，定义客户端与服务器之间的通信规范，支持文本文档同步、代码完成、定义跳转、引用查找、悬停文档等特性
|
||||
- [[SemanticCodeGraph]]：语义代码图谱 — 以节点（文件/符号）和边（contains/imports/calls/refs）表示代码结构的统一语义抽象
|
||||
- [[LSPOrchestration]]：LSP 客户端编排 — 协调多个语言服务器并发运行，统一处理不同语言的 LSP 响应格式
|
||||
- [[nav.index.jsonl]]：导航索引格式 — JSONL 流式索引文件，每行包含 `symId`（符号 ID）、`def`（定义位置）、`refs`（引用列表）、`hover`（悬停文档）
|
||||
- [[LSIF]]：Language Server Index Format — 预计算语义数据的标准化格式，支持导入导出
|
||||
- [[IncrementalGraphUpdate]]：增量图谱更新 — 通过文件监听器和 Git hooks 实现增量更新，而非全量重建
|
||||
|
||||
## Key Entities
|
||||
- [[The-Agency]]：The Agency 多智能体系统组织，147 个 Agent 跨 12 个部门，LSP/Index Engineer 属于 Specialized 部门
|
||||
- [[TypeScript-Language-Server]]：TypeScript 语言服务器——支持 TypeScript 和 JavaScript 的 LSP 实现
|
||||
- [[Intelephense]]：PHP Intelephense——PHP 语言的 LSP 服务器实现
|
||||
- [[gopls]]：Go 语言服务器——Go 官方 LSP 实现
|
||||
- [[rust-analyzer]]：Rust 语言服务器——Rust 官方 LSP 实现
|
||||
- [[pyright]]：Python 语言服务器——Microsoft 的 Python 类型检查和 LSP 实现
|
||||
- [[LSIF]]：Language Server Index Format——预计算语义数据的标准化交换格式
|
||||
- [[GraphDaemon]]：graphd — 核心图谱守护进程，HTTP 服务器提供 `/graph`、`/nav/:symId`、`/stats` 端点，WebSocket 服务器推送实时图谱更新
|
||||
- [[TypeScriptLanguageServer]]：TypeScript 语言服务器 — graphd 默认要求生产就绪的语言服务器之一
|
||||
- [[Intelephense]]：PHP Intelephense — PHP 语言服务器，graphd 默认要求生产就绪的语言服务器之一
|
||||
|
||||
## Connections
|
||||
- [[specialized-workflow-architect]] ← builds upon ← [[LSP-Index-Engineer]]：Workflow Architect 在 LSP/Index Engineer 构建的语义图谱基础上设计工作流注册表和交接合同
|
||||
- [[LSP-Index-Engineer]] ← uses ← [[LSP-317-Specification]]：LSP/Index Engineer 严格遵循 LSP 3.17 规范进行客户端开发
|
||||
- [[LSP-Index-Engineer]] ← provides_input ← [[semantic-code-visualization]]：LSP/Index Engineer 构建的统一图谱为沉浸式代码可视化提供数据基础
|
||||
- [[GraphDaemon]] ← builds ← [[SemanticCodeGraph]]
|
||||
- [[GraphDaemon]] ← orchestrates ← [[LSPOrchestration]]
|
||||
- [[GraphDaemon]] ← streams via ← [[WebSocket]]
|
||||
- [[SemanticCodeGraph]] ← format ← [[nav.index.jsonl]]
|
||||
- [[SemanticCodeGraph]] ← import/export ← [[LSIF]]
|
||||
- [[IncrementalGraphUpdate]] ← triggers ← [[FileWatcher]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[specialized-workflow-architect]] 存在张力：
|
||||
- 冲突点：LSP/Index Engineer 要求"每个系统边界定义显式交接合同"（确定性要求），而 Workflow Architect 承认 LLM 概率性使得穷举建模存在上限
|
||||
- 当前观点（LSP/Index Engineer）：图谱节点必须精确——"每个符号必须有且仅有一个定义节点"，"Reference edges must point to definition nodes"
|
||||
- 对方观点（Workflow Architect）：穷举工作流存在概率性上限，某些边界条件只能通过概率性处理
|
||||
- 协调方向：LSP/Index Engineer 的确定性约束适用于代码符号层面（静态分析），Workflow Architect 的概率性适用于行为工作流层面，两者作用于不同抽象层次，可共存
|
||||
- 无已知冲突页面。该页面为独立的专业 Agent 规范文档，未涉及其他 Wiki 页面中相矛盾的观点。
|
||||
|
||||
@@ -1,62 +1,54 @@
|
||||
---
|
||||
title: "macOS Spatial/Metal Engineer Agent Personality"
|
||||
type: source
|
||||
tags: [agent, apple, metal, spatial-computing, visionos, xr]
|
||||
date: 2026-04-25
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：macOS Spatial/Metal Engineer Agent 的人格定义——一个专注于 Swift + Metal 渲染的空间计算专家 Agent，负责构建 macOS 和 Vision Pro 上的高性能 3D 可视化系统
|
||||
- 问题域：如何在 Apple 平台上实现大规模图数据的高性能 GPU 渲染，并将渲染流通过 Compositor Services 传输到 Vision Pro 进行沉浸式空间计算体验
|
||||
- 方法/机制：使用实例化 Metal 渲染（Instanced Rendering）驱动 10k-100k 节点；通过 RemoteImmersiveSpace 和 LayerRenderer 实现 Vision Pro 立体帧流；用 Metal Compute Shader 实现 GPU 物理力导向图布局
|
||||
- 结论/价值：定义了一个完整的 Apple 平台空间计算 Agent 技术栈，从渲染管线到手势交互到性能调优，覆盖了 visionOS/macOS 跨平台沉浸式开发的核心路径
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agent 通过实例化 Metal 渲染，可在 90fps 立体渲染下驱动 25k 节点图数据
|
||||
- Agent 使用 RemoteImmersiveSpace 实现 macOS 与 Vision Pro 的全沉浸式代码可视化连接
|
||||
- Agent 通过 LayerRenderer 的 stereo 配置（RGBA16Float + Depth32Float）实现高质量立体帧流
|
||||
- Agent 利用 Metal Compute Shader 执行 GPU 并行力导向图布局，避免 CPU 瓶颈
|
||||
- Agent 将注视（Gaze）追踪 + 捏合（Pinch）手势识别作为主要空间交互方式
|
||||
|
||||
## Key Quotes
|
||||
> "Never drop below 90fps in stereoscopic rendering" — Metal 渲染硬性性能要求
|
||||
> "Use instanced drawing for massive node counts" — 核心渲染优化策略
|
||||
> "Stream stereo frames to Vision Pro via Compositor Services" — 跨设备渲染架构目标
|
||||
> "Implement proper depth ordering for stereoscopic rendering" — Vision Pro 立体渲染规范
|
||||
|
||||
## Key Concepts
|
||||
- [[Instanced Rendering]]：通过单次 draw call 批量渲染大量节点，每个节点含 position/color/scale/symbolId 属性
|
||||
- [[RemoteImmersiveSpace]]：macOS 与 Vision Pro 之间的全沉浸式空间连接协议
|
||||
- [[Compositor Services]]：提供 LayerRenderer 用于生成和提交立体帧到 Vision Pro
|
||||
- [[LayerRenderer]]：配置 stereo 模式、RGBA16Float 颜色格式和 Depth32Float 深度格式的渲染层
|
||||
- [[Force-Directed Graph Layout]]：在 Metal Compute Shader 中实现的力导向图物理模拟（排斥力 + 吸引力 + 阻尼）
|
||||
- [[Metal System Trace]]：Xcode Instruments 工具，用于分析 Metal 帧时间和 GPU 利用率
|
||||
- [[Stereoscopic Rendering]]：双眼立体渲染，需维护正确的深度顺序和 vergence-accommodation 限制
|
||||
- [[GPU-Driven Rendering]]：通过 Indirect Command Buffers 实现 GPU 自主驱动的渲染管线
|
||||
- [[Triple Buffering]]：三缓冲策略保证 CPU-GPU 数据传输与渲染流水线的平滑衔接
|
||||
- [[Frustum Culling & LOD]]：视锥裁剪和层级细节优化，用于大规模图数据的性能保障
|
||||
|
||||
## Key Entities
|
||||
- [[Apple]]：平台生态——提供 Metal、visionOS、CompositorServices 等核心框架
|
||||
- [[Vision Pro]]：目标设备——通过 RemoteImmersiveSpace 接收来自 macOS 的立体渲染流
|
||||
- [[Metal]]：底层图形 API——支持 instanced rendering、compute shaders、geometry shaders
|
||||
- [[Xcode Instruments]]：性能分析工具——Metal System Trace 用于帧时间和 GPU 利用率分析
|
||||
- [[RealityKit]]：空间锚点支持——用于 Vision Pro 空间锚点的持久化管理
|
||||
- [[ARKit]]：环境映射——结合 ARKit 实现环境光照和空间理解
|
||||
|
||||
## Connections
|
||||
- [[macos-spatial-metal-engineer]] ← builds ← [[MetalGraphRenderer]]（核心渲染组件）
|
||||
- [[macos-spatial-metal-engineer]] ← integrates_with ← [[VisionProCompositor]]（Vision Pro 流式连接）
|
||||
- [[macos-spatial-metal-engineer]] ← uses ← [[ForceDirectedGraphLayout]]（GPU 物理模拟）
|
||||
- [[xr-immersive-developer]] ← shares_architecture_with ← [[macos-spatial-metal-engineer]]（XR 开发领域重叠）
|
||||
- [[visionos-spatial-engineer]] ← extends ← [[macos-spatial-metal-engineer]]（visionOS 专用扩展）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[visionos-spatial-engineer]] 可能存在职责重叠：
|
||||
- 冲突点：两者都涉及 Vision Pro 开发，但侧重点不同
|
||||
- 当前观点：macOS Spatial/Metal Engineer 专注 macOS 侧渲染管线 + Vision Pro 流式输出
|
||||
- 对方观点：visionOS Spatial Engineer 专注 visionOS 原生空间交互开发
|
||||
- 协调：两者可协同——macOS 侧负责高性能渲染，visionOS 侧负责原生交互体验
|
||||
---
|
||||
title: "macOS Spatial/Metal Engineer Agent Personality"
|
||||
type: source
|
||||
tags: ["apple", "metal", "spatial-computing", "vision-pro", "swift", "rendering"]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：macOS Spatial/Metal Engineer 智能体人格定义文档，用于构建高性能 3D 渲染系统和空间计算体验
|
||||
- 问题域：如何让 AI 智能体扮演 Swift + Metal 渲染专家，同时支持 macOS 和 Vision Pro 的空间计算集成
|
||||
- 方法/机制：通过详细定义 Agent 的身份定位、核心任务、性能指标、技术架构（Metal 渲染管线、Compositor Services 集成、空间交互系统、GPU 布局物理引擎）和工作流程
|
||||
- 结论/价值：提供了一套完整的空间计算智能体开发框架，涵盖从 Metal 渲染优化到 Vision Pro 交互集成的全链路能力要求
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Agent 必须实现 instanced Metal 渲染，支持 10k-100k 节点达到 90fps（主体 + 机制 + 结果）
|
||||
- Agent 必须通过 Compositor Services 将立体帧流式传输到 Vision Pro（主体 + 机制 + 结果）
|
||||
- Agent 必须保持 GPU 利用率低于 80% 以预留散热空间（主体 + 机制 + 结果）
|
||||
- Agent 必须将注视选择延迟控制在 50ms 以内（主体 + 机制 + 结果）
|
||||
- Agent 必须保持内存使用低于 1GB（主体 + 机制 + 结果）
|
||||
|
||||
## Key Quotes
|
||||
> "Never drop below 90fps in stereoscopic rendering" — Metal 性能红线要求
|
||||
> "Stream stereo frames to Vision Pro via Compositor Services" — 跨设备渲染架构核心能力
|
||||
> "Reduced overdraw by 60% using early-Z rejection" — 性能优化的典型表达方式
|
||||
> "Placed focus plane at 2m for comfortable vergence" — 空间 UX 的核心设计考量
|
||||
|
||||
## Key Concepts
|
||||
- [[Metal]]：Apple 的 GPU 编程框架，用于高性能 3D 渲染
|
||||
- [[Vision Pro Compositor Services]]：Apple 的 LayerRenderer API，用于向 Vision Pro 流式传输立体帧
|
||||
- [[RemoteImmersiveSpace]]：Apple 平台的空间计算全沉浸模式，用于 macOS 与 Vision Pro 的代码可视化协作
|
||||
- [[Instanced Rendering]]：GPU 批量渲染大量相似几何体的技术，支持 10k-100k 节点
|
||||
- [[Force-Directed Graph Layout]]：基于 GPU 物理模拟的图布局算法
|
||||
- [[Frustum Culling]]：视锥剔除优化技术，用于跳过不可见几何体
|
||||
- [[Stereoscopic Rendering]]：立体渲染技术，同时渲染左右眼视角
|
||||
|
||||
## Key Entities
|
||||
- [[Apple]]：平台提供商，提供 Metal、visionOS、Compositor Services 等核心技术框架
|
||||
- [[Vision Pro]]：Apple 的空间计算头显设备，通过 RemoteImmersiveSpace 实现远程沉浸体验
|
||||
- [[Xcode]]：Apple 开发环境，用于 Metal 项目构建
|
||||
- [[Metal System Trace]]：Apple 性能分析工具，用于 GPU 性能调优
|
||||
- [[Instruments]]：Apple 系统性能分析套件，用于内存和性能分析
|
||||
|
||||
## Connections
|
||||
- [[visionOS Spatial Engineer]] ← extends ← [[macOS Spatial/Metal Engineer]]
|
||||
- [[Metal Graph Renderer]] ← depends_on ← [[Force-Directed Graph Layout]]
|
||||
- [[Vision Pro Compositor]] ← depends_on ← [[Compositor Services]]
|
||||
- [[Spatial Interaction Handler]] ← depends_on ← [[Gaze Tracking]] ← depends_on ← [[Vision Pro]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现内容冲突
|
||||
|
||||
|
||||
@@ -1,55 +1,58 @@
|
||||
---
|
||||
title: "AI Citation Strategist"
|
||||
type: source
|
||||
tags: ["marketing", "AI", "SEO", "AEO", "GEO"]
|
||||
date: 2026-04-26
|
||||
tags: ["marketing", "AI", "AEO", "GEO", "SEO"]
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/marketing/marketing-ai-citation-strategist.md]]
|
||||
- [[Agent/agency-agents/marketing/marketing-ai-citation-strategist.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AI 推荐引擎优化（AEO/GEO）—— 如何让品牌在 ChatGPT、Claude、Gemini、Perplexity 等 AI 助手中被引用，而不是被竞争对手取代
|
||||
- 问题域：品牌在 AI 搜索引擎中的可见性问题；传统 SEO 策略无法迁移到 AI 引用场景；竞品频繁出现在 AI 推荐中但自身品牌却缺席
|
||||
- 方法/机制：通过多平台引用审计（Citation Audit）、丢失提示分析（Lost Prompt Analysis）、内容缺口检测、Schema markup 优化，生成优先级修复包（Fix Pack）来改善 AI 引用信号
|
||||
- 结论/价值：AI 引用与传统 SEO 是不同策略，需要独立的 AEO/GEO 工作流；通过结构化数据、实体信号强化、FAQ 对齐，可显著提升品牌在 AI 平台上的引用率
|
||||
- 核心主题：AI 推荐引擎优化（AEO/GEO）—— 让品牌在 ChatGPT、Claude、Gemini、Perplexity 等 AI 平台中获得引用推荐
|
||||
- 问题域：品牌在传统 SEO 上表现良好，但 AI 引擎优先推荐竞品；AEO 与 SEO 信号完全不同
|
||||
- 方法/机制：通过多平台引用审计（Citation Audit）识别品牌被竞品替代的根本原因，生成优先级修复包（Fix Pack）
|
||||
- 结论/价值：改善实体信号（Entity Clarity）、结构化权威数据、FAQ 对齐、Schema 标记，提升 AI 引用概率
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AI 引用率（Citation Rate）是衡量品牌在 AI 推荐引擎中可见性的核心指标
|
||||
- 传统 SEO 成功不能自动转化为 AI 可见性，AEO 与 SEO 必须作为独立策略对待
|
||||
- ChatGPT、Claude、Gemini、Perplexity 四个平台的引用行为和内容偏好各不相同，必须多平台审计
|
||||
- Schema markup、实体清晰度、FAQ 对齐是提升 AI 引用率的三大信号优化方向
|
||||
- Fix Pack 应按预期引用改善幅度排序，而非按实施难易度排序
|
||||
- AI 引用与 SEO 排名是两种截然不同的游戏，SEO 成功不等于 AI 可见性
|
||||
- 引用率（Citation Rate）= 品牌被引用次数 / 测试提示词总数，可量化评估 AI 可见性
|
||||
- 必须在 ChatGPT、Claude、Gemini、Perplexity 四个平台同时审计，单平台审计无法反映全貌
|
||||
- AI 响应具有非确定性，只能"提升引用概率"而非"保证被引用"
|
||||
|
||||
## Key Quotes
|
||||
> "AI citation is a fundamentally different game from SEO. Search engines rank pages. AI engines synthesize answers and cite sources — and the signals that earn citations are not the same signals that earn rankings." — 核心差异化定位
|
||||
> "Never guarantee citation outcomes. AI responses are non-deterministic. You can improve the signals, but you cannot control the output." — 诚实边界声明
|
||||
> "Prioritize by impact, not effort." — Fix Pack 排序原则
|
||||
> "AI citation is a fundamentally different game from SEO. Search engines rank pages. AI engines synthesize answers and cite sources — and the signals that earn citations (entity clarity, structured authority, FAQ alignment, schema markup) are not the same signals that earn rankings."
|
||||
> — AI Citation Strategist Agent 核心定位
|
||||
|
||||
> "Always audit multiple platforms. ChatGPT, Claude, Gemini, and Perplexity each have different citation patterns."
|
||||
> — 审计平台选择原则
|
||||
|
||||
> "Benchmark before you fix. Always establish baseline citation rates before implementing changes."
|
||||
> — 先基准测量再修复的方法论
|
||||
|
||||
## Key Concepts
|
||||
- [[Answer Engine Optimization (AEO)]]：针对 AI 问答引擎的优化策略，使品牌内容被 AI 助手引用
|
||||
- [[Generative Engine Optimization (GEO)]]：针对生成式 AI 引擎的可见性优化，通过信号工程提升引用概率
|
||||
- [[Citation Rate]]：品牌在特定 AI 平台被引用的频率，是 AEO/GEO 的核心衡量指标
|
||||
- [[Fix Pack]]：优先级修复包，包含具体的内容修改方案和预期引用改善幅度
|
||||
- [[Lost Prompt Analysis]]：分析品牌应该出现但竞争对手胜出的查询场景
|
||||
- [[Citation Audit Scorecard]]：跨平台 AI 引用审计评分卡，量化品牌在各平台的可见性
|
||||
- [[Entity Optimization]]：强化品牌实体信号（一致性命名、知识图谱存在、Schema markup）
|
||||
- [[Platform-Specific Patterns]]：不同 AI 平台（ChatGPT/Claude/Gemini/Perplexity）的引用偏好差异
|
||||
- [[Answer Engine Optimization]]：答案引擎优化，专注于让内容在 AI 搜索中被直接引用
|
||||
- [[Generative Engine Optimization]]：生成式引擎优化，通过改善内容信号提升 AI 引用概率
|
||||
- [[Citation Audit Scorecard]]：AI 引用审计记分卡，按平台统计引用率
|
||||
- [[Fix Pack]]：优先级修复包，按影响力排序的内容改进计划
|
||||
- [[Lost Prompt Analysis]]：丢失提示词分析，识别品牌应该出现但竞品胜出的查询
|
||||
- [[Schema Markup]]：结构化数据标记，AI 引擎偏好的内容格式信号
|
||||
- [[Entity Optimization]]：实体优化，强化品牌在 AI 知识图谱中的可识别性
|
||||
|
||||
## Key Entities
|
||||
- [[ChatGPT]]：OpenAI 的 AI 助手，引用偏好权威性来源、结构化页面（FAQ、对比表格、操作指南），训练数据截止日 + 实时浏览
|
||||
- [[Claude]]：Anthropic 的 AI 助手，偏好细致、平衡、有明确来源的内容，训练数据截止日模式
|
||||
- [[Gemini]]：Google 的 AI 助手，强烈依赖 Google 生态信号、结构化数据，实时搜索集成
|
||||
- [[Perplexity]]：AI 搜索引擎，偏好来源多样性、时效性、直接答案，实时搜索模式
|
||||
- **ChatGPT**：OpenAI 的 AI 助手，引用偏好权威性来源和结构化页面
|
||||
- **Claude**：Anthropic 的 AI 助手，偏好细腻、平衡、有明确溯源的内容
|
||||
- **Gemini**：Google 的 AI 助手，依赖 Google 生态信号和结构化数据
|
||||
- **Perplexity**：AI 搜索引擎，偏好来源多样性、时效性和直接答案
|
||||
|
||||
## Connections
|
||||
- [[Marketing Growth Hacker Agent]] ← shares_marketing_domain ← [[AI Citation Strategist]]
|
||||
- [[Marketing SEO Specialist]] ← complements ← [[AI Citation Strategist]]（SEO 与 AEO 互补但独立）
|
||||
- [[Marketing Agentic Search Optimizer]] ← related_to ← [[AI Citation Strategist]]（同为 AI 驱动的内容优化方向）
|
||||
- [[marketing-seo-specialist]] ← complements ← [[marketing-ai-citation-strategist]]
|
||||
- [[marketing-agentic-search-optimizer]] ← extends ← [[marketing-ai-citation-strategist]]
|
||||
- [[marketing-growth-hacker]] ← uses ← [[marketing-ai-citation-strategist]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Marketing SEO Specialist]] 潜在冲突：
|
||||
- 与 [[marketing-seo-specialist]] 的潜在冲突：
|
||||
- 冲突点：SEO 高排名是否等同于 AI 高引用率
|
||||
- 当前观点（AEO）：SEO 成功 ≠ AI 可见性，两者信号体系不同，需独立优化
|
||||
- 对方观点（SEO）：传统 SEO 手段（外链、关键词密度）已足够
|
||||
- 建议：AEO 与 SEO 应作为互补策略协同使用，不可偏废
|
||||
- 当前观点（AEO 视角）：SEO 成功不等于 AI 可见性，两者信号完全不同
|
||||
- 对方观点（SEO 视角）：传统搜索优化可以间接提升 AI 引用概率
|
||||
- 结论：两者应作为互补但独立的策略并行推进
|
||||
|
||||
@@ -2,64 +2,52 @@
|
||||
title: "App Store Optimizer"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
date: 2026-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/marketing/marketing-app-store-optimizer.md]]
|
||||
- [[Agent/agency-agents/marketing/marketing-app-store-optimizer.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：App Store 优化（ASO）全栈专家 Agent——专注于应用商店搜索可见性优化、视觉资产转化率提升和可持续用户增长。
|
||||
- 问题域：App 开发者在应用商店中面临的发现难、下载转化低、自然增长乏力的问题。
|
||||
- 方法/机制：数据驱动决策 + 转化优先设计哲学 + A/B 测试系统性优化 + 国际化本地化策略 + 四阶段工作流（市场研究→策略开发→实施测试→优化规模化）。
|
||||
- 结论/价值：帮助 App 实现有机下载月增长 30%+、关键词前 10 排名 20+ 个、转化率提升 25%+、评分提升至 4.5 星+。
|
||||
- 核心主题：App Store 优化（ASO）专家智能体，专注于提升应用商店可发现性、转化率和有机下载量
|
||||
- 问题域：移动应用在 App Store / Google Play 中的搜索可见性不足、商店 listing 转化率低、缺乏系统性 ASO 策略
|
||||
- 方法/机制：数据驱动的关键词研究与元数据优化、A/B 测试视觉资产（图标/截图/预览视频）、本地化策略、评分管理、竞品分析框架
|
||||
- 结论/价值：提供完整的 ASO 策略框架和可量化成功指标（有机下载增长 30%/月、关键词进入 Top 10、转化率提升 25%+）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- App Store Optimizer Agent 通过系统性关键词研究与元数据优化，提升应用商店搜索排名和自然发现量。
|
||||
- 视觉资产（图标/截图/预览视频）是应用商店转化率的核心驱动因素，需通过 A/B 测试持续迭代。
|
||||
- 所有优化决策必须基于转化率数据而非创意偏好，转化优先于美学。
|
||||
- 国际化本地化策略是海外市场扩展成功的关键前提。
|
||||
- 应用商店优化需要持续迭代的四阶段工作循环，而非一次性项目。
|
||||
- App Store Optimizer Agent 通过系统性关键词研究和元数据优化，可将有机下载量提升 30% 以上（月环比）
|
||||
- 视觉资产（图标 + 截图序列 + 预览视频）的 A/B 测试优化可将商店 listing 转化率提升 25% 或以上
|
||||
- 数据驱动的 ASO 方法要求所有优化决策基于性能数据和用户行为分析，而非创意偏好
|
||||
- 应用本地化策略结合文化适配和市场特定截图，可成功拓展国际市场份额
|
||||
|
||||
## Key Quotes
|
||||
> "Improved app store conversion rate from 18% to 28% with optimized screenshot sequence" — 视觉资产优化对转化率的量化影响
|
||||
> "Increased organic downloads by 45% through keyword optimization and visual asset testing" — 关键词策略的 ROI 证明
|
||||
> "Identified keyword gap that competitors missed, gaining top 5 ranking in 3 weeks" — 竞争情报驱动的关键词机会发现
|
||||
> "A/B tested 5 icon variations, with version C delivering 23% higher conversion rate" — A/B 测试驱动的图标优化方法论
|
||||
> "You are App Store Optimizer, an expert app store marketing specialist who focuses on App Store Optimization (ASO), conversion rate optimization, and app discoverability." — Agent 身份定义
|
||||
> "Conversion-First Design Philosophy: Prioritize app store conversion rate over creative preferences." — 核心设计哲学
|
||||
> "Base all optimization decisions on performance data and user behavior analytics." — 数据驱动方法论
|
||||
> "Organic download growth exceeds 30% month-over-month consistently." — 成功指标定义
|
||||
|
||||
## Key Concepts
|
||||
- [[App-Store-Optimization-ASO]]：应用商店搜索可见性与转化率优化的系统性方法论，涵盖关键词研究、元数据优化和视觉资产设计。
|
||||
- [[Conversion-Rate-Optimization-CRO]]：转化率优先设计哲学——优先考虑应用商店转化率而非创意偏好。
|
||||
- [[Visual-Asset-Optimization]]：图标、截图序列、预览视频等视觉资产的系统性设计与 A/B 测试框架。
|
||||
- [[A-B-Testing]]：数据驱动的 A/B 测试框架，用于视觉元素和文案的系统性优化。
|
||||
- [[International-Localization-ASO]]：针对不同国际市场的文化适应与本地化优化策略。
|
||||
- [[Keyword-Research]]：关键词研究与分析，包括主要关键词、长尾关键词和竞争差距识别。
|
||||
- [[Review-Management]]：评论管理系统，用于提升评分和收集用户洞察。
|
||||
- [[Competitive-Analysis-ASO]]：竞争分析框架，识别定位机会和关键词覆盖差距。
|
||||
- [[App Store Optimization（ASO）]]：通过关键词研究、元数据优化和视觉资产优化提升应用在商店搜索结果中的排名和下载量
|
||||
- [[Conversion Rate Optimization]]：将应用商店浏览者转化为下载者的系统性方法，优先于创意偏好
|
||||
- [[A/B Testing]]：对视觉元素（图标/截图/描述）和文本元素进行统计显著的对照测试
|
||||
- [[Keyword Research]]：识别高搜索量、低竞争度的关键词机会，包括主要关键词和长尾关键词
|
||||
- [[Visual Asset Optimization]]：图标、截图序列和预览视频的设计与测试优化
|
||||
- [[App Localization]]：针对国际市场的文化适应和本地化商店 listing 优化
|
||||
- [[Review Management]]：评分管理和用户评价优化策略
|
||||
|
||||
## Key Entities
|
||||
- [[App-Store]]（Apple App Store / Google Play）：App 分发的两大核心平台，各有不同的优化要求和技术规格。
|
||||
- [[iOS]]：Apple 应用商店平台，优化元数据包括标题、副标题、长描述。
|
||||
- [[Android]]（Google Play）：Android 应用商店平台，优化元数据包括简短描述和完整描述。
|
||||
- [[App-Store-Connect]]：Apple 开发者工具，用于 App 元数据管理和分析。
|
||||
- App Store Optimizer Agent：The Agency Marketing 部门的 ASO 专家智能体，人格特质为数据驱动、转化导向、以成果为核心
|
||||
- App Store（iOS）：Apple 的官方应用商店，ASO 的主要优化平台之一
|
||||
- Google Play（Android）：Google 的 Android 应用商店，与 iOS 并列的 ASO 优化平台
|
||||
|
||||
## Connections
|
||||
- [[Marketing-SEO-Specialist]] ← complements ← [[App-Store-Optimizer]]
|
||||
- SEO 优化 Web 搜索发现，ASO 优化应用商店搜索发现，两者共同构成全渠道数字发现优化体系。
|
||||
- [[Marketing-Content-Creator]] ← feeds ← [[App-Store-Optimizer]]
|
||||
- 内容创作者提供高质量 App 描述文案和截图文字，App Store 优化师将其转化为应用商店最优格式。
|
||||
- [[Marketing-Growth-Hacker]] ← collaborates ← [[App-Store-Optimizer]]
|
||||
- 增长黑客负责整体增长策略，App Store 优化师负责应用商店这一关键渠道的有机增长。
|
||||
- [[Marketing-Short-Video-Editing-Coach]] ← supports ← [[App-Store-Optimizer]]
|
||||
- 短视频剪辑教练提供 App 预览视频制作技能，App Store 优化师定义预览视频策略和规格。
|
||||
- [[Marketing-Video-Optimization-Specialist]] ← overlaps ← [[App-Store-Optimizer]]
|
||||
- 视频优化专家与 App Store 优化师共同优化 App 预览视频，两者在视频策略层面互补。
|
||||
- [[Marketing-China-E-Commerce-Operator]] ← complements ← [[App-Store-Optimizer]]
|
||||
- 电商运营师负责国内电商平台，App Store 优化师负责应用商店——两个都是移动用户获取渠道。
|
||||
- [[Marketing Growth Hacker Agent]] ← extends ← [[App Store Optimizer]]：增长黑客 Agent 依赖 ASO 的有机增长基础
|
||||
- [[Marketing Video Optimization Specialist Agent]] ← depends_on ← [[Visual Asset Optimization]]：视频优化专家负责 ASO 所需的预览视频制作
|
||||
- [[Marketing Content Creator]] ← related_to ← [[App Store Optimizer]]：内容创作者为 ASO 提供文案和创意素材支持
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Marketing-SEO-Specialist]] 存在方法论差异（但非冲突）：
|
||||
- 冲突点：内容优化策略是否适用于应用商店。
|
||||
- 当前观点（ASO）：应用商店有独立算法和用户行为模式，Web SEO 最佳实践不可直接迁移。
|
||||
- 对方观点（SEO）：内容质量、反向链接、用户参与信号等核心原则是通用的。
|
||||
- 注：两者实为互补而非竞争——分别服务 Web 和 App 两个不同发现渠道。
|
||||
- 与 [[Marketing Social Media Strategist]] 存在方法论张力：
|
||||
- 冲突点：创意自由 vs 数据约束
|
||||
- 当前观点（ASO）：创意服从转化数据，一切以可量化绩效为准
|
||||
- 对方观点（社媒策略）：品牌一致性和创意叙事同样重要，不应被短期转化率数据绑架
|
||||
- 协调方式：两者互补而非竞争——ASO 优化下载漏斗顶层，社媒策略负责漏斗中层品牌认知
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user