NoirElaina

交互内容实验室：MDX、Vue、Mermaid、ECharts 与 Canvas

Mon, 11 May 2026 00:00:00 GMT

import MermaidDiagram from "../../components/mdx/MermaidDiagram.vue"; import EChartsPanel from "../../components/mdx/EChartsPanel.vue"; import CanvasMotion from "../../components/mdx/CanvasMotion.vue";

export const publishingFlow = flowchart LR A[写作想法] --> B[起草 MDX 文章] B --> C[引入 Vue 组件] C --> D[本地预览] D --> E[发布到博客] E --> F[读者看到图表与动画];

export const hydrationSequence = ` sequenceDiagram participant User as User participant Page as Astro Page participant Vue as Vue Island participant Chart as ECharts

User->>Page: Open post
Page->>Vue: Hydrate imported component
Vue->>Chart: Initialize chart instance
Chart-->>User: Render interactive visual

export const trafficTrendOption = { grid: { top: 40, right: 20, bottom: 30, left: 44, }, tooltip: { trigger: "axis", }, xAxis: { type: "category", data: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"], boundaryGap: false, }, yAxis: { type: "value", }, series: [ { name: "Visits", type: "line", smooth: true, data: [120, 182, 191, 234, 290, 330, 410], areaStyle: {}, lineStyle: { width: 3, }, }, ], animationDuration: 1200, };

export const categoryOption = { tooltip: { trigger: "item", }, legend: { bottom: 0, }, series: [ { name: "Posts", type: "pie", radius: ["38%", "68%"], avoidLabelOverlap: true, itemStyle: { borderRadius: 10, borderColor: "#fff", borderWidth: 2, }, label: { show: true, formatter: "{b}\n{d}%", }, data: [ { value: 12, name: "AI" }, { value: 18, name: "Frontend" }, { value: 8, name: "Notes" }, { value: 6, name: "DevOps" }, ], animationDuration: 900, }, ], };

export const systemHealthOption = { grid: { top: 24, right: 20, bottom: 30, left: 44, }, tooltip: { trigger: "axis", }, xAxis: { type: "category", data: ["API", "Search", "Images", "Deploy", "Comments"], }, yAxis: { type: "value", max: 100, }, series: [ { type: "bar", barWidth: "46%", data: [98, 92, 88, 95, 76], animationDuration: 1000, }, ], };

交互内容实验室

这篇文章的重点不是“介绍 MDX 是什么”，而是直接验证一件事：

现在这个博客已经可以在文章内容里直接引入 Vue 组件。

也就是说，后面你不只是能写普通段落、图片和代码块，还可以把图表、流程图、交互可视化、Canvas 动画直接塞进文章正文。

基础内容能力

在接入 MDX + Vue 之前，这个博客本来就已经支持一批很适合写长文的基础表达能力。这些内容我也一起合并到这篇文章里，方便以后拿它当总样板。

标题层级、强调与链接

正文里支持粗体、斜体、~~删除线~~、行内代码、超链接这些基础表达。

四级标题示例

长文章里把内容拆成多层标题后，右侧目录会更好用，文章结构也会更清楚。

列表、引用与表格

无序列表：

适合整理要点
适合快速扫读
适合做摘要

有序列表：

定义主题
拆出结构
补齐细节

引用：

好的内容页不只是堆信息，而是让文字、图表和交互都能顺着叙事往前走。

能力	当前状态	适合展示什么
Markdown 基础格式	已支持	博客正文、笔记、教程
Mermaid	已支持	流程图、时序图、架构图
ECharts	已支持	折线图、柱状图、饼图、仪表盘
Canvas	已支持	背景动效、自由动画、可视化实验
图片灯箱	已支持	截图、封面、插图
页面切换动画	已支持	页面跳转过渡

图片、提示块与公式

普通 Markdown 图片：

原生 HTML 图片：

:::note 这篇文章现在既是内容能力展示页，也是交互组件实验页。 :::

:::tip 以后你写新文章时，可以直接从这里复制需要的段落、图表和组件用法。 :::

:::warning 如果文章里塞很多大型交互组件，首屏体积会明显上升，最好按模块控制加载方式。 :::

行内公式示例：阅读时间可以近似写成 $t \approx \frac{w}{r}$。

块级公式示例：

$$ T = \lceil W / 200 \rceil $$

代码块与嵌入内容

type Feature = {
  name: string;
  enabled: boolean;
};

const features: Feature[] = [
  { name: "mermaid", enabled: true },
  { name: "echarts", enabled: true },
  { name: "canvas", enabled: true },
];

console.log(features.filter((item) => item.enabled));

pnpm install
pnpm dev
pnpm check
pnpm build

这个主题也能容纳 iframe 内容：

</iframe>

Mermaid：流程图 / 时序图 / 架构表达

Mermaid 很适合在文章里放流程、调用链、系统关系图。

下面这个是时序图示例：

ECharts：折线图、柱状图、饼图

图表这部分现在也已经适合直接进文章了。你只需要在 MDX 里准备一个 option 对象，再把它传给组件。

ECharts 本身就自带动画能力，所以像数值过渡、柱状图生长、折线缓动这些效果，不需要你额外再造一套轮子。

Canvas：更自由的视觉动画

如果你想要的不是标准图表，而是更自由的视觉效果，比如背景动效、粒子、波浪、轨道动画，那就更适合用 Canvas。

这种方式很适合做：

文章头部的氛围动画
项目页里的可视化背景
数据故事里的轻量交互效果
不适合用标准图表表达的动态内容

这套写法以后怎么用

以后你写文章时，大概就是这个工作流：

新建 .mdx 文章
在文件顶部 import 你要用的 Vue 组件
在正文里像写普通标签一样直接插入组件
用 client:load、client:visible 这类指令控制 hydration 时机

适合继续扩展的方向

既然现在已经走到 MDX + Vue 了，后面你还可以继续加：

可交互的时间线组件
代码执行结果可视化组件
音频频谱或波形组件
地图、网络拓扑、节点关系图
带参数控制面板的小型 Demo

如果你愿意，我下一步可以继续帮你把这套能力再往前推一层，比如：

做一个统一的 ChartCard / DiagramCard 组件库
给文章增加可折叠 Demo 区
做一个专门展示所有交互组件的实验页

我的第一篇文章

Sun, 10 May 2026 00:00:00 GMT

你好，欢迎来到这里

这是我博客里的第一篇文章。

这个站点会慢慢记录一些我想留下来的内容，比如：

开发过程中遇到的问题和解决办法
做项目时的思路、复盘和笔记
一些零碎但值得记下来的想法

之所以想认真搭一个博客，是因为很多东西如果只停留在本地，过一段时间就很容易忘掉。写下来不仅方便以后回头看，也能顺手整理自己的思路。

这里会写什么

接下来我大概会主要更新这几类内容：

前端和 Web 开发相关记录
折腾部署、工具链和效率工作流
个人项目的进展与总结

从这篇开始

这篇文章本身没有太多技术内容，它更像是一个开始。

如果你正好也在折腾技术、做项目，或者只是偶然路过，欢迎以后再来看看。

希望这里会慢慢变成一个对自己有用，也对别人有一点点帮助的小地方。

Agent 学习笔记：从会聊天到会行动

Sun, 10 May 2026 00:00:00 GMT

Agent 学习笔记：从会聊天到会行动

最近开始系统地补 Agent 相关内容。

一开始我对 Agent 的理解其实很模糊，总觉得它像一个被包装过的聊天机器人，只是多接了几个工具。后来越看越发现，真正有意思的地方不在“能不能对话”，而在“能不能持续地完成任务”。

对我来说，Agent 更像是一个会思考、会调用工具、会根据结果继续推进任务的执行体。它不是只回答一次，而是会围绕目标不断做下一步。

我怎么理解 Agent

如果只用一句话来描述，我现在会这样说：

Agent = 大模型 + 目标 + 工具 + 状态 + 执行循环

这里面最关键的不是模型本身，而是“循环”。

普通对话模型更像：

你问一次
它答一次
这一轮就结束

而 Agent 更像：

先理解目标
拆出下一步动作
调用工具执行
读取执行结果
判断是否继续
直到任务完成，或者明确失败

也就是说，Agent 的重点不是“说得像不像人”，而是“能不能把事情往前推进”。

一个常见的 Agent 结构

我目前看到的大多数 Agent 系统，基本都绕不开下面几个部分。

1. Goal

也就是目标。

目标越清楚，Agent 的行为越稳定。目标如果很模糊，比如“帮我弄好这个项目”，模型就容易不断试探、发散，最后做了很多动作，却不一定真的解决问题。

所以一个好的目标通常要尽量包含：

想完成什么
成功标准是什么
有哪些限制条件

例如：

帮我把 Astro 博客部署到 GitHub Pages，
要求使用 GitHub Actions 自动发布，
并确保访问路径适配 /ashenwitch。

这个目标就比“帮我部署博客”稳定很多。

2. Tools

如果没有工具，Agent 再聪明也只能停留在纸上谈兵。

工具决定了它能不能真正接触外部世界，比如：

读写文件
执行命令
调用 API
搜索网页
读数据库
操作浏览器

我现在越来越觉得，很多所谓的 Agent 能力，本质上都是工具能力的外延。模型提供理解和决策，工具提供行动能力。

3. Memory / State

Agent 必须知道自己现在处在什么阶段。

这里的“记忆”不一定非得是复杂的长期记忆系统，很多时候只要有一份可靠的状态记录就已经很有用了，比如：

当前目标是什么
已经执行了哪些步骤
上一次工具返回了什么结果
当前有哪些待办

如果没有状态，Agent 很容易重复劳动，或者在几轮之后忘了自己到底在干什么。

4. Planner

不是所有 Agent 都一定要有显式的规划器，但“规划能力”几乎是必须的。

简单任务可以一步完成，复杂任务通常需要拆解。

比如“写一篇博客”看起来只有一句话，但实际过程可能是：

确定主题
列提纲
写初稿
润色结构
补标题和摘要
存入指定目录

如果没有规划，Agent 往往会在第一步就试图直接输出最终结果，质量会非常不稳定。

5. Executor

规划不是结束，执行才是关键。

真正的难点往往出现在执行层，比如：

工具调用失败
文件路径不对
权限不够
返回结果格式和预期不同

所以 Agent 系统不能只会“想”，还得能处理现实里的不确定性。

为什么 Agent 会让人觉得“更像助手”

因为它开始具备了连续性。

一个真正好用的助手，通常不是一次性给你一堆建议，而是能顺着上下文继续做事：

发现问题
提出下一步
执行下一步
再根据结果调整

这种感觉会比单轮问答更接近“协作”。

也是因为这个原因，我觉得 Agent 最适合的场景，不一定是纯知识问答，而是那些带有明确目标、需要多步推进的任务，比如：

编码与调试
内容生产与整理
数据处理
自动化运维
工作流编排

学 Agent 时我最关心的几个问题

它到底是不是“自主”？

我现在的答案是：有限自主。

很多 Agent 看起来很主动，其实依然是在一个被约束好的框架里运行。它的“自主”，更像是在给定目标和工具集中的局部决策能力，而不是无限制自由发挥。

这个边界非常重要。

如果不加约束，自主性越强，翻车概率也越高。

Prompt 重要，还是 Workflow 重要？

两者都重要，但在 Agent 场景里，我会越来越偏向认为 Workflow 更重要。

Prompt 决定单步质量，Workflow 决定整体稳定性。

一个提示词写得再好，如果流程没有重试、校验、回退、状态同步，系统还是会很脆。

评估为什么这么难？

因为 Agent 不是只看最后一句回答对不对。

它的评估往往要看：

最终结果是否完成
花了多少步
是否走了弯路
是否错误调用工具
是否在失败后能恢复

也就是说，Agent 的评估更像评估“过程中的表现”，而不仅仅是“结果对错”。

我目前总结的几个实践感受

1. 先做小闭环，再谈大而全

比起一上来做“万能 Agent”，我更认同先把一个小场景跑通。

例如只做：

自动写日报
自动整理会议纪要
自动分析一个仓库并生成修改建议

这种小闭环一旦稳定，后面再扩展能力会更自然。

2. 工具返回结果一定要尽量结构化

这一点非常现实。

如果工具返回的是一大段随意文本，模型每次都要重新理解，成本高而且容易误判。相反，如果返回的是结构化数据，比如 JSON、明确状态码、固定字段，Agent 的后续决策会稳很多。

3. 不要过度迷信“一次规划到底”

复杂任务里的变化很多，一次性规划完整路径往往不现实。

我更喜欢“走一步，看一步，但每一步都知道为什么走”这种方式。也就是：

先有一个大方向
每轮只决定最合理的下一步
根据实际结果动态调整

4. 失败处理能力很重要

很多系统演示都只展示成功路径，但真实环境里经常会遇到：

网络失败
接口超时
权限不足
文件不存在
格式不兼容

如果 Agent 无法识别并处理失败，那它的可用性会大打折扣。

如果让我继续学下去

接下来我大概会继续沿着这几个方向深入：

更系统地理解 Agent 的规划方式
学习多工具协作时的上下文管理
关注评估方法和可靠性问题
尝试自己做一些小型 Agent 工作流

我现在越来越觉得，Agent 的价值不只是“AI 更聪明了”，而是“AI 开始能接手一部分真实工作流”。

这也是为什么这个方向会让我持续有兴趣。

结尾

这篇更像是一篇阶段性学习笔记，主要是把我目前的理解先整理出来。

后面如果继续学到更具体的内容，比如：

ReAct
Tool use
Planning
Memory
Multi-agent
Eval

我应该会再把它们拆成更细的文章继续写。

至少现在，我已经不再把 Agent 只看成“会聊天的模型”了。