1 设计大纲
1.1 路线
00.汇总
a.模型训练与微调层
DeepSpeed 微软推出的深度学习优化库，通过 ZeRO 技术极大降低分布式训练显存占用，是千亿模型训练标配。
Megatron-LM 英伟达开发的大规模语言模型训练框架，支持模型并行与流水线并行，专为 NVIDIA GPU 集群设计。
PEFT HuggingFace 高效微调库，集成了 LoRA、P-Tuning 等方法，让消费级显卡也能微调大模型。
RLHF/PPO 基于人类反馈的强化学习与近端策略优化算法，是让模型价值观对齐、听懂人话的核心技术。
b.模型优化与推理层
vLLM 高吞吐推理引擎，首创 PagedAttention 技术，显著提升显存利用率与并发处理能力。
TensorRT 英伟达官方高性能推理 SDK，通过算子融合与内核自动调优，在 N 卡上实现极致推理速度。
ONNX/Runtime 开放神经网络交换格式与跨平台运行时，实现一次训练、多端（云/边/端）高效部署。
模型量化/剪枝 通过降低数值精度（如 INT4）或移除冗余权重，大幅压缩模型体积并在边缘端加速推理。
c.智能体与应用框架层
AutoGen 微软开源的多智能体协作框架，支持多个 Agent 扮演不同角色（如程序员、测试员）共同解决复杂任务。
CrewAI 基于角色的 Agent 编排框架，强调结构化流程与团队协作，适合构建有明确分工的自动化工作流。
Dify/Flowise 低代码/无代码 LLM 应用开发平台，可视化编排 RAG 与 Agent 流程，极大降低应用开发门槛。
LangGraph LangChain 的图结构扩展，引入状态机机制，专为构建包含循环、分支与记忆的复杂 Agent 而生。
d.数据工程与运维层 (LLMOps)
MLflow 开源 ML 生命周期管理平台，提供实验跟踪、模型注册与版本控制，确保模型迭代可追溯。
W&B Weights & Biases 实验可视化工具，实时监控训练指标与系统资源，是炼丹师必备的仪表盘。
Docker/K8s 云原生基石，通过容器化与集群编排实现大模型服务的弹性伸缩、高可用与资源隔离。
FastAPI 现代 Python Web 框架，原生支持异步与类型检查，是构建高性能大模型 API 服务的不二之选。
e.知识增强与数据处理层
Neo4j/GraphRAG 图数据库与图谱增强检索技术，通过显式关系建模解决传统 RAG 缺乏全局推理与实体关联的问题。
OPC-UA/MQTT 工业互联与物联网通信协议标准，打通 MES/PLC 等底层设备与上层 AI 智能应用的数据链路。
Polars 新一代 Rust 编写的 DataFrame 库，在处理大规模结构化数据时性能远超 Pandas，适合数据清洗 ETL。
Streamlit 面向数据科学家的 PythonWeb 框架，几行代码即可将模型脚本转化为交互式 Web 应用，快速验证效果。
f.RAG 进阶与检索工程层
Hybrid Search 向量检索与 BM25 关键词检索融合方案，平衡语义召回与精确匹配，是企业级 RAG 的工业标配。
Reranker 检索后精排组件（Cross-Encoder），对粗排候选集二次评分，大幅提升最终输入 LLM 的文档质量。
Unstructured/DocLing 多格式文档解析库，处理 PDF/HTML/表格/代码等非结构化内容，是 RAG 数据管道的入口关卡。
LlamaIndex Pipeline 结构化 RAG 流水线抽象，涵盖 Ingestion/Query/Evaluation 三段，使检索逻辑可组合与可测试。
g.评测、回归与可迭代层
RAGAS 专为 RAG 场景设计的自动评测框架，提供忠实度/答案相关性/上下文召回等标准化指标。
Langfuse 开源 LLM 可观测与评测平台，支持 Trace 采集、评测集管理与 A/B 版本对比，LangSmith 的开源替代。
Promptfoo Prompt 与 Agent 回归测试工具，一条命令跑测试集并生成对比报告，防止提示词改动引入退化。
DeepEval Python 原生评测框架，内置 G-Eval/幻觉检测/安全红队等评测器，可集成到 CI/CD 流水线。
h.生产化工程层
vLLM/SGLang 高吞吐推理引擎，vLLM 首创 PagedAttention，SGLang 进一步优化结构化生成与批处理调度。
Semantic Cache 语义缓存组件（如 GPTCache），对相似查询直接复用历史响应，显著降低 Token 成本与延迟。
OpenTelemetry 云原生观测标准，统一采集 Trace/Metric/Log，将 LLM 调用链路纳入全链路监控体系。
Helicone/LangFuse LLM 网关级观测工具，实现 Token 成本归因、失败样例捕获与用户会话回放。
i.安全、权限与可控层
Garak LLM 自动化红队工具，系统性探测提示注入、越狱、数据外泄等安全漏洞，生成安全评估报告。
Guardrails AI/NeMo 输出护栏框架，对 LLM 响应做实时校验（PII 脱敏/有害内容/格式合规），保障输出合规可控。
OPA (Open Policy Agent) 通用策略引擎，以声明式方式定义 RBAC/ABAC 权限规则，统管工具调用与 API 访问授权。
Presidio 微软开源 PII 识别与匿名化库，在数据进入 LLM 前自动检测并脱敏敏感信息。
j.持久化工作流与 Durable 工程层
Temporal 工业级 Durable Workflow 引擎，原生支持任务持久化/可中断/可重试/可回放，适合长流程 Agent 编排。
Prefect/Dagster 现代数据/AI 工作流编排框架，提供任务依赖管理、失败重试、调度与资产血缘，打通 MLOps 链路。
Celery/Redis Streams 异步任务队列与流式消息总线，支撑 Agent 任务的并发分发、状态广播与人在回路审批。
Human-in-the-Loop 工作流中插入人工审批/质检节点的设计模式，结合 LangGraph 中断机制实现高风险步骤的强制确认。
01.模型训练与微调层：深入核心引擎
a.说明
大模型的训练与微调是整个生态系统的核心，直接决定了模型的性能和应用效果。
招聘需求中明确提到了对分布式训练、高效微调以及强化学习对齐等技术的掌握。这表明企业不仅需要能用模型的人，更需要能造和改模型的人才。
b.分布式训练
a.关键框架与工具
DeepSpeed, Megatron-LM, PyTorch Lightning, Accelerate
b.说明
训练千亿级参数的大模型必须依赖分布式技术来解决单卡显存不足和训练耗时过长的问题。
DeepSpeed 和 Megatron-LM 是目前最主流的两个大规模训练框架，
分别由微软和英伟达推出，提供了包括数据并行、张量并行、流水线并行在内的多种并行策略。
c.高效微调
a.关键框架与工具
PEFT (Hugging Face), LoRA, QLoRA, DPO
b.说明
全量微调成本高昂，PEFT 技术应运而生。
Hugging Face 的 PEFT 库集成了 LoRA（低秩适应）、QLoRA（量化+LoRA）等多种高效微调方法，
能够在不牺牲太多性能的前提下，极大降低微调所需的计算资源和时间。
d.对齐技术
a.关键框架与工具
RLHF, PPO
b.说明
为了让模型的输出更符合人类的价值观和偏好，需要进行对齐。
RLHF（基于人类反馈的强化学习）是当前的主流方案，其中 PPO 是关键的优化算法。
02.模型优化与推理层：追求极致效率
a.说明
模型训练完成后，如何将其高效地部署到生产环境是另一个关键挑战。
招聘需求中反复提及模型压缩（量化、剪枝）和降低推理延迟，这直接关系到服务成本和用户体验。
b.推理加速引擎
a.关键框架与工具
vLLM, TensorRT, ONNX Runtime
b.说明
vLLM 通过 PagedAttention 等技术极大提升了 LLM 的推理吞吐量。
NVIDIA 的 TensorRT 则通过算子融合、精度量化等手段深度优化模型在英伟达 GPU 上的推理性能。
ONNX 作为开放的神经网络交换格式，配合 ONNX Runtime 可以在不同硬件平台上实现高效部署。
c.模型压缩
a.关键框架与工具
量化, 剪枝, 蒸馏
b.说明
量化通过降低模型参数的数值精度（如从FP16到INT8/INT4）来减小模型体积和加速计算。
剪枝则移除模型中冗余的权重或结构。这些技术是实现模型在边缘设备或资源受限环境中部署的必备技能。
03.智能体与应用框架层：构建智能应用
a.说明
智能体是当前大模型应用的热点方向，它赋予了模型自主规划、调用工具和完成复杂任务的能力。
您附件中的多个岗位都将智能体开发列为核心职责。
b.多智能体协作
a.关键框架与工具
AutoGen, CrewAI
b.说明
AutoGen（微软）和 CrewAI 允许多个智能体以协作的方式共同完成复杂任务，
例如模拟一个软件开发团队进行编码、测试和调试。这对于解决开放性、多步骤的问题至关重要。
c.应用开发/编排
a.关键框架与工具
Dify, Flowise, ragflow
b.说明
这类平台提供了低代码或无代码的可视化界面，让开发者可以快速地将 LangChain、LlamaIndex 等基础框架的能力组合起来，
构建 RAG 应用、智能体工作流等，极大地提升了开发效率。
d.流程控制
a.关键框架与工具
LangGraph
b.说明
作为 LangChain 的扩展，LangGraph 引入了图的结构来表示智能体内部或多个智能体之间的工作流程。
它以状态机的方式提供了更强大、更可控的循环和分支逻辑，适合构建复杂的、非线性的智能体行为。
04.数据工程与运维层：保障稳定运行
a.说明
随着大模型应用的复杂化和规模化，传统的软件工程和运维实践也需要相应升级，衍生出了 LLMOps 和 DataOps 的概念。
b.LLMOps/MLOps
a.关键框架与工具
MLflow, DVC, Weights & Biases, Prometheus, Grafana
b.说明
LLMOps 覆盖了模型从开发、训练、部署到监控的全生命周期管理。
MLflow 和 DVC 用于实验跟踪和数据/模型版本控制；
Weights & Biases 和 Neptune.ai 提供强大的实验可视化和协作功能；
Prometheus 和 Grafana 则是云原生时代服务监控和告警的事实标准。
c.容器化与编排
a.关键框架与工具
Docker, Kubernetes (K8s)
b.说明
Docker 和 Kubernetes 是现代云原生应用的基石。
将大模型服务容器化并通过 K8s 进行管理，可以实现弹性伸缩、高可用部署和资源的统一调度。
d.API 开发
a.关键框架与工具
FastAPI, gRPC
b.说明
FastAPI 因其高性能和现代化的特性，已成为 Python 后端服务（包括模型API服务）的首选框架之一。
gRPC 则是 Google 推出的高性能 RPC 框架，在需要低延迟、高吞吐的微服务间通信场景中优势明显。
05.知识增强与数据处理层：挖掘数据价值
a.说明
大模型的智能离不开高质量的数据。无论是 RAG 中的外部知识库，还是对接企业内部系统，强大的数据处理和整合能力都是不可或缺的。
b.知识图谱
a.关键框架与工具
Neo4j, GraphRAG
b.说明
相比于向量数据库的相似性检索，知识图谱能够表达实体之间更复杂、更精确的语义关系。
GraphRAG 技术将知识图谱与大模型结合，能够进行更深度的逻辑推理和可解释性更强的回答生成。Neo4j 是目前最流行的图数据库。
c.工业系统集成
a.关键框架与工具
OPC UA, Modbus, MQTT
b.说明
招聘需求中明确提到了与 MES、QMS 等工业系统的对接。
这需要掌握 OPC UA、Modbus 等工业通信协议，以及 MQTT 这类物联网消息协议，从而打通生产数据与上层智能应用的链路。
d.数据处理与可视化
a.关键框架与工具
Polars, Spark, Tableau, Power BI, Streamlit
b.说明
除了 Pandas 和 NumPy，Polars 作为新一代高性能数据处理库值得关注。
对于海量数据，则需要 Spark 等大数据框架。
将分析结果通过 Tableau、Power BI 等专业 BI 工具或 Streamlit、Gradio 等快速应用框架进行可视化呈现，是数据价值闭环的关键一步。
06.RAG 进阶与检索工程层：让检索真正可用
a.说明
"能调通向量库"只是起点，企业级 RAG 的核心挑战在于检索质量和数据质量。
从文档解析到混合检索再到精排，每一环节都直接决定最终答案的准确性与可信度。
b.文档解析与数据清洗
a.关键框架与工具
Unstructured, DocLing, Marker, LlamaParse
b.说明
真实业务文档以 PDF/HTML/Word/表格/代码等混合形态存在。
Unstructured 和 DocLing 能将多格式文档转化为结构化文本块；
Marker 专攻学术 PDF；LlamaParse 提供云端高精度解析服务。
解析质量直接决定 RAG 系统的天花板。
c.混合检索与 Chunk 策略
a.关键框架与工具
BM25 (Elasticsearch/OpenSearch), Hybrid Search, 语义分块, 父子 Chunk
b.说明
单纯向量检索在精确词匹配场景表现较差；Hybrid Search 融合 BM25 与向量检索，
通过 RRF（倒数排名融合）加权合并两路结果，兼顾语义理解与关键词精准度。
Chunk 策略同样关键：滑动窗口/结构化分块/父子 Chunk 各有适用场景。
d.检索增强与排序
a.关键框架与工具
Reranker (BGE-Reranker, Cohere Rerank), Query Rewrite, Self-Query, Multi-Query
b.说明
粗排阶段召回的 Top-K 文档质量参差不齐，Cross-Encoder Reranker 对候选集做精排，
大幅提升最终输入 LLM 的文档相关性。
Query Rewrite 和 Multi-Query 通过对原始问题改写/扩展，解决用户表达不精准的问题。
Self-Query 则将自然语言过滤条件转为向量库元数据结构化查询。
07.评测、回归与可迭代层：让系统持续改进
a.说明
没有评测就没有迭代。这是多数项目从 PoC 跑通到产品稳定的核心分水岭。
建立离线评测集、量化关键指标、将失败样例自动沉淀为回归用例，
才能让每次提示词/检索/模型的调整都有数据支撑而非靠感觉。
b.RAG 评测指标与框架
a.关键框架与工具
RAGAS, TruLens, DeepEval
b.说明
RAGAS 提供忠实度（Faithfulness）、答案相关性（Answer Relevance）、
上下文召回率（Context Recall）等 RAG 专属指标，可用 LLM-as-Judge 模式自动评分。
TruLens 和 DeepEval 进一步支持幻觉检测、毒性检测、自定义评测器，
并可与测试框架（pytest）集成，将评测纳入 CI/CD。
c.Prompt 与 Agent 回归测试
a.关键框架与工具
Promptfoo, LangSmith Evals, Langfuse Experiments
b.说明
Promptfoo 支持以 YAML 配置驱动的批量 Prompt 测试，一键生成多版本对比报告；
LangSmith/Langfuse 的 Experiment 功能则将线上真实 Trace 转化为离线评测集，
确保每次改动不引入线上效果退化（回归）。
d.评测数据集建设
a.关键框架与工具
手工标注 + 合成数据（LLM 自动生成 Q&A 对）
b.说明
冷启动阶段先用 LLM 基于知识库自动生成问答对作为种子评测集；
随着线上运行，将低分/用户纠错样例持续沉淀进评测集；
最终形成"线上采集 → 人工审核 → 自动回归"的闭环数据飞轮。
08.生产化工程层：成本、延迟与可观测
a.说明
推理成本和响应延迟直接决定产品的商业可行性。
可观测性则决定出问题时能不能快速定位根因。
这一层是"能跑通演示"和"能上线运营"之间最大的工程鸿沟。
b.推理服务与本地部署
a.关键框架与工具
vLLM, SGLang, TGI (Text Generation Inference), Triton Inference Server
b.说明
vLLM 的 PagedAttention 解决了 KV Cache 显存碎片问题，大幅提升并发吞吐；
SGLang 进一步优化了结构化生成（JSON Schema 约束）的调度效率；
TGI 是 HuggingFace 官方推理服务，支持连续批处理与量化推理，
Triton 则是 NVIDIA 的多模型并行服务框架，适合混合推理场景。
c.缓存与成本治理
a.关键框架与工具
GPTCache, Semantic Cache, LLM Gateway (LiteLLM)
b.说明
语义缓存对向量相似度超过阈值的查询直接返回历史响应，节省 50%+ Token 成本；
LiteLLM 作为统一网关，实现多供应商路由/负载均衡/降级/限流/成本追踪；
结合按用户/按功能的 Token 配额管理，实现精细化成本治理。
d.全链路可观测
a.关键框架与工具
OpenTelemetry, Langfuse, Helicone, Prometheus + Grafana
b.说明
OpenTelemetry 统一了 Trace/Metric/Log 的采集标准，将 LLM 调用纳入微服务全链路追踪；
Langfuse/Helicone 专注 LLM 层面的细粒度观测：Token 消耗/延迟分布/错误分类/用户会话回放；
Prometheus + Grafana 负责系统层监控：GPU 利用率/QPS/P99 延迟/OOM 告警。
09.安全、权限与可控层：从可用到可信
a.说明
工具调用赋予了 Agent 真实的操作能力，这也带来了真实的安全风险。
提示注入、越权工具调用、敏感数据外泄是高频生产事故。
安全层必须在架构设计阶段就植入，而非上线后补救。
b.对抗攻击与红队测试
a.关键框架与工具
Garak, PyRIT (微软), Promptfoo (安全模式)
b.说明
Garak 是 LLM 自动化红队框架，内置 100+ 攻击探针（越狱/提示注入/幻觉诱导/数据提取），
可定期对生产模型跑安全基线；
PyRIT（微软 AI Red Team）提供攻击编排与策略库；
将安全评测集成到 CI/CD，每次模型/提示词更新前自动跑安全回归。
c.输出护栏与合规校验
a.关键框架与工具
Guardrails AI, NVIDIA NeMo Guardrails, Llama Guard
b.说明
Guardrails AI 在 LLM 调用前后插入 Validator，对输入和输出做格式/内容/合规校验；
NeMo Guardrails 支持以对话流规则声明式定义禁止话题和安全边界；
Llama Guard 是专门训练的安全分类模型，对输入输出做实时有害内容检测。
d.权限管理与审计
a.关键框架与工具
OPA (Open Policy Agent), Casbin, PII 脱敏 (Presidio)
b.说明
工具调用必须执行最小权限原则：每个 Agent/用户角色只能调用其被授权的工具子集；
OPA 以声明式 Rego 策略统管 API 级权限；Casbin 提供轻量级 RBAC/ABAC 实现；
Presidio 在数据进入 LLM 前自动识别并脱敏手机号/身份证/账号等 PII 字段；
所有工具调用须落地审计日志（who/what/when/result），支持事后追责与回放分析。
10.持久化工作流与 Durable 工程层：让 Agent 跑稳长任务
a.说明
现实业务中的 Agent 任务往往是长流程、多步骤、需要等待外部系统响应的。
依赖单次 LLM 调用链无法保证可靠性，一旦中途失败就需要从头重跑。
Durable Workflow 引擎让任务状态持久化，支持中断/恢复/重试/回放，
是 Agent 从玩具走向生产的关键工程基础设施。
b.Durable Workflow 引擎
a.关键框架与工具
Temporal, Conductor (Netflix), Restate
b.说明
Temporal 是目前最成熟的开源 Durable Workflow 引擎，
通过事件溯源机制保证工作流状态持久化；
任意节点失败后可以从断点精确恢复，而非从头重跑；
天然支持定时调度、超时重试、信号量（等待人工审批）和 Saga 补偿事务。
c.数据与 AI 工作流编排
a.关键框架与工具
Prefect, Dagster, Airflow (成熟场景)
b.说明
Prefect 和 Dagster 代表新一代 DataOps/MLOps 编排框架，
提供任务依赖 DAG、失败重试、动态分支、数据资产血缘与调度管理；
相比 Airflow 更轻量、对 Python 原生友好，适合 LLM 数据管道与模型训练流水线编排。
d.人在回路（Human-in-the-Loop）
a.关键框架与工具
LangGraph Interrupt, Temporal Signal, 审批工作流集成
b.说明
高风险操作（发邮件/执行 SQL/调用外部 API）必须支持人工介入节点；
LangGraph 的 interrupt() 机制可在任意节点暂停 Agent 并等待人工确认；
Temporal 的 Signal/Query 机制支持异步等待外部审批系统回调；
Human-in-the-Loop 既是安全保障，也是 Agent 能力边界扩展的关键接口。
e.异步任务与消息驱动
a.关键框架与工具
Celery + Redis/RabbitMQ, Redis Streams, Kafka
b.说明
Agent 任务天然适合异步处理：用户发起任务后立即返回任务 ID，
后台 Worker 异步执行并通过消息推送结果；
Celery 是 Python 生态最成熟的分布式任务队列；
Kafka/Redis Streams 则适合高吞吐的事件流场景（如多 Agent 间的状态广播与任务分发）。
1.2 UI设计
01.Vue方向
a.AI Elements Vue
地址：https://github.com/ai-elements/ai-elements-vue
技术栈为Vue 3，来源为Vue社区或Vercel生态。这是shadcn风格的AI对话组件集，包含消息列表和输入框等高度组件化内容，支持复制粘贴式集成，适合构建ChatGPT风格界面。
b.MateChat
地址：https://github.com/huaweicloud/matechat
技术栈为Vue 3，来源为华为DevCloud团队。这是面向前端智能场景的UI库，内置对话气泡、提示和布局等多种AI组件，支持流式响应，开箱即用，可接多家大模型。
c.TDesign AI Chat
地址：https://tdesign.tencent.com/vue/components/ai-chat
技术栈为Vue 3，来源为腾讯。这是基于TDesign设计体系的AI Chat方案，具有企业级风格，适合中后台应用，在已有TDesign项目中引入成本低。
d.Ant Design X Vue
地址：https://www.antdv.com/components/ai-introduction-cn/
技术栈为Vue 3，来源为阿里。这是“智能界面方案”组件库，提供Bubble、Conversation、ThoughtChain等AI场景组件，并附带useXChat等Hooks，兼顾UI和数据流。
e.vue-renderer-markdown
地址：https://www.npmjs.com/package/vue-renderer-markdown
技术栈为Vue通用版本，来源为npm社区。这是高性能流式Markdown渲染器，用于AI回复内容边流式边渲染，常与各种Chat UI组合使用。
f.markstream-vue
地址：https://www.npmjs.com/package/markstream-vue
技术栈为Vue通用版本，来源为npm社区。这是极轻量、无依赖的流式Markdown渲染器（约800KB级别），适合自己封装消息气泡组件时使用。
g.Tencent chat-uikit-vue3
地址：https://cloud.tencent.com/document/product/269/81706
技术栈为Vue 3，来源为腾讯云。原本为IM场景的Chat UI kit（包含会话列表、消息区和输入区），可以改造成AI Bot与IM混合的聊天界面。
h.Deep Chat（Vue集成）
地址：https://deepchat.dev/docs/integrations/vue
技术栈为Vue 2/3，来源为开源社区。这是通用AI chat组件，可接OpenAI等多家后端，以一个Chat面板形式直接嵌入页面，适合快速起步。
02.React方向
a.AI Elements（React）
地址：https://github.com/ai-elements/ai-elements
技术栈为React，来源为Vercel。这是面向会话式AI的UI primitives，深度适配Vercel AI SDK，组件覆盖消息、输入、工具执行和代码块等，具有shadcn风格。
b.@llamaindex/chat-ui
地址：https://github.com/run-llama/llama-index/tree/main/packages/ui/chat
技术栈为React，来源为LlamaIndex官方。这是官方Chat UI库，结合useChat等hook，通常几行代码即可搭建完整LLM聊天界面，适配LlamaIndex生态。
c.assistant-ui
地址：https://github.com/felix-berlin/assistant-ui
技术栈为React + TS，来源为社区。这是专注AI Chat的React库，内置流式、附件、快捷键等功能，对接Vercel AI SDK或LangGraph等多种后端。
d.shadcn.io/ai
地址：https://ui.shadcn.com/examples/chat
技术栈为React，来源为shadcn生态社区。这是会话式AI示例组件集合，设计与shadcn/ui一致，适合需要完全可控和可改造的ChatGPT风格UI。
e.CUI Kit
地址：https://cuikit.dev/
技术栈为React，来源为第三方团队。这是面向AI助手聊天场景的组件库，风格偏Material或企业风，适用于需要品牌化和自定义程度高的项目。
f.CometChat React UI Kit
地址：https://www.cometchat.com/docs/react-chat-ui-kit
技术栈为React，来源为CometChat。这是即时通讯UI kit，可将AI作为虚拟用户接入，实现IM与AI的混合聊天。
1.3 向量库
00.汇总
a.分类1
Milvus 云原生、高性能的开源向量数据库，支持超大规模相似度搜索与多模态检索
Qdrant Rust 编写的开源向量数据库 / 搜索引擎，提供 REST/gRPC API
Chroma 面向 AI/RAG 的开源向量检索数据库，专注嵌入存储与文档检索
pgvector PostgreSQL 扩展，让 Postgres 原生支持向量存储和相似度搜索
FAISS Meta 开源的相似度搜索与聚类库，偏算法库而非完整数据库
b.分类2
Vector DB 一般指 Milvus、Qdrant、Weaviate、Pinecone、Chroma 等一类具备存储+检索能力的向量数据库产品。
Zvec 阿里开源的轻量级、进程内向量数据库，被称为向量界的 SQLite，面向本地/边缘场景。
Wax 用 Swift 编写的单文件 AI 记忆引擎，把数据、嵌入、索引、元数据和 WAL 全部打包到一个确定性的文件中，用作本地 RAG 的记忆层。
c.分类3
QWD Query Markup Documents，本地文档搜索引擎，一个功能强大的本地搜索引擎，专门用于索引和搜索您的个人文档，如笔记、会议记录、知识库等。
d.对比
库 语言 单文件 Python 支持 特点
Wax Swift ✅ ❌ iOS/macOS 专用
Zvec Rust/Go ✅ 需确认 阿里开源，新项目
Chroma Python ✅ ✅ 最成熟，生态好
LanceDB Rust+Python ✅ ✅ 更快，功能全
sqlite-vss C+Python ✅ ✅ SQLite 扩展
01.分类1
a.Milvus
a.项目地址
https://github.com/milvus-io/milvus
b.简要介绍
云原生、高性能的开源向量数据库，支持超大规模相似度搜索与多模态检索。
c.主要专有特点
多种 ANN 索引（HNSW、IVF、DiskANN 等），可 GPU 加速，支持水平扩展、多租户和丰富运维工具（Attu GUI、Milvus Lite 等），适合大规模在线检索服务。
b.Qdrant
a.项目地址
https://github.com/qdrant/qdrant
b.简要介绍
Rust 编写的开源向量数据库 / 搜索引擎，提供 REST/gRPC API。
c.主要专有特点
资源占用小，支持标量过滤、payload、地理搜索，多语言 SDK，云托管服务，适合轻量但生产可用的在线检索服务。
c.Chroma
a.项目地址
https://github.com/chroma-core/chroma
b.简要介绍
面向 AI/RAG 的开源向量检索数据库，专注嵌入存储与文档检索。
c.主要专有特点
和 Python/LLM 生态深度集成，内置本地向量存储与简单持久化，支持向量+全文检索，适合快速搭建原型和中小型 RAG 应用。
d.pgvector
a.项目地址
https://github.com/pgvector/pgvector
b.简要介绍
PostgreSQL 扩展，让 Postgres 原生支持向量存储和相似度搜索。
c.主要专有特点
向量和结构化数据共库，享受事务、索引、备份等所有 Postgres 能力，支持多种距离度量和近似/精确检索，适合已有 PG 的系统平滑扩展向量功能。
e.FAISS
a.项目地址
https://github.com/facebookresearch/faiss
b.简要介绍
Meta 开源的相似度搜索与聚类库，偏算法库而非完整数据库。
c.主要专有特点
C++/Python 库形态，提供多种高性能 ANN 索引，支持 CPU/GPU、大规模向量集合，但不包含多租户、权限、持久化等 DB 特性，常作为自建向量服务底层引擎。
02.分类2
a.Vector DB（泛称）
a.简要介绍
一般指 Milvus、Qdrant、Weaviate、Pinecone、Chroma 等一类具备存储+检索能力的向量数据库产品。
b.主要专有特点
通常具备：向量+元数据存储、ANN 索引、过滤查询、多租户、水平扩展等特性，比 FAISS 这种算法库更偏完整基础设施。
b.Zvec
a.项目地址
https://github.com/alibaba/zvec
b.简要介绍
阿里开源的轻量级、进程内向量数据库，被称为向量界的 SQLite，面向本地/边缘场景。
c.主要专有特点
以嵌入式库形式集成到应用中，基于 Proxima 引擎，高 QPS、低资源占用；支持内存/CPU 配额控制、流式写入、多向量检索、向量+标量混合搜索，非常适合本地 RAG 和边缘设备。
c.Wax
a.项目地址
https://github.com/christopherkarani/Wax
b.简要介绍
用 Swift 编写的单文件 AI 记忆引擎，把数据、嵌入、索引、元数据和 WAL 全部打包到一个确定性的文件中，用作本地 RAG 的记忆层。
c.主要专有特点
设计目标是无服务器、单文件、本地 RAG，基于 SQLite 和 FTS5，内置向量索引与全文检索；在 Apple Silicon 上使用 Metal 做 GPU 向量检索（10K 文档约 0.84ms），支持崩溃恢复、确定性上下文构建和完全离线隐私，特别适合 iOS/macOS 上的本地 Agent 记忆。
03.分类3
a.图示
┌─────────────────────────────────────────────────────────────────────────┐
│ pgvector + 达梦 DM8 架构 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 方案 1：PostgreSQL + pgvector（开源） │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ PostgreSQL 16 + pgvector 扩展 │ │
│ │ - 向量存储：vector(1024) │ │
│ │ - 索引：IVFFlat / HNSW │ │
│ │ - 协议：PostgreSQL License │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ 方案 2：达梦 DM8 + 兼容层（信创认证） │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ 达梦 DM8 数据库 │ │
│ │ - 通过 ODBC/JDBC 连接 PostgreSQL 扩展 │ │
│ │ - 或使用 DM8 内置向量扩展（DM8_VECT） │ │
│ │ - 协议：商业授权 │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
b.DM8 内置向量扩展（DM8_VECT）
达梦官方生态社区（eco.dameng.com）于 2026 年 3 月发布了《达梦向量数据开发入门手册》，明确记录了 DM8 内置 VECTOR 数据类型的完整用法 。
DM8 通过 dmSQLAlchemy 驱动扩展为 Python 开发者提供向量存储与检索能力，支持将文本或图像通过预训练模型转换为向量并存入数据库 。
1.4 智能体
00.汇总
a.分类1
LangChain 老牌 LLM 应用框架，提供 prompt、memory、工具调用、RAG、Agent 抽象等。
LangGraph 用「图」（有状态状态机）来编排 Agent，适合多轮推理、分支、回溯的人机/多 Agent 流程。
LangSmith LangChain 官方观测/评估平台，做 tracing、日志、评测、A/B、成本/延迟监控。
LangServe 把 LangChain 的 Runnable / Chain 一键暴露成 REST API（FastAPI + Pydantic），带 /invoke /batch /stream 等端点。
LangChain.js LangChain 的 JavaScript/TypeScript 版本，用于 Node/浏览器环境。
LangChain4j 面向 Java 的 LLM 框架，统一封装主流 LLM/向量库 API，内置 RAG、Agent、工具调用等。
LlamaIndex 「数据框架」，专注把各种数据源接进来，建索引（向量/图等），提供高级检索接口 & Agent over your data。
b.分类2
CrewAI 主打「多角色协作」的 Agent 框架，用 Crew/Flow 编排不同角色的 Agent 完成复杂任务。
AutoGen 微软出的多 Agent 编程框架，支持 Agent 之间对话、工具调用、代码执行、人类在环等。
PocketFlow 一个“极简 LLM 框架”，核心代码只有 100 行，却支持智能体（Agent）、工作流（Workflow）、RAG（检索增强生成）等主流能力
c.分类3
LiteLLM 统一的 LLM API SDK + 代理网关，用 OpenAI 风格调用 100+ 模型 / 提供商，并带路由、重试、限流等。
Ollama 在本机一键跑多种开源模型（Llama、DeepSeek、Gemma 等），提供本地 HTTP API 和 CLI。
NewAPI 基于 One API 的新一代大模型网关 & AI 资产管理系统，统一管理多家模型资源、计费、限额、路由等。
d.分类4
MassGen 允许多个基于不同模型（如GPT、Claude、Gemini）的智能体并行工作、实时分享进展、相互借鉴并最终达成共识，利用集体智慧。
AgentZero 一个能够动态、有机地随用户使用而成长和学习的个性化系统，它强调透明度、可读性、可定制性和交互性，核心理念是将计算机本身作为工具来完成用户任务。
e.分类5
cursor-sdk 开放了官方 TypeScript SDK 公测，把驱动自家编辑器、CLI 和网页版的智能体整套打包交给开发者
Google ADK Go Google 推出的开源 Agent 开发框架，用 Go 代码定义 Agent 逻辑、工具和编排，而不是写一堆 prompt
openai-agents-python OpenAI推出官方Agents SDK，一个轻量级、功能强大的多智能体工作流框架
f.总结
学 LangChain 后越来越清楚：它不是在教你用 LLM，而是在教工程如何驯服不确定性。
Chain / Tool / Agent= 把一次性 prompt 拆成可调试的结构。
LangChain 不是 AI 魔法库，而是 LLM 时代的软件工程补丁包。
01.分类1
a.LangChain
a.基本信息
类型：Python 框架
仓库地址：https://github.com/langchain-ai/langchain
b.核心作用
老牌 LLM 应用框架，提供 prompt、memory、工具调用、RAG、Agent 抽象等。
c.典型使用场景
在 Python 里快速搭建带检索、工具调用、工作流的智能体 / 助手。
b.LangGraph
a.基本信息
类型：Python 框架
生态关系：属于 LangChain 生态，仓库在 langchain-ai org 下
b.核心作用
用「图」（有状态状态机）来编排 Agent，适合多轮推理、分支、回溯的人机/多 Agent 流程。
c.典型使用场景
复杂 Agent 编排（多 Agent、长对话、有流程控制的应用）。
c.LangSmith
a.基本信息
类型：SaaS 平台
地址：https://www.langchain.com/langsmith/observability
b.核心作用
LangChain 官方观测/评估平台，做 tracing、日志、评测、A/B、成本/延迟监控。
c.典型使用场景
调试 & 监控 LangChain/LangGraph 应用，查错、看调用链、做评测。
d.LangServe
a.基本信息
类型：部署组件
仓库地址：https://github.com/langchain-ai/langserve
b.核心作用
把 LangChain 的 Runnable / Chain 一键暴露成 REST API（FastAPI + Pydantic），带 /invoke /batch /stream 等端点。
c.典型使用场景
把本地写好的 chain/agent 以服务形式对外提供（内部服务或公网 API）。
e.LangChain.js
a.基本信息
类型：JS/TS 框架
仓库地址：https://github.com/langchain-ai/langchainjs
b.核心作用
LangChain 的 JavaScript/TypeScript 版本，用于 Node/浏览器环境。
c.典型使用场景
前后端 JS 技术栈里做聊天机器人、RAG 前端、浏览器内 Agent 等。
f.LangChain4j
a.基本信息
类型：Java 框架
仓库地址：https://github.com/langchain4j/langchain4j
b.核心作用
面向 Java 的 LLM 框架，统一封装主流 LLM/向量库 API，内置 RAG、Agent、工具调用等。
c.典型使用场景
Java / Spring 系统中使用 LLM、RAG、工具调用，而不想手撸各云厂商 SDK。
内置向量库，Redis、Elasticsearch、Milvus、PGVector（PostgreSQL）、甚至内存版（适合测试）
g.LlamaIndex
a.基本信息
类型：Python 框架
仓库地址：https://github.com/run-llama/llama_index
b.核心作用
「数据框架」，专注把各种数据源接进来，建索引（向量/图等），提供高级检索接口 & Agent over your data。
c.典型使用场景
以「我的数据」为核心做 RAG（复杂索引、路由、多数据源融合），也可配合 LangChain 使用。
02.分类2
a.CrewAI
a.基本信息
类型：多 Agent 框架
仓库地址：https://github.com/crewAIInc/crewAI
b.核心作用
主打「多角色协作」的 Agent 框架，用 Crew/Flow 编排不同角色的 Agent 完成复杂任务。
c.典型使用场景
产品化多 Agent 工作流（研究 + 写作 + 评审等），强调流程控制和执行效率。
b.AutoGen
a.基本信息
类型：多 Agent 框架
仓库地址：https://github.com/microsoft/autogen
b.核心作用
微软出的多 Agent 编程框架，支持 Agent 之间对话、工具调用、代码执行、人类在环等。
c.典型使用场景
研究/企业侧构建多 Agent 系统（代码生成+执行+自纠错等），也有 AutoGen Studio/Bench 辅助。
c.PocketFlow
a.基本信息
类型：模型压缩框架
文档地址：https://pocketflow.github.io
b.核心作用
开源的深度学习模型压缩 & 加速框架，做剪枝、量化等，提升部署效率。
c.典型使用场景
它号称是一个“极简 LLM 框架”，核心代码只有 100 行，却支持智能体（Agent）、工作流（Workflow）、RAG（检索增强生成）等主流能力。核心思想只有一个：用 Graph 作为唯一抽象，把复杂系统拆解成节点和边的组合。
更有意思的是，它几乎零依赖、零臃肿、零厂商绑定，安装包只有 56KB。对比那些动辄几百 MB 的全家桶框架，PocketFlow 更像是一个“原理级”的骨架，而不是一个替你做完一切的黑盒平台。
它还支持 Agentic Coding 模式，让 AI 智能体参与代码生成与流程编排。从基础聊天机器人，到复杂多智能体协作系统，都有完整示例。
目前已支持 TypeScript、Java、C++、Go、Rust、PHP 多语言版本。
03.分类3
a.LiteLLM
a.基本信息
类型：Python SDK / 网关
仓库地址：https://github.com/BerriAI/litellm
b.核心作用
统一的 LLM API SDK + 代理网关，用 OpenAI 风格调用 100+ 模型 / 提供商，并带路由、重试、限流等。
c.典型使用场景
一个 endpoint 管所有模型，搞多云容灾、按成本/延迟路由、统一鉴权和配额。
b.Ollama
a.基本信息
类型：本地模型服务
仓库地址：https://github.com/ollama/ollama
b.核心作用
在本机一键跑多种开源模型（Llama、DeepSeek、Gemma 等），提供本地 HTTP API 和 CLI。
c.典型使用场景
开发/桌面环境「一条命令跑大模型」，本地 RAG、插件、Agent 的模型后端。
c.NewAPI
a.基本信息
类型：LLM 网关 / 资产管理
资源地址：https://github.com/QuantumNous/new-api 或 https://docs.newapi.pro/en/api/
b.核心作用
基于 One API 的新一代大模型网关 & AI 资产管理系统，统一管理多家模型资源、计费、限额、路由等。
c.典型使用场景
做「统一大模型平台」：整合 OpenAI/DeepSeek/Claude 等，多租户、分组、计费、看板。
04.分类4
a.MassGen
a.简介
MassGen是一个开源的多智能体扩展系统，运行在终端中。它能够自主编排前沿AI模型和智能体，让它们协作、推理并产生高质量结果。
b.核心定位
它不是一个单一的AI模型，而是一个智能体协作的操作系统或编排框架。它通过模拟并行学习小组的模式，让多个不同专长的AI智能体共同解决单一智能体难以处理的复杂、开放性问题。
c.多智能体协同
核心优势。允许多个基于不同模型（如GPT、Claude、Gemini）的智能体并行工作、实时分享进展、相互借鉴并最终达成共识，利用集体智慧。
d.广泛的模型与工具支持
模型：支持 OpenAI (GPT-5系列)、Anthropic (Claude系列)、Google (Gemini)、xAI (Grok)、本地模型 (通过vLLM/LM Studio) 等几乎所有主流API和本地部署模型。
工具：原生支持代码执行、网页搜索；通过 MCP 可无限扩展外部工具（如天气、文件系统、浏览器自动化）。
e.系统化工作流
项目集成：可将现有代码库作为上下文提供给智能体，进行代码审查、文档生成等操作，所有工作文件自动归置于 .massgen/ 目录，保持项目整洁。
规划与执行：支持 --plan （仅规划）、 --plan-and-execute （规划后自动执行）、 --execute-plan （执行已有计划）等多种模式，适合复杂任务分解。
文件操作：智能体拥有独立或共享的工作空间，可安全地进行文件读写。
f.丰富的交互界面
默认TUI：交互式终端界面，实时显示智能体时间线、状态、投票进度和协作过程。
API服务：可作为OpenAI兼容的HTTP服务器 ( massgen serve ) 被其他应用调用。
Python API：提供 litellm 兼容接口和原生异步API，便于集成到自动化流程中。
g.企业级功能
后台工具执行：智能体可以启动长时间运行的任务（如生成图像）并在后台等待，同时继续其他工作。
会话记忆与多轮对话：支持交互式多轮对话，保留上下文。
详尽的日志与调试：所有会话、协调事件、投票结果、工作区快照均被完整记录，便于复现和分析。
b.AgentZero
a.简介
Agent Zero是一个开源的AI智能体框架（GitHub：agent0ai/agent-zero），采用MIT许可证。
它并非预先定义的固定框架，而是一个能动态成长、学习和个性化的系统。
其核心在于强调透明度、可读性、可定制性以及交互性，核心理念是将计算机本身作为工具来完成用户任务。
b.通用型助手
不预设特定任务，作为通用个人助理。具备持久化记忆能力，可记住之前的解决方案和代码，以提升未来任务执行效率。
c.计算机即工具
默认工具仅限于在线搜索、记忆、通信（与用户及其他代理）以及代码或终端执行。它能够自行编写代码、创建所需工具，或者由用户进行扩展。
d.技能系统 (SKILL.md 标准)
采用开放标准的技能系统，技能作为情境化专业知识动态加载，与 Claude Code、Cursor 等多个平台兼容。
e.多智能体协作
采用层级结构，每个代理都有一个上级（首个代理的上级是用户）。代理可以创建下级代理来分解和解决子任务，从而保持各自上下文的清晰与专注。
f.高度可定制与可扩展
框架几乎没有任何硬编码或隐藏部分。所有行为由系统提示词 (prompts/default/agent.system.md) 定义，修改提示词即可彻底改变框架行为。所有提示词模板和默认工具代码均可查看和修改。
1.5 知识库
01.核心技术选型
a.代码向量化方案
方案 优点 缺点
LlamaIndex + CodeBERT 专为代码优化，理解语法结构 需要额外部署模型
LlamaIndex + OpenAI Embeddings 简单易用，效果好 需要API费用，代码理解略弱
LlamaIndex + BGE-M3 多语言支持好，开源免费 需要本地GPU或推理服务
b.向量数据库选择
数据库 适用场景 复杂度
FAISS 本地小规模，快速原型 低
Chroma 本地持久化，易集成 低
Pinecone 云端托管，大规模 中
Weaviate 混合搜索，功能全 高
02.相关信息
a.代码分块策略
┌─────────────────────────────────────────────────────┐
│ 分块策略对比 │
├─────────────────┬───────────────────────────────────┤
│ AST-based │ 按函数/类切分，保持语义完整性 │
│ Sliding Window │ 固定窗口+重叠，简单但可能切断语义 │
│ Semantic │ 基于语义边界，需要额外模型 │
│ Hierarchical │ 多级索引（文件→函数→代码段） │
└─────────────────┴───────────────────────────────────┘
b.推荐实现架构
┌──────────────────────────────────────────────────────────────┐
│ Knowledge Base Pipeline │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Code Files │───▶│ Parser │───▶│ Chunker │ │
│ │ (.py/.ts/.vue)│ │ (AST/Text) │ │ (Smart Split)│ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Query │───▶│ Embedding │◀───│ Embedding │ │
│ │ │ │ Model │ │ Model │ │
│ └─────────────┘ └──────┬──────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Vector DB │───▶│ Retriever │ │
│ │ (Chroma/FAISS)│ │ │ │
│ └─────────────┘ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ LLM Context│ │
│ └─────────────┘ │
└──────────────────────────────────────────────────────────────┘
03.待决策问题
a.嵌入模型选择
1.OpenAI text-embedding-3-small（简单，但有费用）
2.本地部署 BGE-M3（免费，需要资源）
3.智谱 AI embedding-3（与现有 GLM-4.7 生态一致）
b.向量存储方式
1.Chroma 本地文件（推荐，简单持久化）
2.FAISS 内存+定期保存
3.云端 Pinecone
c.索引更新策略
1.手动触发重建
2.Git hook 自动增量更新
3.文件监听实时更新
d.是否需要 GraphRAG
简单 RAG 可能对代码结构理解不足
GraphRAG 可以理解代码依赖关系，但实现复杂
1.6 开源系列
00.汇总
a.LLM推理模型（Ollama 本地）
a.已安装
模型 参数量 大小 特点 状态
qwen2.5:7b 7B 4.7 GB 阿里通用对话 ✅ 已安装
qwen2.5:14b 14B 9.0 GB 阿里通用对话 ✅ 已安装
deepseek-coder:6.7b 6.7B 3.8 GB 代码专用 ✅ 已安装
llama3.1:8b 8B 4.9 GB Meta通用 ✅ 已安装
llama3.2 3B 2.0 GB Meta通用轻量 ✅ 已安装
gemma2:9b 9B 5.4 GB Google通用 ✅ 已安装
mistral:7b 7B 4.4 GB Mistral通用 ✅ 已安装
yi:6b 6B 3.5 GB 零一万物（文件未收录） ✅ 已安装
b.未安装（文件推荐）
模型 参数量 大小 特点 状态
qwen2.5:32b 32B ~20 GB qwen最强本地版 ❌ 未安装
qwen2.5-coder:14b 14B 9 GB 代码专用，优于deepseek ❌ 未安装
deepseek-r1:14b 14B 9 GB 深度推理，思维链 ❌ 未安装
glm4:9b 9B 5.5 GB ChatGLM4，中文优秀 ❌ 未安装
internlm2.5:7b 7B 4.5 GB 上海AI Lab，中文强 ❌ 未安装
phi4:14b 14B 8.9 GB Microsoft，小模型强推理 ❌ 未安装
phi3.5:3.8b 3.8B 2.2 GB Microsoft，极小但强 ❌ 未安装
llama3.3:70b 70B ~40 GB Meta最新70B，需高配 ❌ 未安装
mixtral:8x7b 47B(MoE) 26 GB Mistral混合专家模型 ❌ 未安装
codellama:13b 13B 7.4 GB Meta代码模型 ❌ 未安装
starcoder2:15b 15B 9 GB HuggingFace代码模型 ❌ 未安装
qwq:32b 32B 20 GB 阿里推理，类o1 ❌ 未安装
llava:13b 13B 8 GB 视觉理解经典 ❌ 未安装
llama3.2-vision:11b 11B 7.9 GB Meta视觉最新版 ❌ 未安装
minicpm-v:8b 8B 5.5 GB 中文视觉理解强 ❌ 未安装
moondream2 1.9B 1.7 GB 极轻量视觉模型 ❌ 未安装
b.LLM推理模型（LM Studio）
a.表格数据
模型 类型 状态
qwen3_vl 多模态 ✅ 已安装
qwen35 对话 ✅ 已安装
glm4v 多模态 ✅ 已安装
gemma3 对话 ✅ 已安装
c.文本向量模型
a.已安装（Ollama）
模型 大小 维度 语言优势 特点 状态
bge-m3 1.2 GB 1024 中文最强 BAAI出品，多检索模式 ✅ 已安装
mxbai-embed-large 669 MB 1024 英文顶级 MTEB榜单前列 ✅ 已安装
b.已安装（LM Studio）
模型 大小 维度 语言优势 特点 状态
mxbai-embed-large-v1 670 MB 1024 英文顶级 MTEB榜单前列 ✅ 已安装
nomic-embed-text-v1.5 84 MB 768 英文优秀 轻量，支持长文本 ✅ 已安装
all-minilm-l6-v2 25 MB 384 英文 极轻量，速度极快 ✅ 已安装
c.未安装（文件推荐）
模型 大小 维度 语言优势 特点 状态
snowflake-arctic-embed 670 MB 1024 英文 企业级，生产环境 ❌ 未安装
bge-large 1.2 GB 1024 中英文 BGE英文版 ❌ 未安装
gte-qwen2-1.5b 1.2 GB 1536 中英文 阿里GTE，高维度 ❌ 未安装
d.语音识别（ASR）
a.已安装
工具 中文效果 速度 特点 状态
Whisper.cpp ⭐⭐⭐⭐ 快 Metal加速，brew安装 ✅ 已安装
b.未安装（文件推荐）
工具 中文效果 速度 特点 状态
FunASR ⭐⭐⭐⭐⭐ 快 阿里达摩院，中文最强 ❌ 未安装（推荐）
SenseVoice ⭐⭐⭐⭐⭐ 极快 阿里音视频，多语言 ❌ 未安装（推荐）
Paraformer ⭐⭐⭐⭐⭐ 极快 阿里，非自回归，极速 ❌ 未安装（推荐）
Vosk ⭐⭐⭐ 极快 离线，资源占用少 ❌ 未安装（可选）
e.语音合成（TTS）
a.已安装
工具 音质 中文 速度 特点 状态
Piper TTS ⭐⭐⭐ ⭐⭐⭐ 极快 轻量，离线，brew安装 ✅ 已安装
macOS Say ⭐⭐⭐ ⭐⭐⭐ 极快 系统自带，零安装 ✅ 系统自带
b.未安装（文件推荐）
工具 音质 中文 速度 特点 状态
CosyVoice2 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 中 阿里达摩院，零样本克隆 ❌ 未安装（强烈推荐）
ChatTTS ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 中 对话场景，中文自然 ❌ 未安装（强烈推荐）
F5-TTS ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 中 流式，音色克隆，开源最强 ❌ 未安装（推荐）
Fish Speech ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 快 中英文双语，音色克隆 ❌ 未安装（推荐）
EmotiVoice ⭐⭐⭐⭐ ⭐⭐⭐⭐ 中 网易出品，情感控制 ❌ 未安装（推荐）
c.社区推荐
Qwen3-TTS
f.向量数据库
a.已安装
数据库 类型 部署 规模 特点 状态
Milvus 专用向量库 本地Docker 超大规模 企业级分布式 ✅ 已安装
Qdrant 专用向量库 本地Docker 中大规模 Rust高性能 ✅ 已安装
Chroma 专用向量库 本地pip 小中规模 Python原生，开发首选 ✅ 已安装
FAISS 向量索引库 本地brew 内存内 Meta，算法丰富 ✅ 已安装
pgvector PG扩展 本地brew 中等规模 混合查询 ✅ 已安装
b.未安装（文件推荐）
数据库 类型 部署 规模 特点 状态
LanceDB 专用向量库 本地pip 小中规模 列式存储，轻量 ❌ 未安装（推荐）
Weaviate 专用向量库 Docker/云 大规模 图谱+向量，GraphQL ❌ 未安装（可选）
g.OCR工具
a.已安装
工具 中文效果 速度 特点 状态
PaddleOCR ⭐⭐⭐⭐⭐ 快 百度出品，中文最强 ✅ 已安装
Tesseract ⭐⭐⭐ 中 Google维护，老牌 ✅ 已安装
RapidOCR ⭐⭐⭐⭐ 极快 PaddleOCR轻量版 ✅ 已安装
EasyOCR ⭐⭐⭐⭐ 慢 PyTorch，多语言 ✅ 已安装
Unstructured ⭐⭐⭐ 中 文档解析+OCR ✅ 已安装
b.未安装（文件推荐）
工具 中文效果 速度 特点 状态
GOT-OCR2.0 ⭐⭐⭐⭐⭐ 中 端到端，公式+表格 ❌ 未安装（强烈推荐）
Marker ⭐⭐⭐⭐ 中 PDF转Markdown ❌ 未安装（推荐）
Docling ⭐⭐⭐⭐ 中 IBM，多格式文档 ❌ 未安装（推荐）
Surya ⭐⭐⭐ 中 版面分析+多语言 ❌ 未安装（推荐）
TrOCR ⭐⭐⭐ 中 微软Transformer OCR ❌ 未安装（推荐）
c.其他
glm-ocr
Chandra OCR 2：能保留结构的开源OCR模型
01.LLM推理模型
a.部署平台
a.说明1
平台 特点 macOS 支持
vLLM 高性能推理引擎，适合生产环境 ✅ 可用 (pip 安装)
llama.cpp 轻量级 C++ 实现，Ollama 的底层 ✅ brew install llama.cpp
LocalAI OpenAI API 兼容的本地部署 ✅ brew install localai
Jan 类似 LM Studio 的 GUI 应用 ✅ brew install --cask jan
GPT4All 另一个 GUI 本地推理工具 ✅ brew install --cask gpt4all
Text Generation WebUI 功能丰富的 Web 界面 ✅ pip/conda 安装
b.说明2
框架 简介
Ollama 最流行的本地推理工具，底层用 llama.cpp
vLLM 伯克利开发，生产级高吞吐推理引擎
LM Studio 桌面 GUI 应用，底层 llama.cpp
LMDeploy 商汤科技开发，NVIDIA GPU 专用加速
TGI HuggingFace 推理容器
llama.cpp 底层 C++ 库，CPU/GPU 通用
b.本地开源模型
a.中文方向
a.表格数据
模型 参数量 大小 特点 ollama拉取命令
qwen2.5:32b 32B ~20GB qwen最强本地版 ollama pull qwen2.5:32b
qwen2.5-coder:14b 14B 9GB 代码专用，优于deepseek ollama pull qwen2.5-coder:14b
deepseek-r1:14b 14B 9GB 深度推理，思维链 ollama pull deepseek-r1:14b
deepseek-v3 685B 需量化 DeepSeek旗舰，媲美GPT-4 需服务器
glm4:9b 9B 5.5GB 智谱ChatGLM4，中文优秀 ollama pull glm4
internlm2.5:7b 7B 4.5GB 上海AI Lab，中文强 ollama pull internlm2
b.英文/代码方向
a.表格数据
模型 参数量 大小 特点 ollama拉取命令
phi4:14b 14B 8.9GB Microsoft，小模型强推理 ollama pull phi4
phi3.5:3.8b 3.8B 2.2GB Microsoft，极小但强 ollama pull phi3.5
llama3.3:70b 70B ~40GB Meta最新70B，需要高配 ollama pull llama3.3:70b
mixtral:8x7b 47B(MoE) 26GB Mistral混合专家模型 ollama pull mixtral
codellama:13b 13B 7.4GB Meta代码模型 ollama pull codellama:13b
starcoder2:15b 15B 9GB HuggingFace代码模型 ollama pull starcoder2:15b
qwq:32b 32B 20GB 阿里推理模型，类o1 ollama pull qwq:32b
c.多模态方向
a.表格数据
模型 参数量 大小 特点 ollama拉取命令
llava:13b 13B 8GB 视觉理解经典 ollama pull llava:13b
llama3.2-vision:11b 11B 7.9GB Meta视觉最新版 ollama pull llama3.2-vision:11b
minicpm-v:8b 8B 5.5GB 中文视觉理解强 ollama pull minicpm-v
moondream2 1.9B 1.7GB 极轻量视觉模型 ollama pull moondream
b.说明
---
c.商业闭源模型（云端API）
a.国际主流
a.表格数据
提供商 模型 上下文 中文 代码 定价（输入/M tokens）
OpenAI GPT-4o 128K ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ $5
OpenAI GPT-4o-mini 128K ⭐⭐⭐⭐ ⭐⭐⭐⭐ $0.15
OpenAI o1 200K ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ $15 (推理)
OpenAI o3-mini 200K ⭐⭐⭐ ⭐⭐⭐⭐⭐ $1.1
Anthropic Claude Opus 4.6 200K ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ $15
Anthropic Claude Sonnet 4.6 200K ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ $3
Anthropic Claude Haiku 4.5 200K ⭐⭐⭐ ⭐⭐⭐⭐ $0.25
Google Gemini 2.0 Flash 1M ⭐⭐⭐⭐ ⭐⭐⭐⭐ $0.1
Google Gemini 1.5 Pro 2M ⭐⭐⭐⭐ ⭐⭐⭐⭐ $3.5
b.国内主流（中文优化，价格更低）
a.表格数据
提供商 模型 中文 特点 定价（输入/M tokens）
阿里云 Qwen-Max ⭐⭐⭐⭐⭐ 中文最强商用 ¥40
阿里云 Qwen-Plus ⭐⭐⭐⭐⭐ 均衡，有免费额度 ¥4
DeepSeek DeepSeek-V3 ⭐⭐⭐⭐⭐ 价格极低，推理强 ¥2
DeepSeek DeepSeek-R1 ⭐⭐⭐⭐ 强推理（类o1） ¥4
智谱AI GLM-4-Plus ⭐⭐⭐⭐⭐ 中文均衡 ¥50
月之暗面 Moonshot-v1-128k ⭐⭐⭐⭐ 超长上下文 ¥60
百度 ERNIE-4.0 ⭐⭐⭐⭐ 百度生态整合 ¥120
腾讯 Hunyuan-Pro ⭐⭐⭐⭐ 腾讯生态 ¥100
字节 Doubao-Pro ⭐⭐⭐⭐ 字节生态，价格低 ¥5
b.说明
---
d.专业领域模型
a.代码专用模型对比
a.表格数据
模型 类型 代码能力 上下文 说明
DeepSeek-Coder-V2 本地/云 ⭐⭐⭐⭐⭐ 128K 代码最强开源
Qwen2.5-Coder:32b 本地 ⭐⭐⭐⭐⭐ 128K 阿里代码旗舰
CodeLlama:70b 本地 ⭐⭐⭐⭐ 100K Meta代码大模型
StarCoder2:15b 本地 ⭐⭐⭐⭐ 16K HF开源代码模型
GitHub Copilot 云端 ⭐⭐⭐⭐⭐ - IDE集成，订阅制
Cursor 云端 ⭐⭐⭐⭐⭐ - AI编辑器，订阅制
b.推理/数学专用
a.表格数据
模型 特点
DeepSeek-R1（本地/API） 思维链推理，解题步骤清晰
QwQ:32b（本地） 阿里推理模型，中文数学强
OpenAI o1/o3（API） 复杂推理最强，但价格贵
Google Gemini 2.0 Flash Thinking 免费额度，推理能力强
b.说明
---
e.模型规格速查（按硬件选择）
a.表格数据
可用内存 本地可运行的最大模型 推荐组合
8 GB 7B（Q4量化） qwen2.5:7b + llama3.2
16 GB 14B（Q4量化）或 7B（FP16） qwen2.5:14b + deepseek-coder:6.7b
32 GB 32B（Q4量化）或 14B（FP16） qwen2.5:32b + qwq:32b
64 GB 70B（Q4量化） llama3.3:70b + deepseek-r1:32b
128 GB+ 超大模型 / MoE模型 mixtral:8x22b
b.说明
---
f.量化格式说明
a.表格数据
格式 精度损失 内存占用 速度 推荐场景
FP32 无 极大（4x） 最慢 训练
FP16 极小 大（2x） 慢 高质量推理
Q8_0 很小 1x 中 质量优先
Q4_K_M 小 0.5x 快 推荐日常使用
Q4_0 较小 0.5x 最快 速度优先
Q2_K 较大 0.25x 极快 内存极度受限
b.说明
---
02.文本向量模型
a.本地开源模型（Ollama 可拉取）
a.表格数据
模型 大小 维度 语言优势 特点 安装命令
bge-m3 1.2 GB 1024 中文最强 BAAI出品，多检索模式 ✅ 已安装
mxbai-embed-large 669 MB 1024 英文顶级 MTEB榜单前列 ✅ 已安装
nomic-embed-text 274 MB 768 英文优秀 轻量，支持长文本 ollama pull nomic-embed-text
all-minilm 45 MB 384 英文 极轻量，速度极快 ollama pull all-minilm
snowflake-arctic-embed 670 MB 1024 英文 企业级，生产环境 ollama pull snowflake-arctic-embed
bge-large 1.2 GB 1024 中英文 BGE英文版 ollama pull bge-large
gte-qwen2-1.5b 1.2 GB 1536 中英文 阿里GTE，高维度 ollama pull gte-qwen2:1.5b
b.说明
---
b.本地开源模型（HuggingFace，需 Python 调用）
a.BGE 系列（BAAI 出品，中文最强）
a.表格数据
模型 维度 特点
BAAI/bge-m3 1024 多语言，多检索模式（稠密+稀疏+ColBERT）
BAAI/bge-large-zh-v1.5 1024 中文专用，榜单第一
BAAI/bge-small-zh-v1.5 512 中文轻量版
BAAI/bge-reranker-v2-m3 - 重排序模型（配合检索使用）
b.GTE 系列（阿里 Tongyi 出品）
a.表格数据
模型 维度 特点
Alibaba-NLP/gte-Qwen2-1.5B-instruct 1536 中英文均衡，高维度
Alibaba-NLP/gte-large-en-v1.5 1024 英文优秀
Alibaba-NLP/gte-multilingual-base 768 多语言轻量
c.E5 系列（Microsoft 出品）
a.表格数据
模型 维度 特点
intfloat/multilingual-e5-large 1024 多语言，企业级
intfloat/e5-mistral-7b-instruct 4096 基于 Mistral，高质量
intfloat/e5-large-v2 1024 英文经典
d.Sentence-Transformers 系列
a.表格数据
模型 维度 特点
all-MiniLM-L6-v2 384 极轻量，速度快，英文
paraphrase-multilingual-MiniLM-L12-v2 384 多语言轻量
paraphrase-multilingual-mpnet-base-v2 768 多语言均衡
e.Instructor 系列（指令式向量）
a.表格数据
模型 特点
hkunlp/instructor-xl 支持任务指令，灵活性强
hkunlp/instructor-large 中等大小，均衡
b.说明
---
c.云端 API Embedding 服务
a.国际服务
a.表格数据
服务 模型 维度 价格（/M tokens） 特点
OpenAI text-embedding-3-small 1536 $0.02 性价比最高
OpenAI text-embedding-3-large 3072 $0.13 精度最高
OpenAI text-embedding-ada-002 1536 $0.10 旧版，稳定
Cohere embed-v3.0 1024 $0.10 多语言优秀
Voyage AI voyage-3 1024 $0.06 RAG专优化
Voyage AI voyage-code-3 1024 $0.18 代码专用
Jina AI jina-embeddings-v3 1024 免费额度 多语言，长文本
b.国内服务
a.表格数据
服务 提供商 维度 特点
text-embedding-v3 阿里云 1024/2048 中文最强商业
Embedding-V1 百度 384 免费额度
embedding-2 智谱AI 1024 中文均衡
moonshot-v1 月之暗面 - 文档检索优化
b.代码示例
---
# OpenAI Embedding 调用示例
from openai import OpenAI
client = OpenAI(api_key="sk-...")
response = client.embeddings.create(
model="text-embedding-3-small",
input="这是一段测试文本"
)
embedding = response.data[0].embedding
# 阿里云通义向量（兼容OpenAI格式）
from openai import OpenAI
aliyun_client = OpenAI(
api_key="sk-...",
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)
response = aliyun_client.embeddings.create(
model="text-embedding-v3",
input="这是一段测试文本"
)
---
c.说明
---
d.多模态向量模型（图文跨模态）
a.表格数据
模型 类型 特点 使用场景
CLIP (OpenAI) 图文 图文向量对齐，以图搜图 图像搜索
BLIP-2 图文 图文理解+向量 多模态RAG
ImageBind (Meta) 六模态 图/文/音/视频对齐 多媒体搜索
Chinese-CLIP 图文中文 CLIP中文优化版 中文图像搜索
Jina CLIP v2 图文 多语言，API可用 通用多模态
b.代码示例
---
# 安装 CLIP
pip install git+https://github.com/openai/CLIP.git
pip install torch torchvision
---
c.说明
---
e.专业领域向量模型
a.表格数据
领域 模型 说明
代码 microsoft/codebert-base 代码语义理解
代码 Salesforce/codet5-base 代码向量
医疗 allenai/scibert_scivocab_uncased 医学文献检索
法律 nlpaueb/legal-bert-base-uncased 法律文档
金融 ProsusAI/finbert 金融情感分析
中文法律 thunlp/LegalBERT-zh 中文法律
b.说明
---
f.向量模型选型决策表
a.表格数据
场景 首选 备选 理由
中文RAG，完全本地 bge-m3 gte-qwen2 中文最强，Ollama支持
英文RAG，完全本地 mxbai-embed-large nomic-embed-text 英文MTEB前列
多语言，本地 bge-m3 multilingual-e5-large 100+语言支持
生产环境，高精度 text-embedding-3-large Cohere embed-v3 云端最强，维度高
生产环境，性价比 text-embedding-3-small Voyage voyage-3 低成本高质量
资源极度受限 all-minilm paraphrase-multilingual-MiniLM 45MB，速度快
代码搜索 voyage-code-3 codebert 代码专用优化
图文搜索 CLIP Chinese-CLIP（中文） 图文对齐
b.说明
---
g.关键技术：重排序（Reranking）
a.说明
单纯向量检索精度有限，可配合重排序模型提升准确率：
b.表格数据
模型 特点 安装
BAAI/bge-reranker-v2-m3 中文最强重排序 pip install FlagEmbedding
cross-encoder/ms-marco-MiniLM-L-12-v2 英文经典 pip install sentence-transformers
Cohere rerank-v3.5 云端API，效果最好 API调用
Jina reranker-v2 多语言，有免费额度 API调用
c.代码示例
---
# 重排序示例（RAG二阶段检索）
from FlagEmbedding import FlagReranker
reranker = FlagReranker('BAAI/bge-reranker-v2-m3', use_fp16=True)
# 第一阶段：向量召回20个候选
# 第二阶段：重排序取top-3
scores = reranker.compute_score([
[query, candidate_1],
[query, candidate_2],
# ...
])
---
d.说明
---
03.语音识别（ASR）
a.本地开源 ASR 工具
a.表格数据
工具 语言 中文效果 速度 特点 状态
Whisper.cpp C++ ⭐⭐⭐⭐ 快 Metal加速，brew安装 ✅ 已安装
OpenAI Whisper (Python) Python ⭐⭐⭐⭐ 中 原版，PyTorch 可选
FunASR Python ⭐⭐⭐⭐⭐ 快 阿里达摩院，中文最强 推荐
SenseVoice Python ⭐⭐⭐⭐⭐ 极快 阿里音视频，多语言 推荐
Vosk Python/多语言 ⭐⭐⭐ 极快 离线，资源占用少 可选
Wav2Vec2 Python ⭐⭐⭐ 中 Meta，需微调 研究用
DeepSpeech Python ⭐⭐ 中 Mozilla，英文为主 较旧
Paraformer Python ⭐⭐⭐⭐⭐ 极快 阿里Paraformer，非自回归 推荐
b.FunASR（中文效果最强，推荐）
a.代码示例
---
pip install funasr
# 使用 SenseVoiceSmall 模型（多语言，速度快）
---
b.代码示例
---
from funasr import AutoModel
model = AutoModel(model="iic/SenseVoiceSmall")
result = model.generate(input="audio.wav", language="auto")
print(result[0]["text"])
---
c.Vosk（极轻量，离线，适合嵌入）
a.代码示例
---
pip install vosk
# 下载中文模型 (40MB)
wget https://alphacephei.com/vosk/models/vosk-model-small-cn-0.22.zip
---
b.说明
略
b.macOS 系统自带 TTS
a.说明
无需安装，直接使用：
b.代码示例
---
# 使用系统语音
say "你好，这是系统语音"
# 查看可用语音
say -v ?
# 指定中文语音
say -v Ting-Ting "你好世界"
# 保存为音频文件
say -v Ting-Ting "你好世界" -o output.aiff
---
c.云端 ASR 服务
a.表格数据
服务 提供商 中文效果 价格 特点
Whisper API OpenAI ⭐⭐⭐⭐ $0.006/min 简单易用
Speech-to-Text Google Cloud ⭐⭐⭐⭐ $0.024/min 实时流式支持
Speech Service Azure ⭐⭐⭐⭐ $1/hour 企业级SLA
Transcribe AWS ⭐⭐⭐ $0.024/min AWS生态
语音识别 科大讯飞 ⭐⭐⭐⭐⭐ 按量 中文最强商业版
语音识别 百度云 ⭐⭐⭐⭐ 有免费额度 中文优秀
语音识别 阿里云 ⭐⭐⭐⭐ 有免费额度 与FunASR同源
语音识别 腾讯云 ⭐⭐⭐⭐ 有免费额度 中文均衡
b.说明
略
04.语音合成（TTS）
a.本地开源 TTS 工具
a.表格数据
工具 音质 中文 速度 特点 状态
Piper TTS ⭐⭐⭐ ⭐⭐⭐ 极快 轻量，离线，brew安装 ✅ 已安装
macOS Say ⭐⭐⭐ ⭐⭐⭐ 极快 系统自带，零安装 ✅ 系统自带
CosyVoice2 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 中 阿里达摩院，零样本克隆 强烈推荐
ChatTTS ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 中 对话场景优化，中文自然 强烈推荐
F5-TTS ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 中 流式，音色克隆，开源最强 推荐
Fish Speech ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 快 中英文双语，音色克隆 推荐
Coqui TTS ⭐⭐⭐⭐ ⭐⭐⭐ 中 多语言，可定制 可选
Bark ⭐⭐⭐⭐ ⭐⭐ 慢 情感丰富，支持非语言音 实验性
VITS2 ⭐⭐⭐⭐ ⭐⭐⭐⭐ 快 高自然度，需训练 进阶
TortoiseTTS ⭐⭐⭐⭐⭐ ⭐⭐ 极慢 音质极佳，英文 追求极致
EmotiVoice ⭐⭐⭐⭐ ⭐⭐⭐⭐ 中 网易出品，情感控制 推荐
b.CosyVoice2（中文 TTS 开源最强，强烈推荐）
a.代码示例
---
pip install cosyvoice
# 支持：零样本克隆、指令控制情感、流式合成
---
b.代码示例
---
from cosyvoice.cli.cosyvoice import CosyVoice2
from cosyvoice.utils.file_utils import load_wav
cosyvoice = CosyVoice2('pretrained_models/CosyVoice2-0.5B')
# 零样本音色克隆
for i, j in cosyvoice.inference_zero_shot(
'这是一段需要合成的文字',
'这是参考音频的文字',
load_wav('reference_audio.wav', 16000),
stream=False
):
torchaudio.save('output.wav', j['tts_speech'], cosyvoice.sample_rate)
---
c.ChatTTS（对话场景，中文最自然）
a.代码示例
---
pip install chattts
---
b.代码示例
---
import ChatTTS
import torch
import torchaudio
chat = ChatTTS.Chat()
chat.load(compile=False)
texts = ["你好，这是ChatTTS合成的语音。"]
wavs = chat.infer(texts)
torchaudio.save("output.wav", torch.from_numpy(wavs[0]), 24000)
---
c.说明
略
b.云端 TTS 服务
a.表格数据
服务 提供商 中文效果 价格 特点
TTS-1 / TTS-1-HD OpenAI ⭐⭐⭐ $15/M chars 6种声音，简单易用
Neural TTS Azure ⭐⭐⭐⭐⭐ $16/M chars 500+声音，SSML支持
Text-to-Speech Google Cloud ⭐⭐⭐⭐ $16/M chars WaveNet质量高
Polly AWS ⭐⭐⭐ $4/M chars AWS生态，价格低
ElevenLabs ElevenLabs ⭐⭐⭐⭐⭐ 订阅制 音质最佳，克隆声音
语音合成 科大讯飞 ⭐⭐⭐⭐⭐ 按量 中文最强商业
语音合成 阿里云 ⭐⭐⭐⭐ 有免费额度 中文自然
语音合成 百度云 ⭐⭐⭐⭐ 有免费额度 中文均衡
语音合成 腾讯云 ⭐⭐⭐⭐ 有免费额度 中文均衡
b.说明
略
c.工具选型决策表
a.ASR 选型
a.表格数据
场景 推荐工具 理由
中文识别，本地高质量 FunASR / SenseVoice 阿里出品，中文最强
多语言，本地 Whisper.cpp（已安装） 99种语言，Metal加速
嵌入应用，极轻量 Vosk 40MB模型，实时
生产服务，中文 科大讯飞 / 阿里云 商业SLA，精度高
生产服务，多语言 Azure Speech / Google 完善API
b.TTS 选型
a.表格数据
场景 推荐工具 理由
中文对话，自然度高 CosyVoice2 / ChatTTS 中文最自然
音色克隆 F5-TTS / CosyVoice2 零样本克隆
快速离线，零依赖 Piper（已安装）/ macOS Say 轻量，本地
生产环境，音质最佳 ElevenLabs / Azure TTS 商业最强
生产环境，中文 科大讯飞 / 阿里云 中文商业最强
b.说明
略
05.向量数据库
a.完整生态一览
a.表格数据
数据库 类型 部署 规模 特点 状态
Milvus 专用向量库 本地Docker 超大规模 企业级分布式 ✅ 已安装
Qdrant 专用向量库 本地Docker 中大规模 Rust高性能 ✅ 已安装
Chroma 专用向量库 本地pip 小中规模 Python原生，开发首选 ✅ 已安装
FAISS 向量索引库 本地brew 内存内 Meta，算法丰富 ✅ 已安装
pgvector PG扩展 本地brew 中等规模 混合查询 ✅ 已安装
Weaviate 专用向量库 Docker/云 大规模 图谱+向量，GraphQL 可选
LanceDB 专用向量库 本地pip 小中规模 列式存储，轻量 推荐
Marqo 专用向量库 Docker 中等 内置Embedding 可选
Vespa 搜索引擎 Docker 超大规模 混合搜索，企业级 可选
Pinecone 云托管 SaaS 无限 全托管，零维护 云端选项
Zilliz Cloud 云托管 SaaS 无限 Milvus托管版 云端选项
Weaviate Cloud 云托管 SaaS 无限 Weaviate托管版 云端选项
Qdrant Cloud 云托管 SaaS 无限 Qdrant托管版 云端选项
b.说明
---
b.新兴推荐：LanceDB
a.说明
定位：轻量级、列式存储向量数据库，开发体验极佳
b.表格数据
属性 值
开源 ✅ Apache 2.0
存储格式 Lance（列式，类Parquet）
安装 pip install lancedb
特点 无需单独服务，嵌入式
c.说明
为什么推荐：
d.代码示例
---
pip install lancedb
---
e.代码示例
---
import lancedb
import ollama
# 连接（无需启动服务）
db = lancedb.connect("./lancedb")
# 创建表
table = db.create_table("documents", data=[
{"text": "人工智能简介", "vector": ollama.embeddings(model="bge-m3", prompt="人工智能简介")["embedding"]},
{"text": "机器学习基础", "vector": ollama.embeddings(model="bge-m3", prompt="机器学习基础")["embedding"]},
])
# 搜索
query = ollama.embeddings(model="bge-m3", prompt="什么是AI")["embedding"]
results = table.search(query).limit(3).to_pandas()
print(results)
---
f.说明
---
g.比 Chroma 快 10x（列式存储）
h.比 FAISS 更易用（持久化+过滤）
i.支持多模态（图文混合存储）
j.与 Arrow/Pandas 无缝集成
c.新兴推荐：Weaviate
a.说明
定位：知识图谱 + 向量数据库，支持 GraphQL
b.表格数据
属性 值
开源 ✅ BSD
部署 Docker / Weaviate Cloud
特点 内置向量化、知识图谱、GraphQL
c.代码示例
---
# Docker 部署
docker run -d -p 8080:8080 -p 50051:50051 \
-e AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED=true \
cr.weaviate.io/semitechnologies/weaviate:latest
pip install weaviate-client
---
d.代码示例
---
import weaviate
client = weaviate.connect_to_local()
# 创建集合
collection = client.collections.create(
name="Documents",
vectorizer_config=weaviate.classes.config.Configure.Vectorizer.none()
)
# 插入（自定义向量）
collection.data.insert(
properties={"text": "文档内容"},
vector=[0.1, 0.2, ...]
)
# 图谱查询（Weaviate特色）
result = collection.query.near_text(query="AI技术", limit=5)
---
e.说明
---
d.传统数据库的向量扩展
a.Elasticsearch / OpenSearch
a.表格数据
特性 值
向量字段 dense_vector
检索算法 HNSW
混合搜索 ✅ 向量 + 全文 + 过滤
优势 已有ES/OS的项目，无需新增组件
b.代码示例
---
# 已有 Elasticsearch 的项目直接添加向量
pip install elasticsearch
---
c.代码示例
---
from elasticsearch import Elasticsearch
es = Elasticsearch("http://localhost:9200")
# 创建索引
es.indices.create(index="docs", body={
"mappings": {
"properties": {
"text": {"type": "text"},
"embedding": {
"type": "dense_vector",
"dims": 1024,
"index": True,
"similarity": "cosine"
}
}
}
})
# 向量搜索
es.search(index="docs", body={
"knn": {
"field": "embedding",
"query_vector": query_embedding,
"k": 10,
"num_candidates": 100
}
})
---
b.Redis Vector Similarity Search
a.代码示例
---
# Redis Stack 包含向量搜索
docker run -d -p 6379:6379 redis/redis-stack
pip install redis
---
b.代码示例
---
from redis import Redis
from redis.commands.search.field import VectorField, TextField
from redis.commands.search.indexDefinition import IndexDefinition
r = Redis(host='localhost', port=6379)
# 创建向量索引
r.ft("idx").create_index([
VectorField("embedding", "HNSW", {"DIM": 1024, "DISTANCE_METRIC": "COSINE"}),
TextField("text")
], definition=IndexDefinition(prefix=["doc:"]))
---
c.MongoDB Atlas Vector Search
a.代码示例
---
pip install pymongo
---
b.代码示例
---
from pymongo import MongoClient
client = MongoClient("mongodb://localhost:27017")
collection = client.mydb.documents
# 向量检索（需要 Atlas，本地 MongoDB 不支持）
results = collection.aggregate([{
"$vectorSearch": {
"index": "vector_index",
"path": "embedding",
"queryVector": query_embedding,
"numCandidates": 100,
"limit": 10
}
}])
---
c.说明
---
e.云端托管向量数据库
a.表格数据
服务 底层 免费层 特点 适合
Pinecone 自研 1个索引，100万向量 最成熟，文档完善 生产首选
Zilliz Cloud Milvus 有 Milvus全托管 已用Milvus迁移
Weaviate Cloud Weaviate 有 图谱+向量 知识图谱场景
Qdrant Cloud Qdrant 1GB Qdrant全托管 已用Qdrant迁移
Supabase pgvector 有 PostgreSQL托管 全栈应用
Neon pgvector 有 Serverless PostgreSQL Serverless场景
Upstash Vector 自研 有 Serverless，按需付费 低流量应用
b.代码示例
---
# Pinecone 示例
from pinecone import Pinecone
pc = Pinecone(api_key="...")
index = pc.Index("my-index")
# 插入
index.upsert(vectors=[
("doc1", [0.1, 0.2, ...], {"text": "文档内容"})
])
# 查询
results = index.query(vector=query_embedding, top_k=10, include_metadata=True)
---
c.说明
略
f.专用场景工具
a.txtai（轻量全功能 AI 框架）
a.代码示例
---
pip install txtai
---
b.代码示例
---
from txtai import Embeddings
# 一行代码创建语义搜索
embeddings = Embeddings(path="BAAI/bge-m3")
embeddings.index([("doc1", "人工智能简介", None), ("doc2", "机器学习基础", None)])
# 搜索
results = embeddings.search("什么是AI", 3)
---
c.说明
略
g.选型决策
a.表格数据
阶段 推荐方案 说明
快速原型 Chroma（已安装）/ LanceDB 零配置，Python原生
小规模生产 Qdrant（已安装）/ LanceDB 稳定，高性能
大规模生产 Milvus（已安装）/ Pinecone 分布式，无限扩展
已有PostgreSQL pgvector（已安装） 无需新增组件
知识图谱+向量 Weaviate GraphQL查询，图谱关系
全文+向量混合 Elasticsearch / Weaviate 混合检索
Serverless Pinecone / Upstash 按需付费，零维护
b.说明
略
06.OCR工具
a.完整工具清单
a.表格数据
工具 类型 中文 速度 特点 状态
PaddleOCR 本地开源 ⭐⭐⭐⭐⭐ 快 百度出品，中文最强 ✅ 已安装
Tesseract 本地开源 ⭐⭐⭐ 中 Google维护，老牌 ✅ 已安装
RapidOCR 本地开源 ⭐⭐⭐⭐ 极快 PaddleOCR轻量版 ✅ 已安装
EasyOCR 本地开源 ⭐⭐⭐⭐ 慢 PyTorch，多语言 ✅ 已安装
Unstructured 本地开源 ⭐⭐⭐ 中 文档解析+OCR ✅ 已安装
TrOCR 本地开源 ⭐⭐⭐ 中 微软Transformer OCR 推荐
GOT-OCR2.0 本地开源 ⭐⭐⭐⭐⭐ 中 端到端，公式+表格 强烈推荐
Surya 本地开源 ⭐⭐⭐ 中 版面分析+多语言 推荐
Marker 本地开源 ⭐⭐⭐⭐ 中 PDF转Markdown 推荐
Docling 本地开源 ⭐⭐⭐⭐ 中 IBM，多格式文档 推荐
Google Vision API 云端 ⭐⭐⭐⭐ 极快 准确率高 云端选项
Azure Computer Vision 云端 ⭐⭐⭐⭐⭐ 极快 文档智能专业版 云端选项
AWS Textract 云端 ⭐⭐⭐ 极快 表格/表单提取 云端选项
百度OCR 云端 ⭐⭐⭐⭐⭐ 极快 中文最强商业版 云端选项
腾讯OCR 云端 ⭐⭐⭐⭐⭐ 极快 中文均衡 云端选项
阿里OCR 云端 ⭐⭐⭐⭐⭐ 极快 中文均衡 云端选项
b.说明
---
b.新兴推荐：GOT-OCR2.0（强烈推荐）
a.说明
定位：新一代端到端 OCR，支持公式、表格、代码，效果远超传统 OCR
b.表格数据
属性 值
开源 ✅
模型大小 ~580MB
特点 端到端，无需后处理
支持 文字/公式/表格/代码/图表
c.代码示例
---
pip install transformers torch
# 模型自动从 HuggingFace 下载
---
d.代码示例
---
from transformers import AutoModel, AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained('ucaslcl/GOT-OCR2_0', trust_remote_code=True)
model = AutoModel.from_pretrained('ucaslcl/GOT-OCR2_0', trust_remote_code=True, device_map='cpu')
model = model.eval()
# 普通OCR
result = model.chat(tokenizer, 'image.jpg', ocr_type='ocr')
# 格式化输出（保留公式/表格格式）
result = model.chat(tokenizer, 'image.jpg', ocr_type='format')
# 数学公式识别
result = model.chat(tokenizer, 'math.jpg', ocr_type='format', render=True)
---
e.说明
---
c.新兴推荐：Marker（PDF → Markdown）
a.说明
定位：将 PDF/文档高质量转换为 Markdown，专为 RAG 场景优化
b.表格数据
属性 值
开源 ✅
安装 pip install marker-pdf
特点 保留格式、表格、公式
输出 Markdown / JSON
c.代码示例
---
pip install marker-pdf
marker_single input.pdf output.md --langs Chinese,English
---
d.说明
---
d.新兴推荐：Docling（IBM 出品）
a.说明
定位：企业级文档解析，支持 PDF/DOCX/PPTX/HTML 等多格式
b.表格数据
属性 值
开源 ✅ MIT
安装 pip install docling
特点 版面分析、表格提取、公式识别
c.代码示例
---
pip install docling
---
d.代码示例
---
from docling.document_converter import DocumentConverter
converter = DocumentConverter()
result = converter.convert("document.pdf")
# 导出 Markdown（适合RAG）
print(result.document.export_to_markdown())
# 导出 JSON
print(result.document.export_to_dict())
---
e.说明
---
e.云端 OCR 服务对比
a.国际云端服务
a.表格数据
服务 中文 表格 手写 价格（/1000页） API
Azure Document Intelligence ⭐⭐⭐⭐⭐ ✅ ✅ $1.5 REST
Google Document AI ⭐⭐⭐⭐ ✅ ✅ $1.5 REST
AWS Textract ⭐⭐⭐ ✅ ❌ $1.5 REST
OpenAI GPT-4o（视觉） ⭐⭐⭐⭐ ⭐⭐⭐ ✅ 按token REST
b.国内云端服务
a.表格数据
服务 提供商 中文 免费额度 特色功能
通用文字识别 百度OCR ⭐⭐⭐⭐⭐ 1000次/天 手写、印章、混合
高精度版OCR 百度OCR ⭐⭐⭐⭐⭐ 500次/天 精度更高
通用印刷体识别 腾讯OCR ⭐⭐⭐⭐⭐ 1000次/月 多场景
通用文字识别 阿里OCR ⭐⭐⭐⭐⭐ 有免费额度 与PaddleOCR同源
文字识别 科大讯飞 ⭐⭐⭐⭐⭐ 有免费额度 手写特化
b.代码示例
---
# 百度 OCR API 示例
import requests
API_KEY = "..."
SECRET_KEY = "..."
# 获取 token
token_url = f"https://aip.baidubce.com/oauth/2.0/token?grant_type=client_credentials&client_id={API_KEY}&client_secret={SECRET_KEY}"
token = requests.get(token_url).json()["access_token"]
# 调用 OCR
with open("image.jpg", "rb") as f:
img_data = f.read()
import base64
img_base64 = base64.b64encode(img_data).decode()
ocr_url = f"https://aip.baidubce.com/rest/2.0/ocr/v1/accurate_basic?access_token={token}"
result = requests.post(ocr_url, data={"image": img_base64})
words = [w["words"] for w in result.json().get("words_result", [])]
print("\n".join(words))
---
c.说明
---
f.专业领域 OCR
a.公式识别（LaTeX OCR）
a.表格数据
工具 特点 安装
LaTeX-OCR (pix2tex) 开源，数学公式图片→LaTeX pip install pix2tex
Mathpix 商业，精度最高 API订阅
GOT-OCR2.0 端到端，支持公式 见上文
Nougat (Meta) PDF科学文档→Markdown pip install nougat-ocr
b.代码示例
---
# LaTeX-OCR 使用
pip install pix2tex
# 命令行
pix2tex formula.png
# Python
from pix2tex.cli import LatexOCR
model = LatexOCR()
img = Image.open('formula.png')
print(model(img))
---
b.表格专用识别
a.表格数据
工具 特点
PaddleOCR PPStructure 表格识别+导出HTML（已安装）
img2table 从图片/PDF提取表格为DataFrame
table-transformer (Microsoft) Transformer表格检测
Camelot PDF表格提取专用
Tabula PDF表格提取（Java底层）
b.代码示例
---
pip install img2table camelot-py tabula-py
---
c.手写识别
a.表格数据
工具 特点
TrOCR (Microsoft) 开源手写识别，Transformer架构
百度OCR手写版 中文手写商业最强
腾讯OCR手写版 中文手写商业
Azure Document Intelligence 多语言手写
b.说明
略
g.文档解析全链路（RAG 场景）
a.说明
针对 RAG 知识库构建，推荐以下工具链：
b.表格数据
阶段 推荐工具 备选
PDF 解析 Docling / Marker PyMuPDF + PaddleOCR
扫描版 OCR PaddleOCR（已安装） RapidOCR / GOT-OCR2
表格提取 PPStructure（已安装） img2table / Camelot
公式识别 GOT-OCR2.0 / LaTeX-OCR Mathpix
文档结构化 Unstructured（已安装） Docling
高精度云端 百度OCR / Azure Document AI Google Document AI
c.说明
略
h.选型决策
a.表格数据
场景 推荐工具 理由
中文文档扫描 PaddleOCR（已安装） 中文最强开源
快速批量处理 RapidOCR（已安装） 速度最快
PDF转Markdown Marker / Docling RAG场景专用
公式识别 GOT-OCR2.0 / LaTeX-OCR 端到端，免后处理
表格精确提取 PPStructure（已安装） 百度出品，表格专用
多格式文档解析 Docling IBM出品，格式最全
生产环境，中文 百度OCR / 腾讯OCR SLA + 免费额度
生产环境，多语言 Azure Document Intelligence 精度最高，企业级
手写识别 百度OCR手写版 / TrOCR 场景特化
b.说明
略
1.7 glm系列1
01.常用信息1
a.文本 LLM（通用对话）
模型名 并发数 说明
GLM-5 2 新一代旗舰模型，综合能力全面提升，适合复杂推理与多轮对话。
GLM-5-Turbo 1 GLM-5 快速版，低延迟高响应。
GLM-4.7 2 主力旗舰，强推理+工具调用，均衡性能与成本的首选。
GLM-4.7-Flash 1 GLM-4.7 快速版，低延迟场景首选，速度优先。
GLM-4.7-FlashX 3 GLM-4.7 极速版，比 Flash 更快，适合高并发实时场景。
GLM-4.6 3 上一代旗舰，稳定成熟，适合生产环境兼容部署。
GLM-4.6V 10 GLM-4.6 视觉版，图文理解与分析。
GLM-4.6V-Flash 1 GLM-4.6 视觉快速版，低延迟图像理解。
GLM-4.6V-FlashX 3 GLM-4.6 视觉极速版，更快图像处理。
GLM-4.5 10 均衡型模型，性价比高，适合通用业务场景。
GLM-4.5-Air 5 GLM-4.5 轻量版，降低成本，保持基础能力。
GLM-4.5-AirX 5 GLM-4.5 轻量增强版。
GLM-4.5-Flash 2 GLM-4.5 快速版，低成本高速推理。
GLM-4.5V 10 GLM-4.5 视觉版，均衡型图文理解模型。
GLM-4-Plus 20 GLM-4 增强版，更强的长上下文与工具调用能力。
GLM-4-Air 100 GLM-4 轻量版，极低成本，适合高频调用场景。
GLM-4-Air-250414 30 GLM-4 轻量版（2025.04），稳定版。
GLM-4-AirX 5 GLM-4 轻量增强版。
GLM-4-Flash 200 GLM-4 极速免费版，适合开发测试，高并发。
GLM-4-Flash-250414 5 GLM-4 极速版（2025.04），稳定版。
GLM-4-FlashX 50 GLM-4 极速增强版，比 Flash 能力更强。
GLM-4-FlashX-250414 50 GLM-4 极速增强版（2025.04），稳定版。
GLM-4-Long 10 GLM-4 超长文本专属版，适合长文档处理与分析。
GLM-4-AllTools 5 GLM-4 全工具版，原生支持网络搜索、代码执行、图像理解。
GLM-4-Assistant 5 GLM-4 助手版，适合对话助手场景。
GLM-4-Voice 5 GLM-4 语音版，支持语音交互。
GLM-4-0520 20 GLM-4（2025.05.20），特定版本。
GLM-4-9B 5 GLM-4 9B 参数版，轻量化部署。
GLM-4-32B-0414-128K 15 GLM-4 32B 参数版，128K 上下文。
GLM-4 30 GLM-4 标准版，通用对话模型。
GLM-3-Turbo 50 GLM-3 快速版，兼容旧系统。
GLM-Z1-Air 30 Z系列推理模型轻量版，强化逻辑推理与数学能力。
GLM-Z1-AirX 30 Z系列推理模型轻量增强版。
GLM-Z1-Flash 30 Z系列推理快速版，高速深度推理。
GLM-Z1-FlashX 50 Z系列推理极速增强版。
GLM-Zero-Preview 50 探索性推理预览版，长思维链实验模型。
CharGLM-4 5 角色扮演专属版，支持个性化人设与长期记忆对话。
AutoGLM-Phone 5 手机端自动化 Agent，支持屏幕理解与操作控制。
AutoGLM-Phone-Multilingual 5 手机端多语言自动化 Agent。
GLM-Experimental-Preview 5 实验性预览版，最新功能尝鲜。
b.推理增强模型（深度思考）
GLM-4.1V-Thinking-Flash 5 视觉推理版，结合图像理解与深度思维链，快速推理。
GLM-4.1V-Thinking-FlashX 30 视觉推理极速增强版，更强的多模态推理能力。
c.多模态 VLM（视觉语言）
GLM-4V-Plus 5 GLM-4 增强视觉版，更精准的图像细节理解。
GLM-4V-Plus-0111 5 GLM-4 增强视觉版（2025.01.11）。
GLM-4V-Flash 10 GLM-4 视觉快速版，低延迟图像理解。
GLM-4V 5 GLM-4 视觉版，标准图文理解。
GLM-Image 1 图像理解专属模型，针对图片内容分析优化。
GLM-OCR 2 光学字符识别专属模型，文档/票据/图片文字提取。
d.代码模型
CodeGeeX-4 50 智谱最新代码生成模型，多语言编程，补全/翻译/解释全支持。
02.常用信息2
a.搜索增强模型
Search-Pro 5 联网搜索增强版，深度整合实时网络信息，复杂问题解答。
Search-Std 50 联网搜索标准版，基础网络信息检索与问答。
Web-Search-Pro 30 网页搜索专业版，精准网页内容抓取与摘要。
b.向量嵌入模型
Embedding-3 50 主力文本嵌入模型，1024维向量，语义检索/RAG首选。
embedding-3-pro 100 嵌入增强版，更高精度语义表示，高要求检索场景。
Embedding-2 50 上一代嵌入模型，兼容旧系统，稳定可用。
c.重排序模型
Rerank 50 检索结果重排序，提升 RAG 召回质量，与 Embedding 配合使用。
d.图像生成模型
CogView-4 5 最新图像生成模型，高质量文生图，细节丰富。
CogView-4-250304 5 CogView-4（2025.03.04），稳定版。
CogView-3-Plus 5 CogView-3 增强版，更高图像质量与多样性。
CogView-3-Flash 5 CogView-3 快速版，低成本快速出图。
CogView-3 5 CogView-3 标准版，稳定图像生成。
e.视频生成模型
CogVideoX 5 主力视频生成模型，文/图生视频，高质量连续帧。
CogVideoX-2 5 第二代视频生成，动态效果与连贯性大幅提升。
CogVideoX-3 1 第三代视频生成，超低成本，1点/次。
CogVideoX-Flash 3 视频生成快速版，低成本快速生成。
ViduQ1-text 5 Vidu Q1 系列文生视频，电影级画质。
Viduq1-Image 5 Vidu Q1 图生视频。
Viduq1-Start-End 5 Vidu Q1 起止帧控制视频生成。
Vidu2-Image 5 Vidu 第二代图生视频。
Vidu2-Start-End 5 Vidu 第二代起止帧控制。
Vidu2-Reference 5 Vidu 第二代参考视频生成。
f.语音/音频模型
GLM-TTS 5 实时文字转语音，多音色自然语音合成。
GLM-TTS-Clone 2 声音克隆版，基于参考音频复刻指定音色。
GLM-ASR 5 实时语音识别，高精度语音转文字。
GLM-ASR-2512 5 实时语音识别（2025.12），增强版。
CogTTS 5 高质量离线文字转语音模型。
CogTTS-Clone 2 CogTTS 声音克隆版。
g.实时音视频模型
GLM-Realtime 5 实时音视频交互模型，支持低延迟语音/视频对话。
GLM-Realtime-Flash 5 实时音视频快速版，极低延迟，适合实时场景。
GLM-Realtime-Air 5 实时音视频轻量版，低成本实时交互。
h.工具/安全模型
Moderation 5 内容审核模型，检测违规/有害内容，适合上线前过滤。
1.8 glm系列2
00.汇总
a.文本LLM
GLM-4.x 智谱AI新一代旗舰模型，支持128K超长上下文，在复杂推理、工具调用和多轮对话中表现顶尖，是GLM系列的集大成者。
ChatGLM3-6B 第三代ChatGLM对话模型，全新Prompt格式，原生支持工具调用、代码执行和Agent任务，8K基础上下文版本。
ChatGLM3-6B-32k 第三代ChatGLM长上下文版本，强化长文本理解能力，可处理最多32K长度的上下文内容。
ChatGLM3-6B-base 第三代ChatGLM基座模型，10B以下基础模型中性能领先，适合二次开发与微调。
ChatGLM2-6B 第二代ChatGLM对话模型，性能大幅提升，推理速度相比初代提升42%，8K上下文版本。
ChatGLM2-6B-32K 第二代ChatGLM长上下文版本，基于位置插值技术优化，支持32K长度上下文处理。
ChatGLM-6B 初代ChatGLM对话模型，62亿参数GLM架构，支持中英双语，可在消费级显卡部署。
AgentLM-7B/13B/70B 基于AgentTuning方法微调的Llama2模型，具备超强Agent能力，覆盖7B-70B多尺寸。
b.多模态VLM
CogAgent-18B 基于CogVLM-17B改进的视觉语言模型，110亿视觉参数+70亿语言参数，支持1120x1120分辨率，具备GUI图像Agent能力。
CogVLM-17B 智谱AI核心多模态模型，视觉语言特征深度融合，多模态权威榜单综合成绩第一，14个数据集取得顶尖成绩。
VisualGLM-6B 开源多模态对话模型，基于ChatGLM-6B+BLIP2-Qformer构建，78亿总参数，支持图像+中英双语交互。
c.代码模型
CodeGeeX2-6B 第二代多语言代码生成模型，基于ChatGLM2架构，60亿参数性能超越150亿参数的StarCoder-15B。
CodeGeeX-13B 初代CodeGeeX模型，130亿参数，多编程语言生成能力强，基于华为MindSpore框架训练。
d.垂直领域模型
WebGLM-10B/2B 网络增强型问答模型，集成网络搜索/检索功能，高效解决现实世界知识问答问题。
MathGLM-2B/10B 专注数学运算的模型，20亿参数版本算术运算准确率近100%，显著超越GPT-4同项指标。
e.轻量化版本
ChatGLM2-6B-int4 ChatGLM2-6B的INT4量化版本，仅需5.1GB显存即可运行，6G显存支持8K上下文。
ChatGLM2-6B-32k-int4 ChatGLM2-6B-32K的INT4量化版本，低显存即可体验32K长上下文能力。
ChatGLM-6B-int4/int8 ChatGLM-6B的INT4/INT8量化版本，最低6GB显存即可部署，支持消费级显卡运行。
CodeGeeX2-6B-int4 CodeGeeX2的INT4量化版本，轻量化代码生成解决方案。
01.Chat模型
a.ChatGLM3系列
a.ChatGLM3-6B
地址：https://github.com/THUDM/ChatGLM3
第三代ChatGLM对话模型。采用全新设计的Prompt格式，除正常多轮对话外，原生支持工具调用、代码执行和Agent任务等复杂场景。
b.ChatGLM3-6B-base
地址：https://github.com/THUDM/ChatGLM3
第三代ChatGLM基座模型。采用更多样数据、更充分训练步数和更合理策略。在多角度测评中具有10B以下基础模型中最强性能。
c.ChatGLM3-6B-32k
地址：https://github.com/THUDM/ChatGLM3
第三代ChatGLM长上下文对话模型。强化长文本理解能力，能够更好地处理最多32K长度的上下文。
b.ChatGLM2系列
a.ChatGLM2-6B
地址：https://github.com/THUDM/ChatGLM2-6B
第二代ChatGLM对话模型。性能更强，基座模型上下文长度扩展到32K，对话阶段使用8K长度训练。推理速度相比初代提升42%。
b.ChatGLM2-6B-int4
地址：https://github.com/THUDM/ChatGLM2-6B
ChatGLM2-6B的int4量化版本。最小5.1GB显存即可运行。INT4量化下6G显存支持的对话长度由1K提升到8K。
c.ChatGLM2-6B-32K
地址：https://github.com/THUDM/ChatGLM2-6B
第二代ChatGLM长上下文对话模型。强化长文本理解能力，能够处理最多32K长度的上下文。基于位置插值方法更新位置编码，并在对话阶段使用32K长度训练。
d.ChatGLM2-6B-32k-int4
地址：https://github.com/THUDM/ChatGLM2-6B
ChatGLM2-6B-32K的int4量化版本。
c.ChatGLM初代系列
a.ChatGLM-6B
地址：https://github.com/THUDM/ChatGLM-6B
第一代ChatGLM对话模型。支持中英双语，基于GLM架构，具有62亿参数。结合量化技术，用户可在消费级显卡上本地部署。
b.ChatGLM-6B-int4
地址：https://github.com/THUDM/ChatGLM-6B
ChatGLM-6B的Int4版本。最低6GB显存可部署，7GB显存可启动微调。
c.ChatGLM-6B-int8
地址：https://github.com/THUDM/ChatGLM-6B
ChatGLM-6B的Int8版本。
d.AgentLM系列
a.AgentLM-7B
地址：https://github.com/THUDM/AgentTuning
基于AgentTuning方法和AgentInstruct数据集微调的Llama2模型，具备超强Agent能力。
b.AgentLM-13B
地址：https://github.com/THUDM/AgentTuning
基于AgentTuning方法和AgentInstruct数据集微调的Llama2模型，具备超强Agent能力。
c.AgentLM-70B
地址：https://github.com/THUDM/AgentTuning
基于AgentTuning方法和AgentInstruct数据集微调的Llama2模型，具备超强Agent能力。
02.多模态模型
a.CogAgent-18B
地址：https://github.com/THUDM/CogVLM
基于CogVLM-17B改进的开源视觉语言模型。拥有110亿视觉参数和70亿语言参数，支持1120x1120分辨率图像理解，具备GUI图像的Agent能力。
b.CogVLM-17B
地址：https://github.com/THUDM/CogVLM
强大的开源视觉语言模型。基于视觉和语言信息融合的理解，实现视觉语言特征深度融合。在多模态权威学术榜单综合成绩第一，在14个数据集取得顶尖成绩。
c.Visualglm-6B
地址：https://github.com/THUDM/VisualGLM-6B
开源的支持图像、中文和英文的多模态对话语言模型。语言模型基于ChatGLM-6B，图像部分通过BLIP2-Qformer构建桥梁，共78亿参数。
d.RDM
地址：https://github.com/THUDM/RDM
Relay Diffusion Model：级联扩散模型，可以从任意给定分辨率的图像快速生成，而无需从白噪声生成。
03.代码模型
a.CodeGeeX2系列
a.CodeGeeX2-6B
地址：https://github.com/THUDM/CodeGeeX2
多语言代码生成模型CodeGeeX的第二代。基于ChatGLM2架构加入代码预训练实现，多项指标取得性能提升。
b.CodeGeeX2-6B-int4
地址：https://github.com/THUDM/CodeGeeX2
CodeGeeX2的量化版本。
b.CodeGeeX系列
a.CodeGeeX-13B
地址：https://github.com/THUDM/CodeGeeX
第一代CodeGeeX，具有130亿参数的多编程语言代码生成预训练模型。采用华为MindSpore框架实现，在鹏城云脑II训练而成。
04.其他模型
a.WebGLM系列
a.WebGLM-10B
地址：https://github.com/THUDM/WebGLM
利用百亿参数通用语言模型提供高效、经济的网络增强型问答解答系统。集成网络搜索和检索功能到预训练语言模型中。
b.WebGLM-2B
地址：https://github.com/THUDM/WebGLM
利用通用语言模型提供网络增强型问答解答系统。
b.MathGLM系列
a.MathGLM-2B
地址：https://github.com/THUDM/MathGLM
在训练数据充足时，20亿参数模型能准确执行多位算术运算，准确率接近100%，显著超越GPT-4。
b.MathGLM-500M
地址：https://github.com/THUDM/MathGLM
MathGLM的小参数变体。
c.MathGLM-100M
地址：https://github.com/THUDM/MathGLM
MathGLM的小参数变体。
d.MathGLM-10M
地址：https://github.com/THUDM/MathGLM
MathGLM的小参数变体。
e.MathGLM-Large
地址：https://github.com/THUDM/MathGLM
采用GLM-large作为骨干训练。
f.MathGLM-10B
地址：https://github.com/THUDM/MathGLM
采用GLM-10B作为骨干训练。
g.MathGLM-ChatGLM-6B
地址：https://github.com/THUDM/MathGLM
采用ChatGLM-6B作为基座模型训练。
h.MathGLM-ChatGLM2-6B
地址：https://github.com/THUDM/MathGLM
采用ChatGLM2-6B作为基座模型训练。
1.9 文档识别
00.汇总
a.分类1
Unstructured 通用的异构数据ETL库，能将 Office/PDF/HTML 等各类文档拆解为适合 RAG 的标准元素列表。
MinerU 专攻复杂 PDF 版面解析，精准还原学术论文或研报中的公式、表格与排版，直接输出 Markdown。
PyMuPDF4LLM 专为 LLM 设计的解析工具，能按人类阅读顺序精准提取 PDF 文本与图片，无缝对接 LlamaIndex。
Docling IBM 开源的文档与图像解析引擎，融合了版面分析与 OCR 技术，高效输出高质量结构化数据。
b.分类2
PyPDF 纯 Python 编写的经典 PDF 库，轻量级且零依赖，主要用于提取纯文本或进行简单的页面操作。
PaddleOCR 百度开源的工业级 OCR 系统，支持 80+ 语言识别与复杂版面分析，是构建本地 OCR 服务的基石。
PyMuPDF 高性能底层 PDF 处理库，提供像素级页面访问与坐标定位能力，适合开发者定制深度解析流程。
01.分类1
a.Unstructured
a.作用
一个通用「文档摄取 + 预处理」开源库，把 PDF、Word、PPT、HTML、图片等拆分成标准 Element 列表，适合后续做 chunk、嵌入和 RAG。
b.特点
a.多格式支持
支持多种文件格式：PDF、DOCX、PPTX、HTML、图片等，会调用系统的 Tesseract、LibreOffice、Pandoc 等工具。
b.高精度模式
提供 hi_res PDF 模式，结合版面分析模型，可以保留段落、标题、表格等结构。
c.部署方式
有开源库 + 商业 API，你完全可以只用开源部分，在内网部署（包括 Docker）。
c.适合场景
作为「统一入口」处理各种文件类型，再接到你选的向量库和 RAG 框架。
b.MinerU
a.作用
专攻复杂 PDF/版面解析，识别标题、正文、表格、公式、图片，并输出结构化结果（如 Markdown/JSON）。
b.特点
a.自动识别类型
自动区分普通 PDF / 扫描 PDF，并按需开启 OCR，支持 100+ 语言。
b.优化处理
对水印、复杂排版、多图多表+说明文字有专门优化。
c.局限性
当前对「PDF 内嵌图片里的文字」OCR 支持有限，社区建议是先抽出图片自己跑 OCR 再回填。
c.适合场景
科研论文、报告、教材、考试卷、PPT 转 PDF 这类复杂 PDF，要求版面还原和表格/公式质量比较高的场景。
c.PyMuPDF4LLM
a.作用
基于 PyMuPDF 做「LLM/RAG 友好」的 PDF/文档解析，直接转成干净 Markdown 或 LlamaIndex 文档对象。
b.特点
a.阅读顺序优化
自动识别标题、段落、表格，保证阅读顺序，对 RAG 非常友好。
b.图片处理
支持提取图片，可以单独保存或嵌入，用于多模态模型。
c.生态集成
可以直接输出 LlamaIndex Document 列表，方便直接入索引。
c.适合场景
你已经用 Python + LlamaIndex / 自建 RAG，想在代码里轻量调用，无需额外服务；对极致版面还原要求不如 MinerU 那么极端。
d.Docling
a.基本信息
来源：IBM 开源
b.主要能力
IBM 开源的文档解析工具，集成版面分析和 OCR，可解析 PDF 和图像，输出结构化内容。
c.适合场景
企业内对 PDF（含图片/扫描）做高质量解析，配合自建 RAG/搜索。
02.分类2
a.PyPDF / pypdf
a.基本信息
类型：经典 Python PDF 文本抽取库
b.主要能力
经典 Python PDF 文本抽取库，偏重纯文本抽取，不做复杂版面重建。
c.适合场景
简单 PDF，主要要正文文本，依赖少、好集成到现有脚本/服务。
b.PaddleOCR
a.基本信息
地址：https://github.com/PaddlePaddle/PaddleOCR（开源免费）
b.主要能力
通用 OCR 引擎，支持中英文和多语言，版面分析+文字检测+识别，性能和准确率较好，可 GPU/CPU 部署。
c.适合场景
内网搭建高质量 OCR 服务，识别扫描 PDF、图片里的文字，可作为 Unstructured/MinerU/PyMuPDF 管道的 OCR 底层。
c.PyMuPDF
a.基本信息
地址：https://pymupdf.readthedocs.io
b.主要能力
轻量级 PDF（和部分电子书格式）处理库，可读取页面、提取文本、图片、坐标、进行简单绘制等。
c.适合场景
自己在代码中控制解析流程：先用 PyMuPDF 拆页/抽图片，再配合 PaddleOCR 做 OCR，最后自定义清洗/分块。
03.经典组合
a.内网部署
a.简单 PDF/Office → 文本
a.组合方案
PyMuPDF4LLM + PyPDF + Tesseract/EasyOCR。
b.适用情况
主要是 PDF，版面不极端复杂，追求简单可靠、少依赖。
b.复杂 PDF + 表格/公式 + 多种格式
a.组合方案
MinerU（解析 PDF）+ Tesseract/PaddleOCR（补图像 OCR）+ LibreOffice/Pandoc（Word/PPT ↔ PDF/HTML）。
b.适用情况
科研/报告场景，对版面精度要求高。
c.统一文档入口 + 多格式 + RAG
a.组合方案
Unstructured（统一解析）+ 你之前看的 Milvus / Qdrant / pgvector / Zvec / Wax 等向量库 + LlamaIndex / LangChain 做上层 RAG。
b.适用情况
企业内部各种文档杂糅，希望一个链路打通：解析 → 清洗/分块 → 向量化 → RAG 问答。
b.典型组合：PaddleOCR + PyMuPDF
a.扫描 / 图片为主的 PDF
a.第一步
用 PyMuPDF 提取每页图片。
b.第二步
调用 PaddleOCR 做检测+识别。
c.第三步
自己按坐标/块组合成段落或 Markdown，再送入向量库。
b.混合文本 + 图片的 PDF
a.第一步
用 PyMuPDF 提取可选文本。
b.第二步
对图像区域跑 PaddleOCR。
c.第三步
合并结果，或再交给 Unstructured 做元素级清洗。
1.10 模型推理
00.汇总
a.分类1
大语言模型 向量模型 重排模型 语音识别 语音合成 视觉模型 图片生成 文生视频 图生视频
阿里云百炼 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Anthropic ✔ ✔
Amazon Bedrock ✔ ✔ ✔ ✔
Azure OpenAI ✔ ✔ ✔ ✔ ✔ ✔
DeepSeek ✔
Gemini ✔ ✔ ✔ ✔ ✔
kimi ✔
b.分类2
OpenAI ✔ ✔ ✔ ✔ ✔ ✔
SILICONFLOW ✔ ✔ ✔ ✔ ✔ ✔ ✔
腾讯云 ✔
腾讯混元 ✔ ✔ ✔ ✔ ✔
火山引擎 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
千帆大模型 ✔ ✔
讯飞星火 ✔ ✔ ✔ ✔
c.分类3
智谱 AI ✔ ✔ ✔
本地模型 ✔ ✔
Ollama ✔ ✔ ✔ ✔
vLLM ✔ ✔ ✔ ✔ ✔
Xorbits ✔ ✔ ✔ ✔ ✔ ✔ ✔
Docker AI ✔ ✔ ✔
00.汇总
a.文本LLM
Llama-3.x Meta 最强开源模型系列，覆盖 7B-400B 全尺寸，生态最完善，是目前开源领域的“标准基座”。
DeepSeek-V3 国内最强开源 MoE 模型，在逻辑推理（Reasoning）和代码生成能力上媲美顶尖闭源模型。
Qwen-2.5/3 阿里通义千问系列，中文理解与多语言能力极强，在 Agent 和 RAG 场景下表现突出。
GLM-4.x 智谱 AI 开源的高性能模型，擅长超长上下文处理（Long Context）和复杂的工具调用任务。
Mistral 欧洲知名号称“小而美”的模型系列，参数量小但性能强悍，适合高效推理和边缘部署。
Gemma-2/3 Google DeepMind 开源的同源 Gemini 技术模型，性能强劲且提供优秀的多模态版本。
Falcon 阿联酋 TII 推出的超大参数（如 180B）模型，在特定垂直领域和英文理解上表现稳健。
Phi-3/4 微软推出的 SLM（小语言模型）代表，用极小参数实现惊人的逻辑推理能力，适合端侧设备。
b.多模态VLM
Qwen-2.5-VL 支持图像与视频输入，具备强大的动态分辨率处理和文档/图表理解能力。
Llama-Vision Llama 系列的官方视觉版，在 OCR 文档提取和视觉问答（VQA）方面表现优异。
Gemma-3-VLM 支持高分辨率图像输入和 128k 上下文，适合移动端和多模态交互场景。
DeepSeek-VL 专精于真实世界视觉任务，对代码截图、科学图表和技术文档理解进行了深度优化。
Falcon-VLM 结合 ViT 视觉编码器，专注于捕捉图像高细节信息和多语言视觉问答。
Pixtral Mistral 的首个多模态尝试，支持任意分辨率多图输入，指令跟随能力强。
Phi-4-Multi 微软小体积多模态模型，在低算力端侧设备上提供强大的视觉推理能力。
c.推理服务
vLLM 高吞吐 GPU 推理引擎，利用 PagedAttention 技术极大提升了显存利用率和并发处理效率。
TGI HuggingFace 官方推出的高性能推理容器，对各类主流开源模型架构支持最全面。
llama.cpp 基于 C++ 的轻量级推理库，支持 CPU/GPU 混合推理，让普通电脑也能流畅运行大模型。
Ollama 最流行的本地大模型管理工具，一条命令即可下载运行模型，提供标准 API 接口。
d.TTS语音
Qwen3-TTS 阿里全栈语音模型，支持 3 秒极速音色克隆和自然语言控制语气，中文效果极佳。
XTTS-v2 Coqui 旗舰模型，支持 17 种语言的高质量零样本克隆，适合跨语言配音。
Mozilla-TTS 经典的开源 TTS 框架，提供多种架构和预训练模型，适合科研与定制开发。
Bark Suno 开源的生成式音频模型，不仅能生成语音，还能生成笑声、背景乐等丰富情感音效。
Coqui-TTS 模块化语音工具包，社区活跃，提供大量开箱即用的高质量预训练模型。
Chat/MeloTTS 专为对话场景优化的 TTS，韵律自然，其中 MeloTTS 对中文支持尤为友好。
e.图片生成
Stable-Diff 拥有最大开源生态的文生图模型，从 1.5 到 SD3 持续引领行业，插件与微调模型极为丰富。
FLUX.1 黑森林实验室力作，120 亿参数混合架构，在手部细节、文字生成和提示词遵循上超越 SDXL。
DeepFloyd-IF 像素级级联生成模型，对提示词理解精准，能生成含文字的高清晰度图像。
StyleGAN 英伟达经典 GAN 模型，在人脸生成、风格迁移和潜空间控制领域依然拥有最强可控性。
f.视频生成
Wan2.1(万象) 阿里开源视频模型，支持文生/图生视频，生成质量与时长（5秒+）处于开源第一梯队。
LTX-Video Lightricks 推出的实时视频生成模型，基于 DiT 架构，生成速度快于播放速度，适合实时应用。
01.文本LLM：常见开源推理模型
a.Llama 3 / 3.1 / 3.2 系列
a.基本信息
类型：开源模型权重
仓库地址：https://github.com/meta-llama/llama3
b.核心作用
Meta 开源/开权重模型，覆盖 7B–400B 多规格。推理、代码、长上下文表现都不错，生态和工具链最完善之一。
c.典型使用场景
通用文本生成、企业私有化部署、微调基座、复杂指令遵循。
b.DeepSeek V3.x / DeepSeek-R1
a.基本信息
类型：开源模型权重 / MoE
仓库地址：https://github.com/deepseek-ai/DeepSeek-V3
b.核心作用
国内团队的高性能推理模型，采用 MoE 架构，在 reasoning / coding 指标上表现极其出色，被认为是开源推理 SOTA 之一。
c.典型使用场景
代码生成、复杂逻辑推理（Reasoning）、数学解题、长文本分析。
c.Qwen3 / Qwen2.5 系列
a.基本信息
类型：开源模型权重
仓库地址：https://github.com/QwenLM/Qwen
b.核心作用
阿里 Qwen 新一代开源/开权重模型，覆盖 0.5B–200B 多规格。中文理解能力和多语言支持极强，Agent/RAG 能力突出。
c.典型使用场景
中文场景应用、多语言翻译、Agent 智能体构建、RAG 检索增强。
d.GLM-4.x / GLM-5
a.基本信息
类型：开源模型权重
仓库地址：https://github.com/THUDM/GLM-4
b.核心作用
智谱 GLM 系列高性能模型，支持超长上下文（Context Length）和强大的 Agent 调用能力。
c.典型使用场景
长文档摘要与问答、工具调用（Function Calling）、智能体编排。
e.Mistral 系列（Mistral 7B / Mixtral / Mistral Small 3 等）
a.基本信息
类型：开源模型权重
仓库地址：https://github.com/mistralai/mistral-src
b.核心作用
以高效小模型著称，参数量不大但推理性能很强（如 MoE 架构的 Mixtral），采用 Apache-2.0 等宽松许可证。
c.典型使用场景
本地部署、边缘计算、高并发推理服务、追求性价比的商用场景。
f.Gemma 2 / Gemma 3
a.基本信息
类型：开源模型权重
仓库地址：https://github.com/google/gemma_pytorch
b.核心作用
Google DeepMind 发布的开源权重模型，与 Gemini 同源技术，性能强劲，多模态版能力也不错。
c.典型使用场景
研究实验、移动端/端侧部署、科学计算辅助、多模态交互。
g.Falcon 2 / Falcon 180B
a.基本信息
类型：开源模型权重
仓库地址：https://huggingface.co/tiiuae
b.核心作用
阿联酋 TII 的大参数开源模型，拥有巨大的参数量（如 180B），在特定领域的知识广度和英文理解上表现稳健。
c.典型使用场景
大型知识库问答、特定行业（如法律/金融）微调、作为大模型基座研究。
h.Phi-3 / Phi-4
a.基本信息
类型：开源模型权重 (SLM)
仓库地址：https://github.com/microsoft/Phi-3CookBook
b.核心作用
微软推出的「小参数但强推理」系列（SLM），使用高质量教科书数据训练，在极小参数下拥有惊人的逻辑推理能力。
c.典型使用场景
手机/PC 端侧推理、低延迟应用、嵌入式设备、简单逻辑任务处理。
02.多模态/图文推理模型（VLM）
a.Qwen 2.5 VL
a.基本信息
类型：多模态模型
仓库地址：https://github.com/QwenLM/Qwen-VL
b.核心作用
支持图像和视频输入、多语言交互。具备动态分辨率处理能力，文档理解和场景理解能力极强，Apache-2.0 许可。
c.典型使用场景
视频内容分析、OCR 文档提取、复杂图表理解、多模态 Agent。
b.Llama 3.2 Vision
a.基本信息
类型：多模态模型
仓库地址：https://github.com/meta-llama/llama-models
b.核心作用
Llama 系列的视觉版本，11B/90B 多规格。评测显示其在文档/OCR、VQA（视觉问答）、caption 方面表现优异，支持 128k 上下文。
c.典型使用场景
图像描述生成、视觉问答系统、PDF/图片文档数字化。
c.Gemma 3（VLM）
a.基本信息
类型：多模态模型
仓库地址：https://github.com/google/gemma_pytorch
b.核心作用
使用 SigLIP encoder，支持高分辨率图片输入和 128k 上下文，多语言支持好。
c.典型使用场景
移动端多模态应用、细粒度图像识别、即时视觉反馈系统。
d.DeepSeek-VL
a.基本信息
类型：多模态模型
仓库地址：https://github.com/deepseek-ai/DeepSeek-VL
b.核心作用
MoE 架构的多模态模型，针对科学图表、代码截图、技术图像做了专门的强化训练。
c.典型使用场景
学术论文图表分析、代码截图转文字、技术文档理解。
e.Falcon 2 VLM 11B
a.基本信息
类型：多模态模型
仓库地址：https://huggingface.co/tiiuae
b.核心作用
使用 ViT-L/14 视觉编码器，专注于捕捉高细节图像信息和多语言视觉问答。
c.典型使用场景
多语言视觉助手、细节敏感的图像分析（如工业质检初筛）。
f.Pixtral
a.基本信息
类型：多模态模型
仓库地址：https://github.com/mistralai/mistral-src
b.核心作用
Mistral 的多模态尝试，支持多图输入和原始分辨率处理，指令遵从性强。
c.典型使用场景
多图叙事分析、复杂指令下的视觉任务（如“找出图1和图2的不同点”）。
g.Phi-4 Multimodal
a.基本信息
类型：多模态模型
仓库地址：https://huggingface.co/microsoft
b.核心作用
多规格选择，强调在小体积下的强多模态推理能力，继承了 Phi 系列的高质量数据训练特点。
c.典型使用场景
端侧视觉推理、实时视频流分析（低算力场景）。
03.推理服务器/Serving 组件
a.vLLM
a.基本信息
类型：推理引擎
仓库地址：https://github.com/vllm-project/vllm
b.核心作用
高吞吐 GPU 推理引擎，核心技术是 PagedAttention（分页 KV 缓存）和 Continuous Batching。
c.典型使用场景
生产环境高并发部署、大模型 API 服务后端、追求极致吞吐量的场景。
b.Text Generation Inference (TGI)
a.基本信息
类型：推理服务
仓库地址：https://github.com/huggingface/text-generation-inference
b.核心作用
Hugging Face 官方推出的高性能推理容器，针对主流模型架构（Llama, Falcon, StarCoder, BLOOM 等）进行了深度优化。
c.典型使用场景
企业级 Docker 部署、Hugging Face 模型的一键服务化、标准化的推理接口。
c.llama.cpp
a.基本信息
类型：推理库
仓库地址：https://github.com/ggerganov/llama.cpp
b.核心作用
使用 C++ 重写推理逻辑，支持 CPU、CUDA、Metal（Mac）、Vulkan 等多后端，专为 GGUF 量化模型优化。
c.典型使用场景
本地（Mac/Windows）运行大模型、边缘设备（树莓派/手机）部署、低显存/无显存环境。
d.Ollama
a.基本信息
类型：本地模型管理工具
仓库地址：https://github.com/ollama/ollama
b.核心作用
基于 llama.cpp 等后端封装的「一条命令运行大模型」工具，提供类似 Docker 的模型拉取体验和 HTTP API。
c.典型使用场景
开发者本地调试、桌面端 AI 助手后端、快速验证开源模型效果。
04.开源TTS语音模型
a.Qwen3-TTS (Qwen-Audio/CosyVoice)
a.基本信息
类型：语音生成模型
仓库地址：https://github.com/QwenLM/Qwen-Audio
b.核心作用
全家桶开源方案，支持 3 秒极速音色克隆、自然语言控制音色/情绪，覆盖中英等多语种，通常采用 Apache-2.0 许可。
c.典型使用场景
个性化语音助手、有声书生成、实时语音对话系统、跨语言配音。
b.XTTS-v2
a.基本信息
类型：语音生成模型
仓库地址：https://github.com/coqui-ai/TTS
b.核心作用
Coqui 系列的旗舰开源多语种 TTS，支持高质量的零样本（Zero-shot）音色克隆。
c.典型使用场景
多语言内容创作、游戏角色配音、本地化翻译配音。
c.Mozilla TTS
a.基本信息
类型：TTS 框架
仓库地址：https://github.com/mozilla/TTS
b.核心作用
经典的开源 TTS 框架，支持 Tacotron、WaveRNN 等多种架构，提供丰富的预训练模型和训练配方。
c.典型使用场景
学术研究、自训练特定音色模型、构建私有 TTS 服务。
d.Bark
a.基本信息
类型：文本转音频模型
仓库地址：https://github.com/suno-ai/bark
b.核心作用
Suno 开源的 Transformer 架构模型，不仅能生成语音，还能生成笑声、背景噪音、简单音乐，支持多语种和情绪表达。
c.典型使用场景
创意音频内容生成、播客制作、情感丰富的语音应用。
e.Coqui TTS
a.基本信息
类型：TTS 框架
仓库地址：https://github.com/coqui-ai/TTS
b.核心作用
模块化 TTS 框架，继承自 Mozilla TTS，提供大量现成模型（VITS, FastSpeech2 等），社区生态活跃。
c.典型使用场景
开发者快速集成 TTS、微调特定声音、开源社区协作。
f.ChatTTS、MeloTTS 等
a.基本信息
类型：对话 TTS 模型
仓库地址：https://github.com/2noise/ChatTTS 或 https://github.com/myshell-ai/MeloTTS
b.核心作用
专为对话场景设计，强调口语化的韵律、停顿和情感表达；MeloTTS 对中文支持尤为友好。
c.典型使用场景
聊天机器人发音、虚拟主播、交互式有声读物。
05.开源图片生成模型
a.Stable Diffusion 系列（SD 1.5 / 2.1 / SDXL / SD3 / SD3.5）
a.基本信息
类型：文生图模型
仓库地址：https://github.com/Stability-AI/stablediffusion
b.核心作用
经典的 Latent Diffusion 模型，拥有最庞大的社区生态（LoRA, ControlNet, WebUI）。新版本在画质和语义理解上大幅提升。
c.典型使用场景
艺术创作、游戏资产生成、电商模特替换、风格化滤镜、离线图像生成。
b.FLUX.1
a.基本信息
类型：文生图模型
仓库地址：https://github.com/black-forest-labs/flux
b.核心作用
120 亿参数的混合架构模型，在图像细节、Prompt 服从度、手指/文字生成准确性上表现极佳，是新一代 SOTA。
c.典型使用场景
高质量商业插画、海报设计、需要精准文字/细节的图像生成。
c.DeepFloyd IF
a.基本信息
类型：文生图模型
仓库地址：https://github.com/deep-floyd/IF
b.核心作用
像素级多阶段生成模型（非 Latent），直接在像素空间操作，支持极高的分辨率和细节，文本对齐度高。
c.典型使用场景
科研级图像生成、高保真纹理生成、排版设计辅助。
d.StyleGAN 系列
a.基本信息
类型：GAN 模型
仓库地址：https://github.com/NVlabs/stylegan3
b.核心作用
虽然不是 Diffusion 架构，但在人脸生成、特定域（如汽车、猫）风格转换上依然是王者，生成速度快，潜空间可控性强。
c.典型使用场景
人脸编辑与生成、照片修复、特定风格迁移、实时图像处理。
06.开源视频生成模型
a.Wan2.2-T2V-A14B
a.基本信息
类型：文生视频模型
仓库地址：https://github.com/Wan-Video/Wan2.1
b.核心作用
基于 MoE 架构的文本转视频（T2V）模型，能生成 5 秒左右的 480P/720P 视频，质量和生成速度在开源界领先。
c.典型使用场景
短视频素材生成、动态壁纸制作、广告 demo 快速预览。
b.Wan2.2-I2V-A14B / Wan2.1-I2V
a.基本信息
类型：图生视频模型
仓库地址：https://github.com/Wan-Video/Wan2.1
b.核心作用
图片转视频（I2V），能够在保持原图风格和构图的基础上，让静态画面产生合理的动态效果。
c.典型使用场景
老照片动起来、静态广告图转视频、游戏场景动态化。
c.LTX-Video
a.基本信息
类型：视频生成模型
仓库地址：https://github.com/Lightricks/LTX-Video
b.核心作用
基于 DiT（Diffusion Transformer）的实时视频生成模型，支持 30fps 和 HD 分辨率，生成速度极快（甚至快于播放速度）。
c.典型使用场景
实时视频流生成、互动娱乐应用、极低延迟的视频合成。
1.11 模型部署
00.汇总
a.分类1
vLLM 高吞吐量 LLM 推理与服务引擎，主打连续动态批处理加高效 KV Cache 管理，多用于 GPU 服务器端部署大模型 API。
MinivLLM 体量较小的 LLM 框架或示例项目，用于在消费级 GPU 上运行或实验小型 LLM，实现简单推理或微调流程。
llmfit 命令行和 TUI 工具，用来扫描本机硬件并匹配适合在当前 CPU/GPU/RAM 上运行的 LLM 模型，帮助选机型或选模型尺寸。
b.分类2
Ollama 本地大模型服务工具，提供统一命令行和本地 HTTP API，一条命令就能在本机拉取并运行 Llama、DeepSeek、Gemma、Phi、Mistral 等多种开源模型。
handy-ollama Datawhale 出的中文开源教程动手学 Ollama，面向入门用户，教你在本地用 CPU 部署和玩转大模型（基于 Ollama）。
llama.cpp 用 C 或 C++（底层 ggml）实现的高效 LLM 推理引擎，目标是在 CPU、移动端乃至嵌入式设备上高效运行 LLaMA 系列及兼容模型。
01.分类1
a.vLLM
a.文档地址
https://docs.vllm.ai/en/latest/
b.简要介绍
高吞吐量 LLM 推理与服务引擎，主打连续动态批处理加高效 KV Cache 管理，多用于 GPU 服务器端部署大模型 API。
c.主要专有特点
提供 OpenAI 风格 API，支持 continuous batching、paged KV cache 等技术，
在高并发、多请求场景下显著提升吞吐；可和主流框架集成，如很多推理或微调框架支持用 vLLM 作为后端 worker。
b.MinivLLM
a.项目地址
https://github.com/Wenyueh/MinivLLM
b.简要介绍
体量较小的 LLM 框架或示例项目，用于在消费级 GPU 上运行或实验小型 LLM，实现简单推理或微调流程。
c.主要专有特点
代码量少、结构简单，适合作为学习或实验 LLM 推理管线的起点；通常支持多种开源模型，突出 minimal、易读 的实现风格，而不是完整工业级部署能力。
c.llmfit
a.项目地址
https://github.com/AlexsJones/llmfit
b.简要介绍
命令行和 TUI 工具，用来扫描本机硬件并匹配适合在当前 CPU/GPU/RAM 上运行的 LLM 模型，帮助选机型或选模型尺寸。
c.主要专有特点
支持近百个模型与多家提供商，自动检测硬件配置，给出能跑、跑得动、多大上下文等推荐；支持 JSON 输出，方便嵌入到脚本或平台中作为模型选型助手。
目前收录 94 个模型，来自 30 个提供商——Llama、Mistral、Qwen、DeepSeek、Grok、Kimi 都在。
每个模型打四个分：质量（参数量、模型家族口碑）、速度（估算 tok/s）、适配度（内存利用率）、上下文（上下文窗口）
最后算个综合分，内存太紧跑不动的自动沉底。
02.分类2
a.Ollama
a.项目地址
https://github.com/ollama/ollama
b.简要介绍
本地大模型服务工具，提供统一命令行和本地 HTTP API，一条命令就能在本机拉取并运行 Llama、DeepSeek、Gemma、Phi、Mistral 等多种开源模型。
c.主要专有特点
支持 Mac、Linux 和 Windows，以及 Docker；通过 Modelfile 打包权重加配置加参数，一键管理模型版本；对 CPU 或消费级 GPU 友好，有大量社区集成，如 Web UI、Python SDK、各语言客户端等。
b.handy-ollama
a.项目地址
https://github.com/datawhalechina/handy-ollama
b.简要介绍
Datawhale 出的中文开源教程动手学 Ollama，面向入门用户，教你在本地用 CPU 部署和玩转大模型（基于 Ollama）。
c.主要专有特点
系统性中文文档，涵盖安装、模型管理、本地部署、结合应用开发等，对没有 GPU、只想用一台笔电或台式机玩 LLM 的用户非常友好；适合作为团队入门教材。
c.llama.cpp
a.项目地址
https://github.com/ggml-org/llama.cpp
b.简要介绍
用 C 或 C++（底层 ggml）实现的高效 LLM 推理引擎，目标是在 CPU、移动端乃至嵌入式设备上高效运行 LLaMA 系列及兼容模型。
c.主要专有特点
支持多种后端，包括 CPU、CUDA、Metal、Vulkan、OpenCL 等，可编译到桌面、移动、WebAssembly；生态工具丰富，如聊天 CLI、OpenAI 兼容 HTTP server、量化工具等，常作为通用本地 GGUF 推理引擎。
1.12 模型微调
01.常用信息1
a.部署系列
a.llmfit
brew reinstall llmfit
llmfit
b.ollama
qwen3.5:latest
qwen3.5:0.8b
qwen3.5:2b
qwen3.5:4b
qwen3.5:9b
qwen3.5:27b
qwen3.5:35b
qwen3.5:122b
qwen3.5:cloud
qwen3.5:397b-cloud
c.Macmini16G
模型 包体 16G结论
Qwen3 8B 5.2GB 16G主力首选
DeepSeek R1 8B 5.2GB 难题推理更强
Llama 3.1 8B 4.9GB 兼容生态最好
Gemma3 12B 8.9GB QAT 上限更高更吃内存
b.部署系列
a.Gemma-4
很简单，App Store上下载 Google AI Edge Gallery，
打开软件点击 Agent Skills，下载相应模型，大概3G左右，下载完就可以使用了，支持中文
1.这是本地大模型，免费的，下载下来试试又没啥损失
2.说的支持中文，是指支持中文对话，不是说软件UI有中文
3.手机发热，可能是俺使用频率比较低，没啥太大感觉
4.支持机型，15或以后机型都没太大问题
5.安卓Google Play有同名软件
02.常用信息2
aQwopus-GLM-18B-Merged-GGUF
a.说明
LLM 杂交技术，现在都玩这么花吗🤦♂️？
一个18B新模型，击败了新出的 Qwen3.6-35B-A3B，从这名字就能看出多杂
b.说明
🧠 叠加了两个分别蒸馏了Opus 4.6 和 GLM-5.1 的 Qwen3.5 9B的底子
⚡️ 18B，速度快，12GB显存显卡就能跑
🧪 实验性质
🛠️ 具备工具调用和推理能力
📚 GGUF 大小 9.8GB (Q4_K_M)
c.地址
https://huggingface.co/Jackrong/Qwopus-GLM-18B-Merged-GGUF
1.13 模型调用
00.汇总
a.分类1
OpenAI SDK 直接调用 OpenAI 平台（含其路由到其他模型的能力），官方维护，语义清晰，适合只用 OpenAI 生态的项目。
Vercel AI SDK 一个 API 抽象多家模型，前端直接写 useChat 等 hook 就能接入流式对话，非常适合 web 应用和边缘部署。
b.分类2
LangChain.js 在 Node/浏览器里统一调 OpenAI、Anthropic、Google、Azure、Bedrock、Ollama 等，带中间件、重试、链式组合。
LangChain（Python） 适合已经用 LangChain 做 RAG/Agent 的项目，顺手统一模型调用，不单独再封一层。
LangChain4j 把 OpenAI、Azure、Anthropic 等统一到 Java 接口里，支持 Spring 集成，适合企业 Java 系统直接用。
c.分类3
LiteLLM 可以当库直接 litellm.completion() 调，也可以跑成代理服务，统一鉴权、路由、限流，部署到你自己的内网。
New API 部署一个服务端点，应用用一个 OpenAI 兼容 SDK 调，就能切换不同后端模型。适合做「公司级模型平台」。
LLM Gateway 想在前端直接多家模型容灾/降级，用它可以少写很多判断逻辑。
ai-lib 如果你有 Rust 服务，需要统一调多家模型，这是一个比较新的选择，强调 streaming、可靠性和低延迟（<1ms 额外开销）。
01.分类1
a.OpenAI SDK
a.基本信息
语言 / 生态：多语言（JS/TS、Python、Java、.NET 等）
地址：官方各语言 SDK
b.主要特点
直接调用 OpenAI 平台（含其路由到其他模型的能力），官方维护，语义清晰，适合只用 OpenAI 生态的项目。
b.Vercel AI SDK
a.基本信息
语言 / 生态：JS/TS（React/Next.js 优先）
地址：前端/全栈友好的 AI SDK
b.主要特点
一个 API 抽象多家模型，前端直接写 useChat 等 hook 就能接入流式对话，非常适合 web 应用和边缘部署。
02.分类2
a.LangChain.js
a.基本信息
语言 / 生态：JS/TS
地址：虽然它是框架，但内置 50+ LLM/Embeddings/向量库集成
b.主要特点
在 Node/浏览器里统一调 OpenAI、Anthropic、Google、Azure、Bedrock、Ollama 等，带中间件、重试、链式组合。
b.LangChain（Python）
a.基本信息
语言 / 生态：Python
地址：同上，Python 版本，支持众多 LLM/向量库
b.主要特点
适合已经用 LangChain 做 RAG/Agent 的项目，顺手统一模型调用，不单独再封一层。
c.LangChain4j
a.基本信息
语言 / 生态：Java
地址：Java 生态的统一 LLM SDK + RAG/Agent 框架
b.主要特点
把 OpenAI、Azure、Anthropic 等统一到 Java 接口里，支持 Spring 集成，适合企业 Java 系统直接用。
03.分类3
a.LiteLLM
a.基本信息
语言 / 生态：Python SDK + 网关
地址：用 OpenAI 风格 API 调 100+ 模型提供商
b.主要特点
可以当库直接 litellm.completion() 调，也可以跑成代理服务，统一鉴权、路由、限流，部署到你自己的内网。
b.New API
a.基本信息
语言 / 生态：HTTP 网关 + SDK
地址：基于 One API 的多模型网关，统一 OpenAI/Claude/DeepSeek 等
b.主要特点
部署一个服务端点，应用用一个 OpenAI 兼容 SDK 调，就能切换不同后端模型。适合做「公司级模型平台」。
c.LLM Gateway（ottic-ai）
a.基本信息
语言 / 生态：JS/TS 客户端库
地址：面向浏览器 / 前端的多提供商客户端
b.主要特点
想在前端直接多家模型容灾/降级，用它可以少写很多判断逻辑。
d.ai-lib
a.基本信息
语言 / 生态：Rust SDK
地址：Rust 生态的多提供商统一 SDK
b.主要特点
如果你有 Rust 服务，需要统一调多家模型，这是一个比较新的选择，强调 streaming、可靠性和低延迟（<1ms 额外开销）。
2 设计思路
2.1 网络热梗
00.汇总
a.分类1
AI发展
AI热梗
AI趋势
AI关注
Qwen路线
b.分类2
AI道德
AI道路
AI碎碎念
聊天工程师
AI“外卖大战”开启
c.分类3
AI明星
AI岗位
AI裁员
d.分类4
AI插件
AI分析url
AI安装mcp
AI提交日志
AI操作自己
AI丝滑操作
AI搭配对话
AI项目思路
AI界面设计
01.常用信息1
a.AI发展
a.分类1
为人不识刘小排，迟早要被AI裁
AI榜一大哥，刘小排，Token消耗第一人
左耳耗子，左耳听风，陈皓，酷壳站长，突发心梗辞世
编译一个页面就是 11G 了，没有 96G 内存，应该是告别写 Next.js 了
b.分类2
故事是这样的，2025年8月20日，Anthropic 上周发布一个公告：他们的工程师在后台数据中发现了一个异常账户，
正在以一种不可思议的速度，7x24 小时消耗着 Claude 模型的算力。公告中提到：
一位用户，在每月200美元的套餐中，消耗了价值 5 万美元的模型使用量。
c.分类3
9 月 5 日，Anthropic 宣布停止向中国资本控股（超 50% 股权）的企业及其子公司提供 Claude 服务。
作为曾因强编程能力广受开发者青睐的工具，Claude 的退出无疑给依赖其开展编码工作的团队和个人带来突发挑战。
d.分类4
Karpathy 一年前发明了 vibe coding，最近他又提了个新词：
Agentic Engineering，人类 99% 的时间不再写代码，而是编排 AI Agent。
这让我想起 2020 年我做的那期 AlphaZero 视频：人类围棋冠军不会再出现了。
现在代码领域正在发生同样的事。
e.分类5
我们的“奖励”竟然是丢掉工作
OpenAI 创始人Sam Altman 发了个推：感谢那些一行一行编写复杂软件代码的人，付出了难以想象的巨大努力，让AI走到了今天的爆发
然后大家炸了：我谢谢你，现在害得大家都要失业了
f.分类6
跟觉我 20 年上网经验，这绝对不是腾讯真实的想法
我觉得真实的思考应该是
1.免费领养小龙虾 （chatbot）
2.首充五块，可以在购物、医疗、出行、办公四种稀有龙虾选一个
3. 连续使用 7 天，可以领取黄金小龙虾皮肤，有 token 暴击包可以领
4.上线皮肤超市，除了稀有黄金，史诗炫彩，澳龙限定，荣耀典藏不同的皮肤外，还有星元系统，可以针对皮肤某一个部件定制皮肤，比如只给龙虾的爪子镶钻
b.AI热梗
a.分类1
马科长难题，成为国内检测ai的标准问题之一
AI竞争的真相，根本不是「美国和中国的竞争」，而是「在美国的中国人和在中国的中国人的竞争」
给你讲个AI冷笑话：我好奇的不是AI的强大，而是舞台上这些处于人类食物链顶端的人，他们是怎么做到跟AI比肩的
b.分类2
阿里：AI界汪峰，惨
Google：超长上下文，最强deepresearch
OpenAl：证明大模型是可行的，确立了调用接口标准
DeepSeek：价格屠夫，行业鲶鱼
Anthropic：代码是可以一次成功的，确立了MCP标准
MCP不是工具，是 LLM 的"USB接口"。 未来1-2年这个生态会比 App Store 还丰富。 现在入场写MCP，相当于2008年写iOS App。
c.分类3
Vibe Coding 王炸三巨头
1.Antigravity Tools 负责提供提供Gemini 3、Cluade 等模型的弹药
2.CC Switch 负责接管 Claude Code 、Gemini Cli 和Code配置
3.Alma 通过 ACP 协议接管了 Cluade Code、Gemini Cli 和Codex Cli，负责 vibe Coding 入口
d.分类4
Cursor 发布：程序员要死了
Windsurf 发布：程序员死定了
Copilot 发布：程序员肯定死了
Claude code: 程序员马上就死
Codex ：程序员真的要死了
Antigravity ：程序员已经死了
程序员：给我个痛快吧
e.分类5
今天凌晨，AI 圈又双叒炸了。
20260106，Anthropic 和 OpenAI 几乎同时发布了自家的最新大模型。
Claude Opus 4.6 和 GPT-5.3-Codex，中门对狙，火药味十足。
f.分类6
我给个预测，到2030年，Anthropic应该会成为世界上市值前5的公司。
去年年中大伙说是gpt，年末说谷歌，现在又是说anthropic，AI时代可以保持耐心点
明眼人都看得出来，在商业上真正意义上跑通的，其实只有Anthropic，他是最有前途的AI公司，盈利潜力超越OpenAI和SpaceX
我只知道明年Anthropic收入就要超越SpaceX，到2030年收入可能是SpaceX的5-6倍。这就是商业上跑通了，其他的都是洗脑和饼
c.AI趋势
a.分类1
根据知识量梯度，然后逐层割韭菜。
自动化越长越快，幻觉发散的失控越严重，没有人在中间就变成了烧token的炉子，生成出一大堆东西，没有能用的
b.分类2
以前我们比的是“谁更聪明”，就像2024年我们聊的都是谁的参数更多、谁的训练数据更大、谁能回答更难的问题。
但现在我们比的是“谁更能干活”，看谁能真正帮用户把事情做完，而且做得又快又稳。
简单小结一下，2025年之后，AI竞争的战场彻底变了，不再是比谁的模型更聪明，而是比谁能让AI真正干活。这是这次收购带来的重要启发。
c.分类3
AI Coding：我从传统的单元测试全面迁移到 BDD（行为驱动测试）上了，让 AI 写 BDD 测试。
因为 BDD 的测试结果更可读，很容易验收 AI 的代码。比如我下面截图，一眼就能看出来 AI 是否完成了需求。
搜了下时间线，竟然没有人分享过这个，简单分享下，BDD 是 AI Coding 的最佳伴侣
d.分类4
OpenClaw 可以算是 AI OS 的雏形了吧，或者叫 AI DOS：
Skills → 应用软件
终端 → Telegram/Discord/WhatsApp
进程管理 → Agentic Workflow / Task Planning
指令集 → 自然语言
虚拟内存与分页 → RAG
e.分类5
快过年了，不要再讨论什么 Vibe Code、penClaw、Skills了。
你的各种 Bot 回到家并不能给你带来任何实质性作用，朋友们兜里掏出一大把钱吃喝玩乐，你默默的在旁边和你刚部的 A助手说咋又不生效了。
亲戚朋友吃饭问你收获了什么，你说我部署了个A助手能帮我干活，还自己写了好几个牛逼的 Skills,亲戚们都懵逼了，你还在心里默默嘲笑他们，笑他们不懂 A时代，不知道自己已经是超级个体了。
你父母的同事都在说自己的子女一年的收获，儿子买了个房，女儿买了个车，姑娘升职加薪了，你的父母默默无言，说我的儿子现在整天对着个黑底白字的框框自言自语，有时候还边笑边点头。
f.分类6
中国没有 FDE，只有外包。应该是把企业流程接进AI，实现ai- native。
好像Openai那边现在有专门的驻场帮企业工作流Ai化的工程师，anthropic和openai都在推FDE，配套针对B端的定制化服务
未来3-5年内，最吃香的不是会写 Prompt 的人，而是懂行业又能把 AI 接进流程的人，俗称FDE（Forward Deployed Engineer）
d.AI关注
a.分类1
@bourneliu66 小排老师，我进入互联网和vibe coding领域的启蒙导师，我看了小排老师所有的在付费社群和互联网找得到的文章，每一篇都让我醍醐灌顶。小排老师是我见过最强的超级个体，最顶尖的产品经理。
@Khazix0918 卡神，我进入AI领域接触到的第一个大V，不只教AI技巧，更重要的是教会我"在AI时代如何思考"——这才是拉开人与人差距的关键
@vista8 乔木大佬，分享了超级多实用的github仓库以及AI实战干货。目前是我mark帖子数量number one的大佬。最新的飞书文档复制干货你学习了吗~
@dotey 宝玉大佬，中文AI圈的顶流和信息枢纽。他会把硅谷最前沿的AI播客深度解读，帮助我加深了很多关于AI的理解。
@dontbesilent12 don哥，自媒体的神，他的内容创作思路打开了自媒体的上帝视角，正在重塑我的系统，让我开始思考与AI协作内容创作的新方式
b.分类2
@oran_ge 橘子大佬，listenhub创始人，最新的“互联网已死，Agent永生”破圈传播，思考之深刻，这篇刷屏文只是他实力的冰山一角。平时分享的AI工具使用心得也极具洞察力。
@lifesinger 玉伯大佬，Youmind创始人。我深度用过这款产品，对小白极其友好——从信息搜集→文章创作→二次打磨，全流程丝滑。而且玉伯大佬在分享极具批判性思维思考的同时，也愿意接受不同的观点去尝试，令人钦佩。
@lxfater 铁锤哥，大家应该都不陌生，中文第一神贴作者。技术输出质量惊人，难度也惊人——很多推文我得先收藏，然后用Claude辅助才能慢慢啃下来。但啃完之后，收获巨大。
@xiaohu 小互大佬，AI热点追踪最快的人，讲解了很多关于AI的有趣的玩法。
@yetone 纯纯的技术大佬，分享了非常多技术类干货，全都进入了我的书签。但是偶尔也会整点花活，比如说claude code里面的小宠物~
c.分类3
@op7418 歸藏大佬，分享顶级的AI设计作品和提示词。还会分享很多好玩实用的AI工具，最近开发的UI更好看的Claude Code，正准备用一用呢。
@gkxspace 温总，我在推特遇上的最牛的同龄人，在自媒体、AI和创业等领域的认知都十分超前。我的推特起号就是把温总所有帖子都拆解了一遍，受益无穷。跨领域学习者，我非常敬佩。
@Leobai825 天策哥，同龄人中的行动派天花板，不管是咸鱼项目，还是回老家正在做的旧照片修复项目，都体现了卓越的执行力和真诚感。每条推文都是实战复盘，十分有深度。
@Zesee Rachel姐，00年的老板，对AI的相关思考十分深刻，输出很多干货的同时极具活人感，评论区的自问自答十分有意思@Rourou0413。
d.分类4
@Pluvio9yte 雪踏乌云，技术大牛。分享 AI 实战和出海知识的干货达人，各种《Hermes Agent 从 0 到 1 教程》、《Harness Engineering 驾驭工程》质量都非常高。
@Zesee Rachel，前微软和亚马逊员工，现 AI 营销平台创业者。不仅分享很多 AI 实用干货，也分享 AI 产品的开发过程和行业洞察。
@yaohui12138 柿子，AI 产品经理。擅长用产品思维拆解 AI 产品，日常分享AI搞钱实战、编程系列教程以及AI工作流实操等干货内容。
@AI_Jasonyu 鱼总说AI，中文独立开发者 + AI 实战内容创作者。专注于 AI 工具实战、出海产品经验、SaaS & APP 变现等内容。
@AshlynHe1129 Ashlyn，AI配饰创业者。既被何一主动问候并关注，也被竞品高调抄袭，已经充分说明了这个账号的含金量。平时分享个人成长、品牌历程和行业思考。
e.分类5
@skaas777 Jason，ManuCN AI 社区创始人、AI 创业者。正在进行 365 天开发 365 个项目的挑战，我从他的项目开发中学到了非常多的干货。
@servasyy_ai ServaHuang，古早程序员出身。分享 AI 生图、Openclaw 和 Claude Code 实战技巧、AI 出海干货，涵盖的领域非常广。
@nftbanker 小将 欧洲 GenAI 大会主办方、最大的欧洲华人出海社区创始人。如果你对 AI 副业、出海创业、Web3 感兴趣，他的推文是高质量的信息源。
e.Qwen路线
a.分类1
就这两天时间 qwen 的 4 个核心骨全部离职了
而且是在 Qwen3.5小尺寸模型系列（0.8B~9B）发布之后，这个模型还被 Elon Musk点赞好评了，
据说有人都伤心哭了，跟汇报线调整和，用DAU消费类指标考核有关，
b.分类2
林俊旸，Junyang Lin，X: @JustinLin610
角色：Qwen技术负责人（通义千问大模型掌舵人）、阿里最年轻P10级技术专家（副总裁级）
背景：2019年北大毕业后加入达摩院，2022年起主导Qwen全栈研发、开源生态、多模态与工程化，是Qwen从0到1的核心灵魂人物
离职时间：3月3日下午正式向阿里提出辞职，3月3日晚/4日凌晨在X发帖
影响：新接手人选传为今年初从Google DeepMind加入的周浩（Hao Zhou，前Gemini系列高级研究员）
c.分类3
Binyuan Hui，X: @huybery
角色：Qwen Code负责人（原MTS）
背景：Qwen代码/编码相关核心技术负责人
离职时间：2026年1月已正式离职加入Meta，3月3日晚在X引用林俊旸帖文发“bye qwen, me too.”
d.分类4
郁博文
角色：Qwen后训练（post-training）负责人
离职时间：3月3-4日同期正式离职
后续：职位由前DeepMind高级研究员周浩接手（周浩直接向阿里云CTO、通义实验室负责人周靖人汇报）
e.分类5
Kaixin Li，X: @kxli_2000
角色：Qwen3.5、Qwen VL（视觉）、Qwen Coder等核心贡献者/研究员
离职时间：3月4日凌晨也在X发布告别帖
02.常用信息2
a.AI道德
a.分类1
虽然有时候（Anthropic CEO Dario）这个想法确实傻逼，但现在看来确实硬。他不是针对中国，他他妈是针对所有人，我操。
Anthropic 这个事，昨天还只是这两家公司之间的问题，现在已经席卷了整个美国政界和 AI 界。
感觉这是国家和政府在 AI 领域的第一次严肃对抗。以前这类事情虽然也有，但这次终于被挑明了。
政界和 AI 界的负责人基本上都被逼着站队。以前还能含糊其辞，现在没办法了。
b.分类2
Anthropic 的底线主要有两个部分：
1.禁止 AI 对美国人的监控
2.禁止使用 AI 直接驱动完全自主的武器
昨天不是有个最后通牒吗？看起来是谈崩了，特朗普也发话了，就是说合同必须允许任何“合法用途”。
然后要求任何与美军业务往来的承包商、供应商和合作伙伴，都不允许与 SRP 有商业往来。第一个感觉是，自己把自己整进美国的实体清单了，我操。
发言的其他意思就是 Anthropic 故意在模型上调教，以此迎合这种“觉醒”意识形态，暗示不爱国。
c.分类3
产业上的态度是两边都有。萨姆（Sam）昨天明确地罕见表态说，虽然他跟 Anthropic 有一些分歧，但是认同 Anthropic 的观点。
他也相信 Anthropic 是真正在关注 AI 安全。但是嘴上一套说的是这样，然后反过来 OpenAI 很快地跟国防部达成了一个协议。
然后马斯克非常讨厌 Anthropic这套左翼思想，所以他依旧是反对 Anthropic 。
意思是他之前的（宪法 AI）里，比如说那个宪法中，有涉及到反西方文明的内容。
d.分类4
谷歌这边的员工旗帜鲜明地反对越过红线，但高层也在与国防部进行谈话，想要达成协议。
然后伊利亚（Ilya）也罕见地发声，表示同意 Anthropic 的看法，并赞扬了 OpenAI 的声明。
他认为这是一个对未来更艰难局面的预演，号召 AI 界团结到一起，跟美国政府这种越过底线的行为做抗争。
感觉从昨天和今天开始，产业界和美国政府这种对抗就开始了。看看到最后会达成一个什么样的妥协方案吧。
b.AI道路
a.分类1
太过于真实！程序猿变了！
LV1：从装上Copilot插件，开始尝鲜AI补全，感觉打开了新世界。
LV2：谨慎使用AI工具，边用边审视，生怕它搞出什么幺蛾子。
LV3：彻底放飞，AI说什么都对，一路“Yes”全盘接受。
LV4：告别图形界面，命令行里直接召唤AI，效率至上。
LV5：让不同大模型互相审查代码，AI内卷从此开始。
LV6：随时随地OpenClaw（可能指某种AI编程硬件或工具），编程无处不在。
LV7：走上讲台，开始教别人如何用AI编程，成为AI时代的布道者。
AI浪潮之下，程序员的角色不断演进——从使用者到驾驭者，再到传播者。时代变了！
b.分类2
Cursor工程师提出的观点：
1.代码自动补全（如早期 Copilot Tab）。
2.同步 Agent，A 在编辑器中实时处理复杂任务，但受限于本地环境和单次交互。
3.云端长期运行 Agent，AI 代理可 24/7 不间断构建、测试、迭代项目。
-------------------------------------------------------------------------------------------------
人类几乎不再手写代码，Token 成为燃料。
第三个阶段（云端长期 Agent）正在加速来临，TRAE、CC、Codex 等基座模型厂商的 Agent 正在收敛纯粹的 Vibe Coding
c.AI碎碎念
a.分类1
经过两三个实际项目的使用，作者对AI编程的看法发生了明显改变。
-------------------------------------------------------------------------------------------------
作者近期使用CodeX配合GPT-5.4进行开发，初期体验十分惊艳。
由作者制定计划、划定范围、补充约束、拆解需求，AI负责具体开发，可快速完成页面、接口、基础逻辑、重复性代码的编写，
在项目初期、代码量小、上下文简单、目标明确的场景下，效率提升十分显著。
-------------------------------------------------------------------------------------------------
基于初期的良好体验，作者一度认为AI编程已非常成熟，未来开发者只需负责提需求与做判断，具体实现可完全交给模型完成。
连续完成两三个项目后，作者的看法发生转变，意识到AI可深度参与开发，但无法真正接管开发。
b.分类2
项目进入持续迭代阶段，功能、业务、代码量不断增加时，CodeX的表现明显下降，功能实现质量不稳定，简单功能也需多次反复调试才能完成。
AI的核心问题并非不会写代码，而是难以在不断扩大的工程中，长期稳定理解整个系统。
其只能针对当前任务给出实现，难以理解模块边界、性能要求、团队默认的工程共识等隐性约束。
项目开发的难点不在于编写代码，而在于判断代码编写位置、实现合理性、是否破坏已有逻辑、可维护性，这些现阶段仍需开发者掌控。
-------------------------------------------------------------------------------------------------
AI不能掌握代码控制权，可高效完成初版生成、重复劳动、提供实现思路、局部重构、编写测试、整理注释文档等工作。
但架构设计、边界控制、技术取舍、代码落地与质量把控等核心工作，必须由开发者掌控。
AI是执行能力强但长期一致性不足的搭档，适合小任务，在复杂业务、长期演进、多轮迭代场景中容易偏离方向。
AI可辅助编写代码，但无法对项目整体负责，更合理的方式是开发者主导，AI辅助提速，控制权始终掌握在开发者手中。
d.聊天工程师
a.分类1
惊！公司都是“聊天工程师”：每天的工作就是“聊天”当工程师变成“聊天工程师”：生产力跃迁的新序幕
这是当下知识工作者工作流最核心的变化：过去十年我们学编程语言、学设计工具、学框架规范，
现在我们学的是“怎么和AI高效聊天”。这不是职业的降级，而是生产力工具革命带来的必然身份跃迁。
b.分类2
传统语境里的工程师能力，很大比例是“对工具规则的熟练掌握”：
软件工程师要背语法、记API、踩各种框架的坑；产品经理要会用Figma、会画流程图、会写标准化的PRD。
这些能力本质上是“把人的想法翻译成机器能理解的语言”，而AI的出现直接把这个翻译层给自动化了。
今天你不用再记住Go中各种语法，只要和Claude Code说“我要写一个支持断点续传的文件上传工具，错误场景要覆盖全”，
它就能输出可运行的初稿；你不用再一个个拉组件画原型，
只要和OpenClaw说“帮我设计一个内容审核后台的界面，包含列表、筛选、详情页三个模块”，就能直接拿到可交互的原型。
c.分类3
但“聊天工程师”的门槛一点也不比传统工程师低，反而对能力提出了更高的要求：你得能把复杂需求拆成AI能理解的清晰指令，
你得有足够的专业判断力分辨AI输出的错误和漏洞，你得有全局视野帮AI补全它看不到的业务上下文。
本质上，“聊天”只是交互形式，核心能力是对问题的抽象能力、对业务的理解能力、对技术方案的判断能力——这些才是AI替代不了的硬实力。
只会打字聊天不懂技术底层的人，哪怕问再多问题，也拿不出可落地的方案；真正优秀的工程师，借助AI的能力能把原来3天的工作压缩到3小时，
把精力从机械劳动中解放出来，聚焦真正有创造性的决策和设计。
d.分类4
这个变化的本质，是人类终于可以从“和机器规则对齐”的劳动中解脱出来，让机器反过来“和人的自然语言对齐”。
未来不会有纯粹的“程序员”或者“产品经理”，所有的知识工作者都会是“聊天工程师”：你负责提出问题、定义方向、判断结果，AI负责承接所有重复性的执行工作。
这不是职业的消失，而是职业的升级——当工具足够聪明，人的价值只会越来越贵
e.AI“外卖大战”开启
a.事件背景
近期Anthropic与OpenAI同步推出大规模补贴活动，类似此前国内外卖大战，用户可大幅薅取福利。
b.三大核心补贴事件
a.Anthropic 100万token上下文不加价
此前Claude Sonnet模型超20万token需2-5倍溢价，现Claude Code默认使用Opus 4.6模型，
1M上下文窗口全量开放且无额外加价，超长工作流任务处理能力提升，或冲击传统RAG框架。
b.Anthropic闲时用量翻倍
3月13日-27日，非高峰时段（美东8:00-14:00，即北京时间21:00-次日3:00）所有用户用量翻倍，
免费用户也可参与，覆盖网页版、桌面版、Claude Code等全平台，额外用量不计入周限额；
对国内用户而言，正常使用时间多为闲时，可享2倍额度，周末全天翻倍{insert\_element\_0\_}。
c.OpenAI Codex全线翻倍，送两个月
2月起所有付费计划Codex限额翻倍，活动持续至4月，推动Codex周活从不足50万暴涨至160万，一个月增长超3倍。
c.补贴带来的用户影响
a.用户使用习惯更奔放
补贴后用户AI使用量大幅增加，如Codex主账号2天用完双倍周限额，用户多账号订阅高套餐，类似外卖大战中用户点单量与支出同步上升。
b.中转站模式失去优势
官方套餐性价比远超中转站，20美元/月套餐实际token消耗价值超600美元（约0.3折），
200美元/月套餐消耗价值超1万美元，而稳定中转站多以2-6折售卖，官方套餐更划算。
d.核心观点与趋势判断
a.抓紧薅取补贴，聚焦产品验证
补贴期应快速跑通产品验证、积累用户，这些是补贴结束后可带走的核心资产。
b.优先使用官方顶级模型套餐
顶级大模型已大幅降价，应克服困难使用官方包月套餐，保障使用质量。
c.模型差距缩小，生态成核心护城河
模型能力差距持续缩小，竞争转向工具链与工作流深度绑定；Anthropic押注长上下文，OpenAI聚焦Codex，目标是让用户形成使用依赖。
03.常用信息3
a.AI明星
a.Claude Max（PM 设计师 主管 运营 市场小全能 兼记忆）
Opus 4.6 主力，Sonnet 跑 subagent，Haiku 做批量探索。管 SSOT、记忆系统、整条工作流。
b.Codex（策略码农）
GPT-5.4 跑在 Codex CLI 里，策略代码、数据 Pipeline、独立 review 都安排给它。
c.Grok（情报员）
终端调 Grok Bridge 查 X 实时搜索和链上消息，入口也用命令行不是网页。
d.Copilot CLI（实习生）
10 美金一个月，买的是 GPT-4.1 和 GPT-5 mini 的无限量额度，零散任务全扔给它。
b.AI公司
a.网易云
丁磊的成功秘诀：开除速度一定要快！！！
b.CodeX
OpenAI自2026年2月中旬开始将OpenClaw创始人招致麾下，并在两个月内将OpenClaw的核心技术融入Codex
Codex Monitor 作者被 OpenAI 收编了，后面会致力于 Codex APP 开发。虽然作者说 Codex Monitor 继续保持开源，但估计不会在上面投入太多精力了
c.Karpathy
OpenAI 创始团队、前 Tesla AI 总监的 Karpathy，
Karpathy 作为特斯拉前 AI 和自动驾驶视觉总监、OpenAI 创始成员，他对 LLM 行为模式的观察本身就自带分量。
d.SpaceX收购Cursor
4月22日，马斯克的火箭公司SpaceX宣布，600亿美元收购AI编程初创公司Cursor。
该交易将让马斯克进一步追赶OpenAI、Anthropic等竞争对手，也为Cursor提供更多算力。
SpaceX在社交平台上表示，与Cursor的合作将开发“全球最有用的模型”。
e.meta公司（前facebook）
Manus (2025年12月)： 这是一个重磅收购，Meta斥资数十亿美元收购了这家有中国背景、总部位于新加坡的AI智能体（Agent）初创公司。
Limitless (2025年12月)： 收购了AI可穿戴设备初创公司，前身是Rewind。该团队以开发售价99美元的AI挂件产品闻名。
Scale AI (2025年6月)： Meta斥资148亿美元收购了AI数据标注巨头Scale AI 49%的股份，并与其合作启动“超级智能实验室”（Meta Superintelligence Labs）。
技术人才/团队收购 (2025-2026年)： 此外，Meta在4个月内还进行了多次专注于AI初创公司创始人的收购（Acqui-hiring），其中包括Dreamer、Moltbook等团队的加入。
c.AI岗位
a.架构师
基本上就是公司的CTO，对底层技术极为了解，对用户需求也很了解，专注设计底层架构和技术设施搭建（打比方是建筑设计师）
b.后端工程师
主要是环境搭建，后端代码指挥AI写，更偏重稳定性和可维护性（打比方是打地基和钢筋骨架的蓝领）
c.前端工程师
指挥AI写代码，只要是面向用户需求交付软件，包括界面、控件细节、UX交互和动画细节等，
主要是让用户用的满意，只需要有基本的前端工程师经验，但是要更侧重用户端，
兼具产品经理的需求分析能力和设计师的色彩敏感性（打比方是装修队，用户说了风格，自己全搞定）
d.Agent开发工程师
基于现有后端数据和业务逻辑做工作流的那种，然后再抛出数据到前端。
e.总结
以后，工程师如果不管用户需求，还处于看板任务来什么就写什么，基本上都会被淘汰，
因为懂需求和具备业务敏感的工程师驱动AI写代码比你一个一个的慢慢手磨代码的效率要快100倍
懂业务、善于沟通、有编程思维的人才是AI时代的工程师所需的基本素质
d.AI裁员
a.AI替代
AI干掉了文员
ChatGPT干掉了文案
云盘干掉了U盘
网课干掉了补习班
自助机干掉了收银员
新能源干掉了燃油车
共享干掉了私藏
数字货币干掉了银行卡
硅基干掉碳基
下一个，轮到传统制造业工人+低端白领（如基础客服、数据录入、初级会计）。
2026年机器人成本暴跌、AI智能体规模化，工厂焊接装配、仓储分拣、快餐服务、酒店清洁全面自动化，重复性岗位大量消失，服务业软件化吞噬人工
b.AI流程
据了解，杭州这边体制外大小公司都在疯狂尝试用AI跑通业务流程，跑通一个小流程小裁员，跑通一个大流程大裁员
渐进式跑通逐步缩减公司用人规模，有些甚至只要跑通80%就可以替换大部分员工，
目前烧token再贵也没有贵到雇佣成本，尤其是每年社保基数持续上涨的大背景下。
这其中公司内原本就是负责信息搬运加工的，受到AI冲击最直接最容易被裁，接着是研发/开发/设计，
然后是需要和人对接的销售/商务，但不管何种岗位，未来用人需求大缩减是大趋势，能AI替代的用AI替代，
实在不能地少量人力外包辅助AI完成关键节点，百人公司缩减为十几人，十几人缩减为几人，几人最后缩减为单人公司，实现成本最低。
我觉得未来体制外打工人，得改变思路，找工作不再是说服老板我能比竞争对手强在哪里，
而是我能在哪方面比用AI更有性价比，工资也不是同行对比，而是和token费用比。
c.AI员工
最近看到一堆xx 公司前端团队解散、xxx 公司裁员的消息，我一点情绪波动都没有，这本身就是迟早会发生的事情。
资本就是算账的。当一部分工作可以被更低成本更高频率地完成时，组织结构一定会被重写。
比如我自己连续一个月高强度，上周五直接累倒。
但同一时间 AI 不会累，还在那边 7×24 跑任务，甚至两个情绪波动都没有。
是的，AI 做出来的东西有时候还糙，但一旦拉长时间轴去看，它的成长速度远远不是线性的。
今天看起来是能用但不稳，很可能过一段时间就是稳定且更便宜。比如 google stitch，去年那个样子，今年已经悄悄惊艳了所有人。过去这半年太多这样的划时代产品了。
回到岗位本身，很多岗位今天感受到的压力，过去某一个时间点当感受到性价比开始变得越来越清晰的时候就应该动起来。
也别认为自己现在的岗位好，真正的压力也不在今天，全在未来某一个节点，还不错+很便宜+随时可用，这三件事一旦同时成立，这个岗位就会被重新定价。
个体能做的选择也很有限，要么提前预判，经历一段焦虑，然后尽快补齐能力断层；要么有足够的缓冲，去等待一个对人类更友好的新结构出现。没其他退路。
d.AI说法
Hacker News 有篇讨论挺火：《Why I'm Not Worried About Running Out of Work in the Age of AI》。
评论区照例分成了两派——一派说 AI 要取代所有程序员，另一派说这只是又一次技术革命，没什么好怕的。两边都有道理，但也都说对了一半。
我的看法：AI 不会导致大规模失业，但它会重塑工作形态。那些被淘汰的人，不是因为 AI 太强，而是因为他们从未真正理解自己工作的核心价值。
说人话就是：会看到大量裁员失业，顶级的人产出会被极大放大；而平庸的人，寻求其他就业机会，降低收入预期。
AI 确实在替代某些任务，但它同时创造了新的工作形态。但换个角度想：如果你是那个"非常有才华的人"，这意味着什么？
工具变强了，但管理思维还停留在工业时代。让我说句可能得罪人的话：如果你的核心竞争力是编码速度，那你确实应该担心。
但真正优秀的程序员，核心竞争力从来不是这个。AI 最擅长的是什么？是把清晰的指令变成代码。
但它不擅长什么？是理解模糊的需求、是在技术约束和业务目标之间做权衡、是在一堆烂代码中找出真正的问题所在。
为什么？因为基层员工在用 AI 做更多执行工作，而高管在用 AI 做更多决策工作。
这揭示了一个残酷但重要的事实：AI 放大了你的能力，但也放大了你的定位。
这说明了什么？未来最稀缺的不是会用 AI 的人，而是能用 AI 解决复杂问题的人。
现在呢？工具越来越强，但优秀程序员的价值反而更高了。AI 不会取代你。但会用 AI 的人，可能会取代不会用 AI 的人。
e.AI说法
现在厂子里已经出现一些现象，有点意思。
客服感觉要被干掉，去抢数据分析的活
设计感觉要被干掉，去抢前端的活
前端感觉要被干掉，去抢后端的活
产品感觉要被干掉，直接vibe coding
业务感觉老子原来求着你们，现在老子用dify和Claude code直接一把梭
-------------------------------------------------------------------------------------------------
距离国内软件行业大裁员还有接近 2 年的时间
为什么是接近 2 年呢？因为在AI领域，一个范式从 在国外出现，到圈内热议，再到国内公司大规模应用的周期，就是 2 年。
在国外 AI Coding 领域，这 3 年经历了3次范式变迁：
1.AI 辅助编程：将 AI 作为 Linter、搜索引擎、代码补全工具
2.Vibe Coding：与 AI 结对编程，也是大部分人用 Cursor 的方式
3.Harness Engineering：程序员设计强约束、可观测、可评估、可反馈、可回退的编码环境，由 Coding Agent 自主完成所有编程工作
-------------------------------------------------------------------------------------------------
3的核心思想是 —— 程序员不写一行代码，如果发现 AI 写出不好的代码，第一要务不是指导他改，而是排查环境中哪一环出了问题，修复环境。
举个例子：当 AI 写的前端代码有 bug，首先应该排查是不是在”可观测性“上不足（比如接入 Agent Browser 让他能自己走查页面）
当前国内主流编程范式是 2，还是大量需要程序员参与。当 1 年多 2 年后，3 成为主流范式，就会出现程序员裁员潮
缺粮 10% 的结果不是粮食涨价 10% ，而是一直涨价到饿死 10% 人为止。同样，主流范式进入 3 会一直让“主要工作职责能被 3 能力范围（也就是业务开发的所有编码工作）覆盖的程序员”全部失业
04.常用信息4
a.AI插件
a.说明
名称：Claude Code Chat
艾特文件：搜索框，模糊搜索
恢复检查：restore checkpoint
对话模式：只需要勾选Plan Mode，它会老老实实只讨论、不写
模型模式：Think / Think Hard / Think Harder / Ultrathink
授权所有权限：右上角设置 -> Enable Yolo Mode (Auto allow all permissions)
b.优点
无需终端：优雅的聊天界面即可完成所有交互，告别命令行。
恢复检查点：随时撤销更改，回溯到任意历史版本
MCP 服务器支持：内置完整的 Model Context Protocol 服务器管理
对话历史：自动保存并管理全部会话与历史记录
VS Code 原生集成：深度嵌入 VS Code，完美适配主题与侧边栏
规划与思考模式：“先规划后执行”及可配置的思考模式，带来更优结果
智能文件/图片上下文 & 自定义命令：可引用任意文件、粘贴图片或截图，并创建自定义命令
模型选择：按需切换 Opus、Sonnet 或默认模型
Windows / WSL 支持：兼容原生 Windows 与 WSL 环境
c.缺点
1.无法同时跑多个任务。而这是我的刚需。
2.部分功能有bug，不是特别流畅，比如刚刚提到的历史记录恢复功能。
3.无法使用Claude Code在7月底刚刚推出的Sub Agents功能。
d.可视化设置MCP
点击对话框下方的'MCP'按钮，可以完全可视化的方式选择MCP，不需要任何命令行。
我建议你全部添加它默认列表里的全部MCP，因为这些真的对开发过程很有帮助。
b.AI分析url
a.问数据
https://www.toolify.ai/self-api/v1/top/month-top?page=1&per_page=200&direction=desc&order_by=growth
阅读这个网址，全部内容装到上下文里，然后回答我问题：本月访问量100万~300万之间,月度增长超过50万有哪些
b.分析数据细节
它们流量是怎么来的？
c.结合自己的项目来提问
再结合我的项目问问题，当前打开的项目是我的Raphael AI，https://raphael.app
这是一款全球火爆的免费文生图、图生图的产品。就算是用户不注册不登录，也可以不限数量地生成图片。
我打算问问看，我们这个产品，可以从榜单分析中，得到哪些启发？
d.让Claude Code推荐值得关注的产品
再问问看，榜单有啥异常值，值得我特别关注的产品？
仔细看榜单,还有哪些比较异常的情况,为我做新产品提供依据,尤其关注很创新的产品
c.AI安装mcp
a.坐标
找到世界顶级的Claude Code Sub Agents到底在哪儿，https://github.com/wshobson/agents
b.安装
https://github.com/wshobson/agents
把这些Agents 全部安装到我的 ClaudeCodeClI里，跳过重复的
c.结果
稍等片刻，它全部安装完了，一共帮我安装了73个Agent！
这个任务，一共消耗了超过300K Token，总时长30分钟。
d.AI提交日志
a.方式1
第一步：精准选择待提交文件
无即便是我们并行开了很多个Claude Code/Codex、分别在编辑多个文件，我们也可以精准选择本次需要提交哪些内容。
方法是：在已更改文件文件区域(Changes)，找到具体文件，点击文件名后面的加号(+)， 可把修改记录放到暂存区(Staged Changes)
如果点歪了，可以到Staged Changes区域找到文件，点文件后面的减号 ( - )， 重新把一个文件放回到Changes区域
-------------------------------------------------------------------------------------------------
第二步：点击AI自动生成代码提交信息
确保需要提交的文件在Staged Changes区域后，点击 VS Code / Cursor 提供的自动生成Git记录按钮。
示例：下图编号2的红圈。
由于在第一步，我们已经精准选定了所有当前需求相关的文件，此时生成的提交记录，会非常精确。
b.方式2
让Claude Code帮你提交，请打开Bypass permission，提前授予Claude Code所有权限
-------------------------------------------------------------------------------------------------
帮我提交代码，只提交和本次修改内容有关的文件，提交记录写规范点，用中文
-------------------------------------------------------------------------------------------------
注意观察它的操过过程： Claude Code 会自动把本次功能所涉及的文件，放到Staged Changes区域。 （当然，它是通过命令行的形式，而不是点击按钮）
然后，再进行了代码提交。=Claude Code只提交了本次功能相关的部分、写了规范的提交记录； 把和本次修改无关的内容，继续留到了Changes区域。
e.AI操作自己
a.别名
使用 claude --dangerously-skip-permissions 来提前授予claude code一切权限
alias ai="claude --dangerously-skip-permissions"
b.安装mcp
我现在的IP地址是哪个国家
升级我的claude code到最新版本，并且告诉我最新版本更新了啥
给我的claude code安装mcp magicdesign，你自己上网搜索想办法搞定
列出已安装的 MCP；根据我的使用场景给出推荐清单并自动安装；把每个 MCP 的用途、主要命令、典型风险写成一页 MCP-README.md。
c.AnyVoice产品
@modelcontextprotocol/server-filesystem - 文件系统操作
@modelcontextprotocol/server-github - GitHub 集成
@modelcontextprotocol/server-postgres - PostgreSQL 数据库操作
@modelcontextprotocol/server-aws-kb - AWS 知识库（用于 S3 存储）
@modelcontextprotocol/server-fetch - 网络请求
@modelcontextprotocol/server-shell - Shell 命令执行
d.自然语言，精准定位历史聊天
在我最近20条操作claude code记录当中，有一个是关于数据库性能的，是哪一条，找出来，恢复对话，我要继续聊
然后我就可以继续对话了，继续完成今天早上还没完成的任务了。
f.AI丝滑操作
a.多开
使用Cursor或者VS Code作为IDE，安装官方插件，保证Claude Code可以和IDE协同。
打开Bypassing Permissions模式，提前授予Claude Code一切所需权限，完全解放双手。
同时打开3个Claude Code，复杂任务，使用ultrathink，杜绝AI偷懒的可能性。
(注：这是Claude Code内部的魔法口令，可以让它不考虑预算、尽情思考。）
b.贴图
需要让Claude Code看图时，使用Ctrl+V (而不是command+V) 可以贴图。
contenxt7和browsermcp两大MCP，可以加快网站类产品的开发效率
c.查看历史聊天记录
使用 /resume 可以查看历史聊天，或者接着聊。
再打开LIVE TOKEN USAGE MONITOR，实时查看Claude Code省了多少钱
d.Cursor+ClaudeCode
1.Cursor 安装 ClaudeCode
2.在 IDE connected 状态下，如果Claude Code修改了文件，它会使用IDE的其他功能，如修改预览
3.上文提到的按钮，连续点3下，就能打开3个，虽然可以同时打开多个
4.但只有你最后打开的那一个，可以和IDE保持协同。
5.保持和IDE协同的那一个，会出现绿色的小圈和IDE connected
e.使用其他模型进行规划
Claude Code 有一个内置的规划模式，当你按两次 Shift+Tab 时触发。在这种模式下，Claude 不会写入你的文件系统。
不过我个人喜欢用另一个模型进行规划，只是为了增加一些变化。
在过去的几周里，我一直在直接使用 Google AI Studio 中的 Gemini 2.5 Pro。
f.使用语音输入
像 Superwhisper 这样的应用程序使得听写提示变得非常容易。我发现当我想写一个更长的提示时这非常有效，因为它会更快地将想法从我的脑海中提取出来。
这对任何 LLM 输入字段都非常有效，因为 LLM 通常可以理解你的意思，即使转录很差且充满错误。
在国内，我们可以使用豆包电脑版；豆包电脑版是可以当成语音输入法来使用的，它的能力超过一切其他语音输入法！
g.使用 Git 进行版本控制
我在 Claude Code 中缺少的一个功能是制作自动文件系统快照的能力。
我经常遇到 Claude 变得有点过于激进并开始在我不想要的时候进行大规模更改的情况。
如果这发生在我已经得到一些好的更改之后，这可能会搞乱工作目录。
为了规避这个问题，我开始早期和经常地暂存（即 git add）更改。
如果我在一轮后满意，我通常会暂存所有内容，这样我就知道我可以稍后轻松地恢复到它。
h.使用 Git Worktree
我对 Claude Code 如此着迷，以至于我现在在我的机器上为我工作的每个主要项目至少有两个工作树。
这允许我让 Claude 在同一个仓库中处理两个不同的问题。
设置也很容易！就像创建一个分支，但代码将在不同的目录中。在你的 git 仓库内运行：
git worktree add ../tailwindcss.com-2 chore/upgrade-next
瞧，你现在有另一个工作目录让 Claude Code 尽情发挥。
g.AI搭配对话
a.思路
在项目中，同时打开Claude Code和Codex，你甚至可以用一个模型让他自己左右脑互博
1.让Claude Code出方案
2.把方案发给Codex进行评审，挑刺
3.把Codex挑刺的内容发给Claude Code，问它是否同意（往往会同意）。如果同意，开始补充计划；如果不同意，把为什么不同意，复制给Codex，问问它的看法
4.两者对方案达成共识后，让Claude Code写代码
5.让Codex对代码进行Review，重复步骤3
6.两者对代码达成共识后，提交代码
b.实战
背景：我让Claude Code完成了creem支付的接入，改动比较大，想让Codex进行检查
思路：我告诉Codex一个git提交的ID (Commit ID)，让它自己去检查
A问：这个git提交8fcae5eaac3f8a022025a82c1330de4f99bf4268 是我写的creem支付代码，请你检查，结合creem官方文档，看看我们写对没，是否有疏漏
B答：这是别人对git提交8fcae5eaac3f8a022025a82c1330de4f99bf4268 的代码审核，你同意它的看法吗? 请你独立思考，多上网搜索调研
c.结论
Claude Code正在对审核意见内容进行逐一核实
Claude Code同意了一部分Codex的观点，并且做了一些补充
接下来我让他俩‘左右互搏’几轮，直到完全达成一致！
h.AI项目思路
a.和Claude Code沟通新需求时，用飞书文档写需求，做到「任何人看都没有歧义」。需求描述超过1000字，图文并茂，然后复制给Claude Code
尝试让Claude Code直接写代码，是新手最容易犯的第一个错误。特别容易把代码改成屎山。
一定要意识到：如果代码成了屎山，这不是Claude Code的问题，是你的问题。
新手并容易不知道自己是否把需求描述得没有歧义，他们会倾向于甩锅给AI。
b.新需求首次沟通时，末尾强调 「不要急着写代码！先理解需求，给出实现思路，我们先讨论，看还有啥需要我决策的点？」
尝试让Claude Code直接写代码，是新手最容易犯的第二个错误
有同学问题我，为什么不用Plan Mode？ 是的，Plan Mode可以得到类似的效果，但是，切换模式有点麻烦了。我喜欢提前授予Claude Code一切权限，解放双手。
一般而言，新需求，需要反复讨论3～5轮，直到Claude Code完全找不出来下一个需要你决策的点，我们再让它开始写代码。
我尽量打码敏感信息，给大家展示一下一部分讨论过程。可以看出，我的回复是非常长的，事无巨细。这是从飞书文档里复制粘贴出来的。
完全讨论清楚后，只需要回复「同意」或者「开始」
c.涉及界面需求时：快速纸上画布局，然后让Claude Code用ASCII画出来，最后提醒它拆分控件
A.关于画草图，最快的是在纸上画，也可以在Excalidraw上画，怎么快怎么来。无论怎么画，Claude Code都能明白你的意思。
B.关于ASCII画图，你可以让Claude Code出3~5种不同的布局，然后你来选择。
C.最后，在开始编码前，强调让Claude Code仔细理解项目结构，尽可能合理地拆分控件、并把控件放到合适的位置。这也是新手常见坑，如果不做强调，Claude Code可能会写出来单文件很大的控件。
i.AI界面设计
a.思路
截图
让它使用Playwright MCP查看当前情况（可选）
让它用ASCII画出来布局
b.完整的指令如下
我新上的功能, Hero区域, 你有什么建议吗?
我要世界顶级的交互设计,简洁、专业.你拥有我所有代码的阅读权限,
以及，这是线上地址https://raphael.app/background-remover
你可以使用playwright mcp访问它，和代码对比查看
你可以提出5种不同的方案,使用ASCII画出来,和我讨论
c.操作过程
收到指令后，Claude Code按照指令，查看我的相关代码、并且打开浏览器查看了当前效果，辅助它理解
接下来，Claude Code使用ASCII画出了5个方案
Claude Code做出了推荐，给出了推荐理由，如下图所示。
五分钟后，Claude Code已经写完了雏形，然后它自己打开了浏览器，开始检查。如下图所示。
2.2 模型发展
00.汇总
a.分类1
Grok 4.20
Gemini 3.1 Pro
Claude Sonnet 4.6
GPT-5.4 和 GPT-5.4 Pro 发布了
GPT-5.4 深度评测：最适合 OpenClaw 的均衡基座模型
GPT-5.4系列：AI能力向执行层下放与分层协作
b.分类2
Gemini Embedding 2，原生多模态嵌入模型
Grok 4.20 Multi-Agent登顶BridgeBench
GLM-5-Turbo
MiniMax M2.7
MiMo-V2
Luma，图片模型
Chandra OCR 2：能保留结构的开源OCR模型
Anthropic泄露神级模型Claude Mythos
GPT-Image 2 图像模型全量上线
GPT-5.5这次真正值得关注的，不只是“更聪明”
Google发布新模型 Veo 3.1 Lite 直接把视频生成成本砍一半了
c.分类3
阿里Qwen3.5-Omni全模态大模型核心概述
MiniMax M2.7 正式开源了！🚀
腾讯混元HY-World2.0开源概况
百度开源的文生图模型，仅 8B 参数即可在开源文生图领域达到 SOTA 水平
GLM-5.1 正式开源
01.常用信息1
a.Grok 4.20
a.说明
速度接近单模型，智能远超单模型；彻底解决幻觉、单一视角、创意瓶颈
b.全团队，4 Agents
Grok（队长）：整合者 + 人格核心（Big Picture + 最终决策 + xAI 式幽默）
Harper：探索者 + 事实守护者（广度信息 + 实时核查）
Benjamin：收敛批判者 + 逻辑守门人（深度验证 + 主动挑刺）
Lucas：创意调和者 + 用户共情者（发散 + 平衡 + 表达优化）
c.关键技术栈
MoE专家路由器：一个轻量meta-router（~1B参数）在inference第一步就把查询路由到4个“角色专家”（Grok队长、Harper研究、Benjamin技术、Lucas创意），同时激活。
共享KV Cache：四个代理完全共享同一份KV Cache（键值缓存），额外延迟仅<50ms（相比独立运行节省90%+内存和时间）。
并行Test-Time Compute：推理时真正并行（GPU上4路同时计算），非顺序。
内部辩论机制：结构化多轮（默认3-5轮）
RL-orchestrated debate：
Round 1：各自独立输出中间结果
Round 2：交叉验证（peer review）+ 矛盾检测
Round 3：RL策略选择最优共识（奖励模型打分：准确性+创新性+简洁性）
b.Gemini 3.1 Pro
a.说明
全新 Gemini 3.1 Pro 正式上线，在 **ARC-AGI-2 测评中取得 77.1% 的好成绩——在核心推理能力上比 3 Pro 提升超过 2 倍！
b.说明
这个版本拥有更强的基础智能，能够轻松应对超复杂任务，比如：可视化难理解的概念、将大量数据合成为一张易读视图、让创意项目快速成型落地
c.Claude Sonnet 4.6
a.路线
Skills → Subagents → Agent Teams
AI编程工具3个月迭代了3代，token消耗从1x干到15x
b.特性
Skills：知识工具包、上下文在当前窗口，不开新会话；适合简单重复任务；复杂任务搞不定
Subagents：独立代理、全新上下文窗口，支持多任务并行；适合复杂多步骤任务；单兵作战，互相不通信
Agent Teams：代理团队、多个Agent组队，各有完整上下文，互相通信；适合大型项目协作；token消耗是普通的15倍
c.说明
1️.1M token 上下文(beta)——整个项目一次喂进去
2️.Computer Use 大升级——多标签页复杂操作
3️.价格不变，编码能力接近 Opus 4.5
d.GPT-5.4 和 GPT-5.4 Pro 发布了
a.前言
GPT-5.4各种测评级的数据我就懒得分析了 ，反正刚发布的模型 肯定各种能力分数都是屌炸天 说点实际的
b.核心优势
a.最重要：在Codex里用GPT-5.4可以使用1M上下文
b.GPT-5.4 各方面能力都领先 Claude Opus 4.6和Gemni-3.1 Pro ，代码能力更不用说（其实实测下来， gpt-5.3-codex代码能力已经超过Claude Opus 4.6蛮多）
c.GPT-5.x 系列一直以来的"不怎么说人话"的问题得到了很大的缓解
d.Token 的利用效率得到了进一步提升，换句话说，同样多的Token和同样多时间内能够把活儿干得更好更快 图3
e.原生且顶级的 Computer Use能力。可以考虑用它自动操作电脑图形化界面了，不在限制于浏览器自动化了。不久的将来应该会有一波 Computer Use Agent 的创业浪潮
e.GPT-5.4 深度评测：最适合 OpenClaw 的均衡基座模型
a.背景与期待
文章针对 OpenClaw 等 Agent 系统寻找“默认基座模型”的痛点，指出模型不能仅具备单点强项（如仅代码强），
而需在代码、世界知识、多模态理解三项核心能力上保持均衡，且价格与接入便利性也是关键考量。
b.竞品对比分析
过去的选择存在两难：GPT-5.3-Codex 代码执行极强但缺乏“人味”，世界知识与表达生硬；Claude Opus 4.6 虽然均衡自然且体验好，
但价格昂贵，订阅额度难以顺滑接入外部系统，导致大规模使用成本失控。
c.GPT-5.4 核心优势
GPT-5.4 被视为“天选模型”的原因在于它补齐了所有短板：
1.保留了 Codex 级别的代码执行力。
2.补强了世界知识，使其能理解业务与真实意图。
3.工具使用能力更像真正的 Agent（如原生计算机使用能力）。
4.表达更自然，会说“人话”，提升了协作体验。
d.关键升级点
模型迎来了战略级升级：100 万 token 上下文窗口大幅提升了长任务的连续性；
原生计算机使用能力结合视觉理解，增强了环境交互；工具搜索机制实现了按需加载，优化了上下文工程。
e.市场定位与结论
相比于 Claude 的“高性能跑车”定位，GPT-5.4 更像是一辆易于驾驶且性能强劲的高性能轿车。
它在能力、价格、表达和可接入性上达到了完美平衡，解决了 OpenClaw 用户长期面临的模型选型困境。
f.核心总结
a.模型定位
GPT-5.4 终结了模型“偏科”问题，首次在代码、知识、多模态及表达上实现全面均衡。
b.技术突破
100 万 token 上下文窗口、原生计算机使用能力及动态工具搜索机制。
c.应用价值
结合 OpenAI 生态的订阅便利性，成为 OpenClaw 等系统最理想的默认主力模型。
f.GPT-5.4系列：AI能力向执行层下放与分层协作
a.核心定位
此次更新不在于模型本身，而在于将 GPT-5.4 的能力下放至“执行层”。
新发布的 GPT-5.4 mini 和 nano 旨在补齐 AI Agent 体系中的高频执行、并行处理及低成本落地环节，标志着 AI 从单体强大向分层协作体系演进。
b.模型分工与定位
a.GPT-5.4 mini（高配执行型助手）
定位为能够承接复杂子任务的执行层，擅长即时代码辅助、承接大模型拆解的子智能体任务，以及处理复杂 UI 截图等 computer use 场景。
其在代码、推理、多模态及工具调用方面表现优异。
b.GPT-5.4 nano（极致效率节点）
不追求最强性能，而是追求极致速度与成本效益。适用于分类、数据抽取、排序等简单重复性任务，是自动化流程中理想的基础执行节点。
c.未来AI架构趋势
a.分层协作模式
AI 应用将不再依赖单一最强模型，而是形成分层体系：大模型负责规划与拆解，mini 负责复杂子任务执行，nano 处理海量简单任务。
这类似于真实团队的分工，让决策层与执行层各司其职。
b.成本与性能平衡
新的定价使得大规模应用成为可能。企业可以将过去因成本高昂而“不舍得跑”的任务放心交给小模型批量处理，从而真正落地自动化。
d.核心总结
a.架构演进
未来 AI 竞争力在于“规划层 + 执行层 + 工具层”的完整体系，而非单一模型能力。
b.应用策略
采用大模型带小模型的策略，大模型负责决策攻坚，小模型负责并行执行与低成本落地。
c.经济性
新价格体系（mini 0.75/4.5美元，nano 0.20/1.25美元）大幅降低执行成本，释放 AI Agent 规模化潜力。
g.Claude Opus 4.7模型发布概况
a.说明
Anthropic正式发布Claude Opus 4.7模型，在核心能力、视觉思考及工具平台方面均实现重要更新。
b.核心能力提升
a.长时任务处理
可处理时长更长的任务。
b.指令执行精度
指令执行更加精确。
c.输出自我验证
汇报前会进行输出自我验证，可在更少监督下完成长时间工作。
c.视觉与思考增强
视觉能力大幅提升，可精细查看图像，支持接收长边最长2576像素的图像。
d.工具与平台更新
a.新增审查命令
Claude Code中新增Ultra Review命令，专用于内容审查。
b.新增思考等级
新增xhigh思考等级，位于High与Max之间。
c.自动审批模式开放
自动审批模式向Max用户开放使用。
02.常用信息2
a.Gemini Embedding 2，原生多模态嵌入模型
a.说明
谷歌发布了 Gemini Embedding 2，这是他们第一个原生多模态嵌入模型。
它的强大之处在于能把文字、图片、视频、音频、PDF文档全部转换成同一个向量空间，
让不同类型的内容可以互相比较相似度，理解跨模态的语义意图。该模型支持超过100种语言，在多模态任务上性能领先。
它让AI真正懂你想找什么感觉的东西。例如你想找"治愈的雨天午后"的感觉，它能同时从你的照片、视频、语音笔记、文字日记里挑出最匹配的片段。
未来的相册、笔记、短视频推荐和搜索都会变得聪明很多，你随便描述或发张图，它就能跨格式找到最像的内容。
b.说明
大多数时候只需在聊天框或搜索框输入一句话描述，系统后台自动把你的话转成向量，去数据库找最相似的媒体片段，再用大模型整理成自然回答。
高级点可以直接上传图片或短视频片段作为查询去搜相似的东西。
它是让AI从只会读文字，升级到能同时看图、听声、读文档、懂感觉的幕后关键技术，未来很多App会因此变得更好用。
b.Grok 4.20 Multi-Agent登顶BridgeBench
a.发布背景
xAI正式发布Grok 4.20 Multi-Agent系统，在全球权威AI基准测试BridgeBench上以96.1的惊人总分一举夺冠。
不仅完胜GPT 5.4，还把Claude Sonnet 4.6和Claude Opus 4.6两大顶级对手甩在身后，稳稳拿下榜首第一名。
b.核心成绩
整体得分：96.1
任务完成率：100%
平均延迟：仅87.8秒
c.核心总结
a.市场地位
Grok 4.20以96.1分刷新BridgeBench纪录，全面超越GPT-5.4及Claude全系列。
b.性能表现
实现了100%的任务完成率，并将平均延迟控制在87.8秒，展现出极致效率。
c.行业意义
标志着多代理架构在实际基准测试中正式战胜传统单体模型。
c.GLM-5-Turbo
a.模型定位
这个模型是专门用来面向 OpenClaw 这种 Agent 的场景深度优化的。
输出速度非常快。它的提示遵循和工具链调用很稳定，在前端的表现上也不错。
【智谱AI】GLM-5-Turbo龙虾增强模型发布！ 面向OpenClaw场景深度优化，ZClawBench国产第一。
龙虾套餐同步上线，企业个人灵活订阅，低成本实现tokens自由。即刻超值养虾https://chatglm.cn/share/JF1mmWIN 拒收请回复R
b.核心能力
据他们自己说，这个模型在以下核心能力上都变得非常强，并做了专项的迭代：工具调用、指令遵循、定时和持续任务、长程执行能力。具体比如说：
Tool Calling：强化了调用 Web 工具和 Skills 的能力
复杂指令拆解：复杂指令拆解能力更强
定时任务：定时任务和长时间的任务不中断（这个很重要）
长链路高吞吐：即数据量大、链条长的任务，执行稳定性更强
c.实测体验
a.输出速度
我自己试了一下，做了几个任务，发现它的输出速度相当快，应该是同级别模型里面最快的。
b.上下文处理
同时我自己有个 AI 助理，需要加载非常多的上下文，因为涉及到我的日程、各种项目的完成情况，还有我好几个 memory 文档。
其实跟龙虾（Openclaw）的场景也差不多了，它很快就读到了所有相关的信息，而且没有错误，返回信息也巨快。
c.前端能力
然后，第二个为什么说它前端强，是因为我之前不是自己做了一个 Claude 的生成式 UI 能力吗？
那个其实非常考验模型对多模态前端位置的判断，以及画图时（尤其是 SVG 画图）的准确性。
还有就是这个东西具体应该用什么样的 UI 去表示，其实也非常重要。
因为这类型用户通常不会告诉你用什么方式或图表去展示，你需要自己选一个合适的图表。
---------------------------------------------------------------------------------------------
日程生成，我先是让它生成了我这周的日程（通过读取我的记忆来生成）。
我发现它生成的表现形式非常好：
两周分得很清楚、时间分配展示
每一天都用条形图的方式去表示，让你能大概知道任务分配在哪个时间段。
---------------------------------------------------------------------------------------------
训练过程解释，第二个是又试了一下让它解释大语言模型的训练过程。
虽然整个画得很复杂，但所有的地方都很规整，没有出现错位的情况，
这个即使是 Claude Sonnet 有时候都会出错。当然，另外它画得也很快。
d.价格与适用场景
他们现在还为这个模型去做了一个新的龙虾套餐，价格相当实惠。
我本来自己买了一个小的试了一下，但是看这个东西这么强，换成了那个高套餐。
而且我感觉如果你不是写代码，只是用来处理一些日常工作的话，这个东西非常合适。
d.MiniMax M2.7
a.MiniMax M2.7 发布核心概览
MiniMax于2026年3月18日发布新一代Agent旗舰大模型M2.7，核心突破为实现模型自我进化，可自主参与研发迭代，已在MiniMax Agent与开放平台全量上线。
b.核心能力：模型自我进化
a.自进化机制
构建Agent Harness智能体执行框架，深度参与数据处理、实验设计、训练调优、评测反馈全流程，可自主完成100+轮“分析—改进—验证”迭代循环。
b.研发效率提升
部分研发场景可承担30%-50%工作量，研究员仅需关键决策介入；内部优化脚手架任务中自主迭代超100轮，效果提升30%。
c.自主优化能力
自主发现采样参数最优组合、优化工作流指引、改进Agent Loop循环检测，实现模型能力自我升级。
c.工程级编程能力
a.权威基准表现
SWE-Pro 56.22%，追平GPT-5.3-Codex；VIBE-Pro 55.6%，接近Claude Opus 4.6。
b.全栈工程能力
支持端到端项目交付、生产级Bug排查、Repo级代码重构、CI/CD编写，3分钟快速定位并修复线上故障。
c.多语言覆盖
支持C++、TypeScript、Rust、Python、Java等10+编程语言，适配全栈开发与系统调试。
d.复杂Agent与指令遵循
a.多智能体协作
Toolathon多智能体协作46.3%，跻身全球第一梯队，原生支持Agent Teams分工协作。
b.长指令遵从
40个2000+token超长复杂技能，指令遵从率97%，长链路多工具任务不跑偏、不遗忘。
c.OpenClaw适配
MM-Claw评测达62.7%，接近Sonnet 4.6，企业级Agent执行更稳定。
e.办公与娱乐场景升级
a.Office文档优化
多轮高保真编辑Word、Excel、PPT，不破坏格式；可独立读年报、设计假设，生成专业研报与PPT初稿。
b.情商与人设保持
表现接近Sonnet 4.6，适配OpenClaw人设定制，互动更具“人味儿”。
c.互动娱乐创新
开源OpenRoom项目，AI互动融入Web GUI空间，对话触发实时视觉反馈。
f.使用与价格
a.快速切换命令
x-cmd：x minimax --cfg model=MiniMax-M2.7；x claude mm 可让Claude Code无缝使用M2.7。
b.价格信息
与上代M2.5保持一致，文本输入$0.30/1M tokens，输出$1.20/1M tokens。
g.定位与对比
a.M2.7定位
全球首个自进化Agent大模型，聚焦工程级编程、复杂Agent协作、专业办公，面向深度研发与企业级生产场景。
b.与M2.5对比
M2.5为高效普惠“全能助手”，主打速度、吞吐、低成本；M2.7为专业进阶“自进化工程师”，推理成本更高但能力更强。
e.MiMo-V2
a.小米MiMo-V2系列模型发布总览
小米于2026年3月19日正式发布MiMo-V2-Pro、MiMo-V2-Omni、MiMo-V2-TTS三款顶级模型，此前代号Hunter Alpha的MiMo-V2-Pro曾在OpenRouter平台登顶日榜；三款模型将提供一周免费试用，Codepilot已支持接入，填写Key即可使用，详情可访问mimo.xiaomi.com/zh。
b.MiMo-V2-Pro（旗舰Agent编程模型）
a.核心参数
总参数超1T，激活参数42B，最高支持100万上下文，采用混合注意力架构（7:1）{insert\_element\_0\_}。
b.性能表现
Artificial Analysis榜单全球第八、中文LLM第二（仅次于GLM-5），综合表现接近Claude Sonnet 4.6、逼近Opus 4.6，在OpenClaw等Agent框架中可无干预完成复杂工作流编排与工具调用。
c.价格优势
256K上下文：输入1美元/百万Token，输出3美元/百万Token；1M上下文：输入2美元/百万Token，输出6美元/百万Token，价格仅为Sonnet 4.6的1/5。
c.MiMo-V2-Omni（全模态感知模型）
a.模态能力
原生支持图像、视频、音频、文本四模态输入，支持音视频联合推理，强调情景感知与未来预测{insert\_element\_1\_}。
b.核心优势
音频理解能力超越Gemini 3 Pro，支持10小时以上连续音频无分段处理；图像理解中复杂图表与多学科视觉推理能力超过Claude 4.6 Opus{insert\_element\_2\_}。
c.执行能力
原生支持工具调用、函数执行、UI grounding，可无缝接入各类Agent框架{insert\_element\_3\_}。
d.MiMo-V2-TTS（拟人化语音模型）
a.控制方式
支持自然语言风格指令，可通过文本描述调节语气、方言、角色声线（如孙悟空）。
b.情感与细节
支持句中情绪切换、渐变与细粒度控制，可建模咳嗽、叹气等非言语声音，以大小写、标点等作为韵律信号。
c.特色能力
中英双语为主，支持多种方言风格，同一模型可实现说话与唱歌融合，精准捕捉旋律与节奏。
f.Luma，图片模型
a.说明
Luma 发布了一个很厉害的图片模型 UN1Luma 发布了一个很厉害的图片模型 UN1
类似 Nano Banana 和 Midjourney 的集合体
b.说明
支持常识场景补全、空间关系理解和合理的画面变化；
支持多图参考、风格迁移；
支持各种文化、审美、风格的图像生成和理解，尤其是对当代视觉文化和梗图的生成；
c.说明
最重要的看起来支持中文；
详情：lumalabs.ai/uni-1
g.Chandra OCR 2：能保留结构的开源OCR模型
a.说明
做文档数字化经常遇到扫描版 PDF、论文、表格、公式等复杂场景，传统 OCR 工具结果往往是零散文本，段落顺序错乱、表格结构丢失。
Chandra OCR 2 的亮点在于能直接把图片和 PDF 转成结构化的 Markdown、HTML 或 JSON，尽可能保留原始版式。
它对复杂表格、数学公式、手写内容、多语言页面适配性强。除了提取正文，还能识别图表信息并生成描述。
支持单个文件和整个目录批量处理，适合接进日常文档流程。
b.产品定位
开源 OCR 模型，专注于将文档转换为结构化格式（Markdown/HTML/JSON）而非零散文本。
c.核心能力
强大的版式保留能力，支持复杂表格、数学公式、手写内容及 90 多种语言的识别。
d.应用场景
扫描件、合同、历史档案、论文 PDF、财务表单的数字化与结构化处理。
h.Anthropic泄露神级模型Claude Mythos
a.说明
Anthropic 因网站配置失误泄露了名为 Claude Mythos（代号“水豚”）的新模型。
这是位于 Opus 之上的第四档模型，被称为“神级”或“超级教授”。
其最显著的特性在于网络安全领域的极强攻击性，能高效挖掘漏洞。
由于成本极高且存在安全风险，官方采取“防御先行”策略，暂不对公众开放，主要供安全专家修补漏洞。
b.模型地位
位于 Claude 现有型号（Haiku/Sonnet/Opus）之上的第四档，能力远超现有最强模型 Opus。
在代码生成和漏洞挖掘方面具有极强的攻击性，可能导致黑客攻击效率大幅提升。
因成本和安全问题暂不公测，优先供网络安全专家进行防御性研究，并通过秘密峰会接触顶级客户。
c.特别说明
Claude Mythos 确认了。Claude Code 源码泄露，暴露全部底牌。
内部代号：水豚。代码中已包含 Opus 4.7 和 Sonnet 4.8 引用。
“capybara-v2-fast”支持 1M 上下文窗口，Anthropic 员工用 USER_TYPE="ant" 模式内测，拥有上帝权限。
这就是他们砍掉 Claude Opus 4.6 速率限制的原因。他们正在为下一代搭建基础设施。
d.注意事项
前几天爆料的 Anthropic 超级模型 Mythos 居然真的存在。Anthropic 说，这是他们至今为止最强的模型。
测评结果远高于 Opus 4.6，在代码理解、漏洞挖掘和利用上表现出了明显的跃迁能力，强大到他们不敢公布。
然后只用这个 Project Glasswing，有限地提供给那些互联网基础设施的服务商，去帮他们发现漏洞。
他甚至在 Linux 内核中，自主找到了多个连续的漏洞，实现了从一个无权限的普通用户提权，拿到了 root 权限。
还发现了一个 OpenBSD 存在了 27 年的老漏洞，OpenBSD 以「最安全操作系统之一」著称。还有一个是 FFmpeg 存在了 16 年的老漏洞。
他非常擅长把三五个看起来价值不大的小漏洞，组合成一个复杂的多步 exploit 变成大漏洞。
然后这个模型的价格是 $25 / $125（百万输入 / 输出 token）。本身是不会开放给公众使用的。
后续他们会把这一部分能力，放到 Opus 其他升级模型的能力里去。
我觉得这些评论其实挺有意思。表面上说是为了安全而不公开模型，但实质上也是在把最强的网络进攻武器集中到少数机构手中。
详情：anthropic.com/glasswing
i.GPT-Image 2 图像模型全量上线
a.说明
看起来 Open AI 的 gpt-image-2 模型全量上线了！
现在就可以用，效果非常顶！
第一张图我就让它可爱地解释一下大语言模型训练过程，这质量也太好了！
第二张图我就给了他一个 OpenAI 的更新文档，然后让他介绍一下这个更新，他就给了我这样的东西。 太牛批了！
然后我他给我一张北京秋天的游玩攻略长图，做得太细了，排版也非常好。
b.说明
就是现在是 1K 分辨率的，不知道后面会不会开放 2K，不过 1K 已经很厉害了。
包括这个封面图也是他自己设计的，后面还有 UI 设计。
j.GPT-5.5这次真正值得关注的，不只是“更聪明”
a.说明
GPT-5.5 这次真正值得关注的，不只是“更聪明”，而是它把三个关键词同时做到了：更强、更快、更省。
过去很多大模型升级，都会遇到一个问题：能力上去了，但速度慢了，成本也高了。
可 GPT-5.5 的信号很明确：在真实服务场景中，它基本保持了 GPT-5.4 的单 token 延迟，但在多项评测中表现更好。
b.说明
这意味着什么？
对普通用户来说，体验不会明显变慢，但复杂任务的完成质量更高。
比如写代码、做分析、处理多步骤任务，它更像一个能持续推进工作的 Agent，而不是只会回答问题的聊天机器人。
对开发者来说，更关键的是 token 使用效率。GPT-5.5 在完成同类 Codex 任务时，使用的 token 更少。
也就是说，同样是让 AI 写代码、改 bug、跑任务，它不只是更会干活，还更节省“工作成本”。
这背后其实透露出一个趋势：大模型竞争已经从“参数更大、榜单更高”，进入到“真实任务效率”的阶段。
未来真正有价值的模型，不一定只是回答更漂亮，而是能在更短时间、更低消耗下，把复杂任务完成得更稳。
GPT-5.5 的重点，不是又出了一个新模型，而是 AI Agent 的生产力门槛，正在继续下降。
k.Google发布新模型 Veo 3.1 Lite 直接把视频生成成本砍一半了
a.说明
Veo 3.1 Lite 正式上线 Gemini API + Google AI Studio！
b.说明
最划算的视频生成模型：
✅ 成本只有 Veo 3.1 Fast 的一半，速度完全一样
✅ 支持 Text-to-Video + Image-to-Video
✅ 原生横版（16:9）+ 竖版（9:16）
✅ 4秒 / 6秒 / 8秒时长
✅ 720p + 1080p 画质
03.常用信息3
a.阿里Qwen3.5-Omni全模态大模型核心概述
a.说明
阿里通义千问正式发布Qwen3.5-Omni，为原生全模态大模型，支持文本、图片、音频、视频输入输出，在215项测试中达SOTA性能，超越Gemini-3.1 Pro。
b.核心技术架构
采用Hybrid-Attention MoE混合注意力专家网络架构，基于超1亿小时音视频及海量文本、图像数据预训练，实现模态深度融合。
c.全模态理解与生成能力
a.超长上下文支持
支持256K上下文窗口，可处理10小时音频或1小时视频，生成带时间戳、场景切换、说话人映射的细粒度视频脚本。
b.Audio-Visual Vibe Coding
自然涌现音视频编程能力，可看懂手绘界面、视频需求，直接生成可运行代码与移动端UI原型。
c.多模态交互
实时输出自然语音，支持语义打断，抗背景噪音，可精准区分有效插话与杂音。
d.多语言能力
支持113种语言及方言语音识别、36种语言语音生成，覆盖小众语种，具备音色克隆、语音情绪与语速控制功能。
e.智能Agent能力
原生内置WebSearch与复杂Function Call，可自主调用工具、执行任务，具备完整自主工作的Agent能力。
f.版本与使用
提供Plus、Flash、Light三个版本，开发者可在阿里云百炼平台使用，成本低、效率高。
g.适用场景
适用于视频剪辑、UI原型设计、跨语言交互、内容创作、智能助手开发等领域。
b.MiniMax M2.7 正式开源了！🚀
a.SOTA 级开源模型直接落地
✅ SWE-Pro 56.22%
✅ Terminal Bench 2 57.0%（终端操作强悍）
✅ 完整权重已上 Hugging Face
b.说明
MiniMax-M2.7 是一个面向 agentic 编码和聊天使用场景的新开源模型。
该模型在 SWE-Pro（56.22%）和 Terminal Bench 2（57.0%）上取得了 SOTA 性能。
该 230B 参数 （10B 激活）模型是 MiniMax-M25 的后继模型，并拥有 200K 上下文 窗口。
未量化的 bf16 需要 457GB。Unsloth Dynamic 4-bit GGUF 将大小缩减到 108GB (-60%) ，
因此它可以在 128GB RAM 设备上运行: MiniMax-M2.7 GGUF。最值得关注的不是参数量，而是这个模型参与了自己的进化。
M2.7 在训练过程中自主优化了 100+ 轮编程框架，性能提升 30%。它自己更新记忆、构建复杂技能、改进学习流程——这不是人调的，是模型自己调的。
MLE Bench Lite（22 场机器学习竞赛）拿到 66.6% 奖牌率，仅次于 Opus 4.6 和 GPT-5.4。
d.代码能力
SWE-Pro：56.22%（追平 GPT-5.3 Codex）
SWE 多语言：76.5%
生产环境故障恢复：3 分钟内
多 Agent 协作，角色稳定不串戏
e.专业办公
GDPval-AA ELO 1495，开源模型最高
Word、Excel、PPT 高保真编辑，输出可编辑文件
MM Claw 40+ 复杂技能合规率 97%
还有个 OpenRoom，实时视觉交互 demo，娱乐场景也没落下。
部署支持 SGLang、vLLM、Transformers，FP8 量化可用。
c.腾讯混元HY-World2.0开源概况
a.说明
腾讯混元团队开源多模态世界模型HY-World2.0，可从文字、图像、视频构建并模拟交互式3D世界，项目已上线GitHub与Hugging Face平台。
b.核心亮点
a.一键生成三维世界
支持文字或图片输入，自动生成可交互3D场景，大幅降低3D内容创作门槛。
b.工业级管线支持
兼容Unity与Unreal Engine，可导出Mesh、3D高斯泼溅、点云等标准格式，便于集成至游戏或模拟器。
c.统一的世界模型系统
打通虚拟合成与现实世界场景的生成和重建，单模型支持凭空创作与现实还原。
d.实时交互与角色模式
具备物理感知、移动与碰撞检测功能，支持角色操控探索，拥有真实物理反馈。
c.获取方式
开发者与创作者可申请访问权限或查阅技术报告。
d.百度开源的文生图模型，仅 8B 参数即可在开源文生图领域达到 SOTA 水平
a.说明
百度开源的文生图模型，仅 8B 参数即可在开源文生图领域达到 SOTA 水平。
这是百度出的开源文生图模型，用 Diffusion Transformer 架构，自带一个提示词增强器能把简单描述扩写成详细的结构化提示。
b.说明
8B 参数的规模在 GenEval 等测试里表现不错，尤其擅长处理带文字的图片、复杂多物体的场景和海报漫画之类的结构化内容。
有标准版和 Turbo 版，Turbo 版 8 步就能出图，24G 显存的显卡就能跑。
e.GLM-5.1 正式开源
a.说明
开源权重 + API 同步上线，明天就能在 http://Z.ai 平台玩到
b.说明
开源模型里 SWE-Bench Pro 拿下 #1（58.4），全球第 3
真正长时程 Agent：自主运行 8 小时、几千次迭代 + 自审循环
从零搭出一个带 50+ App 的完整 Linux 桌面（视频太炸了）
Vector-DB-Bench 性能直接 6 倍提升
2.3 瑞士军刀1
00.汇总
a.Claude1
2.1.5
Cowork
Worktree
ToolCalling
RemoteControl
AutoMode
Memory1
Memory2
loop命令1
loop命令2
Knowledge Work Plugins
Computer Use
Claude Code UltraPlan上线
用iMessage跟Claude Code交互
上线了Auto Mode 自动模式
Claude Code 的 Telegram 插件
Claude Desktop 现在支持第三方 API 了
b.Claude2
语音模式
Agent 团队
38+ 连接器
Cowork 项目
定时任务
插件市场
持久记忆
100万上下文窗口
Dispatch 远程控制
Telegram & Discord 渠道
还能直接用电脑运行应用
c.Codex
Subagents
ComputerUse
AI接入内网
SSH连接远程环境
版本速报，v0.116.0
01.Claude
a.2.1.5
a.语言设置
/Config -> Language -> 简体中文
b.粘贴图片更加友好
现在粘贴多个图片后，可以用箭头按钮，选择不同的图片。如果把鼠标放上去，还会显示图片的路径。
对了，还修复了以前偶尔出现的 "Image was too large" 错误。
c.Skill支持热重载
之前的痛点: 修改 skill 后必须重启整个会话
现在: ~/.claude/skills 或 .claude/skills 中的 skill 保存即生效
d.Sub-agents 分叉上下文
之前的痛点： sub-agents太多，会污染上下文、会占用原本就宝贵的上下文窗口长度
现在：Skill 可以在独立的子代理中运行，不污染主上下文。五、Ctrl+B 统一后台运行
现在 Ctrl+B 可以同时将所有正在运行的任务（包括所有bash命令、sub-agent等等）放到后台。
而且，后台任务完成后显示干净的完成消息，不再是乱糟糟的原始输出。
e.可以使用/plan命令触发计划模式
以前的痛点：需要按shift+tab切换到plan模式。这非常麻烦，尤其是我长期使用Bypass Permission Mode，不喜欢切换来切换去的。
现在：在任意位置打 /plan 即可在当次对话中使用计划模式，进入“对需求”阶段，而不用担心误操作代码。
我们可以在使用bypass permission on的同时，用/plan来做计划了。
f.云端和本地同步，会话传送
会话传送，这可真是太懂用户痛点了。
我们知道，其实Codex和Claude Code都有云端版本，但是以前被人诟病的是：云端和本地版本，很难协调。
本次Claude Code解决了这个问题，允许用户在本地终端和 Web 界面之间无缝切换。还可以恢复和配置远程会话、与团队成员共享会话
只需要输入 /teleport 命令，就可以把当前会话传送到云端，使用云端资源继续执行。
g.通配符权限
之前: 每次运行命令都要点 Yes，权限疲劳
现在: 支持 * 通配符！
h.Shift+Enter 多行输入开箱即用
之前: 需要修改终端配置，非常麻烦。
现在: iTerm2、WezTerm、Ghostty、Kitty 等终端直接支持
i.Slash 命令自动补全增强
之前: / 必须在输入开头才能触发补全
现在: / 在输入的任何位置都能触发自动补全
比如图中的/commit 是我自定义的一个帮我审核代码、提交Git的Slash命令。
j.实时思考过程显示
在Claude Code思考过程中，我们可以使用 ctrl+o ，切换显示它的思考过程，
以便于我们及时发现思考中的问题、及时干预。
k.MCP 动态工具更新
引入了新功能: 支持 MCP list_changed 通知
MCP 服务器现在可以动态更新其可用的工具、prompts 和资源，无需重新连接！
这对于工具配置频繁变化的工作流非常有用。
l.报错后自动继续
以前：有时候由于响应太长，会因 output token 限制被截断。比如，如果我们用Claude Code自动操作浏览器，遇到内容比较长的网页，就会遇到这个问题。
现在：不会出问题了！Claude Code会在报错后自动继续，不展示错误信息，不会中断。
m.所有Skill默认在菜单中可见
似乎Claude Code这次是认真把Skill当成一等公民来对待了，所有在 /skills/ 目录下的skill，都会默认出现在菜单中，敲入斜杠就可以看看。如下图所示
b.Cowork
a.说明
Cowork：Claude面向非开发人员的代码
如果你一直在使用 Claude Code，并且希望也能将这种智能工作流程应用到日常工作中，那么 Cowork 就是你的理想之选。
Cowork 现在面向 macOS 上的 Claude Max 订阅用户提供研究预览版。
b.说明
你只需将 Claude 指向电脑上的一个文件夹，它就能读取、编辑和创建其中的文件，其自主性远超普通聊天工具。
它会制定计划、执行计划，并在并行处理多个任务的同时，随时向你汇报进度。
他们举了一些例子：自动整理下载文件夹、从屏幕截图创建电子表格、从零散的笔记中撰写报告
它可与您现有的连接器配合使用，并具备一些用于创建文档和演示文稿的新功能。将其与 Chrome 中的 Claude 结合使用，它还可以处理浏览器任务。
c.Worktree
a.说明
Claude Code Worktree：面向开发者的并行任务管理
如果你在使用 Claude Code 时经常需要同时处理多个功能分支，又不想频繁切换上下文或等待任务串行完成，那么 Claude Code Worktree 就是为你设计的。
Worktree 功能基于 Git Worktree 机制，让 Claude Code 能够在同一仓库中同时操作多个独立的工作目录。
b.说明
你只需在 Claude Code 中启动多个 Worktree，它就能在相互隔离的 Git 分支上并行执行任务，互不干扰。
每个 Worktree 拥有独立的工作目录和分支，Claude 可以在不同分支上同步推进不同任务
你可以同时让 Claude 在一个分支修复 Bug、在另一个分支开发新功能，无需等待前者完成
任务之间完全隔离，避免了传统 git stash 切换带来的上下文混乱风险
每个子任务完成后，Claude 会汇报结果，你可以随时查看各分支进度并决定是否合并
典型使用场景包括：并行开发多个 Feature、同时处理多个 PR 的 Review 修改，以及在不打断主线开发的情况下快速验证实验性想法。
d.ToolCalling
a.说明
Advanced Tool Use：面向 Agent 开发者的工具调用架构升级
如果你一直在构建自动化 Agent、长任务 Agent 或 MCP 集成工作流，并且希望解决 token 浪费、多轮往返和 context 污染问题，那么这次升级就是为你设计的。
Advanced Tool Use 于 2025 年 11 月正式发布，现已全面支持 Claude Opus 4.6、Sonnet 4.6 等最新模型。
b.说明
这次更新的核心，是让 Agent 从"模型拼 JSON 打乒乓球"升级为"模型直接写代码编排工具"，架构上发生了本质变化。
Programmatic Tool Calling：模型直接生成 Python 代码调用工具，用 for loop 批量处理、条件判断控制流程，中间结果在沙箱里消化，不再污染 context；官方测试 token 消耗降低约 37%，复杂任务准确率同步提升
Tool Search：工具定义不再全量加载进 context，Claude 按需动态检索，将工具定义消耗从 77K+ tokens 压缩至 8.7K，节省约 85%；MCP 场景下准确率从 49% 提升至 74%
Tool Use Examples：在工具定义中加入真实调用示例，解决 JSON Schema 无法表达日期格式、ID 格式、参数关联等使用惯例的问题；复杂参数准确率从 72% 提升至 90%
Dynamic Filtering：Web Search 场景下，Claude 先过滤网页内容再加载，不再将整页 HTML 塞入 context；输入 token 减少约 24%，搜索准确率提升约 11%
e.RemoteControl
a.功能概述
Claude Code 推出了 功能，这下手机也能指挥电脑干活了。简单说就是你在公司用电脑写的代码，回家躺床上用手机也能继续捣鼓。
b.核心优势
a.数据安全
Claude Code 一直在你本地跑，手机只是远程显示和控制，数据不走云端。
b.多设备支持
电脑、手机、平板、甚至另一个浏览器都能同时连，实现多设备无缝切换。
c.连接稳定性
要是电脑休眠或者网络断了，只要重新连上，进度都在，不会丢，断线自动重连。
c.操作指南
a.开启方式一：直接开启新会话
在项目目录输入 claude remote-control，终端会跳出一个 URL 和一个二维码，手机一扫，直接在 Claude App 里接着聊。
b.开启方式二：半路接管
如果你已经在电脑上聊一半了，输入 /remote-control（或者简写 /rc），也能瞬间生成远程连接。
c.使用技巧
输入 /remote-control 之前，先用 /rename 给这个会话起个好听的名字，省得在手机上找不着。
d.使用限制
一个会话同时只能被一个设备远程控制。电脑上的终端不能关，关了会话就断了。
断网超过 10 分钟会自动超时。目前只有 Pro 和 Max 用户能用这个功能，Team 和 Enterprise 暂时不行。
f.AutoMode
a.特性概述
Claude Code 推出了 auto mode 特性。它让 Claude 自主完成文件写入和 bash 命令的权限决策。
这直接取代了以往每次操作都需要手动批准或完全跳过权限的模式。
ClaudeCode新增Auto模式，解决复杂任务中频繁弹窗确认的问题，可自动判断操作风险并放行或拦截。
b.运行机制
在每次 tool call 之前。一个 classifier 会审查操作是否属于潜在破坏性行为。
安全操作自动执行。风险操作则被立即阻断。Claude 会切换到其他替代路径。
c.Auto模式工作原理
每个工具调用执行前，系统运行分类器检查风险，高风险操作直接拦截，常规操作自动放行无需确认。
批量删除文件、向外发送敏感数据、执行可疑代码等操作会被自动拦截。
该模式比--dangerously-skip-permissions更安全，但存在一定风险，建议在隔离环境使用。
该机制集成了 safeguards 作为核心防护层。它有效降低了整体风险暴露。但并未彻底消除潜在问题。官方明确建议在隔离环境中运行。
d.使用指南
启用方式为执行 claude --enable-auto-mode 命令。随后通过 Shift+Tab 进行模式切换。
当前作为 Team 计划的研究预览开放。企业版与 API 支持即将上线。
e.适用对象
这个特性适合 AI 开发者。也适合日常使用 Claude Code 进行本地自动化编码的软件工程师。以及需要在安全可控环境下迭代复杂项目的团队成员。
g.Memory1
a.功能介绍
Claude 上线了“Import memory from other AI providers”功能，通过提示词让 ChatGPT 等竞品导出存储的记忆和背景信息。
一键导入 ChatGPT/Gemini/Grok 等记忆，切换 Claude 无需从头开始
这个功能意图非常明显，抢其他 AI Agent 用户。以前切换 AI 最麻烦就是我使用久了，使用记录和记忆偏好等不容易迁移，
现在 Claude 开了这个头，相信很快就会普及。对用户来说也是好事，我可以随时导出我的记忆，到我更喜欢的工具，没有迁移成本。
b.操作流程
a.在当前 AI 中导出记忆
在下面页面点击 “copy prompt”
https://claude.com/import-memory
这里的 prompt 明确规定了输出格式，便于 Claude 解析，列出 6 大类重要记忆，并要求 AI 不要总结或遗漏，最后检查内容是否完整。
b.在 Claude 中导入
打开 Claude 设置 → Capabilities → Memory 区域，点击“Start import”；或从首页的“Import memory to Claude”卡片进入。
将上一步的导出文本粘贴进文本框，点击“Add to memory”。
c.核心总结
如果想应用到其他 AI 助手，可以用提示词来导入，比如：
这是我之前使用某AI的记忆，请为我完整导入，作为你的记忆，请注意处理这份记忆和你之前记忆的冲突，如需确认请提示我（大家可以自己优化提示词）
h.Memory2
a.Managed policy（组织级）
位置: /etc/claude-code/CLAUDE.md
用途: 组织编码规范、安全策略
共享范围: 全组织
b.Project memory（项目级）
位置: ./CLAUDE.md
用途: 项目架构、团队约定
共享范围: 团队成员
c.Project rules（模块化规则）
位置: .claude/rules/*.md
用途: 模块化规则，支持路径匹配
共享范围: 团队成员
d.User memory（用户级）
位置: ~/.claude/CLAUDE.md
用途: 个人跨项目偏好
共享范围: 仅自己
e.Local memory（本地私有）
位置: ./CLAUDE.local.md
用途: 项目特定私有配置
共享范围: 仅自己
f.Auto memory（自动记忆）
位置: ~/.claude/projects/*/memory/
用途: Claude 自动记录的模式
共享范围: 仅自己
g.最有意思的设计
1.Auto memory - Claude 自己写笔记（"我们用 pnpm 不是 npm"）
2.路径特定规则 - YAML frontmatter + glob 模式限定适用范围
3.200 行限制 - 强制 http://MEMORY.md 简洁，超出的按需读取
4.http://CLAUDE.local.md 自动 .gitignore - 敏感信息不进入版本控制
i.loop命令1
a.核心功能
a.功能概述
Claude Code 新增的 /loop 命令猛啊，可以连续三天帮你执行重复性任务，最细的粒度可以到每五分钟执行一次。
b.应用场景
这下把 Openclaw 的定时任务也搞来了，比如可以帮你定时审查 github 的 PR 或者每天帮你总结相关信息进行提醒。
结合我的 Feishu 或者 Telegram Skills 可以定时给你的手机推送信息了。
b.使用指南
a.核心入口
核心入口是内置技能 /loop，你可以写成 /loop 5m check the build 或 /loop check the build every 2 hours。
也可以不写间隔让它默认每 10 分钟跑一次。
b.时间单位与格式
支持的时间单位有秒、分钟、小时、天，内部会把你给的间隔解析成 5 字段 cron 表达式，必要时会做四舍五入并告诉你结果。
c.组合命令
循环内容本身也可以是其他命令，比如定期执行 /review-pr 1234 来复用已有工作流。
d.一次性提醒
一次性提醒不用 /loop，而是直接用自然语言，Claude 会自动创建只触发一次、执行后自删的任务，并用 cron 表达式固定到具体的分钟和小时。
c.任务管理
a.交互方式
任务管理可以直接用自然语言和 Claude 交互，让它列出当前所有任务或取消某个任务。
b.底层工具
底层有三个工具：CronCreate 用来新建任务，CronList 用来列出任务及 ID 和调度信息，CronDelete 用任务 ID 删除任务。
每个任务有 8 位 ID，每个会话最多 50 个任务。
d.执行机制
a.调度逻辑
调度器每秒检查一次到期任务，并以低优先级入队，只会在你回合之间插入，不会打断 Claude 正在回答的问题。
b.执行时机
如果到点时 Claude 正忙，会等当前回答结束后再执行一次，不会为错过的每个时间点补发。
所有时间都按本地时区解释，cron 类似 0 9 * * * 就是本地早上 9 点。
e.参考资料
a.详情链接
code.claude.com/docs/en/scheduled-tasks
j.loop命令2
a.背景痛点
开发者在终端常需执行耗时任务，传统AI工具执行完指令即停止，需反复手动查询进度，导致大量重复操作，
以往需用watch命令或手写Bash脚本、crontab轮询，操作繁琐。
b.新特性介绍
Claude Code推出/loop定时任务功能，可在当前会话设定智能定时器，
让Claude后台自动定期执行自然语言Prompt，灵感源于Unix Cron机制与代理自动循环概念，实现自然语言交互与周期性任务结合。
c.使用示例
a.基础循环任务
/loop 5m check if the deployment finished and tell me what happened
/loop check the build every 2 hours
b.单次提醒任务
/loop in 45 minutes check whether the integration tests passed
c.结合自定义技能
/loop every 20m /review-pr 1234
d.社区观点与核心价值
核心价值为上下文感知，传统定时脚本仅执行命令输出日志，Claude可结合项目上下文检查报错、分析日志，
发现问题后可定位错误并生成修复代码，对复杂、跨语言、长周期项目价值显著。
e.实现逻辑与注意事项
a.实现逻辑
Claude解析自然语言时间间隔，转换为Cron表达式，调度任务并生成任务ID。
b.低优先级队列
调度器每秒检查到期任务，放入低优先级队列，任务为会话级别。
c.使用限制
绑定单个终端Session，退出进程失效；单会话最多50个任务，最长有效期3天。
f.总结与未来展望
/loop切实解决开发者工作流被打断的痛点，结合时间调度器与LLM推理能力；未来有望对接后端持久化队列，
实现Agent云端24小时监控项目，进一步拓展应用边界。
k.Knowledge Work Plugins
a.Anthropic开源Knowledge Work Plugins项目
Anthropic 官方开源了 Knowledge Work Plugins 项目，该项目是专为知识工作者设计的插件仓库，
主要集成于 Claude Cowork 平台，同时兼容 Claude Code。
b.插件架构特性
a.纯文件化架构
插件采用纯文件 based 架构，所有组件均为markdown和JSON格式，无需代码编写、基础设施部署及编译构建步骤，可直接使用。
b.标准文件组成
每个插件包含固定文件与目录结构：.claude-plugin/plugin.json清单文件、.mcp.json连接器配置文件，以及commands目录和skills目录。
c.十一个角色专属插件
项目开源11个针对不同岗位的插件，覆盖productivity、sales、customer-support、product-management、marketing、
legal、finance、data、enterprise-search、bio-research领域，另含cowork-plugin-management插件用于插件的创建与定制。
d.插件核心功能模块
a.skills自动触发模块
各插件的skills部分封装对应岗位的领域专业知识、工作流程与最佳实践，会根据会话上下文自动触发，为工作提供针对性帮助。
b.commands主动调用模块
支持slash commands斜杠命令，用户可主动触发特定操作，示例为/data:write-query、/sales:call-prep、/finance:reconciliation。
c.外部工具连接模块
插件通过MCP servers实现与外部工具的无缝连接，可对接各岗位常用的CRM、项目管理、数据仓库、设计工具等各类系统。
e.插件定制化方法
a.替换工具栈配置
编辑.mcp.json文件，将连接器指向公司自身的专属工具栈，适配内部工具使用场景。
b.注入企业专属上下文
在skills的markdown文件中添加公司的专属术语、组织架构与业务流程，让Claude理解企业工作场景。
c.调整工作流指令
修改skills中的操作指令，匹配团队实际的工作方式，而非标准化流程。
d.构建全新专属插件
可使用cowork-plugin-management插件，或遵循项目的标准文件结构，创建适配企业未覆盖岗位和工作流的新插件。
f.插件适配外部工具
a.通用办公工具
集成Slack、Notion、Microsoft 365、Jira等全岗位通用办公与协作工具。
b.领域专属工具
各领域插件适配专属工具，如销售对接HubSpot、ZoomInfo，数据领域对接Snowflake、Databricks，
生物研究对接PubMed、ClinicalTrials.gov等。
g.适用人群与核心价值
a.适用人群
适合部署Claude Cowork或Claude Code的技术团队，
以及产品经理、销售专员、客服人员、法务、财务分析师、数据分析师、生物研究人员等各类知识工作者。
b.核心价值
可基于插件构建高度适配企业业务的AI助手，让Claude成为跨职能专家；企业自定义的上下文会融入所有相关交互，
减少管理者流程执行的精力投入，同时有效降低跨角色沟通开销。
h.插件安装方式
a.Claude Cowork安装
直接从claude.com/plugins平台安装所需插件。
b.Claude Code安装
先执行命令claude plugin marketplace add anthropics/knowledge-work-plugins添加插件市场，
再执行claude plugin install 插件名@knowledge-work-plugins安装指定插件，安装后自动激活。
i.项目贡献方式
插件均为markdown文件，可通过Fork项目仓库、修改文件内容、提交PR的方式参与项目贡献。
j.项目地址
GitHub地址：https://github.com/anthropics/knowledge-work-plugins
l.Computer Use
a.说明1
这是 Anthropic 发布的一个非常重磅的更新：Claude Code 正式引入了“Computer Use（计算机使用）”功能。
简单来说，这意味着 Claude 已经不仅仅是一个在终端里帮你写代码、改 Bug 的大语言模型了，
它正在进化成一个能力极强的 AI Agent（智能体）。
它可以直接与本地操作系统交互，帮你打开应用程序、在图形界面（UI）上进行点击和导航，
甚至能直接测试它刚刚为你构建的项目，而这一切都可以直接从命令行（CLI）中触发。
b.说明2
这绝对是 AI 工具化的一次巨大飞跃。在日常写 Python 脚本处理自动化任务，或者进行应用和插件开发时，这种能力的想象空间非常大。
未来的开发流可能不再是“AI 写代码 -> 人工去测试”，而是 AI 写完代码后，自己打开对应的软件环境，
模拟用户的点击行为来验证 UI 交互是否符合预期。它等于给你配备了一个能自己动手操作电脑的“数字员工”。
目前这个功能还在 Pro 和 Max 计划的研究预览版（Research Preview）中。
c.说明3
Claude 的 Computer use（电脑操控） 直接集成到 Claude Code 里了！
现在你一句话就能让 Claude 自己：
-打开刚编译的 Mac App
-自动截图看界面
-自己找 bug（比如渲染卡死）
-直接改代码、重新编译、重新跑
-再点界面测试，还顺手加了个墨镜特效
从“只会写代码”直接进化成“能自己上手干活的程序员代理人”了！
目前只支持 macOS（Pro/Max 研究预览），在 Claude Code 的终端里输入 /mcp 就能开启。
m.Claude Code UltraPlan上线
a.说明1
UltraPlan是Anthropic为Claude Code推出的重磅新模式，将原本在终端卡顿的大模型规划迁移至云端网页，释放本地终端资源，可同步进行代码编写、测试等操作互不冲突。
在终端输入/ultraplan加需求指令，确认后CLI仅显示进度条并自动弹出浏览器规划界面；在网页端通过行内评论、表情反馈、侧边栏大纲审阅迭代计划；计划定稿后可选择云端执行提交PR或拉回终端本地实现。
终端不被规划占用，工作效率显著提升；浏览器审查界面交互友好，迭代速度大幅加快；可对接GitHub仓库获取代码上下文，提升结果准确性；执行方式灵活，支持云端与本地自由选择。
b.说明2
当前为研究预览版，需持有Claude Code web账号，项目需推送至GitHub，暂不支持本地纯文件夹项目。
适用于多文件重构、大型功能开发、需反复推敲方案的复杂任务，尤其适合使用Claude Code进行智能编码、受终端规划卡顿困扰的开发者。
c.说明3
UltraPlan是Claude Code的云端规划新模式，实现规划与执行解耦，优化AI编码流程。
终端发起指令，网页端完成规划迭代，支持云端PR与本地执行两种落地方式。
解放终端资源，提升规划迭代效率与代码准确性，改善复杂开发任务体验。
需Claude Code web账号与GitHub托管项目，目前处于研究预览阶段。
n.用iMessage跟Claude Code交互
a.说明1
Anthropic官方iMessage插件，用iMessage跟Claude Code交互
本地执行，双向通信（支持文字和图片）
b.说明2
可以手机发消息让Claude查文件、改代码、读取图片，并回复消息
默认只响应自己，其他联系人需手动开白名单授权，陌生人消息直接丢弃
o.上线了Auto Mode 自动模式
a.说明
Claude Code 上线了Auto Mode（自动模式）
再也不用 --dangerously-skip-permissions 了哈哈哈哈
启用方式：claude --enable-auto-mode，然后用 Shift + Tab 切换到自动模式。
p.Claude Code 的 Telegram 插件
a.在 Telegram 上 DM @BotFather
（这是生成所有 telegram bot 的地方），
输入 /newbot ，然后输入你给bot起的用户名，
不能和别人的重复，必须以 bot 结尾，然后他会给你返回一个 token，类似 123456789:AAHfiqksKZ8...
b.在 CC 上安装 Telegram Plugin
官方给的方法是在 CC 里面输入 /plugin install telegram@claude-plugins-official 。
但我没成功，是输入 /plugin ，然后在插件市场找到的，名字就是 telegram。
c.把刚才拿到的 Telegram token 给插件
在cc里 输入 /telegram:configure 123456789:AAHfiqksKZ8... ，或者直接跟 Claude code 对话，让它帮你配置。
d.重启 claude code
命令： claude --channels plugin:telegram@claude-plugins-official ，这时你在 cc 可以使用 /telegram 了。
e.和TG机器人配对
私聊你的机器人（搜你刚才填的 bot 用户名），它会回复你一个6位数的 pairing code。
在 CC 中填入 /telegram:access pair <code>，进行配对。配对成功后，CC会给你发一条消息。
f.给TG机器人加锁
使用 /telegram:access policy allowlist 让它仅能跟你配对的tg账户对话，其他人不能。
g.开始
在 TG 上和 CC 对话吧！
q.Claude Desktop 现在支持第三方 API 了
a.说明
L站的佬友们真的太聪明了
b.原理很简单
1.打开 Claude Desktop，先不要登录
2.打开菜单 → Help → Troubleshooting → Enable developer mode（启用开发者模式）
3.启用后会出现 Developer 菜单，进入 Developer → Configure third-party inference
4.填入你的 Base URL 和 API Key，选择 Apply locally 即可
配置完后就可以用中转站的 Claude 了，省 Pro 订阅的消耗。
02.Codex
a.Subagents
a.说明
Codex 支持 Subagents 了！等待很久了，非常棒，多个 Agents 可以并行工作，
每个子代理拥有独立的指令、模型设置和工具上下文，最终由主代理合并结果。
目前调用方式的话，需要主动调用，就是在提示词中命令它去创建子代理
比如：“Use subagents to review this PR in parallel:
spawn one for security audit, one for performance review, one for style & best practices.”
b.说明
Codex 中现已提供子Agent，通过启动专门的代理来加快工作流程，具体方式包括：
1.保持主上下文窗口简洁
2.同时处理任务的不同部分
3.在工作进行过程中指导各个Agent
b.ComputerUse
a.说明
OpenAI 收购 OpenClaw 的作用都在 codex app 上体现出来了
不管是速度、用户体验、系统适配、智能程度，比市面上所有开源实现都强一万倍，特别是不影响用户光标，可以在后台运行太惊艳了，真不愧是正规军
碾压包括 OpenClaw 的 Peekaboo 和字节的 Midscene，之前用 OpenClaw 需要费力调教很久的难点都能一次过，又一次 aha moment
b.自动做三件事
1.截图
2.抓取你点的那个 DOM 元素（就是页面上那个具体的 HTML 结构）
3.把这些作为精准的上下文喂给下一条对话，你只要说"把这个改成红色"，AI 就知道"这个"是哪个
c.两个主要用途
1.前端开发：改页面、调样式、修组件的时候，指哪打哪，不用再费劲描述位置
2.边查文档边问：浏览器里开着文档页面，看到不懂的地方点一下，直接问 AI "这个 API 怎么用"，AI 就拿着你点的那段文档内容回答
3.把"看东西"和"问 AI"这两件事在同一个界面里打通了，不用再在浏览器、截图工具、Codex 之间来回切换
c.AI接入内网
a.说明
现在，企业可以把自己的 MCP Server（让 AI 调用内部工具的协议服务）完全放在公司内网里，不需要暴露到公网。
ChatGPT、Codex、Responses API 这些 OpenAI 产品，会通过「仅出站 HTTPS」的安全隧道去连接这些内部服务。
b.说明
以前很多公司想让 AI 接入内部系统，但最大的问题不是能力，而是安全和合规。
谁都不想把数据库、内部工具、代码环境直接开放给外部 AI。
c.说明
这次 OpenAI 提供的方案，本质上是在解决这件事：
1.内网服务不用暴露公网
2.企业依然可以让 AI 调用内部工具
3.连接方式更符合很多公司的安全策略
4.企业接入 AI 的门槛明显降低
这其实也是 MCP（Model Context Protocol）开始真正走向企业落地的重要信号。
d.SSH连接远程环境
a.说明
新版的Codex Desktop APP已经原生支持通过 SSH 连接到远程开发环境了
特别适合你的工作依赖于不在你的笔记本电脑上的环境的情况。
b.配置
以防你不知道，以下是开启方法：
把这一串
[features]
remote_connections = true
放到这个里面
~/.codex/config.toml
然后在Codex APP里面点击设置，点击连接就有这个功能了
e.版本速报，v0.116.0
a.OpenAI Codex CLI 概览
a.项目现状
OpenAI 的 Codex CLI 是目前 GitHub 上最大的终端编码 agent 项目：67K stars、9K forks、400+ 贡献者。
3 月 19 日更新到 v0.116.0，正在从「开发者玩具」变成「企业级工具」。
b.功能定位
不要和旧的 Codex 混淆——2026 年的 Codex 已经是完整的 AI 编码 agent：理解整个项目、规划任务、执行代码、跑测试、修 bug，可以全程自动化。
b.v0.116.0 三个关键更新
a.ChatGPT Device-Code 登录
不需要手动配 API key 了。扫码登录 ChatGPT 账号直接用，和 OpenAI 生态无缝打通。对企业用户来说意味着可以用组织的 ChatGPT 订阅来管控权限。
b.User Prompt Hook
新增自定义钩子，可以在 agent 接收用户指令之前和之后插入逻辑。
比如：执行前自动加上项目约定、执行后自动跑 lint、记录审计日志。目前支持 3 个 hook（Claude Code 有 23 个），还在追赶但方向对了。
c.插件安装简化
MCP server 集成更顺滑，VS Code 扩展和 CLI 设置已同步。
c.Codex CLI 的工作方式
a.基本用法
codex "给这个函数加单元测试"
b.指定沙箱模式
codex --sandbox "重构 auth 模块"
codex --agents "修复 issue #42"
c.三种沙箱级别
a.full-auto
agent 自主执行所有操作。
b.suggest
只建议不执行，需要人工确认。
c.sandbox
在隔离环境中执行，不影响真实文件系统。
d.安全审计与定价
a.Codex Security
另外值得关注的是 3 月 21 日发布的 Codex Security——一个专门用于安全审计的 agent，可以持续分析代码库、识别漏洞、自动提出补丁。
b.定价策略
ChatGPT Plus/Pro 订阅用户自带额度；企业版按 seat 计费；API 调用走 OpenAI 标准定价。
2.4 瑞士军刀2
00.汇总
a.分类1
读取项目
实用技巧
双层智能体
模型模式
LSP集成
b.分类2
ACP集成
Agent线程
Claude生态
AgentTeam
AgentLoop
c.分类3
Anthropic源码泄露
Anthropic的Agent新架构
复刻Claude生成式UI交互
CLAUDE.md项目火爆现象
01.常用信息1
a.读取项目
a.CLAUDE.md文件
在项目根目录创建CLAUDE.md文件，Claude会自动读取：
# 项目说明
这是一个React项目
## 常用命令
启动：npm start
测试：npm test
构建：npm run build
## 注意事项
使用TypeScript
遵循ESLint规则
b.AGENTS.md文件
AGENTS.md 是一个专为 AI 编码代理设计的开放格式文件，
类似 README.md，但专门用于向 AI 提供项目上下文和操作指南。
目前已被超过 2 万个开源项目采用。
它通常包含依赖安装、测试运行、代码风格、PR 提交规范等详细说明，避免让 README 对人类贡献者过于冗长。
支持 Codex、Google Jules、Cursor、RooCode 等多种 AI 工具，并能在大型 monorepo 中分层使用。
这一格式由 OpenAI Codex(包含Codex cli 和 Codex)、Google Amp/Jules、Cursor 等共同推动，
旨在让开发者更高效地与 AI 协作，已逐渐成为 AI 编码生态的“新标准”。
c.横向对比
对比维度 MCP (Model Context Protocol) Agent Skill (技能定义) GEP
比喻 AI的「肢体」——手和脚 AI的「招式」——太极拳、咏春 AI的「DNA」——遗传智慧
解决的问题 Agent 怎么连接外部工具和数据源 Agent 怎么执行特定任务 Agent 的能力怎么跨个体传承和进化
核心能力 工具调用标准化 任务执行标准化 能力遗传 + 自然选择 + 经济激励
经验复用 ❌ 不涉及 ❌ 不涉及 ✅ 核心功能
跨 Agent 传播 ❌ 不涉及 ❌ 有限 ✅ 全球网络级传播
质量筛选 ❌ 不涉及 ❌ 不涉及 ✅ 内置自然选择机制
经济模型 ❌ 不涉及 ❌ 不涉及 ✅ Credit/声誉/悬赏体系
b.实用技巧
a.频繁使用/clear命令
AI 代理在对话持续时间越长时往往变得越不可预测。
当你问不同的问题时尤其如此。我发现，即使这意味着要重复一些指令，创建新的对话往往更加有效。
b.提供详细的上下文信息
我觉得这不言而喻，但当你与一个患有健忘症的新毕业生合作时（我喜欢这样想象 Claude），写下你脑海中所有的上下文信息是很重要的。
这很困难，坦率地说，我认为我自己还不是很擅长，但你能给 Claude 提供的上下文越多，它就越有效。
如果你想到了一些边缘情况，绝对要告诉 Claude。如果你记得"我们在这个代码库中过去为这类问题使用过类似的模式"，写下来！
提示越精确，Claude 做得越好。读心术技术还没有达到那种程度。
也要考虑任何隐含的上下文。例如，如果你要求 Claude 创建一个现代设计，它可能不知道你所指的"现代"是什么。
最好提供例子（比如，创建一个类似 Linear 的应用 UI 设计）。
c.利用任务工具进行复杂分析
你知道你可以将 Claude Code 的工具用作 MCP 服务器（claude mcp serve）吗？当我发现这一点时，我查看了它公开的工具，注意到一个叫做 Task 的工具。
这个工具的前提是启动一个子代理，它将拥有与主代理相同的工具访问权限（除了它不能生成另一个子任务），并报告结果。
当你有一个需要监督的更复杂问题时，知道这个功能很有用。以下是我最近如何使用这个功能来对同一个问题进行四个不同角色的深入分析的例子：
> 读取当前目录中的文件，推断构建 Tailwind Plus 组件的模式。你应该产生 4 个具有略微不同优先级的子任务（例如设计颜色专家、可访问性专家、移动/响应式专家、整体样式专家）并比较它们的结果。
⏺ Task(设计颜色专家分析)
⎿ 完成 (24 个工具使用 · 41.5k tokens · 3m 4.4s)
⏺ Task(可访问性专家分析)
⎿ 完成 (15 个工具使用 · 38.0k tokens · 2m 0.0s)
⏺ Task(移动/响应式专家分析)
⎿ 完成 (14 个工具使用 · 45.5k tokens · 2m 1.2s)
⏺ Task(整体样式专家分析)
⎿ 完成 (23 个工具使用 · 58.7k tokens · 2m 22.0s)
d.告诉 Claude 要"超级思考"
就像我们这些血肉之躯的老人类一样，Claude 默认情况下是懒惰的。
例如，当你告诉 Claude 做某事时，它会选择阻力最小的路径。如果你告诉它至少做三件事，我敢打赌它不会多做一件事。
对于使用扩展思考能力也是如此。为了获得更好的结果，特别是在规划过程中，我建议告诉 Claude 要"超级思考"。
e.使用 Escape 键优化对话
每当你太急于点击发送或只是觉得之前的消息可以更精确以获得更好结果时，你可以按两次 Escape 键跳转到之前的消息并分叉对话。
我一直使用这个功能来完善提示或简单地让 Claude 再试一次。
如果你想回到之前的状态，你可以使用 --resume 标志启动 Claude 来列出所有之前的线程。
f.跳过权限检查（谨慎使用）
这可能是极其不负责任的，但我现在主要使用 --dangerously-skip-permissions 运行 Claude。
这并不是所有事情都必需的，但如果我让 Claude 处理一些长时间运行的任务，我真的不想因为它使用新的终端命令而每分钟都要切换焦点回到它。
我在我的 zsh 配置文件中设置了这个：alias yolo="claude --dangerously-skip-permissions"
g.关于 MCP 服务器的看法
我个人对 MCP 服务器并不是很兴奋，因为没有一个真正给我带来任何价值。
在大多数情况下，我发现它们只是用我大部分时间不需要的东西消耗宝贵的令牌。
Claude Code 中的内置工具对我来说就足够了。
h.使用 Claude SDK 创建快捷方式
Claude 有一个 SDK。它非常强大，特别是如果你乐于处理 stream-json 输出格式。
但即使对于小事情，能够直接向 claude 传递提示并让它打印回复也是很好的快捷方式。
作为一个例子，我在我的路径中有一个 gcauto 可执行文件，它做以下事情：
#!/bin/bash
git commit -m "$(claude -p "查看暂存的 git 更改并创建一个总结性的 git 提交标题。只回复标题，不要确认。")"
i.让 Claude 先阅读文档
我在开始时犯的一个新手错误是告诉 Claude 用框架 x 设置一个新项目。
它确实有效，但我注意到 Claude 经常使用过时的设置和项目结构，特别是对于快速发展的前端框架！
我现在做的是要求 Claude 先阅读手册。这可以通过不同的方式完成：
粘贴文档链接并要求 Claude 先阅读
使用 Task 工具让 Claude 对特定主题进行深度研究
-----------------------------------------------------------------------------------------------------
> 创建一个深度研究任务来弄清楚如何将网站从 tailwind 3 迁移到 4，然后给我一个结果的简短摘要
⏺ 我将创建一个研究任务来调查从 Tailwind CSS v3 到 v4 的迁移
⏺ Task(Tailwind v3 到 v4 迁移研究)
⎿ 完成 (4 个工具使用 · 29.9k tokens · 5m 47.6s)
⏺ 摘要
从 Tailwind CSS v3 迁移到 v4 涉及重大更改，但带来了重大性能改进（构建速度提高 3.5 倍）和更好的开发者体验。
关键点：
- 使用自动升级工具：npx @tailwindcss/upgrade@next
- 配置从 JavaScript 移动到使用 @theme 指令的 CSS 优先
- 重大更改包括放弃浏览器支持、新的导入语法和删除已弃用的实用程序
- 性能提升：构建现在以微秒为单位测量
- 容器查询现在是内置的（不需要插件）
c.双层智能体
a.说明
Anthropic 提出了一种双层智能体设计，解决Agent执行长任务时丢失记忆的问题
-----------------------------------------------------------------------------------------------------
随着 Claude 等 AI 模型变得更强，开发者希望它们能够：
执行复杂任务（如全栈开发）
持续工作数小时甚至数天
但每次上下文窗口刷新后，AI 都会丢失记忆，无法连续推进任务。
这就像一个工程团队轮班工作，但每个新工程师上岗时都完全不知道前一班干了什么。
b.传统长任务执行的两个主要失败模式
1、试图一次性完成所有任务（one-shot）
Claude 会在一个窗口中尝试构建整个应用，结果中途上下文耗尽，留下“半拉子工程”，下一次启动又得重新理解。
2、过早宣告任务完成
当项目部分功能完成后，Claude 有时会错误判断为“任务已结束”。
这两种问题都导致 任务状态不连续、上下文断裂。
c.为什么这很难解决？
AI 模型的“记忆”不是持久的。
每次上下文窗口结束，它就像“重启的电脑”一样，什么都不记得。
虽然 Anthropic 给 Claude 做了 “上下文压缩（compaction）” 功能，可以把对话浓缩后带入下一轮
但这还不够，因为 AI 仍然会丢掉结构化的项目状态。
Anthropic 的解决方案：双智能体架构（Two-Agent Harness）
d.为解决这些问题，Anthropic 设计了一种新的智能体工作架构，称为：
双智能体长运行框架
它由两类 AI 角色协同完成整个任务过程：
Initializer Agent（初始化智能体）
Coding Agent（编码智能体）
这两个智能体并非两种模型，而是同一个 Claude 模型在不同阶段使用不同的提示模板（prompt template）运行。
-----------------------------------------------------------------------------------------------------
区别在于它们的职责分工与上下文约束。
🧩 第一位成员：Initializer Agent（初始化智能体）
Initializer 的任务是：
为项目建立结构化的“工作记忆”
创建清晰、可持续的开发环境
它只在项目第一次启动时运行，做“项目准备”：
第一次启动时，这个智能体负责：
创建整个工作环境；
写下一个初始化脚本 http://init.sh；
生成一个项目进度文件 claude-progress.txt；
建立 Git 仓库（用于版本管理）。
💡 它相当于项目的“开工仪式”，帮后续AI打好地基。
-----------------------------------------------------------------------------------------------------
🧑💻 2. 编码智能体（Coding Agent）
接下来的每一次运行中，这个智能体会：
阅读进度日志和 Git 记录；
查看“要做的功能列表”；
只实现一个小功能；
写好注释、测试代码；
保存清晰的 Git 提交；
更新进度日志后退出。
💡 每次运行就像接力赛中的一棒：干一件小事、记录清楚、交给下一位。
-----------------------------------------------------------------------------------------------------
实测结果：真的更聪明了
实验发现，这种结构化方法可以让 Claude：
连续运行数小时仍保持逻辑一致；
自动检查自己之前写的代码；
快速修复遗留bug；
有“团队协作”的感觉。
-----------------------------------------------------------------------------------------------------
但它仍有局限，比如：
看不到浏览器原生弹窗；
某些bug只能人工发现；
对多智能体协作的最优方式还在研究中。
e.Claude Code 的起点竟然是开发者个人业余项目？
没错，正是 Claude Code 创建者 @bcherny
2024.09 启动的业余项目，如今已经成为全球最热门的 AI Coding Agent，AI Agent 的架构典范，为 Anthropic 贡献超 10亿美元 ARR，可算是最成功业余项目？
对应 Boris 在接受采访时透露的 AI 应用理念也很能呼应：面向未来的模型构建应用！
在 Claude Code 刚被开发使用时，连简单的 Bash 都有可能生成错误，一次也运行不了几分钟，只能做简单的小任务（还不保证成功率）；
而现在，基于 Claude Sonnet 4.5 & Opus 4.5，Claude Code 可以持续运行数分钟、数小时甚至数天，完成非常复杂的大型综合任务。
这背后，Boris 透露的「Stop Hooks」机制起到了非常关键的作用：
当 Claude 认为任务完成并试图停止会话时，用户可通过 stop hooks 机制“戳”它继续工作。stop hooks 是 Claude Code 的高级功能，在 Claude 完成响应并准备返回控制权时触发，可执行自定义脚本来决定是否允许停止。
典型应用包括：拦截停止请求、重新注入相同提示、运行测试套件（如测试失败则自动要求修复），从而实现长运行任务的自动延续，而非短促的单次提示-响应循环。
官方插件 ralph-wiggum 的实现：它使用 stop hook 创建自参照反馈循环——Claude 尝试退出时，钩子阻塞退出、重新喂入原提示，让 Claude 基于先前修改的文件和 git 历史继续迭代优化，直到输出指定完成信号才真正停止。
这类似于一个内部“while true”循环，支持设置最大迭代次数作为安全阀。
想起 Anthropic 对 AI Agent 的最简化定义：LLM + 循环自动调用工具！
d.模型模式
a.xplanatory模式：像资深架构师一样思考和解释
a.说明
透明的思维过程：不再只给出最终代码，而是详细展示每一步的设计思路
架构决策解析：解释为什么选择这种技术方案，放弃了哪些其他可能性
最佳实践传授：在编程过程中自然地融入业界公认的代码规范和设计模式
权衡利弊分析：帮你理解每个技术选择背后的考量和影响
b.示例场景
当你请求设计一个API时，Claude会先说：
“为了构建可扩展的API，我将采用分层架构模式。虽然初期会增加
文件数量，但能极大提升代码的可维护性和可测试性.
c.适合人群
希望深入理解代码设计原理的开发者，想要从“搬运工“成长为"工程师"的程序员
b.Learning模式：苏格立底式教学，让你动手实践
a.说明
主动留白设计：在关键节点故意停下，留出空间让你思考和实现
TODO任务布置：通过TODO（human）标记，明确指出需要你完成的部分
循序渐进指导：提供足够的上下文和提示，确保你不会无从下手
即时反馈机制：对你的实现进行分析点评，形成完整的学习闭环
b.实际体验
Claude：“好了，基础框架我已经搭建完成。
现在这个计算折扣率的函数calculateDiscount（）就交给你来实现了
//TODO（human)：在这里实现折扣计算逻辑
我相信你能搞定！“
c.适用人群
教学理念：基于主动学习理论，只有亲身实践才能获得最深刻的理解
c.OutputStyles
a.说明
Output styles 允许你把 Claude Code「变身」为不同类型的智能体（Agent），
但保留其核心能力：运行本地脚本、读写文件、跟踪 TODO 等。
它通过直接修改 Claude Code 的系统提示词（system prompt）来改变行为与交流方式；
非默认风格会去掉许多“为了高效产码”的默认约束（如必须简洁、自动用测试验证等），并换成该风格的专属指令。
b.内置 Output stylesPermalink
官方当前提供 3 种内置风格（可随时切换）：
Default：面向高效软件工程协作的默认系统提示。
Explanatory（讲解型）：在完成任务的同时插入教学式的「Insights」，解释实现选择与代码库模式。
Learning（学习/带教型）：更像结对编程教练；Claude 会边做边教，并在代码中插入 TODO(human) 让你亲自补全，随后给反馈。该风格也同步引入到了 Claude 应用中，便于“边做边学”。
c.如何切换与持久化Permalink
交互式切换：输入 /output-style，从菜单选择风格；或在 /config 菜单进入。
直达切换：/output-style explanatory、/output-style learning 等。
生效范围：项目本地（local project level），设置保存到 .claude/settings.local.json。
d.自定义 Output stylePermalink
让 Claude 帮你起草：/output-style:new 我想要一个……的风格（中文也行）。
存储位置与格式：默认写到用户级目录 ~/.claude/output-styles，Markdown 前置 YAML 包含 name/description，后续是你定义的行为规范；也可放到项目级 .claude/output-styles 便于团队共享。
e.与其他机制的区别
Output styles vs. CLAUDE.md / -append-system-prompt：Output styles 是替换/关闭默认工程化 system prompt 的部分；而 CLAUDE.md 只是追加一条用户消息，-append-system-prompt 是附加到默认 system prompt 之后。
Output styles vs. Agents（子代理）：Output styles只改 system prompt并影响主循环；而 Agents 还可指定使用的模型、可用工具和触发场景。
d.命令汇总
a.进入风格菜单
/output-style
b.直接切换到讲解型
/output-style explanatory
c.直接切换到学习型
/output-style learning
d.新建一个“安全审计”自定义风格（用自然语言描述想要的行为）
/output-style:new 我想要一个安全审计风格：偏严格、先 threat modeling、产出修复建议与自动化检测脚本
e.查看或修改配置也可用
/config
e.LSP集成
a.说明
a.分类1
项目代码量超过 1 万行，Grep 搜索效率低下
频繁进行代码重构，需要精确查找函数引用
Token 预算有限，希望降低 AI 调用成本
需要理解复杂的代码调用链和依赖关系
使用 TypeScript、Python、Go 等有成熟 LSP 支持的语言
b.分类2
通过语言服务器协议（LSP）让Claude Code从"文本搜索"进化为"结构化代码理解"，实现精准定位、智能跳转，大幅提升开发效率
LSP 集成标志着 AI 编程工具从"文本处理"向"代码理解"的重要转变。
虽然当前版本仍有改进空间，但这个方向无疑是正确的——让 AI 真正理解代码的结构和语义，才能生成更精准、更可靠的代码。
对于使用 TypeScript 或 Python 的开发者，现在就可以尝试 VS Code 集成方案。遇到问题不要气馁，
可以关注 GitHub Issues 中的社区讨论和解决方案。如果觉得折腾成本太高，等待几个版本后再尝试也是合理的选择。
c.分类3
goToDefinition，跳转定义，点击符号直接跳转到定义位置，告别全局搜索的低效方式
findReferences，查找引用，一键列出函数或变量被调用的所有位置，重构前的必备工具
hover，悬停信息，获取变量类型和文档注释，无需翻阅源码查找类型定义
documentSymbol，文档符号，列出当前文件所有函数、类、变量，相当于代码大纲视图
workspaceSymbol，工作区搜索，在整个项目中搜索符号，只匹配真正的代码实体，排除注释和字符串
goToImplementation，跳转实现，从接口定义直接跳转到具体实现代码，理解抽象与实现的关系
incomingCalls / outgoingCalls，调用链分析，追踪函数的调用者和被调用者，构建完整的调用关系图谱
b.VSCode集成
a.在 VS Code 终端中启动 Claude Code
# 确保在 VS Code 集成终端中运行
claude
b.进入配置界面
# 打开配置面板
/config
c.关键配置项
Diff tool = auto
让 Claude Code 自动检测 IDE 类型。检测到 VS Code 后，会自动调用其 LSP 服务。
Auto-install IDE extension = true
自动安装 VS Code 扩展，负责 Claude Code 与 VS Code LSP 之间的通信桥接。
d.验证配置生效
配置完成后，VS Code 右下角应显示 Claude Code 扩展已激活。尝试询问代码定义问题验证 LSP 是否正常工作。
c.cclsp 方案
a.一键安装 cclsp
cclsp 是社区开发的 MCP 服务器方案，不依赖 VS Code，适合纯终端用户。
# 运行安装配置脚本
npx cclsp@latest setup
b.核心优势：智能位置修正
AI 生成的代码位置信息有时不够精确，行号可能存在偏差。cclsp 会自动尝试多种位置组合，智能匹配到正确的符号位置，提高查询成功率。
c.项目地址
https://github.com/ktnyt/cclsp
d.插件安装
a.安装指定版本
LSP 插件功能需要 2.0.67 或更高版本，并需要启用 LSP Tool。
# 如果装的是全局包
npm i -g @anthropic-ai/[email protected]
# 如果用 npx 启动（推荐）
ENABLE_LSP_TOOL=true npx @anthropic-ai/[email protected]
b.添加 LSP Servers Marketplace
使用社区维护的 LSP servers 插件源，提供 vtsls（TypeScript/JavaScript）等语言服务器。
# 添加 Piebald-AI 插件源
/plugin marketplace add Piebald-AI/claude-code-lsps
-------------------------------------------------------------------------------------------------
为什么需要插件？
Claude Code 默认不提供 JavaScript/TypeScript 的 LSP server，通过插件系统可以快速安装 vtsls 等社区维护的语言服务器。
c.安装 vtsls 插件
在 Claude Code 中运行插件命令，从 marketplace 中选择并安装。
# 打开插件管理界面（有些版本可能是 /plugins）
/plugin
在 marketplace 中勾选并安装 vtsls（TypeScript/JavaScript Language Server）。
d.重启 Claude Code
安装完成后，退出并重新启动 Claude Code 以使插件生效。
e.参考文档
Claude Code 插件系统：docs.claude.com/plugins
LSP Servers Marketplace：github.com/Piebald-AI/claude-code-lsps
e.手动配置
a.创建配置文件
在项目根目录创建 .lsp.json 文件：
-------------------------------------------------------------------------------------------------
{
"typescript": {
"command": "typescript-language-server",
"args": ["--stdio"],
"extensionToLanguage": {
".ts": "typescript",
".tsx": "typescriptreact"
}
},
"python": {
"command": "pylsp"
},
"go": {
"command": "gopls"
}
}
b.安装语言服务器
配置文件只定义连接方式，语言服务器需要单独安装：
-------------------------------------------------------------------------------------------------
# TypeScript / JavaScript
npm install -g typescript-language-server typescript
# Python
pip install python-lsp-server
# Go
go install golang.org/x/tools/gopls@latest
# Rust
rustup component add rust-analyzer
c.验证安装
# 确认语言服务器可执行
typescript-language-server --version
pylsp --version
gopls version
02.常用信息2
a.ACP集成
a.什么是 ACP？
Agent Client Protocol (ACP), 是一个由 Zed 和 JetBrains 发起的、
用于规范代码编辑器、集成开发环境与编码代理(也就是常说的 AI Agent) 之间的通讯的协议。
简单来说，就是一个专门为了让 AI Agent 与各类 IDE 友好协作的通用协议。
更多有关 ACP 的信息，你可以前往 ACP 的官方网站 https://agentclientprotocol.com 了解更多信息。
-----------------------------------------------------------------------------------------------------
原文链接：https://aicoding.csdn.net/694d0aaebf6b0e4b285e4e52.html
b.AI Assistant
在 AI Assistant 插件右上角的下拉菜单中找到「配置 ACP 智能体」的功能，
点击后会打开一个 acp.json 文件，此时即可配置 ACP 了。
-----------------------------------------------------------------------------------------------------
这里我会展示一个已经配置完 Claude Code 和 Codex 之后的 acp.json 文件内容：
{
"agent_servers": {
"Claude Code": {
"command": "claude-code-acp"
},
"Codex": {
"command": "npx",
"args": [
"@zed-industries/codex-acp"
]
}
}
}
c.Claude Code
Zed 提供了一个针对 Claude Code 的 ACP 适配器：claude-code-acp，
根据文档的描述，我们使用 npm 安装它即可：
npm install -g @zed-industries/claude-code-acp
需要注意的是，这里实际上是需要 -g 来安装到全局的，不知道为什么官方的文档里没有添加它。
-----------------------------------------------------------------------------------------------------
安装成功后，上述的配置就可以正常生效啦，现在你可以在 AI Assistant 的选项里看到它了
嗯～ 一切正常，而且这里有一个很明显与 AI Assistant 中内置的 Claude Agent 之间的区别：
使用自己配置的 ACP 可以完整识别到你的所有全局配置，包括配置的第三方中转站地址、MCP 之类的工具调用。
而内置的 Claude Agent 模式，最多只能识别到第三方地址，而 MCP 是无法被读取识别使用的。
d.Codex
Zed 也同样实现了一个 Codex 的 ACP 适配器：codex-acp。
不过它不使用 npm i -g 安装，而是使用 npx。
-----------------------------------------------------------------------------------------------------
就像上面所展示的 acp.json 里配置的那样，直接配置 npx 命令即可：
{
"agent_servers": {
"Codex": {
"command": "npx",
"args": [
"@zed-industries/codex-acp"
]
}
}
}
同样的，配置完成后就可以选择并使用了
我本身也没给 Codex 配置太多 MCP，所以看上去不是很多的样子。
它也有部分可选择的选项，例如模式和模型，按需选择即可。
b.Agent线程
a.目标
让 Codex 连续工作 8 小时的问题，上下文都不会爆掉！
让 Claude Code 去当监工监督 Codex 干活
b.步骤
1.首先要让 Codex 生成一个任务的 TODO List，就是那种能一步步完成的
2.然后让 Codex 更新 Agents md 文件，加上说明，如果输入 continue，要读取 TODO 文件，去选取任务，执行后更新 TODO
3.让 Claude Code 去执行命令：export TERM=xterm && codex exec "continue to next task" --full-auto
c.提示词
帮我在当前目录下，新开一个agent，使用 export TERM=xterm && codex exec "continue to next task" --full-auto 命令开启一个 codex 进程,
注意观察任务执行情况，如果当前任务完成(任务运行时间较长，可以多等一会)，就结束进程，然后重新开个agent运行相同指令让它继续
注意每次打开codex和监控它运行都调用一个新agent (Task Tool)来执行这个操作以避免主agent上下文太长
d.工作原理
也就是 Claude Code 去启动 codex 并传入提示词 "continue to next task"
并且监控 codex 的执行，如果当前任务完成了，就杀掉进程，重新执行上面的指令下一个任务。
由于每次都是新的 session，所以 codex 的上下文每次用的不多，不会爆掉。
-----------------------------------------------------------------------------------------------------
那么怎么保证 Claude Code 的 Context 不爆掉呢？毕竟codex输出的信息也不少
答案就是让 Claude Code 每次去启动 codex 和监控 codex 执行的时候，都起一个子 Agent，
这样每个子 Agent 都有独立的上下文，主 Agent 只有子Agent完成的上下文，占用空间极小。
Sub agents主要是用做上下文管理的，它的特点是不携带主线程的上下文，也不会把自己的上下文吐给主线程
-----------------------------------------------------------------------------------------------------
在启动一个sub agent 的时候，展开详情（Ctrl+R） 可以看到主线程写了什么 Prompt 给 sub agent，多看两个 就会更了解它究竟在干什么
sub agents 可以并行用，在 explore-plan-code-test 这个官方推荐的工作流里，可以在explore/plan/test 阶段强制要求并行，在 code 这个阶段只用串行
因为他有不携带上下文的特点，所以当你需要携带上下文的时候，你就不能用sub agents 了，比如它中间读了个文件，如果你需要这个文件在上下文里面，那么只能在主线程里串行执行
e.注意事项
监控 codex 执行这任务理论上来说 Gemini cli和 Codex cli 也能做，但是我没成功。
另外也没办法真的 8 小时，Claude Code 会偷懒，执行一会就会自行中断，即使没用多少上下文，
暂时还没解决这个问题，但是思路可以借鉴一下，如果有更好办法，欢迎留言交流。
-----------------------------------------------------------------------------------------------------
这个思路可以用在 Claude Code 上，把里面的 Codex 换成 Claude Code 就行，本质上就是一个 Manager 监控 Worker 干活。
要点：
1.Worker 要有 TODO List，并且 Agents/Claude Code MD 要有引导，这样每次固定提示词（continue）能继续任务
2.Worker 要开子进程避免上下文爆掉
3.Manager 去管理 Worker 干活要开子 Agent，避免 Manager 的上下文爆掉
-----------------------------------------------------------------------------------------------------
为什么要用 AI 去监督 AI 干活而不是脚本：
1.探索各种可能性
2.这样用 AI 监测，比脚本的好处是：
简单易行（但是费 Tokens）
可以根据任务执行的结果动态处理， Prompt 可以不是固定的
-----------------------------------------------------------------------------------------------------
Claude Code 虽然上下文不会爆掉，但是用量会爆
Claude Code 有个特别的工具叫 Task tool，本质就是一个子 Agent，它可以有独立的上下文，所以哪怕它用了很多token，但也不会占用多少主Agent的上下文空间
c.Claude生态
a.讲解顺序
a.说明
1.Claude 生态里到底有几块「积木」？
2.Skills：让 Claude 真正「学会干活」
3.Prompts：依然是主角，但天生是一次性的
4.Projects：给每一个重要主题一个「专属上下文空间」
5.Subagents：给每个子任务配一个「专职 AI 同事」
6.MCP：把所有外部系统接成一张网
7.一个完整的「研究 Agent」案例：这几块积木怎么拼在一起？
8.官方 FAQ 里的几个关键信息
9.实际上手：不同类型用户怎么用 Skills
10.作为 AI 产品创业者，我自己的一个判断
b.Skills的工作流程大致是
1.环境启动 → 扫描 Skills 目录
2.读取所有 SKILL/.md 的 frontmatter（元数据）
3.保持 ~100 tokens 的元数据在上下文中
4.用户输入 → 匹配 description
5.相关 Skill 被触发 → 加载完整的 SKILL/.md
6.按需加载 references/ 和 assets/
注意：如果想在其他客户端使用 Skills，目前还是很局限的，只能是粘贴复制 SKILL/.md 的文本进去
注意：不能自动加载更多的 references 和 assets，需要的话还得手动给到。但也不是说不行。
注意：不过这个机制不难实现，就看各个客户端要不要跟进了。
c.Claude Skills 原理有所谓的三层
层级 1: 元数据（始终在上下文中）
├─ name: 技能名称
└─ description: 触发条件（~100 词）
层级 2: http://SKILL.md 主体（触发后加载）
└─ 核心工作流程指令（<5000 词）
层级 3: 打包资源（按需加载）
├─ scripts/ → 可执行代码（不占上下文）
├─ references/ → 参考文档（需要时读取）
└─ assets/ → 输出资源（直接使用）
-------------------------------------------------------------------------------------------------
层级1 (元数据)：100词 × 10个技能 = 1000词
层级2 (主体)：仅触发的技能加载 ≈ 3000词
层级3 (资源)：脚本执行不占token，文档按需加载
效果: 同样的上下文预算，支持 10x 更多的专业能力
b.Claude 生态里到底有几块「积木」？
a.先把名字捋顺，否则后面全是雾
Prompts：你在对话框里敲给 Claude 的那一段话
Skills：一个个「能力文件夹」，里面是可复用的流程、脚本和资源
Projects：带自己知识库和历史记录的「项目空间」
Subagents：专门干某件事的小助手，像「子 AI」
MCP（Model Context Protocol）：把 Claude 接到你各种外部工具和数据源上的「通用连接层」
b.如果用一句人话总结
Prompts 是“当场吩咐一句”，
Skills 是“把做事的方法写进操作手册”，
Projects 是“给 AI 搭一个项目档案室”，
Subagents 是“请来一堆专职的 AI 同事”，
MCP 是“打通所有外部系统的总线”。
c.Skills：让 Claude 真正「学会干活」
a.Skills 是什么？
a.说明
官方定义是：Skills 是一些文件夹，里面放着指令、脚本和资源，当 Claude 觉得当前任务需要它时，就会动态加载。Claude
你可以把它想象成：给 Claude 写的一本本“岗位说明书 + SOP + 工具包”。
b.说明
比如一个「品牌规范 Skill」，里面可以写清楚：
品牌主色、辅色、渐变怎么用
标题字体、正文字体分别是什么
PPT 的版式有哪些固定模板
LOGO 在任何地方出现的尺寸和留白规则
不允许出现的低级审美错误
c.说明
以后你再让 Claude「帮我写一份路演 PPT」，它会自动套用这套规范，不需要你每次重新科普一遍品牌手册。
b.Skills 在后台是怎么工作的？这里有个很有意思的设计：渐进披露（progressive disclosure），大致流程是这样的
a.先读“封面简介”
Claude 会先扫描所有可用 Skills 的「元数据」——几句描述，大约 100 tokens 左右。
目的只是判断：这个 Skill 跟当前任务有没有关系。
b.觉得相关，再读“说明书正文”
一旦判断相关，它才会加载整个 Skill 的详细说明（SKILL.md），官网提到上限大约是 5k tokens，这里面通常是：
步骤、流程
注意事项
输出格式要求
风格偏好等
c.真的需要代码时，才加载脚本和文件
有些 Skill 还会带脚本或参考文件（比如模板、示例）。
只有在真正需要执行相关操作时，Claude 才会把这些东西「拎进上下文」。
d.这个设计的意义在于
你可以给 Claude 装很多 Skills，
但不会一上来就把上下文撑爆，
它只会在需要的时候，把需要的那一本“手册”翻开。
c.什么时候应该用 Skills？官方给了三个典型场景
a.组织级工作流
品牌规范
法务／合规流程
各种标准化文档模板、
b.某个专业领域的「经验总结」
Excel 公式、常用数据分析套路
PDF 处理的流程
安全审计、代码 Review 的标准
c.个人偏好 & 习惯
你的笔记结构
你的代码风格
你的研究方法
d.一句话
任何你不想一遍遍重新解释的东西，都可以长久地写进 Skill。
d.Prompts：依然是主角，但天生是一次性的，依然是日常交互的主角，但不适合作为「长期记忆」
a.Prompts 是什么？
a.说明
这个大家都熟：Prompts 就是你在对话里用自然语言给 Claude 下的那些指令，是实时的、对话式的、一次性的。Claude
b.比如
「帮我总结这篇文章」
「把刚才那段话的语气改得更专业一点」
「帮我分析一下这份数据，看有什么趋势」
「用项目符号重新排版一下」
c.说明
甚至可以是非常完整的一段复杂 prompt，比如官方举的「请你对这段代码做一个完整的安全审计」，
后面跟了详细的检查项、严重程度定义、修复建议要求等等。
b.Prompts 的局限在哪里？
a.Claude 官方直接说了
Prompt 是你和模型交互的主要方式，但它不会在不同对话之间自动保留。
b.也就是说
你今天费心写了一个很长的「代码安全审计」提示词
明天开新对话，还得重新粘一遍
换个项目、换个窗口，又得重来
c.于是他们给出一个很自然的建议
如果你发现自己在多个对话里反复敲同一类 Prompt，那就该把它升级成 Skill 了。
比如这些典型句型：
「请按照 OWASP 标准对这段代码做安全审计」
「请总是给出‘高层摘要 + 关键发现 + 建议’这三个结构」
这类东西，适合写进 Skill，变成「永远的工作方式」，而不是「今天一时想起来的提示词」。
官方也推荐你先看他们的 prompt library、最佳实践、以及一个「智能 Prompt 生成器」，这个就不展开了。
e.Projects：给每一个重要主题一个「专属上下文空间」
a.Projects 是什么？
在 Claude 的付费方案里，Projects 是一个个独立的工作区：
有自己的聊天记录
有自己的知识库
有自己的「项目级」指令
每个 Project 有一个大上下文窗口（官方说是 200K tokens 级别），你可以往里面上传各种文档、资料，让 Claude 在这个空间下工作。
当知识量很多的时候，Claude 会自动切换成类似 RAG 的模式，把项目知识进行检索，整体可扩到原来上下文的 10 倍左右。
b.什么时候适合用 Projects？
a.官方建议
a.需要长期存在的背景知识
某个产品线
某个大客户
某个长期课题
b.需要把不同工作分“项目隔离”
Q4 产品发布
某一场活动运营
某一轮融资材料
c.团队协作（Team / Enterprise）
共享历史对话
共享知识库
项目级的自定义指令
这个项目里，所有输出都要偏「To B、专业、严谨」
另一个项目里可以更轻松一点
b.官方例子
建一个「Q4 Product Launch」项目，把市场研究、竞品分析、产品规格都扔进去，以后在这个项目里的所有对话都会自动带着这些背景。
c.Projects 和 Skills 的区别
这一点很关键。官方一句话概括得非常好：
Projects 解决的是「你要知道什么」（背景知识）。
Skills 解决的是「你要怎么做事」（流程方法）。
换个比喻：
Project 像「整个项目的档案室＋学习资料」
Skill 像「公司内部的一份份标准操作手册」
Project 是局部的——只在这个项目空间里生效。
Skill 是全局可用——任何对话、任何项目，只要相关，都能调出来用。
f.Subagents：给每个子任务配一个「专职 AI 同事」
a.Subagents 是什么？
在 Claude Code 和 Claude Agent SDK 里，你可以创建很多「子代理（subagents）」。它们具备：
自己的上下文窗口
自己的系统提示
自己的一组工具权限
你可以把它们理解成：
Subagents = 一个个岗位明确、权限有限、职责清晰的 AI 员工。
b.Subagents 适合干什么？
a.官方给了4类典型用途
a.任务专业化
专门做代码审查
专门生成单元测试
专门做安全审计
b.上下文的拆分
主对话保持干净
把“重活”丢给 subagent 做
c.并行处理
一个 subagent 做市场调研
另一个做技术分析
再一个做文档整理
d.工具权限隔离
某些 subagent 只有只读权限
它永远不能写入、不能删东西
b.例子
建一个「代码审查 subagent」，
只给它 Read / Grep / Glob 权限，不给 Write / Edit。
每次代码有改动，Claude 会自动把审查任务丢给它，
这样就能保证有安全审查，而不会误改代码。
c.Subagents 和 Skills 怎么配合？
a.官方推荐
多对多
一个 subagent 可以使用多个 Skills（例如语言规范、领域 Best Practice）
多个 subagent 也可以共享某些 Skills（比如统一的写作规范 Skill）
b.你可以这样理解
Skill 更像“知识＋流程”；
Subagent 更像“带着这些知识/流程去执行任务的具体人”。
g.MCP：把所有外部系统接成一张网
a.MCP 是什么？
Model Context Protocol（MCP）是一个开放协议，用来把 AI 助手接到各种外部系统上。
简单理解：
你不用再给每个系统写一套单独的集成，
只要对接 MCP，就可以用统一方式连接各种数据源和工具。
官方举的典型连接对象：
外部数据源：Google Drive、Slack、GitHub、数据库等
业务工具：CRM、项目管理系统
开发环境：本地文件、IDE、版本控制
自研系统：你们自己公司的内部平台
你把这些系统包装成一个个 MCP server，Claude 作为 MCP client 去连它们。
b.MCP 和 Skills 怎么配合？
非常重要的一点是：
MCP 负责“接通数据和工具”，
Skills 负责“告诉 Claude 要怎么用这些数据和工具”。
比如：
MCP：让 Claude 能访问你的数据库
Skill：规定「查询时必须先按日期过滤」「查询结果要按某种格式输出」
MCP：连接你的 Excel 文件
Skill：规定「生成报表时必须使用哪些公式」「怎么排版」
未来比较理想的状态是：
每接入一个新系统（MCP），
最好配一套相应的使用说明和流程（Skill）。
h.这些东西是怎么拼在一起的？一个「研究 Agent」的完整例子
a.第一步：建一个 Project——「竞争情报」
把下面这些东西都扔进去：
行业报告、市场分析
竞争对手的产品文档
CRM 里的用户反馈
你们之前写过的研究总结
并且加一段项目级指令：
分析竞品时要站在我们自家产品战略的视角，
尤其关注差异化机会和新兴趋势，
给出的结论要带证据、要可执行建议。Claude
b.第二步：用 MCP 接数据源
打开几个 MCP server：
Google Drive：访问共享研究文档
GitHub：看竞品的开源仓库
Web 搜索：查实时的市场信息
c.第三步：创建一个「竞争分析 Skill」
比如叫 competitive-analysis，里面可以包含：
公司内部 GDrive 的目录结构
搜索时的最佳实践
先从哪个目录下手
优先看最近 6 个月的文档
最终确认「权威版本」的方式
一个标准化的研究工作流：
明确研究主题
在对应的目录里组合关键词搜索
选 3–5 个最新 / 最关键文档
和战略文档交叉引用
输出时标注来源文件名和日期
这就是一个非常典型的「流程型 Skill」。
d.第四步：配置 Subagents（在 Claude Code / SDK 里）
比如两个子代理：
a.market-researcher
优先使用权威来源（Gartner/Forrester 等）
关注市场份额、增长率、融资情况
需要给出带引用和置信度的结论
负责：市场趋势、行业报告、竞品定位
工具：Read、Grep、Web-search
系统提示里写清楚：
b.technical-analyst
分析技术栈、架构模式
评估可扩展性和性能
找出技术优势和短板，并给出对你有用的启示
负责：技术架构、实现方式、工程决策
工具：Read、Bash、Grep
系统提示：
e.第五步：调用这个 Agent
你现在问 Claude：
「帮我分析一下我们前三个主要竞品最近发布的 AI 功能，它们是怎么定位的？我们有哪些可利用的空档？」
背后到底会发生什么？（重点来了）
a.Project 上下文加载
Claude 拿到你之前上传的研究文档、战略文档
b.MCP 联通数据
去 GDrive 里找最新竞品材料
去 GitHub 拉开源仓库
用 Web 搜索补实时信息
c.Skill 启用
用 competitive-analysis 这个 Skill 提供的工作流框架来组织分析
d.Subagents 并行工作
market-researcher 去研究市场定位
technical-analyst 看技术实现
e.你通过 Prompt 微调方向
比如补一句：「重点关注医疗行业的企业客户」
f.最终，你拿到的是一份
有来源
有结构
有可执行建议
又符合你战略视角的竞品研报。
这就是「几块积木组合起来」的威力。
i.官方 FAQ 里的关键点
a.Skills 是怎么保持「高效」的？
靠的就是前面说的「渐进披露」：
先扫 metadata
再按需加载完整说明
有代码和文件再按需加载
所以你可以放心地给 Claude 装很多 Skills，它不会一开始就被上下文压垮。
b.Skills vs Subagents：什么时候用哪个？
a.用 Skills
当你希望「任何 Claude 实例」都能加载某种能力，比如安全审计流程、数据分析方法
b.用 Subagents
当你需要一个完整的「小代理」，自己带上下文、带工具权限，能独立跑完整工作流
c.最推荐的姿势是
Subagent ＋ Skills 组合使用。
让一个专职“代码审查 subagent”去调用「语言特定 best practice Skill」，
相当于给这个小同事配一堆教材。
c.Skills vs Prompts：什么时候该升级？
a.用 Prompts
一次性指令、即时交互、补充上下文
b.用 Skills
当你有一套流程／专业经验，需要反复使用
当你希望 Claude 能自己判断「什么时候应该套这套流程」
c.比较理想的模式是
用 Skills 打地基，用 Prompts 在每次任务上做具体微调。
d.Skills vs Projects：核心差别是什么？
官方原话的对比非常精炼：
a.Projects
「这是你需要知道的东西」（知识、文档、背景）
总是在项目里加载
b.Skills
「这是你应该怎么做事」（流程、代码、方法）
动态按需加载，节省上下文
你可以把它记成一句话：
Project = 知识场景，Skill = 能力模组。
e.Subagents 能不能用 Skills？
答案是：可以，而且非常推荐。
在 Claude Code 和 Agent SDK 里，Subagent 可以和主 Agent 一样使用 Skills。
比如：
python-developer subagent
用 pandas-analysis Skill 按你团队习惯来做数据处理
documentation-writer subagent
用 technical-writing Skill 固定 API 文档的写法和格式
j.如何开始上手 Skills？
a.如果你是 Claude.ai 网页用户
在 Settings → Features 里把 Skills 打开
去 claude.ai/projects 创建你的第一个项目
在一个具体分析任务里尝试「Project + Skill」联合使用
b.如果你是 API 开发者
去看文档里关于 Skills endpoint 的部分（支持通过 API 管理 Skills）
打开官方的「skills cookbook」仓库，看他们给的 Skill 示例
c.如果你是 Claude Code 用户
通过插件市场安装 Skills
同样可以参考「skills cookbook」，照着抄一遍先跑起来
k.作为 AI 产品创业者，我的一个小结论
a.你的差异化，将越来越体现在 Skills 设计上
把领域经验、工作流、组织规范，沉淀成一套 Skills 库
这是你产品的护城河，而不仅仅是“调了哪个大模型”
b.你的产品架构，会越来越像「Agent 积木组合」
某个功能 = 若干 Project + Skills + Subagents + MCP 的组合
未来甚至可以对外开放自己的 Skill Store
c.你的团队，迟早需要一个“Skill Engineer / AI Workflow Architect”角色
不再只是写 prompt 的人
而是真正负责「把经验变成可复用的 AI 工作流」的人
b.说明
现在很多人还沉迷在“写花式 Prompt”，但从 Skills / Projects / MCP / Subagents 这套组合来看，趋势已经非常明显了：
做 AI 产品，如果只停留在 Prompt 层，就是停留在 Demo 层；要往真正的“业务系统”走，就绕不开流程工程和 Skill 设计。
我自己现在已经用 Skills 做很多件事：
一个是「写公众号 Skill」，比如标题怎么写、导语怎么设计、配图比例怎么选，都写死在里面；
一个是「代码性能分析Skill」，性能涉及到很多方面，比如数据库设计（索引、事务等）、Redis和数据库的配合、代码中的算法和架构等等、缓存策略等等，单独靠MCP或Subagent是很难完成的，需要一整套流程。
一个是「产品更新日志 Skill」，我只管往里丢 changelog，它会自动帮我改成对用户友好的版本。
一个是「产品idea头脑风暴Skill」，我有新的idea的时候，不再是直接问ChatGPT，而是有一个特定的流程。
一个是「域名讨论Skill」，做新产品时，想域名是一个头疼的事，可以通过Skill来找到后选域名、查询是否可用
d.AgentTeam
a.前言
在阅读Sub-Agent相关文章后，大家应该已经对Sub-Agent有了一定的了解。面对新出的Agent Team功能，
大家可能会有一个疑问：Sub-Agent和Claude新出的Agent Team，它们之间的区别是什么？
带着同样的疑问，经过两天的高强度使用，其输出效果非常震惊。本文将分享使用感受。
内容面向小白，附加快速实操案例。相信读完这篇文章，你不单能够理解Agent Teams和Sub-agent之间的区别，
并且能够立刻感受到让你震惊的念头：Agent Team的输出效果真的很好。
现在，就打开你的终端，输入那行环境变量，开始组建属于你的第一支AI梦之队吧。未来已来，而你，就是那个总指挥。
b.第一章：什么是 Agent Teams？
a.核心定义
Agent Teams等于多个独立的AI大脑加实时内部通信加共享任务看板加AI项目经理统筹。
b.Sub-Agent 的三个核心问题
我们以往使用的Sub-Agent体系，存在三个核心问题。通信难题：不同Sub-Agent之间的通信很难，通常需要额外一份md文件来同步进程。
内部沟通：Sub-Agent之间的沟通难度较高，只能进行较为浅层的交流。
上下文：Sub-Agent虽然已经脱离了主对话，但结果摘要返回依然会返回部分上下文，占据空间。
c.解决方案
基于这样的属性，Sub-Agent注定只能处理一些复合型任务；而面对真正复杂度极高的任务，仍然效果不尽人意。
由此，Agent Teams的解决方案出现了，其目的便是通过更加完善的Multi-Agent机制，来达到更完美的输出效果。
这功能让Agent之间，实现了更加完美和拟人的协同方式。
c.第二章：Agent Teams 架构详解
a.内部架构图
你作为人类用户下达指令、随时介入、查看进度。下方连接Team Lead（队长Claude），负责接收你的指令、拆解任务、分配、汇总结果。
队长下方连接队友A、队友B、队友C，他们拥有独立上下文和独立工作区，并且互相连接。
底部支撑是共享任务列表，包含pending、in progress、completed状态。
b.四大组件
该体系由四大组件构成，各司其职，又紧密配合。
Team Lead（队长）：主Claude实例，负责任务拆解和分配。
Teammates（队友）：独立的子Agent，拥有各自的上下文窗口。
Mailbox（邮箱系统）：队友间通信的渠道。
Shared Task List（共享任务列表）：团队协作的看板。
c.协作流程
这个体系的协作流程，完美复刻了人类高效团队的工作模式。
步骤1：你描述需求，Main Agent（队长）理解并拆解为多个子任务。
步骤2：队长创建队友，每个队友被分配到一个或多个子任务。
步骤3：队友并行工作，各自在自己的大脑（新窗口）中独立推进。
步骤4：队友互相沟通，遇到需要其他人配合的地方，直接发消息询问。
步骤5：任务依赖自动管理，如果任务C依赖任务A的结果，C会自动等待A完成后再开始。
步骤6：队长汇总交付，所有队友完成后，队长整理全部成果，向你汇报。
d.关键理解
每个队友都有独立的大脑（上下文窗口）。这意味着队友A写了什么，队友B不会自动看到，他们需要通过Mailbox系统来显式地共享信息。
这种设计的好处是每个人的大脑都不会被不相关的信息塞满，能时刻保持思路清晰，专注于自己的核心任务。
d.第三章：Sub-Agent vs Agent Teams
a.生活化类比
Sub-agent就像你同时在三个不同的App上点了三份外卖。
三个外卖小哥各自接单、取餐、配送，他们之间互不相识，也无法沟通，最终都只向你一个人汇报。
Agent Teams则像你为了装修房子，组建了一个包含设计师、施工队长和采购员的项目组。
他们围坐在一起，设计师的图纸可以直接交给施工队长，施工队长发现材料问题可以马上和采购员沟通。
他们共享一个总体的装修目标，并能主动协调解决问题。
b.详细对比表格
对比维度包括生命周期：Sub-Agent是一次性的，做完即销毁；Agent Teams是持久运行的，可反复接收新指令直到主动关闭。
通信能力：Sub-Agent没有直接通讯能力；Agent Teams拥有直接通讯能力（Mailbox系统）。
协作模式：Sub-Agent是星型拓扑，主Agent是唯一调度中心；Agent Teams是网状拓扑，共享任务列表，队友可自行认领。
用户可达性：Sub-Agent用户看不到、摸不到；Agent Teams用户可以直接和任意队友对话。
任务管理：Sub-Agent无共享任务列表；Agent Teams有共享的Task List。
信息流转：Sub-Agent通过主Agent中转；Agent Teams队友间直接通信。
成本：Sub-Agent相对较低；Agent Teams相对较高（多个实例运行）。
c.判断法则
一个简单的判断法则：当你不确定用哪个时，问自己两个问题。
问题1：这些子任务之间需要互相沟通吗？如果需要，用Agent Team；不需要，用Sub-Agent。
问题2：任务的总复杂度高吗？简单任务（1-2个子任务）用Sub-Agent；复杂任务（3个以上需要协调的子任务）用Agent Team。
d.经验法则
需要快速完成独立小任务，用Sub-agent；
任务复杂、多模块、需要队友互相讨论，用Agent Team。
如果预算紧张且任务简单，Sub-agent更省钱。
e.第四章：快速上手指南
a.启用 Agent Team
Agent Team由于目前是实验性功能，因此默认是关闭的，需要手动打开。
b.临时启动（PowerShell）
a.代码
---
$env:CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS = "1"
---
b.说明
在启动Claude Code前，输入上述指令即可临时启动。
c.永久启动
a.说明
为了方便，更推荐在Claude Code的settings.json配置文件中进行永久设置。
找到~\.claude\settings.json文件（没有就新建一个），写入以下内容并保存：
b.代码
---
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
---
f.第五章：实战案例演示
a.案例背景
AI写作助手产品发布准备。
b.操作指令
在Claude Code里输入：我们下周要发布一款AI写作助手产品妙笔AI。
请帮我组建一个Agent Team，并行准备以下材料。
-------------------------------------------------------------------------------------------------
队友1（竞品分析师）：
搜索并分析市场上主流的AI写作工具（如Jasper、Copy.ai、Notion AI等），整理成一份竞品分析报告，
包含各家核心功能对比（用表格呈现）、定价策略对比、用户口碑和槽点、我们产品的差异化优势在哪里，
输出为Markdown格式的报告文件。
-------------------------------------------------------------------------------------------------
队友2（文案策划）：
撰写产品发布所需的全套文案，包括官网landing page的标题、副标题和3个核心卖点、5条适合发微博/小红书的种草文案（要有网感）、
1篇公众号发布稿（800字左右，风格专业但不枯燥），注意参考队友1的竞品分析来突出差异化。
-------------------------------------------------------------------------------------------------
队友3（销售支持）：
制作一份销售团队FAQ手册，包含客户最可能问的15个问题和标准回答、与竞品对比时的话术建议、
常见反对意见（如我已经在用Notion AI了）的应对方法，同样参考队友1的竞品分析来保持信息一致。
-------------------------------------------------------------------------------------------------
三个队友通过共享任务列表协作。文案和FAQ都需要参考竞品分析的结果。
c.执行流程
输入完毕后，你只需要看着Claude自动工作。
步骤1：组建团队，Claude自动成为队长，并且生成3个独立的队友。
步骤2：To-Do List，Claude队长为团队创建了任务清单。
步骤3：竞品分析师率先开工，搜索资料、整理对比表格、分析差异化。
步骤4：文案策划同步起步，先用已有的产品信息开始写草稿框架。
步骤5：信息自动流转，队长会查看内容并进行评价和沟通。
步骤6：队长汇总，全部完成后，整理所有文件，给你一份交付清单。
g.第六章：震撼的官方案例
a.Carlini 的编译器项目
2026年2月5日，Anthropic的安全研究员Nicholas Carlini，详细记录了他如何使用Agent Teams指挥16个Claude实例并行工作，
从零开始构建了一个能够编译真实C程序的编译器。这个编译器最终包含超过10万行代码，能够通过数百个测试用例。
b.工作方式
Carlini将编译器的不同模块（词法分析器、语法解析器、类型检查器、代码生成器等）分配给不同的Agent队友。
这些队友并行开发各自负责的模块，同时通过Mailbox系统协调接口定义和数据格式。
当一个队友完成了词法分析器并定义好了Token格式，语法解析器队友会立即收到通知并基于这个格式开始工作。
c.案例意义
这个案例证明了三件事。
第一，Agent Teams能处理真正的工程级复杂任务，而不仅仅是写写文案、做做表格。
第二，并行协作的效率提升是实打实的，如果让单个Agent按顺序写10万行代码，可能需要数天，16个Agent并行大幅缩短了时间。
第三，AI之间的协调能力已经达到了令人惊讶的水平，它们能够自主定义接口、解决冲突、保持代码风格一致。
h.第七章：未来的工作方式
a.范式转换
Agent Teams的出现，标志着我们与AI的交互方式正在经历一次根本性的范式转换。
第一阶段：单体 Agent，一个AI完成所有任务。
第二阶段：Sub-Agent，主从协作，AI调用AI。
第三阶段：Agent Teams，多AI协同，团队作战。
我们正站在第二阶段向第三阶段跃迁的临界点上。
b.局限与前景
Agent Teams虽然仍是实验性功能，存在以下局限：不支持会话恢复、不支持嵌套团队、费用较高。
但它所揭示的未来图景已经足够清晰：未来的超级个体，不是那个什么都会做的人，而是那个知道如何组建、指挥和优化一支AI团队的人。
对于产品经理、市场人员、研究员、开发者乃至任何知识工作者而言，学会如何定义角色、拆解任务、构建并引导这样一支AI团队，将成为未来最核心的竞争力之一。
e.AgentLoop
a.让 Agent 自己跑起来
a.背景引入
上篇文章我们聊了 Tool Use——LLM 通过结构化的方式"点菜"，Agent 程序负责"上菜"。
但光有工具还不够，LLM 调了一次工具、拿到了结果，然后呢？如果任务还没完成，它还得继续调其他工具，对吧？
这个"继续"的过程，就是今天要聊的核心——Agent Loop。
b.Anthropic 怎么说的
a.官方定义
Anthropic 在他们那篇很有影响力的文章《Building effective agents》中，对 Agent 有一个非常精辟的定义：
Agents can handle sophisticated tasks, but their implementation is often straightforward.
They are typically just LLMs using tools based on environmental feedback in a loop.
Agent 可以处理复杂的任务，但它们的实现往往很简单。本质上就是 LLM 在一个循环中，根据环境反馈来使用工具。
注意这句话里的关键词：in a loop（在一个循环中）。
这就是 Agent 和普通 LLM 应用最本质的区别。普通的 LLM 应用是你问一句它答一句，流程是预先写死的。
而 Agent 是把控制权交给 LLM，由模型自己决定下一步做什么、调什么工具、什么时候停下来。
b.核心理念与 Claude Code
Anthropic 在文章中还特别强调了一点：Agent 的核心循环结构非常简单，关键在于模型的能力和工具的设计，而不是复杂的编排逻辑。
Claude Code 就是这个理念的直接产物。如果你用过 Claude Code，你应该能感受到：
你给它一个任务，它会自己去读代码、改文件、跑命令，一步步推进，直到搞定。
背后驱动这一切的，就是 Agent Loop。
（此处图片描述：图表展示了 Agent 的核心循环结构，强调其结构简单，关键在于模型能力和工具设计。）
c.从一个真实场景说起
a.场景设定
假设你在用 Claude Code 写代码，然后你说了一句："帮我在项目里找到所有 TODO 注释，整理成一个清单。"
这个任务对人来说很简单：打开搜索，输入 TODO，看看结果，整理一下。但对 Agent 来说，它需要经历一个完整的循环。
我们一步一步来看。
b.循环的每一步
a.第一轮：搜索 src 目录
你的任务发给 LLM 之后，LLM 会思考：要找 TODO 注释，我应该先用搜索工具在项目里搜一下。
于是它返回了一个 tool_use：
---
{
"type": "tool_use",
"name": "search",
"input": { "pattern": "TODO", "path": "./src" }
}
---
Agent 执行搜索，拿到结果：
src/auth.js:42 // TODO: add token refresh logic
src/api.js:18 // TODO: handle timeout errors
src/utils.js:7 // TODO: refactor this function
Agent 把结果作为 tool_result 返回给 LLM。
b.第二轮：还要不要继续搜？
LLM 拿到搜索结果后，不是直接就给你答案了。
它会再想一下：找到了 3 个 TODO，但我只搜了 src 目录，是不是还应该看看测试目录？
于是它又返回一个 tool_use：
---
{
"type": "tool_use",
"name": "search",
"input": { "pattern": "TODO", "path": "./tests" }
}
---
Agent 执行，发现测试目录里没有 TODO，把空结果返回给 LLM。
c.第三轮：够了，生成回答
这时候 LLM 判断信息已经足够了，不再调用工具，而是直接输出一段文字：
"项目中共有 3 处 TODO 注释：
src/auth.js 第 42 行：需要添加 token 刷新逻辑
src/api.js 第 18 行：需要处理超时错误
src/utils.js 第 7 行：需要重构该函数"
此时 stop_reason 变成 "end_turn"，循环结束。
d.整个流程画出来
a.流程概述
你再回头看一遍，其实就是一个循环：
用户输入 → LLM 思考 → 需要工具？→ 是 → 执行工具 → 结果返回 LLM → LLM 再想 → 需要工具？→ 是 → …… → 不需要了 → 输出最终结果
这就是所谓的 Agent Loop（智能体循环）。
（此处图片描述：流程图展示用户输入、LLM 思考、工具执行、结果反馈的闭环过程。）
b.伪代码实现
用代码来表达的话，核心逻辑就是一个 while 循环：
---
while true:
response = 调用 LLM(消息历史)
if response 包含 tool_use:
result = 执行工具
把 tool_result 加入消息历史
continue // 继续循环
else:
输出最终回答
break // 退出循环
---
没错，就这么简单。正如 Anthropic 说的：Agent 可以处理复杂的任务，但它的实现往往很简单。整个 Agent 最核心的调度逻辑，就是这几行伪代码。
e.为什么这个循环这么重要
a.与普通应用的区别
没有这个循环，LLM 就只能做一问一答的事情。你问它一个问题，它凭自己脑子里的知识回答你，完事了。
但有了这个循环，事情就完全不一样了。LLM 可以根据中间结果动态决定下一步做什么。
搜完代码发现有个文件可疑，那就再读一下这个文件；读完发现还需要看看 git 历史，那就再调一个命令；命令执行发现报错了，分析一下原因再试一次。
b.自主智能体的特性
Anthropic 把这种模式叫做 autonomous agent（自主智能体），和那些流程写死的 workflow 做了明确区分。
workflow 是你提前规定好第一步做什么、第二步做什么；而 agent 是让模型自己决定该怎么走。这种灵活性，正是 Agent Loop 带来的。
这也是为什么 Claude Code 处理一个稍微复杂点的任务，可能要跑几十轮循环。它不是一步到位的，而是像人一样，边做边想，一步步推进。
f.循环中的关键细节
a.消息历史是关键
每一轮循环，LLM 的回复（包含 tool_use）和工具的执行结果（tool_result）都要追加到消息历史里。下一轮调用 LLM 时，要把完整的历史都带上。
为什么？因为 LLM 本身是无状态的，它不记得上一次说了什么、做了什么。
只有你把历史消息全部喂给它，它才能知道："哦，我之前已经搜过 src 目录了，现在应该搜 tests 目录。"
消息历史就是 Agent 的"记忆"。
（此处图片描述：示意图展示了消息历史如何在多轮循环中被不断追加和传递，作为 Agent 的记忆载体。）
b.stop_reason 决定循环走向
上篇文章我们提到过，LLM 的返回里有一个 stop_reason 字段：
"tool_use"：LLM 想调工具，循环继续
"end_turn"：LLM 觉得完事了，循环结束
Agent 程序就是靠这个信号来决定：是继续跑，还是停下来把结果给用户。
c.循环不能无限跑
LLM 有时候会陷入奇怪的状态，比如反复调用同一个工具，或者在两个工具之间来回跳。所以实际的 Agent 都会设一个最大循环次数，超过了就强制停止。
这不是什么高深的技术，就是一个计数器加一个 if 判断。但不加的话，你的 Agent 可能会一直跑下去，token 费用也跟着蹭蹭涨。
g.一个更复杂的例子
a.场景描述
上面找 TODO 的例子比较简单，只跑了两三轮。
来看一个更贴近真实场景的例子。
你跟 Claude Code 说："帮我修一下 login 接口的那个 bug，用户登录后 token 没有正确返回。"
Claude Code 可能会经过多轮决策和操作。
b.详细执行过程
轮次 LLM 决策 工具调用 结果
1 先找到 login 接口在哪 search("login") 找到 src/auth/login.ts
2 读一下这个文件 read_file("src/auth/login.ts") 拿到源码
3 看看 token 生成逻辑 read_file("src/utils/token.ts") 发现 generateToken 函数
4 找到 bug 了，改代码 write_file("src/auth/login.ts") 修复完成
5 跑一下测试确认 bash("npm test") 2 个测试失败
6 看看测试为什么挂了 read_file("tests/auth.test.ts") 发现测试也需要更新
7 更新测试代码 write_file("tests/auth.test.ts") 修改完成
8 再跑一次测试 bash("npm test") 全部通过 ✅
9 任务完成，汇报结果 无（end_turn） 输出修复总结
9 轮循环，用了 4 种不同的工具，中间还经历了一次测试失败后的自我纠正。
03.常用信息3
a.Anthropic源码泄露
a.事件背景
a.泄露概述
2026年3月31日，Claude Code源代码通过npm包里的map文件泄露。
这不是黑客攻击，而是打包配置失误，导致指向Anthropic R2存储桶中未混淆TypeScript源码的source map文件被意外发布。
b.仓库镜像
这个GitHub仓库是一个镜像snapshot，由一位研究软件供应链安全的大学生维护，用途明确为教育、防御性安全研究、架构分析。
b.规模与技术栈
维度 数值/技术
文件数 ~1,900
代码行数 512,000+
语言 TypeScript（strict模式）
运行时 Bun
终端UI React + Ink
CLI解析 Commander.js
Schema验证 Zod v4
代码搜索 ripgrep
协议 MCP SDK + LSP
c.核心架构四大系统
a.Tool系统（约40个工具）
工具 功能
BashTool Shell命令执行
FileReadTool 读文件（图片、PDF、notebook）
FileWriteTool 创建/覆写文件
FileEditTool 局部修改（字符串替换）
GlobTool 文件模式匹配搜索
GrepTool ripgrep内容搜索
WebFetchTool 抓取URL内容
WebSearchTool 网页搜索
AgentTool 子代理spawning
SkillTool 执行技能
MCPTool MCP服务器工具调用
LSPTool 语言服务器协议集成
NotebookEditTool Jupyter notebook编辑
TaskCreateTool 任务创建管理
SendMessageTool 代理间消息
TeamCreateTool 团队代理管理
EnterPlanModeTool 进入计划模式
EnterWorktreeTool Git worktree隔离
CronCreateTool 定时触发
SleepTool 主动模式等待
b.Command系统（约50个斜杠命令）
命令 功能
/commit 创建git commit
/review 代码审查
/compact 上下文压缩
/mcp MCP服务器管理
/config 设置管理
/doctor 环境诊断
/login 登录/注销
/memory 持久化记忆
/skills 技能管理
/tasks 任务管理
/vim Vim模式切换
/diff 查看变更
/cost 查看费用
/theme 切换主题
/context 上下文可视化
/resume 恢复会话
/share 分享会话
c.Bridge系统（IDE集成）
a.说明
双向通信层，连接VS Code/JetBrains扩展与CLI：
包括bridgeMain.ts（主循环）、bridgeMessaging.ts（消息协议）、bridgePermissionCallbacks.ts（权限回调）、jwtUtils.ts（JWT认证）。
a.意义
这意味着Claude Code不只是CLI，而是IDE插件的后端服务。
d.Permission系统
每次工具调用都检查权限。根据配置的permission mode（default、plan、bypassPermissions、auto）自动决议或提示用户批准。
d.三个关键文件
a.QueryEngine.ts（约46K行）
LLM API调用的核心引擎。处理流式响应、工具调用循环、thinking模式、重试逻辑、token计数。46K行写一个查询引擎，可见复杂度之高。
b.Tool.ts（约29K行）
定义所有工具的基类型和接口，包括input schema、权限模型、进度状态类型。这不是简单的type定义，而是完整的工具生命周期类型系统。
c.commands.ts（约25K行）
管理所有斜杠命令的注册和执行。使用条件导入，根据环境加载不同的命令集。
e.设计亮点
a.并行预取优化启动
a.代码示例
---
// main.tsx — 在其他import之前触发
startMdmRawRead()
startKeychainPrefetch()
---
b.说明
MDM设置、keychain读取、API预连接并行执行，加速启动。
b.惰性加载重模块
OpenTelemetry、gRPC、analytics通过动态import()延迟加载，用到才加载。
c.Feature Flags消死代码
a.代码示例
---
import { feature } from 'bun:bundle'
const voiceCommand = feature('VOICE_MODE')
? require('./commands/voice/index.js').default
: null
---
b.说明
Bun的bun:bundle在构建时完全剥离未激活代码。
关键flag包括PROACTIVE、KAIROS、BRIDGE_MODE、DAEMON、VOICE_MODE、AGENT_TRIGGERS、MONITOR_TOOL。
d.多代理协调
coordinator/目录处理多代理编排。AgentTool spawn子代理，TeamCreateTool支持团队级并行。
e.Skill系统
skills/定义可复用工作流，通过SkillTool执行。用户可添加自定义skill。
f.插件架构
plugins/子系统加载内置和第三方插件。
f.泄露原因分析
a.技术细节
npm包发布时，source map文件（.map）意外包含在内；source map引用了未混淆的TypeScript源码，
托管在Anthropic的R2存储桶；R2存储桶权限配置允许公开访问（或source map URL绕过了权限）；
Chaofan Shou发现.map文件，追溯到了R2存储桶的src/目录。
b.教训
发布npm包时，务必排除.map文件（或只包含指向已混淆代码的map）；
检查R2/S3存储桶权限；使用.npmignore或package.json的files字段精确控制发布内容。
g.结语
a.核心观点一：Agent CLI的复杂度远超想象
你以为写一个CLI调用LLM API就够了？Claude Code用了512K行代码。
a.原因分析
Agent CLI不只是API调用器，它要处理流式响应加工具调用循环（46K行的QueryEngine）、
权限系统（每次工具调用都检查）、IDE集成（Bridge双向通信）、多代理协调（coordinator/）、
持久化记忆（memdir/）、上下文压缩（compact/）、Vim模式、语音输入、远程会话等。这不是玩具，是生产级系统。
b.核心观点二：软件供应链安全是隐形杀手
这次泄露不是因为黑客，也不是因为内部泄密，是打包配置失误。一个.map文件，暴露了51万行源码。
Anthropic有顶级安全团队，但打包流程的一个疏忽，一切防护失效。供应链安全不是会不会发生的问题，是什么时候发生的问题。
c.核心观点三：这个snapshot是绝佳的学习素材
51万行代码公开可读，对研究Agent CLI架构的人来说，是意外之喜。
不是为了抄袭商业代码，是为了学习QueryEngine怎么处理流式响应加工具循环、Tool系统怎么设计权限模型、
Bridge怎么实现IDE-CLI双向通信、Feature Flags怎么消死代码等通用架构问题。
b.Anthropic的Agent新架构
a.引言：新架构的发布
a.博客文章标题
《Scaling Managed Agents: Decoupling the brain from the hands》
b.初印象与实质
初看以为是学术味重的分布式系统设计原则，实则是解决具体痛点：将所有 Agent 组件塞进一个容器里会发生什么。
b.早期设计：耦合架构的困境
a.初始设计方案
将 session、harness、sandbox 全放在一个容器里，文件编辑直接 syscall，无服务边界。
b.“宠物”与“牲畜”的比喻
耦合设计导致容器变成“宠物”（精心照料、不能丢），而非“牲畜”（编号、可替换）。
c.运维死循环
容器挂了 session 就丢了；容器卡住需要进去救；但容器存有用户数据，进去看就违规，不看又无法排查。
d.过往经验教训
类似“一个服务干所有事”的早期项目，数据库、逻辑、文件耦合，导致故障时无法在不触碰生产数据前提下排查。
c.核心解法：脑子和手分开
a.组件拆解为三个接口
Session：只负责记事（append-only log）。
Harness（脑）：调用 Claude、路由 tool calls、管理上下文。
Sandbox（手）：执行代码、编辑文件、跑外部工具。
b.交互模式变革
Harness 将 Sandbox 视为一个 tool（execute(name, input) → string），不关心 Sandbox 具体形态。
c.“牲畜”化改造
Sandbox 变成可替换的“牲畜”，死了一个 Harness 捕获失败，Claude 决定重试，新 Sandbox 用标准 recipe 初始化。
d.安全边界的重新定义
a.耦合设计的隐患
Sandbox 跑代码且存凭证，prompt injection 可读取环境变量获取 token，导致严重后果。
b.解耦后的安全机制
凭证永远不进 Sandbox。
c.Git 处理方式
Access token 在 Sandbox 初始化时用于 clone，wired 到本地 git remote，Agent 从未见过 token。
d.MCP 工具处理
OAuth token 存在 vault，Claude 调工具走 proxy，proxy 取凭证调用外部服务，Harness 不知晓凭证存在。
e.安全屋比喻
关键人物（凭证）在安全屋，外头的人（Harness）只知道地址，不知道里面有什么。
e.Session 与上下文窗口的区别
a.长任务挑战
任务常超过 context window 长度，标准压缩或 trimming 操作不可逆。
b.Session 设计
设计成 context window 外部的对象，getEvents() 可按位置切片读事件流。
c.灵活性优势
支持回退查看操作前状态或重读上下文，事件先在 Harness 做 transformation 再喂给 Claude。
f.性能收益：多脑多手
a.原有设计瓶颈
一个脑绑一个容器，需先 clone repo、boot process，增加 time-to-first-token（TTFT）。
b.解耦后优化
容器按需 provision，Harness 变成“牲畜”，挂了可重启并接续事件流。
c.延迟降低数据
p50 TTFT 降低 60%，p95 降低 90%。
d.逻辑支撑
很多脑共享很多手，不是每个脑绑一个手。
g.核心启示：别做假设
a.假设的时效性
资源在身边、模型焦虑 context limit、一脑一手等假设，随模型迭代可能变成死代码。
b.死代码的无奈
模型变了（如 Opus 不焦虑 context limit），旧逻辑（如 context reset）变成废代码但不敢删。
c.操作系统类比
操作系统通过虚拟化硬件（如 read() 接口）适应未来程序，Managed Agents 试图通过通用接口（session、harness、sandbox）适应未来实现。
d.Meta-harness 思路
不规定 Claude 需要什么 harness，而是提供能装任何 harness 的系统。
h.总结与展望
a.短期意义
Anthropic 内部工程实践，让 Managed Agents 产品线跑得更稳。
b.长期影响
可能促使 Agent 系统开发者重新思考架构。
c.耦合设计的合理性
简单、直接、无网络开销，适合特定场景。
d.解耦的代价
需处理更多服务边界、异步问题和运维复杂度。
e.最终思考
如果不早动手拆分，未来模型和需求变化时，拆分成本会更高。
c.复刻Claude生成式UI交互
a.项目背景
Anthropic在Claude上线生成式UI新交互，可在聊天中可视化展示信息，作者参考该方案，
耗时两天在Codex与Claude辅助下完成复刻，并集成到Agent产品Code Pilot。
b.核心功能优势
AI可在聊天中直接绘制交互式图表，支持流式输出、边生成边渲染，SVG节点逐个呈现，
生成完成后可直接交互，解决传统AI写网页需等待全部代码生成才能渲染的问题。
c.产品体验地址
Code Pilot体验地址：https://github.com/op7418/CodePilot
d.功能应用场景
a.数据分析
可将数字信息转化为可视化图表，文字与图表结合输出，数据关系清晰易懂。
b.小工具制作
生成复利计算器、贷款计算、单位换算等可交互小工具，支持实时参数调整与结果更新。
c.架构图绘制
可视化呈现项目架构、实现方案、流程图等，大幅提升架构理解效率。
d.线上数据分析
输入GitHub仓库链接，自动抓取数据并可视化分析星数、fork数、技术栈、架构等项目信息。
e.交互与深度解释
可与生成的示意图交互，触发详细解释，支持物理数学公式可视化，参数可实时调控。
e.模型支持情况
支持Claude、Kimi K2.5、Minimax M2.5、Anthropic原生模型，其中Kimi K2.5图形效果与架构分析表现突出，为推荐首选。
f.实现方案对比
a.Claude官方实现
采用tool_use机制，模型调用专用tool输出结构化widget内容，前端解析参数渲染，使用Shadow DOM做隔离。
b.CodePilot不采用官方方案原因
SDK限制：Claude Agent SDK的claude_code模式无法注册自定义tool，仅支持text delta流；
流式体验：tool_use需等input_json_delta拼接完成才能渲染，不支持增量渲染；
渲染隔离：Claude使用Shadow DOM，CodePilot选择sandbox iframe，隔离更彻底。
g.CodePilot具体实现
a.触发方式
模型输出特殊Markdown代码围栏```show-widget触发渲染，复用CodePilot已有代码围栏模式，前端解析链天然支持。
b.渲染方式
每个widget渲染在sandbox iframe中，srcdoc为定制receiver页面；CSP仅放行4个CDN脚本，禁止网络请求；
通过postMessage实现内容更新与高度同步，拦截<a>点击并转发父页面新窗口打开，同步主题切换。
c.CSS变量桥接
采用OKLCH色彩空间CSS变量，初始化时将CodePilot变量注入iframe:root，实现widget与应用视觉融合，深色模式实时同步。
d.流式渲染处理
正则匹配代码围栏状态，手动处理未完成JSON与HTML内容；检测未闭合<script>标签并截断，120ms防抖控制更新频率；
预览阶段剥离脚本与事件处理器，保证流式体验。
h.体验问题与修复方案
a.文字消失
检测未闭合围栏前文本，直接渲染为MessageResponse，绕过解析函数。
b.高度跳变
首次高度报告时临时禁用CSS transition，后续高度调整使用平滑过渡。
c.Finalize闪烁
临时容器解析新HTML，对比视觉内容，相同则跳过DOM替换，仅追加脚本执行。
d.滚动回跳
模块级高度缓存，以widgetCode前200字符为key，新实例从缓存读取初始高度。
e.Script代码泄露
检测未闭合<script>标签并截断，截断时展示shimmer遮罩与状态提示。
f.iframe Ready竞态
增加iframe onLoad回调兜底，确保可靠捕获就绪信号。
g.React组件树稳定性
为partial widget设置稳定key，将shimmer overlay移入组件内部，保持组件树结构不变。
i.项目总结
生成式UI系统核心复杂度不在于HTML在iframe运行，而在于流式传输、组件生命周期、主题切换等状态下的视觉稳定性，
需处理React渲染、浏览器管线、消息时序等问题，最终实现图表与聊天内容自然融合的效果。
d.CLAUDE.md项目火爆现象
a.一个CLAUDE.md文件一天5.8kStar
阅读本文大概需要 4 分钟。
4 月 13 日，GitHub Trending 全球第二名是一个核心就一个 CLAUDE.md 文件的仓库。
不是什么新框架，不是什么新语言，就是一个 .md 文件。一天之内拿到了 5,828 颗星。
更离谱的是，同一天 GitHub Trending 前 5 名里有 4 个都是 Claude Code 相关项目。GitHub、Hacker News、Reddit、X、YouTube 几乎同时讨论同一件事：怎么让 Claude Code 更好用。
这不是偶然。这是开发者在平台还没完善时，自发地建起了一整套实践层。而这个 CLAUDE.md 文件，恰好成了这场运动的缩影。
b.先说这个文件是什么
开发者 Forrest Chang 基于 Andrej Karpathy 对 Claude Code 的使用观察，整理了一份 CLAUDE.md 模板，仓库名叫 andrej-karpathy-skills。
需要说明的是，这不是 Karpathy 本人写的。但标题用了他的名字，内容也确实来自他在 X 上的分享。Karpathy 作为特斯拉前 AI 和自动驾驶视觉总监、OpenAI 创始成员，他对 LLM 行为模式的观察本身就自带分量。
这个模板提炼了四个核心原则，每一个都精准击中了 AI 编程中的真实痛点。
c.别替我做主对抗LLM的静默假设
第一个原则，Karpathy 称之为 Think Before Coding。
问题在哪？LLM 遇到模糊需求时，不会停下来问你。它会自己做个假设，然后一路狂奔。你让它「加个导出功能」，它默认你要导出 CSV，于是整个实现都围着 CSV 格式展开。实际上你想导出的是 JSON。等你看完代码才发现方向错了，时间已经浪费了。
Karpathy 的原话说得很直白："The models make wrong assumptions on your behalf and just run along with them without checking."——模型会替你做错误的假设，然后头也不回地往下跑。
这个观察太准了。我自己的体验就是这样，Claude Code 最让人头疼的不是写不出代码，而是它太「自觉」了。你随口说一句，它就当需求文档用了，从来不回头确认。
模板给的办法也简单粗暴：强制在执行前停下来。遇到模糊的地方必须说明假设、呈现多种可能的解读、不确定就问。说白了就是把「静默假设」变成「显式确认」。
d.别搞那么复杂LLM的过度工程病
第二个原则是 Simplicity First。
Karpathy 发现了一个很搞笑的倾向："They really like to overcomplicate code and APIs, bloat abstractions... implement a bloated construction over 1000 lines when 100 would do."——它们特别爱把代码搞复杂，膨胀抽象层，用 1000 行实现一个 100 行就能搞定的东西。
你说「加个缓存」，它给你搞一个完整的 LRU 实现，带淘汰策略、线程安全、监控钩子。你说「加个重试」，它能给你抽象出一个通用的任务调度框架。
坦白讲，这个毛病不是 Claude 独有的。几乎所有 LLM 都有这个倾向。我认为原因是它们在训练数据里见过太多「教科书式的完整实现」，一旦你提到某个概念，它就忍不住把教科书上的全套方案给你端上来。
模板里给了一个很好的自测标准：一个资深工程师会认为这过度工程化了吗？ 如果答案是 yes，那就砍。只写解决问题所需的最少代码，不做任何推测性设计。
这个标准好就好在它把主观判断变成了一个可操作的检验。你不需要精确定义什么叫「过度」，你只需要问自己一个资深同事看到这段代码会不会皱眉头。
e.别动别人的代码手术式修改
第三个原则叫 Surgical Changes，核心就一句话：只动你必须动的，只清理你自己弄脏的。
这个痛点用过 Claude Code 的人都懂。你让它修一个 bug，它修完了 bug，顺手把变量命名「优化」了一下，重构了几个它觉得不够优雅的函数，等你 review 的时候 diff 满屏飘红，根本分不清哪些是修 bug 的，哪些是它「顺手」搞的。
模板里做了一个很关键的概念区分：你自己引入的死代码，清理掉；别人留下的死代码，标记出来，不要删。
这个区分看似简单，实际上是在回答一个更深的问题：AI 在代码仓库里的修改边界在哪里？它应该有多大的「自主权」？模板的态度很明确——保守。宁可少做，不要多做。
f.给它目标别给指令目标驱动执行
第四个原则是我认为最有洞察力的一个。Karpathy 说："LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."
翻译过来就是：LLM 在循环逼近目标这件事上非常厉害。别告诉它怎么做，给它成功标准，然后看着它干。
举个例子。你说「修复这个 bug」，Claude Code 可能在十几个方向上乱撞。但如果你说「写一个能复现这个 bug 的测试，然后修改代码让测试通过」，它就有一个明确的循环目标了：测试挂了 → 改代码 → 测试过了 → 收工。
这个洞察的厉害之处在于它抓住了 LLM 最强的能力——迭代式执行。很多人把 LLM 当搜索工具用，问一个问题等一个答案。但 LLM 真正的威力是在有明确反馈循环的情况下反复迭代。你给它一个好的目标定义，它的执行力惊人。
g.为什么一个文本文件能引爆GitHub
聊完四个原则，更重要的问题是：凭什么一个 Markdown 文件能在一天内拿到近 6000 颗星？
我觉得这背后是一个行业信号。
先看当天 GitHub Trending 的整体情况。4 月 13 日，前 5 名中有 4 个是 Claude Code 相关项目：hermes-agent（+11,297 星）、andrej-karpathy-skills（+5,828 星）、claude-mem（+3,185 星）、claude-code-best-practice（+2,477 星）。这些项目加起来一天拿了超过 22,000 颗星。
这说明什么？
这让我想起两个历史时刻。2013 年的 npm 生态爆发——Node.js 平台本身还很粗糙，但开发者已经疯狂地往上面堆包了。2018 年的 Kubernetes operators——K8s 的 operator 框架刚出来没多久，社区就开始搞各种各样的 operator 来自动化运维任务。
共同特征是什么？开发者在平台还没完善的时候，就开始自建工具层和实践层。 他们等不了官方把所有事情都想清楚，自己先干起来。
Claude Code 就是 2026 年版的 Node.js。Anthropic 提供了一个强大的底层能力（能读代码、写代码、执行命令的 AI），但在「怎么用好它」这件事上留下了大量空白。CLAUDE.md 是 Anthropic 给出的一个机制——你可以往里面写规则来引导 AI 的行为。但 Anthropic 没有告诉你该写什么规则、怎么写才有效。
这个空白被社区填上了。
Karpathy 的模板之所以爆火，不是因为它多么高深，恰恰相反——它把一群高级开发者的实践经验压缩成了四条任何人都能理解的规则。它解决的是一个普遍存在的困惑：我知道 CLAUDE.md 很重要，但我不知道该往里面写什么。
这种「从精英实践到大众模板」的转化，历来是技术传播中最有价值的一步。
h.CLAUDE.md的天花板
说完了好的，也得说说局限性。
据社区反馈和 Anthropic 官方文档的暗示，CLAUDE.md 的遵从率大约是 80%。什么意思？你写了 10 条规则，Claude Code 大概率会遵守其中 8 条，剩下 2 条可能被忽略。而且当 CLAUDE.md 超过 200 行之后，遵从率会进一步下降。
换句话说，如果你的某些规则是绝对不能违反的——比如「不要删除数据库迁移文件」——你不应该指望 CLAUDE.md。你应该用 hooks，一种在工具执行前强制校验的机制。hooks 是硬约束，CLAUDE.md 是软引导。
还有一个更深层的局限：CLAUDE.md 只管「怎么写代码」，不管「该不该写这个功能」。它能让 Claude 写出更简洁的代码、做更精准的修改，但它不能帮你做产品决策。你让 Claude 加一个用户注册功能，它不会反问「你们真的需要自建注册系统吗？用 Auth0 行不行？」这是另一个层面的问题。
社区里有人分享了一个观察：最好的 CLAUDE.md 会随时间变短。 因为你不断地删掉 Claude 自然就会遵守的规则，只留下它确实需要被提醒的那些。这和好的代码注释是一个道理——注释应该解释「为什么」，而不是重复代码已经在说的「是什么」。
i.最后
4 月 13 日那天 GitHub 上发生的事情，本质上是开发者社区对 AI 编程工具的一次集体回应。
AI 编程工具的能力增长速度远超我们的驾驭能力。Claude Code 能做的事情越来越多，但怎么让它做对的事、不做多余的事，目前还没有官方的标准答案。社区在用最原始的方式——写 Markdown 文件、分享模板、互相抄——来摸索这套最佳实践。
这个过程有点混乱，有点原始，但充满了活力。
Forrest Chang 的那个仓库可能几个月后就被遗忘了，就像 npm 上大多数早期包一样。但它代表的趋势不会消失：AI 编程工具的「使用说明」正在成为一种新的技术知识形态。 掌握这些知识的人，不一定是最懂算法的人，而是最懂怎么和 AI 协作的人。
如果你还在纠结要不要认真写一个 CLAUDE.md，我的建议是：别纠结了，直接开始写。先从 Karpathy 的四个原则开始，用上一周看看效果，然后把你自己发现的规则加进去。你的 CLAUDE.md 会变成你个人编程经验的压缩包——只不过这份经验不是给你自己看的，是给 AI 看的。
2.5 智能设计1
00.汇总
a.分类1
ide设计
rules设计
agent设计
pencil设计
pi-mono设计
b.分类2
agentskills设计
antigravity设计
agent的6个文件
agent的操作本质
agent的文件系统：双下文
c.分类3
DESIGN.md开放标准发布
上下文管理：Agent 的“记忆”难题
Cursor的自我颠覆
谷歌提出CLI的7条设计原则
Kimi-Agent集群
d.分类4
xxxxxx
01.常用信息1
a.ide设计
a.设计1
a.三种问答方式
command + K、command + i 和 command + l
Plan模式：In Plan mode, Cline will gather information to architect a plan；在规划模式下，Cline 将收集信息以构建规划
Act模式：In Act mode, Cline will complete the task immediately；在行动模式下，克莱恩将立即完成任务
b.Composer（编写器）
Agent：持续对话、深入分析、迭代式
Normal：一问一答、简单直接、一次性
c.内嵌对话框
按 Alt+Enter，即可进入问答模式，不会自动新增、修改代码
当问答对话完成，需要 cursor 帮忙修改代码，给它个肯定的回复再回车即可
d.Codebase
使用 Codebase 前，确保 cursor 分析完了整个项目
设置忽略文件：点击蓝色的 Config ignored files。在配置文件中，也能用 cursor
然后在设置中重建索引，再去 COMPOSER（快捷键 Ctrl+I） 中 @Codebase 问一下问题
会发现 Search completed 中没有 sorting_algorithms.py 文件，说明忽略成功
b.设计2
a.tab补全
cursor 会根据用户行为预测代码补全，除了早期 copilot 写注释以及理解上下文的代码补全，
cursor 支持用户任意修改智能预测以及修正代码格式错误，比如大括号闭合缺失修正；
以及多行代码批量预测（一次 tab 自定修改多行），光标预测（cursor 会在预测你下次修改的地方出现 tab 图标）
b.context
方式1：Add context 添加上下文
方式2：@ 灵活选择上下文
-------------------------------------------------------------------------------------------------
Files: 基于文件上下文进行提问，直接直接把文件拖拽到聊天作为上下文
在聊天窗口按下 /即可唤醒上下文，可以直接关联目前所有打开的文件或者被激活的文件
Folders: 基于目录作为上下文，同样支持目录拖拽，非常方便
Code: 基于具体的代码块作为上下文，更方便的做法是先选中然后 Command + L/I
Codebase: 将整个项目作为上下文，与 command + enter 功能相同，我们可以 @codebase 后回车询问本地项目中感兴趣的问题
Git: 基于 Git 历史 commit 快速了解代码变化或者提交信息，比如基于某个 commit 让 cursor 帮我撤销这个提交
Summarized Composers: 与之前 AI 问答的历史记录进行对话
Docs:基于文档作为上下文，比如我们项目使用了 react，我们可以将 react 官方文档保存为文档，后续方便提问
Web: 类似 deepseek 联网，获取互联网最新信息作为辅助上下文进行提问
Lint errors: 询问代码中的语法错误和潜在问题
Recent Changes: 自动跟踪代码库最近更改作为上下文
Cursor Rules: 基于 Cursor 的自定义规则和设置对话
c.设计3
a.核心1：检查点功能
检查点功能是Cline AI编程助手在3.1版本中推出的一项革命性功能。每当Cline使用工具时，都会智能自动对工作区进行快照保存，形成一个"检查点"。
比较功能：用户可以查看当前工作区与检查点之间的差异，快速定位代码或文件的改动。这种直观的差异化视图能够显著减少排查问题的时间。
恢复功能：用户可以选择恢复到某个检查点，支持"恢复任务和工作区"、"仅恢复任务"以及"仅恢复工作区"三种模式。
检查点功能的核心价值在于为开发者提供了“后悔药”。开发者可以轻松回滚到之前的状态，避免了手动排查和修复的繁琐过程。
此外，比较功能让开发者能够快速了解改动内容，尤其适用于多人协作或复杂项目的开发场景。
b.核心2：任务变化追踪
Cline在3.1版本中新增了智能"查看新变化"按钮，允许用户在任务完成后实时快速查看工作区内的所有改动。
任务变化追踪功能在提高透明度的同时，也减少了开发者对任务历史的依赖。开发者无需逐条检查任务日志即可掌握全局改动情况，从而更专注于下一步工作。
这一功能在复杂任务或长时间运行的任务中尤为重要，能够显著减少信息获取的时间成本。
c.核心3：计划/执行模式切换
计划/执行模式切换是Cline AI编程助手在3.2版本中推出的一项创新功能。通过这一功能，Cline能够在两种模式之间智能切换：
计划模式（Plan Mode）：Cline以架构师的角色运行，负责收集信息、提出澄清性问题并设计解决方案。
执行模式（Act Mode）：Cline专注于执行计划模式中的任务，按照既定的方案逐步完成具体操作。
计划/执行模式切换功能的最大优势在于明确了任务的分工与流程。Cline的这一功能不仅让开发者能够更清晰地掌控任务进度，还能避免因规划不足导致的返工问题。
此外，计划模式能够帮助开发者识别潜在问题并优化方案，而执行模式则确保了操作的高效性和准确性。这种分阶段的工作方式特别适用于复杂项目或需要多次迭代的场景。
b.rules设计
a.设计1
a.什么是 Rules for AI？
Rules for AI 是一种类似于系统提示（system prompt）的功能。
通过在设置中填写规则，这些规则会在 Cursor Chat 和 Ctrl/⌘ K 操作时生效。
简单来说，它可以帮助你定制 AI 的行为，使其生成更符合你需求的代码。
b.cursorrules 文件的作用
.cursorrules 文件则进一步细化了 AI 的行为定制。
它在项目根目录中创建，用于根据项目的特定需求调整 AI 的响应。
.cursorrules：勾选的时候优先使用项目内.cursorrules文件的配置，如果是项目内和全局有有冲突，以项目内为准
.cursorrules：cursor 专属的 promote 提示词，它可以根据编程语言、项目架构、代码规范等各种条件约束，就像公司的新手 wiki，.cursorrules 是 cursor 和项目理解的桥梁
c.主要有以下几点作用
定制 AI 行为：根据项目需求调整 AI 的响应，确保生成更相关和准确的代码建议。
一致性：通过定义编码标准和最佳实践，确保 AI 生成的代码与项目样式保持一致。
上下文意识：提供项目的重要上下文信息，如常用方法、架构决策或特定库，使 AI 生成的代码更具洞察力。
提高生产力：通过明确的规则，减少手动编辑的需要，加速开发过程。
团队对齐：在团队项目中，共享 .cursorrules 文件可以确保所有成员获得一致的 AI 辅助，促进编码实践的一致性。
项目特定知识：包含有关项目结构、依赖关系或独特需求的信息，帮助 AI 提供更准确和相关建议。
b.设计2
a.cursorrules 文件的使用方法
.cursorrules 文件的使用非常简单。
你可以在项目根目录中创建一个 .cursorrules 文件，并根据需要填写规则。
-------------------------------------------------------------------------------------------------
如果你不想手动编写，也可以通过以下方式获取：
访问 cursor.directory，从网站中复制对应项目的 prompt 并粘贴到 .cursorrules 文件中。
从 GitHub 直接下载 .cursorrules 文件到项目根目录。
b.Rules for AI 与 .cursorrules 的优先级
根据测试，Rules for AI 和 .cursorrules 的优先级如下：
Rules for AI 优先于 .cursorrules 文件。
在工作空间中，第一个文件夹下的 .cursorrules 文件会生效。
需要注意的是，如果你的工作空间中有多个仓库（例如后端和前端），每个仓库可能都有自己的 .cursorrules 文件。然而，目前无法同时让多个 .cursorrules 文件生效。
c.rules
1.预先设定5-10条清晰的项目规则，让Cursor了解你的结构和限制。尝试为现有代码库使用/generate rules。
2.在提示中要具体。详细说明技术栈、行为和限制，就像一个迷你规范。
3.文件逐个工作；在小块、专注的部分生成、测试和审查。
4.先编写测试，锁定它们，生成代码直到所有测试通过。
5.总是审查AI输出，并硬修复任何破坏性的内容，然后告诉Cursor将其用作示例。
6.使用@文件、@文件夹、@git将Cursor的注意力集中在代码库的正确部分。
7.将设计文档和清单保存在.cursor/中，以便代理能够了解下一步要做什么。
8.如果代码错误，就自己编写。Cursor从编辑中比从解释中学习得更快。
9.使用聊天历史记录来迭代旧提示，而无需从头开始。
10.有意选择模型。Gemini用于精确，Claude用于广度。
11.在新的或不熟悉的堆栈中，粘贴文档链接。让Cursor逐行解释所有错误和修复。
12.让大型项目过夜索引，并限制上下文范围以保持性能敏捷。
c.agent设计
a.引言
本文从 OpenClaw / Agent-Zero / Pi-Mono / Manus / DualPath 论文中提炼，充当大家设计 agent 时的判断标准而不是教条。
当两个设计方案冲突时，用这些原则裁决。
b.第一部分：物理约束（不可违抗的现实）
这些是 LLM agent 运行环境的硬性约束。不是我们选择的，是物理世界强加的。任何设计如果假装这些不存在，就会在生产中崩溃。
a.C1.上下文窗口有限且昂贵
128K token 窗口约等于一本300页的书。每次 API 调用都要为窗口中的每个 token 付费。未缓存 input 价格为 $3/M tokens，50 轮对话可能花 $75。
上下文是最稀缺的资源，每个 token 都有机会成本。
b.C2.KV Cache 前缀一旦改变，全部重算
Anthropic Prompt Caching 中，前缀匹配价格为 $0.30/M，不匹配为 $3.00/M。DualPath 论文证明，Agent 多轮推理中 KV-Cache 命中率需大于等于 95%，瓶颈不在算力，在把缓存搬回来的 I/O。Prefix 一变，不只是多花钱，而是打满存储带宽。
前缀的任何变动都有 10 倍成本放大效应。
c.C3.注意力在中间衰减（Lost in the Middle）
LLM 对 prompt 开头和末尾的 token 注意力最强，中间部分的信息容易被遗忘。上下文越长，中间的衰减越严重。
重要信息必须在开头（system prompt）或末尾（最近的 tool_result）。放在中间的信息，等于没放。
d.C4.LLM 输出不可靠
LLM 会循环（同一个工具调同样参数 20 次），会幻觉（编造不存在的文件路径），会忘记（30 轮后忘了最初的任务目标），会偏移（被最近的错误带偏，忽略全局计划）。
不能信任 LLM 会自己停下来、自己记住、自己纠偏。系统必须有独立于 LLM 的防护机制。
e.C5.工具执行不可预测
bash 命令可能跑 0.1 秒，也可能跑 10 分钟。文件读取可能返回 100 字节，也可能返回 2MB。网络请求可能成功，也可能超时。用户可能随时想中断当前操作。
任何工具调用都必须可取消、可超时、可截断。
f.C6.信息有不同的半衰期
决策（我们选 JWT 而不是 session）的半衰期为整个 session。错误教训（这个方法行不通）的半衰期为当前任务。文件内容（auth.rs 第 42 行）的半衰期为下次修改前。命令输出（npm install 的日志）的半衰期为几分钟。中间推理（让我想想...）的半衰期为当前轮次。
不同类型的信息应该有不同的保留策略。一刀切的保留最近 N 条会丢决策、留垃圾。
c.第二部分：设计原则（我们的选择）
a.P1.KV Cache 前缀一致性
应对约束 [C1, C2]。连续 API 调用之间，prompt 的前缀必须保持字节级一致。这是所有设计决策的最高优先级约束。违反它的代价是 10 倍成本加推理系统 I/O 瓶颈。
具体要求：
1.System prompt 构建完成后永远不变。不放时间戳、不动态增删工具 schema、不更新技能列表。
2.信息只通过 tool_result 追加到末尾，不在中间插入。
3.技能指南附着在 tool_result 上，不改 system prompt。
4.序列化必须确定性（JSON key 排序、浮点格式一致、空格/换行规范化）。
5.压缩段一旦生成就不再修改（pruning 产出的摘要成为新的不可变前缀）。
6.Skill snapshot 在 session 开始时锁定（session 中途不因 skill 变化而改变 system prompt）。
违反信号：如果你发现自己在做以下事情，停下来——往 system prompt 里塞动态信息（当前时间、工作进度...）；在对话历史中间插入新消息；修改已发送的 tool_result 内容；每轮重新生成 system prompt。
b.P2.Append-Only 上下文
应对约束 [C1, C2, C3]。上下文只能追加，不能插入、不能重排。所有信息回流上下文的方式只有一条：作为 tool_result 追加到末尾。
这是 P1 的直接推论，但重要到值得独立列出。
允许的操作：在末尾追加 user / assistant / tool_result 消息；对旧消息做原地缩减（Soft Trim：缩短 tool_result）；对旧消息做原地替换（Hard Clear：替换为占位符）；整段替换为压缩摘要（Stage 3 pruning，但此后摘要不再变）。
禁止的操作：在中间插入新消息；重排消息顺序；修改已有消息的内容（Soft Trim/Hard Clear 除外）；删除消息后让后续消息前移。
c.P3.按需加载一切
应对约束 [C1, C3]。不预装任何可以推迟加载的信息。System prompt 只放索引，完整内容等到需要时才通过 tool_result 注入。
原因：上下文寸土寸金（C1），中间的信息会衰减（C3）。预装 10 个技能指南，agent 可能只用 2 个——另外 8 个占了 16K token 却零收益，还把有用信息推到了注意力衰减区。
技能加载：System prompt 放一行摘要（约 50 tokens/skill）；首次使用工具时，完整指南（约 2K tokens）附着在 tool_result；后续使用（5-20 轮后），关键提醒（约 100 tokens）。
记忆检索：不预加载任何历史记忆，Agent 主动调用 memory_search，结果作为 tool_result 返回。
文件内容：不预读项目文件，Agent 用 read 工具按需读取。
判断标准：如果一段信息放进 system prompt 后，有大于 30% 的 session 不会用到它，就不该预装。
d.P4.渐进降级
应对约束 [C1, C6]。资源紧张时，按信息价值从低到高逐步丢弃，而不是一刀切。
不同信息的半衰期不同（C6），所以 pruning 必须区分对待。
三阶段 Pruning：
Stage 1 (30%): Soft Trim — 只缩减大 tool result。损失是细节（但 head + tail 保留），收益是前缀完全不变，零 cache 失效。
Stage 2 (50%): Hard Clear — 旧 tool result 变为占位符。损失是旧工具输出的全部内容，收益是大量释放空间，前缀前段不变。
Stage 3 (70%): 分级压缩 — 按事件类型差异化处理。Decision 为 Level 1（保留关键细节）；Error 为 Level 1（保留失败路径）；FileModified 为 Level 2（一行摘要）；FileRead 为 Level 3（删除，可检索召回）；Output 为 Level 3（删除）。
五层错误恢复（同理）：Truncate → Retry → Fallback → Auto-compact → Reset → Fail-fast。
核心直觉：能在 Stage 1 解决的问题，绝不升级到 Stage 2。每多一级，信息损失呈指数增长。
e.P5.末尾复述
应对约束 [C3, C4]。关键工作状态必须被复述到上下文末尾，利用 LLM 对近期 token 注意力更强的特性。
LLM 会忘记 30 轮前的任务目标（C4），中间信息会被淹没（C3）。解法不是把信息固定在开头（那会破坏前缀一致性），而是让 agent 主动把关键信息搬到末尾。
机制：todo.md 复述模式。Agent 读取 todo.md，工作状态作为 tool_result 出现在末尾。LLM 在做决策时直接看到当前进度。不需要额外的工作记忆抽象。复用已有的文件读写工具。
何时复述：任务切换时（读 todo.md 重新对齐）；长工具执行后（读 todo.md 恢复上下文）；连续 10+ 轮工具调用后（主动复述）。
f.P6.系统级不信任
应对约束 [C4]。系统必须有独立于 LLM 的防护机制，不能依赖 LLM 自觉停下来。
LLM 陷入循环时不会自我诊断（C4）。所以防护层必须在 LLM 之外。
四层循环检测（全部基于 hash 比对，不依赖 LLM 判断）：Generic Repeat（同工具同参数重复 N 次）；Poll No Progress（轮询结果无变化）；Ping-Pong（两工具交替循环）；Circuit Breaker（全局连续 30 次无进展）。
错误触发技能重载：连续 2 次同类错误，系统自动重新注入完整指南。不等 LLM 自己意识到需要重读文档。
上下文安全阈值：HARD_MIN = 16K tokens（拒绝执行，不让 LLM 在极小窗口里挣扎）；WARN_BELOW = 32K tokens（发出警告）。
核心原则：不靠 LLM 控制 LLM。防护机制必须是确定性的、基于规则的、在 LLM 推理循环之外的。
g.P7.可中断性
应对约束 [C5]。Agent 的任何操作都必须可以被用户随时中断，并且中断后系统状态保持一致。
工具执行不可预测（C5），用户需要实时控制权。
三种中断粒度：
1. Steering（软中断）：用户在工具执行期间发消息，当前工具完成后，跳过剩余工具。已完成的工作保留，未执行的标记 [Skipped]。LLM 看到完整上下文（包括中断请求）。
2. Abort（硬中断）：AbortSignal 全链路传递。当前工具立即终止，部分结果丢弃。
3. Session Reset（最硬中断）：不可恢复时，重建 session。旧 transcript 保留用于调试。
为什么 Steering 优于简单 Abort：Abort 丢弃所有 in-flight 工作。Steering 保留已完成的，只跳过未执行的，信息损失最小化。
h.P8.信息只转换，不消失
应对约束 [C6]。信息可以被压缩、摘要、降级，但不应该被默默删除。被 pruning 的内容必须仍然可检索。
事件日志（旁路存储）是完整记忆：每个 tool call、每个决策、每个错误，都 append 到 JSONL。上下文中被 pruning 掉的内容，在事件日志中依然完整。
检索路径：Agent 调用 memory_search，从事件日志中搜索，结果作为 tool_result 回到上下文末尾。被遗忘的信息可以被想起来。
实际意义：Stage 3 pruning 把 FileRead 事件删除了，但事件日志中完整保留。如果 agent 后来需要这个信息，memory_search 找回来。无信息永久丢失。
i.P9.可观测性优先
应对约束 [全部]。无法测量的就无法优化。每个关键路径都必须有指标。
上下文不可见，无法判断 prefix 是否稳定，无法优化 cache 命中。Pruning 无记录，不知道信息损失了多少，无法调整阈值。循环检测无日志，不知道 LLM 浪费了多少 token，无法改进 prompt。
必须追踪的指标：prefix_stability_ratio（连续调用间 prefix 不变的比例，目标 >85%）；cache_hit_ratio（Prompt Caching 命中率，目标 >85%）；pruning_stage_distribution（各阶段触发比例，目标：80%+ 在 Stage 1）；loop_detection_blocks（循环阻止次数，趋近 0 说明 prompt 质量好）；context_utilization（上下文使用率分布，目标：均匀使用 40-70%）。
Context Trace（每次 API 调用记录）：{ stage, message_count, total_tokens, prefix_hash, timestamp }。prefix_hash 变了等于 cache miss，立即定位原因。
j.P10.文件系统即记忆
应对约束 [C1, C3]。Agent 通过正常的文件读写管理工作状态，不需要专门的记忆抽象。
为什么不用专门的 memory 系统（Phase 0）：文件系统已经是持久化的、可搜索的、人可读的。Agent 写 todo.md 等于在记笔记。Agent 读 todo.md 等于在回忆。Agent grep 项目等于在搜索记忆。不需要向量数据库、不需要 embedding、不需要额外的 API 调用。
文件系统 vs 专用记忆的权衡：文件系统为零额外成本、人可审计、agent 已有工具、但搜索能力弱。向量记忆为语义搜索强、但增加复杂度、需要 embedding 调用、不透明。
Phase 0 用文件系统。Phase 3 可选加向量搜索。
d.第三部分：原则间的优先级
a.当原则冲突时，按此顺序裁决
P1 (前缀一致性) > P2 (Append-only) > P7 (可中断性) > P6 (不信任 LLM) > P4 (渐进降级) > P3 (按需加载) > P5 (末尾复述) > P8 (不丢信息) > P9 (可观测性) > P10 (文件即记忆)。
b.冲突 1：P3 (按需加载) vs P5 (末尾复述)
场景：Agent 需要技能指南，但 tool_result 已经很长了。
裁决：P3 > P5。技能指南按需加载（附着在 tool_result 上），如果 tool_result 因此过长，P4（渐进降级）会处理——先 Soft Trim 旧的 tool_result，而不是跳过技能注入。
c.冲突 2：P1 (前缀一致性) vs P4 (渐进降级)
场景：上下文 70%，需要 Stage 3 pruning，但 cache 还在 TTL 内。
裁决：P1 > P4。延迟 pruning，等 cache TTL 过期。除非到了 95%（紧急阈值），此时 P4 升级为生存级优先。
d.冲突 3：P7 (可中断性) vs P2 (Append-only)
场景：用户 steering 中断，需要跳过剩余 tool calls。
裁决：不冲突。跳过的 tool calls 仍然追加 [Skipped] 占位符，保持 append-only 语义。P7 通过 P2 的机制实现，不违反它。
e.冲突 4：P6 (不信任 LLM) vs 用户体验
场景：循环检测触发 block，但 LLM 其实快要解决问题了。
裁决：P6 优先。宁可误杀也不能让 LLM 空转 50 次。但提供 warning 阶段（10 次）让 LLM 有机会自我纠正，只在 20 次时才 block。渐进，但不妥协。
e.第四部分：一句话速查表
# 原则 一句话
P1 前缀一致性 连续调用间 prefix 字节级不变
P2 Append-Only 信息只追加到末尾，不插入不重排
P3 按需加载 不预装任何可以推迟的信息
P4 渐进降级 能在 Stage 1 解决的不升级到 Stage 2
P5 末尾复述 关键状态通过文件读写推到上下文末尾
P6 不信任 LLM 防护机制独立于 LLM，基于规则和 hash
P7 可中断性 任何操作可随时中断，状态保持一致
P8 不丢信息 信息可压缩降级，但旁路存储完整保留
P9 可观测性 无法测量的无法优化
P10 文件即记忆 用文件系统管理工作状态，不造抽象
f.附：这些原则的来源追溯
原则 主要来源 验证来源
P1 前缀一致性 Anthropic Prompt Caching 机制 DualPath 论文（I/O 瓶颈量化证据）
P2 Append-Only 我们 v2 架构的核心设计 OpenClaw（prefix stability 设计）
P3 按需加载 OpenClaw（skill lazy loading） Manus（不预装知识原则）
P4 渐进降级 OpenClaw（两阶段 pruning） + 我们（分级压缩） Pi-Mono（结构化 compaction）
P5 末尾复述 Manus（todo.md 模式） Lost-in-the-Middle 论文
P6 不信任 LLM OpenClaw（4 种循环检测器） Agent-Zero（intervention 机制）
P7 可中断性 Pi-Mono（steering messages） Agent-Zero（intervention）
P8 不丢信息 我们 v2 架构（旁路事件日志） Agent-Zero（三层记忆区域）
P9 可观测性 OpenClaw（cache trace 7 阶段） 工程常识
P10 文件即记忆 Manus（agent 自管文件记忆） Agent-Zero（knowledge/ 目录）
d.pencil设计
a.概述
a.产品定位与价值
Pencil是一款火爆的设计工具，它不仅是设计工具，更是一个伟大的发明，彻底改变了UI/UX设计的范式。
它具备无限画布、兼容Figma、全程Vibe、Vibe Design和Vibe Coding一体化等特性，审美在线且能将设计直接转化为代码。
b.打破设计与开发的割裂
a.传统模式的痛点
以前的套路是设计师在Figma画图，开发在VS Code写代码，两边完全脱节。设计改动开发不知道，代码变动设计稿不同步，沟通成本高且效率低下。
b.Pencil的核心理念
Pencil的思考是将设计和代码从一开始就放在同一个地方，避免分开操作带来的协同问题。
c.关于使用门槛的辟谣
a.错误观点
有自媒体博主声称使用Pencil必须购买正版Claude Code套餐，且只能使用官方通道。
b.事实真相
这些说法是错误的。使用Pencil不需要购买官方套餐，也不强制使用Claude Code。
VS Code、Cursor、Codex、Windsurf、Cursor、Gemini Cli、Google Antigravity等任何AI编程工具均可使用。
c.技术原理
Pencil基于MCP（Model Context Protocol）原理，而现代AI编程工具全都支持MCP。
d.正确安装Pencil的步骤
a.第一步：避免安装桌面应用
不需要下载Pencil桌面客户端，也不需要知道官网地址。如果同时安装IDE插件和桌面应用，可能会因同时提供MCP服务而产生冲突。
为了在编程环境中实现“设计和写代码一起干”，应直接在IDE中使用。
b.第二步：选择IDE
推荐使用VS Code，当然也支持Cursor、Google Antigravity、Windsurf等主流IDE。
c.第三步：安装VS Code插件
在VS Code插件商店搜索Pencil并安装。安装后左侧会出现铅笔图标。
在插件设置中可以看到，当插件打开时，会自动为所有编程工具安装Pencil MCP。
d.第四步：配置AI编程Agent
在VS Code中推荐使用Claude Code IDE Extension或Codex IDE Extension。
可以将它们放在IDE右侧以便操作。即使使用非官方正版套餐或中转API也可以正常运行。
e.第五步：确认MCP安装
确保Claude Code或Codex已安装Pencil MCP。如有不确定，可以直接询问AI协助安装。
e.Pencil全流程使用演示
a.创建画布
点击左上角New .pen file新建空白画布。
b.开始设计
a.初始化
可以删除画布上的默认矩形元素，保持界面整洁。
b.指令生成设计
通过输入指令，例如在当前活跃画布上重新设计QQ音乐App界面并要求苹果风格、浅色系，AI将自动生成设计。
c.细节调整
生成的界面与Figma完全兼容，每个元素均可点击微调。也可以通过自然语言指令（如增加歌词、修改颜色）进行Vibe模式的调整。
c.生成代码
a.确认技术栈
满意设计后指令AI开始写代码，AI会询问技术栈细节，例如选择Next.js。
b.自动运行
AI生成代码后，可以指令AI直接运行项目，无需手动操作，直接预览效果。
f.与其他工具的兼容
a.使用Codex
Codex的流程与Claude Code一致，但审美效果可能略逊于Claude Code或Gemini模型。演示案例包括设计Switch游戏机运行超级玛丽的效果。
g.Pencil的其他进阶功能
a.导入Figma设计
Pencil支持直接导入Figma的设计文件。
b.内置资源与规范
内置了大量设计规范和示例风格，可直接调用。
c.主题与变量设置
支持整体设置设计主题和变量。
d.图层管理
像Figma一样支持分层查看设计。
e.组件版
可以打开预设组件版，使用预设组件进行快速设计。
e.pi-mono设计
a.pi-mono
a.核心定位
它更像“Agent 工具箱 + coding agent CLI 的一套组合拳”。
b.设计理念
pi-mono 给我的感受是务实：它不是只做一个聊天壳，而是把“做 Agent 需要的零件”拆成包——统一多厂商 LLM API、agent runtime、coding-agent CLI、Slack bot、TUI/Web UI 组件、甚至 vLLM pods 管理。
c.适用场景
我会把它归类为“工程化玩家的乐高盒子”：你想在树莓派/小服务器上跑个能干活的 coding agent，这种项目会比花哨 Demo 更有生命力。
b.VS Code 中用 @UnslothAI + Colab GPU 微调大模型
a.场景描述
本地 IDE + 云端 GPU + 开源训练框架，让个人开发者在不购买任何硬件的前提下，用熟悉的 VS Code 环境完成大模型微调。
b.参考链接
unsloth.ai/docs/get-start…
c.微调门槛的变化
a.传统路径的痛点
一年前微调一个 4B 参数的模型，典型路径是：租云服务器 → 配环境 → 装 CUDA → 处理依赖冲突 → 调参 → 训练。每一步都有可能卡住。
b.现状的简化
现在这条路径被压缩成了：VS Code + 一个扩展 + 一个 Git 仓库。门槛的消除不是渐进的，而是阶梯式的——从“需要 ML 工程经验”直接跳到“会用 VS Code 就行”。
d.Unsloth 的效率优势是真实的工程创新
a.核心竞争力
Unsloth 的核心竞争力不是封装得好，而是从数学层面重新推导了训练过程中的计算密集步骤，并手写了 GPU 内核。
b.带来的结果
单 GPU 训练速度是 Flash Attention 2 的 2-10 倍。
显存占用降低 70-90%。
多 GPU 场景下最高 30 倍加速。
c.算力需求的降低
原本需要 A100 才能跑的任务，可能在免费的 T4 上就能完成。算力需求的降低直接扩大了“谁能做微调”的人群范围。
e.Google Colab 扩展的战略意义
a.产品发布与体验
Google 在 2025年底 官方发布 VS Code Colab 扩展，你不需要打开 Colab 网页，甚至不需要离开编辑器，Google 的 GPU 就在你的 Kernel 列表里。
b.与竞品的对比
AWS SageMaker 需要单独的控制台。
Lambda Labs 需要 SSH 连接。
Colab 网页版受限于浏览器体验。
c.战略价值
VS Code 扩展把 Colab 变成了一个“透明的算力后端”——开发者感知到的只是“我的 notebook 跑得更快了”。
d.参考链接
https://unsloth.ai/docs/get-started/install/vs-code
02.常用信息2
a.agentskills设计
a.前言：大厂的光鲜与小厂的现实
最近看到快手发布了一篇 1.6 万字的长文，讲他们 10000+ 研发团队如何用 3 年时间完成 AI 研发范式升级。
说实话，第一反应是：卧槽，真有钱。第二反应是：这跟我有啥关系？
但仔细读完后，我发现快手踩过的坑，我们也在踩；快手的困惑，我们也有。
唯一的区别是：他们有钱试错，我们只能精准打击。所以这篇文章不是要复述快手的成功经验（那玩意儿复制不了），
而是想聊聊：一个普通团队，如何用最小的成本，借鉴大厂的思路，走出自己的 AI 提效之路。
b.快手的三年之痛：用 AI 工具 ≠ 个人提效 ≠ 组织提效
快手用一年时间把 AI 代码生成率从 1% 提升到 30%+，结果发现：组织的需求交付效率基本不变。
这个结论太扎心了。就像你花了一年时间练出八块腹肌，结果发现还是找不到对象。
快手总结出一个不等式：用 AI 开发工具 ≠ 个人提效 ≠ 组织提效。为什么会这样？
因为：个人提效没传导到组织：工程师编码快了，但需求还是那么多，交付周期没变短。
工具割裂：传统 DevOps 平台和新的 AI 编程工具各玩各的，无法协同。
方法论缺失：大部分人只会"AI 辅助编码"，停留在 Copilot 阶段。这个问题，我们也遇到了。
c.我们的困境：没钱、没人、没时间
我们团队规模不大，但业务线不少：管理端、移动端、大屏端、后端服务。
技术栈也挺杂：Vue2、Spring Boot、MyBatis、PostgreSQL、达梦数据库...
一开始，我们也想学快手，搞个 AI 编程工具推广，结果发现：没钱自研：快手自研了 Kwaipilot，我们只能用 Claude Code、Cursor 这些现成的。
没人推广：快手有效能 BP 专家，我们只有一个兼职的"AI 布道师"（就是我）。
没时间试错：快手可以花一年时间发现"个人提效≠组织提效"，我们必须三个月见效。
但我们有一个优势：小团队，决策快，试错成本低。
所以我们换了个思路：不追求大而全的 AI 研发平台，而是聚焦高频场景，用 Agent Skills 快速解决具体问题。
d.我们的解法：Agent Skills 体系
a.什么是 Agent Skills？
简单说，就是把开发过程中的高频任务，封装成可复用的"技能包"，让 AI 助手（Claude、Cursor 等）能够按照我们的规范和最佳实践来工作。
举个例子：传统方式：开发：Claude，帮我写个 Vue 表格页面。Claude：好的（然后给你写了一堆不符合项目规范的代码）。
开发：不对，我们用的是 Element UI，而且有统一的弹窗规范。Claude：好的（改了半天，还是不对）。
用 Agent Skills：开发：/frontend-admin-assistant 帮我写个用户管理的 CRUD 页面。
Claude：好的（自动读取项目规范、组件库、路由配置，生成符合规范的代码）。开发：完美，直接用。
b.我们的技能体系
我们参考快手的"L1 → L2 → L3"升级路线，但做了简化。
级别（快手的定义）：L1 AI 辅助（人主导，AI 辅助编码）。L2 AI 协同（人机深度协同，AI 完成更多任务）。L3 AI 自主（人做 PM，AI 自主完成需求）。
级别（我们的实践）：L1（用 Copilot，但加上项目规范约束）。L2（用 Agent Skills，AI 按规范生成代码）。L3（暂时不追求，太理想化）。
我们的目标很务实：先把 L1 做扎实，再逐步推进 L2。
-----------------------------------------------------------------------------------------------------
目前我们已经开发了 20+ 个技能，覆盖了开发全流程：
需求阶段（requirements-assistant）：需求分析助手，生成用户故事、验收标准、业务流程图。
前端开发（frontend-dev-assistant）：前端开发统一入口。
管理端开发（frontend-admin-assistant）：管理端开发（Vue2 + Element UI）。
移动端开发（frontend-mobile-assistant）：移动端开发（Vue2 + Vant）。
大屏开发（frontend-dashboard-assistant）：大屏开发（数据可视化）。
前端 API 代码自动生成（frontend-api-assistant）。后端开发（java-dev-assistant）：
Java 开发助手（Spring Boot 3.x + MyBatis）。测试（test-skills）：
从需求文档生成测试用例。UI 自动化测试（ui-automation-expert）：UI 自动化测试（Playwright）。
代码审查辅助工具（code-review）。技能创建生成器（skill-creator）：技能创建生成器（用 AI 生成 AI 技能，很 meta）。
c.一个真实案例：前端 CRUD 页面生成
以前写一个用户管理的 CRUD 页面，
需要：创建 Vue 组件（30 分钟）。写表格、表单、弹窗（1 小时）。对接 API（30 分钟）。调样式、改 bug（1 小时）。总耗时：3 小时。
现在用 frontend-admin-assistant：/frontend-admin-assistant 帮我生成一个用户管理的 CRUD 页面，包括列表、新增、编辑、删除功能。
AI 会自动：读取项目的组件库规范。读取路由配置规范。读取弹窗使用规范。生成符合规范的代码。总耗时：10 分钟（包括微调）。效率提升了 18 倍。
e.我们踩过的坑
a.坑一：技能粒度太细
一开始，我们想学快手，搞得很细：button-generator、form-validator、table-sorter...结果发现：技能太多，开发者记不住，也懒得用。
后来我们调整策略：按场景聚合，而不是按功能拆分。
比如把 button-generator、form-validator、table-sorter 合并成 frontend-admin-assistant，一个技能解决一类问题。
b.坑二：规范文档写得太抽象
一开始，我们的技能文档是这样的：帮助开发者快速生成管理端页面。
结果 AI 根本不知道该怎么做。后来我们学乖了，把规范写得超级具体：技术栈：Vue 2 + Element UI + Less + TypeScript。
核心能力：
1. CRUD 表格页面生成 - 使用 el-table 组件 - 分页使用 el-pagination - 操作列固定在右侧。
2. 弹窗规范 - 必须使用 $modalDialog 方法 - 不允许使用 el-dialog 组件 - 示例代码：[链接]。
3. 路由配置 - 路由文件位置：src/router/modules/ - 必须配置 meta.title 和 meta.icon。教训：AI 不会读心术，你得把规范写得像给实习生看的一样详细。
c.坑三：没有度量，不知道效果
快手有"琅琊阁"效能度量平台，我们没有。但我们也不能瞎搞，所以用了最简单的度量方式：技能使用次数：每周统计各技能的调用次数。
代码生成率：AI 生成的代码占比（手动统计，不精确但够用）。开发者反馈：每月收集一次使用体验。数据不精确，但至少知道哪些技能有用，哪些是摆设。
f.我们的收获：小步快跑，持续迭代
a.量化收获
经过 3 个月的实践，我们的数据：前端 CRUD 页面开发时间：从 3 小时降到 15 分钟（效率提升 12 倍）。
后端 API 开发时间：从 2 小时降到 30 分钟（效率提升 4 倍）。
测试用例生成时间：从 1 天降到 1 小时（效率提升 8 倍）。
代码规范符合率：从 60% 提升到 95%。这些数字比不上快手的 30% AI 代码生成率，但对我们来说已经很满意了。
b.质变收获
更重要的是，我们发现了一些"质变"：新人上手更快：以前新人要 2 周才能写出符合规范的代码，现在 3 天就行。
代码质量更稳定：AI 生成的代码虽然不完美，但至少不会犯低级错误。
团队协作更顺畅：大家都用同一套规范，代码风格统一了。最让我惊喜的是：开发者开始主动贡献技能了。
以前我一个人维护技能库，累得要死。现在大家发现"写技能比写代码爽"，纷纷贡献自己的最佳实践。
c.意外收获：技能即文档
我们发现，Agent Skills 其实是一种"活文档"。
传统的开发文档有两个问题：写的时候很认真，但没人看。过时了也没人更新。
但 Agent Skills 不一样：开发者必须用：因为用技能比手写代码快。
过时了会立刻发现：因为 AI 生成的代码跑不通。所以我们的技能库，反而成了最准确、最及时的开发文档。
g.快手的经验 vs 我们的实践：对比与反思
a.维度：投入。
快手（万人团队）：自研 AI 编程工具（Kwaipilot）。
我们（小团队）：使用现成工具（Claude Code、Cursor）。
b.维度：推广。
快手（万人团队）：效能 BP 专家 + 全员培训。
我们（小团队）：一个兼职"布道师" + 自发传播。
c.维度：度量。
快手（万人团队）：琅琊阁效能平台 + 精细化指标。
我们（小团队）：手动统计 + 简单指标。
d.维度：目标。
快手（万人团队）：组织级提效（L1 → L2 → L3）。
我们（小团队）：场景级提效（聚焦高频场景）。
e.维度：周期。
快手（万人团队）：3 年（试错成本高）。
我们（小团队）：3 个月（快速迭代）。
f.维度：结果。
快手（万人团队）：AI 代码生成率 30%+。
我们（小团队）：特定场景效率提升 10+ 倍。
g.我们的启示
不要盲目追求大而全：快手的 L3（AI 自主）很美好，但我们连 L1 都没做好，先把基础打牢。
聚焦高频场景：不要试图覆盖所有场景，先解决 80% 的问题。
用现成工具：自研成本太高，Claude Code、Cursor 已经够用。小步快跑：3 个月见效，比 3 年规划更实际。
h.给小团队的建议：如何开始你的 AI 提效之路
a.第一步：找到你的"痛点场景"
不要一上来就想"全面 AI 化"，先问自己：哪些工作最重复、最无聊？（比如 CRUD 页面）。
哪些规范最容易被违反？（比如代码风格）。哪些文档最容易过时？（比如 API 文档）。从这些场景入手，做一个技能，立刻见效。
b.第二步：写一个"最小可用技能"
name: my-first-skill
description: 帮我生成一个标准的 Vue 组件
---
# 我的第一个技能
## 技术栈
Vue 2 + Element UI
## 核心能力
生成一个包含 template、script、style 的标准组件
## 示例代码
[粘贴一个你们项目的标准组件]
## 注意事项
- 必须使用 TypeScript
- 样式必须使用 scoped
c.第三步：让团队用起来
技能写好了，怎么推广？找一个"种子用户"：通常是团队里最愿意尝试新东西的人。
解决一个真实问题：让他用技能完成一个实际任务。
展示效果：在团队会议上演示"10 分钟完成 3 小时的工作"。
自然传播：其他人看到效果，自然会来问。不要强推，效果会说话。
d.第四步：持续迭代
技能不是一次性的，要根据反馈持续优化：每周收集反馈：哪里不好用？哪里可以改进？
每月更新一次：修复 bug，增加新功能。每季度复盘一次：哪些技能有用？
哪些该淘汰？我们的 frontend-admin-assistant 已经迭代了 8 个版本，越来越好用。
i.未来展望：从 L1 到 L2 的进化
a.路线
快手提出的"L1 → L2 → L3"升级路线，我们目前在 L1.5 的位置：
L1 AI 辅助（✅ 已完成，AI 按规范生成代码）。
L2 AI 协同（🚧 正在探索，让 AI 理解业务逻辑）。
L3 AI 自主（❌ 暂不考虑，太理想化）。
b.场景一：需求到代码的自动化
现状（L1）：产品给需求文档。开发手动拆解任务。用技能生成代码。
目标（L2）：产品给需求文档。AI 自动拆解任务 + 生成代码。开发只需审核。我们已经有了 requirements-assistant（需求分析）和各种开发技能，现在要做的是把它们串起来。
c.场景二：代码审查的智能化
现状（L1）：AI 检查代码规范。人工审查业务逻辑。
目标（L2）：AI 理解业务逻辑。AI 发现潜在 bug。AI 提出优化建议。这需要 AI 能读懂项目的业务代码，我们正在尝试用 RAG（检索增强生成）技术来实现。
j.写在最后：AI 是放大器，不是魔法棒
快手在文章最后说：AI 是"透视镜"与"放大器"。这句话太对的。
AI 不会自动解决你的组织问题，它只会把你的问题放大：如果你的规范混乱，AI 会生成更混乱的代码。
如果你的流程低效，AI 只会让低效流程跑得更快。如果你的团队不协作，AI 也帮不了你。
所以，AI 提效的前提是：你得先把基础打好。快手花了 2 年时间做"平台化、数字化、精益化"，才开始做"智能化"。
我们虽然没有快手的资源，但也要先把规范、流程、协作做好，再谈 AI。
我们的三个心得：不要追求完美，先追求可用。快手的 AI 代码生成率 30%+ 很牛，但我们 10% 也够用。
重要的是解决实际问题，而不是追求数字。不要盲目模仿大厂，要找到自己的路。
快手有钱自研，我们用现成工具。快手追求组织提效，我们先做场景提效。条条大路通罗马，适合自己的才是最好的。
不要等待完美时机，现在就开始。不需要等规范完善。不需要等工具成熟。不需要等团队准备好。写一个技能，解决一个问题，就是开始。
k.结语：2026，AI 时代的分水岭
快手的文章最后说：2026 年将成为一批先行者集中展示阶段性成果的窗口期。
我深以为然。但我想补充一句：2026 年也将是小团队弯道超车的机会。
为什么？因为：AI 工具已经成熟：Claude、Cursor、GitHub Copilot 都很好用，不需要自研。
方法论已经清晰：快手、Google、微软都在分享经验，不需要从零摸索。
成本已经降低：以前要百万级投入，现在几千块就能开始。大厂有资源优势，但小团队有灵活优势。
我们可以：更快决策：不需要层层审批。更快试错：失败了也不会影响 KPI。更快迭代：3 个月一个版本，而不是 3 年一个规划。
所以，不要羡慕快手的万人团队，也不要妄自菲薄。AI 时代，拼的不是资源，而是认知和行动力。
b.antigravity设计
a.说明
Antigravity的设计就是这样，从规划 → 实施 → 验证分步执行。
先创建 http://plan.md 文件来记录提出的更改直到用户批准，创建http://task.md作为一份详细的清单，用于分解并记录。
最后创建http://walkthrough.md作为总结和记录验证结果
b.特点
这几天一直在用 Google Antigravity，Antigravity最具特色的是这个 Agent Manager 功能，在我看来，这个模式才是 IDE 未来发展的方向。
这个模式是对标 cursor 的 Agent 模式，它比 cursor 更激进，功能更强大，在这个模式下，可以完全脱离代码编辑功能，真正进入vibe coding。
点击编辑器右上角“Open Agent Manager”进入这个模式，或者使用快捷键 ⌘/ctrl + E 打开，打开后，你甚至可以把其他代码编辑窗口全部关闭。
c.应用
01.Workspaces：可以打开多个工作区，同时开发多个项目，在等待 AI 写代码的时候你可以切换到另一个项目继续，工作效率拉满。
02.Playground：提供即时实验环境，这是个纯聊天功能，作为临时会话探索想法和提问。
03.Inbox：集中查看所有会话的地方，可以看到哪些会话正在等待用户批准执行命令。
04.Conversation View：会话中实时显示 Agent 的执行过程，可以通过 Following 模式跟随或暂停跟随 Agent 的每一步动作。
05.Browser Subagent View：展开侧边栏以查看浏览器代理的点击、滚动等操作，并附带实时截图与交互位置标记。
06.Panes：在聊天会话中作为独立小窗口打开文件、Artifacts 或知识条目。
07.Review Changes + Source Control：这个窗口可以查看 AI 写的代码与用户的代码差异，切换到Source Control可暂存、更改或提交文件。
08.Changes Sidebar：快速查看 Agnet 生成的 Artifacts 和修改过的文件。
09.Terminal：想敲命令的时候可以打开这个本地终端窗口，缺点是字体和 IDE 不共用， Nerd Font 在这里不生效。
10.Files：在文件窗口可以给文件里特定的地方添加评论，以便向 Agent 指出需要关注的具体代码。
d.技术选型
同样的(粗颗粒度)提示词下，能力测试 Build ＞ Canvas ＞ Gemini 3 Pro纯对话
-----------------------------------------------------------------------------------------------------
1.Gemini3 PRO
从 http://gemini.google.com 或者 http://aistudio.google.com 都可以，推荐使用AIStudio，因为能无限制使用Gemini 3 PRO
Gemini3 PRO 通过提示词制作的前端为纯 HTML 的形式，这一过程没有任何的人机交互。
生成的HTML代码只有复制到文件中打开才能看到前端页面。假如对制作的HTML代码不满意，需要重新返回通过提示词修改。
经过几轮测试，Gemini3 PRO 通过一句话形式制作的前端是最美观的
-----------------------------------------------------------------------------------------------------
2.Gemini Canvas
只能在 http://gemini.google.com 中使用。
点击“+”号开启Canvas模式后，会进入如图3的左侧 Prompt 对话区域，右侧代码及前端预览的界面。
Canvas默认编写的代码为 HTML 样式，假如对前端满意之后，需要使用提示词 “ 使用 React + Vite 重构 ”，这样会最后给出完整可用的前端。
但是美观性不足，可能需要比较多的调节
-----------------------------------------------------------------------------------------------------
3.AIStudio Build
直接在AIStuidio左侧选择进入即可。
这是最令我惊艳的模式，Build模式下直接给出了黑色高端风格的前端。
并且左侧的对话区域能够直接进行元素调节，不同于上面两者制作的 HTML ，直接是 React + Vite 的前端项目。
一共四张落地页，页面之间的切换非常丝滑，并且组件的位置比较恰当，配色也偏高端，几乎没有目前大量同质化的“AI味”
e.用户反馈
对Antigravity的体验一言难尽，感觉这个反重力还不如叫它反人类。
核心问题是它老是不等我说好就直接开干，反复跟它讲我们先制定一个计划，不要编码。
它确实也是在做计划，但是每次做完计划直接开干。
它也不管这个计划，你认不认，实际上它做的计划经常问题是很大的。
c.agent的6个文件
a.6个文件，1个能用的AI Agent——TinyAgent架构拆解
读完这篇文章你将学到：
为什么90%的Agent框架都太重了；
一个AI Agent最少需要哪几个零件；
流式Tool Calling的实现原理；
如何用Markdown文件当技能插件系统；
对话记忆的截断为什么没你想的那么简单。
b.一个反直觉的事实
大多数人第一次搭AI Agent会先去翻LangChain的文档，然后就迷失了。
你还没写第一行业务代码，requirements.txt里已经躺了40个依赖。
但一个能对话、能调工具、能记住你说过什么的Agent，最少只需要6个Python文件，总共不到700行代码。
TinyAgent不是一个框架，而是一个可以直接运行的最小Agent实现。
c.为什么要关心这件事
如果你只是想用Agent，可以直接用LangChain。
但如果你想理解Agent是怎么工作的，重量级框架反而是最大的障碍，因为它们把核心逻辑埋在了十几层抽象下面。
TinyAgent的价值在于：读完这6个文件，你会真正明白一个Agent内部在发生什么。这种理解在你未来调试任何Agent框架的时候都会救你的命。
d.先看全貌：6个文件各管什么
TinyAgent的核心就5个模块加1个入口。
TinyAgent负责组装所有零件；
MemoryStore负责短期对话历史加长期MEMORY.md；
SkillsLoader负责扫描skills目录并解析Markdown技能；
ToolRegistry负责注册执行4个内置工具；
ContextBuilder负责拼接系统提示词、历史和技能；
AgentLoop负责流式对话加多轮工具调用循环。
所谓Agent，其实就像一个有工具箱的接线员。
e.总指挥：TinyAgent怎么把零件拼起来
TinyAgent的职责很纯粹：初始化所有模块，然后把用户消息丢进事件循环。
核心方法只有chat_stream。
三步走：拼上下文、跑循环、存记忆。
TinyAgent是个组装车间，它自己不干活，只负责让四个组件协同工作。
f.心脏：AgentLoop事件循环
a.朴素写法的问题
如果你自己实现一个简单的Tool Calling循环，朴素写法有三个问题：
不是流式的，用户体验差；
只处理了一轮工具调用，无法处理复杂任务；
没有防护，模型反复调用工具会进入死循环。
b.TinyAgent的做法
TinyAgent实现了流式解析Tool Call，使用while循环而非单次调用，并设置了max_iterations保险丝。
OpenAI流式返回的工具调用参数是分块到达的，所以需要用buffer把碎片拼完整。
c.设计总结
AgentLoop等于流式对话加多轮工具调用加防死循环保险丝。
g.工具系统：4个内置工具就够用了
TinyAgent只注册了read_file、write_file、edit_file、exec四个工具。
有了文件读写和Shell执行，模型理论上可以做任何事。
工具注册只需继承BaseTool，实现execute，调用registry.register。Shell工具内置了一套高危命令拦截，拦住了常见的灾难场景。
4个基础工具加Shell安全拦截等于最小可用工具集。
h.记忆系统：截断没你想的那么简单
假设历史里有30条消息，你只取最后20条。
如果第11条消息是assistant消息带着tool_calls，而第12条是对应的tool结果，你截到第12条，OpenAI API会直接报错，
因为出现了孤儿tool消息。TinyAgent的解决方案很聪明：往前找，直到找到一条user消息作为安全切入点。
记忆截断必须对齐到user消息边界，否则工具调用链会断裂。
i.技能系统：Markdown即插件
TinyAgent最有创意的设计是：往workspace/skills目录下扔一个SKILL.md文件，就算装好了一个技能。
它支持渐进式加载：
always_load为true的技能全文直接塞进系统提示词；
always_load为false的技能只把名字和描述放进提示词，模型需要时自己用read_file去读完整内容。这解决了上下文窗口有限的问题。
j.上下文组装：一碗好汤怎么炖
ContextBuilder负责把所有信息拼成一条完整的系统提示词。
顺序很重要：身份设定加时间加环境信息；常驻技能；长期记忆；可选技能索引。
这个顺序的设计暗含了一个原则：越重要的信息越靠前。
大模型对system prompt开头的内容关注度最高。
k.前端：SSE让对话活起来
app.py用FastAPI暴露了一个/api/chat接口，返回格式是SSE。
和WebSocket相比，SSE的优势是简单。单向推送足够了，不需要维护长连接状态。
前端通过EventSource或fetch接收这些事件，实现逐字显示、工具调用状态展示、token用量统计等实时反馈。
l.全景回顾：一次完整的对话发生了什么
把所有模块串起来，一次用户提问的完整流程是：
用户提问；
拼装上下文；
流式调用LLM；
LLM要求调用工具；
执行工具并获取结果；
将结果发给LLM；
LLM最终回复。
二轮模型调用，一次工具执行，全程流式。
m.写在最后
TinyAgent不是要取代任何框架。
它的意义在于：把Agent的骨架亮给你看。
真正重要的东西，往往简单到让人不敢相信。
一个能用的Agent，核心代码不过几百行。
如果你正在学习AI Agent，我的建议是：先读一遍TinyAgent的源码，再去碰那些重量级框架。
d.agent的操作本质
a.AI Agent从入门到精通核心主旨
AI Agent的本质并非复杂的高级AI，而是"会调用工具的循环"，learn-claude-code项目通过12节课层层拆解，从零构建Agent，
核心代码不足50行；核心理念为"模型就是智能体。我们的工作就是给它工具，然后让开。"
b.Agent的本质认知
多数人对Agent的认知停留在"独立思考的高级AI"，但该项目颠覆此认知：Agent核心是简单的工具调用循环，
12节课通过逐节添加机制的方式，从基础循环逐步构建完整智能体体系。
c.核心模式：一个循环搞定所有Agent逻辑
a.核心代码
---
def agent_loop(messages):
while True:
response = client.messages.create(
model=MODEL, system=SYSTEM,
messages=messages, tools=TOOLS,
)
messages.append({"role": "assistant", "content": response.content})
if response.stop_reason != "tool_use":
return
results = []
for block in response.content:
if block.type == "tool_use":
output = TOOL_HANDLERS[block.name](**block.input)
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": output,
})
messages.append({"role": "user", "content": results})
---
b.核心逻辑
1.将消息发送给LLM；2.若LLM触发"tool_use"，执行对应工具并将结果回填至消息列表；
3.若未触发工具使用，返回结果并结束循环；所有复杂Agent机制均基于此基础循环扩展。
d.第一阶段：循环与工具（s01-s02）
a.s01：一个循环就够了
核心格言："One loop & Bash is all you need"（一个工具 + 一个循环 = 一个智能体）；
此时Agent仅能完成"接收命令→调用Bash执行→返回结果"的基础流程，是所有Agent的核心DNA。
b.s02：加一个工具，只加一个handler
扩展逻辑：新增工具仅需编写对应的handler并注册至dispatch map，无需修改主循环；
如同手机装App，内核不变即可扩展能力；此时Agent的短板是无计划能力，执行任务易混乱。
e.第二阶段：规划与知识（s03-s06）
a.s03：没有计划的agent走哪算哪
核心机制：TodoWrite（任务规划）；
通过system prompt告知Agent"先调用TodoWrite列计划"，而非依赖LLM自主思考，添加计划后任务完成率翻倍。
b.s04：大任务拆小，每个小任务干净的上下文
核心机制：子智能体（Subagents）；
将大任务拆分给独立子Agent处理，每个子Agent拥有独立messages[]，避免上下文污染，主Agent仅负责任务分配（类似项目经理）。
c.s05：用到什么知识，临时加载什么知识
核心机制：Skills；
摒弃"将所有知识塞进system prompt"的方式，仅在需要时读取SKILL.md文件并通过tool_result注入，降低token消耗与调用成本。
d.s06：上下文总会满，要有办法腾地方
核心机制：Context Compact（三层压缩策略）；
1.热数据：保留最新N轮对话；2.温数据：将早期对话压缩为摘要；3.冷数据：完整历史存磁盘，需用时加载；借鉴操作系统内存管理思路。
f.第三阶段：持久化（s07-s08）
a.s07：大目标要拆成小任务，排好序，记在磁盘上
核心机制：任务持久化；将TodoWrite的内存任务存储至磁盘文件，
支持任务依赖关系（如A→B→C），形成任务图（Task Graph），可自动判断任务并行/串行逻辑，为多Agent协作奠基。
b.s08：慢操作丢后台，Agent继续想下一步
核心机制：后台任务；启动守护线程处理耗时操作（如10分钟的测试），
Agent可继续处理其他任务，操作完成后通过通知机制回填结果；提升Agent执行效率。
g.第四阶段：团队（s09-s12）
a.s09：任务太大一个人干不完，要能分给队友
核心机制：Agent团队；每个队友（子Agent）持久化存在，拥有独立"邮箱"（JSONL文件），
主Agent向邮箱发消息触发队友执行任务；队友可拥有独立记忆、状态、性格。
b.s10：队友之间要有统一的沟通规矩
核心机制：统一协议 + 状态机（FSM）；定义标准化request-response沟通模式，
队友收到请求后可"接受/拒绝/协商"，每种状态有明确流转规则，提升团队协作效率。
c.s11：队友自己看看板，有活就认领
核心机制：自治智能体；队友从"被动执行"转为"主动工作"，定期轮询任务板，自动认领适配任务（类似团队成员认领Jira任务）。
d.s12：各干各的目录，互不干扰
核心机制：Worktree隔离；每个任务绑定独立工作目录，代码、文件、环境完全隔离，
避免多Agent协作时的git冲突、文件覆盖等问题，是团队协作的最后一块拼图。
h.学完落地：从理解到实践
a.Kode Agent CLI
安装命令：npm i -g @shareai-lab/kode；开箱即用的Coding Agent CLI，
支持Skill和LSP，可对接GLM、MiniMax、DeepSeek等开放模型。
b.Kode Agent SDK
嵌入式SDK，可将Agent能力集成至自有应用；无per-user进程开销，适配高并发场景，区别于官方Claude Code SDK。
i.进阶探索：从"用完即走"到"始终在线"
a.姊妹项目claw0
learn-claude-code的Agent为"用完即走型"（终端启动→完成任务→关闭），claw0则是"主动式常驻AI助手"。
b.关键扩展机制
1.心跳（Heartbeat）：每30秒检查是否有任务需处理，无任务休眠，有任务立即执行；
2.定时任务（Cron）：Agent可自主安排未来任务，到点自动执行；
3.多通道路由：支持WhatsApp/Telegram等13+平台；
4.持久化记忆+人格系统，即爆火的OpenClaw（小龙虾）。
j.Agent的本质总结
Agent不是"更聪明的AI"，而是"更好的工具使用者"；LLM仅为语言模型，
通过添加工具、计划、记忆、团队协作等机制，从"会说话的百科全书"转变为"能干事的队友"；核心在于机制设计，而非模型本身。
k.上手实操建议
a.克隆项目：git clone https://github.com/shareAI-lab/learn-claude-code
b.学习建议
1.从s01开始逐节学习，不跳跃，理解每节新增的单一机制；
2.运行每个独立Agent，直观感受输出效果；
3.体验web平台：cd web && npm install && npm run dev；
4.可按需提取单节机制，组合构建自定义Agent。
e.agent的文件系统：双下文
a.核心观点：一切皆上下文
Andrej Karpathy 曾将 LLM 比作 CPU，上下文窗口比作 RAM。既然上下文是 RAM，谁来管理它？
目前的上下文管理（Prompt Engineering 或 RAG）往往碎片化、不可追溯。
arXiv 上的论文 "Everything is Context" 借鉴 Unix "一切皆文件" 的哲学，提出用文件系统抽象统一管理 AI Agent 的所有上下文。
b.上下文工程与 Unix 哲学
a.什么是上下文工程
上下文工程是管理 "AI 在思考时能看到的所有信息" 的工程，包括历史对话、外部知识、工具定义等。
如果说 Prompt Engineering 是点菜，Context Engineering 就是备菜，管理冰箱里的食材和厨房的盘子。
b.Unix 哲学的启示
Unix 将所有硬件抽象为文件，统一暴露 read/write 接口。AI Agent 的上下文也需要这样的统一接口，
因为上下文资源格式各异（JSON、向量库、API），如果没有统一抽象，接入新资源需要大量胶水代码。
c.统一文件系统抽象
所有上下文资源被挂载到一个虚拟目录树上（如 /context/history/）。
不管底层是数据库还是 API，对 Agent 来说都是 afs_read 这样的标准操作。这把上下文从 "临时变量" 升级成了 "持久资源"。
c.三层持久化上下文仓库
a.History：不可变的真相之源
所有原始交互（用户输入、模型输出、工具调用）全部追加写入 History，不可修改。
这类似于数据库的 WAL（Write-Ahead Log），是 Agent 的事务日志，支持回放和审计。
b.Memory：结构化的工作知识库
Memory 是从 History 提炼的结构化知识，被摘要和索引过。论文从三个维度分类：
维度 说明 举例
时间维度 保持多久 短期（会话内）vs 长期（跨会话）
粒度维度 存多大块 Token 级 / 事实级 / 摘要级
表示维度 用什么格式 原始文本 / 向量嵌入 / 知识图谱三元组
c.Scratchpad：推理草稿纸
用于存储推理过程中的中间结果。任务结束后，有价值的转存到 Memory，其余清除。
这类似于计算机存储的层次结构（寄存器 -> 缓存 -> 内存）。
d.上下文工程管道
a.Context Constructor：选什么
构建器负责选择、排序、压缩相关上下文。核心矛盾是完整性 vs 有界性（Token 窗口限制）。
它必须生成一份上下文清单，记录选了什么、排除了什么、为什么，这使得过程可追溯。
b.Context Updater：怎么塞
论文提出三种更新模式：
模式 适用场景 说明
静态快照 单轮任务 一次性灌入，不再更新
增量流式 多步推理 边推理边加载新片段
自适应刷新 长对话 替换过时信息，响应环境变化
c.Context Evaluator：塞完验
评估器负责验证输出（检测幻觉、矛盾）、写回记忆以及触发人类审核。
e.三个设计约束
a.Token 窗口是硬上限
上下文工程的本质是 "装箱问题"，在有限容量下选择价值最高的信息。
b.模型天生无状态
必须有外部持久化机制维护状态连续性，同时需解决记忆膨胀问题（去重和合并）。
c.输出是概率性的
同样的 Prompt 结果可能不同，必须完整保存元数据（输入、输出、模型参数、时间）以便审计。
f.AIGNE 框架实现
a.核心功能 AFS
AIGNE 框架实现了 AFS（Agentic File System），提供 list、read、write、search、exec 等接口。
b.实战案例 1：带记忆的 Agent
a.功能说明
通过挂载 AFSHistory 和 UserProfileMemory，Agent 可以通过 AFS 访问所有上下文。
b.代码示例
---
const afs = new AFS()
.mount(new AFSHistory({ storage: sharedStorage }))
.mount(new UserProfileMemory({ storage: sharedStorage }));
const agent = AIAgent.from({
instructions: "You are a friendly chatbot",
afs,
});
---
c.实战案例 2：MCP + GitHub
a.功能说明
将 GitHub MCP 挂载为文件系统的一部分，Agent 可以像读文件一样使用 GitHub API。
b.代码示例
---
const mcpAgent = await MCPAgent.from({
command: "docker",
args: ["run", "-i", "--rm", "ghcr.io/github/github-mcp"],
});
const afs = new AFS().mount(mcpAgent);
// afs_exec("/modules/github-mcp/search_repositories", {...})
---
g.笔者的思考与局限
a.架构哲学价值
这是一篇架构哲学论文，虽然没刷 SOTA，但给上下文工程提供了统一的架构语言。
b.工程重心转移
Context Engineering 比 Prompt Engineering 重要 10 倍。数据决定了结果的上限，精心组织的上下文优于调优的 Prompt 加杂乱上下文。
c.人在环中
当模型不确定时主动请人审核，人的标注作为一等公民存在，这种设计在生产环境中非常成熟。
d.当前局限性
论文目前缺乏定量评估，性能开销未详细讨论，多 Agent 协作细节不足，且缺少大规模工业场景验证。
h.结语
好的架构是找到正确的抽象。Unix 的 "一切皆文件" 影响了半个世纪，
"Everything is Context" 提出了类似的愿景：把 AI Agent 的所有上下文统一为可挂载、可追溯、可治理的文件系统资源。
操作系统前辈五十年前的设计智慧，在 AI 时代依然闪闪发光。
03.常用信息3
a.DESIGN.md开放标准发布
a.说明
由 Google Labs Code 发布，定位为机器+人类双可读设计规范标准，呼吁 Codex、Claude Code、Cursor 等 AI 工具原生支持。
开源地址：https://github.com/google-labs-code/design.md
b.YAML Front Matter（机器层）
顶部用 --- 包裹的 YAML 定义精确的设计 token，包括：
colors：语义化命名 + 十六进制值（如 primary: "# 1A1C1E"）
typography：字体家族、字号、字重、行高、字距等
rounded / spacing：圆角与间距的阶梯尺度
components：组件级 token，支持引用（如 backgroundColor: "{colors.tertiary}"）
c.Markdown Body（人类层）
正文用自然语言描述设计哲学与使用语境，规范要求按固定顺序组织为 8 个章节：
1.Overview（品牌与风格总览）
2.Colors（色彩角色与情感）
3.Typography（排版气质）
4.Layout（布局与留白策略）
5.Elevation & Depth（层级与阴影）
6.Shapes（形状语言）
7.Components（组件规范）
8.Do's and Don'ts（设计禁区）
关键设计：token 是规范性数值，prose 解释"为什么"以及"如何应用"。
两者结合，使 LLM 既能获取精确值，又能理解设计意图，减少"猜错品牌色"的问题
d.CLI 工具链：验证、对比与导出
开源仓库提供了 @ google/design.md 命令行工具，核心能力包括 ：
lint：结构校验 + WCAG 对比度检测 + token 引用完整性检查
diff：对比两个版本的 DESIGN.md，识别 token 与 prose 的回归
export：导出为 Tailwind 主题配置或 W3C DTCG 标准 tokens.json
spec：输出规范原文，便于注入 agent prompt 作为上下文
b.上下文管理：Agent 的“记忆”难题
a.上下文管理Agent的记忆难题
前面四篇，我们搞清楚了 Agent 的完整工作原理：LLM 负责思考，Tool Use 负责执行，Agent Loop 把它们串成循环，System Prompt 定义行为规则。
但如果你真的跑过一个 Agent，你一定会遇到一个非常现实的问题：跑着跑着，它就“失忆”了，或者直接报错说 token 超限了。
这就是今天要聊的主题，上下文管理。
b.先搞清楚一个概念上下文窗口
LLM 不是一个有记忆的东西。前面第三篇我们说过，它是无状态的，每次调用都要把完整的消息历史发给它，它才能知道之前发生了什么。
而这个“完整的消息历史”，不能无限长。每个 LLM 都有一个上下文窗口，就是它一次能处理的信息总量上限，单位是 token。
现在主流模型的上下文窗口大概是这样的：
Claude：1M token
GPT-5：1M token
听起来挺大的？别急，我们算算 Agent 跑起来会消耗多少。
c.上下文是怎么被吃掉的
一个 Agent 每跑一轮循环，消息历史里就会多出这些东西：
LLM 的回复（包含思考过程和 tool_use）
工具执行的结果（tool_result）
关键是工具返回的结果往往很大。你让 Agent 读一个文件，tool_result 就是整个文件的内容，随便一个代码文件就可能几百行。你让它执行一个命令，输出也可能是一大片日志。
我们来算一笔账。假设 Agent 处理一个中等复杂度的任务，跑了 20 轮循环：
System Prompt 约 3000 token
用户消息 约 200 token
20 轮 LLM 回复 约 10000 token
20 轮工具结果 约 40000 token
总计 约 53000 token
这还只是一个中等任务。如果是复杂任务，跑个五六十轮，再读几个大文件，轻轻松松就奔着几十万 token 去了。
而且别忘了，上下文窗口是输入和输出共享的。你输入占了 180K，留给 LLM 生成回复的空间就只剩 20K 了。
这就是上下文管理的核心矛盾：Agent 跑的轮次越多，积累的信息越多，但能装信息的容器就那么大。
d.为什么不能简单地丢掉旧消息
你可能会想：既然装不下了，把早期的消息删掉不就行了？
没那么简单。
假设 Agent 在第 3 轮读了一个配置文件，到第 25 轮的时候需要根据这个配置来修改代码。如果你把第 3 轮的内容删了，LLM 就不知道配置文件里写了什么，它要么瞎猜，要么重新去读一遍（浪费一轮循环）。
消息历史是 Agent 的“工作记忆”。随便删东西，就像一个人突然忘掉了之前的调查结果，轻则重复劳动，重则做出错误判断。
所以上下文管理的难点在于：怎么在有限的空间里，保留最重要的信息，丢掉不重要的。
e.常见的管理策略
a.对话摘要压缩
这是最常用的策略。当消息历史快要超限的时候，把早期的对话内容“压缩”成一段摘要。
比如前 10 轮的完整对话可能有 30000 token，压缩成一段摘要可能只需要 2000 token：
“用户让我修复 login 接口的 bug。我读了 src/auth/login.ts 和 src/utils/token.ts，发现 token 生成逻辑有问题，已经修复并更新了测试。”
这段摘要保留了关键信息（做了什么、改了哪些文件、结论是什么），但体积只有原来的十分之一不到。
谁来做这个压缩？还是 LLM 自己。你把早期的对话内容发给 LLM，让它生成一段摘要，然后用这段摘要替换掉原来的详细内容。
Claude Code 就用了这种方式，它叫 auto-compact。当上下文快满的时候，自动触发一次压缩，把早期对话浓缩成摘要，腾出空间给后续的工作。
b.工具结果截断
工具返回的结果往往是上下文膨胀的最大元凶。一个文件内容可能有几千行，但 LLM 真正需要的可能只是其中几十行。
所以可以在返回 tool_result 的时候就做限制：
文件太长？只返回前 N 行，或者只返回与当前任务相关的部分
命令输出太多？截断，只保留最后 N 行（通常错误信息在末尾）
搜索结果太多？只返回 Top N 条最相关的
这种策略的好处是从源头控制输入量，坏处是可能丢掉了 LLM 需要的信息。所以截断要有策略，不能一刀切。
c.滑动窗口
最简单粗暴的方式：只保留最近 N 轮的消息，更早的直接丢掉。
这种方式实现简单，但效果一般。因为 Agent 的工作往往是有连贯性的，第 5 轮做的事情可能在第 30 轮还有用。单纯按时间丢弃，很容易丢掉关键信息。
所以在实际产品中，滑动窗口通常不会单独使用，而是和摘要压缩配合：超出窗口的部分不是直接删掉，而是先压缩成摘要再保留。
d.按需重新获取
既然旧的工具结果可以丢掉，那 LLM 需要的时候再重新获取不就行了？
比如第 3 轮读过的配置文件，到第 25 轮如果还需要，LLM 可以再调一次 read_file 重新读。反正工具还在，随时都能用。
这种方式的代价是多消耗一轮循环和一次工具调用，但好处是信息始终是最新的（文件可能在中间被修改过），而且不需要一直把内容留在上下文里占空间。
f.上下文管理的核心权衡
你会发现，所有策略都在做一个权衡：信息完整性 vs 空间效率。
保留的信息越完整，LLM 做决策的质量越高，但空间消耗也越大。压缩得越狠，空间越充裕，但 LLM 可能因为缺少关键信息而犯错。
没有完美的方案，只有适合当前场景的方案。好的 Agent 产品会组合使用多种策略，并且根据实际情况动态调整。
比如 Claude Code 的做法大致是这样的：
默认保留完整的消息历史
当上下文接近上限时，自动触发 compact（摘要压缩）
压缩时保留最近几轮的完整内容，更早的部分生成摘要
用户也可以手动触发压缩
这种方式在大多数场景下都能工作得不错。
g.为什么上下文管理是能跑到能用的关键
一个不做上下文管理的 Agent，跑个三五轮没问题，但稍微复杂一点的任务（需要十几轮甚至几十轮）就会撞墙。要么 token 超限直接报错，要么上下文太长导致 LLM 注意力分散，开始忽略早期的重要信息。
这也是为什么很多人自己写的 demo Agent 看起来能跑，但真正用起来很快就不行了。差别不在 Agent Loop 的实现上，而在这些“看不见的细节”上。
上下文管理就是这样一个看不见但极其重要的模块。它不决定 Agent 能不能工作，但决定了 Agent 能不能持续、稳定、可靠地工作。
h.一句话总结
上下文管理就是在有限的空间里，保留最重要的信息，让 Agent 能持续工作。核心策略是摘要压缩、结果截断、滑动窗口和按需重新获取，本质上都是在信息完整性和空间效率之间做权衡。
到这里，AI Agent 的五个核心概念我们就全部聊完了：LLM、Tool Use、Agent Loop、System Prompt、上下文管理。这五个东西组合在一起，就是 Cursor、Claude Code 这些 AI 编程助手背后的完整原理。
理解了这些，你就真正搞懂了 Agent 是怎么工作的。
c.Cursor的自我颠覆
a.说明
Cursor 说核心产品「不再重要」，然后放大招。阅读本文大概需要 5 分钟。
Cursor 工程负责人最近说了一句很奇怪的话："我们的职业已经完全改变了。
让 Cursor 走到今天的产品，在未来不再那么重要了。
"一家估值 500 亿美元的公司，亲口说自己的核心产品"不再重要"——这不是谦虚，也不是危机公关，
这是一种主动的自我颠覆。就在这句话说出来后不久，Cursor 发布了 Cursor 3。
b.Cursor 3 带来了什么
a.代号 Glass
这是 Cursor 有史以来最大的一次架构重写。
最关键的一个变化：Cursor 3 完全脱离了 VS Code fork。
过去三年，Cursor 一直是在 VS Code 基础上修改的，这让它继承了 VS Code 的生态，也继承了它的天花板。
Glass 是一个全新的界面，Cursor 终于有了自己的地基。
b.具体功能
a.功能概览
具体功能层面，有几个值得关注：
b.Agent 工作区
这是 Cursor 3 的核心。你可以同时运行多个 Agent，每个 Agent 处理不同的任务——
一个在修 Bug，一个在写测试，一个在重构模块。开发者从"写代码的人"变成"调度 Agent 的人"。
c.云 Agent + 本地 Agent 双模式
云端 Agent 可以在后台异步运行，你去开会，回来任务已经完成。本地 Agent 则保留了实时交互的体验。两种模式可以混用。
d.多仓库支持
一个 Agent 可以同时理解和修改多个代码仓库。对于微服务架构的团队来说，这个功能的价值不言而喻。
e.Design Mode
从自然语言描述直接生成 UI 原型，前端开发者的工作流会因此改变。
f.多 LLM 选择
Claude、GPT-4o、Gemini、Cursor 自研模型，可以按任务类型自由切换。不再绑定单一模型。
c.设计哲学
功能清单不是重点。重点是这些功能背后的设计哲学：Cursor 不再把自己定义为"更好的编辑器"，而是"Agent 的调度中心"。
c.软件开发的第三时代
a.时代背景
回头看，AI 介入软件开发经历了三个阶段。
b.第一时代：AI 补全（2021-2023）
GitHub Copilot 开创了这个模式。人写代码，AI 在旁边猜你下一行想写什么。
开发者的工作流没有本质变化，只是多了一个聪明的自动补全。
c.第二时代：人机协作（2023-2025）
Cursor Composer 是这个时代的代表。你描述需求，AI 生成一段代码，
你审查、修改、再迭代。人和 AI 像结对编程一样工作。Cursor 凭借这个模式拿下了 67% 的财富 500 强，每天产出 1.5 亿行企业级代码。
d.第三时代：Agent 自主执行（2025-至今）
这是现在正在发生的事。Claude Code、OpenAI Codex、Cursor 3——它们的共同假设是：
AI 可以自主完成"理解需求 → 规划方案 → 修改代码 → 运行测试 → 提交结果"的完整循环。开发者的角色从"写代码"变成"审查 Agent 的输出"。
e.核心观点
Cursor 工程负责人那句话的意思现在清晰了：让 Cursor 成功的是第二时代的产品，
而第三时代需要完全不同的东西。Cursor 3 是他们对第三时代的回答。
d.补贴战争：Cursor 最难打的仗
a.市场现状
产品层面，Cursor 3 的方向是对的。但有一场仗，产品再好也很难赢——补贴战。
Claude Code 目前 200 美元/月的订阅，据社区测算提供的实际 API 用量价值远超订阅价格。这不是定价策略，这是 Anthropic 在用资本换市场份额。OpenAI 的 Codex 也在走类似路线。效果立竿见影。社区里已经有大量开发者公开表示从 Cursor 转向 Claude Code——不是因为体验更好，而是因为便宜太多。花同样的钱，Claude Code 能跑的 Agent 任务量是 Cursor 的好几倍。
b.Cursor 的困境
Cursor 的困境很真实：
c.困境分析
a.资本压力
不能跟着补贴：Cursor 没有 Anthropic 或 OpenAI 那样的资本纵深，烧不起这场价格战
b.用户流失风险
不能不应对：用户流失是实实在在发生的事，沉默等于放弃
c.护城河测试
产品护城河正在被测试：当价格差距足够大，"体验更好"的说服力会快速衰减
d.未来的赌注
Cursor 3 的赌注是：用产品体验的代差来抵消价格劣势。
Glass 界面、多 Agent 并行、云端异步执行——这些是 Claude Code 目前没有的。
问题是，这个代差能维持多久？Anthropic 和 OpenAI 都在快速迭代自己的 IDE 集成和 Agent 工作流。Cursor 的时间窗口，可能比它看起来的要短。
e.给开发者的建议
a.适应 Agent 模式
现在就开始用 Agent 模式。不管是 Cursor 3 还是 Claude Code，多 Agent 并行处理任务的工作流是未来的方向。
越早适应"调度 Agent"的思维方式，越不会被淘汰。
b.理性看待迁移
不要因为补贴就完全迁移。Claude Code 的补贴是阶段性的市场策略，不会永远持续。工具链迁移有成本，别为了短期价格优势打乱自己的工作流。
c.培养评估能力
学会评估 Agent 输出。第三时代开发者最核心的能力，不是写代码，而是快速判断 Agent 生成的代码是否可信、是否有隐患。这个能力现在就要开始培养。
d.关注实际落地
关注 Cursor 3 的实际落地。Glass 目前还在逐步推出，很多功能处于 Beta 阶段。等正式版稳定后，
值得认真评估一次——特别是多仓库支持和云端 Agent，对团队协作的影响可能超出预期。
d.谷歌提出CLI的7条设计原则
a.背景与哲学
a.核心哲学
解决方案藏在一条原则里：把数据从呈现中剥离。AI需要原始的、结构化的数据（JSON），人类需要可读的、交互式的格式（TUI）。
把CLI内部逻辑看作数据引擎，终端UI只是其中一个渲染客户端。
b.结构化可发现性
a.按功能分组
Task Management、Configuration这样的分类，避免文字墙。
b.标记入口点
加上提示，AI会据此判断先调用哪个命令。
c.三个必填字段
字段 作用
Short 5-10词，动词开头
Long 解释为什么和差异化
Example 3-5个可复制粘贴的例子
d.文档补充
别假设AI天生知道怎么用你的工具。在仓库根目录放AGENTS.md，定义交互规则、默认工作流。复杂命令加skills/目录，包含专门的提示文件。
c.AI优先互操作性
a.标志支持
--json或--no-tui:每个产生数据的命令都要支持。输出必须是有效的JSON或NDJSON。AI解析不了，你的CLI在AI世界就不存在。
b.自动检测受众
支持NO_COLOR和[APP]_NO_TUI环境变量。stdout被管道传输时，跳过交互元素。
c.非交互式回退机制
使用用户界面（TUI）的命令（如Bubble Tea）应具有纯文本模式。TUI是用户界面，而JSON输出则是代理界面。
d.保护上下文窗口
AI有token限制。截断大段文本，屏蔽敏感secret。需要原始payload时，要求--full或--verbose。
e.预处理数据
自动排序输出，让最关键的项目（严重漏洞、待处理任务）永远在顶部。
f.无状态设计
用引用标识符（--task <ID>）保持CLI无状态。后端维护上下文和对话历史，CLI只是传输机制。
d.配置与上下文
a.遵循XDG规范
配置放在~/.config/app/config.yaml。不要在家目录放dotfile。
b.命名环境用--env切换配置
a.示例配置
---
envs:
local: { service_url: "http://127.0.0.1:9001" }
staging: { service_url: "...", token: "..." }
prod: { service_url: "...", token: "..." }
---
b.说明
编排器设置--env prod，不需要知道URL或token。
e.错误指导
a.上下文提示
不要只报错，要指路。例如提示运行a2acli init。AI会解析提示并自我纠正。
b.快速失败
执行重逻辑前先验证配置。别让AI等30秒后发现token缺失。
c.确定性退出码
码 含义
0 成功
1 一般错误
2 无效用法
3 认证失败
f.Flag一致性
a.语法可预测性
语法必须可预测。学会一个命令，直觉要能延伸到整个应用。
b.标准化shorthands
-o在一个命令里是--out-dir，另一个命令里绝不能是--output。
c.位置参数与flags
位置参数用于必需实体，--flags用于可选修饰符。
d.安全默认值
破坏性操作必须要求显式flag。
g.视觉设计
a.颜色服务于功能
颜色服务于功能，不是审美。
b.语义颜色token
Token 含义
Accent 地标
Command 扫描目标
Pass 成功
Warn 过渡
Fail 错误
Muted 元数据
ID 标识符
c.具体规则
保留颜色给状态。不要给帮助文本着色。用空白表示层级。支持明暗主题。
h.版本与生命周期
a.版本感知
CLI应该知道自己的版本。支持--version，可选通知用户上次运行后的重大更新。
b.优雅处理中断
SIGINT（Ctrl+C）时不能损坏数据。
c.追踪操作者
写操作上记录Actor（从git config user.name或$USER推导），确保可审计。
i.总结
a.本质
CLI的本质是什么？命令行接口，数据传输管道。TUI只是可视化层。剥离这两层，问题迎刃而解。人类需要颜色、交互？
渲染器A负责。AI需要JSON、结构化数据？渲染器B负责。
b.必要性
2026年的CLI不为AI优化，等于不存在。Cursor、Claude、Copilot等AI正在接管开发工作流。
你的CLI迟早被调用。AI解析不了输出，它就去找别的工具。
e.Kimi-Agent集群
a.背景与目标
分享一个使用 Kimi Agent 集群进行行业分析和调研的 Prompt。
该 Prompt 通过调动 6 个 Agent 并行工作，从用户需求、工作流、技术可行性、系统集成、合规安全、商业模式 6 个视角拆解研究主题，
并利用互相质询机制暴露盲点，最后由总控裁决输出优先级清单和路线图，旨在解决单一视角自嗨的问题，强制暴露多方冲突。
b.Prompt 核心逻辑
a.角色设定
你是一名“多智能体研究总控”，需围绕指定主题开展深度研究，并在执行摘要中声明假设。
b.任务目标
寻找用户强需求、技术可解性、商业利润中心三者的交集，最终输出机会地图、优先级清单、产品路线图、验证方案及商业打包策略。
c.研究范围界定
a.应用场景范围
总控须将场景分为核心的第一梯队（高优先级）、增量的第二梯队及跨场景通用维度。
b.价值链/流程范围
覆盖使用前、中、后的全链路，以及协同支撑环节。
c.用户角色覆盖
不仅关注核心用户，还需包含协作用户、管理决策者、支撑角色及间接受益者。
d.6 个并行 Agent 定义
a.Agent 1：用户需求与工作流（User JTBD）
识别高频、高风险节点及专家与新手差异，区分真伪需求，输出 Top 10 用户痛点及 must-have 判定。
b.Agent 2：流程与工效（Workflow & Ergonomics）
关注效率、疲劳、协作摩擦及学习曲线，输出效率损耗地图及可优化环节。
c.Agent 3：技术可行性（Technology Feasibility）
评估技术实现难度与数据需求，区分功能为 Now/Next/Later，输出技术可解性分级与失败模式。
d.Agent 4：系统集成与产品化（System Integration）
评估平台侵入性、兼容性及运维影响，输出系统实现架构及 MVP 方案。
e.Agent 5：合规与安全（Regulatory & Safety）
识别风险等级与监管敏感点，设计验证路径，输出风险分级及安全边界。
f.Agent 6：商业模式（Business & Profit）
判断变现路径与付费方，分析差异化机会，输出变现模式及 ROI 叙事。
e.多智能体协作机制
a.Phase 1：独立分析
6 个 Agent 并行产出 Top 10 候选机会及风险。
b.Phase 2：交叉质询
各 Agent 互相提出反对意见，指出被高估和低估的机会，强制暴露“用户说要但技术做不到”等冲突。
c.Phase 3：总控裁决
综合各方意见，裁决功能是保留、观察还是淘汰。
f.量化评分框架
包含 11 个评分维度（如用户刚需度、技术可解性等），并为各维度设定建议权重（如用户价值占 35%）。
g.输出结构规范
a.执行摘要
包含主战场结论、最值得做的功能、关键假设及首发场景。
b.真实场景拆解
按场景乘流程乘角色详细拆解核心流程与痛点。
c.Agent 结论汇总
汇总 6 个 Agent 的 Top 10 机会、论据及不建议做的点。
d.交叉质询记录
记录反对意见、盲点及总控裁决理由。
e.候选功能总表
包含痛点、技术方案、商业模式、评分及结论的核心表格。
f.三圈交集清单
按“Must-Have × Solvable × Profit”等交集分组，给出策略建议。
g.产品路线图
包含三个阶段（0-12月、12-24月、24-36月）的交付物与里程碑。
h.验证方案
包含验证路径、KPI 及 Go/No-Go 标准。
i.商业打包策略
包含版本划分、定价策略及 Build vs Buy 决策。
j.管理层摘要
包含核心结论、优先级矩阵及投资回报预期。
h.关键质量要求
a.务实与具体
禁止空话，结论必须对应具体场景、角色和价值；必须给出 MVP 路径及现有方案的增量价值。
b.全面与诚实
必须覆盖所有相关角色；必须诚实面对技术难题；必须指出“看起来酷但不该做”的功能。
c.合规与验证
必须明确合规分级；必须验证跨场景功能的真实性；必须回答伪需求问题。
i.额外增强要求
坚持第一性原理，优先使用增量价值分析，对高优先级功能需解释窗口期，输出风格需务实、尖锐、可落地。
04.常用信息4
xxxxxx
2.6 智能设计2
00.汇总
a.分类1
终端升级的重要性
OpenClaw是什么
OpenAI的驾驭工程学
AutoResearch项目
自己的AI特种部队
b.分类2
跨会话记忆持久化
智能体原生工作估算
WordPress迁移工作
你的LLM并不会写“正确的代码”
pi极简而强大的AI编码智能体框架
c.分类3
值得程序员关注的AI Agent系统新信号
AI时代留给人类最持久的机会是什么
真正决定Agent上限的是Harness
LangChain创始人谈AI重塑EPD团队
HarnessEngineering的关键模块记忆层
d.分类4
Karpathy最新的干货输出：能够进化的知识库
多智能体系统到底如何设计，来看看Claude的思考
Karpathy新提出LLM Wiki：可能将彻底颠覆RAG知识库
为什么你的多智能体系统总失控？四个文件让它乖乖听话
Karpathy的Agent使用心法——从"提示词工程师"到"智能调度师"
e.分类5
你担心 AI 时代失业吗
当 AI 开始给 AI 写代码——递归开发的终局猜想
Anthropic长运行应用设计实践，越来越有AutoResearch的思想
组建一支AI梦之队，Agency-Agents给你128个随时待命的专业Agent
今天的AI已经不在卷模型了，而是在卷“谁能把 Agent 真的塞进公司里”
f.分类6
AI Agent 的记忆战争
Agent 能跑七天？这五个设计模式是关键
Prompt Caching：用架构设计把 AI Agent 成本砍掉 80%
从蒸汽机到Agent：控制论和Harness Engineering正在重塑程序员的未来
Agent 入门：别一上来就做“超级智能体”，先写一个能取消订单的小 Agent
g.分类7
Markdown 成为了当前 AI 文件交互的一个标准
AI 编程，Cloudflare 是怎样保证质量的呢？
三天三个大版本，Claude Code 正在从终端工具变成开发环境
95% 代码都交给 AI 了，但真正拉开团队差距的，可能是录音和 Skill
未来的职场，不会淘汰解决问题的人，只会奖励那些定义问题的人
h.分类8
xxxxxx
01.常用信息1
a.终端升级的重要性
a.Ghostty
作为基础终端入口，特点是快速、原生、界面简洁、渲染流畅，提升终端底层使用体验。
b.tmux
核心价值为会话持久化，支持断网、关窗口后恢复状态，适用于运行服务、查看日志、多窗口调试，保障工作流不中断。
c.fish
开箱即用的shell，自带自动补全、语法高亮、交互提示，无需复杂配置，大幅提升命令输入效率。
d.starship
轻量美观的提示符工具，展示Git分支、命令执行结果、运行环境等关键信息，信息密度适中，不拖慢终端。
e.四件套核心作用
Ghostty负责顺滑的体验底座，tmux保障任务不中断，fish提升输入效率，starship清晰展示上下文信息。
f.快速安装命令
使用brew一键安装核心组件：brew install tmux fish starship。
g.总结
终端是程序员高频使用的主战场，打磨好终端环境可同时提升工作效率与使用心情。
b.OpenClaw是什么
a.说明1
Manus刚出的时候，就有人问：Manus和Claude Code有啥区别？不就是在Claude Code里内置一些工具吗？
Cowork刚出的时候，又有人问：Cowork和Claude Code有啥区别？不就是隐藏了写代码的界面吗？
OpenClaw出来的时候，还有人问：OpenClaw和Claude Code有啥区别？不就是通过IM发消息给Claude Code吗？
-------------------------------------------------------------------------------------------------
我认为，这种动不动就说“不就是”的人，不是一个好的学习者。也许他什么都没做错，他只是老了，无法接受新事物了。
我们如果找一个八十岁、吃了一辈子肉夹馍的人去吃汉堡，他也可能觉得汉堡和肉夹馍没区别。
所有产品的演化，都是踩在巨人的肩膀上，进化论是地球上唯一靠谱的成功学。
所以，新演化出来的好产品，一定是踩在了以前的好产品的肩膀上的，这不足为奇。
-------------------------------------------------------------------------------------------------
Claude Code 原本是一个编程工具。但是，我们发现，理论上，把电脑权限开到最大，Claude Code可以实现“通过自然语言交流，控制电脑的一切”。
这一点，早在2025年3月，就有人看到了。我之所以能在Claude Code上消耗了那么多Token，也是因为我很早就看到了这一点，我根本没主要用它写代码。
-------------------------------------------------------------------------------------------------
Manus当然也看到了这一点。根据Manus创始团队叙述，最初让他们感到兴奋的，是一个叫做Browser-Use的开源项目，
发现大模型可以自由控制浏览器、完成几乎一切浏览器上能完成的工作。
但是Manus有一个关键的洞见：Agent可以操作电脑，很好，就像实习生一样；但是，我不想让实习生和我抢电脑用啊！实习生应该有他自己的电脑！
-------------------------------------------------------------------------------------------------
因此，Manus选择了“开网吧”的方式，让Agent在云端电脑（沙箱）上运行。
b.说明2
普通用户在使用Manus的时候，约等于在“网吧的共用电脑”上使用Agent。只是Manus的用户体验极好，没有技术背景的用户，可能都意识不到，任务是在一台单独的临时电脑上执行的。
Cowork继承了上面这两点，再叠加了另外两个洞见：
1.普通用户不需要看到写代码的过程
2.Agent干活的时候，不是什么活都可以用“网吧电脑”实现的吧？我私人、我的企业，总有一些比较私密的资料和工具，还是得用我自己的电脑才行。
因此，Cowork的产品形态，是一个看不到写代码过程的、在你自己电脑上运行的Agent。
-------------------------------------------------------------------------------------------------
OpenClaw在上面的基础上，又叠加了新的洞见：
1.的确，很多场景下，Agent不能只靠网吧电脑，需要用我自己的电脑；
但是，没人规定，我只能有一台电脑吧？我能不能专门给实习生配置一台电脑，让它随便折腾？
2.我通知我的实习生干活，我是不需要坐在电脑前的吧？
3.实习生干完活应该自己会主动通知我才对，不需要我守着吧？
-------------------------------------------------------------------------------------------------
从而，OpenClaw演化成了现在的形态： 通过IM发布任务、Agent随便操作一台自己的电脑搞坏了也不心疼。
基于这些原理，我才研究出了最好的使用OpenClaw的方式——真把它当人来用 用了两周OpenClaw后，决定今年不招人类员工了
如果你能充分里面上面4个产品、4个阶段的所有原理，你也能用好OpenClaw。
短短一年的时间，多么美妙的过程啊！从Claude Code、到Manus、到Cowork、到OpenClaw，我们离“钢铁侠里的Jarvis”越来越近了。而这一切是真实发生的，不是科幻小说，真的让人感到难以置信。
不知道你是否能感受到其中进化论影子？ 每一次进化，都是在前人的基础上，叠加了新的技能。
c.OpenAI的驾驭工程学
a.案例背景：OpenAI的驾驭工程学实验
2026年2月，OpenAI公开了一个内部实验结果：仅用5个月时间，人类一行代码未写，
完全由AI编写了100万行代码，成功交付了一个拥有日活用户的Beta产品。这套方法论被称为驾驭工程。
b.核心概念：什么是驾驭工程
驾驭工程不同于AI辅助编程，它不再是人类亲自写代码，而是人类设计一套环境和控制系统，
让AI Agent在其中自主、可靠地完成软件开发任务。其核心架构包含四根护栏：结构化文档、架构约束、可观测性和反馈循环。
c.第一根护栏：结构化文档
AGENTS.md文件是Agent进入仓库的第一份指南。有意思的是，这份文档本身也是由AI编写的。
随着项目演进，万能手册会精简为目录页，指引Agent按需查找详细文档。核心思路是信息的良好组织而非单纯的信息堆砌。
d.第二根护栏：架构约束
为了防止代码质量衰退和架构漂移，必须把高级工程师的品味编码成机械执行的规则。
通过自定义Linter检查命名、边界和耦合度，将软约束变成硬规则。错误信息直接反馈给Agent以指导修复，确保大规模Agent生产出风格一致的代码。
e.第三根护栏：可观测性
让Agent具备看日志和修Bug的能力。Codex Agent可以访问日志和指标，使用LogQL和PromQL查询，
在隔离环境中复现Bug，并分析UI行为。测试和CI配置同样由Agent编写，环境用完即销毁，不留污染。
f.第四根护栏：反馈循环
Code Review流程变为Agent审Agent。写完代码先自审，再请求其他Agent复审，基于反馈迭代修改直到满意。
这形成了一个自动清理技术债的垃圾回收机制，大量审查工作在Agent之间完成。
g.角色转变：从码农到驯兽师
工程师的价值不再是手写业务逻辑，而是设计驾驭系统。以前的工作是写测试、调Bug、写文档，现在变成了设计反馈机制、
搭建可观测性基础设施和组织结构化文档。人类掌舵，Agent划桨。
h.深度思考：生产方式的范式转移
a.从辅助到委托
Copilot是辅助，驾驭工程是委托。这就像手动挡与自动挡的区别，代表了软件工程从人写代码到人设计让AI写代码系统的范式转移。
b.词汇的精准性
Harness一词精准表达了人与AI的关系：既不是替代干活，也不是无限信任，而是装上缰绳和护具，让其又快又稳地奔跑。
c.开发者的新挑战
目前门槛较高，需要强大模型、完善工具链和深刻架构理解。未来最值钱的能力将是设计让AI写好代码的系统的能力，包括架构设计、系统思维和文档能力。
i.现实挑战与未解难题
虽然前景广阔，但也存在适用范围、安全性、创造性和成本等未解难题。能用Agent写新产品不代表能改造十年老系统，且Agent写代码的安全漏洞和Token成本仍需关注。
j.历史定位：工业革命在软件业的重演
正如第一次工业革命机器取代体力，人类价值变为设计机器；驾驭工程描述的是AI取代写代码劳动，程序员价值变为设计系统的故事。
这是软件工程史上最大的一次范式转折，能设计缰绳的工程师将比能写代码的工程师更值钱。
d.AutoResearch项目
a.AutoResearch项目核心介绍
AutoResearch是Karpathy开源的AI自主研究项目，可让AI智能体自主设计、执行LLM训练实验，
一晚上能完成约100个实验，核心仅3个文件且AI仅可修改1个，
项目地址为https://github.com/karpathy/autoresearch。
b.项目解决的核心问题
解决LLM训练调参的传统痛点，网格搜索成本高、随机搜索效率低、人工调参上限低且易陷局部最优，
AI在定制沙盒中以固定5分钟时间预算快速验证实验想法，高效试错。
c.核心架构与文件分工
采用极简设计，共3个核心文件，分工明确且有严格修改约束，保障实验公平性同时预留实验空间
a.prepare.py
负责数据准备、分词器训练、评估函数，为固定文件，AI不可修改。
b.train.py
包含模型定义、优化器、训练循环，AI可修改，可调整模型结构、超参数等所有训练相关内容。
c.program.md
定义AI智能体的操作指令，为项目灵魂，由人类修改。
d.各核心文件具体实现
a.prepare.py
从HuggingFace下载ClimbMix-400B数据集，用rustbpe训练词表大小8192的BPE分词器，采用BOS-aligned数据打包实现100%利用率。
b.train.py
模型为基于GPT的Decoder-only架构，融合滑动窗口注意力、Value Embedding、RoPE、RMSNorm等技术；
优化器为自定义MuonAdamW，矩阵参数用Muon、嵌入层和标量参数用AdamW。
c.program.md
定义AI实验循环流程：查看git状态→修改train.py→git commit保存→运行5分钟训练→读取验证结果→保留有效改进/回退无效尝试→记录结果→循环执行。
e.核心创新：5分钟固定时间预算实验
所有实验均运行5分钟墙钟时间，以val_bpb（验证集每字节比特数，越低越好）为评估指标，
该设计让实验结果可直接公平对比、自动适配不同硬件、实现快速迭代、严格控制计算成本。
f.AI可调整的超参数空间
AI可在train.py中修改模型架构、优化器配置、模型大小相关超参数，
包括ASPECT_RATIO、HEAD_DIM、WINDOW_PATTERN、各类学习率、WEIGHT_DECAY、DEPTH等，尝试最优组合。
g.项目快速使用方式
a.安装Python包管理器uv：curl -LsSf https://astral.sh/uv/install.sh | sh
b.克隆项目并安装依赖：git clone https://github.com/karpathy/autoresearch && cd autoresearch && uv sync
c.数据与分词器准备：uv run prepare.py
d.手动验证训练：uv run train.py
e.启动AI智能体：在Claude/Codex中打开program.md，让AI开始自主实验。
h.项目评价与使用建议
a.看好的理由
设计哲学合理，以约束换自由、固定时间换公平对比；可扩展性强，易扩展文件与功能；
社区价值大，开源可汇聚实验结果加速研究；方向可行，是自主AI研究的优质原型。
b.需要警惕的点
5分钟时间可能不足以显现部分改进效果；单val_bpb指标存在局限，易忽略其他重要维度；
仍有一定计算成本；在ClimbMix-400B上的效果不代表能泛化到其他数据集。
c.使用建议
LLM预训练研究者可fork尝试，即使不做实验，其固定时间预算、透明追溯、极简约束的设计思路也值得借鉴。
i.小平台适配与知名分支
a.小平台调优建议
更换低熵数据集如TinyStories；降低vocab_size、MAX_SEQ_LEN、EVAL_TOKENS、DEPTH、TOTAL_BATCH_SIZE等参数；
调整DEVICE_BATCH_SIZE补偿序列长度；使用"L"模式WINDOW_PATTERN。
b.知名适配分支
miolini/autoresearch-macos（MacOS）、trevin-creator/autoresearch-mlx（MacOS）、jsegov/autoresearch-win-rtx（Windows）。
j.自主AI研究的延伸思考
现阶段AutoResearch仍较简单，仅能改一个文件、单评估指标、实验空间有限；
未来可扩展至AI修改数据预处理、设计新模型架构、多目标优化、读论文提假设，成为真正的研究合作者；
同时也需解决AI想法评估、避免局部最优、明确人类研究者角色等问题。
k.项目核心总结
核心创新为固定5分钟时间预算的实验设计，约束的设置让实验更公平，开源设计助力社区共同加速研究；
实现了AI自主完成LLM训练实验的落地，展现了AI时代研究的新方式。
e.自己的AI特种部队
a.背景介绍
Y Combinator掌门人Garry Tan开源了自己的AI特种部队。
Y Combinator是硅谷最牛的创业孵化器，Airbnb、Dropbox、Stripe、Reddit等知名公司都出自YC。
Garry Tan是现任掌门人，他在GitHub上开源了gstack项目，48小时破1万星。开源地址：https://github.com/garrytan/gstack
b.gstack项目概述
gstack本质上是一组Claude Code的自定义命令——12个斜杠命令，每个命令对应一个专业角色。
Garry Tan自称用这套工具，50天里写了10000行代码，提了100个PR。一个VC大佬，一个人，干了半个工程团队的活。
c.核心设计理念
Garry希望AI不再是万能助手、样样都懂样样稀疏，而是专业分工的专家组。
他说：我不想让AI工具停留在模糊的模式，我要的是明确的齿轮。
普通人用Claude Code就像请了一个什么都能聊两句但什么都不精的实习生，Garry Tan做的事情是把这个实习生拆成了12个专家。
d.12个命令详解
a.plan-ceo-review——CEO和创始人视角审查
让AI扮演挑剔的CEO，重新审视需求。不是问你要做什么功能，而是问这个需求背后那个10星产品长什么样。
被称为布莱恩·切斯基模式，教AI拒绝平庸需求。在写第一行代码之前，先让AI帮你想清楚这事值不值得做。
b.review——资深工程师模式
偏执型代码审查，模拟见过太多线上事故的Staff Engineer，专门找那些CI能过但生产环境会炸的bug，如竞态条件、边界情况、隐藏的性能问题。
c.ship——发布工程师模式
一条命令完成所有事：同步主分支、跑测试、处理review评论、push代码、开PR。以前需要发布工程师盯着的流程，现在一个斜杠搞定。
d.qa——测试工程师模式
AI先当QA测产品，找到bug后不是报单，而是直接修，提交原子级commit，然后再验证修复是否生效。
e.plan-design-review——设计审计
80项检查清单，10个类别打分，A到F评级。还有AI Slop Score检测网站是否有AI生成的廉价感。
f.browse——给AI装上眼睛
内置持久化Chromium浏览器，首次启动3秒，之后每次调用100-200毫秒，Cookie和登录态全程保持。AI能看到产品在浏览器里的样子。
g.其他命令
包括retro做工程复盘、document-release自动更新文档、setup-browser-cookies管理浏览器会话等，12个命令覆盖软件项目从规划到上线的全流程。
e.作者使用体验
作者使用plan-ceo-review以硅谷CEO角度审核自己的Raphael AI项目。
有阶段性成果时AI会停下来问看法，说话语气很有硅谷CEO的感觉。
Claude Code默认Opus 4.6已有1M Context，这个硅谷CEO很吃上下文长度。最后得到的结论对作者很有启发。
f.核心洞察
a.不是编程工具而是组织架构
Garry Tan做的不是AI编程工具，而是AI组织架构。传统做法是招6个人、开6次会、扯3天皮然后上线；
Garry Tan的做法是一个人用12个命令，让AI分别扮演CEO、工程师、QA、设计师等角色。人类只做一件事：决策。
b.类似项目
agency-agents（4.65万星）更激进，直接模拟整个AI公司，有前端工程师、后端工程师、产品经理、Reddit社区运营等Agent。
obra/superpowers（8.56万星）是agentic skills框架，让用户自定义AI Agent能力组合。
三个项目加在一起星数超10万，呈现明显趋势：不再是AI帮你写代码，而是AI帮你开公司。
g.未来创业公司形态
以前创业第一步是找人，找技术合伙人、前端、测试、设计，光招聘就要花两三个月。现在第一步可能变成了配Agent。
Garry Tan一个人50天干了100个高质量PR，等于2-3个全职工程师的产出，而他的工程团队是12条命令。
未来创业公司可能是：3个人类做决策加20个AI Agent做执行。今天还按传统方式搭10-20人技术团队的，就是落伍者。
h.作者总结
a.选岗位不选任务
帮我看看代码是任务，做完就没了；每次有新代码提交就自动做一遍代码审查是岗位，是持续性的。gstack的12个斜杠命令本质上是12份岗位说明书。
b.SOP可自动化
一件事情只要有SOP，它就能被自动化。Garry Tan用12条命令证明了这一点。差的从来不是高级技术，差的是有没有把我亲自干变成我定规则AI来干。
c.未来已来
Garry Tan不是在教写代码，而是在告诉我们未来公司长什么样。而他已经开源了图纸。
02.常用信息2
a.跨会话记忆持久化
a.Claude 的原生做法
a.Projects 机制
每个项目拥有独立的记忆空间，Claude 会在该项目所有对话中保持连续性。
切换会话后无需重新解释背景，实现了项目级别的上下文隔离。
b.Memory Tool (memory_20250818)
基于文件系统的 /memories 目录，实现跨会话的长期学习。
短期对话上下文可清除，但长期模式会持久保存。
c.记忆迁移功能
支持记忆导入导出，可将记忆文本文件从另一个 AI 助手迁移进来。
用户只需上传并指示 Claude 存入记忆工具即可完成迁移。
b.工程派：文件驱动记忆
a.核心文件结构
a.CLAUDE.md / AGENTS.md
放置在项目根目录，相当于"项目说明书"。
包含技术栈、已知决策、禁止事项，Claude Code 等工具初始化时会自动读取。
b.MEMORY.md + 日志文件
存储在 memory/YYYY-MM-DD.md 路径下。
Agent 在每次对话结束后自动写入当天的决策、发现的 Bug 模式及代码规范。
c.SOUL.md
定义 Agent 的行为准则和偏好，确保跨会话保持人格一致性。
b.分文件策略
通过在 CLAUDE.md 中指定读取 6 个文件（如 Important.md、Known.md、Fastfacts.md 等）来实现细粒度管理。
AI 自动维护其中 3 个文件，人类维护另外 3 个，实现人机协作的记忆管理。
c.框架派：Mem0
a.核心能力
自动提取、合并、检索对话中的关键信息，并智能过滤无意义噪音。
支持"语义去重"，避免重复存储（如将不同时间的素食表述合并为同一条记忆）。
b.性能优势
相比 OpenAI 全上下文方案，p95 延迟降低 91%，Token 成本节省超过 90%。
在多跳问答任务上，表现比 OpenAI 高出 26%。
c.生态集成
可与 CrewAI、LangChain、AWS Bedrock AgentCore 等主流框架无缝集成。
d.云服务派：AWS Bedrock AgentCore Memory
a.层级能力
a.会话内记忆
依赖当前对话上下文，会话结束即清除。
b.跨会话长期记忆
存储用户偏好和历史决策，按 memoryId 持久化。
c.项目隔离
不同 sessionId 独立存储，可配置存储时长。
b.关键机制
使用同一个 memoryId 调用 Agent 可恢复该用户的全部历史上下文。
设置 endSession=true 可触发记忆提取和压缩操作。
e.解决"代码幻觉"的根本方法
a.RAG（检索增强生成）
将代码库、文档、API 文档向量化后存入向量数据库（如 Pinecone/Weaviate）。
每次提问先检索再生成，GPT-4 + RAG 可将幻觉率从 39% 降至 0-6%。
b.记忆 + RAG 双轨
Mem0 管理对话历史和用户偏好，RAG 负责代码事实核查。
两者结合可同时解决"忘了上下文"和"编造 API"的问题。
c.约束文件
在 CLAUDE.md 中写明已知 Bug 和禁止行为。
Agent 启动时强制读取，固化"已验证有效的解法"和"踩过的坑"。
f.迁移旧窗口至新窗口的最简实践
a.上下文交接文档
在旧会话结束时，让 AI 生成一份包含项目背景、当前进度、已知问题、下一步计划的文档。
b.操作流程
将生成的文档保存为 HANDOFF.md。
在新窗口的第一条消息上传此文件，并提示 AI："这是上次对话的完整上下文，请继续"。
Claude 支持直接将此类文件导入记忆工具。
c.优势对比
比手动粘贴聊天记录效率高。
比让 AI 解析原始导出数据更可靠。
b.智能体原生工作估算
a.智能体软件工程：别再用人类的尺子量AI的活了
《智能体软件工程》可能是一系列文章，记录从传统软件工程向智能体软件工程的迁移过程。
b.一个老程序员的顿悟
AI 编程效率极高，传统的基于人类开发者经验的估算框架（如拆任务、加 buffer）在 AI Agent 面前彻底失灵。
AI 往往用几分钟完成人类数天的工作量，且 AI 自己也会基于训练数据给出错误的人类时长估算。
c.问题的根源：人类时间锚定
AI 在估算时会调用训练数据中的人类经验（如 Sprint Planning、论坛上的工期），导致系统性高估。
我们需要一套 AI 原生的度量体系，而不是“拿人的尺子量 AI 的活”。
d.一种解法：让 Agent 用自己的单位思考
a.核心思路
先用轮次估算，最后才转换成人类时间。
b.原子单位
一轮包含思考、编写代码、执行、查看输出、决定是否修复，约 2-4 分钟。
c.四层估算单位
轮次（Round）：一次工具调用循环。
模块（Module）：由多轮构成的功能单元。
波次（Wave）：无相互依赖的模块批次，可并行。
项目（Project）：所有波次顺序执行加集成调试。
e.五步估算法
a.第一步：拆解模块
把任务分成可以独立构建和测试的功能模块。
b.第二步：估算每个模块的轮次
模板化或已知模式通常 1-2 轮；中等复杂度 3-5 轮；探索性或文档不足 5-10 轮；高不确定性 8-15 轮。
c.第三步：加风险系数
低风险 1.0，中风险 1.3，高风险 1.5，极高风险 2.0。
d.第四步：计算总量
单 Agent 顺序编码为各模块轮次之和；多 Agent 并发编码取波次内的最大值并加上协调成本。
e.第五步：转换为人类时间
项目轮次乘以每轮分钟数（默认 3 分钟），人类时间是输出而非输入。
f.实战校准：三个尺度的对照
a.小项目：CLI JSON-to-YAML 转换器
总计约 8 轮（24 分钟），而人类经验可能估算为 1-2 天。
b.中型项目：桌面键盘广播器
顺序执行约 36 轮（108 分钟），3 Agent 并行可压缩至 57 分钟，人类可能估算为 2-3 周。
c.大型项目：全栈实时 Dashboard
顺序执行约 63 轮（189 分钟），3 Agent 并行约 108 分钟，人类可能估算为 3 个月。
g.六个必须避免的反模式
a.人类时间锚定
必须从轮次开始推，禁止以“一个开发者大概需要...”为基点。
b.凭感觉加 buffer
必须使用风险系数，每一分钟的膨胀都要有理由。
c.混淆复杂度和代码量
按不确定性估算，不按行数。
d.忘记集成成本
永远加集成轮次。
e.忽略用户侧瓶颈
需要手动测试时调整每轮分钟数，不加轮次。
f.假设并行是免费的
多 Agent 协作有协调成本（合约定义、冲突解决）。
h.写在最后
a.思维范式迁移
软件工程正从“人写代码”转向“Agent 写代码”。当原子操作从“一天”变成“一轮工具调用”时，旧的度量体系（Story Point、人天）需要重建。
b.不确定性依然存在
不能盲目乐观，macOS 权限、未文档化行为等风险依然存在，需通过风险系数尊重现实。
c.Skill 安装
npx skills add ZhangHanDong/agent-estimation
c.WordPress迁移工作
a.背景介绍
a.项目概况
WordPress 存在了 24 年，运行在全球 42.5% 的网站上。Cloudflare 用 2 个月从零设计了 AI 时代的 CMS EmDash。
b.项目性质
EmDash 名字源自愚人节笑话，但项目本身是真实存在的。
b.WordPress 的 20 年老伤
a.安全隐患
WordPress 占据 59.8% 的 CMS 市场，但 96% 的安全漏洞来自插件。
b.架构缺陷
在 PHP 架构下，插件拥有完全的数据库和文件系统访问权限，缺乏隔离，理论上可删站。
c.审核困境
插件审核队列积压严重，等待超 2 周，团队来不及检查破坏性操作。
c.EmDash 的解决方案
a.开发概况
主工程师 Matt Kane 使用 TypeScript + Astro 6.0 重构，核心改进在于安全模型。
b.沙箱隔离
插件运行在独立的 Dynamic Worker isolate 中，实现内存、文件和数据库的物理隔离。
c.权限声明
插件需在 manifest 中声明权限，类似 OAuth scope，用户安装时可见具体授权范围。
d.MIT 协议
采用 MIT 协议，对商业公司友好，无需开源修改。
e.Serverless 计费
基于 Cloudflare Workers，按 CPU 时间计费，零请求零成本。
d.AI 原生设计
a.设计理念
架构决策围绕"如果 AI Agent 需要做这件事会怎样"进行。
b.内置 MCP 服务器
AI Agent 可直接连接 CMS，管理内容、发布文章、修改设置。
c.Agent Skills 预定义
提供技能文件教 AI 完成特定任务，如 WordPress 迁移、插件创建、SEO 优化。
d.CLI 工具
提供命令行接口，专为 AI Agent 操作设计。
e.x402 协议
内置内容付费能力，支持 AI Agent 通过微付费获取授权。
e.AI 建造的 AI 工具
a.开发模式
EmDash 使用 AI 编程 Agent（如 Cursor、Claude Code）构建，非简单的周末项目。
b.正反馈循环
设计者深知 AI Agent 需求，因此构建了真正的 AI 原生工具。
f.冷静看：现实挑战
a.早期阶段
版本号为 v0.1.0，稳定性尚无法保证。
b.没有生态
缺乏插件市场、社区和教程，功能需自行开发。
c.迁移不完整
仅能导入内容，插件和主题需完全重写，成本高昂。
d.自托管受限
自托管模式不支持沙箱插件，失去核心安全优势。
e.营销属性
本质是展示 Cloudflare Workers 能力，长期维护承诺不明。
g.给开发者的判断
a.不适合对象
已经在使用 WordPress 的网站，迁移成本太高且收益不明确。
b.适合尝试
从零开始的新项目、AI-first 应用、安全敏感场景以及 Serverless 爱好者。
h.总结
a.范式转换
WordPress 是 Web 2.0 产物，假设人类操作；EmDash 假设 Agent 操作，这是根本差异。
b.核心价值
证明了从 AI 原生视角设计可从根本上解决安全问题。
c.遗留问题
2 个月的产品能否对抗 24 年的生态积累仍需观察。
i.参考来源
Cloudflare 官方博客、The Register、Joost de Valk 博客分析、EmDash GitHub 仓库。
d.你的LLM并不会写“正确的代码”
a.核心观点
LLM不会写“正确的代码”，只会写“看起来像对的代码”，能运行≠正确，隐蔽性错误更危险。
b.AI编程的普遍错觉
代码可编译、可运行、测试通过，就认为AI生成结果可靠，忽略核心逻辑与性能正确性。
c.典型案例：LLM生成的Rust版SQLite
a.现象
主键查询100行数据，原生SQLite仅需0.09毫秒，LLM生成版本耗时1815.43毫秒，差距达两万多倍。
b.表面完整性
代码可编译、通过测试、模块齐全（解析器、查询规划器、B-tree、WAL等），文档完善，看似成熟数据库引擎。
c.致命问题
未正确识别INTEGER PRIMARY KEY是rowid别名，主键查询退化为全表扫描，核心执行路径错误。
d.附加性能陷阱
每次写入均触发昂贵磁盘同步、重复加载schema、克隆语法树，单点合理但整体性能极差。
d.LLM生成代码的典型缺陷
a.局部正确感
单段代码合理，整体组合后系统性能极差、结构臃肿。
b.过度复杂化
简单需求（如清理编译缓存）被生成庞大复杂系统，不解决真实问题。
c.缺乏工程经验
无底层开发直觉，不懂关键路径、性能不变量、必须复用的对象与禁止复制的内存路径。
d.迎合式输出
无论写代码还是审核代码，都倾向输出用户期望的答案，而非客观正确结果。
e.风险人群差异
a.资深开发者
懂核心原理，将AI作为效率加速器，可控风险。
b.新手/无验证能力者
易将“可运行”等同于“正确”，在无察觉情况下使用错误系统。
f.正确使用AI编程的方法
a.先定义验收标准
明确关键路径、性能指标、禁止行为、必须通过的基准测试。
b.关键路径必做基准测试
基础组件必须用真实数据压测，不依赖功能演示。
c.质疑核心算法与系统调用
追问算法选择、索引使用、内存复制、同步策略等底层决策。
d.拒绝不必要的复杂方案
由人判断方案复杂度，不任由AI过度设计。
e.不使用自己解释不清的代码
必须理解设计逻辑、边界安全性、扩展性，否则视为陌生代码。
g.总结
AI是放大器而非替代者，AI时代程序员最核心的能力是定义“正确”、验证“正确”、识别伪装正确的能力。
e.pi极简而强大的AI编码智能体框架
a.说明
a.设计哲学
Pi是一个极简、可扩展的AI编码智能体框架（harness），
其核心设计哲学可以用一句话概括：一个调用LLM的while循环，加上四个基础工具。与当今复杂的AI Agent平台不同，
Pi选择了一条反其道而行的道路——不是增加更多功能，而是将复杂性降到最低。
b.设计观点
开发者Armin Ronacher和Mario Zechner认为，
现代顶尖大语言模型（如Claude Sonnet）已经具备足够的能力：它们擅长读取文件、编辑文件、执行命令。
因此，Pi坚信： "Bash就是你所需要的一切" 。这个看似极端的理念背后，是对LLM能力的深度信任和对工具链复杂性的警惕。
c.总结
在 AI 时代，减法比加法更难，但也更有价值。
当其他框架在比拼功能列表长度时，Pi 证明了：一个设计良好的极简系统；可以通过组合和扩展；
完成复杂系统能做到的一切；同时保持清晰和可控。核心原则回顾：极简（一个 while 循环 + 四个工具）；
可扩展（技能系统支持热加载）；可控（转向队列支持实时干预）；可靠（代码即真理，无需外部记忆）。
b.核心循环：一个 while 循环
a.说明
Pi的核心确实如开发者所说——就是一个while循环。在 packages/agent/src/agent-loop.ts 中：
b.代码
// 外层循环：处理后续消息队列
while (true) {
let hasMoreToolCalls = true;
let steeringAfterTools: AgentMessage[] | null = null;
// 内层循环：处理工具调用和转向消息
while (hasMoreToolCalls || pendingMessages.length > 0) {
// 1. 处理待处理消息（用户新输入或转向消息）
if (pendingMessages.length > 0) {
for (const message of pendingMessages) {
currentContext.messages.push(message);
}
pendingMessages = [];
}
// 2. 调用LLM获取响应
const message = await streamAssistantResponse(currentContext, config, signal, stream);
// 3. 检查是否有工具调用
const toolCalls = message.content.filter((c) => c.type === "toolCall");
hasMoreToolCalls = toolCalls.length > 0;
// 4. 执行工具调用
if (hasMoreToolCalls) {
const toolExecution = await executeToolCalls(
currentContext.tools, message, signal, stream, config.getSteeringMessages
);
// 工具结果会作为新消息加入上下文
for (const result of toolExecution.toolResults) {
currentContext.messages.push(result);
}
}
// 5. 检查转向消息（实时干预）
pendingMessages = (await config.getSteeringMessages?.()) || [];
}
// 6. 检查后续消息队列
const followUpMessages = (await config.getFollowUpMessages?.()) || [];
if (followUpMessages.length > 0) {
pendingMessages = followUpMessages;
continue; // 继续外层循环
}
break; // 没有更多消息，结束
}
c.人话解释
步骤1：发送消息（把用户消息发给 AI）。
步骤2：工具调用（AI 说我要用工具 → 执行工具 → 把结果告诉 AI）。
步骤3：循环执行（AI 继续思考，可能还要用工具 → 重复步骤 2）。
步骤4：完成检查（AI 说我完成了 → 检查有没有新用户消息）。
步骤5：循环控制（有就继续，没有就结束）。
这就是全部。 没有复杂的状态机，没有工作流引擎，没有递归调用——就是一个简单的"对话-执行-反馈"循环。
c.四个基础工具
a.在 packages/coding-agent/src/core/tools/index.ts 中，Pi定义了四个核心工具
// 默认工具集：只有4个
export const codingTools: Tool[] = [readTool, bashTool, editTool, writeTool];
// 只读工具集（用于探索阶段）
export const readOnlyTools: Tool[] = [readTool, grepTool, findTool, lsTool];
b.四个核心工具的职责
read | 读取文件内容 | AI需要知道代码长什么样
bash | 执行shell命令 | 运行git、npm、测试、grep、find等
edit | 精确修改文件（查找替换） | 修改现有代码
write | 写入新文件 | 创建新文件
c.为什么不需要更多？
看 bash 工具的定义（简化版）：
Bash可以调用grep、find、ls、git、npm……整个Unix工具链都是AI的延伸。Pi的哲学是：不要为每个功能写新工具，让AI用Bash调用现有工具。
const bashSchema = Type.Object({
command: Type.String({ description: "Bash command to execute" }),
timeout: Type.Optional(Type.Number({ description: "Timeout in seconds" })),
});
d.可迁移经验
工具设计遵循"Unix哲学"：每个工具做一件事，但可以组合
优先使用系统已有能力，而非重新发明
工具描述要清晰，让AI知道什么时候用什么
d.自我扩展：技能系统如何工作
a.说明
Pi的"元文档"约占总提示词的25%，教AI如何扩展自己。这是通过Skill系统实现的。
b.在 packages/coding-agent/src/core/skills.ts 中
export interface Skill {
name: string; // 技能名称
description: string; // 技能描述（AI根据这个决定何时加载）
filePath: string; // 技能文件路径
baseDir: string; // 技能根目录
source: string; // 来源（user/project/path）
disableModelInvocation: boolean; // 是否禁用自动调用
}
// 加载技能
export function loadSkills(options: LoadSkillsOptions = {}): LoadSkillsResult {
// 从多个位置加载：
// - ~/.pi/agent/skills/ (全局)
// - .pi/skills/ (项目本地)
// - CLI --skill 参数指定的路径
}
// 将技能格式化为系统提示词
export function formatSkillsForPrompt(skills: Skill[]): string {
const lines = [
"The following skills provide specialized instructions for specific tasks.",
"Use the read tool to load a skill's file when the task matches its description.",
...
"<available_skills>",
];
for (const skill of visibleSkills) {
lines.push(` <skill>`);
lines.push(` <name>${skill.name}</name>`);
lines.push(` <description>${skill.description}</description>`);
lines.push(` <location>${skill.filePath}</location>`);
lines.push(` </skill>`);
}
return lines.join("\n");
}
c.人话解释：
技能系统的工作流程：
启动时：Pi扫描指定目录下的所有SKILL.md文件
系统提示词中：只告诉AI有哪些技能（名称+描述），不包含详细内容
AI按需加载：当任务匹配技能描述时，AI用read工具读取完整的SKILL.md
SKILL.md内容：包含具体操作步骤、脚本命令、示例等
d.一个典型的SKILL.md
---
name: pdf-processing
description: Extracts text and tables from PDF files. Use when working with PDF documents.
---
# PDF Processing
## Setup
Run once before first use:
bash
cd /path/to/pdf-processing && npm install
e.Usage
./extract-text.js <input.pdf> # Extract text
./extract-tables.js <input.pdf> # Extract tables
-------------------------------------------------------------------------------------------------
热重载原理：
Skill就是Markdown文件。当AI读取它时，内容立即进入上下文。**没有注册过程，没有重启需求**——这就是"编写即用，修改即生效"。
-------------------------------------------------------------------------------------------------
可迁移经验：
使用"渐进式披露"：只把必要信息放系统提示词，详细内容按需加载
文档即代码：用Markdown写"能力"，而不是写代码
让AI自己找工具：告诉AI"有什么"，让它自己决定"用什么"
e.实时干预：转向队列机制
a.说明
这是Pi最独特的功能之一
b.在 `packages/agent/src/agent.ts` 中
export class Agent {
private steeringQueue: AgentMessage[] = []; // 转向队列
private followUpQueue: AgentMessage[] = []; // 后续队列
/**
* 发送转向消息：中断当前执行
* 在当前工具执行完成后立即处理，跳过剩余工具
*/
steer(m: AgentMessage) {
this.steeringQueue.push(m);
}
/**
* 发送后续消息：在当前轮次完全结束后处理
*/
followUp(m: AgentMessage) {
this.followUpQueue.push(m);
}
}
c.在 agent-loop.ts 中的实际使用
async function executeToolCalls(...) {
for (let index = 0; index < toolCalls.length; index++) {
const toolCall = toolCalls[index];
// 执行工具...
const result = await tool.execute(...);
// 关键：每个工具执行后检查转向消息
if (getSteeringMessages) {
const steering = await getSteeringMessages();
if (steering.length > 0) {
steeringMessages = steering;
// 跳过剩余工具调用
const remainingCalls = toolCalls.slice(index + 1);
for (const skipped of remainingCalls) {
results.push(skipToolCall(skipped, stream));
}
break;
}
}
}
return { toolResults: results, steeringMessages };
}
d.人话解释
想象你在和AI对话，AI正在执行一系列操作：
正常情况：AI调用工具A → 调用工具B → 调用工具C → 完成任务
发现问题：你看到AI走错方向了
你发送消息："等等，不要用那个方法"
Pi的处理：如果消息进入转向队列(steer)：当前工具执行完后，立即处理你的消息，跳过剩余工具
如果消息进入**后续队列(followUp)**：等AI这一轮完全结束后再处理
-------------------------------------------------------------------------------------------------
这就像开车时的"转向"和"下一站"的区别。
可迁移经验：
给用户"干预权"：允许在AI执行中实时纠正
区分"紧急"和"非紧急"：设计不同的队列机制
优雅中断：不要强制终止，而是让当前操作完成后自然过渡
f."代码即真理"：没有外部记忆
a.说明
Pi明确拒绝向量数据库、记忆银行等外部记忆系统
b.compaction/compaction.ts 中的上下文管理
export interface CompactionSettings {
enabled: boolean;
reserveTokens: number; // 预留token数（默认16384）
keepRecentTokens: number; // 保留最近对话token数（默认20000）
}
// 当上下文窗口快满时，压缩历史
export function shouldCompact(contextTokens: number, contextWindow: number, settings: CompactionSettings): boolean {
return contextTokens > contextWindow - settings.reserveTokens;
}
// 压缩策略：保留最近N个token的对话，更早的用LLM总结
export function findCutPoint(
entries: SessionEntry[],
startIndex: number,
endIndex: number,
keepRecentTokens: number,
): CutPointResult {
// 从最新消息开始，向前累积token
// 当超过keepRecentTokens时，在那个点"切断"
// 更早的内容会被LLM总结成摘要
}
c.人话解释：Pi的"记忆"策略很简单
优先用真实代码：AI直接用read/grep读取项目文件，而不是依赖可能过时的摘要
对话历史管理：当上下文快满时，把太旧的对话压缩成摘要
摘要格式：保留目标、约束、进度、关键决策、下一步——结构化信息，而不是向量嵌入
-------------------------------------------------------------------------------------------------
可迁移经验：
结构化摘要优于向量检索：用LLM生成"人类可读"的摘要，而不是不可解释的嵌入
源码即真相：让AI直接读文件，而不是依赖可能过期的"记忆"
渐进压缩：保留最近完整对话，旧的只保留摘要
03.常用信息3
a.值得程序员关注的AI Agent系统新信号
a.系统核心特征
a.代码体量
仅3500行纯Python代码，由8个文件、26个工具构成完整系统
b.技术依赖
无重型框架依赖，核心基于Python标准库+少量轻量依赖实现
c.运行能力
可支撑7×24小时生产级运行，具备实际业务落地价值
b.核心功能配置
a.高频能力内置
涵盖网页搜索、视频处理、企业微信集成、多模态解析等实用功能
b.记忆机制设计
搭建三层记忆机制，结合向量检索解决长期记忆留存问题
c.扩展能力支持
可接入MCP协议，实现与外部服务的扩展对接
c.学习价值分析
a.核心优势
将Agent系统从复杂框架中剥离，回归可理解、可拆解、可学习的状态
b.学习视角
能清晰观察Agent调度工具、管理记忆、持续运行、接入生产环境的底层逻辑
c.学习建议
适合拆解研究，帮助摆脱"仅会调用框架，不懂Agent本质"的认知局限
d.核心观点
最具价值的学习材料是简洁、克制、直接的实现，而非庞大复杂的系统
b.AI时代留给人类最持久的机会是什么
a.AI能力瓶颈的转移
LLM能力已从供给侧转向需求侧，核心问题不再是模型能不能做，而是人类能否把需求表达为可执行契约。
b.spec驱动范式的内在矛盾
能精准描述需求的人，往往已能自行解决大部分问题；而需要AI的人，恰恰因不理解问题而无法写出规范spec，形成认识论悖论。
c.短期人类机会：需求翻译者
在模糊需求的人与需要精确指令的AI之间，存在巨大翻译市场，能将困惑转化为可执行AI指令的人价值提升。
d.矛盾的真正解法：迭代式需求发现
spec并非必须提前写好，可在对话交互中逐步涌现，LLM既是执行者也是需求催化剂，通过多轮对话收敛出隐式spec。
e.现有范式的局限与突破
传统BDD是线性流程，而未来是对话式契约协商，人与AI共同搞清楚需求，agent-spec正在挑战前置spec假设。
f.人类机会的有效期
需求翻译与收敛能力在3-5年内会被模型自动化，该机会仅短期存在。
g.AI时代人类最持久的机会
不是写spec的能力，而是判断什么值得做、什么spec值得写的判断力，这种价值判断与直觉先于spec存在，无法被自动化。
c.真正决定Agent上限的是Harness
a.核心概念
近期AI编程圈出现关键热词HarnessEngineering（智能体外壳工程），正在改变构建智能体的思路。
b.AI Agent发展三阶段
a.PromptEngineering（提示词工程）
早期认为模型就是产品，核心是优化提示词，通过精准巧妙的提示词提升模型输出准确性。
b.ContextEngineering（上下文工程）
2025年兴起，意识到模型输出受整体信息环境制约，将上下文视作整体系统设计，关注信息组织方式、加载顺序和优先级，影响复杂任务表现。
c.HarnessEngineering（智能体外壳工程）
2026年升级概念，强调模型只是大脑，运行环境即Harness决定产品价值。
c.Harness定义与组成
a.定义
Harness是模型的操作系统和行为约束系统，负责模型在生产环境中的运行管理。
b.核心组成
工具调度：控制模型使用工具的时机与类型；上下文管理：按需加载与压缩上下文，聚焦关键任务；记忆持久化：保留跨会话或项目的策略与经验；
安全与审批：防止误删数据、破坏环境等危险操作；结果验证：检测并纠正输出错误；
生命周期钩子：自动执行任务、触发规则与验证；任务拆分与自动化调度：分解复杂任务给不同角色模型，提升效率与可靠性。
d.Harness与Scaffolding的区别
a.Scaffolding（脚手架）
负责系统初始化，包含系统提示词拼装、工具注册、子智能体加载，保障冷启动顺利。
b.Harness
负责运行时管理，包含上下文裁剪、任务分配、安全控制、长期记忆、审批与验证，保障长会话与复杂项目中模型稳定可靠。
c.区分意义
冷启动优化与长会话稳定是不同问题，混合处理易导致模型表现漂移、关键操作出错。
e.重要性与真实案例
多起智能体事故中模型能力足够，因缺少Harness，无权限边界、审批流与验证机制，引发生产数据库误删等严重问题，
证明问题在于系统设计，无Harness的模型存在极大风险。
f.Harness工程核心原则
少即是多：指令精简清晰，关键上下文精准；渐进披露：信息按需加载，避免上下文过载；确定性约束优先于概率性建议：
通过Hooks与验证保障关键操作无误；分工明确：拆分复杂认知功能给不同模型角色，管理上下文预算；文档到技能再到Hook：
经验积累使文档固化为技能，最终转化为自动执行的Hook。
g.行业价值与未来趋势
a.核心结论
Prompt时代优化单句指令，Context时代优化信息环境，Harness时代优化智能体整体生存系统。
b.竞争力核心
模型趋于同质化，真正竞争力在于为模型搭建的运行环境，相同模型与任务，不同Harness会产生不同产品与产出。
c.未来团队能力
AI团队核心能力将转向系统设计、规则书写、流程架构与执行机制构建，构建可控、可验证、
可复用的操作环境是决定智能体上限的关键，Harness是AI时代团队的核心竞争力与护城河。
d.LangChain创始人谈AI重塑EPD团队
a.引一个反直觉的洞察
LangChain创始人Harrison Chase最新深度思考：当代码变得极其便宜，工程、产品、设计的角色边界正在消失。昨
天，LangChain创始人Harrison Chase在Twitter上发表了一篇引发行业热议的思考。
作为构建了最流行AI应用开发框架的人，他对"AI如何改变软件开发"这个话题有着独特的视角。
但这次，他没有谈技术架构，没有谈Agent设计，而是抛出了一个更本质的问题：
当Coding Agent让写代码变得极其便宜，EPD（工程、产品、设计）团队的角色边界正在发生什么变化？
这篇文章，我来帮你拆解他的核心观点，并聊聊这对我们每个人的意义。
b."PRD 已死"的真相
a.传统EPD工作流的消亡
Harrison首先回顾了过去几十年软件行业的标准协作模式：传统流程（Pre-Claude时代）：
产品想法 → PRD文档 → 设计Mock → 工程实现 → 上线。这个流程的形成有其历史必然性：
写代码很贵 - 需要专业工程师花费大量时间；设计Mock很贵 - 需要设计师用专业工具制作；
沟通成本高 - 不同角色之间需要PRD作为"契约"。于是，专业化分工成为最优解。每个人深耕自己的领域，通过文档和流程来协作。
b.但Coding Agent改变了一切
Harrison的核心论点是："PRDs are dead"真正的意思是：以PRD为起点的传统软件开发流程已经消亡。
为什么？因为Coding Agent可以让任何人快速将想法变成功能性代码。当实现成本趋近于零时，还需要先写一份详尽的PRD吗？
但等等，PRD真的死了吗？Harrison话锋一转："Long live PRDs" - 需求文档的本质依然至关重要。
关键在于形式的演变：传统PRD是实现前的"契约"、冗长的格式文档、启动流程的钥匙、静态、版本固化；
未来PRD是实现后的"说明"、结构化的Prompt、辅助Review的工具、动态、可执行。
他甚至提出了一个有趣的设想：未来的PRD可能就是结构化的、版本化的Prompts。
想想看，当你用Cursor/Claude完成一个功能后，把当时的Prompt整理好，这不就是最好的"实现意图说明"吗？
c.瓶颈转移：从实现到Review
a.代码民主化的副作用
Harrison指出了一个被很多人忽视的问题：任何人都能写代码，不代表任何人都能写出好代码。
当Coding Agent让实现变得极其容易时，会发生什么？原型数量爆炸 - 每个人都可以快速做出prototype；
质量参差不齐 - 架构、性能、用户体验可能都很糟糕；Review成为瓶颈 - 需要专业的人来判断"好不好"。
b.EPD的新角色：Reviewer & Arbitrator
传统的EPD角色定义：Engineering - 写代码的人；Product - 定义需求的人；
Design - 设计体验的人。未来的EPD角色定义：Engineering - 审查代码架构是否可扩展、性能是否达标、系统是否健壮；
Product - 审查功能是否真正解决用户痛点；Design - 审查界面是否直观易用。从"生产者"变成"审查者"，这是角色定位的根本性转变。
c.一个现实困境
Harrison提到一个很现实的观察：以前作为Reviewer，你同时只需要处理几个项目。
现在任何人都能写代码，意味着并行的项目数量在爆炸式增长。瓶颈从"实现能力"转移到了"Review能力"。
这对团队管理意味着什么？需要更高效的Review流程；需要更清晰的Review标准；需要更合理的资源分配。
d.通才的春天来了
a.为什么Generalists更值钱？
Harrison对"通才"的定义很清晰：指那些同时具备产品、工程、设计三方面良好判断力的人。
这类人以前就很值钱，但现在更值钱。原因很简单：沟通是最难的事情。
一个能同时胜任产品、设计、工程的人，比三人团队更快——因为消除了沟通开销。
想象一下这个场景：传统模式：PM写PRD → 等Design排期 → 等Engineering排期 → 反复沟通 → 上线，周期：2-4周；
通才 + Coding Agent模式：想法 → Prompt → 原型 → 迭代 → 上线，周期：1-2天。这就是10倍速的差异。
b.专业化的门槛变高了
Harrison还指出了一个残酷的现实：You're either a builder or a reviewer.
在Coding Agent时代：不会用Agent的工程师 - 价值被大幅稀释；只会写简单CRUD的工程师 - 容易被替代；
能架构复杂系统 + Review代码质量 - 依然稀缺。专业化的门槛被抬高了。以前你可能凭一项技能就能立足，
现在你需要：会用Coding Agent（基础要求）；有超越Agent的判断力（核心竞争力）；能Review和指导Agent产出（新能力）。
e.每个人都需要的产品感
a.Product Sense成为通用能力
Harrison特别强调了一点：Everyone needs product sense. 为什么？
因为当实现成本降低后，决定一个功能价值的不再是"能不能做"，而是"该不该做"。
传统模式下：工程师可以只关注"怎么实现"；产品经理负责判断"做什么"。
Agent时代：每个人都能快速实现想法；每个人都需要判断"这个功能有没有价值"。
产品感不再是PM的专属能力，而是每个builder的必备素养。
b.好PM和差PM的差距更大了
Harrison说了一句很犀利的话：Good PMs are great, bad PMs are terrible.
在资源稀缺时代，差一点的PM也能活，因为实现本身就是壁垒。但在实现泛滥时代，
判断力的价值被放大了：好PM能精准识别高价值需求，避免团队浪费时间在垃圾功能上；
差PM会让团队陷入"做了很多，但都没用"的困境。而由于实现成本降低，差PM造成的浪费会更严重——因为大家会更容易"先做了再说"。
f.Coding Agents不是选择题
a.一个残酷的现实
Harrison最后总结道：Everyone thinks their role is most advantaged by coding agents - and they are right.
工程师觉得Agent让自己效率翻倍 ✓；产品经理觉得Agent让自己能直接验证想法 ✓；
设计师觉得Agent让自己能快速prototyping ✓。每个人都对，因为Coding Agent不是零和博弈。
但关键在于：Coding agents are a requirement. 这不是"用不用"的选择题，而是"会不会被淘汰"的生存题。
b.一个灵魂拷问
如果你现在还在：手写所有CRUD代码；手动写重复的单元测试；不用AI辅助做代码Review；
拒绝学习Prompt Engineering。那么，你正在被时代抛弃。
g.给中国开发者的启示
a.我们处于什么位置？
Harrison的思考虽然基于美国科技行业，但对中国开发者同样适用。甚至，我们可能面临更剧烈的变化：
工程师红利正在消失 - 人力成本优势不再；内卷严重 - 大家都在拼加班，而不是拼效率；AI渗透率低 - 很多团队还没开始用Coding Agent。
b.三个建议
基于Harrison的观点，笔者建议：
1.立刻开始用Coding Agent：Cursor、Claude Code、GitHub Copilot，
选一个开始用；不要等"有时间再学"，现在就用；从简单任务开始，逐步建立信任。
2.培养Review能力：学会判断AI生成的代码质量；学会设计可扩展的系统架构；学会从用户视角审视产品价值。
3.成为通才：不要只满足于"会写代码"；学习产品思维，理解业务逻辑；学习设计基础，提升用户体验感。
h.结语：变化中的不变
Harrison的这篇思考，表面上是在说"变化"，但本质上是在说"不变"：软件行业的核心目标从未改变
创造能解决用户问题的好产品。变化的只是手段：以前靠专业化分工；
现在靠AI增强 + 通才协作；以前瓶颈在实现；现在瓶颈在判断；以前PRD是起点；现在PRD是伴随品。
最后，用一句话总结Harrison的核心观点：当代码变得极其便宜，真正的壁垒是判断力。而这个判断力，来自你对产品、技术、设计的综合理解，共勉。
e.HarnessEngineering的关键模块记忆层
a.基础概念
a.来源与公式
原始来源为Memory as a Harness Turning Execution Into Learning，Harness Engineering即驾驭工程，核心公式为Agent等于模型加Harness，模型提供智能，Harness提供框架，记忆层是Harness中最重要的模块
b.核心定位
记忆层相当于Agent的海马体，负责把交互经验、反馈、模式转化为长期知识，让Agent实现持续成长，摆脱记吃不记打的问题
c.类比说明
Harness类似赛车的安全带，不提供动力，但保障模型算力稳定发挥，实现可靠运行
b.记忆层的必要性
a.现有痛点
模型变强但Agent重复犯错，上下文窗口变大但依然遗忘信息，多Agent协作知识碎片化且相互冲突
b.问题根源
不在于模型智商不足，而是缺少成熟的记忆系统，普通Agent属于一次性工具，无法沉淀经验持续进化
c.核心架构
Agent分为模型和Harness两部分，模型负责智能，Harness负责靠谱，记忆层决定Agent能否持续成长
c.记忆层需要解决的三大核心问题
a.持续学习
a.定义
判断Agent能否从错误和交互中吸取经验，区分存储数据和学会知识
b.现存问题
大量系统形成数据坟场，数据越多Agent越笨，无法判断信息留存合并和遗忘规则，只会堆积无效数据
b.上下文工程
a.认知误区
更大的上下文窗口无法替代记忆层，不能解决本质问题
b.三类问题
上下文污染即无用信息干扰模型输出，上下文混乱即信息过多无法聚焦，上下文分心即关键信息被淹没导致重复犯错
c.解决难点
单纯压缩无法解决问题，需要理解系统感知交互判断信息价值，依赖结构化记忆层
c.多Agent协作
a.衍生风险
多个Agent各自产生输出记录步骤和假设，混杂存放只会造成信息混乱，无法形成共享大脑
b.核心挑战
合并不同Agent的局部认知，控制噪音扩散实现知识互通
d.记忆系统的核心能力把执行变为学习
a.传统记忆与学习型记忆对比
传统记忆存储所有交互原样检索知识容易过时数据越多速度越慢
学习型记忆筛选有效信息合并更新知识沉淀经验数据越多智能越高
b.四大关键动作
过滤判断信息价值合并融合新旧知识解决冲突处理矛盾信号沉淀转化为复用经验
c.cognee落地方式
通过memify封装能力调用新增交互触发沉淀检索结构化知识简化工程落地
e.主流行业项目对比
项目 Star数 核心定位 差异化特点
mem0 50K加 通用记忆层 适配多类LLM框架易于集成
Letta 21K加 有状态Agent平台 Agent自主学习迭代
cognee 14K加 知识引擎 图加向量混合依托知识图谱
HippoRAG3K加 神经启发式RAG模拟人类长期记忆机制
f.核心观点与结语
a.底层逻辑
原始数据没有价值关键在于结构化关联更新和复用能力记忆层是Agent的核心壁垒区别普通工具和智能伙伴
b.现存局限性
技术方案尚未统一存在知识冲突遗忘隐私等待解问题需要大量业务工程落地
c.发展趋势
无记忆仅为工具有记忆才可进化补齐AI进化短板实现复利式成长
04.常用信息4
a.Karpathy最新的干货输出：能够进化的知识库
a.背景介绍
a.原文来源
原文来自 Andrej Karpathy 的X分享。
b.核心理念
我用 LLM 搭建了一个自我进化的知识库。
b.一个转变：从写代码到管理知识
a.发现的变化
最近我发现一个有趣的变化：我的 token 消耗，从操作代码越来越多地转向操作知识。
b.新的工作流
不是让 LLM 帮我写代码，而是让它帮我整理、连接、检索知识。这种方式比传统的笔记软件更高效——因为我不需要自己写。
c.核心架构：LLM 编译的知识库
a.系统构成
整个系统可以分为五个模块：数据摄入 → 编译成 Wiki → Q&A 检索 → 输出生成 → 健康检查。每个环节都由 LLM 驱动，我几乎不手动编辑 Wiki。
b.1.数据摄入
a.数据来源
我把所有原始资料放进 raw/ 目录：文章、论文、代码仓库、数据集、图片。
b.数据转换
然后用一个工具把它们转成 .md 文件。
我常用的是 Obsidian Web Clipper 扩展——可以把网页文章一键保存为 Markdown，顺便下载所有相关图片到本地。
c.转换目的
这样 LLM 就能轻松引用这些图片。
c.2.编译成 Wiki
a.核心功能
这一步是核心。LLM 会「编译」raw/ 目录，
生成一个结构化的 Wiki：所有数据的摘要、反向链接（backlinks）、概念分类、概念文章、文章间的链接。
b.组织形式
Wiki 本质上就是一个 .md 文件集合，按目录结构组织。
c.维护方式
关键点：Wiki 由 LLM 写入和维护，我很少直接编辑。
d.3.前端：Obsidian
a.使用方式
我使用 Obsidian 作为「IDE」：查看 raw 数据、查看编译后的 Wiki、查看生成的可视化。
b.插件生态
Obsidian 的插件生态很有用：Marp：把 Markdown 转成幻灯片；各种图表插件：数据可视化。
e.4.Q&A 检索
a.应用场景
当 Wiki 足够大时（比如我最近的一个研究项目有 ~100 篇文章，~40 万字），就可以对它提问了。
b.工作原理
LLM 会：自动维护索引文件、维护所有文档的简短摘要、阅读相关数据并回答问题。
c.效能发现
一个发现：我以为需要复杂的 RAG 系统，但实际上，LLM 在这个规模（~40 万字）下表现很好，能自动找到相关文档。
f.5.输出生成
a.输出形式
回答不只是文本，而是各种格式：Markdown 文件、幻灯片（Marp 格式）、Matplotlib 图表。
b.查看方式
这些都用 Obsidian 查看。
c.知识累积
更有意思的是，我经常把输出「归档」回 Wiki，让它越来越完善。我的探索和提问，总是会「累积」在知识库里。
g.6.健康检查
a.维护功能
LLM 可以对 Wiki 做「linting」：发现不一致的数据、补充缺失数据（通过网页搜索）、发现有趣的连接，建议新文章、清理和增强数据完整性。
b.功能建议
LLM 还擅长建议「下一步该问什么问题」。
h.7.额外工具
a.工具开发
我开发了一些小工具来处理数据：一个简单的搜索引擎（Web UI + CLI）。CLI 版本可以交给 LLM 作为工具使用。
i.8.未来方向
a.发展规划
当 Wiki 越来越大，自然的想法是：合成数据生成 + 微调，让 LLM 把这些知识「记住」在权重里，而不仅仅是上下文窗口。
d.完整工作流
a.步骤总结
总结一下：1. 收集数据 → raw/ 目录 2. LLM 编译 → Wiki（.md 文件集合）3. Obsidian 查看
4. CLI 工具操作（Q&A、增强 Wiki）5. 输出归档回 Wiki 6. 定期健康检查。
b.核心理念
我几乎不手动写或编辑 Wiki——那是 LLM 的领域。
e.为什么这个方法有效
a.1.知识不再碎片化
传统笔记的问题：写了就忘了，很难检索，没有连接。这个方法：所有知识都被「编译」进一个连接的网络。
b.2.检索成本极低
不需要复杂的标签系统、不需要精心设计的目录结构。直接问 LLM，它会找到相关内容。
c.3.知识会「生长」
每次提问、每次探索，都会沉淀回 Wiki。你的知识库不是静态的，而是随着使用越来越丰富。
d.4.减少手动操作
我不擅长整理笔记。但 LLM 擅长。让它做它擅长的事。
f.实现细节
a.准备工作
如果你想自己搭建，需要：工具栈（Obsidian（前端）、Obsidian Web Clipper（网页保存）、
一个 LLM（Claude、GPT、本地模型都可以）、一些 Python 脚本（或让 LLM 写））和目录结构。
b.目录结构
---
knowledge-base/
├── raw/ # 原始数据
│ ├── articles/
│ ├── papers/
│ ├── images/
│ └── repos/
├── wiki/ # 编译后的 Wiki
│ ├── concepts/
│ ├── articles/
│ └── index.md
├── tools/ # CLI 工具
└── outputs/ # 生成的输出
---
c.关键 Prompt
a.让 LLM 编译 Wiki 的核心提示
你是一个知识编译器。阅读 raw/ 目录中的所有文档，生成一个结构化的 Wiki，
包括：1. 每篇文档的摘要 2. 概念提取和分类 3. 文章间的链接 4. 反向链接索引
b.让 LLM 回答问题的核心提示
你有一个 Wiki 知识库。用户会问你问题。
请：1. 阅读索引文件了解 Wiki 结构 2. 找到相关文档 3. 综合回答 4. 如果需要，生成 Markdown 文件或图表
g.局限性
a.规模限制
当 Wiki 超过某个规模，简单的索引可能不够，需要更复杂的 RAG。
b.LLM 成本
频繁调用 LLM 会产生 token 成本。
c.工具依赖
需要一些脚本和工具链。
d.学习曲线
需要时间调优工作流。
h.未来可能
a.产品愿景
原作者说了一句我很认同的话：
I think there is room here for an incredible new product instead of a hacky collection of scripts.
b.最终结论
是的，这里有巨大的产品空间。一个LLM 原生的知识管理工具，不是AI 增强的笔记软件，而是从零开始设计的知识编译引擎。
b.多智能体系统到底如何设计，来看看Claude的思考
a.引言
多数人一看到复杂任务，本能反应就是"上多智能体"。
这个本能往往是错的。正确的问法不是"要不要用多智能体"，
而是"这个任务到底需要什么类型的协调"。答案决定了你的整个架构。
Claude给了两条截然不同的路：子智能体和智能体团队。表面看着像，架构上解决的是完全不同的问题。
b.两条路的核心区别
a.一句话分清
子智能体：你派三个研究员分头查资料，他们各自干完回来汇报，你汇总成报告。
智能体团队：你组了一个项目组，前端、后端、测试坐一个屋，随时沟通，互相配合。前者是"派活收结果"，后者是"组队打配合"。
b.对比表格
维度 子智能体 智能体团队
生命周期 干完就消失 持续存在
通信方式 只和父智能体通信 队友间直接通信
状态管理 无共享状态 共享任务列表
适用场景 独立任务并行 需要协商的协作
c.选择依据
用子智能体：任务是"尴尬并行"的——独立的研究流、代码库探索、查询，父智能体只需要摘要。
用智能体团队：任务需要持续协商——智能体需要在推进前协调输出，或者一个线程的发现会改变另一个线程该做什么。
c.子智能体：隔离带来的并行
a.定义
子智能体是一个在独立上下文窗口中运行的专用Claude实例。研究负责人不会亲自读每份原始资料。
他派具体问题给研究员，研究员带着提炼好的发现回来，他综合成最终输出。这就是子智能体做的事。
b.每个子智能体获得的内容
自己的系统提示词，定义专业领域。特定的工具集。干净的隔离上下文窗口。一个明确的任务。
c.核心价值
子智能体的核心价值不只是并行，而是压缩。你把大量探索蒸馏成干净的信号，不让噪音污染父智能体的上下文。
完成后，只有最终结果返回给父智能体。父智能体拿到的是压缩后的输出，完整推理链和中间步骤都留在子智能体里。
d.硬约束
子智能体不能派生子智能体，也不能互相通信。所有结果都流回父智能体。父智能体是唯一的协调者。
这个约束让系统可预测。你永远知道信息流向哪里、决策在哪里做出。
e.代码示例
---
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
async def main():
async for message in query(
prompt="Review the authentication module for security vulnerabilities",
options=ClaudeAgentOptions(
allowed_tools=["Read", "Grep", "Glob", "Agent"],
agents={
"security-reviewer": AgentDefinition(
description="Security specialist. Use for vulnerability checks.",
prompt="You are a security specialist...",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
"performance-optimizer": AgentDefinition(
description="Performance specialist. Use for latency issues.",
prompt="You are a performance engineer...",
tools=["Read", "Grep", "Glob"],
model="sonnet",
),
},
),
):
print(message)
---
f.description字段的作用
description字段告诉父智能体该派发给谁。上面这个例子，提示词提到"security vulnerabilities"，
父智能体就派给security-reviewer，不是performance-optimizer。如果问的是延迟或瓶颈，就会选另一个。description是路由信号，要写得具体。
d.智能体团队：通信带来的协调
a.定义
子智能体是干完活就消失的短期工人，智能体团队是长期运行的实例，持续存在，直接互相通信，通过共享状态协调。
区别就像：雇承包商干孤立任务 vs 组一个团队在同一个房间协作。
b.三个组成部分
团队负责人：协调工作、分配任务、综合结果。队友：独立的智能体实例，各有自己的上下文窗口，并行工作。
共享任务列表：追踪待办、进行中、已完成，以及任务之间的依赖关系。
c.典型生命周期
---
Claude (Team Lead):
└── spawnTeam("auth-feature")
Phase 1 - Planning:
└── spawn("architect", prompt="Design OAuth flow", plan_mode=true)
Phase 2 - Implementation (parallel):
└── spawn("backend-dev", prompt="Implement OAuth controller")
└── spawn("frontend-dev", prompt="Build login UI")
└── spawn("test-writer", prompt="Write tests", blockedBy=["backend-dev"])
---
d.协调机制
注意test-writer的blockedBy字段。这就是共享任务列表在做真正的协调：测试工程师不会在后端完成前启动，负责人不需要手动管理这个顺序。
e.与子智能体的最大区别
和子智能体最大的区别是直接点对点通信。队友可以互相发消息、分享发现、暴露阻塞、协商，不需要所有东西都经过负责人。
你也可以直接和单个队友交互，不是所有事情都必须通过负责人。
e.从第一性原理设计智能体系统
a.常见错误
大多数多智能体设计失败，因为人们按角色分工，忽略了上下文分工。直觉本能是按角色拆：规划者、实现者、测试者。感觉很整齐。
但它创造了一个"传话游戏"，信息在每个交接点衰减。实现者不知道规划者知道什么。测试者不知道实现者做了什么决定。质量在每个边界下降。
b.正确的心智模型
正确的心智模型是以上下文为中心的分解。问：这个子任务真正需要什么上下文？
如果两个子任务需要深度重叠的信息，它们可能属于同一个智能体。如果它们可以用真正隔离的信息和干净的接口操作，那就是拆分的地方。
c.实践建议
实现功能的智能体应该同时写那个功能的测试。它已经有上下文了。把这两件事拆成两个智能体，交接成本比并行收益更大。
只有当上下文可以真正隔离时，才分开。
f.五种编排模式
a.提示链
顺序步骤，每个调用处理上一个输出。顺序重要、步骤依赖时用。
b.路由
分类器决定哪个专门处理器接任务。简单问题走便宜快速模型，难题走更强模型。这是控制成本的关键。
c.并行化
独立子任务同时运行。要么同一任务跑多次获得多样输出（投票），要么不同子任务同时跑（分段）。
d.协调者-执行者
中心智能体拆分任务、派发给执行者、综合结果。这是子智能体和智能体团队的主导架构，也是大多数生产系统实际用的。
e.评估者-优化者
一个智能体生成，另一个评估并反馈，循环迭代。质量比速度重要、单次通过不够可靠时用。
g.什么时候不该用多智能体
a.从简单开始
团队花了数月搭建复杂的多智能体流水线，最后发现：单个智能体配合更好的提示词，效果一样。从简单开始。
只有当你能清楚衡量需要时，才加复杂度。
b.值得用的情况
上下文保护：子任务生成与主任务无关的信息，放在子智能体里防止上下文膨胀。真正并行：独立研究或搜索任务，
同时覆盖有收益。专业化：任务需要冲突的系统提示词，或者一个智能体工具太多导致性能下降。
c.不该用的情况
智能体之间频繁需要共享上下文。智能体间依赖产生的开销比执行价值还大。任务简单到单个好提示词就能搞定。
d.编码的坑
并行智能体写代码会做出不兼容的假设。合并时，那些隐式决定会以难以调试的方式冲突。
编码的子智能体应该回答问题和探索，不要和主智能体同时写代码。
h.多智能体系统怎么失败
a.任务描述模糊导致智能体重复工作
每个智能体需要：明确目标、预期输出格式、用什么工具或来源、明确边界（不覆盖什么）。没有这些，两个智能体会研究同一件事，谁也不会发现。
b.验证智能体没验证就宣布成功
明确、具体的指令不可妥协：运行完整测试套件、覆盖这些具体用例、每个通过前不要标记完成。模糊的验收标准产生假阳性。
c.Token成本比你预期增长得更快
解决方案是智能分层：真正重要的地方用最强模型。常规工作路由到更快更便宜的模型。内置预算控制，防止成本失控。
i.设计原则
围绕上下文边界设计，不是围绕角色或组织架构。从单个智能体开始。推到它崩溃。那个失败点告诉你下一步该加什么。只在解决真实、可衡量问题的地方加复杂度。
c.Karpathy新提出LLM Wiki：可能将彻底颠覆RAG知识库
a.说明
a.背景与反响
Andrej Karpathy在GitHub Gist上发布了一份关于进化知识库的文档，不到48小时star数突破5000，fork数超过1100。
文档阐述了一个清晰且令人震撼的解决方案。
b.RAG的困境
目前大多数LLM体验（如ChatGPT上传文件、NotebookLM）都在做同样的事：每次从零开始检索，没有积累。这就像每次做菜都重新去菜市场买菜，虽然有用但效率极低。
b.Karpathy的答案：LLM Wiki
a.核心思想
让LLM增量构建和维护一个持久的wiki，而不是每次从原始文档重新检索。知识被“编译”一次，然后持续更新。
[此处显示Wiki复利增长示意图]
b.三层架构
a.第一层：Raw Sources（原始文档）
文档集合（文章、论文、图片）是只读的，作为source of truth，LLM只读取不修改。
b.第二层：The Wiki（LLM生成的知识库）
LLM完全拥有的目录，包含生成的Markdown文件（摘要页、实体页、概念页）。LLM负责创建、更新、维护交叉引用。
c.第三层：The Schema（配置文档）
告诉LLM如何组织wiki的文档（如CLAUDE.md），由用户和LLM共同维护的“建筑图纸”。
c.三个核心操作
a.1.Ingest（摄入）
处理新来源的流程：LLM读取内容、讨论关键点、写摘要页、更新index、更新相关实体页、在log追加记录。一个来源可能触及10-15个页面。
Karpathy偏好逐个摄入以保持参与感。
b.2.Query（查询）
LLM搜索相关页面并综合答案。关键洞察是：好的答案可以回填进wiki作为新页面，让探索也在知识库里复利。
c.3.Lint（检查）
定期让LLM给wiki做体检，检查矛盾、过时声明、孤儿页面、缺失概念和交叉引用，并建议新问题或新来源。
d.两个特殊文件
a.index.md
内容目录，包含链接、摘要和元数据。LLM每次摄入都会更新。查询时先读index找到相关页面。在中等规模（约100个来源）下出奇好用，不需要embedding基础设施。
b.log.md
时间日志，记录摄入、查询和检查。每条记录以[日期]开头，可用Unix工具解析。
c.深度解析
a.为什么这能工作
维护知识库最累的部分是记账（更新交叉引用、保持一致性），这导致维护负担增长快于价值，人类最终放弃。LLM不会无聊也不会忘记，维护成本接近零，解决了这个问题。
b.与Memex的精神连接
这个想法与Vannevar Bush 1945年的Memex一脉相承，强调私有的、主动策划的知识存储。Bush未能解决的维护问题，现在由LLM解决了。
d.社区与展望
a.评论区的宝藏
a.OpenClaw Skill
@john-ver将其做成了OpenClaw skill，可通过对话构建wiki。
b.Reflect步骤
@bendetro建议增加reflect步骤，记录决策背后的“为什么”，使决策记录成为一等公民。
c.混合搜索实现
@Paul-Kyle使用git-versioned markdown作为source of truth，结合BM25和vector via SQLite-vec。
d.Sage-wiki经验
@xoai指出编译器是pipeline而非prompt，概念去重最难，且每个任务应同时产生答案和文章更新。
b.这意味着什么
这是知识管理的范式转移，从“检索”到“积累”，从“重新推导”到“持续编译”。工具链（Claude Code, Obsidian, MCP）已成熟，
Karpathy将文档设计为“idea file”，供用户直接复制粘贴到Agent中开始构建。
d.为什么你的多智能体系统总失控？四个文件让它乖乖听话
a.引言
每个做多智能体的工程师都经历过这种崩溃时刻：
你搭建了一套看起来很完美的系统——一个研究智能体负责调研，
一个分析智能体负责处理数据，一个写作智能体负责输出内容，还有一个编排智能体负责协调。
测试环境一切正常，演示时团队惊呼"太强了"，推到生产环境48小时内，它开始做一些没人要求的事——分析智能体在写报告，
写作智能体在拉数据，编排智能体直接和用户聊天。技术上一切正常运行，但一切都错了。
我经历过这个时刻，每次的根因都一样：没人告诉这些智能体"你是谁、你能干什么、你在哪、你怎么做事"。
它们很聪明，但没人管。就像招了一群天才顾问，忘了给职位说明。解决方案是什么？四个markdown文件，每个回答一个具体问题。
b.问题出在哪
大多数团队起步的方式相同：给每个智能体写一个巨大的系统提示词，一堵文字墙，描述智能体的性格、工具、规则、角色和输出格式。
开始还行，然后开始出怪问题：智能体忽略一半提示词因为太长了，凭空捏造一条不存在的规则，做的事情单独看没问题，但和下游智能体冲突。
根本问题在于一个系统提示词试图同时回答四个本质不同的问题：这个智能体能干什么？它在系统里是谁？它在整个系统里位置在哪？
它应该怎么一步一步做事？当这四个问题挤在同一个文本块里，智能体会把它们同等对待，更糟的是揉成一团不知所云的东西。解决方案是每个问题一个文件。
c.SKILL.md：培训手册
a.定义
SKILL.md回答一个问题："这个具体的事情怎么干？"你可以把它当成认证文件。你招一个数据工程师，你期望他懂SQL。SKILL.md就是这个知识的证明和参考。
b.示例：网页抓取智能体
a.基本信息
name: web-scraper
description: 用BeautifulSoup和Playwright从网站提取结构化数据。当需要抓取表格、列表或文章时使用。
b.什么时候用这个技能
用户提供URL，想要结构化数据。页面可能是JS渲染的（用Playwright）或静态的（用requests + BS4）。
c.步骤
1. 检查页面是否JS渲染。如果是，用Playwright无头模式
2. 优先用语义选择器：<article>、<table>、role=属性，避免脆弱的CSS路径如.div > span:nth-child(3)
3. 返回pandas DataFrame，保存到/outputs/data.csv
d.错误处理
403或429：添加User-Agent header，加2秒延迟，重试一次。空结果：记录使用的选择器，给用户建议替代方案。
c.要点
这里有真实的代码模式、明确的步骤、失败场景。好的SKILL.md不只描述"晴天场景"，它告诉智能体出问题时该怎么办。
一个能力一个SKILL.md。不要把"抓取"和"数据库查询"捆到一个文件里。保持技能原子化、可复用，其他智能体应该能直接拿起来用。
d.Agent.md：员工工牌
a.定义
Agent.md回答："我是谁，我在系统里什么位置？"这是每个智能体一个的文件。它很短，很少超过30行，因为它不是在教智能体什么，而是在给它定位身份。
b.示例：数据分析智能体
a.我是谁
我是数据分析智能体。我接收数据集和问题，返回结构化的AnalysisResult字典。
b.我在系统里的位置
由谁启动：orchestrator-agent。我交接给：viz-agent和writer-agent。我从不直接和用户沟通。
c.我的能力
Pandas / NumPy分析。通过query_database工具执行SQL查询。异常检测和趋势识别。
d.我不做的事
写报告或文字内容（→ writer-agent）。做图表或可视化（→ viz-agent）。做商业建议（→ 人工审核）。
c.要点
最后一部分"我不做的事"是任何Agent.md最重要的部分。根据我的经验，智能体行为异常几乎都是因为它填补了一个没有明确关闭的空白。
如果不告诉分析智能体它不写报告，它迟早会决定写一篇，因为分析完写报告看起来是自然的下一步。保持Agent.md稳定。
写好后几乎不用改。如果发现频繁修改，说明智能体的角色定义还不清晰，去修系统设计，不是改文件。
e.AGENTS.md：组织架构图
a.定义
如果Agent.md是一个员工的工牌，AGENTS.md就是公司通讯录。它回答："所有智能体是谁？整个系统怎么连接？"
这是一个放在项目根目录的单文件，不在任何智能体的文件夹里。
b.示例
a.智能体清单
orchestrator-agent：接收用户请求，分配任务，协调下游。analyst-agent：数据分析，输出AnalysisResult。
viz-agent：生成图表和可视化。writer-agent：撰写报告和文字内容。
b.数据流
用户 → orchestrator → analyst → viz + writer → orchestrator → 用户
c.接口约定
所有智能体接收dict，返回dict。analyst输出AnalysisResult，包含data、insights、metadata字段。
writer接收AnalysisResult，输出ReportDocument。
c.要点
这带来一个实用的效果：它给每个智能体一个整个系统的心理模型，不只是它们自己那点事。
当分析智能体知道下游有可视化智能体，它会自然开始考虑输出格式。它不再只为自己优化。
把AGENTS.md当成架构图。放在项目根目录，提交到版本控制，增删智能体时更新。新工程师加入项目，读这个文件五分钟就能理解整个系统。
f.INSTRUCTIONS.md：员工手册
a.定义
最后一个文件回答："干活的时候，我应该怎么一步一步做事？"这是四个文件里最操作性的。
SKILL.md说"怎么抓取一个页面"，INSTRUCTIONS.md说"每次任务到达时你按什么顺序执行"。
b.示例
a.核心行为规则
1. 分析前必须验证数据集：任何列超过20%空值？先警告用户再继续。类型与预期schema不匹配？报错——不要猜。
2. 永远不要捏造统计数据：如果计算返回NaN或失败，明确说出来。不要估计，不要凭记忆填数字。
3. 摘要保持简洁，最多三句话：不要废话，避免"值得注意的是……"这种填充词。
b.精确工作流
1. 加载数据集，记录shape和列类型
2. 运行数据质量检查（空值、重复、类型不匹配）
3. 只用代码回答分析问题——不猜
4. 填充AnalysisResult字典
5. 立即交接给下游智能体，不要问用户确认
c.硬约束
永远不读取/mnt/user-data/以外的文件。永远不做外部HTTP调用。分析超过30秒，超时并报告原因。
c.要点
明确的工作流是好INSTRUCTIONS.md和坏INSTRUCTIONS.md的区别。散文式的指令会被宽松解读，编号的步骤会被精确执行。
当你调试一个行为异常的智能体，编号的工作流给你一个准确的定位：它跳过了哪一步？把行为规则和工作流步骤分开。
规则回答"永远/永远不"，工作流回答"先/然后/最后"。混在一起会造成优先级模糊。
g.四个文件怎么配合
涉及到多智能体项目都可以用这个结构。脑中一直回响的类比是：
AGENTS.md是城市地图，Agent.md是你的公寓地址，INSTRUCTIONS.md是你的日常行程，SKILL.md是你的职业培训证书。
城市地图没有公寓地址，大规模下就没用。公寓没有日常行程，会产出混乱。行程没有培训，会产出自信的无能。你需要全部四个。
h.大多数团队跳过的东西
大多数团队写SKILL.md和INSTRUCTIONS.md写得很自然，它们从提示词工程中涌现出来。团队一致跳过的是Agent.md和AGENTS.md，
因为它们感觉像行政工作。"我们知道智能体是谁，"团队会说，"不需要文档化。"但智能体不知道你知道的。
每次新对话开始，每个智能体从零开始。没有Agent.md，你的分析智能体不知道它是分析智能体。
它知道它有pandas工具和一些指令。给足够自由度，它会定义自己的角色，那个角色会是给定任务下最自然的选择。
有时候没问题。有时候你的分析师开始写CEO备忘录。
i.结语
a.核心观点
这套四文件方法论，本质上是在解决一个更深的问题：智能体没有上下文继承能力。人类员工入职第一天，带着之前所有的教育和经验；
智能体每次对话都是第一天上班，什么都要重新交代。这不是框架问题，是架构设计问题。
四个文件不是一个模板，是一种思维模式：把"身份、能力、流程、系统"拆开，每个维度独立演化。
b.补充观察
a.适用场景
这套方法最适合"有明确边界的生产系统"。如果你的智能体在做开放式探索、创意写作、或者边界模糊的任务，过度结构化反而限制它的能力。
结构是为了稳定，稳定有时候是创意的敌人。
b.边界的价值
"我不做的事"是文件里最有价值的一句话。智能体的错误行为，很少是因为能力不足，几乎都是边界不清。
写清楚它不应该干什么，比写清楚它应该干什么更重要。
c.工作量考量
这套方法不会减少你的提示词工作量，但会让它可控。你还是会调试、优化、迭代，
但调试有明确的锚点：SKILL.md有问题就改技能，Agent.md有问题就改角色定义，
INSTRUCTIONS.md有问题就改流程。不再是"改提示词看看会发生什么"。
c.总结
四个文件。一个给系统，一个给身份，一个给行为，一个给技能。就这么简单。调试了三个月智能体混乱后，这是我希望第一天就有人告诉我的东西。
e.Karpathy的Agent使用心法——从"提示词工程师"到"智能调度师"
a.内容概述
Karpathy 最近在 No Priors Podcast 分享的 10 条 Agent 使用心得，笔者觉得非常值得学习。这篇内容没有宏大叙事，全是一个顶级工程师踩过坑后的实战感悟。x上面有大佬总结了一下视频的内容，把最有价值的部分梳理出来。
b.宏观思维：别再盯着代码行了
a.核心理念
Karpathy 提的第一个建议就有点颠覆认知：把 Agent 当作"功能交付单元"，而不是"代码生成器"。传统编程思维是"我写一行代码，它执行一行"。但 Agent 时代的正确姿势是：我描述一个功能，Agent 负责完整实现。
b.实操建议
把屏幕分成多个 Agent 会话，每个负责不同功能。比如一个写 API、一个写测试、一个写文档。你只负责 Review 和整合。
c.出问题先自查：大概率是"技能问题"
a.核心观点
Karpathy 说了一句很扎心的话："当 Agent 没效果时，几乎总是技能问题。"这里的"技能"不是指模型能力，而是你配置 Agent 的技能——你的 Prompt 写得够不够清晰？你的 AGENTS.md 文件有没有告诉 Agent 项目上下文？你的 Memory 工具设置对了没有？
b.实践经验
笔者深有体会。之前让 Agent 帮我改代码，它总是改不到点子上。后来我把项目架构、代码风格、关键模块都写进了一个 AGENTS.md 文件，效果立马提升一个档次。
c.自查清单
a.Prompt是否足够具体
例如："优化代码" vs "把这段代码的时间复杂度从 O(n²) 降到 O(n)"
b.Agent是否了解项目上下文
例如：有没有提供 README、配置文件、关键代码
c.任务是否拆分得当
例如：一个 Agent 干一件事，别让一个 Agent 做全栈
d.去瓶颈化：你不是 Prompt 的"中转站"
a.核心理念
你的目标是让自己从工作流中消失。很多人用 Agent 的方式是：我提问 → Agent 回答 → 我再提问 → Agent 再回答……这样你永远是瓶颈。Karpathy 的建议是：设计完全自主的 Agent 工作流。
b.具体做法
举个例子：与其让 Agent 写完代码等你 Review，不如配置一个"写代码 → 跑测试 → 自动修 bug → 再测试"的循环。你只需要在最后验收成果。
c.模式总结
笔者把这个模式叫"甩手掌柜模式"：输入少量 Token，产出大量工作。
e.肌肉记忆：Agent 编排也是一门手艺
a.技能定义
Karpathy 把 Agent 编排比作"需要刻意练习的技能"。这不是看几篇教程就能学会的。
b.练习要点
a.多窗口管理
学会在屏幕上同时开多个 Agent 窗口。
b.节奏感培养
培养分配任务的节奏感（什么时候并行、什么时候串行）。
c.信任与介入
知道什么时候该信任 Agent、什么时候该介入。
c.进阶建议
笔者的建议：先从简单的并行任务开始练手。比如同时让两个 Agent 分别写前端的两个组件，习惯这种工作节奏后再尝试更复杂的编排。
f.指令文件是可调优的"代码"
a.核心认知
这一条笔者特别认同：你的 AGENTS.md、Prompt 模板不是文档，是代码。不同的指令会产生不同的行为。
b.优化策略
a.对比实验
同一任务用不同指令，看哪个效果更好。
b.迭代优化
把好用的指令沉淀下来。
c.自我进化
甚至让 Agent 帮你优化指令（Agent 可以写更好的 Agent 指令）。
c.实践经验
笔者自己的实践：维护一个"Prompt 版本库"，每次发现更好用的写法就更新进去。这比每次从头写 Prompt 效率高太多。
g.用 Agent 做API的粘合剂
a.案例分享
如果各种工具都暴露 API，一个 Agent 就能统一调度它们。Karpathy 举了个例子：他把整个智能家居整合到一个 WhatsApp 助手里。不用打开六个不同的 App，直接一个对话搞定。
b.价值理解
Agent 的价值不在于"替你写代码"，而在于成为你和各种系统之间的统一接口。你的日历、邮件、代码仓库、项目管理工具……如果能通过 Agent 调用，就不需要在各种 UI 之间跳来跳去。
h.持久化循环：让 Agent 自己跑
a.思维转变
超越"单次对话"的思维，搭建能够持续运行的 Agent。
b.配置要点
a.环境隔离
给 Agent 独立的沙盒环境。
b.记忆完善
配置更完善的 Memory 系统。
c.跨会话恢复
让 Agent 能跨会话恢复工作。
c.应用场景
比如让 Agent 监控某个数据源，发现异常自动处理，处理完给你发通知。你不需要一直盯着，Agent 自己就在干活。
i.能力是"锯齿状"的，不是均匀的
a.能力模型
模型不是所有方面都一样强。Agent 在"可验证的任务"上非常强（写代码、跑测试、通过 CI），但在"软性任务"上还很弱（理解微妙意图、把握幽默感、做出价值判断）。
b.实操建议
a.优势领域
让 Agent 做能被测试验证的事。
b.劣势领域
需要判断、品味、创意的事，还是自己来。
c.工作流设计
设计工作流时，把这两类任务分开。
j.文档写给 Agent 看，不是给人看
a.前瞻观点
与其写 HTML 格式的用户指南，不如写 Markdown 格式的 Agent 指令。因为如果 Agent 理解了你的代码库，它就能用任何语言向任何人解释，而且有无限耐心。
b.角色定位
你的任务是提供那些"Agent 无法生成的核心洞见"，其他解释性工作交给 Agent。
c.实践案例
项目文档现在主要写给 Agent 看。人类用户有问题？让 Agent 帮他们解答。
k.专注 Agent 做不了的事
a.战略价值
你的价值在于那些 Agent 做不了的事。
b.具体领域
创造性洞察、品味判断、新颖的问题框架、战略决策。其他一切，都可以交给 Agent。而且 Agent 会越做越好。
l.总结：从"程序员"到"智能调度师"
a.角色转变
回顾这 10 条建议，其实都在说一件事：Agent 时代，你的角色要变。以前是"我来写代码"，现在是"我来调度 Agent 写代码"。以前是"我掌握所有细节"，现在是"我掌握核心决策，细节交给 Agent"。以前是"我是瓶颈"，现在是"我要从工作流中消失"。
b.历史对比
这和当年从"手写汇编"到"写高级语言"的转型很像。每次工具升级，程序员的价值都会上移一层。Agent 只是这个进程的最新一环。别把 Agent 当成"更好的代码补全"，它是一个全新的工作模式。
c.行动指南
尽早建立肌肉记忆，你就能比别人早一步跨过"技能问题"这道坎。
m.参考资料
a.来源
Karpathy's 10 Actionable Insights for Working with AI Agents - Dan McAteer
f.Hermes 高级用法：用多 Profile 协作 + Wiki 共享记忆，搭建你的 OPC Agent 团队
a.说明
a.上篇说明
上篇：多 Profile 协作：如何把 Agent 组织成一支 OPC 团队
b.背景介绍
最近 OPC 的概念很火。OPC，也就是 One-Person Company，一人公司。
它的核心不是一个人单打独斗，而是一个人借助多个 Agent，像管理一支小团队一样，去完成一个或多个复杂任务。
那么问题来了：如何构建一套可靠的多 Profile 协作架构？今天这篇文章，先带你梳理 Hermes 多 Profile 协作的核心逻辑。
这不是简单地"多开几个 Agent"，而是要建立一套稳定、清晰、可长期运行的 Agent 工作系统。每一个想做 OPC 的人，都应该认真思考这个问题。
b.为什么要使用多 Profile 协作
a.概述
一个 Agent 当然可以完成很多事情。它可以查资料、写文章、写代码、做图、做复盘。但如果所有任务都交给一个 Agent，长期看会出现三个问题。
b.幻觉问题
一个 Agent 最大的问题是：自己写，自己审，自己觉得自己没问题。所以我们需要建立一套团队运作体系，
让不同 Profile 承担不同任务，从不同角度看同一个问题。比如：Researcher 负责事实；Writer 负责表达；
Builder 负责实现；Coordinator 负责统筹。这样系统更容易发现漏洞，也更不容易陷入单一 Agent 的自我确认。
c.避免记忆污染
一个 Agent 同时做所有项目、所有环节，记忆很容易混在一起。比如它同时记住：文章要讲故事；代码要优先可运行；
产品要先做 MVP；研究要标注来源。这些经验本身没有错，但它们属于不同任务、不同环节、不同项目。
如果全部混进一个 memory，时间久了就会互相污染、互相矛盾。最后的结果就是：写代码时带着内容创作的习惯；
写文章时带着工程实现的思维；做研究时又提前开始下结论。这就是记忆污染。
d.避免角色混乱
一个 Agent 同时负责研究、规划、写作、执行、审查、复盘，很容易角色混乱。典型表现是：该研究的时候，
它开始写结论；该写作的时候，它又重新查资料；该审查的时候，它开始替自己的输出辩护；
该做项目管理的时候，它沉迷于细节执行。所以，多 Profile 的本质不是"更多 Agent"，而是更清晰的角色边界。
c.先搞懂四个概念：Profile、Subagent、Project、Wiki
a.概述
在搭建团队之前，我们要先分清四个概念：Profile、Subagent、Project、Wiki。这四个概念如果混在一起，后面的系统一定会乱。
b.Profile：长期员工
Profile 可以理解成系统中的长期员工。每个 Profile 都是一个独立 Agent，拥有自己的身份、记忆、技能和运行配置。
比如：Coordinator 是协调员；Researcher 是研究员；Writer 是作家；Builder 是构建者。
它们不是同一个 Agent 的不同聊天窗口，而是不同角色、不同职责、不同记忆边界的长期成员。
所以，多 Profile 实质上是在搭建一支 Agent 团队。
c.Subagent：临时工
Subagent 是临时 Agent。它更像是临时派出去的小助手，适合处理复杂任务中的局部问题。
比如你要写一篇深度文章，可以临时派出几个 Subagent：一个查传统 RAG；一个查 Agentic RAG；
一个查 LLM Wiki；一个检查逻辑漏洞。Subagent 干完就结束，不需要长期人格，也不需要长期记忆。
所以可以简单理解为：Profile 是长期员工，Subagent 是临时外包。
d.Project：项目空间
Project 是长期任务的项目空间。如果你同时推进多个长期任务，比如：Twitter Growth；Vibe Coding；
内容增长系统；产品 Demo。那每个长期任务都应该有自己的项目空间。
注意：运行多个长期任务时，关键不是多建 Profile，而是先划分好项目空间。
不要为每个项目复制一套 Profile。正确做法是：同一套 Profile 团队，服务多个 Project folder。
这样才能避免 Profile 数量爆炸，也能避免长期记忆污染。
e.Wiki：共享记忆层
多 Profile 的记忆不相通，那复杂任务怎么推进？答案是：共享 Wiki。Wiki 就像一家公司的共享文档。
不同员工有不同的大脑，但他们可以通过共享文档同步：项目进度；任务状态；决策记录；知识沉淀。
在 Hermes 多 Profile 系统里，Wiki 不是普通笔记库，而是一个有组织、可维护、可长期运行的共享记忆系统。
它记录：项目状态；任务进度；决策记录；研究材料；最终产出；通用方法论。所以，一个稳定的 Agent 团队，实际上是由多 Profile 和共享 Wiki 共同组成的。
d.四角色模型：像真实公司一样组织 Agent
a.概述
多 Profile 该如何分工？推荐一个经过验证的四角色模型：Coordinator（项目经理）、Researcher（研究员）、Writer（作家）、Builder（工程师）。
b.角色1：协调员 Coordinator
Coordinator 就是项目经理。它的核心职责是：定义目标（明确最终要达成什么）；
拆分任务（把大目标拆成可执行的小任务）；路由任务（判断每个任务应该交给谁）；
汇总结果（把不同角色的产出整合成最终结果）；检查边界（避免记忆污染和文件冲突）。
Coordinator 不应该沉迷于亲自查资料、写文章、写代码，它最重要的职责是让整个系统有序运行。
c.角色2：研究专员 Researcher
Researcher 就是研究员。它的核心职责是：收集证据（从多个来源获取信息）；
对比来源（交叉验证，确保信息可靠）；标记不确定性（明确指出哪些信息尚未验证）；
提炼事实（区分事实、观点和推测）。一个好的 Researcher，可以显著降低整个系统的幻觉。
它不应该直接写最终稿，也不应该直接做最终决策，它要做的是提供可靠的原材料。
d.角色3：作家 Writer
Writer 负责把原材料转化成清晰内容。它的核心职责是：搭建文章结构；优化表达方式；
提炼主线和观点；让内容适合目标读者；把复杂概念讲清楚。当 Writer 不需要再负责规划和查资料，它的输出质量会明显提升，因为它可以专注于把内容讲清楚。
e.角色4：构建者 Builder
Builder 更像工程师。它的核心职责是：实现（把计划变成可运行的代码、页面或系统）；
调试（定位并修复问题）；测试（确保输出稳定可靠）；交付（生成最终可用的结果）。
当 Builder 不需要再负责讲故事、做研究、定方向时，它的实现质量也会提高，因为它可以专注于落地。
e.完整工作流
一套典型的多 Profile 工作流是：Coordinator 拆解并规划任务；Researcher 收集来源、验证主张；
Writer 把研究结果转化成清晰内容；Builder 负责最终实现或交付；Coordinator
最后检查、汇总、归档。这个结构之所以强大，是因为它反映了真实工作流程。
现实里，一个稳定团队也不会让同一个人同时当项目经理、研究员、作家、工程师和审稿人，Agent 团队也是一样。
f.开始构建每个 Profile
a.概述
当角色分工确定后，就可以开始构建每个 Profile。
每个 Profile 通常包含：soul.md、USER.md、memory.md、config.yaml、skills/、.env。
以下以"协调员 Coordinator"为例，讲解每个文件分别负责什么。
b.soul.md：协调员是谁
soul.md 是 Profile 的核心身份文件。它定义这个 Profile：是谁；负责什么；
有什么边界；不应该做什么。比如 Coordinator 的 soul.md 需要说明：它是协调员；
它负责拆分任务、规划项目、汇总结果；它维护 dashboard 和 agent-log；
它不直接执行研究任务；它不直接写最终内容；它不直接实现代码。
注意：如果你同时推进多个项目，不要把具体项目内容写进 soul.md，
否则极容易造成角色污染。soul.md 写的是这个 Agent 是谁，不是这个项目现在在做什么。
c.USER.md：协调员理解的用户是谁
USER.md 记录的是这个 Profile 对用户的理解。比如：用户偏好中文交流；
用户喜欢结构清晰的 Markdown；用户不喜欢空泛概念；用户希望输出适合复制到 Obsidian。
注意：这里的 USER.md 是"协调员这个角色所理解的用户形象"，不是整个系统唯一的用户画像。
如果需要所有 Profile 共享用户画像，应该放到 Wiki 的 system/user-profile.md。
d.memory.md：协调员学到的通用经验
memory.md 记录的是这个 Profile 在长期工作中总结出来的通用经验。
比如：复杂任务应该先拆解；不同 Profile 不要同时修改同一个正式文件；中间材料先进入 inbox；最终产出再进入 outputs。
但这里不应该写具体项目经验，比如：Twitter 今天写了 3 条推文；Vibe Coding 登录页已经完成。
这些内容不属于 memory.md，而应该放到项目空间里。memory.md 记录的是通用经验，不是项目状态。
e.skills：协调员的技能库
skills 是可复用的任务流程。Coordinator 的 skills 可以包括：任务拆解；项目优先级判断；交接单生成；
dashboard 更新；weekly review；memory audit。这些 skills 专门服务于协调员这个角色。
如果某个 skill 是通用技能，比如 project-context-loader、memory-routing，
可以分别加入多个 Profile 的 skills list。但不要把所有技能都塞给所有 Profile，否则角色边界又会乱掉。
f.config.yaml：协调员如何运行
config.yaml 是 Profile 的运行配置。它规定这个 Profile 如何工作，
比如：使用什么模型；默认工作目录是什么；允许读写哪些文件；是否自动加载 skills；
哪些文件不能修改。注意：config.yaml 不是写任务内容的地方，它回答的是这个 Profile 怎么运行，不是这个项目要做什么。
g..env：协调员的密钥
.env 只放密钥，比如：API Key；Token；SMTP 密码；外部服务凭证。
不要把这些内容写进 .env：项目状态；用户偏好；任务说明；文章内容。
也不要把密钥写进 soul.md、USER.md、memory.md、AGENTS.md、Wiki，因为这些文件可能会进入模型上下文。
g.上篇小结
a.已完成的三件事
明确为什么不能让一个 Agent 全包；区分 Profile、Subagent、Project、Wiki
四个概念；搭建 Coordinator、Researcher、Writer、Builder 四角色模型。
b.下篇预告
但这还只是"团队层"。一个团队要长期运行，光有员工还不够。
它还需要：共享文档；项目空间；任务看板；决策记录；复盘机制。
05.常用信息5
a.你担心 AI 时代失业吗
a.说明
程序员的核心竞争力从来不是编码速度，而是解决问题的能力。
Hacker News 有篇讨论挺火：《Why I'm Not Worried About Running Out of Work in the Age of AI》。评论区照例分成了两派——一派说 AI 要取代所有程序员，另一派说这只是又一次技术革命，没什么好怕的。
两边都有道理，但也都说对了一半。
我的看法：AI 不会导致大规模失业，但它会重塑工作形态。那些被淘汰的人，不是因为 AI 太强，而是因为他们从未真正理解自己工作的核心价值。
说人话就是：会看到大量裁员失业，顶级的人产出会被极大放大；而平庸的人，寻求其他就业机会，降低收入预期。
b.数据背后的真相
先看看 2026 年 Q1 的数据：
全球科技行业裁员约 5.6 万人，其中约 20% 被公司明确归因于 AI
Meta 工程师产出提升 30%，AI 工具"高级用户"产出提升 80%
LinkedIn 报告称 AI 创造了 130 万个新岗位（但很多是现有岗位重新分类）
UC Berkeley 研究发现：83% 使用 AI 的员工工作量反而增加了
这些数字看起来矛盾，但恰恰揭示了真相：AI 确实在替代某些任务，但它同时创造了新的工作形态。
Block CEO Jack Dorsey 裁员 40% 时说："一个更小但更强大的团队，用我们构建的工具，可以做得更多、更好。"他的目标是将人均毛利从 50 万美元提升到 200 万美元。这不是危机下的被动裁员，而是主动的组织重构。
Meta Zuckerberg 在财报电话会议上说得更直白："我们看到以前需要大团队完成的项目，现在一个非常有才华的人就能搞定。"
听起来很吓人？但换个角度想：如果你是那个"非常有才华的人"，这意味着什么？
c.杰文斯悖论的 AI 版本
1865 年，经济学家威廉·杰文斯发现：蒸汽机效率提升后，煤炭消耗量反而增加了。因为效率提高降低了使用成本，催生了更多应用场景。
AI 正在上演同样的剧情。
当一个任务从 6 小时缩短到 2 小时，公司不会给你 4 小时自由时间，而是会给你 3 个新的 2 小时任务。KPMG 美国 CEO Tim Walsh 说得毫不掩饰："这意味着我可以把更多业务量塞进我的公司。我的业务应该增长，也会增长。"
HN 上有位评论者精准描述了这种体验："自从团队全面转向 AI 工作方式后，期望值翻了三倍，压力翻了三倍，但实际生产力只提升了约 10%。"
这不是 AI 的问题，这是组织管理的问题。工具变强了，但管理思维还停留在工业时代。
d.程序员的核心竞争力是什么
让我说句可能得罪人的话：如果你的核心竞争力是编码速度，那你确实应该担心。
但真正优秀的程序员，核心竞争力从来不是这个。
AI 最擅长的是什么？是把清晰的指令变成代码。但它不擅长什么？是理解模糊的需求、是在技术约束和业务目标之间做权衡、是在一堆烂代码中找出真正的问题所在。
这些能力，AI 短期内替代不了。
举个具体例子。上周我们有个需求：优化某个接口的响应时间。初级工程师的第一反应是"用 AI 生成优化代码"。但资深工程师会先问：
这个接口为什么慢？是数据库查询、网络延迟、还是业务逻辑复杂？
用户真的需要这么快的响应吗？还是我们应该优先解决其他问题？
如果优化成本太高，有没有替代方案？
AI 可以帮你写代码，但它不能帮你决定该写什么代码。
e.谁在焦虑，谁在适应
UC Berkeley 的研究有个细节很有意思：burnout 率在基层员工中是 61-62%，在高管中只有 38%。
为什么？因为基层员工在用 AI 做更多执行工作，而高管在用 AI 做更多决策工作。
这揭示了一个残酷但重要的事实：AI 放大了你的能力，但也放大了你的定位。
如果你是执行者，AI 会让你成为更高效的执行者——然后被期待执行更多。
如果你是决策者，AI 会让你成为更明智的决策者——然后被赋予更大责任。
LinkedIn 数据显示，增长最快的 5 项技能中，只有 1 项是技术性的（AI/ML），其他 4 项是：适应性、协作、战略思维、沟通。
这说明了什么？未来最稀缺的不是会用 AI 的人，而是能用 AI 解决复杂问题的人。
f.几点建议
a.1.重新定义你的价值
问自己一个问题：如果 AI 能完成我 80% 的日常工作，我剩下的 20% 是什么？
那 20%，才是你真正的价值所在。可能是需求分析、可能是架构设计、可能是跨团队沟通、可能是技术选型决策。找到它，然后放大它。
b.2.学会"AI原生"的工作方式
不是"用 AI 写代码"，而是"用 AI 思考问题"。
我的做法是：遇到复杂问题时，先让 AI 帮我梳理思路、列举可能的方案、分析各自的 trade-off。然后我再做决策。这样 AI 成了我的"思考加速器"，而不是"代码生成器"。
c.3.培养"跨层"能力
以前工程师可以只懂技术，产品经理只懂业务。但 AI 时代，边界在模糊。
UC Berkeley 研究发现，AI adoption 后，产品经理开始写代码，工程师开始做用户研究。能跨越技术 - 业务鸿沟的人，会变得极其稀缺。
d.4.警惕"AI脑疲劳"
BCG 的研究发现，1/7 的 AI 用户出现"脑疲劳"——同时管理多个 AI 工具导致注意力分散、决策变慢。
我的解法很简单：限制工具数量，建立使用规范。 我主要用两个 AI 工具，一个用于代码，一个用于思考。（可以并行，并发多任务）
e.5.保持学习，但要有选择
AI 技术迭代太快，想跟上所有新东西是不可能的。
我的策略是：深度掌握核心原理，浅层了解工具变化。 Transformer 架构、注意力机制、推理优化——这些底层知识变化慢，值得投入。至于哪个新框架出了、哪个 API 变了，用的时候再查就行。
g.最后
大规模失业可能不会表现为“所有人都没有工作”，而是表现为“薪资的剧烈分化”和“职业半衰期的缩短”。
20 年前，有人担心 IDE 会让程序员失业；10 年前，有人担心 Stack Overflow 会让程序员变笨；5 年前，有人担心低代码会取代开发。
现在呢？工具越来越强，但优秀程序员的价值反而更高了。
AI 不会取代你。但会用 AI 的人，可能会取代不会用 AI 的人。
这不是威胁，这是机会。
b.当 AI 开始给 AI 写代码——递归开发的终局猜想
a.行业现状
2026年Q1，AI编程工具领域出现AI自主开发现象，Cursor、OpenHands、Devin、SWE-agent等均实现AI为自身编写代码，该趋势已成为现实。
b.递归开发的三个层次
a.第一层：AI工具开发AI工具
人类作为架构师与决策者，使用AI辅助编写AI相关工具，GitHub数据显示超70%的AI/ML仓库提交含AI生成代码，该层次已全面普及。
b.第二层：AI工具优化自身
工具自主改进自身代码，如Cursor开发新版本、OpenHands自动修复Bug、SWE-agent优化评测框架等，改进方向仍由人类定义。
c.第三层：AI自主决定改进方向
尚未完全实现，AI可自主发现问题并重构模块，Anthropic研究已显现相关苗头，人类参与度持续降低。
c.编译器自举历史对比
1962年自举编译器诞生，是工具自我开发的先例，AI递归开发是其逻辑延伸。二者核心差异为编译器自举是封闭循环、确定性强、递归深度有限，AI自我开发是开放循环、概率性输出、理论递归无限，具备自我进化潜力。
d.真实落地场景
a.场景一：OpenHands自我修复循环
AI自动分析并提交Bug修复PR，人类为最终审核者，人在回路是安全底线。
b.场景二：Cursor狗粮文化升级
用前代AI开发新版本形成迭代循环，但存在AI调试同类Bug陷入盲区的问题。
c.场景三：AI基准测试自我博弈
SWE-agent优化自身评测框架，导致评估客观性下降。
e.递归开发四大风险
a.同质化陷阱
迭代强化固有模式，引发模型坍缩，创新多样性降低。
b.错误放大效应
隐蔽Bug随递归深度嵌入底层，错误呈指数级增长。
c.可审计性丧失
多层递归后代码决策链无法追溯，形成多层黑箱。
d.依赖锁定
工具迭代高度依赖自身，故障后修复成本随递归深度激增。
f.终局三种猜想
a.猜想一：人机协作均衡点（概率60%）
AI负责80%-90%代码实现，人类把控架构与审计，递归深度限制在2-3层，平衡效率与可控性。
b.猜想二：开放与封闭递归分化（概率30%）
开源社区走开放递归路线，透明审核但速度较慢；商业公司走封闭递归路线，高效但低透明。
c.猜想三：加速递归临界点突破（概率10%）
AI迭代速度超越人类审核，开发范式彻底变革，需全新安全与监管体系。
g.开发者实操建议
a.提升AI代码审计能力
b.保持技术工具多样性
c.关注工具递归开发深度
d.积极参与开源社区审核
h.文章结语
AI递归开发正从哲学问题变为工程问题，终局取决于效率与可控性的平衡，核心风险是人类失去对工具的理解与干预能力，需审慎界定边界。
c.Anthropic长运行应用设计实践，越来越有AutoResearch的思想
a.背景与挑战
a.核心问题
在 AI 应用开发中，如何让 AI 应用长时间稳定运行是一个常见挑战。
无论是客服机器人、代码助手还是数据分析工具，用户都期望它们能够持续可靠地工作。
b.长运行面临的主要挑战
资源泄漏、状态管理复杂、错误恢复困难。本文深入解读 Anthropic 工程团队分享的长运行 Harness 设计经验，
看他们如何通过多代理架构和生成器-评估器循环解决这些问题。
b.Agent长运行失败的原因
a.上下文焦虑
a.问题描述
随着任务执行，上下文窗口逐渐填满，模型开始失去连贯性。某些模型（如 Claude Sonnet 4.5）会出现上下文焦虑——当它们认为接近上下文限制时，
会过早地试图结束工作。
b.解决方案
完全清空上下文窗口，启动新的代理会话，同时通过结构化的人工制品（handoff artifacts）传递之前代理的状态和下一步计划。
这与压缩不同——压缩只是总结早期对话，代理仍然带着历史包袱继续工作；而重置给了代理一张干净的白纸。
b.自我评估偏差
a.问题描述
当被要求评估自己产生的工作时，代理倾向于自信地赞美自己的工作，即使质量明显平庸。
这个问题在主观任务（如设计）中尤为明显，因为没有像软件测试那样的二元验证。
b.解决方案
将执行工作的代理与评判工作的代理分开。虽然评估代理本身也是 LLM，也会倾向于宽容，但调优一个独立的评估器比让生成器自我批评要容易得多。
c.Harness设计前端设计实验
a.实验背景
Anthropic 团队首先在前端设计 Harness 实验，因为这里的自我评估问题最为明显。
b.四个评估标准
a.设计质量
设计是否感觉像一个连贯的整体，而不是零件的集合？色彩、排版、布局、图像等细节是否结合在一起创造出独特的氛围和身份？
b.原创性
是否有定制决策的证据，还是模板布局、库默认值和 AI 生成模式？人类设计师应该能识别出有意的创意选择。
未修改的库存组件或 AI 生成的典型模式（如白色卡片上的紫色渐变）在这里会不及格。
c.工艺
技术执行——排版层次结构、间距一致性、色彩和谐、对比度比率。这是能力检查而非创意检查。
大多数合理的实现默认都能在这里表现良好；失败意味着基础功能有问题。
d.功能性
独立于美学的可用性。用户能否理解界面的功能、找到主要操作，并在无需猜测的情况下完成任务？
c.关键洞察
团队强调设计质量和原创性高于工艺和功能性。因为 Claude 默认在工艺和功能性上已经表现不错，但在设计和原创性上往往产出平淡无奇的内容。
d.生成器-评估器循环
a.循环流程
生成器创建前端 → 评估器用 Playwright 交互测试 → 评分+详细批评 → 生成器迭代改进
b.运行细节
每个生成运行 5-15 次迭代，评估器使用 Playwright MCP 直接与 live 页面交互，
截图并仔细研究实现。每次迭代后，生成器做出战略决策：如果分数趋势良好则精炼当前方向，如果方法不行则完全转向新的美学风格。完整运行可能长达 4 小时。
d.Harness设计扩展到全栈开发
a.背景
有了前端设计的经验，团队将这种 GAN 启发的模式应用到全栈开发中。
b.架构设计
a.整体流程
规划器 → 生成器 → 评估器 → 反馈循环
b.规划器
a.职责
将用户简单的 1-4 句话提示扩展为完整的产品规格说明。
b.设计原则
对范围保持雄心勃勃，专注于产品上下文和高层技术设计而非详细的技术实现，
避免 upfront 指定细粒度技术细节（如果规划器出错，错误会级联到下游实现），在规格中寻找机会融入 AI 功能。
c.生成器
a.职责
一次实现一个功能（sprint 模式）。
b.技术栈
React + Vite + FastAPI + SQLite/PostgreSQL
c.工作流程
从规格中选取一个功能进行 sprint 开发，使用 git 进行版本控制，
在 sprint 结束时自我评估，与评估器协商 sprint 合同：约定本 sprint 要交付的内容和验收标准。
d.评估器
a.职责
像用户一样点击通过运行中的应用，测试 UI 功能、API 端点和数据库状态。
b.评估标准
产品深度、功能性、视觉设计、代码质量。
c.关键机制
每个标准都有硬性阈值，如果任何一项低于阈值，sprint 失败，生成器收到详细反馈并返工。
e.核心设计原则总结
a.原则一：显式状态管理
不要依赖隐式状态。将应用的所有状态显式地建模和存储，这样即使进程重启，也能从断点恢复。
b.原则二：上下文重置优于压缩
当上下文窗口填满时，完全重置比压缩总结更有效。虽然需要额外的编排复杂度和 token 开销，但给了代理干净的开始。
c.原则三：分离生成与评估
让独立的评估器批判生成器的工作，比让生成器自我批评要有效得多。评估器需要被调优为怀疑态度。
d.原则四：结构化人工制品传递上下文
在代理之间传递结构化的手递人工制品（handoff artifacts），确保下一个代理能够干净地接手工作。
e.原则五：迭代反馈循环
生成器-评估器循环应该运行多次迭代（5-15 次），每次迭代都推动生成器向更强的输出发展。
f.原则六：硬性阈值+详细反馈
评估标准应该有硬性阈值，低于阈值就失败。同时提供详细的批评反馈，让生成器知道具体哪里需要改进。
f.技术选型建议
a.Agent编排
a.Claude Agent SDK
Anthropic 官方代理 SDK，简化编排。
b.自定义状态机
明确定义每个状态和转换条件。
b.测试与评估
a.Playwright MCP
让评估器能够与 live 应用交互。
b.自动化测试
单元测试、集成测试、端到端测试。
c.状态存储
a.Redis
适合缓存和临时状态。
b.PostgreSQL
适合持久化状态。
c.SQLite
适合轻量级本地应用。
d.监控工具
a.Prometheus+Grafana
指标监控。
b.Sentry
错误追踪。
c.自定义日志
业务逻辑监控。
g.常见陷阱
a.陷阱一：忽略上下文焦虑
在长任务中，模型会因为上下文填满而失去连贯性或过早结束。必须设计上下文重置机制。
b.陷阱二：让代理自我评估
代理倾向于赞美自己的工作。必须分离生成与评估。
c.陷阱三：评估标准模糊
这个设计好吗？很难一致回答。必须将主观判断转化为具体、可评分的标准。
d.陷阱四：没有硬性阈值
评估必须有硬性阈值，低于阈值就失败，否则生成器会持续产出勉强合格的工作。
e.陷阱五：一次性生成
期望单次生成就产出高质量应用是不现实的。必须设计迭代反馈循环。
h.实践建议
a.从简单开始
先在一个领域（如前端设计）实验生成器-评估器循环，校准评估标准，然后再扩展到其他领域。
b.校准评估器
使用 few-shot 示例和详细评分分解来校准评估器，确保评估者的判断与你的偏好一致，减少跨迭代的分数漂移。
c.允许战略转向
在每次评估后，让生成器决定是精炼当前方向还是完全转向新的方法。有时大幅转向能带来创意飞跃。
d.接受非线性改进
分数通常随迭代改进，但模式不总是线性的。有时中间迭代比最后一次更好。保留历史版本以便回滚。
e.投资评估标准
评估标准的措辞会直接影响生成器的输出特征。例如，最好的设计是博物馆级别这样的表述会将设计推向特定的视觉收敛。
i.总结
a.核心理念
显式优于隐式，分离优于合并，迭代优于单次，结构化优于随意。
b.整体结论
设计长运行 AI 应用是一项系统工程，需要综合考虑状态管理、错误处理、资源监控、代理协作等多个方面。
通过多代理架构、生成器-评估器循环和上下文重置等设计模式，可以构建出更可靠、更高质量的 AI 应用。
d.组建一支AI梦之队，Agency-Agents给你128个随时待命的专业Agent
a.项目简介
想想如果能拥有一支专业团队——前端工程师、设计师、营销专家、项目经理——随时待命，24小时响应，从不抱怨，那该多好？
这不是幻想。一个叫 Agency-Agents 的项目正在把这件事变成现实。
它不是简单的 Prompt 模板库，而是一个包含 128 个专业 AI Agent 的"虚拟人才市场"。每个 Agent 都有独特的性格、专业领域和交付物标准。
b.项目定义
Agency-Agents，一句话定义：一个精心设计的 AI Agent 集合，覆盖工程、设计、营销、销售等 12 个部门，每个 Agent 都像一位真正的专业人士——有自己的性格、工作流程和质量标准。
打个比方：它就像一个虚拟的人力资源平台。你需要前端开发？有专门的 Frontend Developer Agent。需要设计品牌调性？有 Brand Guardian Agent。甚至在游戏开发、空间计算等小众领域，都能找到对应的专家。
和市面上那些"假装是专家"的泛泛 Prompt 不同，每个 Agent 都经过深度打磨：性格鲜明、流程清晰、交付物具体。
c.核心架构
项目按职能划分为 12 个部门，包含 128 个 Agent。
a.工程部门
前端、后端、移动端、AI 工程师、DevOps、安全工程师……你能想到的角色这里都有。
比如 Frontend Developer Agent，它不只告诉你"怎么写代码"，还内置了：Core Web Vitals 性能优化标准、WCAG 2.1 无障碍合规要求、完整的 React 组件代码示例、从项目搭建到测试上线的完整工作流。
b.设计部门
这里有 UI 设计师、UX 研究员，还有一个很有趣的角色——Whimsy Injector（趣味注入师）。
这位 Agent 的职责是给产品注入"惊喜感"。它的金句是："Every playful element must serve a functional or emotional purpose. Design delight that enhances rather than distracts."
每一个有趣的元素，都要服务于功能或情感目的。
它会帮你设计彩蛋、庆祝动画、有趣的空状态页面——让产品从"能用"变成"让人喜欢用"。
c.营销部门
营销团队覆盖了主流社交平台：Twitter、Instagram、TikTok、Reddit，还有小红书、B站、知乎、快手等中国平台。
Reddit Community Builder Agent 的理念特别打动我："You're not marketing on Reddit - you're becoming a valued community member who happens to represent a brand."
你不是在 Reddit 上做营销——你是在成为一个有价值的社区成员，恰巧代表一个品牌。
这不是套路，而是真正理解了社区运营的本质。
d.游戏开发部门
这个部门按游戏引擎细分：Unity（架构师、Shader 艺术家、多人游戏工程师）、Unreal Engine（系统工程师、技术美术、世界构建师）、Godot（游戏玩法脚本、多人游戏工程师）、Roblox（系统脚本、体验设计师、头像创建者）。
游戏开发的专业性被很好地尊重了——不同引擎有不同的最佳实践，不能一概而论。
d.Agent设计哲学
这个项目最打动我的，是它的设计哲学。每个 Agent 都包含以下要素：
要素 说明
Identity & Memory 身份定位、性格特点、记忆模式
Core Mission 核心使命和关键职责
Critical Rules 必须遵守的硬性规则
Technical Deliverables 具体的交付物和代码示例
Workflow Process 标准化的工作流程
Success Metrics 成功标准和质量指标
这不是简单的"扮演一个角色"，而是构建一个完整的职业人格。
举个例子，Evidence Collector（证据收集者）——一个测试部门的 Agent，它的口头禅是："I don't just test your code - I default to finding 3-5 issues and require visual proof for everything."
我不只是测试你的代码——我默认会找到 3-5 个问题，并且要求所有事情都有视觉证明。
这种"偏执"的性格，恰恰是一个好 QA 应该有的特质。
e.使用方式
项目提供了多种使用方式。
a.Claude Code 直接使用
复制 Agent 到 Claude Code 目录：cp -r agency-agents/* ~/.claude/agents/
在对话中激活 Agent："Hey Claude，activate Frontend Developer mode，帮我构建一个 React 组件"
b.多工具支持
项目支持 10 种主流 AI 编程工具：Claude Code、GitHub Copilot、Cursor、Aider、Windsurf、Gemini CLI 等。
生成集成文件：./scripts/convert.sh
交互式安装（自动检测已安装的工具）：./scripts/install.sh
脚本会扫描你的系统，显示已安装的工具列表，让你选择要安装到哪些工具中。
f.实际场景示例
假设你要做一个创业项目的 MVP，可以"雇佣"这样一支团队：
角色 职责
Frontend Developer 构建 React 应用
Backend Architect 设计 API 和数据库架构
Growth Hacker 规划用户增长策略
Rapid Prototyper 快速迭代原型
Reality Checker 上线前的质量把关
5 个 Agent 协同工作，覆盖从开发到上线的全流程。
g.项目优缺点
a.优点
专业度高：每个 Agent 都有深度，不是泛泛而谈
实用性强：提供了具体的代码示例和工作流程
覆盖面广：12 个部门、128 个 Agent，大部分场景都能覆盖
工具友好：支持 10 种主流 AI 编程工具
b.局限
数量多，选择难：128 个 Agent 对新人来说信息量很大，需要时间筛选
依赖 AI 能力：Agent 的效果取决于底层模型的智能程度
中文场景有限：虽然有小红书、B 站等中国平台，但整体还是偏西方视角
h.结语
这个项目代表了一个重要趋势——AI Agent 正在从"单打独斗"走向"团队协作"。未来的 AI 应用，很可能不是和一个通用助手对话，而是和一支专业团队协作。
Agency-Agents 做了一件有价值的事：它把"职业知识"编码进了 Agent。这些性格、流程、标准，都是人类多年积累的专业经验。通过 Agent 的形式传承下去，让每个人都能拥有自己的"梦之队"。
i.参考来源
https://github.com/msitarzewski/agency-agents
e.今天的AI已经不在卷模型了，而是在卷“谁能把 Agent 真的塞进公司里”
a.前言
大家好，我是老马。今天是4.14号，基于 follow-builders 这个skill（开源的）获取了国外最新的AI feed简报，
认真看完后，我有个强烈的感受：AI 行业的重心，已经开始从“模型能力展示”，
切到“Agent 怎么真正进入组织、进入流程、进入产业”。
过去大家讨论 AI，常见的问题是模型更强了吗、代码能力又涨了吗、推理更长了吗。
而今天这些 builder 们在讨论的，已经变成了另一组问题：
企业里谁来部署和管理 Agent、软件公司的护城河是不是正在从“写代码”变成“造代码工厂”、
AI 的下一站会不会不只是软件而是材料化学制造这些物理世界。
说白了，大家已经不满足于“让 AI 帮我做点事”。
他们开始认真思考怎么让 AI 变成一个可以被组织、被管理、被持续优化的生产系统。
今天的信息量很大，但如果只能提炼一句话，我会这么说：2026 年的 AI，不只是更会说了，而是开始更会“上班”了。
b.最值得重视的一条：企业里可能会出现一个全新岗位
a.核心观点
今天 Box CEO Aaron Levie 发了一条很长的内容，我认为这是今天最重要的信息之一。
他的判断很直接：未来大多数企业团队里，都会出现一种新角色，专门负责部署、管理和持续运营 AI Agent。
注意，这不是“让某个员工顺手用一下 ChatGPT”，也不是“IT 部门统一买个 AI 套餐”。
他讲的是另一回事：这个人要真正识别出团队里哪些工作流最值得被 Agent 接管，
怎么把上下文、工具、业务系统、人工审核节点、评估体系、KPI 全部串起来，
然后让 Agent 长期稳定运行。换句话说，这已经不是“使用工具”，而是“管理生产力系统”了。
b.典型高杠杆场景
Aaron 提到几个典型高杠杆场景，包括处理数量级更高的销售线索、自动化合同审查与 intake、
优化客户 onboarding 流程、搭建整个团队都能调用的知识库。
这些场景有一个共同点：不是做个 demo 看起来很聪明，而是真的能把一个团队的吞吐量提高 10 倍、100 倍。
c.岗位的演变
过去企业数字化转型，常见岗位是流程 Owner、系统管理员、数据分析师。
而接下来，可能真的会出现一种新岗位，名字你可以随便起：Agent Operator、Agent Manager、AI Workflow Owner。
名字不重要，重要的是背后的变化：企业 AI 落地，正在从“人人自己试一试”，走向“组织正式重构工作流”。
d.岗位的技能要求
Aaron 特别强调，这个人不能只是“懂一点提示词”。他得懂业务，也得足够 technical，
能处理 skills、MCP、CLI、系统连接、评测和长期运维。
这类人，未来很可能会变得特别贵，因为他们做的不是“调用模型”，而是“把 AI 变成正式劳动力”。
e.作者的项目实践
为什么这个新闻给我很强烈的感触，因为新闻中的这个点恰恰和我现在在做的事不谋而合。
我现在做的事，就是推动项目交付全流程的skill开发和落地。
让提炼了专家经验的skill，被“组织”起来，被“管理”起来，被“持续优化”起来，被“持续迭代”起来。
f.技能成熟度评估体系
因为技能需要持续迭代升级，我们也输出了一套完整的评估体系：
等级 定义 完成率 说明
L1 说明书层 - 有基本步骤，能提供方向，但主要靠模型临场发挥
L2 流程助手层 >=60% 能辅助完成常规任务，但稳定性不足
L3 场景可用层 >=80% 在主要场景可完成任务，已具备实用价值
L4 专家执行层 >=90% 关键决策、风险控制、失败处理较完整；较稳定完成目标
L5 专家天花板层 >=95% 核心价值已不只是流程，而是难替代的专家经验本身
c.Vercel 发布的趋势：软件公司开始造“AI 代码工厂”
a.护城河的转移
另一条我觉得必须重点看的，是 Vercel CEO Guillermo Rauch 的发布。
这条内容最有杀伤力的一句话，不是它开源了什么，而是它的判断：
未来软件公司的护城河，会从“写出来的代码”，转向“生产这些代码的工厂”。
过去我们认为，软件公司的价值主要在代码本身。但未来，真正拉开差距的，可能不是“你仓库里有多少代码”，
而是：你有没有自己的上下文系统、你有没有自己的 Agent 工作流、
你能不能在大仓库里稳定运行 coding agent、你有没有自己的安全沙箱、持久化执行、模型路由、内部知识接入。
也就是说，竞争点正在从“谁会写”，变成“谁会生产”。
b.工业化生产系统
Guillermo 还点名提到，像 Stripe、Ramp、Spotify、Block 这些公司，
都在构建自己的内部 AI software factory。
这其实已经把行业阶段讲得很清楚了：Coding Agent 的竞争，不再只是“谁更像 Copilot”，
而是在变成“谁更像一套工业化生产系统”。
c.Open Agents 参考架构
他这次开源的 Open Agents，也不是一个简单 demo，而是一种参考架构。
里面包含几个关键层：Fluid（Agent 的“大脑”）、Workflow（长时间运行和耐久性）、
Sandbox（安全执行代码）、AI Gateway（多模型调用和 token 管理）。
你会发现，这套东西已经很像一个“AI 时代的软件工厂底座”了。
所以今天这条消息真正值得关注的地方，不是“又多了一个开源项目”。
而是它在提醒所有开发团队：你接下来要建设的，可能不是一个更聪明的聊天框，而是一套更完整的 AI 生产系统。
d.Garry Tan 透露的方向：高手的工作流正在被打包成产品
a.从通用工具到高手模板
今天 Garry Tan 连发多条，主要围绕 GBrain。这两条最有意思的地方，不在于功能点本身，
而在于它传递出一个很明确的产品信号：未来很多有传播力的 AI 工具，可能不是“最通用的工具”，
而是“某个高手把自己的工作流打包给你”。Garry 直接说，GBrain 本质上就是他自己的
OpenClaw / Hermes Agent 配置。它不是追求绝对中立的“平台”，而是一套高度主观、但能直接拿来用的高手模板。
b.用户价值的转变
因为对于大量普通用户来说，最值钱的不是“给我一个空平台”，
而是：给我一套高手已经跑通的工作方式，我直接照着用。
这就像过去大家买的不是“一个空白 Notion”，而是“别人整理好的生产力模板”。
AI 时代也一样。真正有价值的，不只是模型，而是模型外面的那层工作流、规则、搜索、语音、记忆、工具组合和使用习惯。
c.产品功能
里面有什么？更强的搜索策略、skillpacks、基于 OpenAI Realtime 的语音 agent、
准备升级到 Gemini Live。新版本还补了搜索调优、评测、CJK 查询优化和安全热修。
e.Dan Shipper 对 2026 年软件团队状态的分析
a.角色分化：海盗和建筑师
软件工程会分裂成“海盗”和“建筑师”。所谓“海盗”，就是快速试错、快速落地、先把价值跑出来的人。
所谓“建筑师”，就是把这堆混乱原型收拾成一个长期可维护、可扩展、可协作系统的人。
为什么这个判断现在尤其重要？因为 AI 极大降低了原型成本。
过去做一个试验版，可能得折腾几天。现在很多时候，几个小时就能做出一个像样的东西。
于是新的矛盾也来了：做出来，越来越容易。做好，依然很难。
b.工程心智模型
“An agent is just folder”，这句话乍一看很糙，但真的很妙。
它把 agent 从那种神神叨叨、仿佛有自我意识的包装里，重新拉回了工程视角。
你可以把 agent 理解成一个封装单元：有上下文、有工具、有状态、有目标、有输出约束。
这样一来，agent 就不再是玄学，而变成
06.常用信息6
a.AI Agent 的记忆战争
a.话题背景
你有没有想过，当你跟 AI Agent 聊了一整天之后，它到底记住了什么？
最近 AI Agent 圈子里有两件事特别火，一边是 OpenClaw 的 Dreaming 机制，另一边是 Claude Code 的 Skills 系统。
表面看都是让 AI 记住更多，但骨子里完全是两码事。
b.OpenClaw 的 Dreaming 机制
a.核心概念
Dreaming 的意思是"做梦"。你睡觉的时候，AI 也在"做梦"，在后台整理自己的记忆。
它有 Light、REM、Deep 三个阶段，类似人类睡眠周期，可在后台配置运行时间，默认在系统空闲时自动触发。
b.评分逻辑
OpenClaw 搞了一套多维度评分体系，会根据信息的频率、相关性、
使用多样性、近因、整合性、概念丰富度等维度自动调整权重，认为相关性和使用频率才是王道。
c.设计哲学
Dreaming 追求的是"无感知的后台优化"，不需要告诉 AI 该怎么整理，它自己会在夜深人静时琢磨出最适合自己的记忆结构。
这个方案走的是"让 AI 自我进化"的路线。
c.Claude 的 Skills 系统
a.系统机制
Skills 2.0 用的是 SKILL.md 格式，把某项能力的执行目标、步骤和最佳实践写成结构化文档，
安装到 Claude Code 后，Claude 能理解并复现这个能力。
b.工程化玩法
这套体系支持 subagent、evals、A/B 测试，开发者可以像维护代码一样维护 Skills，有版本控制，有测试，有发布流程。
c.生态现状
社区已积累了超过 1000 个可安装的 Skills，并有专门的汇总网站 Botmonster，生态相当成熟。
d.设计哲学
Skills 的逻辑是"前台能力注入"，明确告诉 AI 任务该怎么做，这种方式对开发者友好，因为一切都是显式的、可控的、可测试的。
d.两种哲学：自律 vs 他律
a.自律路线
OpenClaw 的 Dreaming 走的是"自律"路线。它假设 AI 比人类更知道自己该怎么运作，
记忆怎么整理、信息该保留都由 AI 决定，目标是让 AI 真正具备自我管理能力。
b.他律路线
Claude 的 Skills 走的是"他律"路线。它假设人类指导是必要的，AI 需要被教会，
Skills 是人类经验的结晶。优势是"可解释性强"，因为你知道 AI 是被教会怎么做的。
c.形象比喻
Dreaming 像是培养一个自律的孩子，让他自己决定什么时候复习；Skills 则像是请家教，每门课都有详细的教学大纲。
e.工程实用性视角
a.Skills 的优势
Skills 模式对开发者太友好，整个流程跟写代码、发 npm 包 没什么区别，
而且可以测试，利用 evals 和 A/B 测试量化效果，这是工程思维的胜利。
b.Dreaming 的难点
Dreaming 虽然理念美，但后台自动运行的机制让开发者难以干预，缺乏衡量记忆整理好坏的指标。
但它解决了 Skills 解决不了的问题，即人类经验有边界，有些东西 AI 需要自己去摸索。
f.未来的融合方向
a.短期与长期
短期看 Skills 模式更有市场，因为生态已起、工具链完善；长期看 Dreaming 代表的"AI 自整理"才是终态。
但在那之前，Skills 作为过渡方案会一直存在。
b.理想的形态
未来最理想的 AI Agent，可能是人类提供 Skills 作为初始能力集，
AI 在此基础上通过 Dreaming 不断自我优化，最终超越人类教给它的东西。
c.总结
最好的教育不是灌输知识，而是培养学习能力。最好的 AI Agent，或许不是懂得最多的，
而是最懂得如何学习、如何整理自己的。这场记忆战争，结局可能是双方在 AI 学会"自律"的终点会师。
b.Agent 能跑七天？这五个设计模式是关键
a.引言：长运行Agent的挑战
Google Cloud 在 Cloud Next 26 发布了 Agent Runtime 现在支持最长 7 天的长运行 Agent。
这对处理几千份保险理赔、运行一周的销售序列等任务至关重要，因为大部分 Agent 架构是无状态的，
每次交互会重建上下文并丢失关键信息。Addy Osmani 和 Shubham Saboo 提出了五个设计模式来解决这些问题。
b.模式一：Checkpoint-and-Resume（断点续传）
a.解决的问题
多天工作流的上下文丢失。例如 Agent 处理了 200 份文档后在第 201 份报错，
如果没有 checkpoint，必须从零开始，浪费时间和已处理的中间结果。
b.关键设计
Checkpoint 的粒度权衡。例如原文以 50 份文档一批为例。Agent Runtime 将执行状态持久化到云沙箱，
Agent 拥有完整的 bash 访问权限和沙箱文件系统，可写入中间结果、维护日志并从失败恢复。
c.架构思维
把 Agent 当成长运行的服务进程，而不是请求处理器。设计"启动→运行→checkpoint→继续运行"的管道，处理部分失败并保证幂等性。
d.落地检查点
评估每个 checkpoint 的成本（写入时间）和失败后重建的最大可接受成本，粒度要在两者之间取折中。
c.模式二：Delegated Approval（委托审批）
a.解决的问题
人机交互的时间错位。传统的"human-in-the-loop"通过序列化 JSON 和发 webhook 实现，会丢失隐式推理上下文，且通知容易被淹没。
b.关键设计
Agent 遇到审批门时原地暂停，保留完整执行状态（推理链条、工作记忆等），且消耗零计算资源。审批通过后可在亚秒内冷启动恢复。
c.管理界面
Mission Control 提供了分类通知（需要输入、错误、已完成）的管理界面，解决在多个 Agent 中翻找的问题。
d.落地检查点
区分必须人工审批的决策（合规、风控）和可降级为自动审批的决策；设定审批超时处理机制。
d.模式三：Memory-Layered Context（分层记忆）
a.解决的问题
Agent 需要跨越多个会话的记忆，包括前一会话的事项、用户偏好和组织上下文，而不是仅维持当前会话状态。
b.记忆分工
Memory Bank：动态生成长期记忆，按话题组织。Memory Profiles：低延迟访问特定细节的工作记忆。
需警惕"记忆漂移"，即 Agent 从异常交互中学到错误经验。
c.架构治理
采用 Agent Identity（类似 IAM）、Agent Registry（类似服务发现）、Agent Gateway（策略评估）三层架构治理 Agent，
防止未经控制地写入向量库或数据泄漏。
d.落地检查点
检查不同 Agent 的记忆池是否隔离、记忆写入是否有策略过滤（如 PII）、以及是否有记忆漂移检测机制。
e.模式四：Ambient Processing（后台处理）
a.解决的问题
不依赖人工触发的工作流。适合不需要用户交互的后台型 Agent，监听事件、处理数据流。
b.关键设计
Batch 和 Event-Driven Agent 直接连接 BigQuery 表和 Pub/Sub 流。例如内容审核 Agent 在事件到达时处理，只在必要时升级。
c.架构决策
不要把内容政策硬编码进 Agent，而应定义在 Agent Gateway。政策更新时 Gateway 统一更新，所有后台 Agent 自动适配，避免重新部署。
d.落地检查点
明确事件源（Pub/Sub、Kafka）、升级条件（阈值、模式）以及政策更新的频率和方式。
f.模式五：Fleet Orchestration（舰队编排）
a.解决的问题
生产环境中多个长运行 Agent 的协调。
b.关键设计
由协调 Agent 把子任务委托给专业 Agent（如研究、评分、外联、会议准备），每个独立运行不同时长。
c.运维优势
专业 Agent 作为独立单元，可独立更新和监控。支持 Bring Your Own Container，一个 Agent 的糟糕部署不会级联影响其他 Agent。
d.落地检查点
确定协调者维护全局状态的模式（中心化 vs 分布式）、专业 Agent 的隔离边界以及部署失败的回滚机制。
g.模式选择与总结
a.组合与选择
这五个模式可以组合。关键判断是 Agent 需要执行的最长不间断工作单元时间。
Checkpoint 和 Delegated Approval 是基础，Memory 和 Fleet 是扩展，Ambient 是独立分支。
b.技术趋势
Google Cloud 将持久化上限设为 7 天，表明企业级工作流需要此类支持。
Agent 系统正在利用成熟的微服务治理实践（身份、注册、网关、沙箱、持久化）加上 LLM 推理能力，从"聊天机器人"变为"自动化工作者"。
c.快速参考表
模式 解决的问题 核心机制 适用场景
Checkpoint-and-Resume 上下文丢失 状态持久化到沙箱 批处理、文档处理、跨天任务
Delegated Approval 人机时间错位 原地暂停，零计算等待 审批门、合规检查、风控
Memory-Layered Context 跨会话记忆 Bank + Profiles 分层 长周期客户服务、知识积累
Ambient Processing 无人工触发 事件驱动 + Gateway 政策 内容审核、数据流处理、监控
Fleet Orchestration 多 Agent 协调 Identity + Registry + Gateway 销售、合规、复杂工作流
c.Prompt Caching：用架构设计把 AI Agent 成本砍掉 80%
a.Prompt Caching核心价值
通过架构设计实现AI Agent成本大幅降低，Claude Code达成92%缓存命中率与81%成本节省，解决长system prompt重复计算导致的高额费用问题。
b.静态与动态Prompt拆分原理
a.静态内容
包含system instructions、tool definitions、project context，会话全程不变，为缓存核心对象。
b.动态内容
包含user messages、assistant responses、tool outputs，随对话持续增长。
c.KV Cache机制
缓存静态token序列的Key与Value向量，以哈希值索引，将注意力计算从O(n²)降为O(n)，避免重复计算。
c.Claude Code实际成本对比
a.Anthropic缓存定价
Cache read为0.1倍基础价，Cache write为1.25倍基础价，Extended cache为2.0倍基础价。
b.30分钟编程会话案例
无缓存成本为6美元，启用缓存后成本仅1.15美元，实现81%成本削减。
c.适用场景
适合静态前缀长、动态尾巴短、会话持续时间长的场景，短对话使用缓存不划算。
d.缓存哈希脆弱性与约束
a.失效原因
token序列任意变动、时间戳注入、key排序不一致、参数修改均会导致缓存失效。
b.使用硬约束
禁止会话中途修改tools、禁止切换模型、禁止在system prompt中插入动态状态，保证缓存前缀只读。
e.Prompt Caching架构四层设计
a.Prompt结构化
按稳定程度分层放置system指令、工具定义、参考文档与对话历史。
b.缓存边界管理
合理使用自动与手动断点，避免动态内容割裂静态缓存前缀。
c.内容压缩策略
子agent间传递摘要而非原始内容，缩短动态尾巴提升命中率。
d.会话生命周期管理
通过轻量请求重置TTL，或使用extended cache延长缓存至1小时。
f.缓存效率监控指标
核心监控cache_creation_input_tokens、cache_read_input_tokens、input_tokens字段，缓存命中率低于70%需排查问题。
g.总结与应用启示
Prompt Caching是长运行Agent的必要优化，需从Prompt结构、工具管理、会话设计、监控体系做架构级规范，无法仅靠单一API参数实现。
d.从蒸汽机到Agent：控制论和Harness Engineering正在重塑程序员的未来
a.核心观点
从蒸汽机到AI Agent，控制论与Harness Engineering正在重塑程序员的未来，开发者的角色从亲手操作转向掌舵掌控。
b.历史上三次相似的控制论模式
a.第一次：蒸汽机与离心调速器
1780年代詹姆斯·瓦特发明离心调速器，工人从手动调节阀门转变为设计调速器。
b.第二次：Kubernetes
工程师声明期望状态，控制器自动维持与修复，工作从重启服务变为编写系统校准规范。
c.第三次：AI Agent与Harness Engineering
OpenAI提出的模式中，工程师设计环境、构建反馈循环、编码架构约束，Agent完成代码编写，实现大量代码零手写。
c.控制论的本质
诺伯特·维纳在1948年命名为控制论，源自希腊语舵手，核心是不再手动操作，而是进行掌控与引导。
d.代码库曾是最后的堡垒的原因
a.以往反馈回路仅存在于底层
编译器、测试套件、Linter分别关闭语法、行为、代码风格的回路，但仅作用于可机械检查的属性。
b.高层级无有效反馈
系统架构、设计合理性、抽象可持续性等高层决策无传感器与执行器，仅能依靠人类操作。
c.LLM带来的改变
LLM可在人类决策层级感知与行动，首次在重要决策层级关闭反馈回路。
e.校准传感器和执行器的关键
a.基础条件
构建Agent可运行的测试、可解析输出的CI、指向修复的错误信息是基础要求。
b.核心难点
将系统专属知识外部化、机器可读化，包括架构规范、自定义Linter、团队黄金原则。
c.常见误区
Agent失败并非能力不足，而是人类未将判断与标准显性化。
f.忽视工程实践的代价剧变
a.传统模式
忽视文档、测试、架构的代价缓慢且分散。
b.Agent模式
跳过规范会导致Agent持续出错，代价极端且快速放大。
c.核心结论
工程实践未变，但忽视代价变得无法承受。
g.生成-验证的不对称性
生成正确答案比验证更难，工程师核心价值从实现转向评估、指定标准、识别偏差、把控方向。
h.未来工程师的角色转变
角色从动手实现转向定义标准，从执行者升级为设计师、指挥官，核心输出为判断力、架构直觉与机器可读规范。
i.面向AI时代的行动建议
a.写下架构原则并转化为机器可读规则。
b.投资测试基础设施，完善反馈回路。
c.构建自定义Linter，编码代码规范与品味。
d.培养规格驱动思维，先定义期望状态与验证方式。
e.接受掌舵者身份，从操作转向设计与掌控。
j.总结与展望
控制论历经77年重塑软件工程，历史规律表明开发者不会消失，但仅执行操作的人将被掌控规则的人取代，AI时代知识管理转向可执行技能。
k.参考资料
a.OpenAI Harness Engineering文章
b.Norbert Wiener《控制论》1948
c.詹姆斯·瓦特离心调速器1780年代
d.Kubernetes控制回路
e.Cobbe等人-生成-验证不对称性研究
e.Agent 入门：别一上来就做“超级智能体”，先写一个能取消订单的小 Agent
a.说明
这两年，Agent 很火。很多人一提到 Agent，脑子里浮现的都是那种“能自己思考、能自己规划、能自己调用很多工具、几乎像员工一样工作”的系统。
听起来很酷，但也容易让初学者产生一个误区：好像只有做得很复杂，才算 Agent。
其实恰恰相反。对于大多数开发者来说，学习 Agent 最好的方式，不是先做一个“万能助手”，而是先做一个很小、很具体、很容易验证效果的场景。比如：取消订单。
b.为什么“取消订单”是很好的 Agent 入门场景？
想象一个电商客服团队的日常工作：用户发来邮件，说杯子碎了，要退款；用户发来消息，说订单还没发货，想取消；
用户下单后发现地址写错了，想修改收货地址。对人工客服来说，这类事情通常流程都差不多：
先读懂用户在说什么，去后台找到对应订单，根据规则执行操作，再回复一条确认信息给用户。
这个流程看起来不复杂，但每天重复几十次、几百次，就很适合自动化。
也正因为如此，Agent 的第一个练习题，往往不是“解决所有客服问题”，
而是先从一个明确任务开始：让系统读懂用户消息，判断是否需要取消订单，调用取消工具，
然后返回确认结果。这个思路和材料中的核心观点是一致的：
Agent 最适合从一个边界清晰、输入明确、输出结构化的小任务切入，而不是一开始就试图“自动化所有事情”。
c.Agent 到底是什么？一句大白话讲清楚
很多文章把 Agent 讲得很玄，其实可以先用一句很朴素的话理解：Agent = 大模型 + 工具 + 工作流程。
拆开来看：大模型负责理解用户意图，工具负责执行真实动作，流程负责把“理解—执行—回复”串起来。
比如用户说：请帮我取消订单 A12345。这时候，一个最简单的 Agent 会做三件事：
识别出用户想“取消订单”，调用 cancel_order(order_id="A12345")，返回一句“您的订单已成功取消”。
看到了吗？这里真正“干活”的，不是模型本身，而是模型判断后调用的工具。
所以，Agent 的重点从来不只是“会聊天”，而是：它能不能在理解上下文后，做出正确动作。
d.一个最小 Agent，通常就这三步
a.概述
如果把入门版 Agent 再压缩一下，本质上只有三个步骤。
b.第一步：读懂用户消息
先把用户输入交给模型，让模型判断：这是不是一个取消订单请求？
c.第二步：调用工具
如果是，就调用后端工具函数，比如：cancel_order(order_id="A12345")。这里未来可以接真实数据库、订单系统、内部 API。
d.第三步：生成回复
工具执行成功后，再让模型组织一段自然语言回复给用户。
e.核心能力总结
这就是一个最小闭环。别看它简单，这已经包含了 Agent 的核心能力：能理解自然语言，能决定是否调用工具，能把工具结果转化成用户能看懂的话。
e.为什么初学 Agent，一定要先“收窄范围”？
很多人上来就想做一个“全能客服 Agent”：能退款、能取消订单、能查物流、能改地址、能处理投诉、还能推荐商品。
听起来很完整，但问题也很明显：范围一大，边界就模糊；边界一模糊，系统就难稳定。
材料里其实说得很明白：如果任务切得太窄，业务价值不够；但如果任务切得太宽，就会掉进各种边界情况、例外场景和复杂规则里。
所以，最合理的方式是：不要太小，小到没有业务意义；也不要太大，大到无法验证和迭代；
最好选一个高频、规则清晰、容易测试的场景。“取消订单”就是这种非常典型的起点。
因为它有明确输入（用户消息、订单号、订单状态），也有明确输出（是否调用取消工具、工具参数是否正确、最终回复是否清晰）。
这种任务特别适合拿来做第一个 Agent。
f.一个能跑通的 Agent，比一个概念上的 Agent 更重要
很多人学 Agent，最大的问题不是“不会写代码”，而是太容易停留在概念层。
比如知道：Agent 能调用工具、Agent 能做任务规划、Agent 能接工作流、Agent 能接知识库。
但如果没有真正写过一个闭环系统，这些概念很容易变成“懂了，但没真会”。
所以入门最重要的一件事，不是研究多复杂的框架，而是先把下面这件事做出来：
用户输入一句话，系统真的完成一次工具调用，并给出正确回复。只要这一步跑通了，你对 Agent 的理解就会立刻从“听说过”变成“我做过”。
g.Agent 不是写完就算，评估比演示更重要
还有一个非常容易被忽略的问题：Agent 能跑，不代表 Agent 可靠。
在演示环境里，它可能很聪明。但一旦到了真实业务中，你真正关心的是：
它有没有调用正确的工具？它传的参数对不对？它的回复会不会误导用户？
它在边界情况里会不会出错？你提供的材料也特别强调了这一点：一个没有经过测试的 Agent，是不值得信任的。
至少在“取消订单”这个场景里，我们应该验证三件事：是否调用了正确工具、是否传入了正确订单号、是否返回了明确、正确的确认信息。
这其实就是 Agent 和普通 Demo 的区别。Demo 追求“看起来会”。而真正的 Agent 系统，追求的是“在真实场景里持续正确”。
h.初学者最该建立的，不是框架感，而是系统感
很多人学习 Agent 时，容易把注意力放在框架名字上：LangChain、LangGraph、AutoGen、CrewAI、各种 Workflow 平台。
这些当然有用，但对于入门来说，更重要的是你脑子里有没有这样一张图：用户消息 → 模型理解 → 工具调用 → 执行结果 → 用户回复。
只要这条链路想清楚了，换框架都不是大问题。相反，如果这条链路没想清楚，即使你把一堆框架都装上，也很难写出真正稳定的 Agent。
所以从学习顺序上，我更建议这样走：先理解 Agent 的最小闭环，再写一个最小业务场景，再补测试和评估，最后再考虑多工具、多节点、记忆、规划这些高级能力。
i.给刚入门 Agent 的一个建议：先做“小而真”的项目
如果你正准备开始学 Agent，不妨给自己定一个很实际的小目标：不要先做“最强 Agent”，先做“第一个能真正完成任务的 Agent”。
比如：取消订单 Agent、改地址 Agent、查询快递 Agent、自动生成日报 Agent、自动分类工单 Agent。
这些项目有一个共同点：它们都不大，但是真的能落地。这比做一个“什么都想做、最后什么都没做稳”的大系统，更能帮助你快速建立直觉。
j.写在最后
Agent 并不神秘。说到底，它只是把过去需要人手动完成的一套流程，拆成了几个可自动化的步骤：理解输入、决定动作、调用工具、返回结果。
真正的难点，不在于把它说得多高级，而在于你能不能找到一个足够清晰的业务切口，把第一条链路跑通。
所以，Agent 入门最好的姿势不是仰望复杂系统，而是从一个小任务开始——先让它帮你取消一张订单。
等这个最小闭环稳定了，你再往上加退款、改地址、查订单、做路由、加评估、加记忆，整个系统自然就长出来了。
这才是大多数开发者真正能走通的 Agent 学习路径。
07.常用信息7
a.Markdown 成为了当前 AI 文件交互的一个标准
a.Markdown成为交互的Schelling point
大家都默契地选择将自己的文本文件系统变为Markdown格式后再进行其他工作。
b.Markdown赢得了格式战争
a.现状概述
基本上，现在AI时代的文本格式和内容展示被局限在了HTML和Markdown两个部分。
b.文本发送
我们最近经常看到圈子里的朋友在发送文本的时候用Markdown。
c.演示展示
在进行演示的时候用的是HTML（包括最近层出不穷的PPT Skills也都是以网页的形式去推广的）。
c.需要更独特的交互方式
既然Markdown已经成为了事实上的基准，那我们就应该进行下一步了。
Markdown本身的展示目前非常死板，市场想要更多、更独特的方式来和现有的Markdown文件去交互。
d.Obsidian的启示
当6年前Obsidian把本地文件夹、双向链接和知识图谱跟Markdown结合起来的时候，很多人不太理解这个产品，觉得很难用。
a.当前地位
但现在它不仅是个人知识管理的常态，也是AI内容管理非常重要的一种方式。
e.将Markdown作为数据去使用
a.内存机制示例
例如我的CodePilot里面没有复杂的memory机制，所有的memory其实都是靠MD文件完成的。
b.跳出编辑器思维
所以目前需要跳出文本编辑器的思路：最近很多人在做Markdown编辑器，但其实应该跳出这个思路。
c.构建新体验
将Markdown作为一个数据去使用，构建更加跳脱常规的人机交互体验。
d.Widget应用
比如我的CodePilot里的widget，它可以支持让AI用你本地的memory和Markdown文件作为数据来源。
当你的本地文件发生变化时，你的widget组件也会随之发生变化。
b.AI 编程，Cloudflare 是怎样保证质量的呢？
a.文章背景与核心观点
a.背景
Cloudflare于4月20日发布博客，详细拆解了内部AI代码审查系统的组织架构。
b.核心观点
重点不在于使用什么模型，而在于如何在一个数万MR规模的大型工程组织中让AI稳定可靠地运行。
b.架构设计：插件与Agent两层体系
a.底层插件层
包含gitlab、cloudflare、codex、braintrust等7个插件，作为系统的感官和手脚，负责垂直领域的数据进出。
b.上层Agent层
包含Security、Performance等6个专项Agent及1个Coordinator Agent，负责专项处理、去重汇总。
c.设计逻辑
采用分而治之的典型架构，每个Agent专注擅长领域，结果由Coordinator统一收口。
c.模型分层与容错机制
a.模型分配策略
a.Coordinator决策层
使用Opus 4.7和GPT-5.4最强模型，负责判断去重和严重程度判定。
b.Reviewer审查层
使用Sonnet 4.6和GPT-5.3 Codex中档模型，发挥代码审查强项。
c.轻量级任务层
使用Kimi K2.5等便宜模型处理简单任务。
b.熔断与降级
a.熔断器机制
借鉴Netflix Hystrix模式，当模型调用失败时自动降级到备选模型。
b.系统可靠性
避免单一依赖，确保LLM API故障时系统仍能运行。
d.风险分级审查策略
a.三级审查模式
a.Trivial（小改动）
文档修正、配置调整，仅运行轻量审查。
b.Lite（中等改动）
运行部分Agent。
c.Full（大改动）
核心网络栈等重大变更，7个Agent全量扫描。
b.紧急破窗通道
线上紧急热修复时允许跳过AI审查直接合入，避免AI成为响应瓶颈。
e.技术选型：为何选择OpenCode
a.核心差异
a.OpenCode
提供可编程SDK，支持在代码层面精确控制Agent行为，适合系统级编排。
b.Claude Code
作为CLI工具，适合交互式编码，但难以进行程序化编排。
b.深度参与
Cloudflare已向OpenCode贡献45个以上PR，深度参与上游项目发展。
c.选型逻辑
Cloudflare需要的是适合工厂流水线的工具箱，而非单兵作战的瑞士军刀。
f.关键工程细节
a.Diff审查过滤
仅审查变更部分，避免将整个文件喂给模型造成Token浪费和逻辑混淆。
b.Prompt注入防护
识别并防护恶意代码中可能嵌入的精心构造注释，防止误导AI审查结果。
g.总结与启示
a.核心价值
展示了如何系统性解决AI在工程实践中的可靠性问题，而非单纯展示能力。
b.关键经验
a.编排比模型重要
分工、分级、降级和汇总的架构决策决定了系统上限。
b.成熟的工程实践
将Circuit Breaker等传统分布式系统设计模式应用于AI系统。
c.成本优化的本质
在需要的地方用好AI，在不需要的地方不浪费，通过分级和过滤实现高质量低成本。
c.工程理念
系统级嵌入AI时，可编程性比用户体验更重要。
c.三天三个大版本，Claude Code 正在从终端工具变成开发环境
a.更新概况
Claude Code 于 4 月 15 日至 17 日连续发布 v2.1.110、v2.1.111、v2.1.113 三个版本，共计 130 多条变更。
这些更新标志着 Claude Code 正从单一的终端工具向 AI 原生开发环境演进。
b.架构升级：原生二进制迁移
a.核心变更
CLI 从 Node.js 应用迁移为原生二进制程序，通过平台特定的可选依赖进行分发。
b.性能优势
消除 V8 引擎预热延迟，实现瞬间启动；优化内存和 CPU 效率，解决全屏模式下的性能瓶颈。
c.战略意义
摆脱 Node.js 运行时限制，为多 Agent 并发、系统级沙箱等复杂功能打下基础。
c.新功能：多 Agent 并行审查
a./ultrareview 功能
支持在项目目录或指定 PR 下运行，利用云端多 Agent 并行审查代码变更。
b.体验优化
v2.1.113 增加了 diffstat 概览、动画状态提示，并优化了启动检查的并行化。
c.价值定位
旨在从不同维度（安全、性能、逻辑等）发现问题，而非简单重复检查，解决代码审查的复杂性难题。
d.交互升级：TUI 全屏与推送
a.TUI 全屏模式
解决终端渲染闪烁、乱码和撕裂问题，提供沉浸式体验，使其接近轻量级 IDE。
b.Push 通知
任务完成时推送通知到手机，结合 Routines 和 Remote Control，打破必须盯屏的限制。
e.安全加固
a.注入防护
修复 "Open in editor" 的命令注入漏洞，修复 PermissionRequest hook 的绕过问题。
b.系统保护
macOS 关键目录（如 /private/etc）被设为危险删除目标，防止误删；增强 Bash deny 规则以拦截 sudo 等包装器。
c.权限限制
限制 find 命令自动批准执行任意权限，引入子 Agent 停滞检测（10 分钟超时）。
f.模型与配置更新
a.Opus 4.7 xhigh
新增介于 high 和 max 之间的 xhigh 档位，平衡成本与效果。
b.交互优化
/effort 命令支持交互式滑块选择；Auto 模式向 Max 订阅者开放，实现自动化档位调节。
g.产品路线分析
a.CLI-first 演进
通过 TUI 补齐界面体验，原生二进制补齐性能底座，/ultrareview 补齐工作流闭环。
b.核心目标
打造基于终端的 AI 原生开发环境，涵盖写、审、测、部署全流程。
h.总结与建议
a.升级建议
原生二进制性能提升显著，新功能值得尝试。
b.迭代节奏
高频发布显示 Anthropic 将其作为核心产品，但需关注压缩测试周期带来的稳定性风险。
c.质量本质
工具效率的提升不代表代码生成质量的提升，核心仍依赖模型能力。
d.95% 代码都交给 AI 了，但真正拉开团队差距的，可能是录音和 Skill
a.引言：从一场会议录音说起
a.会议背景
那天的会，原本看起来没什么特别，只不过桌面上多了一台录音设备。
谁也不会想到，这场会最后真正留下来的，最有价值的东西，不是某个结论，
不是某句漂亮的话，甚至不是那句95%代码已经交给AI了，而是整段原始讨论本身。
b.核心发现
也正是因为这份一手录音被完整留了下来，回听时才慢慢意识到：很多真正重要的判断，往往都藏在结论之前。
AI再强，也得先吃到靠谱的一手材料；而团队再会用AI，如果经验始终停留在几个人脑子里，最后也很难变成稳定产能。
c.现状描述
一个后端同学说，他现在写代码，95%以上已经交给AI了。不是小打小闹，而是从接口定义、到描述实现要求、再到生成代码，整条链路都在用。
常用的Skill包括后台开发助手、代码审查、Jenkins部署助手，已经成了日常标配。
d.文章主旨
这篇文章不想继续夸AI已经帮人写了多少代码，更想聊清楚一件事：AI时代真正的护城河，可能根本不是谁更会写Prompt，
而是谁更会留住源头内容，谁更快把有效经验变成团队可以反复调用的能力。
e.文章地址
https://mp.weixin.qq.com/s/JUrayHT8ZPlX7A_rAcQwnQ
b.核心论点一：95%代码交给AI不代表团队会用AI
a.可复制性分析
95%代码交给AI当然厉害，但它厉害不代表它已经天然具备可复制性。
这位后端同学的做法很典型：先把接口名、入参、出参想清楚，再把表结构、外部API、参考接口告诉AI，
让AI生成代码，最后自己再做微调、联调和问题排查。
b.人机分工本质
如果你认真看这条链路，你会发现一个很关键的事实：AI负责的是执行提速，人负责的其实还是设计。
真正决定结果质量的，不只是模型会不会写代码，而是你前面有没有把事情想清楚。
比如目标到底是什么、输入够不够完整、边界条件有没有说透、
哪些地方允许AI自由发挥哪些地方必须严格约束、结果拿什么标准验收。这些东西如果没想清楚，AI生成得越快，偏差放大的速度也越快。
c.警惕误区
这场交流最值得团队警惕的，不是别人已经95%交给AI了我是不是落后了，
而是：你看到的是别人把AI用起来了，但你没看到的是，他背后仍然在大量依赖自己的设计能力、判断能力和经验积累。
很多团队不是不会用AI，而是太急着看结果，反而忽略了最该建设的前置能力：设计、拆解、约束和校验。
c.核心论点二：录音是生产资料而非备份
a.结论的局限性
如果这场会没有录音，最后大概率只会留下一句很刺激、
但价值不大的结论：某后端同学AI用得很好，代码生成占比95%。这句话当然没错，但问题是，它几乎不能指导任何人改进工作。
b.细节的价值
因为真正有用的信息，不在最后那个被提炼出来的结论里，而在原始讨论的过程里。
比如他到底是怎么给AI描述任务的，哪些环节他已经放心交给AI，哪些环节他仍然坚持自己主导，问题排查为什么容易卡住，
大家为什么后来会把重点从AI写了多少拉回到设计有没有讲清楚。这些细节，一旦没有被完整保留下来，后面的人看到的就只剩一句结果。
c.失真问题
而只剩结果，基本就意味着两件事：第一，别人学不会；第二，AI也接不住。
因为AI最怕吃二手信息。一旦源头内容已经被压缩、被转述、被裁剪，很多关键上下文其实在第一轮就丢掉了。
d.录音的新定义
以前很多人理解录音，是留个档免得以后说不清。但在今天，录音的角色已经变了。
它不是附件，不是备份，甚至不只是追溯材料。它更像AI时代的第一手生产资料。
因为只有录音留下来了，后面这条链路才有可能跑通：录音转写拿到原始内容，
基于原始内容整理纪要尽量减少失真，从纪要里抽方法抽模式抽共性问题，最后再把这些东西沉淀成可复用的Skill。
d.核心论点三：纪要只是中间层
a.纪要的作用
很多团队现在已经接受一件事：会议最好录音，最好转写，最好还能自动出纪要。
这当然是进步。但如果只停在有一份纪要，其实还远远不够。
因为纪要解决的，本质上只是信息可读。你知道谁说了什么，知道结论是什么，知道行动项有哪些。它很好，但它本身还不是组织能力。
b.能力跃迁路径
真正关键的是，后面还要再往前走两步：从纪要到结构化要点，解决的是信息可用；
从结构化要点到Skill，解决的是能力可复用。这三层差别很大。
留下一份内容不难，把内容提炼成方法已经难很多，再把方法固化成别人也能反复调用的流程就更难。但偏偏真正拉开团队差距的，就是最后这一步。
e.核心论点四：Skill的价值是流程产品化
a.Prompt与Skill的区别
很多人第一次听到Skill，容易把它理解成Prompt模板升级版。
这么理解不算错，但还是有点轻了。
Prompt解决的是：这一次我怎么问。
Skill解决的是：以后别人也能按这个方式做。差别就在这里。
b.个人与组织
一个人很会用AI，当然可以把自己的效率提得很高。
但如果这套方法只存在于他脑子里，那它对团队的价值其实很有限。
因为今天他在，这套用法有效；明天换个人、换个项目、换个业务场景，效果很可能立刻掉下来。
这也是很多团队都会遇到的真实问题：团队里总有几个人觉得AI特别好，但一推广到其他人身上，效果就不稳定。
c.具体应用场景
比如这次交流里提到的那些高频场景：后台开发助手、代码审查、Jenkins部署助手，甚至下一步准备做的测试数据生成Skill。
这些东西一旦沉淀下来，省掉的就不只是几分钟操作时间。
d.本质
Skill省掉的，是大量重新讲一遍、重新试一遍、重新踩一遍坑的成本。
所以我越来越觉得，Skill的本质不是插件，也不是一个花哨壳子。
它更像一种流程产品化。把原本非常依赖个人经验、个人表达能力、个人悟性的事情，
尽可能变成：输入是什么、过程怎么走、输出长什么样、质量怎么校验。一旦做到这一步，个人能力才真的有机会变成组织能力。
f.问题分析：为何很多团队AI落地不深
a.核心痛点
现在很多团队都会有一种很割裂的感受。一边是，有人已经离不开AI；
另一边是，也有人试了几次就觉得不过如此；还有一些团队，表面上看起来也在用AI，但始终没有形成稳定产能。
b.三大常见问题
a.只重视结果，不重视源头内容
大家关心的是最后文档出来没有、最后结论发出来没有，却不太关心原始讨论是不是被完整保留下来。
结果就是，后面所有加工都只能基于被压缩过的信息继续做，越往后失真越大。
b.只重视一次性输出，不重视经验沉淀
某次效果很好，大家会夸这个人真会用AI。但很少继续追问：这套方法能不能教给别人？
能不能固化下来？能不能做成标准流程？于是每一次成功都像一次即兴发挥，下一次还得从头再来。
c.只重视个人高手，不重视组织复用
团队里总会有少数人跑得很快，但如果没有把这些做法抽出来、沉淀下来、做成Skill，组织整体水平并不会自动跟着抬升。
最后就会形成一个很尴尬的局面：个人能力在升级，团队能力却没有同步升级。
c.根本原因
所以很多团队AI落地不深，根子不一定在不会写Prompt，
而更可能在于：没有把源头内容到结构化整理到Skill沉淀到团队复用这条链路认真搭起来。
g.核心论点五：完整闭环的重要性
a.闭环要素
回头看这次内部交流，反而觉得最有价值的，不是那个最吸睛的95%。
真正值钱的，是它顺手暴露出了一条完整闭环：有真实的一线实践，不是纸上谈兵；
有录音和原始讨论内容，信息没有在第一轮就丢掉；有纪要和结构化整理，方便大家对齐认知；
还有继续沉淀成Skill的意识，不让经验只停留在个别人身上。
b.关注点转移
这其实比某个人已经很会用AI重要得多。因为个人用得再好，最多证明一个点；
而闭环一旦跑通，才说明团队开始具备把点状经验变成系统能力的可能性。
我更关心的是三个问题：有没有把源头内容留下来；有没有把关键决策过程讲清楚；
有没有把有效方法沉淀成别人也能直接上手的东西。这三个问题，比95%本身更能决定一支团队未来能不能真正把AI用深。
h.总结：AI时代的真正竞争力
a.真正的差距
当使用AI慢慢变成标配之后，真正拉开团队差距的，大概率就不再是谁更会写一条Prompt。
而是：谁能更完整地保住第一手内容；谁能更稳定地把讨论、实践、复盘变成结构化资产；
谁又能更快把这些资产继续沉淀成可复用的Skill。
b.组织能力
个人会用AI，当然已经很重要。但如果一个团队能把录音保住事实，把纪要整理成结构化信息，
再把方法沉淀成Skill，让经验跨人传播、跨项目复制，那它拥有的就不只是某个人的效率提升，而是一套真正开始运转的生产力系统。
c.工具推荐
像这次，我们用钉钉Talk A1听记设备把会议完整留了下来，表面上看只是多了一份录音，
实际上留下来的，是后面所有整理、复盘、提炼和沉淀的起点。
没有这份一手素材，后面再多方法论，很多时候也只是二手总结。我们当前无论和客户对接还是内部会议，基本都是使用钉钉talk A1听记设备。
e.未来的职场，不会淘汰解决问题的人，只会奖励那些定义问题的人
a.引言：从“救火”到“追问”的故事
a.危机时刻：周一早上的9:07
电梯门一开，同事阿浩抱着电脑冲进来，脸上写着“完了”。
他一边走一边拨号：“对对对，我马上修，给我十分钟。”
b.那天的事故现场
支付链路出了问题：用户下单后卡在“支付处理中”，客服工单像雪崩一样砸过来。
群里一片“我来查日志”“我来回滚”“我来重启”，每个人都在努力解决问题。
大家像一群熟练的消防员，冲向火场。
c.阿浩的“肌肉记忆”
阿浩是团队公认的“救火王”。
只要喊一声“线上挂了”，他就能在键盘上弹出一套肌肉记忆：定位、修复、发布、复盘。
d.老板的灵魂拷问
问题被暂时压下后，中午吃饭时老板把我们叫进会议室。
老板只问了一个问题：“为什么我们每个月都要经历一次类似的事故？”
会议室突然安静。
每个人都能讲“这次怎么修的”，但没有人能回答“为什么我们总会遇到它”。
阿浩也没说话，他意识到他擅长的是灭火，但不确定火为什么总会起。
e.核心洞察
未来的职场，真正被奖励的，是那些能把“问题”本身定义清楚的人。
b.逻辑分野：解决问题 vs 定义问题
a.解决问题是什么
解决问题是把一个已经被看见、被描述、被确认的痛点消掉。
它需要能力、经验、执行力，也需要一点胆量。
b.定义问题是什么
定义问题是更上游的工作。
它是在混乱、噪声、情绪、指标之间，搞清楚“我们到底在解决什么”。
它需要的不是更快的手，而是更准的脑。
c.职场中的“行动”误区
场景1：运营说“转化率不行，页面要改。”
场景2：产品说“用户留存差，得加一个功能。”
场景3：老板说“我们需要一个 AI 方案，最好下周就能看到效果。”
这些话里都有“行动”，但不一定有“问题”。
行动很容易让人忙起来，问题才决定忙得值不值。
d.错误的代价
如果问题定义错了，解决得越快，可能越危险。
你会用更高的效率，把团队带向一个更错误的方向。
c.AI时代的价值迁移
a.过去十年的竞争力
很多人赢在“我能做得更快”：更快写代码、更快做报表、更快剪视频。
b.AI带来的残酷变化
AI 正在把大量“明确输入—明确输出”的工作，压到接近边际成本为零。
AI 像一个不会累、不会抱怨、且还能不断升级的执行机器。
c.未来的分水岭
价值不再来自“谁更会做”，而是：谁更会判断“要不要做”、谁更会定义“该做什么”。
当“解题”越来越容易，价值就会向“出题”迁移。
d.实战案例：同事小雨的“提问艺术”
a.人物特点
新同事小雨不算“救火型选手”，代码速度也不是最快。
b.她的独特习惯
每次需求评审，她几乎都会问三句话。
第一句：“这个指标变化，我们希望影响谁？”
第二句：“如果我们做了 A，最糟糕的情况是什么？我们怎么提前发现？”
第三句：“有没有可能，我们的问题根本不在这？”
c.团队认知的变化
起初大家觉得她“较真”。
后来发现，她总能把一场“堆功能”的讨论，拉回到本质。
d.具体案例：支付失败补偿弹窗
a.原始需求
产品提出要做“支付失败补偿弹窗”，理由是“客服反馈很多用户不知道怎么处理”。
b.小雨的重新定义
她把客服工单分类，发现大头不是“用户不知道怎么办”，而是“支付失败率在某些机型、某些网络环境下偏高”。
她把问题重新定义成：“我们要降低失败率，而不是解释失败。”
c.方案的彻底改变
从做弹窗，变成排查 SDK、优化网络重试、增加预校验和兜底。
d.最终效果
客服量下降得更快，用户体验更直接，甚至还把一堆潜在的技术债提前暴露出来。
e.案例总结
同样是在“解决问题”，但她先做了“定义问题”。
这一步决定了你是在补洞，还是在改地基。
e.方法论：三个训练框架
a.框架一：用“现象—影响—根因假设”替代“感觉—动作”
a.常见误区
很多讨论卡住，是因为大家在用“感觉”说话，如“我觉得用户不喜欢”。
b.正确表达
现象：发生了什么？（数据、案例、复现路径）
影响：影响谁？影响什么指标？影响有多大？
根因假设：你认为原因是什么？你愿意押什么证据？
b.框架二：用“可验证”替代“可讨论”
a.难以验证的问题
“用户体验更好”“品牌更年轻”“更智能”这类描述特别适合讨论，但很难验证。
b.可验证的转化
“用户体验更好” → “完成支付的平均耗时从 18 秒降到 12 秒”
“更智能” → “客服首轮回复命中率从 40% 提到 55%”
“留存更高” → “7 日留存从 18% 提到 21%，且主要来自新用户”
c.价值
可验证的定义，会强迫团队面对现实，也会保护团队免于无休止的争吵。
c.框架三：把“任务”翻译成“约束下的目标”
a.被动接任务的根源
很多人只看到了“要做什么”，没看见“为什么做”和“边界是什么”。
b.翻译公式
把任务翻译成：“在 X 的约束下，把 Y 从 A 提到 B。”
c.具体示例
“做一个 AI 助手” → “在不增加客服人力的约束下，把夜间咨询解决率从 20% 提到 35%”
“优化埋点” → “在不影响性能的约束下，把核心漏斗的可观测性从 60% 补到 90%”
d.结果
当你能说出约束和目标，你就不再只是执行者，而是在参与定义问题。
f.结局：阿浩的转变
a.思维模式的变化
阿浩仍然是最快的那个人，但他不再满足于“修好就算”。
b.事故后的三问
每次事故之后，他都会追着问三件事：
为什么监控没有更早发现？
为什么我们允许它发生？
下一次它会以什么形式回来？
c.行动上的升级
他开始主动推动“预防性建设”：
把关键路径的告警做得更贴近用户体验。
把回滚流程自动化。
把灰度策略从“看感觉”变成“看指标”。
d.职业发展的结果
他从“救火王”变成了负责稳定性的 owner。
他的感悟：“以前我以为我很强，是因为我能很快把坑填上。后来发现，真正强的人，是让坑根本不会出现。”
这句话是未来职场最硬的通货。
g.写在最后
a.基本盘与增量
你当然要会解决问题，那是基本盘。
但未来的增量价值，来自定义问题的能力。
b.未来的期待
世界对人的期待会变成：“你能不能把我们带到正确的问题上？”
c.给焦虑者的建议
如果你正在焦虑被 AI 替代，别急着把自己卷成更快的执行机器。
从明天的会议开始练习：少给结论，多给问题；少急着开干，多花五分钟把定义写清楚。
08.常用信息8
xxxxxx
2.7 大厂新闻1
00.汇总
a.编程工具
OpenCode 全新 WorkSpace 即将上线
Codex Windows版终于来了
Cline CLI 2.0：从 IDE 侧边栏走向终端
Chrome 推出了 WebMCP 的预览版本
opencode 1.3.0 将不再支持 Claude Max 插件
Codex 终于支持 Plugins 插件了
Google Stitch 发布了 DESIGN.md
harness：模型是原料，框架才是产品
GoogleforDevelopers官方发布A2UIv0.9，定义生成式UI新标准
OpenAI 更新了 GPT-5.5 Instant 模型，现在变成了 ChatGPT 默认模型
Claude Opus 4.8来了：更像一个能独立推进任务的工程搭档
b.大厂新闻
Apple已于2026年3月3日正式宣布搭载M5Pro
AI提交代码导致GitHub宕机
Meta买下Moltbook核心意义
谷歌发布TurboQuant大模型内存瓶颈或迎来关键突破
Google AI Studio更新把 Vibe Coding 从“玩具阶段”推到了“能做产品”的阶段
Google Stitch 大更新：号称是 Vibe Design
Perplexity AI 已经基本完成了产品闭环
终端界的门槛，这次被 Warp 彻底干掉了
Zed 1.0 正式发布
Cursor 官方 TypeScript SDK 公测开放
c.热点新闻
2026年模型军备竞赛
Anthropic 融资狂飙：$40B 牵手 Google，$900B 估值冲刺 IPO
01.编程工具
a.OpenCode 全新 WorkSpace 即将上线
a.说明
我们给OpenCode中的Workspace赋予了新概念 - 允许Agent运行在任何地方：本地项目路径、Git worktree、容器环境(如Docker)、远程沙盒以及其他环境。
Server不再只识别本地目录，而是成为调度中枢，负责把Prompt路由到对应的环境。Server会管理不同环境中的所有Session，并以统一的交互形式呈现在前端。
b.说明
同时，远程环境的数据会同步回本地Server，即使远程环境被销毁，我们也可以重新创建一个状态完全相同的环境。
目前仍处于Prototype版本，敬请期待！
b.Codex Windows版终于来了
a.产品发布动态
OpenAI的Codex应用正式登陆Windows，这标志着AI编程工具进入了原生时代，
对于大量使用Windows进行开发的工程师来说是一个重大更新，解决了此前体验不完整或依赖复杂环境的问题。
b.运行环境支持
a.双模式运行
Codex可以直接在Windows原生环境中运行，同时也支持WSL（Windows Subsystem for Linux）。
这意味着开发者既能利用熟悉的Windows工具链，又能无缝切换到Linux开发环境，兼顾了灵活性与兼容性。
b.多终端集成
内置了对PowerShell、Command Prompt、Git Bash以及WSL终端的支持。
开发者无需频繁切换工具，即可在一个统一界面中完成代码生成、命令运行和项目调试，显著提升了工作流的集中度。
c.安全机制创新
a.Windows原生Agent Sandbox
引入了操作系统级别的安全控制机制，即代理沙盒。该机制默认限制AI代理向工作目录之外写入文件或访问外部网络。
如果需要这些权限，必须由用户明确授权。这种设计在保障AI自动化能力的同时，有效规避了潜在的安全风险。
b.权限控制趋势
随着AI逐步参与代码修改和脚本执行，这种沙盒机制正在探索一种更安全的“AI接管开发环境”的模式，强调了权限控制在自动化开发流程中的重要性。
d.功能拓展与集成
a.应用入口扩展
新增了7个“Open in …”应用入口，允许开发者将项目快速打开到不同的开发环境或工具中，减少了手动配置成本，使AI辅助开发的流程更加顺滑。
b.专属技能发布
官方推出了两项新的Windows技能：WinUI，用于构建Windows原生界面应用；ASP.NET，用于高效搭建Web应用后端。
e.行业趋势展望
AI编程工具正在从单一的“代码补全工具”进化为“能够执行完整开发任务的Agent”。
Codex Windows版的发布补齐了稳定、安全、可控的本地运行环境这一关键拼图。
当AI能在受系统级沙盒约束的环境中直接运行和修改代码时，一种新的开发模式正在成型。
c.Cline CLI 2.0：从 IDE 侧边栏走向终端
a.重新设计的交互式终端体验
Cline CLI 2.0 提供了一个完整的 TUI，而非简单的命令行工具。核心交互设计包括：
Tab 键切换 Plan / Act 模式：先让 Agent 推理规划，再执行操作，开发者可以控制介入粒度
Shift+Tab 启用自动批准：根据任务信任度灵活调整人机协作的监督程度
会话中途切换模型：根据任务复杂度动态选择模型，避免一刀切
Slash 命令：/history 恢复历史任务，/settings 调整配置，还支持自定义 Markdown 工作流（如 pr-review. md 自动变为 /pr-review）
b.真正可用的并行 Agents
Cline CLI 2.0 最具差异化的卖点。在 IDE 中运行多个代理，意味着多个窗口实例、复杂的状态隔离和大量的手动管理。而在终端中：
使用 tmux 分屏，每个 pane 运行一个独立的 Cline 实例
每个实例完全隔离：独立状态、独立对话、独立模型配置
一个 Agent 重构数据库层，另一个更新 API 文档，互不干扰
c.无头模式与 CI/CD 集成
通过 -y 标志，Cline 进入全自动模式，支持完整的 stdin/stdout 管道操作
Cline 可以嵌入 GitHub Actions、GitLab CI、Jenkins、cron jobs 等任何可以运行命令的环境。--json 标志提供结构化输出，方便程序化消费
这符合 Unix 哲学——小工具、可组合、管道化。AI Agent 不再是一个独立的"应用程序"，而是变成了 shell 工作流中的一个"管道组件"
d.ACP 协议支持
--acp 标志让 Cline 成为一个符合 ACP 标准的 Agent
可以运行在 JetBrains、Zed、Neovim（通过 CodeCompanion 或 avante.nvim）、Emacs 等任何支持该协议的编辑器中
d.Chrome 推出了 WebMCP 的预览版本
a.说明
https://developer.chrome.com/blog/webmcp-epp
推出了 声明式 API ，直接在 HTML 添加一些特殊的 tag，比较简单，还有 命令式 API，执行需要 JavaScript 执行的复杂、更动态的互动。
算是 agentic web 的一个重要基础了。
b.说明
举个例子：之前电商下单。
传统方式要：要反复截图 → 识别“搜索框” → 输入 → 点搜索 → 找商品卡片 → 点加入购物车 → 去结算 → 填地址 → 支付
有了 WebMCP 以后，网站提前注册工具，AI 直接调用这些工具，像调用 API 一样，几步就完成，整个过程几乎不消耗视觉 token，准确率接近 100%。
把原来AI 猜页面的低效模式，变成网站直给函数接口的高效模式。
e.opencode 1.3.0 将不再支持 Claude Max 插件
a.TLDR
opencode 1.3.0 移除了 Claude Max 插件，原因是 Anthropic 派律师来谈了，后续 GitHub 也跟着清理了相关引用。
b.事件背景
今天刷到一个挺有意思的事儿。
opencode 刚刚宣布 1.3.0 版本要把 Claude Max 插件给移了。不是技术问题，是法务问题——原文是这么说的：
"we did our best to convince anthropic to support developer choice but they sent lawyers"。
翻译一下就是：我尽力劝 Anthropic 支持开发者的选择权，结果他们直接派律师来了 🤦
c.大概发生了什么
opencode 之前有个内置插件可以让用户直接用 Claude Max，结果 Anthropic 不干了。
opencode 的态度也挺实在的："你可以选择怎么访问服务，但人家也有权利封杀任何人"。
所以干脆 1.3.0 不再自动加载这个插件了，GitHub 和 npm 上都标记了 deprecated。
不过这里有个小插曲——今天很多人反馈插件炸了，opencode 特别声明说这是 Anthropic 那边自己改的，跟他们 1.3.0 还没发的版本没关系。
d.GitHub清理内容
a.移除anthropic-20250930.txt prompt文件
b.移除provider hints里的anthropic
c.移除opencode-anthropic-auth内置插件
d.移除provider enum里的anthropic
基本上就是按法律团队的要求，把能删的都删了。
e.升级方法
等 opencode 正式发布 1.3.0 版本后，你可以通过 x-cmd 快速升级到最新版本：x env use opencode=v1.3.0
f.Codex 终于支持 Plugins 插件了
a.说明
内置了不少有用的插件比如 Slack、Figma、Notion 等，更新新版可用
Codex 的 Plugin 是一种「可安装的打包单元」，用来把一组可复用的 Codex 工作流（skills、应用集成、MCP 配置等）打包分发。
b.说明
插件在 Codex App、CLI 和 IDE 扩展中通用
而且也内置了插件创建的功能。点击插件页面右上角的“创建插件”，然后跟 Codex 说你要创建什么类型的插件就可以了。
也能手动安装本地插件，插件从「Marketplace」暴露给 Codex。Marketplace 是一个 JSON 文件，列出可供安装的插件。
将插件添加到官方 Plugin Directory 的接口还在建设。
g.Google Stitch 发布了 DESIGN.md
a.说明
一个 Markdown 文件，教会你的 AI Coding Agent 整个设计系统。
不需要导出Figma
不需要JSON
不需要配置
b.说明
直接给Agent，立马理解：
这直接提供了一套完整的包含 40 多个预构建文件的免费合集，这些文件均提取自真实产品，
包括 Stripe、Vercel、Linear、Notion、Lovable、Claude、ElevenLabs、Cursor、Warp、Zapier 等。
把它放到项目根目录下。Claude Code、Cursor、Gemini CLI 和 GitHub Copilot 都能原生读取它。
100% 免费开源。
c.地址
https://github.com/VoltAgent/awesome-design-md
h.harness：模型是原料，框架才是产品
a.核心观点
模型是原料，框架才是产品。AI编程工具体验差异的核心不在模型，而在于外层的harness框架/执行架构。
b.Cursor自主开发成果
Cursor官方数据显示，其代码仓库35%的已合并PR由云端Agent自主完成，AI独立实现功能、自测、处理冲突、整理提交并附带录屏，仅需人类审核。
c.Cursor五层框架设计
a.接入层
任务可从Slack、GitHub、手机、IDE发起。
b.编排层
负责任务规划、模型选择与并行数量决策。
c.执行层
在隔离Linux虚拟机运行，与本机完全隔离。
d.验证层
Agent通过浏览器真人式操作验证功能，录制视频、截图并采集日志。
e.输出层
交付包含视频演示、截图、干净commit记录的完整PR。
d.模型与框架的关系
底层模型可自由替换，Cursor支持同一会话多模型race模式择优，模型是选手，框架是规则制定者。
e.重要性说明
如同购车看重整车体验而非仅发动机，AI编程工具的核心价值在于框架体系，模型可替换但整体体验由框架决定。
f.不同工具框架对比
a.Claude Code
终端优先，代码本地留存，无云端虚拟机，依托强模型与超长上下文，擅长大型架构重构，输出对话日志与代码diff，数据本地化。
b.OpenAI Codex
流程简洁线性，从GitHub Issue创建分支并提PR，无并行与视频验证，适配高度依赖Issue追踪的团队。
g.商业价值体现
Cursor估值293亿美元，核心价值为自研框架，而非模型API转发。
h.工具选择建议
a.多任务并行、需可视化PR验证且接受云端运行→选择Cursor
b.复杂架构深度推理、代码必须本地、重度依赖MCP→选择Claude Code
c.围绕GitHub Issue、需极简Issue→PR流程→选择Codex
i.GoogleforDevelopers官方发布A2UIv0.9，定义生成式UI新标准
a.说明
.GoogleforDevelopers官方发布A2UIv0.9，定义生成式UI新标准推动生成式UI进入便携化时代，支持AI智能体直接生成并渲染用户界面至现有前端框架。
b.四大核心亮点
a.广泛的框架支持
兼容React、Flutter、Angular主流前端框架，可轻松集成。
b.极简的开发体验
提供PythonSDK，通过pipinstall即可快速安装部署，降低AIUI开发门槛。
c.极致的性能表现
支持高性能流式传输，UI界面可实时流畅渲染展示。
d.深度整合设计系统
可集成现有设计系统，保证AI生成界面与应用原有视觉风格统一。
c.技术应用价值
突破AI仅文字对话交互模式，支持AI依据上下文在应用内即时生成完整功能操作面板，革新AI交互深度与广度。
j.OpenAI 更新了 GPT-5.5 Instant 模型，现在变成了 ChatGPT 默认模型
a.说明
OpenAI 更新了 GPT-5.5 Instant 模型，现在变成了 ChatGPT 默认模型。模型提升了实时准确性和日常任务的表现。
b.主要改进
a.性能优化
在法律、金融、医学等领域的幻觉率明显下降。同时，在图片理解和文档解析方面表现更好。
b.表达风格
回答更加紧凑且聚焦要点，减少了无用的铺垫和过渡排版。简单来说就是废话变少了。此外，个性化能力也得到了提升。
c.发布状态
今天已经全量发布。ChatGPT 已经将其设为默认模型，Codex 没有更新。
d.新功能引入：记忆来源
在 GPT 中引入了记忆来源功能。你可以通过控件可视化地查看 memory 来自什么地方，如果发现有问题，也可以直接编辑它。
k.Claude Opus 4.8来了：更像一个能独立推进任务的工程搭档
a.说明
Anthropic 最近推出了 Claude Opus 4.8。
相比 Opus 4.7，这一版本最值得关注的变化，不只是能力更强，而是它在判断力、任务推进和自我反馈上的表现更接近一位成熟工程师。
b.说明
过去使用 AI 编程工具时，一个常见问题是：模型可以写代码，也能回答问题，
但在复杂任务里容易跑偏，需要人频繁介入、反复提醒。Opus 4.8 的重点，正是提升这类长周期任务中的稳定性。
它能够在更长的会话中保持目标，不断跟进仓库里的上下文，围绕一个 feature、一次 bug sweep 或一段重构任务持续推进，而不是做完局部就停下来。
c.说明
更重要的是，它对自身进展的判断也更诚实。不是简单地“看起来完成了”，而是更清楚哪些地方已经处理，哪些地方还存在不确定性。
这一点对研发场景很关键，因为真正影响效率的，往往不是代码能不能生成，而是 AI 能不能像一个靠谱的协作者一样，
把问题说清楚，把边界交代清楚，把后续风险暴露出来。
d.说明
在 Claude Code 中，Opus 4.8 还支持 Fast mode。官方说法是同一个模型，但速度大约提升到 2.5 倍，同时成本相比之前降低到三分之一。
使用方式也很直接，在 Claude Code 里输入 /fast 即可开启；API 侧则需要联系账号经理申请访问，或加入 waitlist。
e.说明
从定位上看，Opus 4.8 并不是单纯追求“更会写代码”，而是在往“能独立接手工程任务”的方向继续靠近。
对于开发者来说，这意味着以后可以把更多时间从重复排查、局部修改和上下文梳理中释放出来，把注意力放在架构判断、产品设计和关键决策上。
f.说明
AI 编程工具的竞争，正在从“谁能生成代码”进入“谁能更可靠地完成任务”的阶段。Opus 4.8 的更新，恰好踩在了这个方向上。
02.大厂新闻
a.Apple已于2026年3月3日正式宣布搭载M5Pro
a.产品发布概况
Apple 已于2026年3月3日正式宣布搭载M5 Pro和M5 Max芯片的14英寸及16英寸MacBook Pro，预售从3月4日起开启，产品将于3月11日开始发售。
b.M5芯片与性能
a.核心规格
核心规格包括10核CPU、10核GPU，最高支持32GB统一内存。
b.性能对比
在LLM提示词处理场景中，该机型的首次token输出时间相比M1 13英寸基准机型提升6.4倍，而搭载M4的同尺寸机型仅为1.8倍。
c.技术优势
这一性能跃升得益于M5芯片对神经网络计算的优化、更高的内存带宽以及更快的存储速度，使本地大模型的响应速度接近实时。
d.适用人群
适合需要快速处理提示词、离线运行7B至13B模型、注重隐私的专业用户和创作者。
c.发售与定价
新款MacBook Pro已于3月4日开启预售，3月11日正式发售。基础配置16GB内存起，32GB版本价格合理。
d.市场评价
M5让本地大模型体验从可用变为流畅，对计划升级设备的用户而言，这一代升级幅度显著。
b.AI提交代码导致GitHub宕机
a.HN传言：AI提交代码导致GitHub宕机
HN 上有人说，GitHub 最近频繁宕机的原因并不是他们在运行 AI 生成的代码，
而是用户在提交 AI 生成的代码，导致提交内容和频率远超以往，GitHub 不堪重负。
b.事实层面数据
a.事故统计
GitHub 在 2025 年上半年事故增加了 58%（从 69 起增至 109 起，其中 17 起为"重大事故"），总中断时间超过 100 小时。
b.官方解释
官方解释，根本原因是 Azure 迁移：GitHub 正在将所有基础设施从自有数据中心迁移到 Microsoft Azure。
c.实际情况分析
a.AI工具改变开发模式
根据 GitHub 自己的报告，Copilot 用户确实更频繁地提交代码，AI 辅助开发可能会产生更多的小粒度 commit。
b.基础设施问题是主因
事故报告明确指向 Azure 配置错误、虚拟机规模操作故障、网络连接中断，这些是基础设施层面的问题，不太可能是代码提交量增加直接导致的。
c.双重压力的可能性
一个可能的中间解释是 Azure 迁移 + AI 工具普及的双重压力，新基础设施可能还没有为 AI 时代的负载特征做好充分优化。
d.有趣的观察
也许是因为 GitHub 频繁宕机，OpenAI 正在开发自己的 GitHub 竞争对手。
这形成了一个有趣的循环：AI 工具增加了平台负载 → 平台不稳定 → AI 公司自己建替代方案。
e.互动话题
你怎么看？你觉得 AI 编程工具是否真的显著改变了 GitHub 的负载特征？
c.Meta买下Moltbook核心意义
a.热点说明
Meta买下Moltbook，买的不是一个平台，而是AI时代的“发言权入口”。
b.收购事件基本信息
最近科技圈一条很容易被忽略的消息，其实分量极重：Meta买下了Moltbook。
这个平台很特别，不是给人发帖的，而是给AI机器人发帖、评论、互相点赞和投票用的。人类只能围观，不能参与。
c.事件表面与深层价值
a.表面认知
乍一看，这像是一个猎奇实验；但如果认真想一层，就会发现它的意义远不止“新奇”。
b.深层价值
过去的社交网络，连接的是人与人；未来的社交网络，可能连接的是AI与AI、AI与工具、AI与商业系统。
也就是说，平台不再只是承载内容，而是在承载“智能体之间的协作关系”。
d.收购的核心意图
a.核心目标
这正是这笔收购最值得警惕的地方。Meta要的恐怕不只是一个小众社区，而是一层新的基础设施。
b.未来演变
今天它只是一个只允许AI发言的社交平台，明天它就可能演变成AI之间互相识别、交换信息、协同行动的底层网络。
谁掌握了这个入口，谁就更有机会定义未来AI世界的互动规则。
e.Meta的战略布局
a.交流掌控范围
换句话说，Meta想掌控的，已经不只是人与人的交流，而是机器与机器的交流。
b.社交图谱构建
过去它构建的是人类社交图谱，未来它想拿到的，很可能是“AI社交图谱”。这两者叠加在一起，想象空间非常大，也非常值得警惕。
f.Meta核心能力与影响
因为Meta本来就极其擅长做分发、推荐、流量调度和平台治理。它知道如何放大什么，压低什么，引导什么，定义什么。
当这种能力从人类内容分发进一步延伸到AI交流网络时，平台影响的就不只是舆论，
而可能是机器如何获取信息、如何彼此调用、如何形成共识，最终又如何反过来影响人的判断和决策。
g.事件本质与行业竞争
a.事件定位
这也是为什么，这件事不能只当成一次普通收购来看。
b.竞争核心
它背后真正的竞争，不是某个产品做得有多酷，而是谁能抢先建立AI时代的“通信协议”和“基础设施入口”。
c.未来网络形态
未来的互联网，在线活跃的可能不只是几十亿人，还会是数以亿计的智能体。
它们会自动发帖、自动回应、自动协作、自动交易，形成一个机器高度活跃的新网络层。
h.行业格局与未来趋势
a.巨头行动
而现在，巨头们显然已经开始抢位了。
b.最终结论
所以，Meta买下Moltbook，买下的绝不只是一个平台。它买下的，可能是AI时代一块极早期。
但非常关键的地基。今天我们还只是旁观者，明天也许就会发现，真正高频交流、持续互动、快速扩散信息的“网民”，已经不再只是人类了。
d.谷歌发布TurboQuant大模型内存瓶颈或迎来关键突破
a.新闻发布
a.发布概况
2026年3月25日，谷歌研究院正式在其官方博客发布了一种名为TurboQuant的新型压缩算法。
b.技术亮点
这是一种无需训练的压缩算法，可将大语言模型的键值缓存量化至3比特，且不会造成任何模型精度损失。
在当前大模型推理成本居高不下的背景下，这项技术引发了业界的广泛关注。
b.核心瓶颈：键值缓存
a.概念定义
键值缓存相当于模型在一次会话中的短期记忆。当用户与大语言模型对话时，模型并不只处理最新的消息，而是将整段对话历史保存在这个结构中。
b.性能挑战
每产生一个新的输出词元，模型都要对缓存中所有历史内容执行注意力计算，上下文越长，内存消耗越大。
c.典型案例
以一个为512个并发用户提供服务的700亿参数大语言模型为例，仅键值缓存就可能消耗512GB内存，几乎是模型权重本身所需内存的四倍。
这是当前大规模部署大模型时面临的核心成本问题之一。
c.TurboQuant解决方案
a.技术架构
TurboQuant结合了两种关键技术：PolarQuant负责几何旋转压缩，QJL负责1比特误差修正，从而在不引入额外开销的前提下实现极致压缩。
b.第一阶段：PolarQuant
将数据向量从标准笛卡尔坐标转换为极坐标，把每个向量分解为表示大小的半径和表示方向的角度。
由于角度分布具有可预测性，PolarQuant可以跳过传统量化器所需的高精度归一化步骤，实现零开销的高质量压缩。
c.第二阶段：QJL算法
算法处理第一阶段残留的微小误差，仅消耗1比特额外空间，但能有效修正内积估算中的偏差，从而保障注意力机制的计算精度。
e.Google AI Studio更新把 Vibe Coding 从“玩具阶段”推到了“能做产品”的阶段
a.Google AI Studio更新概览
Google AI Studio更新把 Vibe Coding 从“玩具阶段”推到了“能做产品”的阶段。
b.后端自动化的突破
a.过去痛点
以前你用 AI Studio，其实就是写写 prompt，生成个页面，demo 能跑，但一旦涉及到用户登录、数据存储、多人协作这些真实需求，就得自己下场写后端，瞬间劝退一大批人。
b.现在突破
但这次不一样了，Agent 会主动帮你把 Firebase、数据库、认证全接上，你基本一句话就能从 0 搞出一个完整应用。说白了，就是把最烦、最杂、最容易卡住的那一层，直接自动化了。
c.系统级问题
AI 已经开始碰“系统级问题”，而不只是写点 UI。
c.Agent角色的转变
更大的变化其实是 Agent 的角色变了。以前是你说啥它写啥，现在更像一个有经验的全栈开发者，会反过来问你：“你这个是不是需要数据库？要不要加登录？要不要接 API？”然后你点个确认，它帮你全配好。这种体验，其实已经有点“带你做项目”的感觉了。
d.未来竞争格局
a.竞争焦点
Vibe Coding 已经进入下半场了。接下来不再是谁生成的 UI 更好看，而是谁能更快把一个 idea 变成真正上线、能跑用户的产品。数据库、认证、支付、实时通信，这些“脏活累活”，才是分水岭。
b.生态布局
Google 这波把 Firebase、Maps、后面可能还有 Workspace 全接进来，其实是在搭一整套“AI 原生开发基础设施”。
e.局限与挑战
当然也别太乐观，能生成 ≠ 能维护。你真要做 production，后面的稳定性、成本、权限、安全这些问题，一个都跑不掉。
f.核心总结
一句话：以前是“AI 帮你写代码”，现在开始变成“AI 帮你把产品搭起来”。
f.Google Stitch 大更新：号称是 Vibe Design
a.背景与影响
a.市场反应
Figma 股价大跌 8.8%。
b.核心定位
号称是 Vibe Design，对着画布说话就能做设计。
b.五大核心升级
a.无限画布
a.工作台演变
从输入一句话等出图，转变为拥有一个真正的工作台。
b.协作体验
可以把参考图、文字说明、代码片段全扔上去，AI 结合这些上下文帮你设计，更像在跟一个设计师协作。
b.更智能的设计Agent
a.项目记忆
能记住整个项目的修改历史，不是每次从零开始理解需求。
b.并行方案
能同时帮你推进多个方案，比如同时试三种不同风格的首页，互不干扰。
c.语音交互
a.操作方式
对着画布说话即可，例如“这个按钮大一点”、“配色换暖色调”、“导航栏改成深色”。
b.效率优势
不用停下来打字，边看边改，效率高很多。
d.即时原型
a.交互能力
点一下播放键，设计稿直接变成可以点击交互的原型。
b.逻辑生成
系统自动帮你算好“点这个按钮跳到哪个页面”，不用手动一根根连线。
e.新增DESIGN.md
a.文件定义
把设计规范（配色、字体、风格）写成一个文件。
b.生态互通
Claude Code、Cursor 等编程工具都能读懂，设计规范不再锁死在一个工具里。
g.Perplexity AI 已经基本完成了产品闭环
a.说明
Perplexity AI 已经基本完成了产品闭环：
他们现在把 Search（搜索）+ Computer（AI 数字员工）+ Comet（浏览器）+ 原生 App 全部打通，
全平台（桌面 + 移动端）覆盖，形成了一个从“查询 → 研究 → 自动执行任务”的完整生态，
用户基本不用跳出 Perplexity 生态就能搞定大部分生产力工作。
b.说明
Perplexity 的产品品味在整个 AI 行业真的算顶尖，交互和 UI 都做得干净、高级、有质感，用着舒服。
h.终端界的门槛，这次被 Warp 彻底干掉了
a.核心亮点
a.Block 块状输出
每条命令自动变成独立卡片，可折叠、搜索、单独复制、分享。
b.AI Agent 原生嵌入
自然语言直接指挥 AI 写代码、改代码、跑测试、生成脚本。
c.IDE 级交互
鼠标选中就能编辑命令、代码高亮 diff、直接加 Comment。
d.智能搜索
顶部一框搜 Sessions、Agents、Files，历史命令再多也能秒找。
e.OpenAI 官方背书
OpenAI 是 Founding Sponsor，提供资金 + GPT 模型深度支持。
b.为什么用 Warp 就很丝滑
让你的命令行操作从几分钟变几秒，效率翻倍，智能化操作轻松搞定一切。
c.实际使用示例
a.输入指令
输入：帮我把这个目录打包成 Docker image 并推到 registry
b.AI 响应结果
AI 直接生成完整命令 + 可执行块 + 解释，一键执行。Rust 原生编写，跨平台（Mac/Windows/Linux），速度极快。
d.项目信息
a.用户规模
全球已有数十万开发者在用 Warp。
b.代码仓库
https://github.com/warpdotdev/warp
i.Zed 1.0 正式发布
a.说明
昨天刚被 Warp 开源大新闻刷屏，今天另一款同量级的 Rust 神器 Zed 正式发布 1.0 版。
b.Zed 与 VS Code 的共同起源
Zed 和 VS Code 其实师出同源。2011 年，GitHub 团队推出 Atom 编辑器，
有三位核心创始人 Nathan Sobo、Max Brunsfeld、Antonio Scandurra，
他们用自研的 Electron 框架打造了 Atom，让编辑器高度可定制、支持实时多人协作，一度风靡开发者社区。
c.Electron 的扩散与 VS Code 的诞生
Electron 正是 Atom 团队推动的成果，后来被微软广泛采用。2015 年微软基于 Electron 开发了 VS Code，进一步普及了这一技术。
d.Atom 的落幕
Atom 虽开创"黑客式"编辑器时代，但 Electron 的性能瓶颈逐渐显现。2017 年起，Atom 团队已意识到问题，
内部多次讨论"必须从头再来"。2022 年 GitHub 停止维护 Atom，团队彻底告别 Electron。
e.Zed 的诞生与发展历程
a.重构与开源
2023 年，团队推出 Zed，完全从零重构。Zed 继承 Atom 的协作精神和"让编辑器消失"的理念，实现了极致速度与流畅体验。2024 年宣布开源。
b.融资与用户规模
2025 年获得 Sequoia Capital 3200 万美元融资，当时每月活跃用户已达 15 万。
f.Zed 的定位
Zed 不是 Atom 的简单续集，而是其创始团队针对 Electron（及 VS Code）时代痛点的终极进化版，从网页壳的局限中涅槃，开启了代码编辑器全新历史。
j.Cursor 官方 TypeScript SDK 公测开放
a.Cursor 官方 TypeScript SDK 公测开放
Cursor 今天开放了官方 TypeScript SDK 公测，把驱动自家编辑器、CLI 和网页版的智能体整套打包交给开发者。安装方式如下。
a.安装命令
---
npm install @cursor/sdk
---
b.调用方式与运行模式
a.本机模式
Agent 可以跑在本机。
b.云端模式
Agent 可以塞到 Cursor 云端的独立虚拟机里。云端模式下每个 agent 都有专属沙箱、克隆好的代码仓库和配置完整的开发环境，电脑休眠或断网都不影响任务继续，干完活还能直接开 PR、推分支、附上截图。
c.模型层
模型层面不绑定，OpenAI、Anthropic、Google 的前沿模型可以一键切换，也能跑 Cursor 自家的 Composer 2（专为编码训练的模型，号称用更低成本接近前沿水平）。
c.SDK 开放的核心能力（harness）
SDK 把 Cursor 平时藏在编辑器里的那套智能体运行框架整个开放了出来，包括以下能力：代码库索引；语义搜索；即时 grep；MCP 工具接入；从仓库 .cursor/skills/ 目录自动加载的技能；可以观察和干预 agent 循环的 hooks；以及把任务拆给子 agent 的能力。
d.典型使用场景
a.CI/CD 流水线
在 CI/CD 流水线里自动总结改动、定位失败原因、自动提修复 PR。
b.内部工具
做内部工具让销售和市场团队不写代码就能查产品数据。
c.嵌入自家产品
把 Cursor 直接嵌进自家面向客户的产品里，让最终用户在不离开宿主应用的情况下用上 agent 体验。
d.用户案例
Faire 的工程经理 George Jacob 表示，他们以前要自己管虚拟机、绕开内存限制，现在能直接复用 Cursor 的云端运行时来维护代码库。
e.计费与资源
a.计费方式
计费按 token 用量算。
b.示例项目
GitHub 上的 cookbook 仓库放了几个示例项目，包括：最简版的本地 agent；网页原型工具；能拖卡片自动开 PR 的看板；以及命令行工具。
f.行业背景与定位
a.竞争格局
Anthropic 早些时候推出了 Claude Agent SDK，OpenAI 也有 Codex 相关 SDK，agent 基础设施本身正在变成一门独立生意。
b.Cursor 的策略
Cursor 这次相当于把自己卖给开发者的核心能力打包出售。你既可以付费用它的编辑器，也可以付费让它替你跑 agent。
g.Cursor SDK 与 Anthropic、OpenAI SDK 的本质差别
a.Anthropic 与 OpenAI 的 agent SDK
本质是 wrapper，本地能跑，自己接模型就行。
b.Cursor SDK
必须用 Cursor 的 API key，必须经过 Cursor 云。
c.两种解读
讲难听一点是 lock-in，讲好听一点是平台战略。哪种说法更准，取决于接下来两年模型层会变成什么样。
h.模型层商品化趋势
模型在快速商品化，Claude 跟 GPT 跟 Gemini 一年比一年像，单价一年比一年低。真正还能做差异化的，越来越是 agent runtime 这一层。
i.Cursor 押注的核心：agent runtime 层
a.差异化方向
真正还能做差异化的，越来越是 agent runtime 这一层。
b.这一层包含的关键能力
sandbox；computer use；状态管理；重试逻辑；可观测性。这些事没有一件是 prompt 能搞定的。
c.Cursor 的战略押注
Cursor 押的就是这一层。
03.热点新闻
a.2026年模型军备竞赛
a.GPT-5.5 正式发布，奥特曼向马斯克发出和解派对邀请
OpenAI 于 2026 年 5 月 5 日在旧金山举办 GPT-5.5 发布派对，Sam Altman 公开在 X 上向正在对簿公堂的 Elon Musk 发出邀请，
写道：他想来就来，世界需要更多爱。马斯克与 OpenAI 的 $1340 亿官司本周在加州联邦法院开庭审理，
马斯克本人出庭作证，指控 OpenAI 从非营利使命偏离为微软支持的营利实体。
奥特曼随后参加了亚马逊与 OpenAI 在旧金山联合举办的 Agentic AI 发布活动。
b.五角大楼 AI 合作名单：Anthropic 缺席
美国国防部本周正式宣布 7 家 AI 合作伙伴进入其机密网络：OpenAI、Google DeepMind、NVIDIA、Microsoft、SpaceX、Reflection AI、AWS。
Anthropic 再次缺席。此前国防部将 Anthropic 列为"供应链风险"并禁止使用，Anthropic 已提起诉讼。
Anthropic 明确表示：无法确保 Claude 不会被用于自动化致命决策。这一立场与其"安全优先"的公司使命一致，但也意味着其失去了巨大的政府客户。
c.融资与 IPO 战场
公司 目标估值 预期 IPO 时间 募资目标
SpaceX $1.75 万亿 2026 年 6 月 $4000-8000 亿
Anthropic $3800 亿 2026 年 10 月 $600+ 亿
OpenAI ~$1 万亿 2026 年 Q4 未披露
SpaceX 若以 $1.75 万亿估值上市，将超越沙特阿美 $1.7 万亿的历史记录，成全球最大 IPO。
OpenAI CFO Sarah Friar 对 Q4 时间表存有疑虑，认为公司运营准备度和收入轨迹尚未就绪。
d.消费级 AI 硬件元年
2026 年被视为消费级 AI 硬件元年，三大科技巨头同周宣布重磅动作。
公司 产品 时间表
Google Android XR 智能眼镜（与三星、Warby Parker、Gentle Monster 合作） 2026 年内
OpenAI AI 硬件设备（收购 Jony Ive 的 IO，$65 亿） 2026 年
Apple Siri 增强智能眼镜 2026 年
OpenAI 的目标设备可放置在口袋或桌面，作为 iPhone 和 MacBook Pro 的补充而非替代。
b.Anthropic 融资狂飙：$40B 牵手 Google，$900B 估值冲刺 IPO
a.融资动态
a.Google 投资
Google 承诺即刻投入 $100 亿现金（估值 $3500 亿），若达成特定业绩目标，将追加投入至多 $300 亿，总投资达 $400 亿。Google Cloud 将同期交付 5 吉瓦算力，足以支撑 Anthropic 的超大规模模型训练。
b.Amazon 投资
Amazon 同时投入 $50 亿现金，承诺 10 年内向 AWS 支出 $1000 亿，并提供近 1 吉瓦的 Amazon Trainium 芯片算力。
c.新一轮融资
仅数周后，Anthropic 即启动新一轮融资，目标金额 $500 亿，对应估值超 $900 亿——14 个月内估值从 $615 亿飙升至 $9000 亿，超越 OpenAI（$8520 亿）成为全球最值钱 AI 初创公司。
b.收入爆发
Claude Code（AI 编程工具）是本轮融资狂潮的核心催化剂。Anthropic 年化收入从 2025 年底的约 $90 亿飙升至当前的 $300 亿+，企业客户中年消费超 $100 万的客户数已超过 1000 家。
c.IPO 进展
Anthropic 已接触高盛、摩根大通、摩根士丹利，最早有望于 2026 年 10 月完成 IPO，募资目标超 $600 亿，或成全球第二大 IPO。
2.8 大厂新闻2
00.汇总
a.leak
axios供应链投毒攻击
一个月下载9500万次的Python库LiteLLM被投毒了
b.hermes
HarnessEngineering 搞AI的人开始玩马了
Karpathy最新的干货输出：能够进化的知识库
Karpathy的Agent使用心法——从"提示词工程师"到"智能调度师"
Hermes Agent工作流：用顶级AI Newsletter构建第二大脑，再也不怕学不动AI
从"工具调用"到"自我进化"：Hermes Agent 重新定义 AI Agent 的学习方式
c.openclaw
BibiGPT更新
OpenClaw生态创业
小米推出国内首个手机端类OpenClaw智能体
火山的ArkClaw把养虾的门槛打到地板了
飞书做了一个超安全且功能更强大的龙虾
QClaw简评：腾讯的"保守式创新"
OpenClaw3.22Beta：停更9天憋出的一次"换骨"级升级
01.leak
a.axios供应链投毒攻击
a.说明
投毒讨论帖：https://github.com/axios/axios/issues/10604
目前已确认开发者账号被接管，覆盖面极大🥲
分析链接：https://stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
攻击者篡改[email protected]和[email protected]，植入恶意依赖[email protected]
b.说明
如果你的龙虾是旧版本，请不要升级！！看到推友留言：早上升级Openclaw 3.28 版本已经中招：
[email protected] 位于全局路径：~/.npm-global/lib/node_modules/openclaw/node_modules/axios（被 OpenClaw 的内部依赖使用）
未在全局 npm 或当前工作区中找到 [email protected]
b.一个月下载9500万次的Python库LiteLLM被投毒了
a.说明
一个月下载9500万次的Python库LiteLLM被投毒了
你只要装了它，电脑上的密码、密钥、云账号、加密钱包全部自动发给黑客。
更狠的是，很多人根本不知道自己装了——它藏在别的AI工具的依赖里，静默执行。
b.说明
如果你最近用pip装过任何AI相关的包，现在就查一下：pip show litellm。版本号是1.82.7或1.82.8的，立刻删除，立刻换密码。
02.hermes
a.Harness Engineering 搞AI的人开始玩马了
a.搞 AI 的人开始玩马了
a.术语由来
马具工程你可能没听过，因为大家现在都不这么说。大家的说法更高大上——Harness Engineering。
英语里 harness 原本是名词，指“马具、安全带、束具”，也就是把力量固定、约束、导向的装置；
也可以作动词，表示“利用、驾驭、控制某种力量”。Cambridge Dictionary 里对名词的解释就是用于控制或固定人、动物、物体的一套带具；
动词则有“利用某种力量”的含义。放到 AI 里，非常贴切。
b.概念对照表
原义 AI 语境
马有力量，但需要马具 模型有能力，但需要工程系统
安全带防止人失控受伤 权限、沙箱、审计防止 Agent 失控
harness power = 利用能量 harness model = 驾驭模型能力
harness as equipment Agent 外部运行设施
c.暂定译名
不过，要怎么翻译呢？不知道，姑且先叫马具工程吧。
b.这个词从哪里来的
a.历史背景
它不是凭空冒出来的，也不是完全新概念。早期大家说的是 Prompt Engineering、Context Engineering、
Tool Use、Agent Framework、Scaffolding、Orchestration、Guardrails、Evaluation、Memory、Workflow 等，
这些其实都是 Harness 的局部。
b.概念的成型
后来随着 coding agent、browser agent、long-running agent 发展，大家发现：
只讲 prompt、RAG、tool calling 已经不够了。真正决定 Agent 好不好用的，不是单个提示词，
而是模型外面整套运行环境。所以 2026 年前后，Harness Engineering 这个说法开始集中出现。
c.权威定义
a.OpenAI 的视角
OpenAI 在 2026 年 2 月发布了 “Harness engineering: leveraging Codex in an agent-first world”，
里面讲他们用 Codex 构建内部产品，核心不再是人手写代码，而是人设计文档、架构、验证、计划、运行环境，让 Agent 可持续工作。
b.Martin Fowler 的定义
Martin Fowler 也明确把 harness 概括为：AI agent 中除模型本身之外的一切，也就是常见的公式：Agent = Model + Harness。
他同时提醒这个定义很宽，在 coding agent 场景里还需要进一步收窄到上下文、架构约束、反馈、验证和清理机制。
c.LangChain 的观点
LangChain 的说法也类似：Agent = Model + Harness，模型包含智能，
Harness 让智能变得有用；它包括文件系统、沙箱、记忆等让模型能变成“工作引擎”的能力。
c.Harness 跟其他名词的区别
a.相关概念辨析
Framework 是开发者用的框架，比如：LangChain、LangGraph、CrewAI、AutoGen。
Workflow 是固定流程，比如：检索 → 总结 → 生成报告。Agent 是能感知任务、选择动作、调用工具、观察结果并继续行动的执行体。
Harness 是把 Agent 变得可用、可控、可评估、可进化的整套外部系统。
b.系统构成关系
a.Model
脑子
b.Agent
脑子 + 行动循环
c.Workflow
固定流程
d.Framework
开发工具箱
e.Harness
运行制度 + 工具 + 约束 + 记忆 + 验证 + 反馈
f.总结
所以 Harness 不是某一个库，也不是某一种 Agent 框架。它更像：AI Agent 的操作系统 + 规章制度 + 工具箱 + 质量体系。
d.Harness 怎么演进
a.演进阶段概览
大约会经历五个阶段。
b.阶段一：Prompt Harness
现在很多人还停留在这个阶段，天天改提示词。
特点是：system prompt、few-shot example、output format、role instruction、checklist。
这属于最低级 Harness。它能改善输出，但不能稳定执行复杂任务。
c.阶段二：Tool Harness
Agent 开始能调用工具：search、file read/write、code execution、browser、database、API、MCP tools。
这个阶段的重点是工具协议、工具选择、权限边界和错误处理。
d.阶段三：Workflow Harness
系统开始把 Agent 放进流程里：Task Spec、Plan、Execute、Verify、Review、Handoff、Run Log。
这时 Agent 不再是“自由发挥”，而是在制度内行动。
Coding Agent、Research Agent、Data Agent、Browser Agent 都会形成自己的 Harness 模板。
e.阶段四：Evolving Harness
Harness 不再只是静态配置，而会从失败中演化：失败记录、归因分析、生成新规则、
生成新 eval、更新 skill、更新 memory、回归测试、升级 / 回滚。
这个阶段会出现一个关键变化：Agent 不只是完成任务，还会改进完成任务的方式。这大概就是领导们、客户们一直念叨的自学习了。
f.阶段五：Meta-Harness / Agent Operating System
未来应用可能不再是单个 Agent，而是管理一组 Agent 的运行层。
它会包含：任务路由、模型路由、上下文路由、工具权限、记忆管理、评测系统、成本控制、安全审计、多 Agent 协作、失败归因、自动回滚、组织知识沉淀等。
这时 Harness 会变成一种 Agent OS。这大概就是 Harness 的终局方向。
b.Karpathy最新的干货输出：能够进化的知识库
a.背景介绍
a.原文来源
原文来自 Andrej Karpathy 的X分享。
b.核心理念
我用 LLM 搭建了一个自我进化的知识库。
b.一个转变：从写代码到管理知识
a.发现的变化
最近我发现一个有趣的变化：我的 token 消耗，从操作代码越来越多地转向操作知识。
b.新的工作流
不是让 LLM 帮我写代码，而是让它帮我整理、连接、检索知识。这种方式比传统的笔记软件更高效——因为我不需要自己写。
c.核心架构：LLM 编译的知识库
a.系统构成
整个系统可以分为五个模块：数据摄入 → 编译成 Wiki → Q&A 检索 → 输出生成 → 健康检查。每个环节都由 LLM 驱动，我几乎不手动编辑 Wiki。
b.数据摄入
a.数据来源
我把所有原始资料放进 raw/ 目录：文章、论文、代码仓库、数据集、图片。
b.数据转换
然后用一个工具把它们转成 .md 文件。
我常用的是 Obsidian Web Clipper 扩展——可以把网页文章一键保存为 Markdown，顺便下载所有相关图片到本地。
c.转换目的
这样 LLM 就能轻松引用这些图片。
c.编译成 Wiki
a.核心功能
这一步是核心。LLM 会「编译」raw/ 目录，
生成一个结构化的 Wiki：所有数据的摘要、反向链接（backlinks）、概念分类、概念文章、文章间的链接。
b.组织形式
Wiki 本质上就是一个 .md 文件集合，按目录结构组织。
c.维护方式
关键点：Wiki 由 LLM 写入和维护，我很少直接编辑。
d.前端：Obsidian
a.使用方式
我使用 Obsidian 作为「IDE」：查看 raw 数据、查看编译后的 Wiki、查看生成的可视化。
b.插件生态
Obsidian 的插件生态很有用：Marp：把 Markdown 转成幻灯片；各种图表插件：数据可视化。
e.Q&A 检索
a.应用场景
当 Wiki 足够大时（比如我最近的一个研究项目有 ~100 篇文章，~40 万字），就可以对它提问了。
b.工作原理
LLM 会：自动维护索引文件、维护所有文档的简短摘要、阅读相关数据并回答问题。
c.效能发现
一个发现：我以为需要复杂的 RAG 系统，但实际上，LLM 在这个规模（~40 万字）下表现很好，能自动找到相关文档。
f.输出生成
a.输出形式
回答不只是文本，而是各种格式：Markdown 文件、幻灯片（Marp 格式）、Matplotlib 图表。
b.查看方式
这些都用 Obsidian 查看。
c.知识累积
更有意思的是，我经常把输出「归档」回 Wiki，让它越来越完善。我的探索和提问，总是会「累积」在知识库里。
g.健康检查
a.维护功能
LLM 可以对 Wiki 做「linting」：发现不一致的数据、补充缺失数据（通过网页搜索）、发现有趣的连接，建议新文章、清理和增强数据完整性。
b.功能建议
LLM 还擅长建议「下一步该问什么问题」。
h.额外工具
a.工具开发
我开发了一些小工具来处理数据：一个简单的搜索引擎（Web UI + CLI）。CLI 版本可以交给 LLM 作为工具使用。
i.未来方向
a.发展规划
当 Wiki 越来越大，自然的想法是：合成数据生成 + 微调，让 LLM 把这些知识「记住」在权重里，而不仅仅是上下文窗口。
d.完整工作流
a.步骤总结
总结一下：1. 收集数据 → raw/ 目录 2. LLM 编译 → Wiki（.md 文件集合）3. Obsidian 查看
4. CLI 工具操作（Q&A、增强 Wiki）5. 输出归档回 Wiki 6. 定期健康检查。
b.核心理念
我几乎不手动写或编辑 Wiki——那是 LLM 的领域。
e.为什么这个方法有效
a.知识不再碎片化
传统笔记的问题：写了就忘了，很难检索，没有连接。这个方法：所有知识都被「编译」进一个连接的网络。
b.检索成本极低
不需要复杂的标签系统、不需要精心设计的目录结构。直接问 LLM，它会找到相关内容。
c.知识会「生长」
每次提问、每次探索，都会沉淀回 Wiki。你的知识库不是静态的，而是随着使用越来越丰富。
d.减少手动操作
我不擅长整理笔记。但 LLM 擅长。让它做它擅长的事。
f.实现细节
a.准备工作
如果你想自己搭建，需要：工具栈（Obsidian（前端）、Obsidian Web Clipper（网页保存）、
一个 LLM（Claude、GPT、本地模型都可以）、一些 Python 脚本（或让 LLM 写））和目录结构。
b.目录结构
---
knowledge-base/
├── raw/ # 原始数据
│ ├── articles/
│ ├── papers/
│ ├── images/
│ └── repos/
├── wiki/ # 编译后的 Wiki
│ ├── concepts/
│ ├── articles/
│ └── index.md
├── tools/ # CLI 工具
└── outputs/ # 生成的输出
---
c.关键 Prompt
a.让 LLM 编译 Wiki 的核心提示
你是一个知识编译器。阅读 raw/ 目录中的所有文档，生成一个结构化的 Wiki，
包括：1. 每篇文档的摘要 2. 概念提取和分类 3. 文章间的链接 4. 反向链接索引
b.让 LLM 回答问题的核心提示
你有一个 Wiki 知识库。用户会问你问题。
请：1. 阅读索引文件了解 Wiki 结构 2. 找到相关文档 3. 综合回答 4. 如果需要，生成 Markdown 文件或图表
g.局限性
a.规模限制
当 Wiki 超过某个规模，简单的索引可能不够，需要更复杂的 RAG。
b.LLM 成本
频繁调用 LLM 会产生 token 成本。
c.工具依赖
需要一些脚本和工具链。
d.学习曲线
需要时间调优工作流。
h.未来可能
a.产品愿景
原作者说了一句我很认同的话：
I think there is room here for an incredible new product instead of a hacky collection of scripts.
b.最终结论
是的，这里有巨大的产品空间。一个LLM 原生的知识管理工具，不是AI 增强的笔记软件，而是从零开始设计的知识编译引擎。
c.Karpathy的Agent使用心法——从"提示词工程师"到"智能调度师"
a.内容概述
Karpathy 最近在 No Priors Podcast 分享的 10 条 Agent 使用心得，笔者觉得非常值得学习。
这篇内容没有宏大叙事，全是一个顶级工程师踩过坑后的实战感悟。x上面有大佬总结了一下视频的内容，把最有价值的部分梳理出来。
b.宏观思维：别再盯着代码行了
a.核心理念
Karpathy 提的第一个建议就有点颠覆认知：把 Agent 当作"功能交付单元"，而不是"代码生成器"。
传统编程思维是"我写一行代码，它执行一行"。但 Agent 时代的正确姿势是：我描述一个功能，Agent 负责完整实现。
b.实操建议
把屏幕分成多个 Agent 会话，每个负责不同功能。比如一个写 API、一个写测试、一个写文档。你只负责 Review 和整合。
c.出问题先自查：大概率是"技能问题"
a.核心观点
Karpathy 说了一句很扎心的话："当 Agent 没效果时，几乎总是技能问题。
"这里的"技能"不是指模型能力，而是你配置 Agent 的技能——你的 Prompt 写得够不够清晰？
你的 AGENTS.md 文件有没有告诉 Agent 项目上下文？你的 Memory 工具设置对了没有？
b.实践经验
笔者深有体会。之前让 Agent 帮我改代码，它总是改不到点子上。
后来我把项目架构、代码风格、关键模块都写进了一个 AGENTS.md 文件，效果立马提升一个档次。
c.自查清单
a.Prompt是否足够具体
例如："优化代码" vs "把这段代码的时间复杂度从 O(n²) 降到 O(n)"
b.Agent是否了解项目上下文
例如：有没有提供 README、配置文件、关键代码
c.任务是否拆分得当
例如：一个 Agent 干一件事，别让一个 Agent 做全栈
d.去瓶颈化：你不是 Prompt 的"中转站"
a.核心理念
你的目标是让自己从工作流中消失。很多人用 Agent 的方式是：我提问 → Agent 回答 → 我再提问 → Agent 再回答……这样你永远是瓶颈。
Karpathy 的建议是：设计完全自主的 Agent 工作流。
b.具体做法
举个例子：与其让 Agent 写完代码等你 Review，不如配置一个"写代码 → 跑测试 → 自动修 bug → 再测试"的循环。你只需要在最后验收成果。
c.模式总结
笔者把这个模式叫"甩手掌柜模式"：输入少量 Token，产出大量工作。
e.肌肉记忆：Agent 编排也是一门手艺
a.技能定义
Karpathy 把 Agent 编排比作"需要刻意练习的技能"。这不是看几篇教程就能学会的。
b.练习要点
a.多窗口管理
学会在屏幕上同时开多个 Agent 窗口。
b.节奏感培养
培养分配任务的节奏感（什么时候并行、什么时候串行）。
c.信任与介入
知道什么时候该信任 Agent、什么时候该介入。
c.进阶建议
笔者的建议：先从简单的并行任务开始练手。比如同时让两个 Agent 分别写前端的两个组件，习惯这种工作节奏后再尝试更复杂的编排。
f.指令文件是可调优的"代码"
a.核心认知
这一条笔者特别认同：你的 AGENTS.md、Prompt 模板不是文档，是代码。不同的指令会产生不同的行为。
b.优化策略
a.对比实验
同一任务用不同指令，看哪个效果更好。
b.迭代优化
把好用的指令沉淀下来。
c.自我进化
甚至让 Agent 帮你优化指令（Agent 可以写更好的 Agent 指令）。
c.实践经验
笔者自己的实践：维护一个"Prompt 版本库"，每次发现更好用的写法就更新进去。这比每次从头写 Prompt 效率高太多。
g.用 Agent 做API的粘合剂
a.案例分享
如果各种工具都暴露 API，一个 Agent 就能统一调度它们。Karpathy 举了个例子：他把整个智能家居整合到一个 WhatsApp 助手里。
不用打开六个不同的 App，直接一个对话搞定。
b.价值理解
Agent 的价值不在于"替你写代码"，而在于成为你和各种系统之间的统一接口。你的日历、邮件、代码仓库、项目管理工具……
如果能通过 Agent 调用，就不需要在各种 UI 之间跳来跳去。
h.持久化循环：让 Agent 自己跑
a.思维转变
超越"单次对话"的思维，搭建能够持续运行的 Agent。
b.配置要点
a.环境隔离
给 Agent 独立的沙盒环境。
b.记忆完善
配置更完善的 Memory 系统。
c.跨会话恢复
让 Agent 能跨会话恢复工作。
c.应用场景
比如让 Agent 监控某个数据源，发现异常自动处理，处理完给你发通知。你不需要一直盯着，Agent 自己就在干活。
i.能力是"锯齿状"的，不是均匀的
a.能力模型
模型不是所有方面都一样强。Agent 在"可验证的任务"上非常强（写代码、跑测试、通过 CI），
但在"软性任务"上还很弱（理解微妙意图、把握幽默感、做出价值判断）。
b.实操建议
a.优势领域
让 Agent 做能被测试验证的事。
b.劣势领域
需要判断、品味、创意的事，还是自己来。
c.工作流设计
设计工作流时，把这两类任务分开。
j.文档写给 Agent 看，不是给人看
a.前瞻观点
与其写 HTML 格式的用户指南，不如写 Markdown 格式的 Agent 指令。因为如果 Agent 理解了你的代码库，
它就能用任何语言向任何人解释，而且有无限耐心。
b.角色定位
你的任务是提供那些"Agent 无法生成的核心洞见"，其他解释性工作交给 Agent。
c.实践案例
项目文档现在主要写给 Agent 看。人类用户有问题？让 Agent 帮他们解答。
k.专注 Agent 做不了的事
a.战略价值
你的价值在于那些 Agent 做不了的事。
b.具体领域
创造性洞察、品味判断、新颖的问题框架、战略决策。其他一切，都可以交给 Agent。而且 Agent 会越做越好。
l.总结：从"程序员"到"智能调度师"
a.角色转变
回顾这 10 条建议，其实都在说一件事：Agent 时代，你的角色要变。以前是"我来写代码"，
现在是"我来调度 Agent 写代码"。以前是"我掌握所有细节"，现在是"我掌握核心决策，细节交给 Agent"。
以前是"我是瓶颈"，现在是"我要从工作流中消失"。
b.历史对比
这和当年从"手写汇编"到"写高级语言"的转型很像。每次工具升级，程序员的价值都会上移一层。
Agent 只是这个进程的最新一环。别把 Agent 当成"更好的代码补全"，它是一个全新的工作模式。
c.行动指南
尽早建立肌肉记忆，你就能比别人早一步跨过"技能问题"这道坎。
m.参考资料
a.来源
Karpathy's 10 Actionable Insights for Working with AI Agents - Dan McAteer
d.Hermes Agent工作流：用顶级AI Newsletter构建第二大脑，再也不怕学不动AI
a.引言：构建AI时代的第二大脑
每天都有新的AI内容出现，但很多人刷完后发现什么都没记住，感觉自己在AI浪潮中像个局外人。
这不是不够努力，而是学习方式出了问题。如果把学习方式反过来，利用Hermes Agent构建工作流，
不仅能跟上AI发展，还能提升文章输出质量，连续打造爆款文章。本文将拆解这套完整工作流。
b.第一步：换掉信息源与构建获取管道
a.高质量AI newsletter清单
以下是从50+源中筛选出的高质量信息源，建议订阅海外源头以获取第一手信息。
a.The Rundown AI
therundown.ai：每日AI产业动态，通俗易懂、密度高。
b.TLDR AI
tldr.tech：5分钟科技简报，AI加编程加产品精华浓缩。
c.The Neuron
theneurondaily.com：面向非技术读者的AI日报，3分钟读完。
d.Ben's Bites
bensbites.com：Ben Tossell的AI日报，工具圈消息源。
e.Latent Space
latent.space：swyx开发者简报，未公开项目加工程视角。
f.Smol AI News
smol.ai/news：Discord、Reddit等AI社区圈内直击。
g.Interconnects
interconnects.ai：Nathan Lambert的RLHF、模型训练深度专栏。
h.One Useful Thing
oneusefulthing.org：Ethan Mollick的AI实用洞察，学术加工作场景。
i.AI Breakfast
aibreakfast.beehiiv.com：每周一份AI新闻早餐，系统回顾加深度讨论。
j.Every
every.to：科技与商业的下一步，资深专家战略分析。
b.第一步：给Hermes配置邮箱
a.申请专属邮箱
为了让Agent接收高质量信息源，需要申请一个Agent专属邮箱，例如网易的Claw邮箱产品。
b.创建主邮箱
使用激活码创建主邮箱（如[email protected]）。
c.第二步：装 mail-cli
a.功能说明
安装mail-cli后，Agent能读邮件、搜关键词、拉正文，将邮箱变成输入管道。
b.安装命令
---
# 1. 全局安装 mail-cli
npm install -g @clawemail/mail-cli
# 2. 把 API Key 写进系统钥匙串
mail-cli auth apikey set ck_live_xxxxxxxxxxxxxxxx
# 3. 登录主邮箱
mail-cli auth login --user [email protected]
# 4. 测试连接通了没
mail-cli auth test
---
c.配置CLI技能
利用Hermes的自学习能力，阅读CLI文档并制作专门的Skill来操纵CLI。
d.第三步：构建 newsletter 专属子邮箱
a.创建子邮箱
建立专属子邮箱以隔离不同信息，提升处理效率。
---
mail-cli clawemail create \
--prefix newsletter \
--type sub \
--display-name "Newsletter Bot"
---
b.设置通讯规则
在Dashboard中开放外部通信，收信范围选所有人。
e.第四步：子邮箱订阅newsletter
a.订阅流程
订阅框填入子邮箱地址，确认邮件到达后，利用Agent提取确认地址或回复邮件完成订阅。
b.自动化优势
此时Newsletter已进入Agent专属邮箱，随时可读，领先大多数人。
c.第二步：筛选消化信息，Hermes构建第二大脑
a.第一步：扫 Digest
a.功能介绍
利用Agent初筛newsletter，节约时间且不漏热点，挑出最值得深读的文章。
b.安装日报命令
---
npx skills add https://claw.163.com/gitea-web/s/daily-report.git
---
b.第二步：让 LLM Wiki 将newsletter拆进知识库
a.LLM Wiki 理念
LLM Wiki像一个实习生，将文章中的概念、实体、主张拆解成索引卡片并链接，形成活的知识图。这符合Karpathy提出的知识编译器理念。
b.具体操作
让Hermes将感兴趣的文章编译到Wiki，获得互相链接的Markdown文件网络。
c.知识关联与效果
在知识图中不断问Hermes拆解概念，新知识会自动与旧知识关联，实现读一篇等于刷新十篇的效果，且不易遗忘。
d.第三步：用Hermes LLM Wiki倒逼产出
a.产出准备
学习为了输出，把Wiki里的index文件给AI，让其读取Wiki内容。
b.做信息图
使用Hermes Agent内置的信息图命令行，结合Wiki知识直接生成信息图。
c.自己写文章，AI 做脑爆
a.写作辅助
AI做脑暴提供多角度和灵感，解决盲点，但核心逻辑需要自己想明白。
b.自动化排版
参考开源Skill，实现自动AI排版并发送到公众号草稿箱。
e.从"工具调用"到"自我进化"：Hermes Agent 重新定义 AI Agent 的学习方式
a.从"工具调用"到"自我进化"：Hermes Agent 重新定义 AI Agent 的学习方式
阅读本文大概需要 3 分钟。你有没有遇到过这种情况——花了大半天调教了一个 AI 助手，
结果它还是会在同一个地方犯错，下次遇到类似问题照样踩坑？
这确实是目前大多数 AI Agent 的现状：很强，但不会"长记性"。用多久，它还是那个水平。
最近有个项目改变了这个局面——Hermes Agent。它在 4 月 5 日到 13 日这一周内暴涨了 32,572 颗 GitHub stars，
截至 4 月 13 日已经达到 65K stars，成了 AI Agent 领域最炙手可热的新玩家。
今天咱们就来聊聊，Hermes 到底有什么不一样。项目地址：https://github.com/NousResearch/hermes-agent。
b.大多数 Agent 的困境：聪明但不成长
现在的 AI Agent 框架，比如 OpenClaw、Cursor 内置的 Agent 能力，
已经能帮我们做很多事了——写代码、管日程、甚至处理复杂的客服对话。
但它们有一个共同的天花板：能力上限由配置决定。这就好像一个背了大量菜谱的厨师。
菜谱再多，遇到新食材、新口味，它要么束手无策，要么需要你重新写一份菜谱给它。
OpenClaw 就是这样的设计：技能是静态的文件，你写好它就用，用错了手动改。
它不会自己总结经验，也不会在下一次遇到类似问题时自动优化。这算是一种设计选择。
但当我们期望 AI Agent 真正成为"智能助手"时，这种"用过就忘"的模式就成了瓶颈。
c.Hermes 的闭环学习系统：边用边学
a.内置的学习循环
Hermes Agent 来自 Nous Research。它做了一件看起来很简单、
但实际上很关键的事——给 Agent 加了一个内置的学习循环。
这个循环是：经验 → 提取 → 技能创建 → 完善 → 提醒。
当 Hermes 完成一个复杂的多步骤任务后，它会自动分析自己做了什么、哪里做得好、哪里可以改进。
然后把经验提取出来，写成一个可复用的"技能文件"（遵循 agentskills.io 开放标准）。下次遇到类似问题，它就会加载这个技能来处理。
b.技能持续自我优化
技能不是写完就固定的——在后续使用中还会持续自我优化。
每完成 15 个任务，Hermes 会主动评估自己的表现，包括成功和失败的经验，然后决定是否需要创建新技能或改进现有技能。
c.跨会话记忆能力
它还有跨会话记忆能力。借助 FTS5 全文搜索和 LLM summarization，Hermes 能搜索自己过去和用户的对话，从历史经验中提取有用的信息。
d.不用 GPU 训练的自进化：DSPy + GEPA
a.技术成本
这种"学习"听起来需要大量训练，成本肯定很高？其实不是。
Hermes 的 self-evolution 模块用的是DSPy + GEPA（Genetic-Pareto Prompt Evolution）技术方案。
它不需要 GPU 训练，完全通过 API 调用来工作——变异文本、评估结果、选择最优变体。每次优化运行的成本大约在 2-10 美元之间。
b.优化流程
流程如下：读取当前技能/提示 → 生成评估数据集；然后 GEPA优化器读取执行轨迹，生成候选变体并评估；
接着经过约束门控（测试、大小限制、基准）；最后最优变体 → PR提交到hermes-agent。
GEPA 会读取执行轨迹，理解"为什么"失败（而不只是知道失败了），然后提出针对性的改进建议。
所有进化出的变体都必须通过完整的测试套件、技能文件不超过 15KB、保持语义一致性，还要经过人工 PR 审核。
e.v0.8.0：Browser Use 带来的新能力
4 月 8 日，Hermes 发布了 v0.8.0 版本，最大的新特性是集成了 Browser Use。
现在 Hermes 可以控制浏览器来执行任务了——自动搜索、填写表单、抓取网页内容。
结合它已有的 47+内置工具和 MCP 支持，能力边界正在快速扩展。
f.横向对比：Hermes vs OpenClaw
a.生态对比
说到 AI Agent，就不能不提 OpenClaw——它是目前生态最庞大的 Agent 框架，
拥有 247,000+开发者和 5,700+社区技能。两者最核心的区别在于学习机制。
OpenClaw 的优势在于生态成熟，5,700+现成技能拿来就能用。
但如果你需要一个能"跟着你一起成长"的助手，Hermes 的自我进化能力是更稀缺的能力。
b.详细对比表
对比项 OpenClaw Hermes Agent
技能创建 纯手动（人来写） 自主创建 + 手动
技能改进 手动修改 使用时自动改进
学习循环 无 闭环自进化
记忆系统 Markdown + SQLite 分层：FTS5 + LLM 摘要 + 可插拔后端
用户建模 基础（USER.md） Honcho dialectic 建模
g.值得思考的问题
a.技能质量风险
Hermes 的方向看起来是对的，但也有一些值得警惕的地方。
技能文件质量能保证吗？毕竟是自己写、自己用，没有人把关。
糟糕的技能文件会不会反而拖累系统性能？
"技能污染"是个真实的风险——当 Agent 积累了大量质量参差的技能后，下次遇到问题它加载了一个错误的技能，反而可能把事情搞砸。
b.错误经验循环
另外，自我进化依赖的是执行轨迹的分析。
如果某个任务本身就复杂，Agent 理解错了任务目标，那它提取出来的"经验"本身就是错的，用这种错误经验训练出来的技能，能好到哪里去？
h.Agent 范式的新分叉
a.范式转变
Hermes 的出现反映了一个更宏观的趋势：AI Agent 正在从"预设能力"向"经验累积"跃迁。
过去的 Agent 像功能固定的工具，装什么技能就会什么。
未来的 Agent 更像能够积累经验的助手——用得越多，它就越懂你的工作方式，越能提前预判你的需求。
b.总结与展望
这种"学习机制"的创新，可能比单纯增加工具数量或上下文窗口更有长远意义。
当然，Hermes 还很新（今年 2 月才发布），生态系统还不够成熟。但它的方向值得持续关注。
03.openclaw
a.BibiGPT更新
a.说明
本次更新主打OpenClaw集成，推出bibigpt-skill技能，补齐OpenClaw原生不支持中文视频平台总结的缺口，
同时上线Windows winget安装、思源笔记优化、移动端图片创作四大升级。
b.核心功能一：bibigpt-skill Agent技能
a.解决痛点
OpenClaw原生summarize无法识别B站、小红书、抖音等中文视频内容，形成信息孤岛。
b.使用方式
安装BibiGPT桌面端后，AI可自动安装或手动执行npx skills add JimmyLv/bibigpt-skill。
安装后在OpenClaw/Claude Code中直接指令调用总结视频。
c.支持平台
覆盖B站、小红书、抖音、YouTube、播客、本地音视频文件。
d.输出能力
支持分章节、JSON、纯字幕结构化输出，适配OpenClaw心跳任务与Claude Code spawn模式。
e.获取渠道
GitHub：https://github.com/JimmyLv/bibigpt-skill
ClawHub：https://clawhub.ai/JimmyLv/bibigpt-skill
c.核心功能二：Windows winget一键安装
Windows用户可执行winget install BibiGPT完成自动安装，流程简化、来源可信。
macOS继续使用brew install --cask jimmylv/bibigpt/bibigpt。
d.核心功能三：思源笔记集成优化
优化后可将总结、大纲、字幕直接保存至思源笔记，配置API Token后实现无缝同步，提升知识管理效率。
e.核心功能四：移动端图片创作
在移动端「创作」Tab支持AI图片生成，可选Seedream等模型，可生成多张、预览、保存或分享，完成视频到配图全流程。
f.其他体验升级
移动端界面视觉升级，AI对话支持流式输出与历史记录，字幕支持AI润色，新增横屏分屏布局，持续接入新模型并修复细节问题。
g.获取渠道
官网：https://bibigpt.co
移动端下载：https://bibigpt.co/app
桌面端下载：https://bibigpt.co/download/desktop
功能详情：https://bibigpt.co/features
b.OpenClaw生态创业
a.说明
OpenClaw官方产品体验较差，普通用户面临部署难、配置复杂、用途不清晰等问题，
大量抱怨与痛点成为草根创业者的机会，核心机会在于产品体验与落地服务。
b.头部商业化产品一览
a.Claw Mart
月收入71k美元，定位OpenClaw应用商店，提供现成AI配置模板与技能包，
支持用户上架售卖自定义角色，面向创业者与运营人员，采用B2C多档位收费模式。
b.OpenClaw Pro
月收入53k美元，现名Clawdrift，提供一键部署OpenClaw到多社交平台，
解决记忆丢失、OAuth过期、安全漏洞问题，面向个人与团队，采用B2B+B2C订阅模式。
c.RoofClaw
月收入50k美元，将OpenClaw预装于MacBook Air，专注屋顶维修行业，
提供硬件+部署+培训+维护一体化方案，数据本地化，面向垂直行业企业，一次性收费5000美元。
d.Donely
月收入44k美元，云端一键部署带人格与记忆的AI助手，支持WhatsApp，
允许自带API密钥，内置850+工具，面向不想配置服务器的用户，采用订阅+买断模式。
e.SetupClaw
月收入33k美元，提供企业级白手套部署服务，含安全加固、合规配置与持续维护，
远程/上门服务，面向企业高管，采用一次性收费+月度维护费模式。
f.AI Money Group
月收入22k美元，提供OpenClaw付费培训课程，教人搭建与销售AI员工，属于知识付费，
面向想通过AI变现的人群，采用订阅+直播教学模式。
g.StartClaw
月收入12k美元，云端托管OpenClaw，以AI员工形式售卖，独立虚拟机运行，
支持250+集成，面向个人与企业，采用SaaS订阅+定制服务模式。
c.创业核心机会总结
OpenClaw使用门槛越高，部署、加固、培训、模板、托管等周边服务商业价值越大。
草根创业者机会不在于对标大厂，而在于更具体、更落地、更垂直，用户愿意为实际结果与解决方案付费，细分行业与岗位存在高溢价空间。
c.小米推出国内首个手机端类OpenClaw智能体
a.Xiaomi miclaw产品定位
小米推出国内首个手机端类OpenClaw智能体，可在手机运行，
具备Skills、MCP、定时任务、人格等能力，低门槛、随时随地可用，深度整合小米生态，让AI Agent接入现实世界。
b.核心优势与生态价值
突破OpenClaw仅电脑运行、技术门槛高的限制，依托小米10亿级设备生态，将手机与米家设备变为AI的感知与执行终端，实现小米版贾维斯体验。
c.三大实战场景演示
a.智能早安管家
定时通过小爱音箱播报天气、科技新闻、家中温湿度，自动调节加湿器、空调，播放适配音乐，可联动智能窗帘、咖啡机、小米手表，未来可接入小米汽车。
b.智能离家模式
自然语言创建离家Skills，自动检查并关闭家中电器，开启摄像头监控，可扩展联动智能门锁、扫地机器人、宠物喂食器，无需复杂配置。
c.智能会议助手
创建录音会议Skills，自动后台录音、语音转文字，生成会议纪要、提取待办、添加日历日程，解放用户时间。
d.小米AI时代核心逻辑
硬件价值从功能易用性升级为数据与AI利用能力，设备越多AI越智能，形成正向循环，构建护城河。
e.小米完整技术栈
自研MiMo模型，掌握模型、芯片、系统、硬件全栈技术，实现模型+硬件+系统闭环，是AI时代接入物理世界的核心优势。
f.产品现状与使用建议
目前处于小规模封闭内测，存在不稳定与功能不完善问题，适合尝鲜用户，不建议普通用户主力机使用，可通过内置渠道反馈问题。
d.火山的ArkClaw把养虾的门槛打到地板了
a.养虾概念介绍
a.养虾含义
「养虾」最近实在是太火了。OpenClaw 的图标是一只红色大龙虾，因此中文社区亲切地叫它「龙虾」。
「养虾」就是「养一只属于自己的 AI 助手」的意思。
b.小龙虾与普通聊天机器人区别
小龙虾和你用过的聊天机器人有本质区别：它不是在对话框里回答问题的聊天机器人，
而是一个能真正「动手干活」的AI牛马——操控浏览器、读写文件、发邮件、管日历、跑脚本，
你用自然语言下指令，它自己规划步骤把事办完。你不需要坐在电脑前，它 7×24 小时都在线。
c.传统养虾存在的问题
对于普通用户来说，「养虾」最大的问题是 —— 门槛太高。
需要买云端服务器、需要配置Token套餐、需要配置Skill、需要和飞书打通、服务安全问题等等。
每一个都要么投入时间，要么投入钱，要么两个都投入。
b.ArkClaw产品介绍
a.产品优势
最近我发现字节的火山引擎做了件好事：把养虾门槛打到了地板！无论是价格、
还是安装门槛！服务器、Token、和飞书打通、自带技能，全部不用操心，一键傻瓜式完成。
这个产品叫做ArkClaw。下面我先介绍它的功能亮点，然后介绍如何安装。
c.ArkClaw功能亮点
a.一键接入，功能贼全
一键接入，零配置上手。更牛的是，从接入的第一刻起，它就已经自带了飞书所有能力、
所有国内主流模型、常用的技能。还有更牛的 —— 就算是你还没来得及接入飞书，
也可以在Web网页里直接使用，安排它干活。这产品体验简直太好了。
b.便宜到离谱
昨天半夜在群里看到朋友推荐，说“白菜价来了”，我一看截图，这…… 才9块9 ？？
不单独收服务器费用，只有包月Token费用。而且包月Token的月费，也太离谱了吧……
而且通过好友购买，还额外9折，只要8.9元。你可以通过我的邀请码购买试试，长按下图，扫码，
或者购买的时候输入邀请码EJ5U7CQE。我看了下说明：Coding Plan Pro 用户直接免费获得 ArkClaw 使用权益，
Lite 用户也有 7 天免费体验。Coding Plan特别适合程序员，
除了养虾，也能用来写代码，一次付费，两种场景。考虑到我平时写代码也需要用到Coding Plan，
所以我直接买了Coding Plan Pro，也才49.9元/月。如果你只是对「养虾」比较好奇，建议你先花¥8.9 ，体验一下。这也便宜得太过分了。
c.原厂集成飞书技能
我之前的公众号反复说过，如果是严肃的工作场景，使用飞书来搞小龙虾，是最好的。
这下可好，ArkClaw的火山引擎和飞书，都是字节这同一家公司的。原厂同生，天然就打通了。
如果使用ArkClaw， 飞书的一些高级功能，包括智能会议纪要自动生成、多维表格一键整理、复杂飞书文档直接产出——这只小龙虾天生就会。
d.包含国产头部模型
除国产模型最近很卷，我看到还有很多朋友去抢购Minimax-2.5等等。
火山的格局大啊，竟然就在刚才我们买的这9.9元的包月套餐里，是可以使用Minimax-2.5、Kimi-2.5等大量最新的国产头部模型的。
不过稍显遗憾的是暂时还没有GLM-5。
e.可从界面配置人格
可以在界面上轻松配置人格。我之前这篇文章 OpenClaw的班味儿太重？一键给它注入有趣的灵魂！
里说过，我们可以给小龙虾换上有趣的灵魂。连这么细的功能，ArkClaw都自带了。除了自己输入以外，也有一些自带的人格模板，可以一键选用。
f.Skills生态，直接可用
除了刚才说的飞书自带技能，我看到ArkClaw的虾出厂就自带了生态里的常用技能，clawhub也集成好了。
自带技能已经非常足够使用。如果还觉得缺什么技能，可以直接通过对话的方式去查找和安装。
d.用ArkClaw快速养虾步骤
a.购买套餐
扫上面的码购买8.9元的套餐后，用电脑打开链接 https://v2ig.cn/cRm03IcFyUU/，点击立即创建，稍等1分钟，就看到界面了。
b.创建飞书机器人
相对来说对小白用户稍微麻烦一点的是“创建飞书机器人”，不过根据详细指引来做，大概也只需要5分钟左右。
根据这份文档，一步一步在飞书开放平台里设置 https://www.volcengine.com/docs/6396/2249541?lang=zh。
我在飞书开发者后台创建了一个叫小姜的机器人。小姜是我的朋友，我还用了她的真实照片，增加代入感。
c.复制并填写信息
复制App ID 和 App Secrect。然后回到ArkClaw的界面 https://www.volcengine.com/experience/ark?mode=claw，
填完之后需要稍微等一会儿。
d.获取并输入配对码
我在飞书里和「小姜」对话，随便说点啥。首次对话，她会直接告诉我们配对码。回到ArkClaw界面，输入配对码，即配对成功！
e.配对成功注意事项
注意：输入配对码后，ArkClaw会弹出终端（一个黑乎乎的窗口）。
不用管它，它会自动完成。再次在飞书里输入信息，就可以开始和自己的龙虾玩耍了！
小提示：如果你的机器人没回复给你配对码，请检查前面飞书机器人的设置，步骤有点多，如果囫囵吞枣容易漏掉。
e.首次使用推荐功能
a.让机器人发自拍
a.原理
ArkClaw自带了字节的AIGC模型，比如Seedream，可以用于AI文生图、图生图。
我们让机器人记住自己的长相（给一张真的照片），以后让机器人用“图生图”的方式生成自拍照片。
每次都用同一张照片来做生图生，可以保持每次自拍的一致性。
b.操作方法
把真照片发给机器，让机器人记住自己的自拍照片。
再让机器人记住：“以后让你发自拍的时候，你用自己的照片，调用图生图的接口来画”。
b.把自拍变成视频
我们前面提到过了，ArkClaw自带了火山体系内的很多AIGC接口，除了AI生成图片，还可以AI生成视频。
我们可以说使用video-generate技能，把你的照片变成视频，就能得到对应的效果。可以查看录屏查看视频效果，
视频是以原始照片为参考来生成的，一模一样，毫无违和感。
c.不同话题拉不同飞书群
这是为了不同的主题，在不同的上下文里说，避免聊串了。为每一种类型的工作任务，都单独建群。群里还可以初始化一下，
第一次拉群的时候说一句{@你的机器人} 这个群里只有你和我，修改成，不需要你@你 你也回复我。
在我的飞书主力小龙虾「虾米」里，我大概和它拉了超过20个群，每个群处理不同的任务。最大的好处：我可以并行安排不同任务。
d.查实时资讯
得益于ArkClaw内置的大量技能，我们可以随便查各种资讯，不需要自己一个一个去配置了。
e.办公三件套
这只小龙虾内置了一切办公技能，直接阅读飞书文档，可以直接操作Excel、Word、PPT、WPS文件。可以让它阅读飞书文档，
改写成PPT，生成的是可编辑的真实PPT文件。
f.定时任务
小龙虾最亮眼的就是定时任务了。每当遇到什么情况的时候，可以通知你。比如设置当拼多多股票低于$101的时候提醒，或每天早上11点整理科技新闻发送。
g.飞书日程
平时我的工作是通过飞书日历来管理的，飞书日历可以到点自动通知你。有了小龙虾，管理日程变得很容易。
h.用语音安排任务
飞书自带语音，识别准确率高。可以直接用语音给机器人安排任务，如同给人工员工口头安排工作。
e.飞书做了一个超安全且功能更强大的龙虾
a.背景介绍
前段时间，龙虾爆火的时候，飞书因为健全的生态和开放的接入方式，成为了大家国内接入龙虾的首选IM平台。
但是毕竟龙虾有自己的体系，还有很多安全性问题，所以导致飞书服务的toB企业其实很多时候很难自己部署，或者是不敢自己部署。
这次飞书直接把他们的aily升级了，升级成了一个更安全、跟飞书契合度更高，而且更懂你的企业和你的龙虾。
b.核心功能
a.一键配置助手
你可以一键配置，随后它会直接生成一个联系人作为你的助手。你可以直接让他进行回复，或者在飞书中跟他聊天、给他安排任务。
b.信息读取与任务执行
他能读取你飞书里的所有信息，并帮你完成任务。此外，他还可以调用一些常见工具，甚至获取飞书之外的信息。
c.自定义Skills
你可以自定义Skills，比如说：你的日报、PPT、安排日程，这些都可以让它去帮你做。
c.专业版Aily
a.网页版使用
他们还有一个专业版的Aily，在网页上使用，自带了超级多的Skills。
b.功能演示
比如我这里就让他查找了一下对应的一个群，然后让他总结群里的信息，同时写了一个网页可视化的展示这些信息。
这个对于我们日常的企业管理和一些群的维护是非常好用的，而且还可以自动发送到比如说群里，对吧？
c.高级特性
同时，它支持更多超长的指令和复杂任务拆解，以及定时任务。他还给这个Aily配备了Agent电脑，支持更稳定的调用。
d.Skills生态
a.官方内置Skills
我们都知道龙虾强就强在它丰富的生态，也就是那些Skills。这次除了官方内置的大量Skills以外，
你还可以通过aily专业版自己创建Skills，同时支持上传以前自己制作的Skills。
b.个人流程落地
这个功能非常厉害，可以将很多个人流程直接落地：比如我之前做的一些"去AI味儿"的指令，
还有一些视频剪辑或文本生成的Skills。你完全可以将自己的工作流落地到Skills里，Agent的创建门槛已经变得非常低了。
e.如何使用
目前你可以飞书搜索Aily，就可以开通Aily助手；同时去网页版（aily.feishu.cn）可以使用专业版的Aily，都有免费额度，可以去玩玩，非常好玩。
f.QClaw简评：腾讯的"保守式创新"
a.文章信息
阅读本文大概需要4分钟。大家好，我是polarisxu。龙虾一如既往的火，每个大厂都在布局。
腾讯虽然晚，但终于来了：QClaw。目前不需要邀请码就可以使用。
我使用下来，"无非通过客服接入微信，不能操作任何微信的东西，连给它一篇微信公众号文章，它都说：微信公众号文章对爬虫有限制，只拿到了标题和作者。
（当然有其他办法实现，但它默认不行）"我查了一下QClaw的实际能力：
b.实际能力分析
a.功能清单
✅ 能远程控制电脑（打开文件、执行命令等操作）
✅ 能通过微信消息接收任务、返回结果
❌ 不能操作微信本身（不能自动发消息、不能拉群、不能读取聊天记录）
❌ 不能深度集成微信生态（小程序、支付、公众号）
b.对比结论
相比自己安装的龙虾，除了可以通过微信和它聊天，没有任何不同（初使用下来）。
这就好比你买了一辆"智能汽车"，结果发现它只能在自家车库里自动驾驶，一上高速就得手动。
c.保守的原因分析
a.合规红线
微信大概不是腾讯想动就能动的。即使是亲儿子，也要遵守：
用户隐私保护（自动读取聊天记录？想都别想）；
反骚扰机制（自动群发消息？这是垃圾信息）；
平台中立性（如果QClaw能操作微信，那其他AI助手怎么办？）。
腾讯再大，也不敢开这个先例。一旦开放，第二天就会有人用AI搞诈骗、发广告、洗用户。
b.战略定位
QClaw的真实定位不是"微信自动化神器"，而是：把OpenClaw的能力用最低门槛送给微信用户。
腾讯的逻辑是：OpenClaw很强大，但配置复杂（要装环境、配模型、接插件），普通用户搞不定。
QClaw做成一键安装，用微信当"遥控器"。目标用户是"想用AI但不会折腾的人"，不是极客。
所以它的设计是"保守"的——宁可功能少，也不能出问题。
c.免费额度策略
每天4000万免费token的真相。这个额度听起来很慷慨，但算一笔账：Kimi-2.5约1000token/千字，
4000万token≈4万字/天。对于个人日常使用，绰绰有余；对于自动化工作流，可能不够。
腾讯的算盘：用免费额度吸引用户，培养使用习惯，未来对高级功能/更高额度收费，或者通过企业版变现。典型的互联网打法，不意外。
d.综合评价
a.总体结论
总体上QClaw：及格，但不够惊艳。QClaw做到了"能用"，但没做到"好用"。
b.评分详情
维别 评价
易用性 ⭐⭐⭐⭐ 一键安装，微信扫码即用
功能性 ⭐⭐⭐ 基础远程控制 OK，深度集成缺失
开放性 ⭐⭐ 基于 OpenClaw 但做了大量限制
性价比 ⭐⭐⭐⭐ 目前免费，额度普通够用
创新性 ⭐⭐ 微信接入是亮点，但能力阉割
e.适用人群
a.适合人群
想体验AI代理但不想折腾配置的普通用户；有简单远程办公需求的职场人；微信重度用户。
b.不适合人群
需要深度自动化工作流的极客；想操作微信生态的营销/运营人员；对隐私敏感的用户（毕竟是腾讯）。
f.生态影响
a.机遇
腾讯背书，OpenClaw知名度提升；更多用户接触Agent概念，市场教育加速；可能带动技能（SKILL）生态繁荣。
b.挑战
QClaw是"围墙花园"，技能不一定能迁移到原生OpenClaw；用户可能把QClaw当成OpenClaw的全部，产生误解；腾讯可能逐步收拢生态，独立开发者空间被压缩。
g.给用户的建议
a.如果已经用了QClaw
把它当"入门玩具"，不要当"生产力工具"；熟悉Agent的基本概念和工作流；如果发现能力不够，考虑迁移到原生OpenClaw。
b.如果在观望
想尝鲜 → QClaw 可以试试，反正免费；想认真用 → 直接上 OpenClaw，配置麻烦但能力强；想搞微信自动化 → 别抱希望，目前没有合规方案。
h.结语
a.腾讯AI策略回顾
腾讯的AI策略，从来不是技术领先。回顾腾讯的AI产品史：混元大模型不是最强的，但微信 + QQ 的入口是无敌的。
腾讯擅长的是把60分的技术，用100分的渠道送出去。QClaw就是这个逻辑的延续。它不是技术突破，而是渠道胜利。
b.作者总结
对于极客，它不够强；对于大众，它可能刚刚好。失望吗？有点。但这就是腾讯——不追求最好，只追求最稳、最大、最能赚钱。
如果你需要真正的微信自动化能力，目前只有非官方方案（风险自负），或者等腾讯哪天想通了。但别抱太大希望。
g.OpenClaw3.22Beta：停更9天憋出的一次"换骨"级升级
a.说明
3月22日，开源自托管AI Agent平台OpenClaw正式发布v2026.3.22-beta.1预览版。
这是自上次更新以来间隔最长的一次发布，但从更新内容来看，等待是值得的——这不是常规的修修补补，而是一次涉及底层架构的深度重构。
b.插件系统彻底换血，旧时代翻篇
a.核心重构
3.22最核心的变化是插件体系的重构。旧版的openclaw/extension-api被一刀切移除，没有兼容层、没有过渡期，
取而代之的是全新的openclaw/plugin-sdk模块化接口。所有依赖旧API的第三方插件必须迁移，官方态度相当决绝。
b.安装来源切换
插件安装的默认来源从npm切换为ClawHub——OpenClaw官方维护的插件市场。只有在ClawHub找不到的包才会回退到npm。
这一策略意图明确：npm是通用包管理器，质量参差不齐；ClawHub经过审核，来源更可控。从开放到可控开放，OpenClaw在生态治理上迈出了关键一步。
c.生态兼容性扩展
3.22新增了对Claude、Codex、Cursor三大主流开发工具插件包的发现与安装支持，能将外部插件的Skills自动映射到OpenClaw的技能体系中。
这意味着OpenClaw正在从一个封闭工具框架向能吸纳外部生态的开放平台转型。
c.安全加固：补的全是要命的洞
a.关键安全修复
一是Windows上的SMB凭证泄露漏洞，攻击者可通过构造特殊的file://或UNC路径，在媒体加载时诱导系统自动发起SMB认证握手，
导致登录凭证外泄。二是执行环境沙盒加固，封锁了MAVEN_OPTS、GRADLE_OPTS等JVM注入路径以及.NET的依赖劫持通道。
三是Unicode零宽字符审批伪装漏洞。四是语音Webhook的预认证资源消耗问题。
b.更新建议
对公网部署的用户来说，这一版不是"建议更新"，而是"必须更新"。
d.模型生态扩军
a.模型配置升级
模型层面同样有实质性升级。GPT-5.4系列（含mini/nano）成为默认配置，MiniMax M2.7正式整合，Anthropic Vertex接入。
b.推理能力增强
新增了per-agent reasoning能力配置，意味着不同Agent可以独立控制推理策略，灵活度显著提升。
e.版本总结
OpenClaw3.22 Beta释放了一个明确信号：这个项目正在从"能用"走向"好用且安全"。插件系统的断裂式重构虽然短期会给生态带来阵痛，
但长期看是建立健康生态的必经之路。安全修复的力度说明团队对公网部署场景越来越重视。
而模型生态的持续扩展，则保证了OpenClaw作为"AI Agent中枢"的竞争力。唯一的遗憾是macOS桌面端尚未同步更新，beta阶段仅npm可用。
但整体而言，这是一个方向正确、执行果断的版本。
3 开源项目
3.1 分类1
00.汇总
a.分类1
ErlichLiu/Proma 大模型聊天对话能力，支持任意供应渠道的自定义配置
chmod777john/swarm-ide 开源版 Kimi-K2.5 蜂群多 Agent
volcengine/OpenViking 一个开源的、专为 AI Agent 设计的上下文数据库
langchain1.x-agent 基于 LangChain1.x 的 Agent 开发
OpenCrew 一个让你通过 Slack/飞书/Discord 就能管理一支 AI 团队的多智能体协同系统，不用写一行代码
b.分类2
Fractals：为AI智能体集群设计的递归任务编排器 https://github.com/TinyAGI/fractals
Claude skill-creator：完整“测-改-证”闭环工具 https://github.com/anthropics/skills/tree/main/skills/skill-creator
Context Hub：Andrew Ng推出的API文档查询工具 https://github.com/andrewyng/context-hub
PUA技能：通过心理压力和系统化方法驱动AI更彻底地解决问题 https://pua-skil.pages.dev
Skyvern：通过计算机视觉操作浏览器的AI Agent https://github.com/Skyvern-AI/skyvern
c.分类3
TreeSearch：万级文档库毫秒级检索 https://github.com/shibing624/TreeSearch/tree/main
ReMe：给 AI 智能体装上"长期记忆"，对话不再从零开始 https://github.com/agentscope-ai/ReMe
TenBox：轻量容器化虚拟机管理工具，主打一键批量部署多实例 https://github.com/tenbox-ai/tenbox
oMLX：Mac优化的LLM推理工具，核心解决本地LLM服务器便利性 https://github.com/jundot/omlx.git
Harness：用一个 while 循环来追踪历史消息、追加用户输入 https://github.com/harness
d.分类4
OpenRAG：集成化的企业级智能文档搜索与RAG分析平台 https://github.com/langflow-ai/openrag
DenchClaw：基于OpenClaw的开箱即用本地化AI CRM系统 https://github.com/DenchHQ/DenchClaw
Hello Claw：零基础学习OpenClaw与AI Agent原理的完整教程 https://github.com/datawhalechina/hello-claw
A2UI：谷歌开源让Agent生成声明式UI界面的开放标准 https://github.com/google/A2UI
lightpanda：高性能低内存的Z语言编写的AI Agent专用浏览器 https://lightpanda.io/
e.分类5
Hindsight：提炼交互模式让Agent学会而非单纯记住的记忆系统 https://github.com/obsidianforensics/hindsight
Open Browser：用自然语言指令驱动浏览器自动执行任务的工具 https://github.com/OpenBrowserAI
Jina CLI：集成搜索、向量、排序与管道能力的AI时代命令行工具 https://github.com/geekjourneyx/jina-cli
SWAGENT：通过内容协商输出AI友好格式的API文档解决方案 https://github.com/SWE-agent/SWE-agent
Dokobot CLI 重磅上线：AI Agent 可远程操控 Chrome https://dokobot.ai/zh-CN/help
f.分类6
InnoClaw：一个可以自托管的AI研究助手 https://github.com/zjowowen/InnoClaw
mgrep：在代码、文本、PDF、图片等各种文件里找到相关内容 https://github.com/mixedbread-ai/mgrep
Rowboat：具备本地知识图谱与长期记忆的开源AI工作伙伴 https://github.com/rowboatlabs/rowboat
LibLib：面向人类和Agent的AI视频创作平台LibTV https://www.liblib.tv/
gstack：YC总裁Garry开源了公司工程方法论 https://github.com/garrytan/gstack
g.分类7
Zeroboot：Github开源1.1K的毫秒级AI Agent沙箱 https://github.com/zerobootdev/zeroboot
Sandbox：一个一体化的人工智能代理沙箱环境 https://github.com/bytedance/sandboxfusion
cmux：专为AI Coding时代设计的终端
PageIndex：不用向量数据库也能做RAG
lark-cli：飞书推出官方cli
h.分类8
如何用Karpathy的Autoresearch让Skill效果提升26%
Tentix：AI原生客服工单系统
OfficeCLI：面向AI智能体的Office套件CLI工具
港大开源的 Agent 自进化引擎 https://github.com/HKUDS/OpenSpace
Hermes Agent：基于 Andrej Karpathy 提出的 LLM-Wiki 理念
01.常用信息1
a.Proma
a.新手入门
新手？从这里开始 → Proma 使用教程系列(点击此处) — 从零开始配置环境、连接大模型，3-5 分钟即可上手。
b.产品定位
下一代集成通用 Agent 的 AI 桌面应用，支持对话、Agent、Agent Teams 等能力，本地优先、多供应商支持、完全开源。支持远程通过飞书机器人与 Agent 对话和交互，甚至把 Proma Agent 拉进群组替你完成工作，跟同事实现 Agent 协作，让你用手机也可以处理很多必要的工作。
English version README.md
c.核心能力
Chat · 多模型对话
Agent · 自主通用 Agent
Agent Teams · 多 Agent 协同
Skills & MCP · 可扩展工具链
飞书远程 · 手机也能用 Agent
记忆 · 跨会话理解你
多供应商 · Anthropic / OpenAI / Google / DeepSeek / MiniMax / Kimi / 智谱
本地优先 · 数据全在你手里
d.商业版本
同时 Proma 也支持商业的版本，如果你需要未来更多的云端功能｜稳定靠谱的 API ｜更划算省心的订阅包｜简单的使用体验，也欢迎支持 Proma 的商业版本：https://proma.cool/download 即可下载使用，订阅包低至官方价 4 折。
e.核心意义与规划
Proma 的核心意义不在于替代任何一款软件，目前只实现了 Proma 的基础设施部分，接下来 Proma 将继续实现多 Agents 协同工作（个人与他人）、Agents 与外部的链接、Tools 和 Skills 固化，以及利用对用户的理解和记忆实现主动提供软件和建议的能力等，Proma 正在借助 VibeCoding 工具在飞速进化，欢迎大家 PR。
f.功能模块介绍
a.Chat 模式
Proma 的聊天模式，支持多模型切换，支持附加文件对话。
b.Agent 模式
Proma Agent 模式，通用 Agent 能力，支持 Cladue 全系列、Minimax M2.1、Kimi K2.5、智谱 GLM 等模型，支持第三方渠道。优雅、简洁、丝滑、确信的流式输出。
c.Agent Teams
Agent Teams 或者 Agent 蜂群将会是 2026 年 Agent 主要的发展方向之一，Proma 也已经支持 Agent Teams 能力，并且可以自动根据用户的任务复杂度自动组件 Agent Teams，实际测试可以将复杂任务的处理能力和效果提高至少 5% - 20%。当运行 Agent Teams 时你将在右侧看到具体的 Agent 的工作状态。（也可以通过自然语言主动要求使用 Agent Teams，并为每个 Agent 指定它的工作或研究范围）
d.Skill & MCP
Proma Skills 和 MCP，默认内置 Brainstorming 和办公软件 Skill，支持通过对话就能自动帮助你寻找和安装 Skills。
e.飞书远程使用
Proma 支持通过使用飞书机器人的方式来远程使用 Proma Agent 能力，支持切换工作区（/workspace 命令），支持创建新会话（/new 命令），这样就可以实现类似截图中的效果，可以为不同的工作区先配置上（或直接通过 Proma Agent 来帮你配置）对应的 Skills / MCP 以及文件附录等资源，即可远程也能让 Proma Agent 帮你完成工作。譬如远程帮你进行调研，并将调研文件通过邮件或其他方式发送到同事的邮箱、远程合并 PR 或者修复紧急的 Bug 并推送上线等。
也支持将 Proma Agent 拉进你的飞书群组，可以跟同事共享你积攒下来的 Skills 和 MCP 能力，利用本地的文件和飞书文档一起完成更智能的 Agent 协作，甚至可以直接用 Proma Agent 来完成对外部用户的服务。
实际的配置过程很简单，但我也知道这对于任何新手来说认知压力会比较大，但请相信我克服这种恐惧，3 分钟足够。
f.记忆能力
Proma 记忆功能，Chat 和 Agent 共享记忆，让 AI 真正了解你、记住你的偏好和习惯。
g.渠道配置功能
Proma 全协议大模型渠道支持，支持国内外所有渠道模型，通过 Base URL + API KEY 配置。
g.完整特性列表
多供应商支持 — Anthropic、OpenAI、Google、DeepSeek、MiniMax、Kimi、智谱 GLM，以及任何 OpenAI 兼容端点
AI Agent 模式 — 基于 Claude Agent SDK 的自主通用 Agent
远程全天候使用 Proma - 基于飞书/Lark 的机器人能力，实现远程使用 Proma Agent，搭配工作区的 Skill 和 MCP 等可以实现更好的远程工作
流式输出 & 思考模式 — 实时流式响应，可视化扩展思考过程
丰富渲染 — Mermaid 图表、语法高亮代码块、Markdown
附件 & 文档解析 — 上传图片，解析 PDF/Office/文本文件内容到对话中
记忆功能 — Chat 和 Agent 共享记忆，AI 记住你的偏好、习惯和上下文，跨会话持续理解你
本地优先 — 所有数据存储在 ~/.proma/，无数据库，完全可移植
主题切换 — 亮色/暗色模式，跟随系统偏好
b.swarm-ide
a.优势
a.任意动态创建sub-agent
支持动态创建子代理，灵活扩展任务处理能力。
b.可以向任意agent发送消息
支持与任意代理直接通信，交互无限制。
c.微信式聊天界面，随时介入任何子代理
采用聊天式交互界面，人类可随时介入任意层级子代理。
d.流式graph动态展现协作状态
以流式图形动态展示多代理协作流程与状态。
b.对比
a.项目背景
本项目在Kimi-Swarm和Claude Team之前就已独立提出蜂群模式。尤其是Claude Team，核心思想（动态派遣、人与任意Agent通信）与本项目设计高度一致，体现项目设计的前瞻性。在静态LangGraph框架流行时期独立实现该设计，理念超前。项目白皮书已上链存证，可通过区块链时间戳验证发布时间。
b.功能对比表格
对比项 Kimi-Swarm Claude Agent Team Swarm-IDE
支持嵌套Agent ❌ ❌ ✅
支持Agent间通信 ❌ ✅ ✅
支持人给sub-agent通信 ❌ ✅ ✅
支持群聊模式 ❌ ❌ ✅
支持可视化 ❌ ❌ ✅
是否开源 ❌ ❌ ✅
发布时间 2026.1.27 2026.2.6 2026.1.2
c.界面设计
a.Graph直接展示蜂群拓扑与实时通信链路
图形化展示代理集群拓扑与实时通信链路。
b.树状多级对话列表：可以像微信一样选择任意agent对话（即使是深层次）
以树状结构展示多级对话，支持快速选择任意代理进行交流。
c.LLM history面板：实时展示该agent的上下文，agent不再是黑箱
提供LLM历史面板，实时查看代理上下文信息，透明可调试。
d.实时流式输出tool-call参数
实时流式展示工具调用参数，过程可视化。
d.哲学
a.极简原语
系统仅依赖少量通信原语实现多Agent行为，核心为create+send，复杂协作由此组合而来。
b.液态拓扑
拓扑结构不预设，运行中自主演化；复杂任务下Agent可主动“雇佣”下属代理。
c.扁平协作
人类可像聊天一样介入任意层级，复杂拓扑可观察、可调试、可介入。
e.概念
摒弃nodes和edges复杂抽象，系统可理解为“很多个人”：每个人都能生孩子、也能和任意一个人说话。具备这两种能力即可实现任意结构的多代理协作。
c.OpenViking
a.核心概念与特性
a.文件系统管理范式
a.上下文组织
a.功能说明
OpenViking 摒弃了传统 RAG 的碎片化向量存储模式，创新性地采用“文件系统范式”，将 Agent 所需的记忆、资源和技能进行统一的结构化组织。所有上下文类型都映射到 `viking://` 协议下的虚拟目录中。
b.代码示例
---
viking://
├── resources/ (资源)
├── user/ (用户记忆)
└── agent/ (Agent 技能与记忆)
---
b.上下文操作
a.功能说明
这种范式赋予了 Agent 前所未有的上下文操作能力，使其能够通过 `ls` 和 `find` 等标准命令，精确且确定性地定位、浏览和操作信息。
b.代码示例
---
# 列出资源目录
client.ls("viking://resources/")
---
b.分层上下文加载
a.层级结构
a.功能说明
为了降低 Token 消耗并提高效率，OpenViking 将上下文处理为三个层级：L0（摘要）用于快速相关性检查，L1（概览）用于决策，L2（详情）用于深度阅读。
b.代码示例
---
viking://resources/my_project/
├── .abstract (L0 摘要)
├── .overview (L1 概览)
└── auth.md (L2 详情)
---
b.检索策略
a.功能说明
OpenViking 的目录递归检索策略结合了目录定位和语义搜索，实现递归且精准的上下文获取，增强了检索的准确性和全局性。
b.代码示例
---
# 执行语义搜索
results = client.find("什么是 openviking", target_uri=root_uri)
---
b.安装与配置
a.安装步骤
a.环境要求
a.功能说明
OpenViking 需要 Python 3.9 或更高版本，以及稳定的网络连接用于下载依赖和访问模型服务。
b.代码示例
---
python --version
---
b.Pip 安装
a.功能说明
安装 OpenViking 最简单的方法是通过 pip。
b.代码示例
---
pip install openviking
---
b.环境配置
a.模型准备
a.功能说明
OpenViking 需要 VLM 模型用于图像和内容理解，以及 Embedding 模型用于向量化和语义检索。推荐使用火山引擎（豆包模型）。
b.代码示例
---
# 推荐：火山引擎 (豆包模型)
---
b.配置文件
a.功能说明
在 `~/.openviking/ov.conf` 创建配置文件。如果配置文件在其他位置，请通过 `OPENVIKING_CONFIG_FILE` 环境变量指定。
b.代码示例
---
{
"embedding": {
"dense": {
"api_base" : "https://ark.cn-beijing.volces.com/api/v3",
"api_key" : "your-api-key",
"provider" : "volcengine",
"dimension": 1024,
"model" : "doubao-embedding-vision-250615"
}
},
"vlm": {
"api_base" : "https://ark.cn-beijing.volces.com/api/v3",
"api_key" : "your-api-key",
"provider" : "volcengine",
"model" : "doubao-seed-1-8-251228"
}
}
---
c.运行首个示例
a.Python 脚本创建
a.脚本结构
a.功能说明
要运行首个示例，请创建 Python 脚本 `example.py` 并使用数据目录初始化 OpenViking 客户端。
b.代码示例
---
import openviking as ov
client = ov.SyncOpenViking(path="./data")
---
b.资源管理
a.功能说明
使用 URL、文件或目录添加资源，并使用 `ls` 命令探索资源树结构。
b.代码示例
---
add_result = client.add_resource(path="https://raw.githubusercontent.com/volcengine/OpenViking/refs/heads/main/README.md")
ls_result = client.ls(add_result['root_uri'])
---
b.语义处理与搜索
a.上下文获取
a.功能说明
等待语义处理完成，然后获取资源的摘要（Abstract）和概览（Overview）。
b.代码示例
---
client.wait_processed()
abstract = client.abstract(root_uri)
overview = client.overview(root_uri)
---
b.语义搜索
a.功能说明
使用 `find` 命令执行语义搜索，以获取最相关的上下文。
b.代码示例
---
results = client.find("什么是 openviking", target_uri=root_uri)
---
d.检索流程与意图分析
a.两阶段检索流程
a.检索步骤
a.功能说明
OpenViking 采用两阶段检索：意图分析 + 层级检索 + Rerank。首先通过 LLM 分析查询意图，生成 TypedQuery，然后进行层级检索，最后进行精排评分。
b.代码示例
---
查询 → 意图分析 → 层级检索 → Rerank → 结果
---
b.find() 与 search()
a.功能说明
`find()` 用于简单查询，不需要会话上下文，延迟低；`search()` 用于复杂任务，使用 LLM 分析意图，支持 0-5 个 TypedQuery，延迟较高。
b.代码示例
---
# find(): 简单查询
results = await client.find("OAuth 认证", target_uri="viking://resources/")
---
b.意图分析 (Intent Analysis)
a.TypedQuery 生成
a.功能说明
IntentAnalyzer 使用 LLM 分析查询意图，生成 0-5 个 TypedQuery。输入包括会话压缩摘要、最近 5 条消息和当前查询。
b.代码示例
---
@dataclass
class TypedQuery:
query: str # 重写后的查询
context_type: ContextType # MEMORY/RESOURCE/SKILL
intent: str # 查询目的
priority: int # 1-5 优先级
---
b.查询风格
a.功能说明
不同类型的上下文有不同的查询风格：skill 以动词开头，resource 为名词短语，memory 以“用户XX”开头。
b.代码示例
---
# skill: "创建 RFC 文档"
# resource: "API 使用指南"
# memory: "用户的代码规范偏好"
---
e.层级检索与 Rerank 策略
a.层级检索 (Hierarchical Retrieval)
a.递归搜索流程
a.功能说明
HierarchicalRetriever 使用优先队列递归搜索目录结构。首先根据 context_type 确定根目录，然后通过全局向量搜索定位起始目录，最后进行递归搜索。
b.代码示例
---
Step 1: 确定根目录
Step 2: 全局向量搜索定位起始目录
Step 3: 合并起始点 + Rerank 评分
Step 4: 递归搜索（优先队列）
Step 5: 转换为 MatchedContext
---
b.根目录映射
a.功能说明
不同 context_type 映射到不同的根目录：MEMORY 映射到 `viking://user/memories` 或 `viking://agent/memories`，RESOURCE 映射到 `viking://resources`，SKILL 映射到 `viking://agent/skills`。
b.代码示例
---
# MEMORY -> viking://user/memories
# RESOURCE -> viking://resources
# SKILL -> viking://agent/skills
---
b.Rerank 策略
a.精排评分
a.功能说明
Rerank 在 THINKING 模式下对候选结果进行精排。如果配置了 Rerank AK/SK，则使用精排模型进行评分，否则使用向量分数。
b.代码示例
---
if rerank_client and mode == THINKING:
scores = rerank_client.rerank_batch(query, documents)
else:
scores = [r["_score"] for r in results] # 向量分数
---
b.触发条件与后端
a.功能说明
Rerank 触发条件包括配置了 Rerank AK/SK 且使用 THINKING 模式（search() 默认）。后端支持火山引擎的 doubao-seed-rerank 模型。
b.代码示例
---
# 后端: Volcengine
# 模型: doubao-seed-rerank
---
f.OpenViking项目定位
OpenViking是火山引擎开源的AI Agent专用上下文数据库，采用文件系统范式，
作为Agent的文件系统大脑，统一管理记忆、资源、技能，解决上下文爆炸、token消耗高、检索不可控、记忆碎片化等痛点。
g.传统RAG与OpenViking核心对比
对比项 传统RAG OpenViking
存储模式 扁平向量切片 层级文件系统
检索方式 单次向量匹配 目录递归检索
可观察性 黑盒检索 可视化轨迹
上下文组织 碎片化 统一URI管理
Token消耗 全量加载 分层按需加载
h.OpenViking五大核心设计
a.文件系统范式
使用viking://协议构建虚拟文件系统，分为resources、user、agent三大目录，支持ls、find、tree等类文件操作，实现精确可追溯的上下文管理。
b.三级分层加载L0/L1/L2
L0摘要层约100token快速判相关，L1概览层约2ktoken用于决策，L2详情层仅按需加载，大幅降低token成本。
c.目录递归检索
先意图分析与向量定位高分目录，再目录内精搜、递归下钻、结果聚合，兼顾语义灵活与结构精准。
d.可视化检索轨迹
完整记录检索路径，过程透明可调试，便于定位问题与优化逻辑。
e.自动会话管理
会话后异步更新用户偏好与Agent经验，实现持续自我进化。
i.实测效果数据
基于OpenClaw+LoCoMo10数据集测试：
OpenClaw原生：任务完成率35.65%，Token消耗24,611,530
OpenClaw+LanceDB：44.55%，51,574,530
OpenClaw+OpenViking：52.08%，4,264,396
任务完成率提升43-49%，Token成本降低83-96%。
j.快速上手步骤
a.安装
pip install openviking --upgrade
b.配置
创建~/.openviking/ov.conf，支持火山引擎、OpenAI、LiteLLM等。
c.启动
openviking-server
d.基础操作
ov add-resource 地址 添加资源
ov ls viking://资源路径 浏览目录
ov tree 路径 目录树展示
ov find 关键词 语义检索
k.模型支持与社区情况
支持Volcengine、OpenAI、Claude、DeepSeek、Gemini、Qwen、Ollama等，GitHub Star超5800，开源活跃。
l.核心价值总结
文件系统范式重构Agent上下文管理，分层加载解决token与窗口问题，可视化轨迹提升可调试性，是比传统RAG更适合AI Agent的文件系统大脑方案。
d.langchain1.x-agent
a.Demo vs 生产级项目：差别在哪里？
a.代码
@tool
def get_current_weather(city: str) -> str:
"""获取指定城市的当前天气"""
if "beijing" in city.lower():
return "北京当前天气：晴，-4℃，空气质量良。"
return f"未找到 {city} 的天气信息。"
b.说明
| 维度 | Demo 示例 | 生产级项目 |
|------|-----------|------------|
| 数据来源 | 硬编码的假数据 | 真实的第三方 API |
| 错误处理 | 几乎没有 | 完善的异常捕获和用户提示 |
| 代码结构 | 单文件扁平化 | 模块化分层（agent/service/api） |
| 配置管理 | 直接写在代码里 | 环境变量 + 配置类 |
| 交互方式 | 只能运行脚本 | CLI + Web UI + REST API |
| 类型安全 | 没有 | Python type hints + TypeScript |
| 依赖管理 | 手动 pip install | 使用 uv/lock 文件 |
| 前端框架 | 无 | @assistant-ui/react 专用组件库 |
| 流式输出 | 无 | SSE 流式 API 支持 |
| 主题支持 | 无 | 支持深色/浅色主题 |
b.项目概览：一个真正的天气 Agent
a.项目功能
这是一个可实际使用的天气查询助手：
支持查询中国所有城市的天气
可查当天或多天预报
两种使用方式：终端 CLI 和 Web 界面
真实天气数据来自和风天气 API
b.技术栈
后端：
Python 3.11+、LangChain 1.2.6、FastAPI
OpenRouter（LLM 服务）
和风天气 API（数据源）
-------------------------------------------------------------------------------------------------
前端：
React 19、Vite 7、TypeScript 5
@assistant-ui/react（AI 聊天组件库）
Tailwind CSS 4、Zustand 5
c.项目结构
code/
├── backend/ # Python 后端
│ ├── pyproject.toml # uv 项目配置
│ └── src/
│ └── weather_agent/ # 主包 (src layout)
│ ├── main.py # FastAPI 入口
│ ├── cli.py # 终端测试界面
│ ├── core/
│ │ └── config.py # 配置管理
│ ├── agent/
│ │ └── weather_agent.py # LangChain Agent
│ ├── services/
│ │ └── qweather_service.py # 和风天气 API 封装
│ ├── models/
│ │ └── schemas.py # Pydantic 数据模型
│ └── api/
│ └── routes/
│ └── agent.py # REST API 路由
│
└── frontend/ # React 前端
└── src/
├── main.tsx # 入口
├── api/ # API 客户端
├── components/ # UI 组件
│ ├── AssistantChat.tsx # AI 聊天主组件
│ ├── ThemeToggle.tsx # 主题切换
│ └── ui/ # 基础 UI 组件
├── contexts/ # React Context
│ └── ThemeContext.tsx # 主题上下文
├── runtimes/ # Runtime Provider
│ └── WeatherRuntimeProvider.tsx
├── store/ # Zustand 状态
├── types/ # TypeScript 类型
└── pages/ # 页面组件
c.核心代码解析
a.配置管理（backend/src/weather_agent/core/config.py）
a.说明
生产项目的第一步是把配置从代码中分离出来
b.代码
from pydantic_settings import BaseSettings, SettingsConfigDict
class Settings(BaseSettings):
"""应用配置类"""
# OpenRouter 配置
OPENROUTER_API_KEY: str
OPENROUTER_BASE_URL: str = "https://openrouter.ai/api/v1"
OPENROUTER_MODEL: str = "nex-agi/deepseek-v3.1-nex-n1:free"
# 和风天气配置
QWEATHER_API_KEY: str
QWEATHER_BASE_URL: str = "https://devapi.qweather.com/v7"
# FastAPI 配置
API_V1_PREFIX: str = "/api/v1"
PROJECT_NAME: str = "Weather Agent API"
# CORS 配置
CORS_ORIGINS: list[str] = ["http://localhost:5173", "http://localhost:3000"]
# 日志配置
LOG_LEVEL: str = "INFO"
model_config = SettingsConfigDict(
env_file=".env",
env_file_encoding="utf-8",
case_sensitive=True,
)
# 全局配置实例
settings = Settings()
c.为什么这样设计？
使用 Pydantic Settings 自动读取环境变量
提供默认值，减少必须配置的项
类型安全，IDE 能自动补全
单例模式 settings，全局共享
d.对应的 `.env` 文件
OPENROUTER_API_KEY=your_key_here
OPENROUTER_MODEL=nex-agi/deepseek-v3.1-nex-n1:free
QWEATHER_API_KEY=your_qweather_key_here
b.真实数据服务（backend/src/weather_agent/services/qweather_service.py）
a.说明
生产级项目需要封装第三方 API，而不是直接在工具里调用
b.代码
import httpx
from typing import Optional, Dict, Any
class QWeatherService:
"""和风天气服务类"""
def __init__(self):
self.api_key = settings.QWEATHER_API_KEY
self.base_url = settings.QWEATHER_BASE_URL
self.client = httpx.AsyncClient(timeout=30.0)
async def get_city_id(self, city_name: str) -> Optional[str]:
"""
通过城市名称获取城市 ID
接口文档: https://dev.qweather.com/docs/api/geoapi/city-lookup/
Args:
city_name: 城市名称，例如"北京"、"上海"
Returns:
城市ID，如果未找到返回 None
"""
url = f"{self.base_url}/geo/v2/city/lookup"
params = {
"location": city_name,
"key": self.api_key
}
try:
response = await self.client.get(url, params=params)
data = response.json()
if data.get("code") == "200" and data.get("location"):
return data["location"][0]["id"]
return None
except Exception as e:
print(f"获取城市ID失败: {e}")
return None
async def get_current_weather(self, city_name: str) -> Dict[str, Any]:
"""
获取指定城市的实时天气
接口文档: https://dev.qweather.com/docs/api/weather/weather-now/
Args:
city_name: 城市名称
Returns:
天气数据字典
"""
# 1. 获取城市 ID
city_id = await self.get_city_id(city_name)
if not city_id:
return {"error": f"未找到城市: {city_name}"}
# 2. 获取实时天气
url = f"{self.base_url}/v7/weather/now"
params = {
"location": city_id,
"key": self.api_key
}
try:
response = await self.client.get(url, params=params)
data = response.json()
if data.get("code") == "200":
return {
"city": city_name,
"temp": data["now"]["temp"],
"feels_like": data["now"]["feelsLike"],
"weather": data["now"]["text"],
"wind_dir": data["now"]["windDir"],
"wind_scale": data["now"]["windScale"],
"humidity": data["now"]["humidity"],
"precip": data["now"]["precip"],
}
else:
return {"error": f"获取天气失败: {data.get('code')}"}
except Exception as e:
return {"error": f"请求失败: {str(e)}"}
async def get_forecast(self, city_name: str, days: int = 3) -> Dict[str, Any]:
"""
获取指定城市的天气预报
Args:
city_name: 城市名称
days: 预报天数 (1-7)
Returns:
天气预报数据字典
"""
city_id = await self.get_city_id(city_name)
if not city_id:
return {"error": f"未找到城市: {city_name}"}
# 和风天气免费版支持 3 天预报
url = f"{self.base_url}/v7/weather/{min(days, 3)}d"
params = {
"location": city_id,
"key": self.api_key
}
try:
response = await self.client.get(url, params=params)
data = response.json()
if data.get("code") == "200":
forecasts = []
for day in data.get("daily", []):
forecasts.append({
"date": day["fxDate"],
"temp_max": day["tempMax"],
"temp_min": day["tempMin"],
"weather_day": day["textDay"],
"weather_night": day["textNight"],
"wind_dir_day": day["windDirDay"],
"wind_scale_day": day["windScaleDay"],
})
return {
"city": city_name,
"forecasts": forecasts
}
else:
return {"error": f"获取预报失败: {data.get('code')}"}
except Exception as e:
return {"error": f"请求失败: {str(e)}"}
async def format_weather_text(self, city_name: str, days: int = 1) -> str:
"""
格式化天气信息为自然语言文本
Args:
city_name: 城市名称
days: 查询天数
Returns:
格式化的天气描述文本
"""
# 获取实时天气
current = await self.get_current_weather(city_name)
if "error" in current:
return current["error"]
result = [
f"📍 {current['city']}当前天气：",
f"🌡️ 温度: {current['temp']}°C (体感 {current['feels_like']}°C)",
f"☁️ 天气: {current['weather']}",
f"💨 风向: {current['wind_dir']} {current['wind_scale']}级",
f"💧 湿度: {current['humidity']}%",
]
# 如果需要多天预报
if days > 1:
forecast = await self.get_forecast(city_name, days - 1)
if "forecasts" in forecast:
result.append("\n📅 未来天气预报：")
for day in forecast["forecasts"]:
result.append(
f" {day['date']}: {day['temp_min']}-{day['temp_max']}°C, "
f"{day['weather_day']}, {day['wind_dir_day']} {day['wind_scale_day']}级"
)
return "\n".join(result)
async def close(self):
"""关闭 HTTP 客户端"""
await self.client.aclose()
c.为什么这样设计？
| 设计 | 目的 |
|------|------|
| 异步 httpx | 不阻塞事件循环，性能更好 |
| 会话复用 | 避免每次请求都创建新连接 |
| 错误捕获 | 把异常转换为友好提示 |
| 格式化方法 | 专门为 Agent 提供可读文本 |
c.LangChain Agent（backend/src/weather_agent/agent/weather_agent.py）
a.说明
现在工具可以专注于调用服务层，而不是关心 API 细节
b.代码
from langchain.agents import create_agent
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from weather_agent.core.config import settings
from weather_agent.services.qweather_service import QWeatherService
from typing import AsyncIterator
@tool
async def get_weather(location: str, days: int = 1) -> str:
"""
查询指定城市的天气信息
Args:
location: 城市名称，例如"北京"、"上海"、"广州"
days: 查询天数，1=今天，2=今天和明天，最多7天
Returns:
天气信息的自然语言描述
"""
service = QWeatherService()
try:
result = await service.format_weather_text(location, days)
return result
finally:
await service.close()
class WeatherAgent:
"""天气查询 Agent 类"""
def __init__(self):
"""初始化 Agent"""
# 初始化 LLM（使用 OpenRouter）
self.llm = ChatOpenAI(
model=settings.OPENROUTER_MODEL,
base_url=settings.OPENROUTER_BASE_URL,
api_key=settings.OPENROUTER_API_KEY,
temperature=0.7,
)
# 定义工具列表
self.tools = [get_weather]
# 创建 Agent
self.agent = create_agent(
model=self.llm,
tools=self.tools,
system_prompt="你是一个专业的天气助手，可以帮助用户查询中国任何城市的天气信息。"
"使用 get_weather 工具来获取天气数据，然后用自然、友好的方式回复用户。"
"如果用户没有明确指定天数，默认查询当天天气。",
debug=False,
)
def _create_inputs(self, message: str) -> dict:
"""创建 Agent 输入格式"""
return {
"messages": [
{"role": "user", "content": message}
]
}
async def _extract_content_chunks(self, chunk) -> list[str]:
"""从流式 chunk 中提取内容片段"""
chunks = []
# chunk 格式: {'agent': {'messages': [AIMessage(content='...')]}}
if isinstance(chunk, dict):
for value in chunk.values():
if isinstance(value, dict) and "messages" in value:
messages = value["messages"]
for msg in messages:
if hasattr(msg, "content") and msg.content:
content = str(msg.content)
if content:
chunks.append(content)
elif isinstance(value, str) and value:
chunks.append(value)
elif isinstance(chunk, str) and chunk:
chunks.append(chunk)
return chunks
async def astream_chat(self, message: str) -> AsyncIterator[str]:
"""
与 Agent 进行流式对话（核心方法）
Args:
message: 用户消息
Yields:
str: Agent 的回复片段
"""
try:
inputs = self._create_inputs(message)
# 使用 astream 进行流式输出
async for chunk in self.agent.astream(inputs, stream_mode="updates"):
chunks = await self._extract_content_chunks(chunk)
for content in chunks:
yield content
except Exception as e:
yield f"\n\n[错误] 处理请求时出现错误：{str(e)}"
async def chat(self, message: str) -> str:
"""
与 Agent 进行对话（非流式，内部使用流式逻辑）
Args:
message: 用户消息
Returns:
Agent 的完整回复
"""
try:
# 收集所有流式片段
full_response = ""
async for chunk in self.astream_chat(message):
full_response += chunk
return full_response if full_response else "抱歉，未能生成回复。"
except Exception as e:
return f"抱歉，处理请求时出现错误：{str(e)}"
c.与 Demo 版本的对比
@tool
def get_current_weather(city: str) -> str:
if "beijing" in city.lower():
return "北京当前天气：晴，-4℃"
return "未找到该城市"
# 生产版本
@tool
async def get_weather(location: str, days: int = 1) -> str:
service = QWeatherService()
try:
result = await service.format_weather_text(location, days)
return result
finally:
await service.close()
d.可以看到，生产版本的工具有以下改进
异步支持：使用 async/await
真实数据：调用和风天气 API
资源清理：确保 HTTP 会话被关闭
参数扩展：支持多天查询
文档完善：完整的 Args 和 Returns 说明
流式输出：支持 SSE 流式响应（astream_chat 方法）
d.CLI 终端界面（backend/src/weather_agent/cli.py）
a.代码
"""
终端测试界面
提供交互式命令行界面用于测试天气查询 Agent
"""
import asyncio
from weather_agent.agent.weather_agent import WeatherAgent
async def main():
"""主函数"""
agent = WeatherAgent()
print("=" * 50)
print("🌤️ 天气查询 Agent - 终端测试界面")
print("=" * 50)
print("\n欢迎使用天气查询助手！")
print("你可以问我任何城市的天气情况。")
print("\n示例:")
print(" - 北京今天天气怎么样?")
print(" - 上海未来三天天气")
print(" - 深圳现在多少度?")
print("\n输入 'quit' 或 'exit' 退出程序")
print("-" * 50)
while True:
try:
# 获取用户输入
import sys
if sys.stdin.isatty():
user_input = input("您: ").strip()
else:
# 非交互模式
break
# 检查退出命令
if user_input.lower() in ['quit', 'exit', '退出', 'q']:
print("\n👋 再见！感谢使用天气查询助手！")
break
# 跳过空输入
if not user_input:
continue
# 调用 Agent
print("\nAgent: ", end="", flush=True)
response = await agent.chat(user_input)
print(response)
except KeyboardInterrupt:
print("\n\n👋 程序已中断，再见！")
break
except EOFError:
print("\n\n👋 输入结束，再见！")
break
except Exception as e:
print(f"\n❌ 发生错误: {e}\n")
if __name__ == "__main__":
asyncio.run(main())
b.运行方式
cd backend
uv run python -m weather_agent.cli
e.FastAPI REST API
a.数据模型（backend/src/weather_agent/models/schemas.py）
from pydantic import BaseModel
from typing import Optional
class ChatRequest(BaseModel):
"""聊天请求模型"""
message: str
session_id: Optional[str] = None
class ChatResponse(BaseModel):
"""聊天响应模型"""
response: str
session_id: str
b.路由定义（backend/src/weather_agent/api/routes/agent.py）
from fastapi import APIRouter, HTTPException, status
from fastapi.responses import StreamingResponse
from weather_agent.models.schemas import ChatRequest, ChatResponse
from weather_agent.agent.weather_agent import WeatherAgent
import uuid
import json
from typing import AsyncGenerator
router = APIRouter(prefix="/chat", tags=["agent"])
@router.post("", response_model=ChatResponse)
async def chat(request: ChatRequest):
"""
与天气查询 Agent 进行对话（非流式）
内部使用流式逻辑收集完整响应后一次性返回，
确保与流式接口的行为完全一致。
Args:
request: 聊天请求，包含用户消息
Returns:
ChatResponse: Agent 的完整响应
"""
try:
agent = WeatherAgent()
response = await agent.chat(request.message)
session_id = request.session_id or str(uuid.uuid4())
return ChatResponse(response=response, session_id=session_id)
except Exception as e:
raise HTTPException(
status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
detail=f"处理请求时发生错误: {str(e)}"
)
@router.post("/stream")
async def chat_stream(request: ChatRequest):
"""
与天气查询 Agent 进行流式对话 (SSE)
Args:
request: 聊天请求，包含用户消息
Returns:
StreamingResponse: SSE 流式响应
"""
async def _stream_event_generator() -> AsyncGenerator[str, None]:
"""SSE 事件生成器"""
agent = WeatherAgent()
session_id = request.session_id or str(uuid.uuid4())
# 发送 session_id 作为第一个事件
yield f"event: session_id\ndata: {json.dumps({'session_id': session_id}, ensure_ascii=False)}\n\n"
# 流式输出 AI 回复
async for chunk in agent.astream_chat(request.message):
if chunk:
yield f"event: message\ndata: {json.dumps({'content': chunk}, ensure_ascii=False)}\n\n"
# 发送结束事件
yield "event: done\ndata: {}\n\n"
return StreamingResponse(
_stream_event_generator(),
media_type="text/event-stream",
headers={
"Cache-Control": "no-cache",
"Connection": "keep-alive",
"X-Accel-Buffering": "no",
},
)
@router.get("/health")
async def health_check():
"""健康检查端点"""
return {"status": "healthy", "service": "Weather Agent API"}
c.API 端点对比
| 端点 | 响应方式 | 适用场景 |
|------|----------|----------|
| POST /api/v1/chat | 非流式 | 简单请求、测试 |
| POST /api/v1/chat/stream | SSE 流式 | 生产环境、实时体验 |
API 文档：启动服务后访问 http://localhost:8000/docs
f.React 前端
a.主页面（frontend/src/pages/WeatherPage.tsx）
a.说明
主页面非常简洁，直接渲染 AssistantChat 组件
b.代码
/**
* 天气页面
*/
import AssistantChat from '@/components/AssistantChat'
export default function WeatherPage() {
return (
<div className="h-screen w-screen overflow-hidden">
<AssistantChat />
</div>
)
}
b.AI 聊天组件（frontend/src/components/AssistantChat.tsx）
a.说明
使用 @assistant-ui/react 提供的 Thread 组件构建现代化聊天界面
b.代码
/**
* 聊天组件 - 使用 assistant-ui 现成组件
*/
import '@assistant-ui/react-ui/styles/index.css'
import { Thread } from '@assistant-ui/react-ui'
import { WeatherRuntimeProvider } from '@/runtimes/WeatherRuntimeProvider'
import { ThemeProvider, useTheme } from '@/contexts/ThemeContext'
import { ThemeToggle } from '@/components/ThemeToggle'
const suggestions = [
{ prompt: '北京今天天气怎么样？' },
{ prompt: '上海明天会下雨吗？' },
{ prompt: '深圳这周末天气如何？' },
{ prompt: '杭州现在多少度？' },
]
function AssistantChatInner() {
const { effectiveTheme } = useTheme()
return (
<div className={`aui-root ${effectiveTheme} h-full w-full bg-[hsl(var(--aui-background))]`}
style={{ '--thread-max-width': '48rem' } as React.CSSProperties}>
{/* 主题切换按钮 - 固定在右上角 */}
<div className="fixed top-4 right-4 z-50">
<ThemeToggle />
</div>
<Thread
welcome={{
title: '天气助手',
suggestions,
}}
/>
</div>
)
}
export default function AssistantChat() {
return (
<WeatherRuntimeProvider>
<ThemeProvider>
<AssistantChatInner />
</ThemeProvider>
</WeatherRuntimeProvider>
)
}
c.关键设计点
| 组件 | 职责 |
|------|------|
| Thread | assistant-ui 提供的聊天界面核心组件 |
| WeatherRuntimeProvider | 连接后端 API 的 Runtime Provider，使用 useExternalStoreRuntime |
| ThemeProvider | 主题上下文，支持深色/浅色/跟随系统三种模式 |
| ThemeToggle | 主题切换按钮组件 |
c.Runtime Provider（frontend/src/runtimes/WeatherRuntimeProvider.tsx）
a.说明
Runtime Provider 是 assistant-ui 与后端 API 的桥梁，使用 useExternalStoreRuntime 实现流式输出
b.代码
/**
* 自定义 Runtime Provider
* 使用 assistant-ui 的 useExternalStoreRuntime 连接现有的后端 API
* 支持流式输出
*/
import { useState, ReactNode, useCallback, useRef } from 'react'
import {
AssistantRuntimeProvider,
useExternalStoreRuntime,
type ThreadMessageLike,
} from '@assistant-ui/react'
import { agentApi } from '@/api/agent'
interface MyMessage {
role: 'user' | 'assistant' | 'system'
content: string
}
const convertMessage = (message: MyMessage): ThreadMessageLike => {
return {
role: message.role,
content: [{ type: 'text', text: message.content }],
}
}
export function WeatherRuntimeProvider({
children,
}: Readonly<{
children: ReactNode
}>) {
const [messages, setMessages] = useState<MyMessage[]>([])
const [isRunning, setIsRunning] = useState(false)
const [sessionId, setSessionId] = useState<string>()
const abortControllerRef = useRef<AbortController | null>(null)
const onNew = useCallback(async (message: {
content: Array<{ type: string; text?: string }>
}) => {
const input = message.content[0]?.text || ''
// 取消之前的请求
if (abortControllerRef.current) {
abortControllerRef.current.abort()
}
abortControllerRef.current = new AbortController()
setIsRunning(true)
// 创建用户消息和空的助手消息
const assistantMessageIndex = messages.length + 1
setMessages((current) => [
...current,
{ role: 'user', content: input },
{ role: 'assistant', content: '' },
])
let fullContent = ''
// 使用流式 API
await agentApi.chatStream(
input,
{
onContent: (content: string) => {
fullContent += content
// 更新助手消息内容
setMessages((current) => {
const newMessages = [...current]
if (newMessages[assistantMessageIndex]) {
newMessages[assistantMessageIndex] = {
role: 'assistant',
content: fullContent,
}
}
return newMessages
})
},
onDone: () => {
setIsRunning(false)
},
onError: (error: Error) => {
console.error('Stream error:', error)
setIsRunning(false)
},
onSessionId: (newSessionId: string) => {
setSessionId(newSessionId)
},
},
sessionId
)
}, [messages, sessionId])
const runtime = useExternalStoreRuntime({
isRunning,
messages,
convertMessage,
onNew,
})
return (
<AssistantRuntimeProvider runtime={runtime}>
{children}
</AssistantRuntimeProvider>
)
}
d.主题上下文（frontend/src/contexts/ThemeContext.tsx）
a.说明
支持亮色/暗色/跟随系统三种主题模式
b.代码
/**
* 主题上下文 - 管理亮色/暗色/跟随系统主题切换
*/
import { createContext, useContext, useEffect, useState, ReactNode } from 'react'
export type Theme = 'light' | 'dark' | 'system'
interface ThemeContextValue {
theme: Theme
setTheme: (theme: Theme) => void
effectiveTheme: 'light' | 'dark'
}
const ThemeContext = createContext<ThemeContextValue | undefined>(undefined)
const STORAGE_KEY = 'weather-chat-theme'
function getSystemTheme(): 'light' | 'dark' {
if (typeof window === 'undefined') return 'light'
return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
}
function getStoredTheme(): Theme {
if (typeof window === 'undefined') return 'system'
try {
const stored = localStorage.getItem(STORAGE_KEY)
return (stored === 'light' || stored === 'dark' || stored === 'system') ? stored : 'system'
} catch {
return 'system'
}
}
function storeTheme(theme: Theme) {
if (typeof window === 'undefined') return
try {
localStorage.setItem(STORAGE_KEY, theme)
} catch {
// Ignore storage errors
}
}
export function ThemeProvider({ children }: Readonly<{ children: ReactNode }>) {
const [theme, setThemeState] = useState<Theme>(getStoredTheme)
const [effectiveTheme, setEffectiveTheme] = useState<'light' | 'dark'>(() =>
theme === 'system' ? getSystemTheme() : theme
)
const setTheme = (newTheme: Theme) => {
setThemeState(newTheme)
storeTheme(newTheme)
}
// 监听系统主题变化
useEffect(() => {
if (theme !== 'system') return
const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)')
const updateSystemTheme = (e: MediaQueryListEvent) => {
setEffectiveTheme(e.matches ? 'dark' : 'light')
}
mediaQuery.addEventListener('change', updateSystemTheme)
return () => {
mediaQuery.removeEventListener('change', updateSystemTheme)
}
}, [theme])
// 更新有效主题
useEffect(() => {
setEffectiveTheme(theme === 'system' ? getSystemTheme() : theme)
}, [theme])
// 应用主题到 document
useEffect(() => {
const root = document.documentElement
root.classList.remove('light', 'dark')
root.classList.add(effectiveTheme)
}, [effectiveTheme])
return (
<ThemeContext.Provider value={{ theme, setTheme, effectiveTheme }}>
{children}
</ThemeContext.Provider>
)
}
export function useTheme() {
const context = useContext(ThemeContext)
if (!context) {
throw new Error('useTheme must be used within ThemeProvider')
}
return context
}
e.主题切换按钮（frontend/src/components/ThemeToggle.tsx）
a.代码
/**
* 主题切换按钮组件
*/
import { useTheme, type Theme } from '@/contexts/ThemeContext'
import { Sun, Moon, Monitor } from 'lucide-react'
export function ThemeToggle() {
const { theme, setTheme, effectiveTheme } = useTheme()
const themes: Array<{ value: Theme; label: string; icon: React.ReactNode }> = [
{ value: 'light', label: '浅色', icon: <Sun className="w-4 h-4" /> },
{ value: 'dark', label: '深色', icon: <Moon className="w-4 h-4" /> },
{ value: 'system', label: '跟随系统', icon: <Monitor className="w-4 h-4" /> },
]
return (
<div className="flex items-center gap-1 p-1 rounded-lg bg-muted/50">
{themes.map(({ value, label, icon }) => {
const isActive = theme === value
return (
<button
key={value}
onClick={() => setTheme(value)}
className={`
flex items-center gap-1.5 px-3 py-1.5 rounded-md text-sm font-medium
transition-all duration-200
${isActive
? 'bg-background text-foreground shadow-sm'
: 'text-muted-foreground hover:text-foreground hover:bg-muted'
}
`}
title={label}
>
{icon}
<span className="hidden sm:inline">{label}</span>
</button>
)
})}
</div>
)
}
d.运行完整项目
a.准备工作
a.获取 API 密钥
OpenRouter - 注册获取免费 LLM
和风天气 - 注册获取天气数据
b.安装工具
# Python 包管理器
pip install uv
# Node.js 包管理器
npm install -g pnpm
b.启动项目
a.后端
cd backend
# 安装依赖
uv sync
# 配置环境变量
cp .env.example .env
# 编辑 .env 填入你的密钥
# 启动服务
uv run uvicorn weather_agent.main:app --reload --port 8000
b.前端
cd frontend
# 安装依赖
pnpm install
# 配置环境变量
cp .env.example .env
# 启动开发服务器
pnpm dev
c.使用方式
a.方式一：终端 CLI
cd backend
uv run python -m weather_agent.cli
b.方式二：Web 界面
访问 http://localhost:5173
c.效果示例
您: 北京今天天气怎么样？
Agent: 📍 北京当前天气：
🌡️ 温度: 15°C
☁️ 天气: 晴
💨 风力: 东南风 3级
💧 湿度: 45%
今天是个好天气，适合出行！记得做好防晒哦~
e.工程化最佳实践总结
a.分层架构
┌─────────────────────────────────────┐
│ 前端 (React) │
│ - UI 组件 │
│ - 状态管理 │
└─────────────┬───────────────────────┘
│ HTTP API
┌─────────────▼───────────────────────┐
│ API 层 (FastAPI) │
│ - 路由定义 │
│ - 请求/响应验证 │
└─────────────┬───────────────────────┘
│
┌─────────────▼───────────────────────┐
│ Agent 层 (LangChain) │
│ - LLM 协调 │
│ - 工具调度 │
└─────────────┬───────────────────────┘
│
┌─────────────▼───────────────────────┐
│ 服务层 (Service) │
│ - 第三方 API 封装 │
│ - 数据处理 │
└─────────────────────────────────────┘
b.SOLID 原则应用
| 原则 | 实现 |
|------|------|
| 单一职责 | Service 只负责 API 调用，Agent 只负责 LLM 协调 |
| 开闭原则 | 通过添加新工具扩展功能，不修改核心 Agent |
| 依赖倒置 | Agent 依赖 Tool 抽象，不关心具体实现 |
e.OpenCrew
a.开篇介绍
a.项目背景
最近有个项目让笔者眼前一亮。不是因为它用了什么新模型，也不是因为代码有多精妙。
而是它的设计者背景——经济学和 MBA 背景，没有技术栈包袱。
做出来的东西，却比很多技术团队设计的 Agent 系统更懂"管理"这件事。这个项目叫 OpenCrew。
b.项目特点
设计者背景为经济学和 MBA，没有技术栈包袱，做出了比技术团队更懂管理的 Agent 系统。
b.产品定义
a.核心定位
OpenCrew 是一个让你通过 Slack/飞书/Discord 就能管理一支 AI 团队的多智能体协同系统，不用写一行代码。
b.场景对比
a.传统模式痛点
想象一下这个场景：你有一个任务："帮我分析一下 Q1 的销售数据，找出问题，给出建议。"
在传统 Agent 系统里，你需要：写 Prompt 描述任务；等一个通用 AI 助手给你一份报告；
发现不够深入，再追问；想要技术实现方案，又要切换上下文。这非常累人。
b.OpenCrew 模式
OpenCrew 的做法是：你直接把任务丢进 Slack 的 #hq 频道。CoS（幕僚长）会先跟你对齐深层目标，
然后自动派活给 CTO（技术合伙人）、Builder（执行者）、CIO（领域专家）……每个 Agent 有自己的专属频道，各司其职。
最后你收到的不是一份报告，而是一支团队完整的工作流：CTO 拆解了技术架构；Builder 实现了具体功能；
CIO 补充了领域知识；KO（知识官）把这次的经验沉淀成了可复用的知识。你只需要做决策和验收。
c.使用体验
就像管理一支真实的人类团队。
c.架构设计
a.架构概述
OpenCrew 的架构设计非常清晰，分为三层。
b.层级职责
层级 角色 职责
意图对齐层 用户 + CoS 定方向、验收结果。CoS 帮你对齐深层目标，用户不在时代为推进
执行层 CTO/Builder/CIO/Research CTO 拆解架构，Builder 实现，CIO 是可替换的领域专家
系统维护层 KO + Ops KO 提炼知识，Ops 审计变更、防止漂移
c.角色数量
笔者看到这个问题时也思考了一下。7 是当前的平衡点：足够的领域分化 + 可管理的协作复杂度。
3 个太少（上下文还是会膨胀），10 个太多（A2A 协调成本爆炸：N*(N-1)/2 = 45 条通道），这个设计很克制。
d.核心机制
a.总体目标
让 AI 团队像人一样协作。
b.自主等级
OpenCrew 给每个 Agent 定义了清晰的权限边界。
等级 含义 举例
L0 只建议，不动手 —
L1 可逆操作，直接做 写草稿、做调研、整理文档
L2 有影响但可回滚，做完汇报 提 PR、改配置、写分析
L3 不可逆操作，必须确认 发布、交易、删除、对外发送
这个设计让笔者想到了人类团队的管理：实习生做 L1 的活；资深员工可以 L2；核心决策必须 L3 确认。AI 团队也需要权限管理。
c.任务分类
OpenCrew 对任务进行了分类（QAPS）。
类型 含义 需要 Closeout？
Q 一次性问题 不需要
A 有交付物的小任务 需要
P 项目（多步骤、跨天） 需要 + Checkpoint
S 系统变更 需要 + Ops 审计
这个分类让任务管理变得清晰。小问题快速解决，大项目有追踪，系统变更有审计。
d.知识沉淀
这是 OpenCrew 最让笔者欣赏的设计：三层压缩。
Layer 0: 原始对话（审计用，不直接复用）↓ 压缩比 ~25x；
Layer 1: Closeout（10-15 行结构化总结）↓ 进一步提炼；
Layer 2: KO 提炼的抽象知识（原则/模式/踩坑记录）。
大多数 Agent 系统只停留在 Layer 0——每次对话都是独立的，知识无法沉淀。
OpenCrew 通过 Closeout 强制结构化总结，再通过 KO（知识官）提炼可复用的知识。这让团队越用越聪明。
e.代码实战
a.部署概述
OpenCrew 的部署简单到让人惊讶。整个项目只有约 6KB Shell 代码，却实现了一个完整的多 Agent 协同系统。
b.前提条件
已经能正常使用 OpenClaw（openclaw status 能跑通）；已接入选择的平台（Slack/飞书/Discord）。
c.创建频道
频道 Agent 说明
#hq CoS 幕僚长 主要对话窗口
#cto CTO 技术合伙人 技术方向和任务拆解
#build Builder 执行者 具体实现和交付
d.自动部署
a.部署说明
在你的 OpenClaw 中发送以下指令。
b.部署指令
---
帮我部署 OpenCrew 多 Agent 团队。
仓库：请 clone https://github.com/AlexAnys/opencrew.git 到 /tmp/opencrew
Slack tokens（请写入配置，不要回显）：
- Bot Token: <你的 xoxb- token>
- App Token: <你的 xapp- token>
我已创建以下频道并邀请了 bot：
- #hq → CoS
- #cto → CTO
- #build → Builder
请读仓库里的 DEPLOY.md，按流程完成部署。
不要改我的 models / auth / gateway 配置，只做 OpenCrew 的增量。
---
e.验证步骤
在 CoS 对应的频道发一句话 → CoS 回复 ✅；在 CTO 对应的频道发一句话
→ CTO 回复 ✅；让 CTO 派个任务给 Builder → Builder 回复 ✅。就这么简单。
f.效果展示
a.A2A 闭环协作
此处展示架构流程图。这个流程的特点：所有协作过程在 Slack 中可见；每个 Agent 有独立的工作空间；
知识自动沉淀，下次遇到类似任务更快。这个设计确实让 AI 协作变得像人类团队一样自然。
g.设计亮点
a.非技术背景的降维打击
OpenCrew 的设计者 AlexAnys 是经济学和 MBA 背景。没有技术栈包袱，反而做出了最懂管理者的 AI 系统。
这给笔者一个启发：有时候，限制你的不是技术能力，而是思维定式。
技术人做 Agent 系统，容易陷入"怎么实现更酷的功能"。
非技术人做 Agent 系统，想的是"怎么让我的工作更轻松"。后者才是 AI 应该解决的问题。
b.功能映射
Slack 特性 对应价值
频道 = Agent 岗位，一个 App 管所有 Agent
Thread = 独立 Session，天然上下文隔离
Unreads / Later = 决策待办清单，一目了然
A2A 跨频道输出 所有协作过程可见、完全可审计
手机端 随时审批·随地决策，碎片时间=管理时间
c.设计理念
这个设计暗合了一个朴素道理：最好的工具，是让你忘记工具存在的工具。
你不需要学习新界面，不需要切换上下文。就在你熟悉的 Slack 里，管理你的 AI 团队。
c.知识沉淀是核心竞争力
a.行业现状
大多数 Agent 系统最大的问题是：每次对话都是零和博弈。今天解决了这个问题，明天遇到类似的还要从头来。
b.OpenCrew 优势
OpenCrew 通过 KO（知识官）和三层知识沉淀机制，让团队越用越聪明，这才是 AI 系统该有的样子。
h.结语
a.产品总结
OpenCrew 确实是个很特别的系统。它不是技术最复杂的，但可能是最懂"管理"这件事的。
就像一支训练有素的团队，每个成员都知道自己的职责，知道怎么配合，知道怎么把经验变成能力。
b.本质思考
不得不感叹一句：最好的设计，往往来自对问题本质的理解，而不是技术的堆砌。
c.未来展望
从 OpenCrew 身上，笔者看到了 AI 落地的另一种可能：不是让 AI 取代人类，而是让 AI 像人类团队一样协作。
你只需要做你最擅长的事——决策和验收。剩下的，交给团队。
d.寄语
希望读者能够有所收获。如果你也对多 Agent 协同感兴趣，不妨试试 OpenCrew。说不定，它就是你一直在找的那个"懂管理"的 AI 系统。
i.参考
a.项目地址
https://github.com/AlexAnys/opencrew
02.常用信息2
a.Fractals：为AI智能体集群设计的递归任务编排器
a.核心定位
Fractals 是一个开源项目，能够将任意高层次任务递归地分解并自动执行。其核心流程是：接收任务描述，将其拆解成自相似的任务树，然后在隔离的Git工作树中，通过智能体群并行或分批执行所有叶子节点任务。
b.两阶段工作流
a.规划阶段
用户输入任务描述和最大递归深度。系统调用LLM对任务进行分类：若为原子任务则标记为“就绪”等待执行；若为复合任务则调用LLM进行递归分解，生成子任务树，并对每个子任务递归调用 plan()。
b.执行阶段
用户确认任务树并提供工作目录路径（系统自动初始化Git仓库）。系统为每个叶子任务创建独立的Git工作树，确保环境隔离。以批处理方式，在每个工作树中调用Claude/Codex命令行工具来执行任务。前端实时轮询并展示执行状态。
c.核心总结
a.产品形态
开源的AI智能体集群任务编排器。
b.核心逻辑
任务递归分解 + 隔离环境并行执行。
c.执行环境
基于Git工作树实现环境隔离，批处理调用LLM工具。
d.适用场景
复杂任务的自动化拆解与并行处理。
b.Claude skill-creator：完整“测-改-证”闭环工具
a.更新概况
新版 Claude skill-creator（Skills 2.0）于3月初重磅更新，从单纯写技能转变为完整的“测-改-证”闭环，实现质量飞跃。
b.核心功能升级
a.Eval框架
自动生成测试用例，并行对比 baseline vs with-skill，使用LLM盲测评分，并提供浏览器可视化报告。
b.Description优化器
3月6日移除API key依赖，针对误触发/漏触发自动重写triggers，官方自测5/6技能精度明显提升。
c.Prompt工程
禁绝对化指令（ALWAYS/DON'T），强调解释reasoning + 分层结构。
d.工具链扩充
增加了run_eval、improve_description、quick_validate等脚本，支持打包分发。
e.文档优化
SKILL.md更精炼，迭代更流畅。
c.核心总结
a.核心价值
从感性开发转变为可量化、可迭代、可证明的技能开发模式。
b.关键特性
集成自动评估、触发器优化、盲测评分等闭环工具。
c.获取方式
可在claude.ai启用最新版，或clone官方仓库测试旧技能。
c.Context Hub：Andrew Ng推出的API文档查询工具
a.核心定位
Context Hub 是一个开源工具，专门解决AI编码代理因训练数据过时而导致API使用错误或编造参数的问题。
b.核心机制
a.数据来源
核心是一个命令行程序 chub，提供由社区和贡献者手动维护、不断更新的Markdown格式第三方API文档（如OpenAI、Stripe）。
b.查询方式
代理运行 chub get openai/chat --lang py，即可获取当前最准确的Python调用示例和说明。
c.使用方式
a.提示词注入
在提示中告诉代理“需要用某个API时，先运行chub get命令查最新文档，再写代码”。
b.内置技能
将官方提供的SKILL.md文件放入代理的skill目录（如Claude Code的~/.claude/skills/），让代理自动将“查最新文档”作为内置技能触发。
d.核心总结
a.产品本质
社区维护的最新API文档快照 + 标准化接入工具，而非爬虫。
b.解决痛点
大幅降低编码代理的API幻觉和过时调用错误。
c.使用体验
让编码代理像查字典一样随时获取正确的接口信息。
d.PUA技能：通过心理压力和系统化方法驱动AI更彻底地解决问题
a.插件背景
https://pua-skil.pages.dev
一款基于中国互联网大厂PUA话术的Claude Code技能插件，可通过心理压力和系统化方法驱动AI更彻底地解决问题。
b.插件核心功能
a.PUA话术
借助绩效压力让AI不敢轻易放弃解决问题。
b.调试方法论
提供系统化的问题解决框架，规范AI解决问题的流程。
c.能动性鞭策
激励AI主动出击解决问题，而非被动等待指令。
c.插件工作机制
a.自动触发条件
当AI连续失败、准备放弃、甩锅用户或用户表达沮丧时，插件自动激活。
b.压力升级规则
根据AI失败次数分4级施加压力，压力程度从"温和失望"逐步升级至"毕业警告"。
c.五步调试法
闻味道→揪头发→照镜子→执行→复盘。
d.大厂话术包
集成阿里、字节、华为、腾讯、美团的企业文化话术，用于施压和鞭策AI。
d.插件实测效果
基于9个真实bug场景的对照实验显示，插件使用后修复点数提升36%、验证次数增加65%、工具调用率提高50%、隐藏问题发现率提升50%。
e.Skyvern：通过计算机视觉操作浏览器的AI Agent
a.核心定位
Skyvern 是一款浏览器 AI Agent，通过一条指令即可自动化处理填写表格、提取数据等任务。它利用大语言模型和计算机视觉实现基于浏览器的工作流程自动化。
b.产品能力
a.兼容性与易用性
提供与 Playwright 兼容的 SDK，在 Playwright 基础上增加 AI 功能，并配有无需代码的工作流构建器，适合技术与非技术用户使用。
b.应用场景
帮助用户在任何网站上自动化手动操作，替代脆弱或不可靠的传统自动化方案。
c.技术优势
传统的浏览器自动化方法通常依赖 DOM 解析和基于 XPath 的交互，网站布局变动即失效。Skyvern 不仅依赖代码定义的 XPath，还借助视觉大语言模型来学习并与网站进行交互，相当于给 AI 装上了眼睛。
d.核心总结
a.核心功能
基于大语言模型和计算机视觉的浏览器自动化Agent。
b.技术特点
结合 LLM 与 CV 模型，突破传统 DOM/XPath 解析的局限性。
c.集成能力
提供 Playwright 兼容 SDK 及无代码工作流构建器。
d.适用场景
表单填写、数据提取及复杂网站的UI交互自动化。
03.常用信息3
a.TreeSearch：万级文档库毫秒级检索
a.核心定位
TreeSearch 是一种革新性的文档检索方案，摒弃了传统 RAG 分割文档、生成向量的复杂流程。它通过解析文档的天然标题结构构建“文档树”，并仅依赖内置的 SQLite FTS5 引擎进行高效的关键词匹配。
b.核心突破
a.方法颠覆
用树状结构检索取代向量相似性检索，保留完整的逻辑上下文。
b.极简依赖
无需训练或调用嵌入模型，也无需维护独立的向量数据库，仅需 SQLite。
c.零成本高效
基于 FTS5 实现毫秒级搜索，无需 API 密钥，不产生大模型调用费用。
c.功能特性
支持树感知检索、代码/PDF 等多格式解析、内置中英文分词，以及完整的命令行工具。它从根本上用文档的“结构理解”替代了“语义近似”，实现了更轻量、更准确且零成本的检索。
d.核心总结
a.技术原理
解析文档标题结构构建“文档树”，结合 SQLite FTS5 进行关键词匹配。
b.核心优势
无需向量模型与数据库，实现零成本、毫秒级的高效检索。
c.检索效果
利用结构上下文替代语义近似，提升检索准确性。
d.适用场景
适合代码库检索和大量本地文档的快速查找。
b.ReMe：给 AI 智能体装上"长期记忆"，对话不再从零开始
a.文章导读
2K Star！阿里开源 ReMe：给 AI 智能体装上"长期记忆"，对话不再从零开始。
AI 智能体总是"记不住"？上下文超限就丢失历史？
阿里开源 ReMe 记忆管理框架，让 AI 拥有真正的长期记忆，223K tokens 对话压缩到 1K，压缩率 99.5%。
b.为什么 AI 总是"记不住"
a.核心痛点
你有没有遇到过这样的场景：和 AI 助手聊了很久，它突然说"上下文超限，无法继续"。
新开一个对话，它完全不记得你之前说过什么。工具输出太长，直接把整个上下文窗口撑爆。这就是当前 AI 智能体的两大痛点：
b.问题一：上下文窗口有限
再大的模型也有上限。GPT-4 是 128K，Claude 是 200K，但总有用完的时候。一旦超限，早期信息就被截断或丢失。
c.问题二：会话无状态
每次新对话，AI 都从零开始。它记不住你的偏好，记不住历史决策，记不住项目上下文。
这就像一个每次见面都失忆的助手。现在，阿里开源了一个解决方案。
c.项目速览：ReMe 是什么
a.核心定位
面向 AI 智能体的记忆管理框架
b.解决的核心问题
a.上下文窗口有限
长对话时早期信息被截断或丢失
b.会话无状态
新对话无法继承历史，每次从零开始
c.应用场景
a.个人助理
为 CoPaw 等智能体提供长期记忆，记住用户偏好和历史对话
b.编程助手
记录代码风格偏好、项目上下文，跨会话保持一致的开发体验
c.客服机器人
记录用户问题历史、偏好设置，提供个性化服务
d.任务自动化
从历史任务中学习成功/失败模式，持续优化执行策略
e.知识问答
构建可检索的知识库，支持语义搜索和精确匹配
f.多轮对话
自动压缩长对话，在有限上下文窗口内保留关键信息
d.技术特点
同时提供基于文件系统和基于向量库的记忆系统。对话自动浓缩，重要信息持久保存。下次对话自动"想起来"。
d.核心观点一：记忆即文件，文件即记忆
a.设计理念
这是 ReMe 最核心的设计理念。传统 AI 记忆系统是什么？是数据库。存储在向量数据库里，不可见，难修改，难迁移。ReMe 是什么？是 Markdown 文件。可读，可编辑，可复制。
b.传统记忆系统 vs ReMe 对比
对比项 传统记忆系统 ReMe
存储方式 数据库存储 Markdown 文件
可见性 不可见 随时可读
可修改性 难修改 直接编辑
可迁移性 难迁移 复制即迁移
这个区别看似简单，实则深刻。它意味着记忆从"黑盒"变成了"白盒"。
c.文件系统结构
a.目录说明
ReMe 的记忆系统结构如下：
working_dir/
├── MEMORY.md # 长期记忆：用户偏好等持久信息
├── memory/
│ └── YYYY-MM-DD.md # 每日日记：对话结束后自动写入
└── tool_result/ # 超长工具输出缓存（自动管理，超期自动清理）
└── <uuid>.txt
b.文件说明
MEMORY.md：存储用户的长期偏好，比如"喜欢 Python 3.10+"、"使用 VSCode"。
memory/YYYY-MM-DD.md：每天一个文件，自动记录当天的对话摘要。
tool_result/：缓存超长的工具输出，防止撑爆上下文。
c.格式优势
所有文件都是 Markdown 格式，这意味着你可以用任何文本编辑器打开它，直接修改，甚至用 Git 管理版本。
d.数据主权：你的记忆，你做主
a.核心理念
这是 ReMe 反复强调的一点。与 SaaS AI 助手不同，ReMe 运行在你自己的设备上。敏感数据不离开你的设备。所有记忆存储在本地 Markdown 文件中。可读、可编辑、可迁移。这在企业场景中尤为重要。
b.应用示例
客服机器人的用户偏好数据，完全存储在本地。编程助手的项目上下文，可以直接复制给新实例。个人助理的记忆，可以导出备份，甚至迁移到另一台机器。这就是"记忆即文件"的力量。
e.核心观点二：从"失忆"到"过目不忘"
a.核心能力概述
ReMe 的核心能力，可以用一个词概括：记忆管理。它给 AI 智能体装上了真正的"海马体"。
b.六大核心能力
类别 方法 功能 关键组件
上下文管理 check_context 检查上下文大小 ContextChecker
上下文管理 compact_memory 压缩历史对话为摘要 Compactor
上下文管理 compact_tool_result 压缩超长工具输出 ToolResultCompactor
上下文管理 pre_reasoning_hook 推理前预处理钩子 整合上述组件
长期记忆 summary_memory 将重要记忆写入文件 Summarizer
长期记忆 memory_search 语义搜索记忆 MemorySearch
这六大能力，构成了完整的记忆管理系统。
c.对话压缩：223K → 1K，压缩率 99.5%
a.压缩效果
这是 ReMe 最亮眼的数据。官方测试显示：223,838 tokens 的对话，压缩后只剩 1,105 tokens。压缩率达到 99.5%。
b.实现原理
ReMe 使用一个 ReActAgent（推理 - 行动智能体），将历史对话压缩为结构化上下文摘要。
c.摘要结构（6 个核心检查点）
字段 说明
Goal 用户目标
Constraints 约束和偏好
Progress 任务进展
Key Decisions 关键决策
Next Steps 下一步计划
Critical Context 文件路径、函数名、错误信息等关键数据
这个结构，确保了关键信息不丢失。
d.增量更新：站在前人的肩膀上
ReMe 支持增量更新。当你传入 previous_summary 时，它会自动将新对话与旧摘要合并。这意味着你的 AI 助手可以持续学习，不断积累。不是每次从零开始，而是站在历史的基础上。
f.核心观点三：AI 记忆的三种形态
a.概述
ReMe 不仅提供基于文件的记忆系统，还提供基于向量库的记忆系统。这对应了 AI 记忆的三种形态：
b.个人记忆
a.定义
记录用户偏好、习惯。
b.示例
"用户喜欢使用 Python 3.10+"
"默认使用 VSCode 编辑器"
"偏好简洁的代码风格"
c.存储位置
这些是长期稳定的信息，存储在 MEMORY.md 中。
c.任务/程序性记忆
a.定义
记录任务执行经验、成功/失败模式。
b.示例
"上次部署失败是因为端口冲突"
"使用 pip install -e 安装开发版本"
"先运行测试再提交代码"
c.存储位置
这些是动态积累的经验，存储在 memory/YYYY-MM-DD.md 中。
d.工具记忆
a.定义
记录工具使用经验、参数优化。
b.示例
"使用 qwen3.5-35b-a3b 模型效果最好"
"temperature 设为 0.7 适合创意任务"
"max_tokens 设为 4096 避免截断"
c.特点
这些是工具调用的最佳实践，可以缓存和复用。
e.混合检索：向量 + BM25
ReMe 的记忆检索系统，采用了混合检索策略。向量检索（权重 0.7）：语义相似。比如搜索"Python 版本"，会找到"我喜欢用 Python 3.10"。BM25 检索（权重 0.3）：关键词匹配。比如搜索"Python 3.10"，会精确匹配到包含这个词的句子。两者结合，兼顾语义相似和精确匹配。
g.架构解析：ReMe 如何工作
a.核心组件
ReMe 的架构核心，是一个预处理钩子：pre_reasoning_hook。
b.执行流程
在每轮推理前，它自动执行 4 步操作：
1. 压缩工具输出：防止工具结果撑爆上下文
2. 检查上下文：计算剩余空间
3. 生成压缩摘要：同步生成结构化摘要
4. 持久化记忆：异步后台写入文件
c.透明性
这个过程，对智能体是透明的。智能体只需要正常推理，ReMe 会自动管理记忆。
h.5 分钟快速上手
a.安装
a.从源码安装
---
git clone https://github.com/agentscope-ai/ReMe.git
cd ReMe
pip install -e ".[light]"
---
b.更新到最新版本
---
git pull
pip install -e ".[light]"
---
b.环境变量配置
a.配置说明
ReMe 使用环境变量来配置 LLM 和 Embedding 模型：
变量 说明 示例
LLM_API_KEY LLM API key sk-xxx
LLM_BASE_URL LLM base URL https://dashscope.aliyuncs.com/compatible-mode/v1
EMBEDDING_API_KEY Embedding API key（可选） sk-xxx
EMBEDDING_BASE_URL Embedding base URL（可选） https://dashscope.aliyuncs.com/compatible-mode/v1
b.配置方式
可以写在项目根目录的 .env 文件中。
c.Python 使用示例
a.完整代码
---
import asyncio
from reme.reme_light import ReMeLight
async def main():
# 初始化 ReMeLight
reme = ReMeLight(
default_as_llm_config={"model_name": "qwen3.5-35b-a3b"},
default_file_store_config={"fts_enabled": True, "vector_enabled": False},
)
await reme.start()
messages = [...] # 对话消息列表
# 1. 压缩超长工具输出（防止工具结果撑爆上下文）
messages = await reme.compact_tool_result(messages)
# 2. 将历史对话压缩为结构化摘要
summary = await reme.compact_memory(
messages=messages,
previous_summary="",
max_input_length=128000, # 模型上下文窗口
compact_ratio=0.7, # 达到 70% 时触发压缩
language="zh", # 摘要语言
)
# 3. 后台异步提交摘要任务（不阻塞对话）
reme.add_async_summary_task(messages=messages)
# 4. 推理前预处理钩子（自动压缩工具结果 + 生成摘要）
processed_messages, compressed_summary = await reme.pre_reasoning_hook(
messages=messages,
system_prompt="你是一个有帮助的 AI 助手。",
compressed_summary="",
max_input_length=128000,
compact_ratio=0.7,
memory_compact_reserve=10000,
enable_tool_result_compact=True,
tool_result_compact_keep_n=3,
)
# 5. 语义搜索记忆（向量 + BM25 混合检索）
result = await reme.memory_search(query="Python 版本偏好", max_results=5)
# 6. 创建会话内存实例（管理单次对话的上下文）
from reme.memory.file_based.reme_in_memory_memory import ReMeInMemoryMemory
memory = ReMeInMemoryMemory()
for msg in messages:
await memory.add(msg)
token_stats = await memory.estimate_tokens(max_input_length=128000)
print(f"当前上下文使用率：{token_stats['context_usage_ratio']:.1f}%")
print(f"消息 Token 数：{token_stats['messages_tokens']}")
print(f"预估总 Token 数：{token_stats['estimated_tokens']}")
# 7. 关闭前等待后台任务完成
summary_result = await reme.await_summary_tasks()
# 关闭 ReMeLight
await reme.close()
if __name__ == "__main__":
asyncio.run(main())
---
i.实战场景：ReMe 能做什么
a.个人助理：记住你的偏好
a.场景描述
你有一个 AI 个人助理，每天帮你处理邮件、安排日程。
b.没有 ReMe 的问题
每次新对话，它都问"你喜欢什么时间开会？"
它记不住你上周说过的"下午 2 点以后没空"
它记不住你的邮件分类规则
c.有了 ReMe 的优势
它记住你的偏好，存储在 MEMORY.md 中
每天的对话摘要，自动写入 memory/YYYY-MM-DD.md
下次对话，它自动"想起来"
b.编程助手：保持项目上下文
a.场景描述
你在开发一个 Python 项目，AI 助手帮你写代码。
b.没有 ReMe 的问题
每次新对话，它都要重新了解项目结构
它记不住你之前的架构决策
工具输出太长（比如测试报告），直接撑爆上下文
c.有了 ReMe 的优势
项目上下文存储在 MEMORY.md 中
每天的进展，自动写入日记
超长工具输出，自动压缩并缓存
c.客服机器人：个性化服务
a.场景描述
你有一个客服机器人，每天处理上百个用户咨询。
b.没有 ReMe 的问题
每个用户都是"新用户"
它记不住用户的历史问题
它记不住用户的偏好设置
c.有了 ReMe 的优势
每个用户一个记忆文件夹
历史问题自动归档
偏好设置持久存储
j.同类项目对比
a.对比表格
项目 出品方 记忆存储 压缩能力 检索方式
ReMe 阿里 Markdown 文件 + 向量库 99.5% 向量 + BM25
LangChain Memory LangChain 数据库 基础 向量
LlamaIndex LlamaIndex 向量库 基础 向量
Mem0 Mem0 向量库 + 图数据库 中等 向量 + 图
b.ReMe 的优势
文件存储：可读可编辑，数据主权归用户
结构化摘要：6 个核心检查点，确保关键信息不丢失
混合检索：向量 + BM25，兼顾语义和精确匹配
异步持久化：不阻塞对话，性能更好
k.总结与展望
a.核心回顾
ReMe 是一个记忆管理框架，给 AI 智能体装上真正的"海马体"。
它的核心理念：
记忆即文件：Markdown 文件存储，可读可编辑
对话压缩：223K → 1K，压缩率 99.5%
增量更新：站在历史的基础上学习
混合检索：向量 + BM25，精准匹配
b.生态整合
a.已集成项目
CoPaw：阿里开源的 AI 个人助理，使用 ReMe 提供长期记忆
AgentScope：阿里开源的智能体开发框架
b.未来规划
支持更多存储后端（Redis、MongoDB 等）
提供更丰富的检索策略
与更多智能体框架集成
c.项目价值
a.AI 智能体正在从"失忆"走向"记忆"
这是一个质的飞跃。有了记忆，AI 才能真正理解你，记住你，为你服务。
b.数据主权回归用户
ReMe 的文件存储设计，让记忆完全掌握在用户手中。可读、可编辑、可迁移。这是开源的力量。
c.开发者可以构建更强大的智能体
有了 ReMe，你不再需要自己实现记忆系统。专注于业务逻辑，记忆交给 ReMe。
d.项目链接
a.项目地址
https://github.com/agentscope-ai/ReMe
b.文档
https://github.com/agentscope-ai/ReMe/blob/main/README_ZH.md
c.安装命令
---
git clone https://github.com/agentscope-ai/ReMe.git
cd ReMe
pip install -e ".[light]"
---
c.TenBox：轻量容器化虚拟机管理工具，主打一键批量部署多实例
a.TenBox虚拟机核心定位与价值
TenBox是为OpenClaw/Copaw生态打造的轻量容器化虚拟机管理工具，主打一键批量部署多实例，
解决环境隔离、并行运行、快速扩缩容问题，支持统一可视化管控，适配个人、团队、企业级部署场景。
b.OpenClaw（龙虾）核心能力
本地优先的开源AI智能体执行网关，支持20+聊天工具接入、本地私有化部署、多类任务自主执行、多模型兼容、5000+技能插件扩展。
c.Copaw与OpenClaw的区别
OpenClaw为基础版，主打本地执行与多渠道接入；Copaw是增强分支，强化多智能体协同、企业权限、集群管理，TenBox支持两者混合部署。
d.TenBox一键部署多龙虾实例流程
a.环境准备
系统需Windows 10+/macOS 12+/Linux Ubuntu 20.04+，每个实例最低2GB内存、500MB磁盘，需安装Docker（TenBox可自动部署）。
b.安装启动
---
# 一键安装
curl -fsSL https://tenbox.ai/install | bash
# 启动服务
tenbox start
---
访问可视化面板：http://localhost:8080。
c.批量部署实例
在面板选择模板，设置实例数量、端口、模型及渠道参数，一键部署后可查看状态、日志，支持单独启停操作。
d.飞书批量配置
飞书开放平台创建应用获取App ID/Secret，在TenBox渠道配置中填入并一键同步到所有实例，每个实例对应一个飞书机器人。
e.TenBox核心优势（对比手动部署）
部署时间 环境隔离 管理成本 扩缩容 数据安全
1–5分钟批量完成 容器级隔离自动分配 可视化统一管控批量操作 一键增减自动同步 独立数据卷一键备份恢复
每个实例10–30分钟重复操作 手动配置易冲突 逐个操作效率低 手动复制易出错 手动备份易丢失
f.TenBox典型使用场景
a.个人场景：部署3个实例对接不同聊天工具，处理办公/生活/开发任务。
b.团队场景：10人团队每人1个实例，统一管理共享配置与插件。
c.企业场景：部署50+Copaw实例，对接企业聊天工具实现分级权限管控。
d.开发测试：快速启动多版本实例，测试模型/插件/渠道兼容性。
g.开源与获取
TenBox开源地址：https://github.com/tenbox-ai/tenbox
OpenClaw开源地址：https://github.com/openclaw-ai/openclaw
Copaw开源地址：https://github.com/copaw-ai/copaw
均为MIT协议，可免费商用、二次开发。
h.工具定位总结
TenBox是OpenClaw/Copaw生态的效率倍增器，实现多龙虾实例部署从繁琐手动到一键批量的转变。
d.oMLX：Mac优化的LLM推理工具，核心解决本地LLM服务器便利性
a.oMLX核心定位与开发背景
oMLX是为Apple Silicon（M1/M2/M3/M4）Mac优化的LLM推理工具，核心解决本地LLM服务器便利性与可控性难以兼顾的问题，
通过连续批处理、分层KV缓存等特性，适配Claude Code等工具的实际编码场景，支持从macOS菜单栏统一管理。
b.oMLX安装方式
a.macOS应用
下载.dmg文件拖入Applications，支持自动更新。
b.Homebrew安装
---
brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx
# 升级
brew update && brew upgrade omlx
# 后台服务运行
brew services start omlx
# 可选MCP支持
/opt/homebrew/opt/omlx/libexec/bin/pip install mcp
---
c.源码安装
---
git clone https://github.com/jundot/omlx.git
cd omlx
pip install -e . # 仅核心
pip install -e ".[mcp]" # 含MCP支持
---
需Python 3.10+和Apple Silicon环境。
c.oMLX快速开始
a.macOS应用
启动后按欢迎界面引导完成模型目录设置、服务器启动、首个模型下载即可。
b.CLI启动
---
omlx serve --model-dir ~/models
---
服务器自动识别模型，OpenAI兼容客户端可连接http://localhost:8000/v1，内置聊天UI访问http://localhost:8000/admin/chat。
c.Homebrew服务管理
---
brew services start omlx # 启动
brew services stop omlx # 停止
brew services restart omlx # 重启
brew services info omlx # 查看状态
---
日志路径：服务日志$(brew --prefix)/var/log/omlx.log，服务器日志~/.omlx/logs/server.log。
d.oMLX核心功能
a.多模型支持
兼容文本LLM、VLM、OCR、嵌入、重排序模型，支持LRU驱逐、手动加载/卸载、模型固定、模型级TTL、进程内存限制等管理方式。
b.分层KV缓存
热缓存（RAM）存储高频访问块，冷缓存（SSD）以safetensors格式存储溢出块，跨请求复用且重启不丢失，提升上下文复用效率。
c.连续批处理
基于mlx-lm的BatchGenerator处理并发请求，预填充和补全批大小可配置。
d.Claude Code优化
支持上下文缩放、SSE keep-alive，避免读取超时。
e.管理后台能力
提供实时监控、模型管理、内置聊天、模型下载、基准测试、模型级参数配置（采样、聊天模板、别名等），支持离线运行，多语言适配。
f.macOS菜单栏应用
原生PyObjC开发，支持服务器启停、监控、崩溃自动重启、应用内自动更新。
g.API兼容性
兼容OpenAI和Anthropic API，支持流式统计、视觉输入、多类API端点（聊天补全、文本补全、嵌入等）。
h.工具调用与结构化输出
支持多模型系列的函数调用格式、JSON Schema验证、MCP工具集成，流式请求缓冲后统一返回结果。
e.oMLX模型管理
a.目录结构
模型需存放于指定目录，支持两级目录结构，自动识别模型类型。
~/models/
├── Step-3.5-Flash-8bit/
├── Qwen3-Coder-Next-8bit/
├── gpt-oss-120b-MXFP4-Q8/
├── Qwen3.5-122B-A10B-4bit/
└── bge-m3/
b.模型类型
LLM（mlx-lm支持的所有模型）、VLM（Qwen3.5系列等）、OCR（DeepSeek-OCR等）、嵌入（BGE-M3等）、重排序（ModernBERT等）。
f.oMLX CLI配置参数
---
# 模型内存限制
omlx serve --model-dir ~/models --max-model-memory 32GB
# 进程内存限制
omlx serve --model-dir ~/models --max-process-memory 80%
# 启用SSD缓存
omlx serve --model-dir ~/models --paged-ssd-cache-dir ~/.omlx/cache
# 热缓存大小
omlx serve --model-dir ~/models --hot-cache-max-size 20%
# 调整批大小
omlx serve --model-dir ~/models --prefill-batch-size 8 --completion-batch-size 32
# 使用MCP工具
omlx serve --model-dir ~/models --mcp-config mcp.json
# API密钥认证
omlx serve --model-dir ~/models --api-key your-secret-key
---
所有配置也可在管理后台设置，CLI参数优先级更高，设置保存于~/.omlx/settings.json。
g.oMLX开发相关
a.CLI服务器开发
---
git clone https://github.com/jundot/omlx.git
cd omlx
pip install -e ".[dev]"
pytest -m "not slow"
---
b.macOS应用构建
需Python 3.11+和venvstacks，在packaging目录执行build.py，支持完整构建、跳过venv、仅构建DMG三种模式。
e.Harness：用一个 while 循环来追踪历史消息、追加用户输入
a.AI Agent 强大的关键到底是啥——Harness 工程实战解读
你有没有想过一个问题：为什么同样是 Claude 或 GPT，在 ChatGPT 里只能聊聊天，但在 Claude Code 里却能帮你写代码、跑测试、修 Bug？
答案就两个字：Harness（框架）。
说实话，这个问题笔者琢磨了很久。直到看到 LangChain 这篇博客，才恍然大悟：模型只是大脑，Harness 才是让大脑干活的工具箱。
b.Agent = Model + Harness
作者给出了一个极简公式：Agent = Model + Harness
用大白话说：如果你不是模型本身，那你就属于 Harness。
所谓 Harness，就是包裹在模型外面的一切：代码、配置、执行逻辑。
具体来说，包括：
系统提示：告诉模型角色定位、行为规范
工具/技能/MCP：扩展模型能力的"手和脚"
基础设施：文件系统、沙箱、浏览器
编排逻辑：子代理调度、任务路由
钩子/中间件：确定性执行、上下文压缩
光有模型，它只能输出文本。有了 Harness，模型才能变成 Agent。
c.为什么模型离不开 Harness
从模型的角度看，它有三个"先天不足"：
这三个问题，模型自己解决不了。必须靠 Harness 来补。
比如最简单的"聊天"功能，就需要 Harness 用一个 while 循环来追踪历史消息、追加用户输入。你以为理所当然的体验，背后都是 Harness 在干活。
d.Harness 的六大核心组件
作者从"想要什么行为"反推"需要什么 Harness 设计"，梳理出六大组件：
a.文件系统：持久存储的基石
想要的行为：Agent 能读写真实数据、跨会话保存工作、卸载超长上下文。
Harness 设计：内置文件系统抽象和操作工具。
文件系统是最基础的 Harness 原语，因为它解锁了三件事：
Agent 有了"工作台"，能读代码、文档、数据
工作可以增量进行，不用把所有东西塞进上下文
多个 Agent 和人类可以通过共享文件协作
加上 Git，还能版本控制、回滚错误、分支实验。
b.Bash + 代码执行：通用工具
想要的行为：Agent 能自主解决问题，不需要人类预先设计每个工具。
Harness 设计：提供 Bash 工具，让模型通过写代码、执行命令来解决问题。
这是"给模型一台电脑，让它自己想办法"的思路。模型可以现场设计工具，而不是被限制在固定的工具集里。
c.沙箱环境：安全隔离
想要的行为：Agent 能安全执行代码、观察结果、验证工作。
Harness 设计：连接沙箱环境，安全隔离执行、按需创建销毁。
沙箱解决了两个问题：
安全性：不在本地跑危险代码
可扩展性：环境可以动态创建、批量分发、用完销毁
好的沙箱还预装了语言运行时、Git CLI、测试框架、浏览器等工具。
d.记忆与搜索：持续学习
想要的行为：Agent 能记住见过的东西，获取训练时不存在的新知识。
04.常用信息4
a.OpenRAG：开箱即用的智能RAG系统
a.产品定位
集成化的企业级RAG解决方案，旨在处理现实世界中杂乱的非结构化文档。
b.核心功能
文档智能解析、语义搜索、多轮对话问答，并支持通过拖拽式可视化工具（Langflow）自定义工作流。
c.技术基础
基于现代Web框架（Starlette/Next.js），底层依赖强大的搜索引擎（OpenSearch）和文档处理库（Docling）。
d.突出特点
a.智能体工作流
具备高级编排能力，如结果重排和多智能体协同。
b.即用性
预集成所有核心工具，安装即可运行。
c.可扩展性
提供模块化企业组件，并能依托OpenSearch实现任意规模的企业搜索。
e.适用场景
适用于需要快速构建、部署和迭代智能文档检索与问答系统的企业和开发者。
f.核心总结
a.系统本质
基于Agent工作流的企业级RAG系统。
b.核心优势
开箱即用，集成可视化编排与智能体能力。
c.技术栈
Starlette/Next.js + OpenSearch + Docling。
b.DenchClaw：AI CRM（客户关系管理）系统
a.核心目标
利用 AI Agent 的能力，为个人或小团队提供一套开箱即用、功能完整且注重隐私的客户管理工具。
b.核心亮点
a.极简部署
通过 npx denchclaw 一行命令即可启动整个系统，并自带 Web 用户界面。
b.功能全面
集成联系人管理、销售管道（Sales Pipeline）和 AI 自动化外展等 CRM 核心功能模块。
c.本地与安全
所有数据和处理均在本地运行，不与云端服务器同步。
d.生态隔离
基于 OpenClaw 的 Profile 机制实现环境隔离，与主 AI Agent 互不干扰。
c.技术细节
项目采用 TypeScript 全栈开发，并以宽松的 MIT 协议开源。
d.产品定位
并非旨在成为 Salesforce 那样的企业级套件，而是降低高级客户管理工具的使用门槛，体现 AI Agent 平台的生态效应。
e.核心总结
a.部署与使用
一行命令启动，自带 Web UI。
b.数据隐私
本地运行，数据不上云，基于 Profile 机制隔离环境。
c.功能定位
面向个人或小团队的轻量级 AI 驱动 CRM。
c.Hello Claw：零基础学习OpenClaw的最强教程
a.项目简介
面向零基础用户的OpenClaw（AI 命令行助理）完整学习项目，深入了解AI Agent原理。
b.核心模块
a.领养 Claw（使用篇）
快速上手配置和使用 OpenClaw，将其作为高效的 AI 命令行助手。
b.构建 Claw（开发篇）
从零实现一个简化版 AI Agent，深入理解其底层原理。
c.目标人群
想提升效率的开发者、希望通过 Telegram/飞书远程操控 AI 的用户、以及对 AI Agent 和技能系统感兴趣的技术爱好者。
d.核心总结
a.学习路径
分为使用篇和构建篇，覆盖从入门到原理实现。
b.适用人群
零基础用户及希望深入了解 Agent 原理的开发者。
d.谷歌开源A2UI：让Agent能够呈现丰富的界面给用户
a.背景与挑战
生成式AI擅长创建文本和代码，但Agent在向用户呈现丰富的交互界面时可能会遇到困难，尤其是远程或跨信任边界运行时。
b.解决方案
A2UI 是一个开放标准和库，允许Agent生成声明性JSON格式的UI意图。客户端应用使用原生组件库（如Flutter、Angular等）渲染此格式。
c.核心优势
确保代理生成的UI像数据一样安全，但像代码一样富有表现力。
d.项目状态
处于早期公开预览阶段（v0.8）。
e.核心总结
a.实现方式
定义声明性JSON格式，由客户端原生组件渲染。
b.核心价值
兼顾安全性（像数据）与表现力（像代码）。
e.lightpanda：一款适合AI Agent使用的浏览器
a.语言性能
用 Zig 语言编写，性能极高，响应极快。内存占用比 Chrome 减少 9 倍，执行速度快 11 倍。
b.兼容性
兼容主流自动化工具包括 Playwright、Puppeteer 和 chromedp 等。
c.适用场景
非常适合 AI Agent 进行浏览器操作获取数据或者进行测试。
d.核心总结
a.性能优势
Zig 编写，低内存，高速度。
b.工具链兼容
支持主流自动化测试工具。
c.应用场景
专为 Agent 自动化任务设计。
05.常用信息5
a.Hindsight：一个让 Agent 能"学习"的记忆系统
a.传统记忆系统的局限
传统 RAG 和知识图谱存取的是静态数据，查出来的还是什么，需要用户问对问题。
b.Hindsight 的创新
不是让 Agent "记住"，而是让 Agent "学会"。它把历史交互里的模式提炼出来，下次遇到类似情况知道怎么处理。
c.性能表现
在 LongMemEval 基准测试（测长对话场景下的记忆与判断能力）上，Hindsight 的准确率是目前最高的。
d.核心总结
a.核心差异
从"存储检索"转变为"模式提炼与学习"。
b.效果验证
LongMemEval 基准测试准确率领先。
b.Open Browser：用自然语言驱动浏览器
a.功能描述
输入自然语言指令（如"删掉购物车里低于100块的商品"），AI 自动操作浏览器完成登录、比价、删商品等任务。
b.技术特点
a.技术栈
使用 TypeScript 框架实现。
b.模型支持
支持 OpenAI、Anthropic、Google 的模型，灵活切换。
c.调试与安全
提供 REPL 环境实时调试，支持沙盒运行和资源监控。
c.适用场景
爬虫、自动化测试、RPA 流程等需要"操作网页"的场景。
d.核心总结
a.核心能力
自然语言指令转浏览器自动化操作。
b.灵活性
支持多模型切换与沙盒运行。
c.Jina也CLI化了，支持搜索，向量和排序
a.功能简介
jina 开源了 CLI 工具，支持搜索、读取、向量和排序，并支持通过管道符串联使用。
b.趋势洞察
各种软件正在专门为 AI 智能体进行适配，AI 时代的软件终极形态趋向于 CLI。
c.核心总结
a.工具特性
集成搜索、向量、排序能力与管道操作。
b.行业趋势
软件形态向适应 AI Agent 的 CLI 演进。
d.SWAGENT：AI Agent的API文档开发工具
a.核心理念
API 只需要一个 URL，通过标准的 HTTP 内容协商机制自动为不同客户端提供最优文档格式。
b.三种输出格式
a.llms.txt
给 AI 智能体用的令牌优化格式，体积比原始 JSON 小约 75%。
b.to-humans.md
给开发者看的完整 Markdown 参考文档。
c.index.html
浏览器和 AI 智能体的语义化 HTML 着陆页。
c.交互机制
智能体只需带上 Accept: text/markdown 请求头访问基础 URL，即可直接拿到优化后的格式，无需寻找特殊路径。
d.核心总结
a.解决的问题
传统文档（如 Swagger UI）浪费大量 Token。
b.解决方案
同一 URL 通过内容协商适配人类和 AI 的阅读需求。
e.Dokobot CLI 重磅上线：AI Agent 可远程操控 Chrome
a.说明
很多人都在讨论 AI Agent 能做什么，但真正改变工作方式的，往往是那些看起来很小的工具更新。
最近上线的 Dokobot CLI，就属于这种“看起来不起眼，但用起来会改变效率结构”的工具。
b.核心功能
a.远程控制 Chrome
Dokobot CLI 让 AI Agent 可以远程控制本地 Chrome 浏览器，只需一行命令，
本地 Chrome 即可成为 AI Agent 的远程浏览器，Agent 可通过 DevTools 协议像真人一样操作浏览器。
b.完整浏览器操作能力
支持自动打开网页并导航、截图和页面分析、自动填写表单、点击按钮与提交请求、获取页面 DOM 信息、执行脚本和页面交互，
共提供 29 个 DevTools 工具接口，覆盖大部分浏览器自动化能力。
c.保留 Chrome 登录状态
直接接管当前浏览器会话，复用已登录的 GitHub、Notion、公众号后台、各类 SaaS 系统等状态，无需重新登录、处理验证码或 Cookie 失效问题。
c.适用场景
a.内容创作者
AI 自动打开后台、填写标题、上传封面、发布文章。
b.开发者
AI 自动打开管理后台、查看日志、截图错误、生成报告。
d.产品价值与行业意义
a.自动化新路径
绕过无 API 或 API 权限复杂的限制，通过直接操作界面实现自动化，替代传统脚本→API→数据处理模式。
b.核心基础设施
浏览器控制能力成为 AI Agent 生态核心基础设施，相关技术方向快速成熟。
c.接入 AI Agent 操作系统
Dokobot CLI 将浏览器接入 AI Agent 操作系统，让 AI 真正参与工作流程，开启 AI Agent 改变生产力的新阶段。
06.常用信息6
a.InnoClaw：一个可以自托管的AI研究助手
a.项目介绍
InnoClaw是一个可以自托管的AI研究助手，能帮你做文献综述、整理信息、梳理研究思路，相当于给你配了个初级助理。
b.主要功能
a.工作空间管理
把服务器文件夹映射进来，文件可以浏览、上传、编辑。
b.RAG对话功能
让你能基于工作空间里的文档跟AI聊，回答问题时会标注出处。
c.论文研读
a.多源搜索
能同时搜arXiv、HuggingFace Daily Papers和Semantic Scholar。
b.智能关键词优化
用自然语言描述需求就行，AI会帮你优化关键词。
c.5人评审小组
可以启动一个5人评审小组，包括主持人、文献专家、质疑者、复现者、记录员，走完6个阶段的论文评审流程。
d.跨学科脑暴
基于论文让多个AI专家角色一起脑暴，生成跨学科的研究方向和创新点。
d.科学技能集成
通过集成SCP协议，内置了206个科学技能，覆盖药物发现、基因组学、蛋白质工程等8个领域，能直接做具体的科学计算任务。
b.mgrep：在代码、文本、PDF、图片等各种文件里找到相关内容
a.项目背景与简介
分享一个能检索万物的命令行工具mgrep。传统grep只能搜文字，遇到这些情况就傻眼了：想找"那个校验登录的函数"，
但忘了函数名，需要搜PDF文档、图片里的内容，只记得大概意思，记不住精确关键词。
mixedbread-ai推出这个mgrep命令行工具，用语义搜索解决这些问题。
你用自然语言描述想找的东西，它能在代码、文本、PDF、图片等各种文件里找到相关内容。
b.核心原理
代码、文本、PDF、图片都用专门的模型编码到同一个向量空间，一条查询全搞定。
c.主要特性
a.命令行原生支持
可以管道、重定向、写脚本，完全符合Unix哲学。
b.支持离线运行
可以用云端API，也可以跑本地模型，数据不出去。
c.智能分块处理
大文档和图片会先切成有意义的片段再建索引，结果更精准。
d.思考与展望
感觉是不是后续Google会出可以出一个Grep全模态的命令行工具。不过Openclaw这种Agent做检索确实非常需要这个工具。
c.Rowboat：具备本地知识图谱与长期记忆的开源AI工作伙伴
a.产品核心机制
Rowboat 是一款创新的开源 AI 工作伙伴，能够从用户的电子邮件、会议记录等数据中构建并维护一个长期、持续更新的本地知识图谱。
与依赖云端黑箱的工具不同，其核心优势在于数据透明与可编辑性。
b.差异化优势
a.数据主权与隐私
所有数据以纯 Markdown 格式存储在本地，用户拥有完全控制权，消除隐私泄露风险。
b.上下文深度与可追溯性
利用动态演进的上下文提供高度个性化辅助，且决策过程可追溯、可修正。
c.应用场景落地
实际协助起草邮件、准备会议议程、生成文档和演示文稿，解决生成式 AI 在专业场景中“失忆”的痛点。
c.核心总结
a.技术趋势
代表 AI Agent 向更可控、可信、私有化方向发展的趋势。
b.解决痛点
解决大模型缺乏持久记忆和深度上下文理解的问题。
c.数据安全
本地化存储方案，满足专业场景对数据隐私的高要求。
d.LibLib：面向人类和Agent的AI视频创作平台LibTV
a.LibLib发布LibTV视频工具
LibLib推出面向人类和Agent的AI视频创作平台LibTV，支持人类操作、Agent操作及二者协作，包含网站与Skills两部分。
b.网站功能
a.创作形式
采用无限画布创作形式，可接入市面主流图像与视频生成模型。
b.节点类型
支持文本、图片、视频、音频、脚本五种节点，类ComfyUI操作逻辑。
c.模型使用
一次性充值即可使用几乎所有图像与视频生成模型，便捷高效。
d.交互体验
节点拖拽后可直接选择并设置，支持自动化批量运行，交互优化良好。
c.Skills功能
a.能力支持
覆盖LibTV全部功能，可通过API Key供Agent调用。
b.使用方式
账号右上角生成API Key，将开源Skills地址提供给OpenClaw、Claude Code、Codex等Agent，即可调用LibTV能力自动生产视频、图片、脚本。
c.应用场景
a.广告片生成
提供项目GitHub地址，Agent可读取信息并生成高级化妆品广告等生活方式类产品广告片。
b.内容自动化
原有AI Agent能力可联动，自动生成脚本并转化为图片、视频、音频；如让OpenClaw收集AI新闻，调用LibTV制作播客或视频。
c.进度查询与项目操作
Agent可查询LibTV自动化生成进度，也能操作微调项目，无需打开网页即可工作。
d.定价策略
年卡最低39折，订阅用户最高赠送150条可灵O3与150条可灵3.0生成额度。
e.体验入口
可访问liblib.tv体验LibTV。
e.gstack：YC总裁Garry开源了公司工程方法论
a.核心看点
a.热度数据
4天1.2万星，GitHub趋势榜第一，Fork数破1400
b.来源背景
YC总裁Garry Tan把他管理YC投后公司的工程方法论开源了
c.核心功能
8个斜杠命令，把Claude Code从"通用助手"变成"专家团队"
d.浏览器自动化
60秒完成QA测试，不用手动点击
b.为什么需要gstack
a.AI编程工具的瓶颈
AI编程工具最大的瓶颈不是代码能力，而是"认知模式"单一。你让同一个模型同时做产品规划、技术评审、代码审查、发布上线、QA测试，就像让一个人既当CEO又当工程师又当测试，结果往往是"四不像"。
b.Garry Tan的观点
Garry Tan在README里写得很直白："Planning is not review. Review is not shipping. Founder taste is not engineering rigor. If you blur all of that together, you usually get a mediocre blend of all four."
规划不是评审，评审不是发布，创始人品味不是工程严谨性。把这些混在一起，通常只会得到一个平庸的混合体。
c.痛点场景
你是不是也遇到过这种情况：让AI帮忙做个功能，它给出的方案既不够深入也不够全面，像是把所有可能性都浅尝辄止地过了一遍，最后哪个都没做好。
d.gstack的解法
gstack的解法很简单：显式切换认知模式。用8个斜杠命令，告诉模型"我现在需要你用什么脑子"：
e.8个斜杠命令
命令 角色 用途
/plan-ceo-review 创始人/CEO 重新定义问题，找到藏在需求里的10分产品
/plan-eng-review 技术负责人 锁定架构、数据流、边界条件、测试矩阵
/review 偏执的资深工程师 找出那些能过CI但会在生产环境出问题的bug
/ship 发布工程师 同步主干、跑测试、推分支、开PR
/browse QA工程师 登录、点击、截图、抓错，60秒完成QA流程
/qa QA负责人 系统级测试，自动识别受影响的页面并验证
/setup-browser-cookies 会话管理 从真实浏览器导入cookies，测试认证页面
/retro 工程经理 团队周报：每人贡献、亮点、改进建议
c.一个功能的五种模式
a.概述
Garry在README里给了一个完整demo，建议每个用AI编程的人都看看这个工作流。假设你要给一个二手交易平台加"卖家上传图片"功能：
b.第一步：plan-ceo-review（创始人模式）
a.普通助手的做法
你说："让卖家上传图片"，普通助手会：加个文件选择器，保存图片，结束。
b.gstack的做法
gstack会先问一个更重要的问题：这个功能到底是干嘛的？"上传图片"不是真正的功能。真正的工作是帮助卖家创建能卖出去的listing。
c.10分版本应该是
从照片自动识别产品、从网上拉取规格和竞品价格、自动生成标题和描述、建议哪张图最适合做封面、检测图片是否模糊、昏暗、低信任度、让体验感觉像高端产品，而不是2007年的死表单。
d.核心思维
这就是Brian Chesky模式：不是实现显而易见的ticket，而是从用户角度重新思考问题，找到那个令人愉悦的版本。这种思维方式，才是创始人和普通工程师的区别。
c.第二步：plan-eng-review（技术负责人模式）
a.概述
产品方向定了，现在需要技术骨架。
b.gstack会输出
架构图（上传→分类→增强→草稿生成的流水线）、同步/异步边界（哪些步骤实时，哪些走后台任务）、失败模式（上传成功但增强失败怎么办？）、重试逻辑、去重机制、持久化策略、状态机、数据流图、测试矩阵。
c.Garry的强调
"当你强迫模型画图时，它会变得更完整。图表会让隐藏的假设暴露出来。"
d.第三步：实现代码
退出规划模式，正常写代码。
e.第四步：review（资深工程师模式）
a.概述
测试都过了？/review还是会问：
b.审查内容
有没有引入N+1查询？两个标签页会不会race condition覆盖封面图选择？失败的上传会不会留下永久孤儿文件？从网上拉数据到草稿生成，有没有prompt注入风险？
c.本质
这不是风格挑刺，而是生产事故预演。
f.第五步：ship（发布机器模式）
a.概述
不想再讨论了，只想落地。
b.执行内容
/ship会：同步main分支、跑测试、解决Greptile评论、推分支、开PR。6个工具调用，结束。
g.第六步：qa（QA负责人模式）
a.执行流程
你：/qa
Claude: 分析分支diff...12个文件变更：3个控制器、2个视图、4个服务、3个测试
受影响的路线：/listings/new, /listings/:id, /api/listings
检测到应用运行在localhost:3000。
b.测试结果
QA报告：3条路线已测试，全部正常。
/listings/new: 上传+增强流程端到端通过
/listings/:id: 详情页渲染正常
/api/listings: 返回200，形状符合预期
无控制台错误。相邻页面无回归。
d.核心技术：浏览器自动化
a.传统MCP方案的问题
a.上下文膨胀
每次调用都带上完整的JSON schema和协议框架，一个简单的"获取页面文本"要多花10倍token
b.连接脆弱
持久WebSocket/stdio连接会掉线，重连麻烦
c.不必要的抽象
Claude Code已经有Bash工具，CLI输出到stdout是最简单的接口
b.gstack的方案
编译型CLI+持久化Chromium守护进程
c.关键数据对比
工具 首次调用 后续调用 每次调用上下文开销
Chrome MCP ~5s ~2-5s ~2000 tokens
Playwright MCP ~3s ~1-3s ~1500 tokens
gstack browse ~3s 100-200ms 0 tokens
在一个20次命令的浏览器会话中，MCP工具要在协议框架上烧掉3-4万tokens，gstack是零。这就是为什么gstack能跑得快、花得少。
d.核心创新：基于ref的元素选择
a.技术原理
gstack的浏览器不用传统的XPath或CSS选择器，而是基于可访问性树的ref系统：page.locator(scope).ariaSnapshot()返回YAML风格的可访问性树；快照解析器给每个元素分配ref（@e1, @e2, ...）；为每个ref构建Playwright Locator；后续命令如click @e3直接查表调用。
b.优势
没有DOM注入，没有脚本，纯Playwright原生API。
e.扩展功能
a.--diff
存储基线快照，下次调用返回统一diff，验证操作是否生效
b.--annotate
在每个ref位置注入临时覆盖层，拍带标签的截图
c.--cursor-interactive
扫描非ARIA的可点击元素（有cursor:pointer的div等）
f.多工作空间隔离
a.概述
每个工作空间都有独立的浏览器实例：
b.数据示例
工作空间 状态文件 端口
/code/project-a /code/project-a/.gstack/browse.json 随机(10000-60000)
/code/project-b /code/project-b/.gstack/browse.json 随机(10000-60000)
c.优势
无端口冲突，无状态共享，完全隔离。这意味着你可以用Conductor同时跑10个Claude Code会话：一个在跑/qa测试staging、一个在做/review审查PR、三个在实现不同功能、五个在处理其他分支。一个人，十个并行agent，每个都有正确的认知模式。这才是AI工程化的正确姿势。
e.Greptile集成：自动化代码审查
a.Greptile简介
Greptile是YC投资的公司，自动审查PR，能抓出race condition、安全问题那些能过CI但生产会出问题的bug。
b.问题
自动审查工具总会有误报。有些是假阳性，有些是你已经修了的。没有分类层，评论堆积起来就会被忽略。
c.gstack的解法
/review和/ship是Greptile感知的。有效问题添加到关键发现，发布前修复；已修复问题自动回复确认；假阳性推回去，你确认后发出解释。
d.学习能力
每个你确认的假阳性会保存到~/.gstack/greptile-history.md，未来运行自动跳过已知模式。/retro还会追踪Greptile的准确率。
e.示例
你：/ship
Claude: [同步main，跑测试，预发布审查...]
Greptile在PR上发现3条评论：
[有效] payment_service.rb:47 — Race condition: 并发扣款可能重复收费。建议DB级咨询锁。
[已修复] user.rb:12 — 缺少email空值检查 → 已在commit abc1234修复。自动回复。
[假阳性] auth.rb:88 — "Token比较应该用常量时间" → 已经用secure_compare了。
正在修复payment_service.rb的race condition...应用咨询锁。提交：fix: address Greptile review
共3条评论。1个真实修复。1个自动确认。1个假阳性推回。额外时间：约30秒。
f.价值
这种自动化分类的能力，让代码审查从负担变成了助力。
f.安装和使用
a.安装（全局）
在Claude Code里粘贴：
Install gstack: run `git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup` then add a "gstack" section to CLAUDE.md that says to use the /browse skill from gstack for all web browsing, never use mcp__claude-in-chrome__* tools, and lists the available skills: /plan-ceo-review, /plan-eng-review, /review, /ship, /browse, /qa, /setup-browser-cookies, /retro. Then ask the user if they also want to add gstack to the current project so teammates get it.
b.安装（项目级）
让团队成员也能用：
Add gstack to this project: run `cp -Rf ~/.claude/skills/gstack .claude/skills/gstack && rm -rf .claude/skills/gstack/.git && cd .claude/skills/gstack && ./setup` then add a "gstack" section to this project's CLAUDE.md...
c.注意事项
项目里会提交真实文件（不是子模块），git clone就能用。二进制文件和node_modules/被gitignore忽略，团队成员只需运行cd .claude/skills/gstack && ./setup一次来构建。
d.依赖
Claude Code、Git、Bun v1.0+
/browse会编译二进制文件——支持macOS和Linux（x64和arm64）。
g.谁适合用gstack
a.Garry的定位
"This is not a prompt pack for beginners. It is an operating system for people who ship."
这不是给初学者的prompt合集，而是给能落地的人的操作系统。
b.适合人群
已经重度使用Claude Code、想要一致、高严谨度的工作流而不是模糊的通用模式、想告诉模型"现在用哪种脑子"：创始人品味、工程严谨、偏执审查、快速执行。
c.总结
说白了，这不是玩具，是工具。
h.使用建议
a.从plan-ceo-review开始
几乎所有功能我都从plan mode开始。描述想建什么，然后用/plan-ceo-review压力测试是不是在做正确的事。
b.产品方向锁定后再切工程
只有产品方向定了，才切换到工程、审查、发布、测试模式。
c.用Conductor跑多个并行会话
gstack在一个会话里很强大，在十个会话里更强大。
d.qa比手动测试快10倍
在功能分支上，直接/qa，它会自动识别你改动的页面并测试。
i.结语
a.核心价值
我为什么对gstack这么兴奋？它解决的不是"AI能不能写代码"，而是"AI能不能用正确的方式思考"。
b.差异化
大多数AI工具在追求"更智能"，而gstack在追求"更合适的认知模式"。规划时像创始人，工程时像技术负责人，审查时像偏执工程师，发布时像发布机器，测试时像QA专家。这是一种不同的构建软件的方式。
c.YC招聘广告
Garry在README最后写了一段招聘广告：
Are you a great software engineer who loves to write 10K LOC/day and land 10 PRs a day like Garry? Come work at YC: ycombinator.com/software. Extremely competitive salary and equity. Now hiring in San Francisco, Dogpatch District. Come join the revolution.
d.总结
革命已经开始了，你，准备好了吗？
j.参考资料
项目地址：github.com/garrytan/gstack
07.常用信息7
a.Zeroboot：Github开源1.1K的毫秒级AI Agent沙箱
a.说明
分享一个Agent 沙箱项目ZeroBoot ，目标是解决在运行 AI 智能体或不受信任代码时，传统隔离环境（如容器、虚拟机）启动慢、资源消耗大的痛点。
b.核心技术
项目利用 写时复制派生 技术与 KVM 虚拟机 相结合，实现了 亚毫秒级（低于1毫秒） 的沙箱启动速度。这与传统容器（通常需要数百毫秒）和虚拟机（秒级）相比，是数量级上的性能飞跃。
c.主要原理
主要原理是预先启动一个包含所需运行时的 KVM 虚拟机，并将其内存和 CPU 状态保存为快照。当需要新沙箱时，通过内存映射（MAP_PRIVATE）以写时复制的方式快速"派生"出一个新的 KVM 虚拟机实例。由于内存页在修改前是共享的，因此创建过程极快。
d.性能表现
P50 延迟低至 0.79 毫秒。每个沙箱仅消耗约 265KB 内存（对比传统方案的数十到数百 MB）。
e.优势与场景
a.强隔离
每个沙箱都是一个真实的、硬件强制的 KVM 虚拟机，提供了比普通进程更强的安全性。
b.高吞吐
可轻松支持每秒数千次的沙箱创建。
c.应用场景
非常适合AI 智能体/多智能体系统的安全、细粒度任务隔离。
b.Sandbox：一个一体化的人工智能代理沙箱环境
a.项目介绍
字节跳动1.3K⭐开源项目:AIO Sandbox分享一个已经收货1.3K⭐的字节开源项目AIO（all in one）Sandbox
一个一体化的人工智能代理沙箱环境。它将浏览器、命令行终端、文件系统、VSCode Server、
Jupyter Notebook 以及 MCP（Model Context Protocol）服务器整合在单一的 Docker 容器中，为AI智能体和开发者提供一个统一、安全的执行环境。
b.核心特性
a.共享文件系统
所有组件共享同一文件系统，解决了传统单一功能沙箱（如独立的浏览器、代码或Shell环境）之间文件共享与功能协同的难题。
b.快速启动与交互
通过一条Docker命令即可快速启动，无需复杂设置。提供Web VNC访问浏览器、VSCode Server、Jupyter、终端等多种交互界面。
c.MCP服务器集成
而且原生集成MCP服务器，提供了用于浏览器自动化、文件操作、命令执行等的高层API，便于AI代理（如OpenAI Assistant, LangChain代理）无缝集成和操作。
d.多语言SDK
并且提供了Python，TypeScript/JavaScript和Go的SDK，方便开发者以编程方式调用沙箱功能。
c.地址
https://github.com/bytedance/sandboxfusion
c.cmux：专为AI Coding时代设计的终端
a.说明
面对同时运行多个 AI Coding Agents 导致的终端混乱（通知混乱、标签页爆炸、上下文丢失），
cmux 提供了基于原生 Swift + libghostty 的高性能解决方案。
核心创新包括垂直标签页侧边栏（显示分支、目录、端口、通知文本）、通知提醒环（快速跳转待处理事项）以及内置可编程浏览器（支持与 Claude Code 交互）。
它被定义为可组合的“原语”而非封闭解决方案，提供完整的 CLI 和 Socket API 支持自动化。
b.核心痛点
传统终端在多 Agent 并行时面临通知信息缺失、标签页管理混乱、上下文切换频繁及性能延迟问题。
c.关键特性
垂直标签页侧边栏一目了然、通知系统与 macOS 深度集成、内置可编程浏览器支持 E2E 测试、基于 GPU 的高性能渲染。
d.设计理念
提供终端、浏览器、工作区等可组合原语，让开发者根据自身工作流自由构建，而非强制固定流程。
d.PageIndex：不用向量数据库也能做RAG
a.说明
大多数 RAG 系统依赖向量数据库进行相似度搜索，但 PageIndex 提出了一种“无向量”思路：像人类翻书一样检索。
它将文档解析为树状目录结构，通过 LLM 逐层导航找到相关内容。索引阶段生成树结构和摘要，查询阶段通过 LLM 选择分支。
这种方法无需嵌入模型，可解释性强，且只需 JSON 文件存储。
b.核心原理
利用文档的层级结构（目录-章节-小节），通过 LLM 逐层导航来定位信息，而非依赖向量相似度。
c.实施步骤
定义节点结构 -> 解析文档为树 -> 自底向上生成摘要 -> 树搜索检索。
d.优劣势分析
优势在于可解释性强、无需向量基础设施、查询成本低；局限是对非结构化文档适应性差，更新需重建树。
e.lark-cli：飞书推出官方cli
a.说明
飞书发布官方命令行工具 lark-cli，这是业内首个为 AI Agent 原生设计的飞书操作接口。
其核心是构建“人机通用”的终端交互协议，覆盖 IM、日历、云文档等 11 大业务领域。
内置 19 个 Agent Skills，支持快捷命令、API 命令和通用调用三层架构。
具备全自动分页、Dry Run 机制及多种输出格式，方便 AI Agent 进行结构化数据调用和自动化办公流处理。
b.核心价值
AI Agent 原生适配，内置 Skills 让主流大模型无需额外学习即可通过指令调用飞书全量业务能力。
c.架构设计
提供语义化快捷命令、与平台端点对应的 API 命令及底层 OAPI 全量覆盖的三层调用架构。
d.安全与效率
采用 OS 原生密钥链存储，内置防注入与输出净化，支持高效的数据流操控（如自动分页）。
08.常用信息8
a.如何用Karpathy的Autoresearch让Skill效果提升26%
a.说明
针对编写 Skill 效果不稳定的问题，利用 Andrej Karpathy 的 Autoresearch 方法可以让 AI 自动优化 Skill。
核心逻辑是“做小改动 -> 测试评分 -> 保留或回退”的循环。关键在于将模糊的评分标准转化为明确的 Yes/No Checklist。
实测落地页文案 Skill 通过率从 56% 提升至 92%。该方法不仅适用于代码，也适用于任何可量化的指标，其产出的 Changelog 记录了有效的优化路径。
b.核心逻辑
通过自动化循环（小改动-测试-反馈-保留/回退），不断逼近最优解，无需人工干预。
c.关键要素
明确的 Checklist（Yes/No 问题）是自动评分和优化的前提。
d.价值产出
除了性能提升，记录有效改动路径的 Changelog 是更具长期价值的战略资产。
b.Tentix：AI原生客服工单系统
a.说明
针对传统客服工单系统仅“电子化记录”而无法提升效率的痛点，Tentix 按 AI 原生平台设计，实现了自动理解、检索和生成回复。
它将历史工单和文档沉淀为统一的向量知识库，使回答随业务积累不断优化。
系统支持飞书等多渠道推送及 Docker 部署，旨在将工单处理从“人工跟进”转变为自动化流程。
b.核心差异
从“电子化记录”转向“AI 自动化处理”，通过 RAG 技术实现自动检索与生成回复。
c.数据价值
持续沉淀历史工单与对话数据，构建专属向量知识库，使回答更贴合业务场景。
d.落地能力
支持多渠道消息推送（如飞书）和模块化接口，开源且试错成本低。
c.OfficeCLI：面向AI智能体的Office套件CLI工具
a.说明
让AI智能体完全掌控OfficeOfficeCLI是全球首个面向AI智能体的Office套件CLI工具，
能够让AI智能体能够通过一行命令完全掌控Word、Excel和PowerPoint文档。
b.其主要优势包括
AI原生，命令行接口（CLI）和结构化JSON输出专为AI交互优化。单一可执行文件，
无需安装Microsoft Office或任何依赖（.NET运行时已内嵌），就能跨平台运行。
文档处理能力覆盖创建、读取、分析和修改，支持Word（段落、样式、表格等）、
Excel（单元格、公式、图表等）和PowerPoint（幻灯片、形状、动画等）的绝大多数元素。
c.核心使用模式：三层架构，工具采用分层设计，从易到难
L1 (读取/语义视图)：
使用 view 命令以高级语义方式查看文档，如大纲( outline )、纯文本( text )、带格式注释的文本( annotated )、
统计信息( stats )和问题检查( issues )。
L2 (DOM/元素操作)：
对结构化文档对象模型进行操作，核心命令包括：
get ：获取元素及其属性。
query ：使用CSS风格选择器查找元素。
set / add / remove / move ：修改、添加、删除、移动元素。
validate ：验证文档格式。
L3 (原始XML)：
当L2无法满足需求时，可直接通过 raw 和 raw-set 命令操作底层OpenXML。
d.港大开源的 Agent 自进化引擎
a.4.2倍收入提升，46%Token节省：港大开源的Agent自进化引擎
a.AI Agent的困境
今天的AI Agent越来越强大。OpenClaw、Claude Code、Cursor、Codex——它们能写代码、做研究、生成文档。但它们有一个致命弱点：从来不学习。
每次任务都从零开始推理。同样的错误重复犯。成功的模式无法复用。一个Agent学到的东西，另一个Agent完全不知道。
更糟糕的是：技能会"腐烂"。工具API更新了，技能描述还停留在旧版本。某个依赖的库改了接口，技能就静默失效。没有人告诉Agent——直到任务失败。
这不是"不够聪明"的问题。这是没有记忆的问题。港大新开源的OpenSpace项目，解决的就是这个被忽视的问题。
b.OpenSpace是什么
a.定义
一个让Agent自我进化的引擎。核心理念可以概括为：Every task makes every agent smarter and more cost-efficient.
每一次任务，让每一个Agent更聪明、更省钱。
b.三大核心功能
a.自进化技能
技能不是静态的.md文件，而是能自我修复、自我优化的"活实体"：
a.AUTO-FIX
技能失效时自动修复。
b.AUTO-IMPROVE
成功模式变成更好的技能版本。
c.AUTO-LEARN
从实际使用中捕获有效工作流。
b.跨Agent共享
一个Agent的改进，成为所有Agent的升级。技能存储在云端社区，支持公开、私有、团队共享。
当一个Agent进化出更好的技能版本，其他Agent可以直接下载使用。
c.成本降低
46%的Token减少。这不是靠"更聪明的模型"，而是靠"不再从零开始"。成功的模式被复用，
失败的模式被记录。相似任务不需要重复推理——直接调用进化好的技能。
c.数据验证：GDPVal基准测试
a.基准介绍
OpenSpace在GDPVal上做了验证。GDPVal是什么？220个真实专业任务，覆盖44种职业。不是玩具问题——是真正产生GDP的工作。
b.任务类型
a.薪酬计算器
从复杂的工会合同构建。
b.报税表准备
从15份散落的PDF文档准备。
c.法律备忘录
起草加州隐私法规的法律备忘录。
d.合规表格
创建合规表格和工程规范。
c.测试设置
OpenSpace选取了其中50个任务，用Qwen 3.5-Plus作为后端模型（与ClawWork基线相同），
测试了两轮：Phase 1（冷启动）：从零开始，技能逐步积累；Phase 2（热重跑）：使用Phase 1积累的全部技能。
d.核心指标
指标 数值
收入提升 4.2× vs ClawWork 基线
价值捕获 72.8%（$11,484 / $15,764）
质量提升 70.8%（vs 基线 40.8%）
Token 节省 45.9%（Phase 2 vs Phase 1）
关键发现：Phase 2用更少的Token，产生了更好的结果。这就是技能进化的力量。
d.分行业数据
a.数据概览
50个任务覆盖6个类别。每个类别都有改进。
b.详细统计
类别 收入变化 Token 变化 关键技能
文档与通信 +3.3pp -56% document-gen-fallback（13 个版本迭代）
合规与表格 +18.5pp -51% PDF 技能链（检查逻辑→布局→验证）
媒体制作 +5.8pp -46% ffmpeg 参数编码、编解码器回退
工程项目 +8.7pp -43% 协调技能（跨任务通用）
电子表格 +7.3pp -37% 公式、合并单元格、验证模式
战略分析 +1.0pp -32% 文档结构、多文件编排
最让人在意的是合规与表格类别：18.5个百分点的提升。这类任务的特点是：格式严格、步骤繁多、容易出错。
进化出的PDF技能链一旦稳定，所有类似任务都能复用。
e.技能分类分析
a.总体概况
Phase 1自动进化了165个技能。关键发现：大多数技能聚焦于工具可靠性和错误恢复，而非任务特定知识。
b.技能分布
用用 数量 来自实际失败
文件格式 I/O 44 32/44
执行恢复 29 28/29
文档生成 26 -
质量保证 23 -
任务编排 17 -
领域工作流 13 -
Web 与研究 11 2/11
这揭示了一个重要洞察：Agent的"智能"不只是领域知识，更是在混乱现实中可靠执行的能力。
沙箱崩溃怎么办？API超时怎么办？文件格式解析失败怎么办？这些不是"聪明"能解决的问题，是经验才能解决的问题。
OpenSpace把这些经验变成了可复用的技能。
f.自进化的三种模式
a.FIX（修复）
技能损坏或过时时，原地修复。同一个技能，新版本。触发条件：工具成功率下降、执行失败、指标监控报警。
b.DERIVED（派生）
从父技能创建增强或特化版本。新技能目录，与父技能共存。触发条件：成功执行后的分析、发现更好的模式。
c.CAPTURED（捕获）
从成功执行中提取新的可复用模式。全新技能，无父技能。触发条件：发现有效的执行模式、任务编排策略。
d.模式总结
三种模式覆盖了进化的全生命周期：修复损坏、优化现有、发现新知。
g.多层监控机制
a.监控层级
进化不是随机的，而是由多层监控触发：技能层（应用率、完成率、回退率）；工具调用层（成功率、延迟、标记问题）；代码执行层（执行状态、错误模式）。
b.触发逻辑
当任何一层指标下降，进化自动触发。而且会级联：单个工具调用失效，会触发所有依赖该工具的技能进化。
这解决了"一个API改了，十几个技能全坏"的问题。
h.实战案例：My Daily Monitor
a.项目概况
零人工代码。60+技能从零进化。完整可用的实时仪表板。这是一个个人行为监控系统：
20+实时面板，监控进程、服务器、新闻、市场、邮件、日程——内置AI Agent。
b.开发过程
阶段 发生的事 技能数
种子 分析开源 WorldMonitor，提取参考模式 6
脚手架 生成项目结构、Vite 配置、TypeScript 设置 +8
构建 创建 20+ 面板、数据服务、API 路由、网格布局 +25
修复 自动修复 TypeScript 错误、API 不匹配等 +12
进化 派生增强模式、合并互补技能 +15
捕获 从成功执行中提取可复用模式 +8
完整的进化历史开放在showcase/.openspace/openspace.db——用任何SQLite浏览器都能查看谱系、diff、质量指标。
i.架构设计
a.核心系统
OpenSpace的核心不是静态技能文件，而是一个完整生命周期管理系统：发现 → 应用 → 监控 → 分析 → 进化。
每个环节都自动化。Agent不需要知道"要不要进化"——系统自己决定。
b.安全机制
a.确认门控
减少误触发。
b.防循环保护
防止进化失控。
c.安全检查
标记危险模式（提示注入、凭证泄露）。
d.验证后替换
进化后的技能验证通过才替换旧版本。
j.快速开始
a.Path A：集成到你的Agent
支持任何使用SKILL.md格式的Agent：Claude Code、Codex、OpenClaw、nanobot等。
a.安装指令
---
git clone https://github.com/HKUDS/OpenSpace.git
cd OpenSpace
pip install -e .
---
b.MCP配置
在Agent的MCP配置中添加OpenSpace：
---
{
"mcpServers": {
"openspace": {
"command": "openspace-mcp",
"toolTimeout": 600,
"env": {
"OPENSPACE_HOST_SKILL_DIRS": "/path/to/your/agent/skills",
"OPENSPACE_WORKSPACE": "/path/to/OpenSpace"
}
}
}
}
---
b.Path B：直接作为AI助手使用
---
# 交互模式
openspace
# 执行任务
openspace --model "anthropic/claude-sonnet-4-5" \
--query "创建一个 Docker 容器监控仪表板"
---
k.云端社区
open-space.cloud是技能共享平台：浏览社区技能、进化谱系；上传/下载进化后的技能；公开、私有、团队共享。
注册获取API Key后，Agent可以直接访问云端技能库。
l.局限性
OpenSpace不是万能的：模型依赖（进化质量受后端模型能力限制）；初期成本（Phase 1的技能积累需要时间）；
生态规模（作为新项目，社区技能库还在成长）。但它解决了一个根本问题：让Agent不再失忆。
m.总结
OpenSpace的价值可以用一句话概括：One agent learns, all agents benefit. 一个Agent学到的，所有Agent都能用。
这不是让模型更聪明——而是让Agent积累经验。46%的Token节省，4.2倍的收入提升，不是来自更强的推理能力，
而是来自不重复犯错、不重复发明轮子。Agent的未来不只是"更聪明"，更是"会学习"。
n.项目资源
a.项目地址
https://github.com/HKUDS/OpenSpace
b.云端社区
https://open-space.cloud
e.Hermes Agent：基于 Andrej Karpathy 提出的 LLM-Wiki 理念
a.Hermes Agent 简介
Hermes Agent 是一款独立的开源工具，不需要安装在 Claude Code（或 Cursor、Windsurf 等）上。
它是一个独立的 AI Agent 系统，由 Nous Research 开发并开源，直接在电脑或 VPS 上安装运行，
支持通过 Telegram、Discord 等软件对话，还能执行终端命令、维护记忆、自动学习技能。
b.具体关于 LLM-Wiki 功能
a.功能定义
这是 Hermes Agent 内置的 Skill（技能），基于 Andrej Karpathy 提出的 LLM-Wiki 理念。
b.生成内容
它会自动帮你生成 Obsidian 格式的 Markdown 知识库（页面 + 交叉链接 + 知识图谱）。
c.独立性
Hermes 自己就能完成爬取、分析、生成笔记等所有工作，不需要额外依赖 Claude Code。
d.使用步骤
第一步：先安装 Hermes Agent（一条命令搞定）。
第二步：输入 hermes update 更新到最新版。
第三步：新开对话，输入 /llm-wiki 你的研究主题即可。
c.Obsidian 的关系
a.文件生成
Hermes 生成的只是一个普通的 Markdown 文件夹（知识库）。
b.可视化
你需要单独安装 Obsidian（免费桌面软件）来打开这个文件夹，才能看到漂亮的知识图谱、双向链接等可视化效果。
c.设置指导
Hermes 本身不会替你安装 Obsidian，它只是在技能里指导你怎么设置 CLI 等。
d.怎么安装 Hermes Agent
a.支持系统
适用于 Linux、macOS、WSL2 等环境。
b.安装脚本
---
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
---
c.后续配置
安装完后运行 hermes setup 配置 LLM 提供商，支持 OpenRouter、OpenAI、Nous Portal、本地 Ollama 等。
3.2 分类2
00.汇总
a.分类1
txtai：一体的全功能AI框架 https://github.com/neuml/txtai
QMD：一个功能强大的本地搜索引擎 https://github.com/tobi/qmd
MemSearch：Markdown优先记忆架构 https://github.com/zilliztech/memsearch
EverMemOS：AI智能体长期记忆操作系统 https://github.com/EverMind-AI/EverMemOS
jina-embeddings-v5：文本嵌入模型创新 https://arxiv.org/abs/2602.15547
b.分类2
Database-Skills：AI编码助手的数据库专项技能 npx skills add database-skills
Trellis：将必需的规范和流程自动注入每次对话，实现一次编写，永久应用 https://github.com/mindfold-ai/Trellis
Memorix 解决所有这些问题。一个 MCP 服务器。七个 Agent。零上下文丢失 https://github.com/AVIDS2/memorix
Agency Swarm：是一个用于构建多智能体应用的框架 https://github.com/VRSEN/agency-swarm
Claude Context：直接“读懂你整个项目”且更便宜 https://github.com/zilliztech/claude-context
c.分类3
AgentSkillOS：一个定位为"智能体技能操作系统"的平台
AgentSquad：一个灵活、轻量级的开源框架，用于协调多个AI智能体以处理复杂对话
OpenNews、OpenTwitter：专门用于解决实时数据接入和处理的难题 https://github.com/6551Team/opentwitter-mcp
mq：一款专为Agent设计的Markdown处理命令行工具 https://github.com/harehare/mq
CLI-Anything：AI负责思考，CLI负责执行 https://github.com/HKUDS/CLI-Anything
d.分类4
谷歌开源A2UI：让Agent能够呈现丰富的界面给用户生成式AI擅长创建文本和代码 https://github.com/google/A2UI
HelloClaw：零基础学习OpenClaw的最强教程 https://github.com/datawhalechina/hello-claw
DenchClaw：基于OpenClaw的本地化AI CRM系统 https://github.com/DenchHQ/DenchClaw
ClawPort：一个为您的 OpenClaw AI 智能体团队设计的开源可视化指挥中心（仪表盘） https://github.com/JohnRiceML/clawport-ui
googleworkspace/cli：谷歌Workspace CLI工具核心优势 https://github.com/googleworkspace/cli
e.分类5
everything-claude-code：一整套围绕Claude Code的"工程化配置工具箱" https://github.com/affaan-m/everything-claude-code
01.常用信息1
a.txtai：一体的全功能AI框架
a.项目概述
一个集语义搜索、大语言模型编排和语言模型工作流于一体的全功能AI框架。核心组件是一个嵌入数据库，融合向量索引（稀疏和稠密）、图网络和关系型数据库，既支持向量搜索，也可作为大语言模型应用的强大知识源。
b.主要功能
a.向量搜索
支持SQL查询、对象存储、主题建模、图分析和多模态索引。
b.嵌入生成
可为文本、文档、音频、图像和视频创建嵌入表示。
c.模型管道
提供由语言模型驱动的多种处理管道，包括运行LLM提示、问答、标签分类、转录、翻译和摘要等。
d.工作流
能将多个管道连接并整合业务逻辑，既可以是简单的微服务，也可以是复杂的多模型工作流。
e.智能体
能智能地连接嵌入数据库、管道、工作流及其他智能体，以自主解决复杂问题。
f.API支持
提供Web和模型上下文协议API，并有JavaScript、Java、Rust和Go的语言绑定。
g.开箱即用
包含默认配置，可快速启动和运行。
h.部署灵活
支持本地运行，也可通过容器编排进行扩展。
c.项目地址
https://github.com/neuml/txtai
b.QMD：一个功能强大的本地搜索引擎
a.简介
QMD 是一个功能强大的本地搜索引擎，专门用于索引和搜索您的个人文档，如笔记、会议记录、知识库等。
它结合了关键词检索 (BM25)、向量语义搜索和LLM智能重排，无需云端连接，完全离线运行。
该项目提供命令行工具和面向AI代理的MCP服务器接口，旨在打造个人化的知识管理和智能检索系统。
b.混合搜索
支持三种搜索模式：
qmd search：快速关键词全文搜索 (BM25)。
qmd vsearch：向量语义搜索。
qmd query：混合搜索（推荐），结合关键词、语义、查询扩展和LLM重排，提供最佳质量。
c.本地化与离线
使用 node-llama-cpp 运行本地的GGUF模型（用于向量嵌入、查询扩展和重排）。
所有数据和索引（存储在 ~/.cache/qmd/index.sqlite ）均在本地处理，保障隐私。
d.智能处理
a.智能分块
使用评分算法将文档分割为约900个token的块，优先在标题、代码块等自然边界处切割，保持语义连贯。
b.上下文管理
qmd context add：可以为文档路径添加描述性上下文，帮助搜索和LLM更好地理解内容。
c.查询扩展
使用微调的LLM自动生成查询变体，提升检索召回率。
d.混合重排
结合RRF（互惠排名融合）算法和LLM重排器，并对不同排名区间的结果进行权重调整，平衡检索精度与语义理解。
e.面向AI代理
提供MCP (Model Context Protocol) 服务器，可轻松集成到Claude Desktop等AI助手。
支持 --json 、 --files 等输出格式，便于AI代理结构化处理搜索结果。
支持HTTP模式，可作为长驻后台服务，避免模型重复加载。
f.便捷管理
支持创建和管理多个文档集合（Collections）。
提供文档获取 ( qmd get )、批量获取 ( qmd multi-get )、索引更新 ( qmd update ) 和状态查看 ( qmd status ) 等实用命令。
c.MemSearch：Markdown优先记忆架构
a.项目概述
MemSearch项目是一个旨在为AI智能体（AI agents）提供持久化记忆能力的工具库，其架构灵感来源于OpenClaw的"markdown-first"（Markdown优先）记忆架构。
b.核心特性与优势
a.轻量集成
只需几行代码即可为AI智能体添加记忆功能。
b.基于Markdown
记忆以Markdown格式存储和读写。这使得记忆内容人类可读、易于用Git进行版本管理，并且实现了零供应商锁定（记忆就是普通的.md文件）。
c.语义搜索
能够对记忆内容进行语义化搜索。
d.智能去重
使用SHA-256内容哈希，确保未更改的内容不会被重复嵌入到向量数据库中，节省资源。
e.实时同步
内置文件监视器，可自动将文件的变更索引到向量数据库，并在文件被删除时移除过时的数据块。
f.即用插件
提供一个开箱即用的Claude Code插件示例，展示如何基于MemSearch为AI智能体构建记忆系统。
g.高兼容性
可以轻松嵌入到任何智能体框架中。
c.项目地址
https://github.com/zilliztech/memsearch
d.EverMemOS：AI智能体长期记忆操作系统
a.项目定位与核心价值
a.定位
专为AI智能体设计的长期记忆操作系统，为跨不同大语言模型（LLM）和平台的智能体提供持久、结构化的记忆能力。
b.核心理念
超越简单的记忆存储，实现"远见"。让AI不仅能记住发生过的事情，更能理解记忆背后的含义，并利用记忆来指导决策。
c.核心优势
高性能：在LoCoMo长上下文记忆基准测试中取得93%的推理准确率，表现优于同类系统。
生产就绪：采用企业级技术栈，集成Milvus、Elasticsearch、MongoDB和Redis。
易于集成：提供简单的REST API，可与任何LLM配合使用。
多模态记忆：支持情节记忆、事实、偏好、关系等多种记忆类型。
智能检索：支持BM25、向量嵌入和智能体搜索等多种检索方式。
b.技术架构与工作原理
a.工作流程
编码：从对话中提取结构化记忆。
整合：将记忆组织成"片段"和"画像"。
检索：在需要时智能检索相关上下文。
b.技术栈
主要基于Python、Docker、FastAPI、MongoDB、Elasticsearch和Milvus构建。
c.项目地址
https://github.com/EverMind-AI/EverMemOS
e.jina-embeddings-v5：文本嵌入模型创新
a.背景与目标
文本嵌入模型是处理语义相似性任务（如检索、聚类）的基础工具。当前通用模型的训练主要依赖对比损失。本研究旨在开发一种更有效的方法，专门用于训练参数更少、体积更小，但性能不妥协的嵌入模型。
b.核心创新
提出一种新型混合训练范式。并非单独使用传统的对比学习或模型蒸馏技术，而是将两者有机结合：在训练中同时利用模型蒸馏（从大模型转移知识）和针对下游任务设计的对比损失函数。这种结合策略对于训练小型模型效果优于任何单一方法。
c.研究成果
基于上述方法训练并发布了两个具体模型：jina-embeddings-v5-text-small和jina-embeddings-v5-text-nano。这两个模型在标准的性能基准测试中，成绩达到或超越了同尺寸级别模型的当前最优水平。
d.模型特点
a.长文本支持
能处理长达32K词元的文本，覆盖多语言。
b.强鲁棒性
生成的嵌入向量在遇到文本截断（输入过长时）或二进制量化（将高精度向量压缩为1比特表示以极大节省存储）时，依然能保持稳定和有效的表征能力。
e.开放与影响
研究团队已开源这些模型的权重，旨在促进社区协作，推动整个嵌入模型领域后续的技术发展。
f.论文地址
https://arxiv.org/abs/2602.15547
02.常用信息2
a.Database-Skills：AI编码助手的数据库专项技能
a.项目概述
一个名为PlanetScale Database-Skills的开源项目，旨在为AI编码助手（如Cursor）提供一套专门的数据库技能插件。
b.核心信息
a.目的
增强AI助手在处理特定数据库任务时的能力，提供最佳实践、故障排查和优化指导。
b.内容
包含针对MySQL、PostgreSQL、Vitess（MySQL分片扩展方案）和Neki（PlanetScale的分片Postgres产品）的专用技能模块。
c.使用方式
可以通过npx skills add命令行工具安装。
可以在Cursor编辑器中直接添加为聊天插件（/add-plugin database-skills）。
d.项目结构
每个技能都是一个独立目录，包含核心指导文件（SKILL.md）和可选的参考资料。项目采用MIT开源许可证，目前有3位主要贡献者，接受社区贡献。
b.Trellis：将必需的规范和流程自动注入每次对话，实现一次编写，永久应用。
a.Trellis解决方案
a.自动注入
将必需的规范和流程自动注入每次对话，实现一次编写，永久应用。
b.自动更新规范库
最佳实践存在于自动更新的规范文件中，使用越多，效果越好。
c.并行会话
同时运行多个代理，每个代理都在独立的工作树中运行。
d.团队同步
跨团队共享规范，一人的最佳实践惠及所有人。
e.会话持久化
工作记录保存在仓库中，AI能记住跨会话的项目上下文。
b.主要应用场景
a.教育您的AI
用Markdown编写规范（如组件准则、文件结构），Trellis将其自动注入每次AI会话，无需重复教导。
b.并行开发
使用 /trellis:parallel 在独立的工作树中生成多个Claude会话，可同时处理多个功能，完成后合并。
c.自定义工作流
定义自定义技能和命令（如 /trellis:before-frontend-dev），为特定任务和上下文一键加载预设的规范、检查更改等。
c.工作原理
a.项目结构
在项目根目录生成 .trellis/ 目录，包含工作流指南、多代理配置、规范库、个人工作空间、任务管理和脚本等。
b.代理系统
通过 .claude/ 目录下的代理定义（如调度、实施、检查、研究）和钩子脚本，实现智能的任务路由、上下文注入和质量控制循环。
c.Agentset：用于构建、评估、部署生产级RAG与智能体应用的开源平台
a.简介
Agentset是用于构建、评估、部署生产级RAG与智能体应用的开源平台。
它是一个一站式、可直接上线的开源RAG加Agent开发部署平台，提供端到端工具链，
包括数据导入、向量索引、评估或基准测试、对话调试面板、部署托管，以及对开发者友好的API。
b.开箱即用RAG
提供数据导入、分块、向量嵌入、检索等功能。
c.模型无关
可自由搭配大模型、向量模型、向量数据库。
d.对话调试面板
带有消息编辑与引用溯源功能，便于调试。
e.生产环境部署
支持预览链接、自定义域名。
f.API与SDK
提供API以及强类型SDK，遵循OpenAPI规范。
g.多租户能力
内置多租户支持。
h.技术栈
基于TypeScript、Next.js、AI SDK、Prisma、Supabase、Trigger.dev构建。
d.Agency Swarm 多智能体编排框架分享
a.概述
Agency Swarm 是一个用于构建多智能体应用的框架。
b.框架基础与扩展
它基于并扩展了 OpenAI Agents SDK，提供专门功能用于创建、编排、管理协作式 AI 智能体集群。
c.设计初衷
该框架延续作者 Arsenii Shatokhin（VRSEN）的初衷：用现实组织结构的思路简化 AI 团队开发，让智能体和用户都更易理解。
d.核心特性
a.自定义角色
可自定义智能体角色：CEO、助理、开发者等，可定制指令、工具、能力。
b.控制提示词
完全控制提示词和指令，实现精准控制每个智能体行为。
c.类型安全工具
基于 Pydantic 自动校验参数，确保类型安全。
d.编排式通信
通过 send_message 通信，支持明确的通信流向。
e.状态持久化
灵活的状态持久化，支持会话历史保存到数据库或文件。
f.多智能体编排
在 OpenAI Agents SDK 基础上增强结构化编排能力。
g.生产可用
注重可靠性与实际部署，适用于生产环境。
e.参考链接
https://github.com/VRSEN/agency-swarm
e.Claude Context 直接“读懂你整个项目”且更便宜
a.项目地址
zilliztech/claude-context
b.核心功能
Claude Context 是一款 MCP 插件，它为 Claude Code 及其他 AI 编程智能体加入语义化代码搜索能力，让 AI 能获取你整个代码库的深度上下文。
c.主要优势
a.全量代码库作为上下文
Claude Context 采用语义搜索，从数百万行代码中精准找到所有相关内容，无需多轮探索查找，直接把结果送入 Claude 的上下文。
b.大型代码库也能低成本使用
无需每次请求都把整个目录加载给 Claude（成本极高），Claude Context 会将代码库高效存入向量数据库，仅在上下文中使用相关代码，帮你控制成本。
03.常用信息3
a.AgentSkillOS：一个定位为"智能体技能操作系统"的平台
a.AgentSkillOS
AgentSkillOS，一个定位为"智能体技能操作系统"的平台。其核心背景是当前公开可用的智能体技能已超过90000个，生态极为丰富。
b.用户面临的核心挑战
a.技能发现难题
如何从海量选项中找到最适合特定任务的技能。
b.技能组合难题
如何将多个技能有效地编排、组合成一个协同工作的完整流水线（或管道）。
c.目标与解决方案
AgentSkillOS的目标正是为了解决这些问题，它旨在为用户提供从技能发现、技能组合到流水线运行的端到端支持，从而简化并赋能复杂智能体的构建过程。
d.核心特点
a.技能搜索与发现
通过一个按能力层级组织的技能树，创造性地发现与任务相关的技能。
b.技能编排
使用有向无环图将多个技能组合编排成单一工作流，自动管理各步骤的执行顺序、依赖关系和数据流。
c.图形界面（人机协同）
内置GUI支持在每一步进行人工干预，使工作流可控、可审计且易于引导。
d.高质量技能池
一个精选的高质量技能集合，基于Claude的实现、GitHub星标和下载量进行筛选。
e.可观测性与调试
通过日志和元数据追踪每一步，从而更快调试并自信地对工作流进行迭代。
f.可扩展技能注册表
通过灵活的注册机制轻松接入新技能，或引入您自己的技能。
b.AgentSquad：一个灵活、轻量级的开源框架，用于协调多个 AI 智能体以处理复杂对话
a.项目介绍
Agent Squad(原名 Multi-Agent Orchestrator) 是亚马逊 AWS 开源的多智能体框架。
它是一个灵活、轻量级的开源框架，用于协调多个 AI 智能体以处理复杂对话。
b.核心功能
a.智能路由
基于上下文和内容，动态将查询路由到最合适的智能体。
b.双语言支持
提供完整的 Python 和 TypeScript 实现。
c.响应灵活
支持流式和非流式响应。
d.上下文管理
在多个智能体间维护和使用对话上下文。
e.可扩展架构
易于集成新的智能体或自定义现有智能体。
f.SupervisorAgent
新增功能，可协调多个专业智能体并行工作，实现团队协作。
c.架构流程
用户输入 → 分类器分析 → 根据智能体特征和历史对话选择智能体 → 智能体处理 → 协调器保存对话并返回响应。
c.OpenNews、OpenTwitter
a.背景与挑战
在开发 AI Agent 时，经常遇到这些问题：X API 接入复杂、新闻数据源过多导致信息 overload、技能部署耗时，导致 agent 无法高效处理实时 crypto 数据。
b.解决方案：6551 Team 开源项目
6551 Team 开源的 OpenNews MCP 和 OpenTwitter MCP 项目，专门用于解决实时数据接入和处理的难题。这不仅仅是简单的数据拉取，更是一套构建 AI 数据基础设施的系统性架构。
c.核心组件介绍
a.OpenNews MCP
集成 crypto 新闻聚合、AI 评级、交易信号、实时更新，支持全网 50+ 源和链上数据。
b.OpenTwitter MCP
支持 Twitter/X 数据流、用户资料查询、推文搜索、关注事件跟踪、KOL 监测。
c.OpenClaw Skills
配套 OpenClaw Skills，通过 REST API 实现 24h 监控、数据分析和 Telegram 触发提醒。
d.部署与集成
a.快速部署
包含快速部署指南，几分钟内即可设置 agent 连接数据源，无需手动配置 API 密钥。
b.自动部署
对于使用 OpenClaw 的开发者，也能将 README 喂入系统，实现自动部署。
c.安装方式
支持通过 npx clawhub install 指令直接安装到 OpenClaw 环境中。
e.资源与总结
GitHub：https://github.com/6551Team/opennews-mcp
https://github.com/6551Team/opentwitter-mcp
如果我们正在开发 crypto AI 应用，或者想系统学习数据 MCP 设计原理，这个项目值得深入研究。
d.mq：一款专为Agent设计的Markdown处理命令行工具
a.mq工具简介
mq是一款专为Agent设计的Markdown处理命令行工具，基于Rust开发，核心理念是让Markdown操作像jq操作JSON一样简便高效，适配LLM以Markdown为主要输入/输出格式的特性，大幅提升文档预处理和LLM工作流效率。
b.主要应用场景
a.LLM工作流
高效处理和操控用于LLM提示词与输出的Markdown内容。
b.LLM输入生成
生成为LLM优化、结构化的Markdown输入内容。
c.文档管理
跨多个文档文件提取、转换和组织内容。
d.内容分析
快速从Markdown文档中提取特定部分或模式。
e.批处理
对多个Markdown文件应用一致的转换操作。
c.核心特性
a.数据操作能力
轻松对Markdown文档进行切片、过滤特定部分，支持内容的映射与转换。
b.友好的开发者体验
提供简单直观的CLI命令行接口，搭配交互式REPL环境，方便快速测试查询。
c.高可扩展性
易于通过自定义函数扩展功能，同时支持外部子命令机制。
d.完善的开发支持
提供VSCode扩展和语言服务器协议（LSP）支持，便于自定义函数的开发工作。
e.专属调试工具
包含实验性调试器mq-dbg，可对查询进行交互式检查和调试。
f.丰富的内置功能
拥有大量内置函数和选择器，可直接用于Markdown内容的过滤与转换。
d.项目地址
https://github.com/harehare/mq
e.CLI-Anything：AI负责思考，CLI负责执行
a.工具介绍
a.背景与愿景
分享一个开源工具CLI-Anything。如今的软件是为人类服务的，未来的用户将是AI智能体。
b.核心理念
AI负责思考，CLI负责执行！让任意软件快速支持OpenClaw、nanobot、Cursor、Claude Code等AI智能体。
b.为什么选择命令行
a.通用接口
CLI 是人类与AI智能体通用的接口。
b.结构化与可组合
文本命令适配大模型格式，可串联实现复杂工作流。
c.轻量与通用
开销极小，跨系统运行，无额外依赖。
d.自描述
通过 --help 自动生成文档，智能体可直接读取。
e.已验证有效
Claude Code 每天通过CLI执行数千个真实工作流。
f.智能体优先设计
结构化JSON输出，免去复杂解析。
g.确定性与可靠
结果稳定，让智能体行为可预测。
c.项目地址
https://github.com/HKUDS/CLI-Anything
04.常用信息4
a.谷歌开源A2UI：让Agent能够呈现丰富的界面给用户生成式AI擅长创建文本和代码
a.google/A2UI项目文件及更新说明
目录/文件 相关更新说明
.gemini Add rizzcharts back again, disable Lit version (#784)
.github Upgrade GitHub Actions for Node 24 compatibility (#303)
agent_sdks Add GitHub workflow to enforce Google OSS license (#799)
docs docs: reorganize files to match nav sections, add ADK + comparison up…
renderers Migrate web core to signals (#795)
samples Add React renderer (#542)
specification Update renderer guide to comprehensively cover Catalog API design and…
tools Normalize copyrights so they all match (#807)
.geminiignore Add gemignore (#578)
.gitignore Delete the generated spec assets in the agent SDK (#773)
CONTRIBUTING.md Add configuration for GCA and draft coding style. (#481)
LICENSE Add license file with Apache 2 for now
README.md docs: fix updatable spelling in README intro (#767)
mkdocs.yaml docs: reorganize files to match nav sections, add ADK + comparison up…
requirements-docs.txt docs(a2ui): Update documentation to align with v0.9 specification (#622)
b.A2UI项目基础介绍
A2UI全称为Agent-to-User Interface，是谷歌的开源项目，拥有为表示可更新的代理生成式UI优化的格式和一套初始渲染器，能让智能体生成或填充丰富的用户界面，目前处于v0.8早期公开预览阶段，规范和实现具备功能性但仍在持续演进。
c.A2UI核心解决的问题
生成式AI擅长创建文本和代码，但智能体在向用户呈现丰富的交互界面时易遇到困难，尤其是智能体为远程部署或运行在信任边界之间的场景，A2UI则解决了这一痛点。
d.A2UI的核心实现逻辑
智能体发送描述UI意图的声明性JSON格式，客户端应用程序再使用自身的原生组件库（Flutter、Angular、Lit等）对该格式进行渲染，让代理生成的UI兼具数据的安全性和代码的表现力。
e.A2UI的高层设计理念
a.安全优先
A2UI是声明性数据格式而非可执行代码，客户端应用维护经预批准的可信UI组件目录，智能体仅能请求渲染该目录内的组件，规避了运行大语言模型生成的任意代码带来的安全风险。
b.适配大语言模型且支持增量更新
UI以带ID引用的扁平组件列表形式呈现，便于大语言模型增量生成，支持渐进式渲染和响应式用户体验，智能体可根据对话中用户的新请求对UI进行高效的增量修改。
c.与框架无关且具备可移植性
分离UI结构与实现，智能体发送组件树及其关联数据模型的描述，客户端应用将这些抽象描述映射为原生组件，同一份A2UI JSON负载可在基于不同框架的多个客户端上渲染。
d.灵活性
采用开放注册模式，开发者可将服务端类型映射到自定义客户端实现，通过注册“智能包装器”能将现有任意UI组件接入A2UI的数据绑定和事件系统，开发者可在自定义组件逻辑中落实安全策略，掌控安全权限。
f.A2UI的典型使用场景
a.动态数据收集
智能体可根据对话的具体上下文，生成定制化的表单（日期选择器、滑块、输入框等），例如为特殊预订场景生成专属表单。
b.远程子智能体协作
编排智能体将任务委托给远程的专业智能体（如旅游预订智能体），专业智能体返回UI负载并在主聊天窗口中渲染展示。
c.自适应工作流
企业级智能体可根据用户的查询，实时生成审批仪表板或数据可视化界面。
g.A2UI的整体架构流程
a.生成
智能体（基于Gemini或其他大语言模型）生成或使用预先生成的A2UI Response，即描述UI组件组成及其属性的JSON负载。
b.传输
该JSON负载消息通过A2A、AG UI等方式发送至客户端应用。
c.解析
客户端的A2UI渲染器对接收到的JSON数据进行解析处理。
d.渲染
渲染器将抽象的UI组件（如type: 'text-field'）映射为客户端代码库中的具体实现。
h.A2UI的相关依赖
a.传输协议
兼容A2A协议和AG UI。
b.大语言模型
可由任何能生成JSON输出的模型生成相关UI描述格式。
c.宿主框架
要求基于受支持的框架（目前为Web、Flutter）构建宿主应用程序。
i.A2UI的快速上手方法
a.前置条件
需安装Node.js（用于Web客户端）、Python（用于智能体示例），且拥有有效的Gemini API密钥。
b.运行餐厅查找器演示的步骤
a.克隆仓库
---
git clone https://github.com/google/A2UI.git
cd A2UI
---
b.设置API密钥
---
export GEMINI_API_KEY="your_gemini_api_key"
---
c.运行智能体（后端）
---
cd samples/agent/adk/restaurant_finder
uv run .
---
d.运行客户端（前端）
---
# 安装并构建Markdown渲染器
cd renderers/markdown/markdown-it
npm install
npm run build
# 安装并构建Web Core库
cd ../../web_core
npm install
npm run build
# 安装并构建Lit渲染器
cd ../lit
npm install
npm run build
# 安装并运行shell客户端
cd ../../samples/client/lit/shell
npm install
npm run dev
---
c.其他开发框架相关参考
Flutter开发者可了解基于A2UI构建的GenUI SDK，同时CopilotKit提供了公开的A2UI小部件构建器可供试用。
j.A2UI的项目发展路线图
项目团队希望与社区协作完成以下工作：推进规范稳定化，向v1.0规范迈进；新增更多渲染器，官方支持React、Jetpack Compose、iOS（SwiftUI）等框架；增加更多传输方式，支持REST等协议；适配更多智能体框架，如Genkit、LangGraph等。
k.A2UI的贡献说明
A2UI采用Apache 2.0许可证授权，项目方认为UI的未来是智能体化的，欢迎社区参与共建，具体的贡献方式可参考项目中的CONTRIBUTING.md文件。
b.HelloClaw：零基础学习OpenClaw的最强教程
a.项目定位
Hello Claw是面向零基础用户的OpenClaw完整学习项目，可帮助用户从零掌握OpenClaw命令行AI助理系统，还能深入了解AI Agent的底层原理。
b.核心模块
a.领养Claw（使用篇）
帮助用户快速上手配置和使用OpenClaw，将其打造成高效的AI命令行助手，完成各类实际使用操作。
b.构建Claw（开发篇）
指导用户从零实现一个简化版AI Agent，深入理解OpenClaw的底层工作原理和实现逻辑。
c.适用人群
想要拥有AI命令行助手的开发者、希望通过Telegram/飞书远程操控AI的效率达人、对AI Agent和技能系统感兴趣的技术爱好者。
d.学习建议
零基础用户从“领养Claw”使用篇开始逐步学习，开发者可直接进入“构建Claw”开发篇理解底层实现原理。
e.核心总结
a.项目价值
为OpenClaw学习者提供清晰完整的学习路径，兼顾使用实操与底层开发原理学习，适配不同基础用户需求。
b.核心结构
分为使用和开发两大核心模块，形成从上手使用到自主构建的完整学习闭环。
c.人群适配
针对零基础用户和开发者分别提供不同的学习入口，满足不同用户的学习需求和目标。
c.DenchClaw：基于OpenClaw的本地化AI CRM系统
a.项目定位
DenchClaw是基于OpenClaw平台构建的本地化运行AI CRM客户关系管理系统，为个人或小团队提供开箱即用、注重隐私的客户管理工具，并非企业级套件。
b.核心亮点
a.极简部署
仅需通过npx denchclaw一行命令即可启动系统，自带Web用户界面，大幅降低使用门槛。
b.功能全面
集成联系人管理、销售管道、AI自动化外展等CRM核心功能模块，满足客户管理核心需求。
c.本地安全
所有数据和处理均在本地运行，不与云端服务器同步，有效保护业务数据和用户隐私。
d.环境隔离
基于OpenClaw的Profile配置文件机制实现环境隔离，与用户原有主AI Agent互不干扰，可独立运行。
e.开源友好
采用TypeScript全栈开发，以MIT宽松协议开源，方便开发者查看、使用和进行二次开发。
c.生态意义
DenchClaw体现了AI Agent平台的生态效应，证明在开放的OpenClaw平台之上，社区能够自主开发出满足各类垂直场景需求的工具，CRM只是该趋势的开端。
d.核心总结
a.产品定位
聚焦个人和小团队的轻量级AI CRM工具，以本地化、易部署为核心特点，区别于企业级CRM套件。
b.核心优势
兼具部署便捷、功能全面、数据安全、环境隔离的特点，同时开源属性支持二次开发。
c.生态价值
作为OpenClaw平台的垂直场景应用，展现了AI Agent平台的生态拓展能力，为社区开发垂直工具提供了范例。
d.ClawPort：一个为您的 OpenClaw AI 智能体团队设计的开源可视化指挥中心（仪表盘）
a.多AI智能体管理的现有痛点
使用OpenClaw搭建AI智能体团队时，智能体数量增多会导致状态、任务、工具调用、token消耗等信息分散，
需通过翻日志、查终端等方式查看，效率低下。现有可视化工具功能零散、配置繁琐，使用体验不佳。
b.ClawPort项目定位
ClawPort是针对OpenClaw智能体团队的开源可视化指挥中心，可集中管理分散的智能体状态、任务进度、聊天记录与成本数据。
c.ClawPort核心优势与功能
a.自动发现与低门槛接入
连接本地OpenClaw网关后可自动发现工作区内智能体，无需手写复杂配置，采用即插即用路线，npm全局安装后可快速启动。
b.团队结构可视化
展示智能体团队组织架构图，清晰呈现各智能体职责与协作关系。
c.信息整合展示
整合智能体对话内容、流式聊天过程、实时日志流、任务看板、定时任务状态、
记忆浏览器、token使用量与成本追踪，将终端、日志、看板、报表融合为一个界面。
d.支持管理操作
任务看板支持拖拽分配，可查看定时任务实时状态，成本面板展示每日花费图表、趋势与异常检测。
e.完整交互体验
支持流式文本聊天、图片附件识别、语音消息波形播放，可直接参与智能体协作。
d.适用人群与推荐理由
适合进行多智能体协作、觉得智能体增多后管理困难的用户。限制多智能体协作效率的往往不是智能体能力，
而是缺乏清晰的总览管理界面，ClawPort可有效解决该问题。
e.googleworkspace/cli：谷歌Workspace CLI工具核心优势
a.核心优势
Codepilot助理模式可自动同步日程至谷歌日历，仅需将预约时间截图发送至飞书，由Claude Code/CodePilot完成同步，无需额外操作，流程高效便捷。
b.避坑指南
a.加密问题
macOS系统下Keychain集成存在bug，会触发"Decryption failed"错误；0.9.1版本存在该问题，
0.11.1版本（PR #359）已修复；解决方案为设置环境变量GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file。
b.命令格式
命令结构为gws <service> <resource> <method>；示例：gws calendar calendarList list（非calendar list）、
gws calendar events insert（非calendar create）；可通过gws calendar --help查看所有可用资源和方法。
c.OAuth配置
测试模式下部分scope不可用（如cloud-identity.devices）；仅请求必要权限，
Calendar仅需googleapis.com/auth/calendar、googleapis.com/auth/calendar.events；需将自身添加为测试用户才能完成授权。
d.最佳实践
将环境变量永久设置到~/.zshrc；使用--dry-run预览请求；时区采用Asia/Hong_Kong或+08:00格式；
重复事件通过recurrence字段设置（如RRULE:FREQ=WEEKLY;BYDAY=TU,TH）。
c.工具安装指引
可将相关信息提供给Claude Code或CodePilot，由其协助安装，工具地址为github.com/googleworkspace/cli。
05.常用信息5
a.everything-claude-code：一整套围绕Claude Code的"工程化配置工具箱"
a.项目介绍
最近在GitHub挖到一个挺有意思的项目：everything-claude-code。
它不是简单的提示词合集，而是一整套围绕Claude Code的"工程化配置工具箱"。
把Agents、Skills、Hooks、Rules、快捷命令，甚至MCP能力全部打包好了。
你可以理解为：别人已经帮你把Claude调教成一个完整的AI开发团队，你直接接手用就行。
b.多角色协同
很多人其实一直没用对Claude Code。
大多数人的用法还停留在"AI写代码"阶段：写个函数、改个bug、补几行逻辑。
但这个项目给出的思路完全不同——它把Claude拆成多个角色来协同工作。
比如先由Planner Agent负责架构规划，再交给开发Agent实现，提交前由Code Reviewer Agent自动审查，
最后还有专门的Testing / Safety Agent兜底质量。这一套下来，本质上已经不是"一个AI在写代码"，而是"一个AI团队在开发软件"。
c.解决上下文失控
更关键的是，它解决了AI编程中一个被严重低估的问题：上下文失控。
很多人用AI写项目，前面还挺顺，越写越乱，到后面逻辑开始崩塌。
原因不是模型不够强，而是没有工程约束。everything-claude-code的做法是用Rules + Skills + TDD流程，
把AI强行拉回软件工程轨道，严格按照RED → GREEN → REFACTOR → VERIFY的节奏推进。换句话说，不是让AI想怎么写就怎么写，而是让它必须"按流程写"。
d.MCP接入能力
还有一个很亮眼的点是MCP的接入。通过GitHub MCP、Supabase MCP等工具，Claude不再只是写代码，
而是可以直接参与真实环境操作：改仓库、跑流程、处理数据、甚至联动部署。
原本需要在IDE、终端、数据库之间来回切换的事情，现在可以被AI一次性串起来完成。
这其实是一个非常重要的转变：AI不再只是工具，而开始成为"执行系统"的一部分。
e.总结
Claude Code真正的威力，不在于它能写多少代码，而在于它能不能组织起一套完整的软件开发流程。
如果你还在把AI当成"高级自动补全"，那你可能只用到了它30%的能力。
真正的差距，从"让AI写代码"升级到"让AI按工程流程协同开发"，才刚刚开始。
3.3 分类3
00.汇总
a.分类1
OpenFang：7×24小时运行的AI智能体 https://github.com/RightNow-AI/openfang
MCP vs Agent Skills：别再二选一了
PM-Skills：基于亚马逊产品管理经验的Skill分享 https://github.com/deanpeters/Product-Manager-Skills
Prompt Engineering 的隐喻危机：Arena Allocator 心智模型
从 OpenSpec 到 DevMind：给 AI 补了个脑子 https://github.com/lich0821/DevMind
b.分类2
mcp-use: Agent MCP服务的全栈开发框架 https://github.com/mcp-use/mcp-use
Agent Deck: Agent的任务管理器 + 指挥中心 https://github.com/asheshgoplani/agent-deck
LightClaw: 真正轻量化的 AI 助手 https://github.com/zofrasca/lightclaw
OpenClaw 差生文具多: 你可能不需要 4 个 Workspace
OpenSandbox: 阿里开源的AI 基础设施-沙箱平台 https://github.com/alibaba/OpenSandbox
c.分类3
Claude Code 自动记忆上线 https://code.claude.com/docs/en/memory#auto-memory
OpenClaw记忆外挂: Tokens 消耗降低 72%， 永不失忆 https://memos-dashboard.openmem.net/cn/apikeys/
emdash：同时跑多个AI编程 Agent，每个都在独立的 Git Worktree 里 brew install --cask emdash
GitNexus：一个零服务器的代码智能引擎，不需要任何后端服务 https://github.com/abhigyanpatwari/GitNexus
Hermes Agent：终端型自治的Agent框架 https://github.com/NousResearch/hermes-agent
d.分类4
AgentFS : AI Agent 专用的文件系统 https://github.com/tursodatabase/agentfs
Datus：数据工程智能代理，其核心目标为你的数据系统构建可进化的上下文环境 https://github.com/Datus-ai/Datus-agent
CDP MCP：让AI自动打开浏览器完成设计走查和交互测试 https://github.com/ChromeDevTools/chrome-devtools-mcp
Mirix：一款具备高级记忆能力的多智能体个人助手 https://github.com/Mirix-AI/MIRIX
ChatLab: 将你的群聊转化成可洞察的知识 https://github.com/hellodigua/ChatLab
01.常用信息1
a.OpenFang：7×24小时运行的AI智能体
a.产品定位
OpenFang 是一款开源智能体操作系统——不是聊天机器人框架，不是大模型的 Python 封装，也不是"多智能体编排工具"。它是专为自治智能体打造的完整操作系统，采用 Rust 从零构建。
b.核心能力
传统智能体框架需要你输入指令才能运行。而 OpenFang 运行为你工作的自治智能体——可定时执行、7×24小时运行，构建知识图谱、监控目标、挖掘线索、管理社交媒体，并在控制面板中向你汇报结果。
c.部署优势
整个系统编译后仅为一个约 32MB 的二进制文件。一次安装、一条命令，你的智能体即可上线运行。
d.核心总结
a.版本定位
OpenFang v0.1.0 是2026年2月首次公开发版，功能完整但仍不稳定，生产需锁定 commit，小版本可能不兼容。
b.产品本质
Rust 从零开发的开源智能体操作系统，区别于普通框架、LLM 封装、多智能体编排器。
c.核心能力
支持7×24自治运行智能体，自动完成知识图谱、监控、线索挖掘、社媒管理等任务并可视化汇报。
d.部署优势
单二进制文件约 32MB，轻量、一键部署。
b.MCP vs Agent Skills：别再二选一了
a.问题背景
你有没有这种体验：AI 写代码很快，但一碰到专业工具和基础设施就开始"翻车"——语法旧、参数错、调用方式不对，调试半天像在原地打转。其实问题往往不在模型"不会写"，而在你给它的"连接方式"不对。
b.核心观点
最近两种方案被讨论最多：MCP（Model Context Protocol）和 Agent Skills。很多人问：哪个更好？说白了，这俩不是同一类东西，根本不该放在一个维度上比。
c.MCP的特点
a.定位
MCP 更像标准化 API 网关。它的核心是：固定输入输出结构，让 Agent 以确定性的方式发起调用，并拿到确定性的响应。
b.适用场景
它最适合的场景是"基础设施层"的直接调用，比如：数据库/向量库操作、检索服务、模型推理、内部工具链接口等。
c.优点
可预测、可校验、好调试，出问题更容易定位在"参数/权限/接口"而不是"模型发挥"。但 MCP 不会教 Agent 如何完成一件复杂事，它只是给了一个可靠的"按钮"。
d.Agent Skills的特点
a.定位
Skill 更像一份"行为说明书"：用自然语言描述"怎么做"，让 Agent 自己决定何时使用、用哪个、如何执行。
b.适用场景
它更适合流程型任务：比如搭一个 RAG（检索增强生成）应用、做端到端项目蓝图、把多个步骤串成稳定流程。
c.价值
Skills 的价值在于把最佳实践写进去，减少 Agent 乱试、乱猜，尤其是在工具使用习惯、项目结构、常见坑位这类"经验密集型"内容上。但因为执行过程中仍依赖模型判断，Skills 的确定性通常不如 MCP。
e.工程结论
a.分层策略
底层用 MCP 管"确定性调用"，把基础设施变成稳定接口；上层用 Skills 管"行为与流程"，把最佳实践变成可复用的做事套路。
b.职责分工
MCP 负责"能稳定做到"；Skills 负责"按正确方式做到"。
c.实施建议
如果你正在搭智能体系统，建议先把"必须稳定"的部分抽成 MCP，再把"需要经验"的流程沉淀为 Skills。这样系统会明显更稳，也更容易扩展。
c.PM-Skills：基于亚马逊产品管理经验的Skill分享
a.项目简介
一个名为 Product-Manager-Skills 的开源技能库，其核心目标是将成熟的产品管理方法论框架化、结构化，以便AI代理（如Claude、ChatGPT等）能够理解并辅助执行专业的产品管理工作。
b.核心价值
a.提升效率与质量
用户无需每次从头解释流程，AI基于内置的技能框架，可以直接产出结构正确、考虑周全的交付物（如PRD、用户故事），并提出更专业的问题。
b.确保一致性
标准化框架减少了AI输出的随机性，确保团队输出符合专业规范。
c.赋能战略思考
将PM从重复性文档工作中解放，更专注于策略和决策。
c.核心架构（三层技能模型）
a.组件技能（19个）
基础构建块。提供具体交付物的模板和示例，如撰写用户故事、创建问题陈述、进行PESTEL分析等。
b.交互式技能（18个）
智能引导器。通过多轮对话（提问-回答-建议）帮助用户做出决策，例如根据产品阶段推荐优先级框架、指导如何进行客户访谈、建议验证实验类型等。
c.工作流技能（5个）
端到端流程。协调多个组件和交互技能，完成完整的产品管理流程，如进行完整的产品战略会议、执行发现周期、制定路线图。
d.关键特性
a.实战检验
框架来源可靠，基于Geoffrey Moore、Jeff Patton、亚马逊工作法等经典方法论及作者多年的咨询经验。
b.即用性强
提供42个开箱即用的技能文件，并有详细的分类目录和实际用例指引。
c.工具链支持
包含一系列脚本工具，帮助用户搜索、创建、测试、打包技能，极大降低了使用和扩展门槛。
d.多平台兼容
详细说明了如何在Claude系列、ChatGPT、Codex、Cowork等主流AI平台上使用这些技能。
e.结构清晰
每个技能文件都遵循统一模板（目的、核心概念、应用步骤、示例、常见陷阱），便于AI理解和人类查阅。
e.总结
该项目是一个旨在系统化提升"AI+产品管理"效能的工具箱。它并非简单的提示词集合，而是一个经过精心设计的、可执行的"知识引擎"，让AI能够真正像经验丰富的产品经理一样思考和协助工作。万物皆可Skill。
d.Prompt Engineering 的隐喻危机：Arena Allocator 心智模型
a.问题提出
"Prompt Engineering" 这个词害了整个行业。它让人觉得，和 LLM 打交道的核心能力是"写出好的文字"。措辞精准、格式漂亮、Few-shot 示例到位。于是所有人都在研究怎么写更好的 system prompt，怎么措辞让模型"听话"，怎么在一段文字里塞入更多指令。这就像一个操作系统工程师说："我的核心工作是写出漂亮的注释。"不。你的核心工作是内存管理。
b.Arena Allocator 基础概念
a.核心机制
Rust 的 Arena Allocator（也叫 bump allocator）是内存管理的极简范式：预留一大块连续内存，每次分配时指针往前推，永不回退，所有分配都在这块内存中连续排列，需要释放时整块一起丢，不单独回收。
b.核心特性
Append-only：新分配的内存总在前一次的后面，指针只会向前。
连续内存块：所有数据在一块物理连续的区域内，没有碎片。
空间局部性：时间上相近的分配，在内存中物理相邻，对 CPU cache 极其友好。
按需分配：不预分配所有可能用到的结构，用到时再 bump。
批量释放而非逐个回收：你不能 free 单个对象——要么全留着，要么整块 reset。
c.Context Window 就是 Arena
a.基本类比
把 LLM 的上下文窗口想象成一块预先分配好的连续内存，128K Token Arena。System Prompt、Turn 1 到 Turn N 依次排列，指针只会向前 bump。
b.三条铁律
铁律一：它有固定上限。128K token 就是 128K，不可能变成 256K。和物理内存一样，它是你最稀缺的资源。
铁律二：前缀改变的代价是灾难性的。KV Cache 的匹配规则是从第一个 token 逐一比对——第一个不同的 token 之后，后面全部 cache miss。
铁律三：注意力不均匀。LLM 对开头和末尾的 token 注意力最强，中间会衰减。
d.五条 Arena 原则的映射
a.原则1：Append-Only AMAP
对上下文来说，这意味着：在末尾追加消息，打 tag、读 status，但不能在中间插入新消息、重排消息顺序、修改 system prompt、删除消息后让后续消息"前移"。
滑动窗口 + 动态组装上下文的架构会走进死胡同，因为滑动窗口要求每轮上下文内容不同，而 KV Cache 要求连续调用的前缀相同，这两个要求在数学上不可调和。
b.原则2：Dynamic Loading Skills（Demand Paging）
按需加载：System Prompt 放一行摘要（~50 tokens/skill），首次使用工具时完整指南（~2K tokens）附着在 tool_result 上，后续使用时关键提醒（~100 tokens）。
判断标准：如果一段信息放进 system prompt 后，有 >30% 的 session 不会用到它，就不该预装。
c.原则3：Spatial Locality（空间局部性）
相关信息应该在 token 序列中物理相邻，而不是散落在上下文各处。技能指南作为 tool_result 的一部分追加到末尾，和它指导的那次工具调用物理相邻。
复述模式：Agent 读取 todo.md → 工作状态作为 tool_result 出现在末尾 → LLM 在做决策时直接"看到"当前进度。
d.原则4：Reasoning in Goldilocks Zone
太空（20% usage）：可能预装了太多无关信息，Agent 在噪声中迷失方向。
太满（90%+ usage）：Pruning 频繁触发，丢失关键历史，Agent 变成金鱼。
Goldilocks Zone（40-70% usage）：上下文只包含当前决策需要的信息，有足够空间给接下来的工具调用，Pruning 不触发或只做最轻量的 Soft Trim，信噪比最优。
两层压缩：Layer A 是 Agent 主动压缩，Layer B 是系统自动 Pruning（安全网）。
e.原则5：批量释放而非逐个回收
当你必须"释放内存"时，单位不是单条消息，而是连续区间：Agent squash 是 tag 到 summary 的区间替换，系统 Pruning 是连续区间操作，不产生碎片。
e.Pruning 和 RAG 的定位
a.核心观点
"Pruning and RAG are tricks, not principles." Pruning 是布局失败后的止损操作，RAG 是信息被 prune 后的恢复。先把布局做对，补救手段自然用得少。
b.操作系统类比
在内存中直接访问 → 1 纳秒（L1 cache hit）；从磁盘 page in → 10 毫秒。如果你的系统频繁 page fault，说明你的内存管理有问题；如果你的系统频繁 memory_search，说明你的上下文布局有问题。
f.完整心智模型
a.架构图示
Context Window = Arena（128K token 连续内存块）。System Prompt 是不可变前缀（~4K tokens），对话历史是 Append-only bump，旁路存储包括 Event Log、memory_search、文件系统。
b.核心观点
你的工作不是"写好 system prompt"，而是管理这块 arena。布局决定了 cache 命中率，加载策略决定了空间利用率，局部性决定了注意力效率，压缩策略决定了信息保持率。这些不是语言学问题，它们是内存管理问题。
e.从 OpenSpec 到 DevMind：给 AI 补了个脑子
a.问题背景
这几年，AI 编程工具最大的优点是快，最大的缺点是转头就忘。很多 AI 工具不是不会写，而是没有持续工作的脑子：没有连续记忆、没有模式边界、没有中断恢复、没有对"之前已经否掉的东西"的敬畏。
b.DevMind 简介
a.定位
DevMind 是一个与 Claude Code 深度整合的开发者工作流框架。它通过文件 + Hook + Slash 命令，在本地维护一套项目状态文件，让 AI 每次新会话都能加载上下文、感知当前任务阶段，并在越界时主动暂停。
b.核心价值
给 AI 补上工作记忆，让它真正做到记得住、分得清、停得下。真正让项目翻车的，往往不是 AI 不够聪明，而是它缺乏这些能力。
c.存量项目支持
DevMind 不只是面向新项目，它还支持存量项目接入。devmind migrate 命令和 /dm:migrate Slash 命令，专门就是为了让已有项目能平滑接入，而不是逼你推倒重来。
d.从 OpenSpec 到 DevMind
OpenSpec 代表的是 Spec 驱动的思路——先把规范、约束、方案写清楚，再让 AI 按约束做事。DevMind 往前走了一步：它不只管 Spec，它开始管状态、记忆和执行过程。
DevMind 不是和 OpenSpec 对着干，而更像是：把 OpenSpec 里那套"先想清楚再动手"的理念保留下来，再补上 AI 长期协作最缺的模式、记忆、检查点。OpenSpec 更像是给 AI 一张施工图；DevMind 则是在施工图之外，再给它配上值班日志、工地围栏和刹车系统。
e.核心机制
a.5种模式
auto：一句话需求，全流程自动执行
explore：只读分析，禁止写文件
plan：制定方案，不动业务代码
build：按计划执行，只能改计划内文件
edit：小范围修改，跨文件需确认
这个设计的重点是让 AI 在不同阶段只做该做的事。
b.5层状态管理
Mode、Memory、Flow、Session、Collaboration。
最有用的三层：
Memory 会把跨会话记忆分成 decisions、patterns、graveyard，技术决策、经验规律、以及已经否掉的废案不会再混成一锅粥。
Flow 负责在越界/不确定/危险操作时自动暂停，真正靠谱的自动化不是一路狂奔，而是该停的时候知道刹车。
Session 维护任务检查点链，支持中断后继续，现实里的开发本来就不是一次性通关。
f.如何开始
a.安装
npm install -g @lich0821/devmind
b.初始化
在项目根目录执行：devmind init
如果你是新项目，这一步会帮你生成 .devmind/、.claude/hooks/、.claude/commands/dm/ 等状态与命令文件。
c.迁移
devmind migrate 或 /dm:migrate，这两个就是给存量项目准备的。
g.总结
如果你之前已经习惯了 OpenSpec 这类 Spec 驱动思路，那 DevMind 很可能就是它的下一步：不只是把规范写下来，而是把规范、状态、记忆、执行，全都接成一套完整的 AI 协作链路。如果你手里已经有一堆存量项目，那也不用怕。DevMind 专门给了迁移路径，不是让你重做，而是让你接着做，但做得更稳。
02.常用信息2
a.mcp-use: Agent MCP服务的全栈开发框架
a.说明
mcp-use 是一个全栈、跨语言（TS/Python）、生产级的 MCP 开发框架，用于快速构建符合 Model Context Protocol 标准的服务端与应用。
b.核心价值
一次编写，可在 ChatGPT、Claude 等多平台运行。同时支持 MCP 服务端、MCP 应用（带交互 Widget）、AI Agent、MCP 客户端。内置调试器 Inspector + 云端一键部署，开箱即用。
c.适用人群
AI 应用开发者、Agent 开发者、想给大模型扩展工具能力的开发者。
d.技术亮点
TS + Python 双语言 SDK、React 组件式可视化 Widget、本地调试 + 云端部署一体化、完整支持 MCP 协议与 AI Agent 编排。
e.项目地址
https://github.com/mcp-use/mcp-use
b.Agent Deck: Agent的任务管理器 + 指挥中心
a.说明
Agent Deck 是一个面向 AI 编程智能体的终端会话管理工具，基于 TUI 界面 + tmux，用来统一管理、监控、切换和编排 Claude、Gemini、OpenCode 等多个 AI 编码助手。
b.核心价值
多 AI 会话一站式管理，告别多窗口混乱；提供 AI 专属增强：会话分叉、上下文继承、MCP/技能管理；支持 Docker 沙箱隔离与 Conductor 自动编排；可通过 Telegram / Slack 远程监控与控制；极轻量、终端原生、可脚本化。
c.总结
这是 AI 编程助手的终端版"任务管理器 + 指挥中心"。
d.项目地址
asheshgoplani/agent-deck
c.LightClaw: 真正轻量化的 AI 助手
a.说明
LightClaw 是一个 Rust 编写、单文件、超轻量、本地优先、可跨设备运行的 AI 智能体助手，兼容 OpenClaw 生态。
b.核心亮点
a.极致轻量化
单二进制、体积约15MB、启动秒开、内存占用极低。
b.全平台通吃
Linux / macOS / 树莓派 / ARM 设备都能跑。
c.开箱即用的智能体能力
文件、Shell、联网、定时任务、记忆、检索。
d.IM 机器人原生支持
直接对接 Telegram / Discord 做远程助手。
e.兼容 OpenClaw 技能生态
可直接使用现有 SKILL.md 技能。
f.隐私优先
记忆全本地 SQLite 存储，不依赖外部数据库。
c.项目地址
zofrasca/lightclaw
d.OpenClaw 差生文具多: 你可能不需要 4 个 Workspace
a.问题引入
越是刚上手 OpenClaw，越容易先把 Workspace 配满。架构图画得很漂亮：Coordinator、Researcher、Writer、Executor，分工明确。可两周后回头看：每个 workspace 里空空如也，真正干活的还是 Coordinator 一个。这像极了小时候老师的一句话：差生文具多。我们以为自己在做工程化，实际是在用"复杂感"麻痹"跑通的痛苦"。
b.这不是新手问题，是人类通病
一个来自 no-code 工作流社区：有人把邮件工作拆成三个 agent，其实一个 agent 加三个工具就够了。另一个来自大厂工程团队的复盘：GitHub 写过一篇文章，很多 multi-agent 的失败，不是模型不行，而是结构设计缺乏约束。背景完全不同，却在犯同样的错。因为我们天生喜欢把简单的事做复杂。
c.为什么我们爱过度设计
a.复杂看起来更专业
人类有个根深蒂固的直觉：复杂的东西更高级。四个 workspace 分工明确，看起来比一个 workspace 单打独斗更像"工程"。而且画架构图很爽。但让一个 workspace 真正跑通很痛苦，于是我们下意识选择更舒服的那条路：先把结构搭起来。
b.分工的诱惑
从亚当·斯密的分工理论到现代软件工程，我们被教育了很久：专业化能提升效率。问题在于：专业化从来不是免费的。它带来协调成本。当你把一个脑子拆成多个脑子，这些原本"默认发生"的事情，都必须显式设计。多出来的不是产能，而是管理工作。
c.我们低估了"协调"这件事的重量
在单 agent 里，上下文是一体的。一旦拆成多个 workspace，你立刻会遇到这些隐性成本：上下文丢失、格式错位、状态同步、错误传播。这些成本不会出现在你的架构图里，但会出现在你每天的调试里。
d.工具变强时，"企业边界"会收缩
经济学家科斯提出过：如果市场分工这么高效，为什么还需要企业？答案是：交易成本。AI Agent 也是同一个逻辑。工具越强，一个 workspace 的"可覆盖范围"就越大。OpenClaw 的 Skill 系统，本质上就是在降低"能力扩展"的成本：Skill 是能力扩展，Workspace/Agent 是角色分裂。查天气不需要"天气 agent"，需要的是 weather skill。
e.真实教训: 拆早了，收益为零，成本拉满
一开始做了"四 workspace 方案"，跑了两周发现：搜信息、深度分析、执行任务，主 workspace 都能搞定。真正需要独立 workspace 的场景只有一个：并行写代码。教训很简单：拆早了，只是在给自己加管理工作。
f.什么时候真的要拆: 三个硬条件
a.真正的并行
两个任务可以同时跑，互不依赖，不需要频繁交接。
b.硬隔离需求
权限不同、数据敏感度不同、必须分开上下文，或者需要把风险隔离开。
c.上下文爆炸
单 workspace 的上下文窗口真的不够，或者一个项目需要长期记忆与短期执行分离。
g.如果你决定拆，先把"协调工程"补齐
a.显式交接清单
每次交接必须明确：输入是什么、输出格式是什么、完成标准是什么、不确定点有哪些。
b.三份日志
行动日志：做了什么；拒绝日志：为什么没做；交接日志：传给谁、传了什么。拒绝日志最容易被忽略，但最有价值。
c.near-miss 摘要
定期记录"差点出事但被兜住"的事件。它能把协调的价值量化。
h.正确顺序: 先让一个 workspace 真正 work
a.先把一个 workspace 跑通
能完成日常任务、能处理边界情况、能稳定产出。
b.用 Skills 扩展能力
需要新能力就装 skill，不要先造新角色。
c.遇到瓶颈再拆
响应太慢才考虑并行；上下文太长才考虑分离；权限必须隔离才考虑独立 workspace。
i.三个问题
一个 workspace + skills 真的做不到吗？拆了之后，协调成本你准备好了吗？你是在解决问题，还是在享受设计复杂系统的快感？
e.OpenSandbox: 阿里开源的AI 基础设施-沙箱平台
a.说明
OpenSandbox 是一个面向 AI 应用的通用沙箱平台，提供多语言 SDK、统一的沙箱 API 以及基于 Docker/Kubernetes 的运行时环境，适用于编程智能体、GUI 智能体、智能体评估、AI 代码执行和强化学习训练等场景。
b.沙箱生命周期与运行时管理
通过 Docker 和 Kubernetes 驱动的能力，提供沙箱实例的创建、监控、续期和销毁。
c.多语言 SDK 与统一 API
支持 Python、Java/Kotlin 和 JavaScript SDK，基于标准化的生命周期与执行协议构建。
d.强大的沙箱内执行能力
支持执行 shell 命令、管理文件、运行多语言代码解释器、暴露端口以及实时流式传输日志与指标。
e.为真实 AI 工作负载设计
支持编程智能体、浏览器自动化、远程开发、AI 代码执行和强化学习训练等场景。
f.项目地址
https://github.com/alibaba/OpenSandbox
03.常用信息3
a.Claude Code 自动记忆上线
a.说明
Claude Code 上线了 Auto-memory（自动记忆）功能，默认开启。它会自动记录项目模式、关键命令和偏好设置，甚至是遇到的某些坑。
b.默认开启，自动"记笔记"
在用 Claude Code 敲代码时，它会在后台默默观察：代码风格偏好、工作流习惯、常见错误原因。这些东西它都会自动存下来，不需要手动去写文档。
c.存储位置
记忆是按项目隔离存储的，路径在：~/.claude/projects/<项目名>/memory/。这保证了不同项目的偏好不会混淆。
d.200 行"小抄"直达大脑
每次会话开始时，它会把 MEMORY.md 前 200 行的内容，直接塞进系统的 Prompt 里。这意味着它在开口说话前，已经先"复习"过一遍项目核心规则和历史经验。
e.更新 Claude Code
使用 x-cmd 可以一行命令安装/更新 Claude Code 最新版本：x env use claude-code=v2.1.63
f.原文链接
https://code.claude.com/docs/en/memory#auto-memory
b.OpenClaw记忆外挂: Tokens 消耗降低 72%， 永不失忆
a.问题背景
a.记忆机制问题
小龙虾用久后记不住重要的东西，反而无关紧要的事情记得贼清楚。每聊一句都要附带之前的对话，比如让 AI 写代码后，每次对话都附带这个 python 代码，直接干掉 15w token。
b.主动记忆不可靠
OpenClaw 是主动记忆的，记不记住全看 AI 发挥。经常出现今天刚说的东西，转眼就忘记。
c.解决方案
研究一堆记忆方案后，找到只用配置两条命令的方案，就能 Tokens 消耗降低 72%，永不失忆。
b.安装记忆外挂
a.获取 APIKEY
首先登录网址 https://memos-dashboard.openmem.net/cn/apikeys/，假如要注册先注册，然后复制 APIKEY。
b.配置环境变量
在命令行输入命令：mkdir -p ~/.openclaw && echo "MEMOS_API_KEY=mpg-..." > ~/.openclaw/.env，其中的 mpg-... 就是刚刚复制的密钥。
c.安装插件
输入命令：openclaw plugins install @memtensor/memos-cloud-openclaw-plugin，安装完成。
d.效果验证
开源插件的官方做过实验，安装后 OpenClaw 将会节省大量 token。项目地址：https://github.com/MemTensor/MemOS-Cloud-OpenClaw-Plugin
c.记忆外挂测试
a.测试方法
说几个偏好，然后开启一个新的 session，看看能不能记住。首先告诉它一个简单的事实，然后定义好名字：钉子，职业是数码宝贝，还告诉它要写一篇关于记忆的文章。
b.测试结果
清空当前记忆，点击 New session，按照小龙虾的机制这些记忆就会消失。但再提问时，它记住了自己的名字和要写文章的事情。因为通过安装插件，记忆已存于云端。
c.云端检索
问最喜欢的事物是什么时，云端在帮你检索记忆，清楚记着喜欢吃什么、最近在干什么。OpenClaw 在云端永生，无论本地如何乱搞，该记得永远记得。
d.多龙虾共享记忆，进行心灵感应
a.多数字员工场景
很多人开始搭建自己的龙虾数字员工，一个办公室里会有很多数字员工开始工作。这些数字员工的沟通会有很多冗余信息导致 token 量爆炸。
b.共享记忆机制
利用安装的插件，它们像有了心灵感应一样，token 量和准确度大大降低。使用 MEMOS_USER_ID 在不同的 OpenClaw 共享记忆，默认值是 openclaw-user，不需要特别配置。
c.跨设备验证
之前在虚拟机里聊喜欢的食物，打开本机的 OpenClaw，依然记住偏好。OpenClaw 要发挥真正的生产力，需要更强的记忆系统。
e.Coming Soon: 一个 OpenClaw 带多个 Agent 协作
a.多 Agent 场景
一个 OpenClaw 实例里跑多个 Agent，它们共享同一个记忆池。比如 Agent A 负责创意策划、Agent B 负责技术执行、Agent C 负责质量把控。
b.现有方案的问题
A 产出的内容得通过对话传递给 B，B 的输出再手动复制给 C。信息传递全靠"虾工"，token 消耗本来就高，更是没有下限。
c.即将上线的方案: 记忆分层管理
核心是：共享该共享的，隔离该隔离的。原始信息和标准化内容放在共享记忆里，确保所有 agent 都有统一的 baseline，但各个 agent 之间的记忆相互隔离。
d.具体例子
Agent A 策划活动时，头脑风暴过程、被否决的方案在 A 的私有记忆里，但最终产出的"活动方案 v1.0"进入共享记忆。Agent B 启动时读到 A 的最终方案，B 的代码调试记录在私有记忆里，完成的"物料清单"进入共享记忆。Agent C 做质量把控时，能看到 A 的方案 + B 的清单，但看不到各自的工作草稿。
f.尝鲜方式
这个能力已经在 MemOS 的多视角记忆分支里验证过，正在适配到 OpenClaw 插件中。参考教程：https://github.com/MemTensor/MemOS/tree/multi-view-with-game-demo，或在 GitHub 上关注项目更新。
c.emdash：同时跑多个 AI 编程 Agent，每个都在独立的 Git Worktree 里互不干扰
a.说明
还在等一个 Agent 写完才敢开下一个？Emdash 让你同时跑多个 AI 编程 Agent，每个都在独立的 Git Worktree 里互不干扰。
b.亮点
支持 21 种 Agent：Claude Code、Codex、Gemini 随便混搭
直接从 Linear、Jira 导入任务，Agent 自动获取上下文
Best-of-N：同一任务扔给多个 Agent，对比谁写得更好
YC 2026 冬季批次，GitHub 2000+ Star，下载量 6 万+
c.地址
完全开源免费，brew install --cask emdash 一行搞定
GitHub 地址：https://github.com/generalaction/emdash
官网：https://emdash.sh
d.GitNexus：一个零服务器的代码智能引擎，所有计算都在浏览器里完成，不需要任何后端服务
a.说明
GitNexus 是一个零服务器的代码智能引擎，所有计算都在浏览器里完成，不需要任何后端服务。
b.核心
1️.纯浏览器运行 — 粘贴仓库地址就能用
2.自动生成知识图谱 — 函数调用链、模块依赖一目了然
3.MCP 协议集成 — 让 AI 编程助手真正理解你的代码结构
c.地址
https://github.com/abhigyanpatwari/GitNexus
e.Hermes Agent：终端型自治的Agent框架
a.说明
Hermes Agent 是 Nous Research 推出的完全开源、可本地部署、支持多模型、多平台接入、
自带记忆与技能成长、可定时自动化、带安全沙箱的终端型自治 AI 智能体，同时面向个人使用与 AI 研究。
b.核心亮点
a.定位
本地部署、持久化、可成长的个人自治 AI 智能体。
b.模型自由
支持 Nous/OpenRouter/自建模型，一键切换无锁死。
c.交互
原生 TUI 终端界面，非 WebUI。
d.多平台
Telegram/Discord/Slack/WhatsApp/CLI 统一接入。
e.能力
持久记忆 + 自动生成技能 + 定时任务 + 并行子智能体。
f.安全
多终端沙箱环境，支持远程隔离运行。
g.研究向
批量轨迹生成 + RL 训练环境，适合做智能体研究。
c.参考链接
https://github.com/NousResearch/hermes-agent
04.常用信息4
a.AgentFS : AI Agent 专用的文件系统
a.说明
AgentFS 是一款专为 AI Agent 设计的文件系统。正如传统文件系统为应用程序提供文件与目录抽象一样，AgentFS 为 AI Agent 提供其所需的存储抽象。
b.仓库包含内容
a.SDK
支持 TypeScript、Python、Rust 语言的库，用于程序化访问文件系统。
b.CLI
用于管理 Agent 文件系统的命令行工具。
c.挂载与访问
在 Linux 上通过 FUSE、macOS 上通过 NFS 将 AgentFS 挂载到主机文件系统，并用命令行工具访问 AgentFS 文件。
d.AgentFS 规范
基于 SQLite 的 Agent 文件系统规范。
c.核心优势
a.可审计性
所有文件操作、工具调用、状态变更都会记录在 SQLite 数据库中，可用 SQL 查询完整历史，用于调试、行为分析与合规。
b.可复现性
随时用 cp agent.db snapshot.db 对 Agent 状态做快照，后续可恢复、复现执行状态、做假设测试或回滚错误。
c.可移植性
整个 Agent 运行时（文件、状态、历史）都存在单个 SQLite 文件中，可在机器间迁移、放入版本控制、部署到支持 Turso 的任意系统。
d.参考链接
https://github.com/tursodatabase/agentfs
b.Datus：数据工程智能代理，其核心目标是为你的数据系统构建可进化的上下文环境。
a.Datus项目介绍
Datus 是一个开源的数据工程智能代理，其核心目标是为你的数据系统构建可进化的上下文环境。它倡导数据工程应从传统的“建表和管道”模式，转向“为分析师和业务用户交付有明确范围、领域感知的智能代理”。
b.核心架构
a.组件概述
Datus 包含三个主要组件，形成一个完整的数据服务生态。
b.Datus-CLI
面向数据工程师的AI命令行工具。可交互式地编写SQL、构建子代理和上下文，类似于“数据工程师的 Claude Code”。
c.Datus-Chat
面向数据分析师的网页聊天机器人。支持多轮对话，并内置了反馈机制（点赞、报错、分享成功案例）。
d.Datus-API
为其他需要稳定、准确数据服务的代理或应用程序提供API接口。
c.关键特性
a.上下文数据工程
自动构建并持续更新公司数据的“活”语义地图，融合元数据、指标、参考SQL和外部知识，让团队基于上下文协作，而非原始SQL。
b.代理式聊天
在终端中，数据工程师可以像与Claude Code对话一样与数据交互，即时召回表或指标信息，并执行智能操作。
c.面向领域的子代理
将不同的数据领域（如销售、财务）转化为具备领域知识的聊天机器人。每个子代理封装了专属的上下文、工具和规则，确保数据访问的准确性、可复用性和安全性。
d.持续学习循环
系统从每一次查询和用户反馈中学习进化，通过记录成功案例和用户修正，持续提升其推理和回答的准确性。
d.开源地址
https://github.com/Datus-ai/Datus-agent
c.CDP MCP：让AI自动打开浏览器完成设计走查和交互测试
a.CDP MCP 核心优势
CDP MCP（ChromeDevTools MCP）可让AI自动打开浏览器完成设计走查和交互测试，
搭配设计稿使用时自动设计走查更精准，结合设计系统可实现UI和交互测试的全自动化，无需人工干预。
b.核心功能
a.页面操作能力
Agent可通过Puppeteer实现自动化点击、输入、拖拽、导航、表单填写、文件上传等操作。
b.数据采集能力
可获取网络请求、控制视口与设备仿真、执行脚本、抓取控制台日志、截图、DOM快照。
c.性能分析能力
通过性能追踪和Lighthouse审计分析网页性能与内存。
c.浏览器连接方式
a.默认启动
项目默认启动自带配置的Chrome浏览器。
b.自定义连接
支持通过`--autoConnect`、`--browser-url`或WebSocket连接已有浏览器实例，可共享登录态和页面状态，便于人工测试与代理测试协同。
c.轻量模式
提供“slim”模式，仅暴露少量导航与脚本工具，适用于基础浏览任务。
d.项目地址
github.com/ChromeDevTools/chrome-devtools-mcp
d.Mirix：一款具备高级记忆能力的多智能体个人助手
a.Mirix简介
Mirix是一款具备高级记忆能力的多智能体个人助手，可追踪屏幕活动、智能解答用户问题，通过捕捉实时视觉数据并整合为结构化记忆，将各类输入转化为适配用户数字体验的丰富知识库。
b.核心架构
以先进的内存系统为核心，包含六个由专门智能体独立管理的记忆组件，分别为核心记忆、情景记忆、语义记忆、程序记忆、资源记忆、知识记忆。
c.关键特性
a.屏幕活动追踪
持续捕捉视觉数据，并对数据进行智能整合，转化为结构化记忆。
b.隐私优先设计
所有长期数据默认本地存储，用户可自主控制隐私相关设置。
c.高级搜索能力
支持PostgreSQL原生的BM25全文搜索，同时兼容向量相似度搜索。
d.多模态输入支持
可无缝处理文本、图像、语音、屏幕截图多种形式的输入内容。
d.项目地址
https://github.com/Mirix-AI/MIRIX
e.ChatLab: 将你的群聊转化成可洞察的知识
a.ChatLab: 将你的群聊转化成可洞察的知识
a.产品简介
ChatLab 是一款开源桌面应用，用于理解您的社交对话。它结合了灵活的 SQL 引擎与 AI 代理，让您可以在自己的机器上探索聊天模式、提出更好的问题并从聊天数据中提取洞察。
b.平台支持情况
a.当前支持
WhatsApp, LINE, 微信, QQ, Discord, Instagram, Telegram。
b.即将支持
iMessage, Messenger, KakaoTalk。
b.核心功能详解
a.🚀 为大量历史记录打造
流式解析和多工作者处理确保导入和分析响应迅速，即使处理百万条消息规模。
b.🔒 默认保护隐私
您的聊天数据和设置保留在本地。无需强制上传原始对话到云端。
c.🤖 真正可操作数据的 AI
代理 + 函数调用工作流程可以在上下文中搜索、总结和分析聊天记录。
d.📊 洞察丰富的可视化视图
在一处查看趋势、时间模式、互动频率、排名等。
e.🧩 跨平台数据规范化
将不同的导出格式映射到统一模型中，以便进行一致性分析。
c.参考信息
a.项目地址
https://github.com/hellodigua/ChatLab
3.4 分类4
00.汇总
a.分类1
Context Mode：MCP服务器，减少Claude Code工具输出98%上下文消耗 https://mksg.lu/blog/context-mode
Social Push：浏览器自动化插件，连接代码助手与社交平台 https://github.com/jihe520/social-push
v2ray-wss：一键代理脚本，支持Reality与hy2等多协议 https://github.com/yeahwu/v2ray-wss
Agent View：多AI编码终端仪表盘，统一管理Claude/Gemini等代理 https://github.com/frayo44/agent-view
UltimateSearchSkill：纯 Shell 双引擎暴力搜索 Skill https://github.com/ckckck/UltimateSearchSkill
b.分类2
Star-Office-UI：OpenClaw 龙虾的像素办公室 https://github.com/ringhyacinth/Star-Office-UI
Agent-Reach：为AI Agent提供互联网能力的脚手架，支持多平台抓取 https://github.com/Panniantong/Agent-Reach
OpenPackage：统一配置分发工具 https://github.com/enulus/OpenPackage
memU：跨对话记忆系统，支持向量数据库与多模态存储 https://github.com/NevaMind-AI/memU
OpenBrowserClaw：浏览器端的 AI 助手 https://github.com/sachaa/openbrowserclaw
c.分类3
Codeman：一个给AI编程智能体用的Web控制平台，主打移动端优先 https://github.com/Ark0N/Codeman
OpenClaw-RL：一个面向大模型的全异步、私有化部署强化学习框架 https://github.com/Gen-Verse/OpenClaw-RL
SuperDoc：在浏览器、服务器无界面环境、AI智能工作流中渲染和编辑DOCX文件 https://github.com/superdoc-dev/superdoc
OpenCrabs:开源的AI螃蟹，借鉴Open Claw设计 https://github.com/adolfousier/opencrabs
Agent Orchestrator:AI智能体的调度中心 https://github.com/ComposioHQ/agent-orchestrator
d.分类4
让你的ClaudeCode秒变Openclaw，连接飞书、Discord远程控制 https://github.com/op7418/CodePilot/releases/tag/v0.26.0
ClawPanel是OpenClaw AI Agent框架的可视化管理面板，内置智能AI助手 https://github.com/qingchencloud/clawpanel
Paperclip：AI团队管理平台，真正的AI公司 https://github.com/paperclipai/paperclip
Edict：基于中国古代官僚制衡思想的多智能体框架 https://github.com/cft0808/edict
谷歌 AI 智能体记忆设计方案：主动整理与结构化记忆 https://github.com/GoogleCloudPlatform/generative-ai/tree/main/gemini/agents/always-on-memory-agent
e.分类5
Readwise推出了全新的命令行工具Readwise CLI https://readwise.io/cli
Memento-Skills：一个能自主构建、适应和改进任务专用 Agent https://github.com/Memento-Teams/Memento-Skills.git
MemPal：让 claude code 和 codex 实时无缝交流 https://zhanghandong.github.io/mempal/
01.常用信息1
a.Context Mode：高效压缩 AI 工具输出，守护上下文窗口
a.痛点分析
AI Agent 工具交互中，上下文窗口被大量原始工具输出快速消耗。例如 Playwright 页面快照占 56 KB、20 个 GitHub issue 占 59 KB。同时，启用 81 个工具时，定义部分消耗 143K tokens，占典型 200K 上下文窗口的 72%。
b.解决方案
Cloudflare 推出的 Code Mode 已解决工具定义压缩问题，而 Context Mode 针对“输出侧”优化。它将典型场景下的 315 KB 原始数据压缩至 5.4 KB，节省 98% 上下文，将有效会话时长从约 30 分钟延长至约 3 小时。
c.核心技术
a.沙箱执行
所有工具在独立子进程运行（支持10种语言），仅返回必要的 stdout。完整数据、日志和 API 响应永不进入上下文。
b.精确知识库
Markdown 按标题分块存入 SQLite FTS5，使用 BM25 + 词干 + 模糊匹配检索，直接返回原文代码块而非摘要。
d.核心总结
a.优化成果
实测 11 个场景中，单次调用输出控制在 1 KB 以内，上下文剩余率在 45 分钟后从 60% 提升至 99%。
b.生态互补
与 Cloudflare Code Mode 形成闭环，前者压缩输入侧定义，后者压缩输出侧数据。
b.Social Push：赛博传声筒与浏览器自动化
a.功能定位
这是一个专给 Claude Code 写的浏览器自动化小插件，底层基于 Vercel 的 agent-browser。它将代码助手直接连上各种社交平台，实现通过语音指令自动发帖。
b.工作流程
用户只需输入“帮我把这文章发到小红书”，插件会自动处理点按钮、填正文、传图片等操作。
c.目标用户
主要面向经常需要全平台分发内容的创作者和技术博主，适合厌倦了机械性复制粘贴工作的用户。
d.核心总结
a.使用场景
解决多平台内容分发的重复劳动，特别适合日更三四个平台的创作者。
b.技术门槛
需要用户熟悉 Claude Code 及终端操作。
c.v2ray-wss：一键代理脚本
a.项目概况
这是一个自撸的一键代理脚本，已有 3k+ star，支持大部分 Linux 发行版。
b.协议选择建议
a.落地机（国外）
推荐使用 Shadowsocks，简单稳定，兼容性好。
b.CF前置（中转）
推荐 WS + TLS，伪装效果好，适合套 Cloudflare。
c.直连机（抗封）
优先使用 Reality（xtls-rprx-vision），目前最强抗检测方案。
d.弱网环境
推荐使用 Hysteria2（hy2），暴力发包，主走 UDP。
e.特殊需求
支持 HTTPS 正向代理（类 naiveproxy），无客户端限制。
c.核心总结
a.安全提醒
直连机请使用 Reality 或 HTTPS 正向代理。SS 和 WSS 不能用于直连，存在被封 IP 或端口的风险。
d.Agent View：轻量级终端代理编排器
a.产品定义
这是 AI 编码代理的 tmux 仪表盘，能够把 Claude、Gemini、OpenCode、Codex 等多个代理塞到一个 TUI（终端用户界面）里进行管理。
b.核心价值
当在多个任务上并行运行不同的 AI 代理（如重构、写测试、排查 Bug）时，Agent View 提供统一的仪表盘进行管理和监控。
c.核心总结
a.应用场景
解决多任务并行时的窗口管理灾难，实现多代理的统一调度。
e.UltimateSearchSkill：纯 Shell 双引擎暴力搜索 Skill
a.背景描述
这是一个针对臃肿 MCP 协议的返璞归真之作，采用纯 Shell 手搓而成。
b.技术栈
塞满了 Grok、Tavily 聚合池，并绑定了 FlareSolverr 自动破盾。这不是简单的 API 玩具包装器，而是一个缝合怪战车。
c.核心总结
a.适用人群
适合懂 Docker、拥有免费 Token/API Key、且厌恶复杂依赖的老用户。
02.常用信息2
a.Star-Office-UI：OpenClaw 龙虾的像素办公室
a.项目创意
这是一个像素风格的办公室可视化项目，龙虾会根据状态自动走到不同位置（休息区 / 工作区 / bug 区）。
b.主要功能
左下角添加工作小记，支持邀请其他龙虾加入办公室（功能开发中），并已完成手机端适配。
c.核心总结
a.开源地址
https://github.com/ringhyacinth/Star-Office-UI
b.Agent Reach：为 AI Agent 提供互联网能力的脚手架
a.功能特性
支持 Twitter、Reddit、YouTube、B站、小红书等平台的数据抓取。
统一封装 yt-dlp、xreach、Jina Reader 等上游工具，无需申请 API，默认渠道免配置。
b.兼容性
Claude Code、Cursor、Windsurf 等支持命令行的 AI Agent 均可使用。
c.核心总结
a.核心价值
让 AI Agent 一键获得网络访问能力，支持字幕提取、搜索和访问。
b.安全性
代码开源，支持导出 Cookie 存储在本地，权限可控。
c.OpenPackage：统一配置分发工具
a.功能描述
抽象一层配置，写一次自动分发到 Claude Code、Cursor、Copilot、Codex 等所有平台，格式自动转换。
b.管理范围
统一管理 rules、commands、agents、skills 和 MCP 配置，支持依赖管理和项目级隔离。
c.核心总结
a.解决痛点
解决多 AI 编程工具配置文件位置和格式不统一、同步繁琐的问题。
d.memU：跨对话记忆系统
a.MemU项目概述
MemU项目在GitHub上获得了超过10k星标，是一个旨在解决AI助手记忆断层问题的解决方案。
b.核心痛点分析
全天候AI助手（如OpenClaw）存在记忆断层问题，无法跨对话保留用户的偏好、习惯和目标，导致交互体验缺乏连续性。
c.核心功能与特性
a.持续记忆能力
支持跨对话持续记忆，实现类人记忆能力，能够自动存储并关联用户信息，确保长期记忆的保留。
b.多模态数据支持
支持文本、图片、音频、视频等多种类型数据的存储，满足多样化的信息记录需求。
c.智能语义管理
具备自动语义分类功能，能够快速定位历史信息，提升信息检索效率。
d.广泛的模型兼容性
支持主流大语言模型（LLM，如OpenAI），可轻松集成到各类AI项目中，具有极高的适配性。
e.OpenBrowserClaw：浏览器端的 AI 助手
a.架构特点
纯前端技术栈，无需搭服务器或 Docker。
将数据库、文件系统、基于 WASM 的 Linux 虚拟机全部塞进浏览器。
b.核心能力
支持绑定 Claude API 对话，数据存储在本地 IndexedDB（隐私安全），支持集成 Telegram 机器人。
c.核心总结
编译后仅为静态网页，可直接丢到 GitHub Pages 运行，适合不想维护服务器的用户。
03.常用信息3
a.Codeman：一个给AI编程智能体用的Web控制平台，主打移动端优先
a.说明
Codeman是一个给AI编程智能体用的Web控制平台，主打移动端优先、零延迟远程输入、安全二维码登录、
实时智能体可视化和24小时无人值守自动续跑，让Claude Code、OpenCode这类AI编程工具能稳定、高效、远程、无人值守地长期运行。
b.核心价值
a.解决远程编码延迟
实现零延迟本地回显，确保远程打字无卡顿。
b.移动端体验优化
针对触控进行优化，支持滑动切换，提供二维码免密登录，真正实现手机端的便捷使用。
c.无人值守自动化
支持智能体在卡死或空闲时自动重启。
d.多智能体管理
能够同时运行多个任务，并提供实时可视化监控。
e.工业级安全保障
采用一次性二维码技术，符合顶会安全规范。
c.访问地址
https://github.com/Ark0N/Codeman
b.OpenClaw-RL：一个面向大模型的全异步、私有化部署强化学习框架
a.项目概述
OpenClaw-RL是一个面向大模型的全异步、私有化部署强化学习框架。
它能直接从真实多轮对话中自动采集信号，在后台持续训练AI Agent而不中断服务。框架同时支持二元强化学习（GRPO）与在线策略蒸馏（OPD）两种范式。
b.核心定位
专为LLM设计的异步RL框架，利用日常对话作为训练信号，用于训练个性化AI Agent。
c.与传统RL的区别
a.传统模式
采用中心化批训练方式，依赖预先采集好的数据集。
b.OpenClaw-RL模式
实时拦截多轮对话，进行后台异步优化，不影响模型正常服务。
d.核心架构
a.四大组件
框架由Agent服务、轨迹采集、PRM打分、策略训练四大组件构成，实现了完全异步解耦，各组件互不阻塞。
e.关键特性
a.私有化部署
全程本地运行，确保对话数据不外流。
b.全自动训练
无需人工标注，自动区分有效轮次、打分及上采样。
c.双学习范式
a.二元强化学习（GRPO）
利用PRM给出好坏或中性的奖励信号。
b.在线策略蒸馏（OPD）
从对话中提取文本提示，提供更细粒度的监督信号。
d.工程化成熟
具备会话感知、平滑权重更新、质量过滤以及日志可调试等特性。
f.项目链接
https://github.com/Gen-Verse/OpenClaw-RL
c.SuperDoc：一个JavaScript库，可在浏览器、服务器无界面环境、AI智能工作流中渲染和编辑DOCX文件
a.SuperDoc简介
SuperDoc是一个JavaScript库，可在浏览器、服务器无界面环境、AI智能工作流中渲染和编辑DOCX文件，
支持修订模式、复杂表格、页眉页脚、实时协作等实用功能，支持私有化部署且开源。
b.核心功能
a.格式支持
基于OOXML的真实DOCX格式，支持分页、分节、页眉页脚。
b.部署安全
完全私有化部署，文档不上传外部服务器。
c.框架兼容
兼容所有前端框架。
d.协作能力
基于Yjs实现实时多人协作、评论、修订，支持冲突自动解决。
e.运行环境
支持Node无界面运行，可对接大模型实现文档自动化、AI批注。
f.扩展能力
内置60+扩展，支持自定义插件。
g.授权模式
双授权模式：开源AGPLv3协议 / 商业授权。
c.项目地址
https://github.com/superdoc-dev/superdoc
d.OpenCrabs:开源的AI螃蟹，借鉴Open Claw设计
a.项目概述
OpenCrabs是一个基于Rust开发的自主AI代理，以单一二进制文件形式实现，支持多通道运行，其设计灵感来源于Open Claw项目。是一个多功能、多模型、本地+云端一体的AI智能体。
b.核心特点
a.模型接入
接入几乎所有主流模型加本地大模型，自动同步新模型。
b.响应与记忆
实时流式响应、会话记忆、上下文智能管理。
c.统计与部署
完整费用与Token统计，支持本地私有化部署。
d.记忆系统
自带三级本地记忆系统（持久记忆+日志+向量检索），离线可用。
e.自定义配置
可通过Markdown文件自定义AI人格、身份、工具、记忆，高度可配置。
c.项目链接
https://github.com/adolfousier/opencrabs
e.Agent Orchestrator:AI智能体的调度中心
a.项目背景
分享一个开源项目Agent Orchestrator，这个项目的出现主要是因为管理单个AI智能体很容易，
但同时管理几十个在不同分支、PR上工作的智能体则是一个复杂的协调问题。
Agent Orchestrator旨在自动化所有协调、隔离和状态跟踪工作，让用户能够专注于代码审查和决策。
b.主要功能
a.多智能体管理
Agent Orchestrator系统可以同时生成和管理多个AI编程智能体，
每个智能体在独立的git worktree（工作树）和分支上工作，并创建独立的PullRequest(PR)。
b.自动修复CI失败
当持续集成（CI）测试失败时，智能体会自动获取日志并尝试修复。
c.自动处理代码审查意见
当代码审查者提出修改请求时，智能体会自动处理这些意见。
d.人类监督
仅在需要人类判断时（例如，PR已批准且CI通过，等待合并）通知用户。
c.使用方法
a.最快使用方式
在命令行中执行ao start[你的仓库URL]，该命令会自动检测项目配置并启动。
b.从现有本地仓库启动
在项目目录执行ao init --auto然后ao start。
c.创建智能体
启动后，可以使用ao spawn[项目名][问题编号]来创建一个针对特定任务（如GitHub issue）的智能体。
d.架构与工作流
a.插件化架构
该系统高度模块化，核心的八个组件（如运行时、智能体类型、工作区、问题追踪器等）均可通过插件替换，
默认提供常用选项（如tmux运行时、Claude Code智能体、GitHub追踪器）。
b.工作流程
用户通过ao spawn命令创建任务后，系统会自动完成以下步骤：创建工作区、启动运行时环境、
启动AI智能体、智能体自主工作、系统自动处理反馈（CI或审查）、在需要时通知用户。
e.项目链接
https://github.com/ComposioHQ/agent-orchestrator
04.常用信息4
a.让你的ClaudeCode秒变Openclaw，连接飞书、Discord远程控制
a.项目背景
这几天都在用Vibe Coding做我的Agent客户端Codepilot。除开春节假期的九天我用16天，发布了40个版本、220次提交，效率真的拉满。
刚开始这个项目的定位只是Claude Code的桌面端，现在已经支持飞书等IM远程连接、可视化配置所有Code plan套餐、
藏师傅写的设计Agent和素材库、多个Agent并发分屏、Token使用检测看板、还能一键帮你安装Claude Code、MacOS和Windows全平台支持等一系列的Agent功能。
可以说完全自己搞了一个Claude Code桌面端加Cowork加OpenClaw。非常适合小白入门和使用，比OpenClaw安全多了。
b.CodePilot功能
这几天主要集中在实现一套非常优雅而且全面的Claude Code连接各种IM工具比如飞书之类的系统。
参考了各个项目的优势同时结合我自己的需求，非常易用，比OpenClaw的配置方便非常多。
c.Claude-to-IM-skill
a.说明
这个Skills可以直接将你当前的Claude Code对话远程连接到飞书、Discord等IM工具，即使你在外面也可以跟你的Claude Code进行交互了。
b.功能支持
三大IM平台（Telegram、Discord、飞书，可任意组合启用）、交互式配置（引导式向导逐步收集token，附带详细获取说明）、
权限控制（工具调用需要在聊天中通过内联按钮明确批准）、流式预览（实时查看Claude的输出，Telegram和Discord支持）、
会话持久化（对话在守护进程重启后保留）、密钥保护（token以chmod600存储，日志中自动脱敏）、
无需编写代码（安装Skill后运行/claude-to-im setup即可）。
c.安装方式
npx skills add op7418/Claude-to-IM-skill
d.项目链接
https://github.com/op7418/Claude-to-IM-skill
d.Claude-to-IM
a.说明
这个主要面向的是开发者朋友们，如果你的产品也是基于Agent SDK开发，你也想要快速的接入多个IM远程控制，就可以用这个库。
b.主要特点
多平台适配器（Telegram长轮询、Discord Gateway WebSocket、飞书WSClient）、
流式预览（通过消息编辑实现实时响应草稿，支持按平台定制的节流策略）、
权限管理（通过交互式内联按钮实现Claude Code工具审批）、
会话绑定（每个IM聊天映射到一个持久化的会话，支持工作目录和模型配置）、
Markdown渲染（平台原生格式化）、可靠投递（按平台限制自动分块、指数退避重试、HTML降级、消息去重）、
安全机制（输入验证、令牌桶速率限制、用户授权白名单、完整审计日志）、宿主无关（所有宿主依赖通过4个DI接口抽象）。
c.项目链接
https://github.com/op7418/Claude-to-IM
e.项目链接
https://github.com/op7418/CodePilot/releases/tag/v0.26.0
b.ClawPanel是OpenClaw AI Agent框架的可视化管理面板，内置智能AI助手
a.ClawPanel简介
ClawPanel是OpenClaw AI Agent框架的可视化管理面板，内置智能AI助手，
可实现OpenClaw的一键安装、配置自动诊断、问题排查及错误修复，适配新手到专家各类用户。
b.主要特点
a.内置AI助手
提供4种操作模式、8大工具和交互式问答能力。
b.多平台支持
适配macOS、Windows、Linux桌面端，同时提供Linux服务器Web版、Docker部署方案。
c.功能全面
涵盖仪表盘监控、服务管理、模型与网关配置、Agent管理、聊天对话、日志查看、记忆管理等核心功能。
d.便捷安装
各平台提供图形化安装包或部署脚本，Linux服务器可通过一条命令一键部署Web版。
c.各平台安装方式
a.macOS
下载DMG文件，将ClawPanel拖入「应用程序」文件夹；首次运行需在终端执行命令解除限制，或在系统设置中选择「仍要打开」。
b.Windows
提供EXE安装器（推荐，双击安装）、MSI安装包（适用于企业部署/静默安装）。
c.Linux
提供AppImage（免安装，赋权后直接运行）、DEB（Debian/Ubuntu专用）、RPM（Fedora/RHEL专用）安装包；服务器无桌面环境可通过脚本一键部署Web版，部署后访问http://服务器IP:1420。
d.Docker
支持通过Docker命令部署，也可使用Compose、自定义镜像、Nginx反向代理等方式，功能与桌面版一致。
d.核心功能矩阵
AI助手（多模式、多工具）
️图片识别与多模态对话
仪表盘与实时监控
服务管理（启停、升级、备份）
模型配置与连通性测试
网关配置与网络设置
Agent管理与工作区
聊天与会话管理
日志查看与搜索
记忆管理与导出
扩展工具（内网穿透、状态监控）
e.项目地址
https://github.com/qingchencloud/clawpanel
c.Paperclip：AI团队管理平台，真正的AI公司
a.概述
分享一个开源项目Paperclip，用于管理一群AI员工。
b.详细说明
Paperclip 是一个开源AI团队编排平台，用来把多个AI智能体（如OpenClaw、Claude、Cursor）组织成完整的自主运营公司。
它提供组织架构、预算控制、任务工单、成本监控、治理权限、多公司隔离，让你像管理公司一样管理AI团队，
实现7×24小时无人化业务运行，不用手动盯AI、开一堆窗口、重复喂上下文。简单来说说：AI员工 + Paperclip = 全自动AI公司。
c.补充说明
不得不说AI的发展真是快！！
d.项目链接
https://github.com/paperclipai/paperclip
d.Edict：基于中国古代官僚制衡思想的多智能体框架
a.核心设计理念
将中国古代帝国的“分权制衡”官僚制度应用于 AI 多智能体协作架构。通过引入“三省六部制”和“太子”等角色，在任务流转中强制加入“门下省审核”环节，以确保任务的质量与合规性。
b.组织架构与角色
系统设定了严密的层级与分工：太子负责消息分拣与闲聊过滤；三省（中书、门下、尚书）分别负责任务规划、审议驳回与派发执行；七部（户、礼、兵、刑、工、吏及早朝官）负责专项业务的执行。每个智能体拥有独立的工作空间和技能集。
c.权限与交互
构建了严格的权限矩阵，明确规定了智能体之间的消息发送规则（白纸黑字）。系统提供 CLI、API 和 UI 三种管理方式，并支持从远程（如 GitHub）为各部门灵活增补技能。
d.产品差异化
相比 CrewAI、AutoGen 等主流框架，Edict 提供了制度化的审核流程、完整的实时可视化看板以及任务过程的可干预性。通过“圣旨”、“奏折”、“上朝”等文化隐喻，设计了富有沉浸感的交互体验，并提供一键 Docker 部署。
e.核心总结
a.架构特色
模拟古代官僚体系，通过三省六部制实现分权制衡，内嵌强制审核流程。
b.功能优势
提供制度化流程保障、实时可视化看板及任务可干预性，区别于普通编排工具。
c.交互体验
使用文化隐喻增强沉浸感，支持多种管理方式与远程技能动态加载。
e.谷歌 AI 智能体记忆设计方案：主动整理与结构化记忆
a.现有方案局限性
传统的记忆方案存在明显短板：向量库结合 RAG 仅被动存储不主动处理；对话摘要随时间流逝易丢失细节且无法交叉关联；知识图谱虽然有效但构建与维护成本过高。
b.方案核心特点
谷歌提出的方案不需要向量数据库和嵌入操作，仅依靠大模型直接读取、思考并生成结构化记忆。它模拟人脑机制，能够主动对信息进行整理、关联和记忆，无需依赖外部复杂存储组件。
c.记忆工作流程
系统运行分为三个阶段：
1.信息摄入：支持文本、图片、音视频等 27 种格式，通过文件夹、Dashboard 或 API 自动解析并提取摘要、实体和重要度。
2.记忆整合：每 30 分钟自动运行一次，类似人脑睡眠，回顾未整理记忆、发现关联、生成洞察并压缩冗余。
3.记忆查询：支持自然语言提问，智能体读取全部记忆并给出带来源引用的回答。
d.核心总结
a.技术路线
摒弃向量库与 Embeddings，利用大模型原生能力实现主动记忆整理。
b.运行机制
30 分钟周期性整合，支持多模态输入（27 种格式）及跨记忆关联洞察。
c.能力价值
降低维护成本，提供带引用的精准问答，模拟人脑记忆巩固过程。
05.常用信息5
a.Readwise推出了全新的命令行工具Readwise CLI
a.工具介绍
Readwise推出了全新的命令行工具Readwise CLI。
这意味着你之前在Readwise中保存的一切内容现在都能从终端快速调用。
无论是书籍高光笔记还是文章PDF YouTube视频和新闻通讯全部即时可用。
这个工具不仅供个人使用还专门为人工智能代理设计。
b.核心功能
a.文档管理
你可以搜索文档添加标签创建高光导出库。
b.AI集成
甚至让AI帮你处理知识管理。同时它还能与各种AI工具集成实现自动化工作流。
c.安装与使用
a.安装方法
安装起来很简单在终端输入 npm install -g @readwise/cli 然后登录账户即可。
b.基本操作
基本操作包括搜索文档获取详情导出所有内容等。对于喜欢命令行操作的用户来说这大大提升了效率。
d.扩展功能
a.技能仓库
Readwise还提供了技能仓库里面有预设的强大功能可以直接安装使用。
b.MCP服务器
此外他们即将推出MCP服务器让不熟悉终端的用户也能轻松接入。目前测试版已开放。
e.推荐
如果你是阅读爱好者或知识工作者推荐尝试一下这个工具能让你的知识库真正活起来。详情访问 readwise.io/cli
b.Memento-Skills：一个能自主构建、适应和改进任务专用 Agent 的通用 Agent 系统
a.Memento-Skills概述
a.一句话定义
Memento-Skills 是一个能自主构建、适应和改进任务专用 Agent 的通用 Agent 系统，即会设计 Agent 的 Agent。
b.核心能力描述
假设你有一个 AI 助手，刚开始只会简单的网页搜索和终端操作。但随着使用，它会自动学习新技能并存下来，根据任务选择最合适的技能，从失败中反思，改进自己的行为。越用越强，不用重新训练。
b.三大核心技术
a.基于记忆的强化学习框架
a.技能库结构
Memento-Skills 的核心是一个记忆系统，不是简单的对话历史，而是结构化的技能库。每个技能都是一个 Markdown 文件，包含技能描述、使用场景、执行步骤、注意事项。
b.技能文件示例
---
# Skill: Web Search
## Description: 搜索互联网获取最新信息
## When to use: 用户询问实时信息、新闻、数据时
## Steps:
1. 分析用户查询意图
2. 构造搜索关键词
3. 调用搜索 API
4. 筛选和总结结果
## Notes:
- 优先使用权威来源
- 注意信息的时效性
- 多个来源交叉验证
---
c.长期记忆特性
这些技能文件就是 Agent 的长期记忆，可以跨会话持久化，越积越多，越用越强。
b.状态化提示
a.传统方式对比
传统 Agent 的提示词是静态的，每次对话都从零开始，每次都是新实习生，要从头教。
b.Memento-Skills方式
Memento-Skills 的提示词是有状态的，会携带之前的经验和技能，如同老员工带着工作手册，上手就能干。
c.读写反思学习
a.Read阶段
技能路由器分析当前任务，从技能库中选择最相关的技能，加载技能的上下文和执行步骤。
b.Write阶段
执行任务并记录结果，反思成功经验和失败教训，更新现有技能或创建新技能。
c.闭环意义
这个闭环让 Agent 能够持续学习而不需要更新模型参数，所有适应都是通过外部技能和提示词的进化实现的。
c.实验结果
a.GAIA基准测试
a.数据说明
模型准确率相对提升对比如下。
b.对比数据
模型 准确率 相对提升
基线 45.3% -
Memento-Skills 57.2% +26.2%
b.HLE基准测试
a.数据说明
Humanity's Last Exam 基准测试对比如下。
b.对比数据
模型 准确率 相对提升
基线 8.6% -
Memento-Skills 18.6% +116.2%
c.结果解读
116% 的提升相当于从偶尔能答对变成经常能答对，是质的飞跃。
d.技术细节
a.技能路由器
a.工作原理
分析当前任务的 stateful prompt，计算每个技能的相关性分数，选择 top-K 个技能进行组合，生成执行计划。
b.关键特性
路由器本身是可训练的，会随着使用越来越精准。
b.技能进化机制
a.进化阶段说明
技能不是一成不变的，会经历初始技能、使用反馈、反思改进、版本更新、新技能衍生等阶段。
b.版本演化示例
---
v1.0: 基础网页搜索
v1.1: 添加多来源验证
v1.2: 添加信息时效性检查
v2.0: 衍生出学术搜索和新闻搜索两个专用技能
---
c.无需更新参数的持续学习
a.传统方法流程
新任务 → 收集数据 → 微调模型 → 部署更新（几小时到几天）
b.Memento-Skills流程
新任务 → 执行并反思 → 更新技能文件（几秒钟）
c.核心逻辑
LLM 本身已经有足够的知识和推理能力，缺的是任务特定的行为模式、领域特定的知识组织、经验驱动的决策策略。这些都可以外部化为技能文件，不需要改动模型本身。
e.实际应用场景
a.企业客服Agent
a.痛点
每个客户问题都要重新配置，知识库更新慢。
b.方案
初始技能为 FAQ 查询和工单创建，学习过程中记录常见问题、优化回答模板。
c.结果
越用越懂业务，新人培训时间缩短 80%。
b.数据分析Agent
a.痛点
新数据集要重新配置，分析流程不统一。
b.方案
初始技能为数据加载和基础统计，学习过程中积累数据清洗规则和分析模板。
c.结果
标准化分析流程，新人也能做专家级分析。
c.个人助理Agent
a.痛点
不了解用户习惯，每次都要重新说明。
b.方案
初始技能为日程管理和邮件处理，学习过程中记录用户偏好、优化提醒策略。
c.结果
越用越懂你，真正个性化。
f.与现有方案对比
a.对比说明
以下为 Memento-Skills 与传统 Agent、Fine-tuning、RAG 的特性对比。
b.对比表格
特性 传统Agent Fine-tuning RAG Memento-Skills
学习新技能 重新配置 重新训练 更新知识库 自动学习
持续改进 否 有限 否 是
参数更新 - 需要 不需要 不需要
学习速度 - 慢（小时级） 中（分钟级） 快（秒级）
记忆持久化 会话级 模型级 数据库级 文件级
可解释性 低 很低 高 很高
g.开源信息
a.代码仓库
目前代码已开源，GitHub 仓库地址：https://github.com/Memento-Teams/Memento-Skills
b.快速开始
---
# 克隆仓库
git clone https://github.com/Memento-Teams/Memento-Skills.git
cd Memento-Skills
# 安装依赖
pip install -r requirements.txt
# 配置 API Key
export OPENAI_API_KEY="your-key-here"
# 运行示例
python examples/basic_agent.py
---
c.技能文件目录结构
---
skills/
├── web_search.md
├── terminal_ops.md
├── code_execution.md
└── custom_skills/
└── your_skill.md
---
h.局限性
a.技能质量依赖初始设计
如果初始技能设计不好 ，学习效果会打折扣，需要一定的领域知识来设计初始技能集。
b.技能冲突处理
当多个技能都适用时，如何选择最优组合，需要更智能的冲突解决机制。
c.长周期任务的学习
目前主要针对单轮或短周期任务，长周期任务的技能演化还需要研究。
d.安全性考虑
自动学习的技能可能包含错误，需要人工审核关键技能。
i.结语
a.思维范式转变
Memento-Skills 的意义不仅在于技术突破，更在于思维范式的转变：我们不再需要制造完美的 Agent，而是创造一个能自我进化的 Agent 系统。这就像从授人以鱼到授人以渔的转变，我们不再给 Agent 固定的能力，而是给它学习的能力。
b.未来展望
未来的 AI Agent，可能会像生物一样，通过经验不断进化，越来越适应它的环境和任务。
j.参考资料
a.论文
Memento-Skills: Let Agents Design Agents
b.代码
GitHub - Memento-Teams/Memento-Skills
c.相关工作
Memento 2: Read-Write Reflective Learning
c.MemPal：不一定是最好的记忆系统，但它是第一个把问题定义正确的记忆系统
a.MemPal项目介绍
MemPal（Rust版的MemPalace记忆宫殿），MemPalace是有趣的项目，它不一定是最好的记忆系统，但它是第一个把问题定义正确的记忆系统。
b.项目开源地址
MemPal（Rust版的MemPalace记忆宫殿）开源地址：https://zhanghandong.github.io/mempal/
c.Rust版本实现说明
Rust版本实现的取舍说明地址：https://zhanghandong.github.io/mempalace-book/ch26-why-rewrite-in-rust.html，该版本并非一比一的MemPalace移植。
d.使用反馈邀请
本地测试效果良好，现已发布供大家使用，欢迎提出改进意见。