一见

用 AI 写初稿、生代码、做方案，速度提升 5 到 10 倍。很多人据此判断：AI 已经能把事做完了。但真正交付的时候才发现——快的是前面，慢的是后面；省的是体力，费的是心智。从 0 到 90%（能跑通主流程）的效率爆炸和从 90% 到 100%（能上线扛住边界场景）的成本陡增之间，藏着一个吃掉所有收益的陷阱。

DeerFlow 给自己的定位不是"又一个 Agent 框架"，而是 Super Agent Harness。这个词不是随便用的——它意味着 DeerFlow 要解决的不是"Agent 能不能跑"，而是"Agent 能不能跑得住"。它和 Harness Engineering、Agent Team、Workflow 分别是什么关系？

本文介绍了如何将Agent团队从隐式编排（基于Skill文件组织）改造为显式编排（使用工具链调用）。核心差异在于通过四个工具函数实现团队生命周期的可见可控： 团队创建：用team_create显式建立团队容器，替代Skill加载时的隐式组建 成员派发：通过task逐个显式启动Agent，替代自动加载prompt文件 通信机制：使用send_message工具显式调用，替代prompt中的描述性规则 生命周期：通过shutdown_request和team_delete显式管理，避免隐式结束 显式编排虽然搭建

摘要： AI编程正从"单模型写代码"向"团队化开发"演进，关键在于三层工程基础设施： OpenSpec（规范层）：结构化定义需求、接口与验收标准，确保多Agent理解一致； Superpowers（纪律层）：通过TDD、代码审查等技能强制工程最佳实践，保障代码质量； Harness（协作层）：管理Agent分工、权限与任务调度，避免冲突。 三者协同形成完整开发体系：OpenSpec定目标，Superpowers控流程，Harness管执行。落地建议分步实施，优先规范与

本文会从一个真实项目出发，把 Sub-Agent 和 Agent Team 这两种架构模式掰开了讲清楚。同时也聊一个很多人容易混淆的问题：Agent Team 什么时候需要 API Key，什么时候不需要？这背后的区别到底是什么？

摘要： Harness Engineering是为AI Agent设计运行控制系统的工程学科，旨在通过构建约束、反馈和管理机制，确保Agent稳定、持久且不偏离目标地完成任务。其核心包括三大支柱：可读性（如AGENTS.md规范）、防御机制（硬约束确保行为合规）以及反馈学习（持续优化Agent行为）。这一方法论超越了传统的Prompt Engineering和Context Engineering，成为AI工程实践的新范式，尤其适用于复杂长周期任务的管理与优化。

大模型智能体开发核心要点 模型特性：大模型默认无跨请求记忆，上下文窗口有限，需显式提供历史信息 输出控制：通过系统提示词、知识检索、规则约束等可控因素优化输出质量 知识管理：区分SKILL（能力流程）、RULE（合规边界）和知识库（事实资料） 生效机制：文件需经索引构建、检索匹配、上下文注入等链路才能真正影响输出 工程实践：推荐模块化、结构化编写文档，明确适用场景和执行标准，避免模糊表述 智能体开发的核心是在约束条件下组织最优上下文，实现全流程任务管控，而非简单拼接Prompt。

AI浪潮席卷各行各业，从大模型巨头到智能体厂商，形成了清晰的金字塔格局。普通人无需盲目入局技术博弈，而应聚焦AI工具的应用和自身专业壁垒的打造。智能体终局将分化为手机端、PC端和云端三大战场，由头部厂商主导。随着AI普及，岗位替代和社会变局不可避免，但逃避无益，主动精进才是破局之道：既要掌握AI工具提效，又要深耕专业打造不可替代性。面对不可逆的技术趋势，理性应对、借力成长才是最优选择。

摘要：该图展示了AI Agent的典型架构，通过Agent中枢协调用户请求处理流程。系统整合任务理解、上下文管理、知识检索（RAG）、记忆存取及工具调用（MCP）等功能，将多源信息组装为大模型输入，完成推理后返回结果。相比单纯问答模式，该架构显著提升了AI的可执行性、上下文连贯性和系统扩展能力。图示清晰呈现了从请求输入到结果输出的完整处理链路。

当大多数人还在沾沾自喜于用AI写出了更优雅的函数时，软件开发的底层逻辑其实已经彻底变天了。AI不再是那个帮你提升效率的“副驾驶”，它正在成为效率本身。从“人写AI查”到“AI写人看”，再到如今的“AI全托管”，我们正在经历一场类似从“有安全员”到“驾驶位空置”的物种级跨越。

OpenSpec是一个轻量级规范驱动开发框架，旨在解决AI Agent时代的互操作性问题，让不同AI系统能够像互联网一样互联互通。其核心机制是通过标准化"契约"(Spec)明确输入输出，使AI Agent无需了解底层代码即可调用工具，类似乐高积木的标准化接口。 主要功能包括： 通过npm安装OpenSpec CLI工具 初始化工作区并配置工作流(如propose、explore、apply等命令) 使用/opsx:propose快捷创建变更并生成完整规划制品 或使用/opsx:new创建

摘要：WorkBuddy中将"Skill"称为插件，采用两阶段安装方式：首先将插件安装到指定市场目录（cb_teams_marketplace或codebuddy-plugins-official），然后通过修改settings.json配置文件启用插件。插件实际存放在市场的plugins子目录中，启用状态由settings.json中的enabledPlugins字段控制（true表示启用）。这种设计既分离了插件存储与启用机制，又支持自动化安装流程，只需完成文件拷贝和配置修改即可实现插

本文介绍了WorkBuddy与QQ机器人集成的完整配置流程：1)从官网下载安装WorkBuddy；2)在QQ开放平台申请机器人账号，需妥善保存AppID和AppSecret；3)扫码添加机器人好友；4)在WorkBuddy设置中输入机器人凭证完成对接；5)配置Webhook实现双向通信。完成上述步骤后，用户即可通过QQ与WorkBuddy进行交互操作。文中配有详细操作图示，并提示配置失败时的错误提示特征。

本文对比分析了两种AI智能体（豆包和OpenClaw）的核心差异。豆包采用反向代理模式，在云端处理用户请求，仅提供建议而不直接操作系统；OpenClaw则采用正向代理模式，安装在客户端，可远程控制用户本地设备执行操作。OpenClaw虽然能实现文件处理、系统命令执行等自动化功能，但存在严重的权限滥用、数据泄露等安全风险，架构类似"智能木马"。文章建议在使用这类工具时，需在便利性和安全性之间权衡，采取最小权限、操作审计等防护措施。

本文详细介绍了OpenClaw工具的安装配置流程，主要包括：1) 环境准备（Node.js安装和npm镜像配置）；2) OpenClaw安装与向导式配置；3) 常见配置问题解决方案；4) 浏览器插件安装与托管模式设置；5) QQBot插件安装与绑定；6) 重点讲解了QQBot插件的编译过程及常见错误处理方案；7) 工具权限配置说明；8) 使用注意事项。文章提供了完整的命令和配置示例，特别针对TypeScript编译过程中的各类错误给出了具体解决方案，并强调了权限最小化原则的重要性。

摘要：OpenClaw 2026.3.2版本默认仅开放消息权限（tools.profile=messaging），导致无法执行命令。本文详解如何通过修改配置文件（~/.openclaw/openclaw.json）中的tools.profile取值来调整权限范围：minimal（基础会话）、coding（文件

SKILL.md文件拆分的判断标准：当文件超过500行、存在独立使用场景、章节内容膨胀、维护成本高或需要独立版本管理时建议拆分。具体阈值：500-1000行考虑拆分，1000行以上强烈建议拆分，2000行必须拆分。拆分后应保持内容连贯性，避免过度拆分导致维护困难。不应拆分的情况包括内容高度相关、文件较小（<500行）或拆分会产生大量重复内容。合理的拆分方案可提升文档可维护性和用户体验。

本文档体系包含四种定位不同的文件：SKILL.md（操作指南）、rule.md（规则约束）、knowledge_base.md（背景知识）和prompt.md（AI交互示例）。当SKILL.md文件过大（超过1000行）、内容模块化明显或维护困难时，建议按功能拆分为多个子文件（如基础操作、高级功能等）。拆分标准包括文件行数阈值、独立使用场景、章节膨胀和维护成本等因素，但需避免拆分高度相关或小规模内容。合理的拆分能提升文档的可维护性和用户体验。

本文系统阐述了AI系统中Skill、Rule和Knowledge Base三者的定义、特征与关系。Skill作为可执行模块（200-500行），专注于"怎么做"；Rule作为强制性规范（500-1500行），界定"能不能做"；Knowledge Base作为背景知识库，解答"是什么"且无大小限制。三者协同工作：Skill执行需遵守Rule并参考KB。针对当前SKILL.md存在的混杂、过大和职责不清问题，建议进行职责分离重构，精简核心Skill步骤

智能体与工作流的区别主要体现在自主性和灵活性。智能体具备自主决策能力，能动态调整任务流程（如根据用户偏好增加优惠券查询步骤），适用于复杂场景；工作流则严格遵循预设步骤（如订单处理的固定流程），适合标准化任务。智能体像自主决策的项目经理，工作流则像工厂流水线。二者可协同工作，智能体负责决策，工作流执行固定步骤。核心差异在于：智能体具有环境感知和动态调整能力，而工作流仅能按预定流程执行。

大模型产业呈现清晰的"训练-推理-应用"三层架构：训练层由少数科技巨头垄断，依赖高端GPU集群完成千亿参数模型训练，涉及巨额成本和技术门槛；推理层通过API开放服务能力，厂商采用自研芯片优化性能；应用层基于推理API开发各类智能工具。这种架构既保障核心技术安全，又促进应用生态繁荣。训练环节封闭性确保模型安全和知识产权保护，推理环节开放性赋能广泛场景应用，形成完整的AI产业价值链。各层级在控制权、资源需求和技术复杂度上存在显著差异，共同推动大模型技术的持续演进和商业化落地。

本文介绍了AI系统中四个核心组件的功能分工：大模型LLM负责智能决策，基于权限结果输出；智能体Agent作为流程协调者，不涉及业务逻辑；图书馆MCP服务专门处理业务权限验证（"能做什么"）；认证服务则负责基础身份验证（"谁"），采用标准协议如OAuth2/JWT。文章通过架构图展示了各组件间的关系，强调认证服务由Agent直接调用，而非通过MCP中转。系统设计实现了功能解耦，确保权限验证与身份认证的清晰分离。

AI技术生态的三层架构：基础能力层由少数头部团队研发大模型（如DeepSeek、文心一言等），提供核心认知与生成能力；场景执行层通过智能体（Agent）实现行业应用落地，如写作、健康管理等解决方案；生态工具层则包含大量MCP服务（如数据库、图像处理工具），为上层提供标准化支持。该体系呈现技术难度逐层递减、参与规模递增的"金字塔"结构。

摘要：谷歌《Attention Is All You Need》论文提出的Transformer架构与多头注意力机制，同GFS、MapReduce、Bigtable三大数据论文一样具有划时代意义。Transformer通过摒弃传统RNN/CNN，实现了并行计算和长序列建模，奠定大模型基础，推动AI领域革命；而三大数据论文则开创了分布式存储与计算范式，催生大数据生态。二者均实现"从0到1"的范式创新，前者重塑AI发展路径，后者奠定大数据技术基石，共同推动产业变革。（149字）

摘要：大模型、智能体和MCP服务形成多对多协同关系。大模型作为"大脑"提供认知能力，智能体作为"身体"协调任务执行，MCP服务则作为"四肢五官"完成具体操作。三者密切配合：一个大模型可服务多个智能体，智能体通过多个MCP服务完成任务，MCP服务也能支持多个智能体和大模型。这种架构通过标准化协议实现高效协同，共同满足用户需求，体现了分布式智能系统的协作优势。(149字)

Ollama 是一款本地运行大模型的工具，用来部署和运行 DeepSeek，从下载 Ollama。