崔安兵的博客

给小白看懂：Skill / Agent / 多Agent协同 / MCP / LLM / AI应用，是什么？各自干嘛？基础分层总览（先记住这条链） LLM（底层大语言模型）：推理底座，“大脑”，只会读文本、续写文本；没有工具、没有记忆、没有流程调度。 Skill：单任务静态SOP手册，定义【什么时候触发、步骤、输出格式、红线约束】，纯描述性规则包。 Agent（单智能体）：具备循环规划+反思+多步执行能力的智能体，可以自己拆分子任务、判断下一步、循环执行。 多Agent协同：由多个职责独立的Agent组成协作团队，分工配合、互相通信，共同完成大型目标。 MCP（Model Context Protocol）：标准化协议层，解决「LLM/Agent怎么统一调用外部工具、外部资源」，相当于工具通用接口规范。 AI应用（豆包 / Codex / ChatGPT客户端等）：载体，提供会话、文件、工具调用、组件调度能力，把各种组件串起来。 一句话极简关系： LLM是大脑；MCP是统一工具总线；Skill是单...

AI Skill 工作流沉淀：从重复提示词到可复用系统如何把脑子里重复的做事方法，沉淀成一套 AI 可以稳定执行的 Skill 系统——从识别工作流、拆解步骤、编写 SKILL.md、三案例测试到上传 GitHub 的完整实操路线。 一句话总结提示词解决一次任务，Skill 固化一类任务。本文带你从零开始，把重复无数次的AI对话沉淀成一套可安装、可测试、可分享的个人工作流。如果你每周都要把同一段要求重新发给AI，这篇文章就是写给你的。 举个例子：每周五你都要告诉AI：「先整理本周成果，再提炼问题和经验，最后列出下周行动。不要编造数据，每个行动都要有完成标准。」 单次使用叫提示词；每周重复使用，背后已经是一套固定工作流。 把这套工作流整理成文件夹，让AI遇到同类任务就知道何时接手、按什么步骤执行、输出达到什么标准，这就是 Skill。 什么是 Skill？把AI编程助手想象成能力很强，但刚入职的新同事。它懂代码、写作、分析，但不知道： 在什么场景启动某项工作 你的执行先后习惯 哪些规则绝对不能违反 输出必须包含哪些栏目 做到什么程度才算合格 Skill = 岗位说明...

A2A（Agent2Agent）详解引言Agent2Agent 协议（简称 A2A）由 Google 于 2025 年 4 月提出，是面向多 Agent 协作的开放协议。如果说 MCP 解决的是”一个 Agent 怎么调用工具”，那么 A2A 解决的是”一个 Agent 怎么发现另一个 Agent、把任务交过去、再拿回结果”。 本文是 A2A 的专题详解，读完你会掌握： 多 Agent 协作到底难在哪里； Agent Card 如何让 Agent 互相”被找到”； Task 的完整生命周期与状态机； Message 与 Artifact 在协作中扮演什么角色； 一次完整的 A2A 协作流程如何走通； 它适合解决哪些问题。 前置知识：了解 Agent 和 LLM 基本概念即可。文中事实以官方规范为准，个人理解处会明确标注。 要解决的问题：让 Agent 能”找到彼此并接力”当一个系统里只有一个 Agent 时，事情很简单——它只管自己干活。但当系统里有多个独立部署、由不同团队维护的 Agent 时，问题就来了： 一个”招聘 Agent”想调用”简历解析 Agent”，它怎么知...

A2A 与 MCP：两种 AI Agent 互联协议解析与选型引言做 AI 应用的人这两年绕不开两个缩写：MCP（Model Context Protocol）和 A2A（Agent2Agent Protocol）。它们都由头部厂商提出，都被冠以”开放标准”，却常常被混为一谈。很多人以为它们是同类竞品，其实两者解决的是完全不同的问题。 读完本文你会明白： MCP 解决的是「模型如何调用外部工具和数据」，管的是单体 Agent 的能力接入； A2A 解决的是「一个 Agent 如何找到并协作另一个 Agent」，管的是多 Agent 之间的互联； 两者不是二选一，而是经常叠加使用，各自负责协议栈的不同层次。 本文面向已经了解 LLM 基本概念、准备搭建 Agent 系统的开发者。文中事实以官方文档与规范为准，个人理解处会明确标注。 背景：为什么 Agent 需要协议先看一个演进过程。最早的 LLM 应用是”问答机”：模型吃 prompt，输出文本。很快大家发现模型不会查数据库、不会调 API，于是有了 Function Calling——模型按 JSON Schema 声明”我...

MCP（Model Context Protocol）详解引言Model Context Protocol（模型上下文协议，简称 MCP）由 Anthropic 于 2024 年 11 月发布，是 AI 生态里连接”模型”与”外部世界”的事实标准之一。做 Agent、做 AI 应用的人都会遇到它。 本文是 MCP 的专题详解，读完你会掌握： MCP 到底解决了什么痛点； Host / Client / Server 三角色与 Tools / Resources / Prompts 三类原语； 一条请求从模型到外部工具完整走一遍的生命周期； 它支持哪些传输方式、版本如何演进； 一个可直接运行的最小 MCP Server 示例。 前置知识：了解 LLM 的基本概念即可。文中事实以官方规范为准，个人理解处会明确标注。 要解决的问题：告别”每家一套适配层”在 MCP 出现前，让模型调用外部能力主要靠两种方式： Function Calling：模型按 JSON Schema 声明想调的函数，应用端手写逻辑去执行。问题是每接一个工具都要写一遍适...

大单体应用量化判定线设定很多团队在做微服务拆分、架构评审的时候，都会遇到同一个难题：什么是单体、什么时候算过大单体？ 大家嘴上都认同 “避免大单体应用” 这个原则，但评审会上经常变成主观辩论：有人觉得当前服务刚好合适，有人一看就觉得太重了，却拿不出明确标尺，最后要么凭经验拍板，要么干脆搁置拆分决策。 定性原则是底线，但没有量化判定线，架构治理就没有抓手。本文整理一套可直接放进架构评审清单的量化指标，覆盖代码、领域模型、数据、运行时、变更、团队六个维度，区分预警线与红线，同时配套使用约束、争议案例，让评审有据可依。 前置说明：指标是判定参考标尺，不是硬性拆分触发器。指标触达预警线，启动架构复盘、评估拆分必要性；触达红线，必须给出改造计划；业务稳定、变更极低的遗留系统可以单独豁免，不能一刀切。 术语对齐：大单体判定，核心区分【部署单体】（一个进程/一个部署包）和【逻辑单体】（边界混乱、多个限界上下文揉在一起，哪怕拆成多个进程也是分布式单体）。下面指标同时覆盖部署层、代码层、数据层、领域层。 一、代码层指标（单个部署单元） 指标项 预警线 红线（强论证线） 备注 ...

AI Coding时代，为什么业务能力才是程序员的核心护城河大多数技术同学，骨子里都会偏爱技术本身，而对业务提不起兴趣。我曾经也是这样。过去很长一段时间，我都默认理解业务是产品、运营的责任，开发只需要接收需求，产品提什么，我们就实现什么。这是学生时代遗留下来的惯性思维：把开发当成纯粹的代码实现工作，追求写出优雅的代码、掌握前沿框架，一心想做纯粹的技术项目，打造受人关注的开源作品，这也是当初我踏入开发领域最原始的动力。 直到读完于江水前辈《我在淘宝做前端的这三年》系列文章，我的想法发生了根本性转变。文中一段话让我醍醐灌顶：“业务能力应该是程序员除了技术之外，最具价值的能力，也是最必要的。因为技术本身很难赚钱，业务落地才能赚钱。当程序员具备了业务和产品能力，才可能选取业务和技术的折中点，又快又好的支撑业务，带来价值和效益。懂产品和业务（甚至交互设计）的技术，更容易跟其他工种进行沟通，用通俗易懂的方式介绍技术实现和难度，可以提升在企业中的自身地位和价值。此外，对于架构师，理解业务也是必备能力。” 这段话放在当下AI Coding快速普及的时代，有着比过去更强的现实意义。如今Cursor...

FontAwesome-Free 图标缺失问题排查与解决方案一、问题背景项目前端采用 @fortawesome/fontawesome-free 免费版作为图标依赖，开发过程中出现部分图标渲染失败，页面显示空白方框、问号占位符。经排查，核心根源是混淆了 FontAwesome Free 免费版与 Pro 专业版的能力边界。很多 UI 设计稿、原型工具里直接选用 Pro 专属图标与样式，开发直接复制 class 到项目，而当前项目仅引入 free 包，最终导致图标找不到。 简单回顾两者核心差异： 1. 图标数量与样式（核心差别） fontawesome-free（免费版） 图标总数约 2000+（v6/v7）；只支持 Solid（实心）、Regular（常规空心少量）、Brands 品牌图标 三种。 ✅ 全部品牌图标（微信、github、抖音等品牌 logo 图标免费开放） ❌ 没有 Light、Thin、Duotone 双色、Sharp 锐利系列，大量图标缺失，很多图标只有 solid 实心样式，没有细线条版本Font Aweso… fontawesome-pro（Pr...

职场人如何靠本职工作积累财富 原文链接：https://asheradeniyi.com/2026/04/10/how‑to‑build‑wealth‑as‑a‑career‑person/发布时间：2026‑04‑10翻译时间: 2026年10月19日 有一种很普遍的观点：巨额财富大多只属于创业者。我们总是追捧创始人、投资人、企业老板，以至于很多职场打工人会产生一种错觉 —— 上班只是用来糊口谋生，只有自己当老板才是实现财富自由的唯一出路。 但我并不认同这个看法。我身边不少朋友，就是依靠一份普普通通的全职工作，搭建起了可观的个人财富。他们当中，有的人名校出身，优秀的学业成绩帮他们叩开了优质企业的大门；也有些人并没有亮眼的成绩单，但他们修炼出一些比一纸成绩单更加重要的特质。时间久了我发现，这两类人中发展最好的那群人，身上有着很多共通特质。 他们拥有坚韧的毅力。不是被动等待工作安排，而是主动创造结果；以解决问题、快速学习、拿得出实绩为人所知。趁着职业生涯早期精力充沛，不断打磨专业能力，积累个人口碑，能力辐射不再局限于自己所在部门。坚持持续学习，既有系统的正式学习，也有碎...

先叠甲，我不是工贼。但是要是真有人这么认为，我只能说大家对自己人生的立场不同，观念不同，追求不同。再其次工作得是自己喜欢的最好，兴趣胜过一切。 职场感悟：拿三千薪资，要具备八千的做事心态 作为一名从业多年的 IT 架构师，见过大量开发人员的成长与掉队。技术圈同样存在一种很现实的认知误区：工资给多少，我就干多少活。但职场不是菜市场，你输出多少价值，才配拿到多高的薪资。 那句很扎心的开发圈潜台词团队里曾经来过一位初级开发，交付的模块 bug 一堆，边界场景完全没考虑，接口文档残缺不全。我组织评审指出一堆问题，对方回了一句让我印象很深的话： “我就拿这点工资，你还指望我做到什么程度？” 乍一听似乎很公平，等价交换，拿多少钱办多少事。但职场不是菜市场，如果你只输出三千块的代码质量，公司永远不会给你八千的薪资。薪资是价值的结果，而不是做事的前提。 回想我刚入行的时候，薪资同样不高。但每次接到需求，除了完成产品明确要求的实现版本，我还会额外输出两套备选方案：一套严格按照需求落地，另一套是我结合系统现状思考的优化方案，包含性能、可扩展性、异常兜底的考量，交给上级做选择。 当时并没有刻意算计升...