Markdown 作为一种轻量级标记语言，因其简洁、易读、易写的特性，已成为文档撰写、学术写作、知识管理及技术博客的首选格式。市场上针对不同使用场景的编辑工具层出不穷，本文挑选了数款最具代表性的热门工具，从学术研究、知识管理到沉浸式写作进行深度解析。 1. Zettlr：专为学术研究与卡片盒笔记而生 如果你需要撰写学术论文、研究报告或处理大量参考文献，Zettlr 是一款不可多得的学术级 Markdown 编辑器。它在设计之初就融入了“卡片盒笔记法”（Zettelkasten），旨在无缝连接写作与文献管理。 官方地址：https://www.zettlr.com/ 开源状态：完全开源（GPL-3.0 协议） 价格模式：完全免费 核心亮点： 深度文献集成：原生支持无缝对接 Zotero、JabRef 等文献管理工具，可直接插入 BibTeX 引用格式与生成脚注。 学术导出扩展：基于 Pandoc 引擎，支持将文档导出为 PDF、Word、EPUB 及 LaTeX 等多种格式，满足期刊排版要求。 自动化辅助：内置番茄钟、拼写检查以及自定义代码片段功能，大幅提升长时间写作的效率。 适用人群：学者、研究生、科技文章创作者及卡片盒笔记法实践者。 2. Obsidian：基于本地文件的网状知识库 Obsidian（黑曜石）不仅是一个 Markdown 编辑器，更是一个打造“第二大脑”的个人知识管理系统。它以双向链接（Bi-directional Links）和本地纯文本存储为核心理念。 官方地址：https://obsidian.md/ 开源状态：闭源 价格模式：个人免费（商业使用需付费，另提供官方付费同步 Obsidian Sync 服务） 核心亮点： 关系图谱（Graph View）：以可视化图形展示笔记之间的双向链接关系，帮助发现潜在的思维交集与知识联系。 强大的插件生态：拥有极度活跃的社区，提供数千种插件（从 Kanban 画布、Dataview 数据库查询到 AI 联动），扩展性极强。 数据自主控制：所有文档均以纯文本 Markdown 格式保存在本地硬盘中，不受平台锁定限制，隐私安全性极高。 适用人群：构建知识体系的研究者、开发者、个人资料整理狂人及重度笔记用户。 3. Typora：极致无缝的“所见即所得”标杆 如果你追求极致纯粹的写作体验，不希望被左侧代码、右侧预览的分屏布局分散注意力，Typora 无疑是“所见即所得”（WYSIWYG）领域的行业标杆。 官方地址：https://typora.io/ 开源状态：闭源 价格模式：买断制收费（买断约 $14.99，提供 15 天免费试用） 核心亮点： 实时无缝预览：输入 Markdown 语法后会自动渲染为最终视觉样式，既保持了排版的美观，又保留了纯文本的精简。 富文本增强支持：内置极佳的表格编辑交互，支持画图引擎（Mermaid）、LaTeX 数学公式渲染以及优雅的代码高亮。 高度自定义主题：支持加载不同的 CSS 主题，方便导出极具视觉美感的 PDF 或 HTML 文档。...

使用 AI Agent 时，经常会遇到这样的情况： 你让 Agent 分析一个项目，它先读取文件，再分析代码，然后准备修改几个文件。等了半天，你突然发现需求说错了，于是点击「停止」。 普通聊天中，停止生成文字通常就够了。但 Agent 不一样，它可能正在调用模型、执行工具、读写文件，甚至请求外部 API。 这时，一个问题就出现了：用户点击停止之后，Agent 真的停下来了吗？ 如果只是让前端不再显示回答，后台任务可能还在运行。如果只停止当前模型请求，Agent 也可能在下一步继续调用工具。 因此，任务取消不是简单地增加一个停止按钮，而是需要让 Agent 的整个执行过程都能响应取消操作。 一、为什么 Agent 不能简单地停止生成？ 先看一个常见的 Agent 执行过程： 用户提出需求 ↓ AI 分析任务 ↓ 调用搜索工具 ↓ 分析搜索结果 ↓ 调用文件处理工具 ↓ 整理结果 ↓ 返回回答 Agent 并不是一次性生成答案，而是根据每一步的执行结果，决定接下来做什么。 例如，用户让 Agent「搜索资料并生成一份报告」，它可能先搜索网页，再读取内容，最后生成报告。每一步都可能涉及新的模型请求或工具调用。 如果用户在搜索过程中点击停止，系统至少要解决三个问题： 不再发起新的模型请求。 不再启动新的工具调用。 尽可能停止已经运行的模型请求和工具任务。 前两个相对容易，第三个则取决于具体操作是否支持取消。 例如，正在执行的本地任务可能可以主动检查取消状态；已经提交给第三方服务的任务，则未必能被立即终止。 所以，停止 Agent，不只是停止它说话，还要阻止它继续做事。 二、给 Agent 一个「停止信号」 可以把 Agent 想象成一个正在执行任务的员工。 用户点击「停止」，就相当于通知这个员工：「先别继续做了。」 但光发出通知还不够。员工需要在工作过程中留意这条通知，收到后停止接下来的工作。 在程序中，这种通知可以通过「取消信号」实现。 以 JavaScript 为例，浏览器和 Node.js 都提供了 AbortController，可以用它发出取消信号。 const controller = new AbortController(); // 把信号传给支持取消的任务 const task = fetch("/api/agent/run", { method: "POST", signal: controller....

做一个自己的产品，真正花钱的地方其实很多。 代码托管、服务器、数据库、对象存储、邮件、监控、数据分析、设计、支付……如果每个环节都选择一个收费服务，一个还没验证需求的 MVP 很容易先产生一笔固定成本。 下面整理一套比较实用的全球独立开发者低成本套餐。 代码管理 + CI/CD 推荐： GitHub 个人开发项目基本可以直接使用 GitHub。 可以解决： Git 仓库 Issue Pull Request Release Actions 项目 Wiki 自动构建 自动部署 GitHub Free 支持无限公开和私有仓库，个人账户还包含 GitHub Actions 等能力。 如果是个人项目，没有必要一开始就购买 GitLab、Bitbucket 等商业套餐。 一个 GitHub 仓库就可以把： 代码 + Issue + CI/CD + Release + 项目文档 全部串起来。 部署 + CDN 推荐： Cloudflare Vercel 如果是静态网站、博客、Landing Page、前端项目，Cloudflare 和 Vercel 都非常适合。 Cloudflare Workers Free 目前提供每天 10 万次请求，适合部署一些轻量 API、Webhook、定时任务和边缘逻辑。 Cloudflare 还有： CDN DNS DDoS 防护 Workers Pages D1 KV R2 Queues Turnstile 对于独立开发者来说，Cloudflare 最大的优势不是单独某一个服务，而是可以把很多基础设施放在一起。...

随着 AI Coding 和 Agent 的发展，Skill 正逐渐成为扩展 Agent 能力的重要方式。 一个 Skill 通常由 SKILL.md 以及可选的脚本、参考资料和资源文件组成，用于把某一类任务的知识、流程和经验封装起来，让 Agent 在需要时加载并执行。Agent Skills 目前已经形成开放格式规范，并支持通过渐进式加载机制减少不必要的上下文消耗。 如果你正在学习 Agent Skills，或者已经开始使用 Claude Code、Codex、Cursor 等 AI 编程工具，下面这些资源值得收藏。 一、 学习与官方资源 Agent Skills 官方规范 地址：https://agentskills.io/ 介绍：Agent Skills 的官方开放规范，介绍 Skill 的基本结构、SKILL.md、元数据、资源目录以及 Progressive Disclosure，是学习 Skills 最值得优先阅读的资料。 Agent Skills GitHub 地址：https://github.com/agentskills/agentskills 介绍：Agent Skills 开放规范的官方 GitHub 项目，可以查看规范源码、文档和相关示例，也适合跟踪规范的后续发展。 Anthropic Skills 地址：https://github.com/anthropics/skills 介绍：Anthropic 官方 Skills 仓库，提供文档处理、PDF、Excel、PowerPoint 等实际 Skill，可以直接参考成熟 Skill 的目录结构和编写方式。 Claude Agent Skills 地址：https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview 介绍：Claude 官方 Skills 文档，介绍 Skills 的工作机制、创建方式、API 使用方法以及安全注意事项。...

AI 编程工具本身已经具备代码生成、代码修改和 Agent 执行能力，但真正进入实际开发后，往往还需要搜索、浏览器调试、文档查询、代码检查、规范管理等额外能力。 这些能力可以通过 MCP、IDE 插件和 Skill 等扩展方式接入 AI 编程工作流。下面整理一批比较实用的工具，方便按需选择。 一、 MCP 服务器类 Firecrawl MCP 地址：Firecrawl 介绍：网页内容抓取工具，可以让 AI 搜索、抓取和理解网页内容，适合获取技术文档、博客、竞品网站等外部资料。 Brave Search MCP 地址：Brave Search API 介绍：为 AI 提供联网搜索能力，可以搜索网页、新闻、图片等内容，适合需要实时互联网信息的开发任务。 Context7 地址：Context7 介绍：专门为 AI 提供最新的技术文档和代码示例，可以减少 AI 使用过时 API 或错误用法的问题，尤其适合框架和第三方库开发。 Web to MCP 地址：Web to MCP 介绍：可以将网页中的组件和页面信息转换为 AI 可使用的上下文，适合前端开发、网页复刻和 UI 分析。 Chrome DevTools MCP 地址：Chrome DevTools MCP 介绍：将 Chrome DevTools 能力提供给 AI，可以进行浏览器操作、网络请求分析、性能分析、页面调试和自动化测试。 EdgeOne Pages MCP 地址：EdgeOne Pages 介绍：将 EdgeOne Pages 部署能力接入 AI，可以辅助完成网站部署、HTTPS 和 CDN 配置等工作。...

AI Agent 的基本模型： Agentic Coding ↓ Context Engineering ↓ MCP ↓ Tool Design ↓ Agent Loop 但还有一个问题没有解决： Agent 知道有哪些工具，也知道怎么调用工具，为什么它还是经常“不知道应该怎么做”？ 例如让 Agent 完成一次代码 Review。 它可能拥有： git_diff read_file search_code run_test 这些 Tool 已经足够让它操作代码库。 但它仍然需要知道： 先看什么？ 重点检查什么？ 什么问题值得报告？ 如何判断问题严重程度？ 什么时候应该运行测试？ 最终应该如何输出？ 这些内容既不是 Tool，也不是 MCP。 它更接近一种： 任务级的知识、流程和操作规范。 这就是 Agent Skill。 今天的 Agent Skills 已经不只是某个产品里的一个概念，而是正在形成一个开放的文件格式和生态。官方规范将 Skill 定义为一个包含 SKILL.md 的目录，可以进一步携带脚本、参考资料和其他资源，并通过 Progressive Disclosure 按需加载。 1. Skill 到底是什么？ 先给出一个比较工程化的定义： Skill 是围绕某一类任务封装的可复用知识、操作流程、规则、示例和辅助资源，让 Agent 能够以更加稳定和一致的方式完成这类任务。 例如： code-review 不是一个具体的 Tool。 它可能包含：...

前面几篇文章分别了解了 Agentic Coding、Context Engineering、MCP 和 MCP Tool Design。 把这些内容放在一起，就会出现一个更核心的问题： AI Agent 到底是怎么“行动”的？ 我们经常看到这样的描述： 用户： “帮我分析一下这个项目的问题，并修复它。” Agent： 读取代码 → 分析问题 → 修改代码 → 运行测试 → 发现错误 → 再次修改 → 重新测试 → 完成任务 看起来像是 AI 在「自主工作」。 但从工程角度看，它并不是一个神秘的黑盒。 Agent 的核心其实可以抽象成一个不断循环的过程： 理解任务 ↓ 观察当前环境 ↓ 决定下一步行动 ↓ 调用 Tool ↓ 获得结果 ↓ 更新 Context ↓ 再次判断 ↓ …… ↓ 任务完成 也就是说： Agent 最核心的能力，不是一次生成一个答案，而是能够根据环境反馈持续决定下一步应该做什么。 1. 从一次 LLM 调用开始 最简单的 LLM 应用其实非常直接： User ↓ Prompt ↓ LLM ↓ Response 例如：...

上一篇文章介绍了 MCP 的基本原理。 MCP 真正有价值的地方，并不是「把一个 API 包装成 Tool」这么简单。对于 AI Agent 来说，一个 Tool 本质上是一份让模型理解外部能力的接口契约。 传统 API 主要服务于程序员和程序。开发者知道接口文档在哪里、参数是什么意思、什么情况下应该调用哪个接口。 Agent 不一样。 Agent 必须根据当前任务、上下文以及 Tool 的描述，自主判断： 这个 Tool 能不能解决当前问题？ 应该什么时候调用？ 参数应该怎么填写？ 哪些参数必须提供？ 调用结果意味着什么？ 如果调用失败，应该怎么修正？ 因此，一个功能正确的 Tool，并不一定是一个好 Tool。 Anthropic 在 2025 年发布的 Tool Engineering 实践中也明确强调：Agent Tool 应该按照 Agent 的使用方式进行设计，而不是简单地把传统软件 API 原样暴露给模型。 这也是 MCP Tool Design 最值得关注的地方。 1. Tool 不是普通函数，而是给 Agent 使用的接口 假设我们有一个获取用户信息的 API： GET /api/users/{id} 传统程序调用它非常简单： $user = $client->getUser(10086); 程序员知道： 10086 是用户 ID。 但是 Agent 看到的可能只是一个 Tool：...

在上一篇《Context Engineering》中，我们讨论了一个问题： Agent 想要把事情做好，不仅需要一个足够强的模型，还需要正确的 Context。 但 Context 解决的主要是「让 Agent 知道什么」。 还有一个问题没有解决： Agent 怎么真正去做事情？ 例如，一个 Coding Agent 需要读取代码、修改文件、执行测试；一个企业 Agent 需要查询数据库、读取 CRM、发送邮件；一个知识库 Agent 需要搜索文档、查询向量数据库。 最直接的办法当然是给 Agent 接 API。 但当工具越来越多，问题很快就出现了。 每个 AI 应用都有自己的工具接入方式，每个工具都有自己的参数定义和调用方式。开发者需要为不同的模型、不同的 Agent、不同的应用重复做适配。 MCP 正是在这样的背景下出现的。 MCP 全称是 Model Context Protocol（模型上下文协议），是一个用于标准化 AI 应用与外部系统连接的开放协议。官方文档目前将它定义为连接 AI 应用与外部系统的开放标准，并围绕 Tools、Resources、Prompts 等能力建立协议规范。 如果把 Agent 看成一个需要不断获取信息和执行操作的软件，那么 MCP 解决的核心问题可以简单概括为： 如何用一种标准方式，让 AI 应用发现、理解并使用外部能力。 1. AI Agent 为什么需要“工具协议” 先不考虑 MCP。 假设我们正在开发一个 AI Agent，它需要操作 GitHub。 最简单的方式是： Agent ↓ GitHub API ↓ GitHub 然后我们又希望它能够查询 MySQL：...

如果你使用过 Cursor、Claude Code 或其他 AI Coding 工具，应该遇到过这样的情况： 同样一个模型，同样一句需求，在一个项目里表现很好，换到另一个项目却经常答非所问。 你让它修改一个接口，它改错了文件；让它增加一个功能，它没有遵守项目现有的架构；明明项目里已经有一个工具类，它却重新写了一套；甚至你已经告诉它某个规则不能违反，它还是会继续这么做。 很多时候，问题并不是模型不会写代码。 而是它不知道足够多的东西。 这也是 Context Engineering 开始受到关注的原因。 如果说 Prompt Engineering 关注的是「我应该怎么告诉模型」，那么 Context Engineering 更关注：为了让模型完成任务，我到底应该让它知道什么？ 这两个问题看起来很接近，但面对复杂 Agent 时，区别会越来越明显。 1. Prompt Engineering 解决什么问题 Prompt Engineering 并没有过时。 在简单任务中，一个好的 Prompt 仍然非常重要。 例如： 请把下面的 方法重构一下： 要求： 1. 保持接口兼容； 2. 降低数据库查询次数； 3. 增加异常处理； 4. 给出修改后的代码。 这里已经包含了任务、约束和输出要求。 对于一次性的文本生成、代码生成、总结、分类等任务，这样的 Prompt 通常已经足够。 但软件开发中的很多任务并不是一次性的。 例如： 给这个项目增加用户注册功能。 这句话真正包含的信息其实非常少。 Agent 要完成它，至少还需要知道： 项目是什么框架？ 目录结构是什么？ Controller 怎么写？ Service 怎么写？ 数据库表在哪里？ Model 怎么定义？ 验证规则是什么？ 异常怎么处理？ 返回格式是什么？ 认证体系是什么？ 测试怎么写？ 哪些代码不能修改？ 如果这些信息没有进入 Agent 的上下文，那么你即使把 Prompt 写得再漂亮，也很难得到稳定的结果。...