仰望星空时

前端 Token 节省实战心得从前端转向 AI Native 开发已经有一段时间了，现在基本全程使用 Cursor 或 CodeBuddy 写代码。 刚开始的时候，3k 刀的预算真的感觉随便用。直到有一天 Token 预算突然开始打折，额度肉眼可见地往下掉，我才被迫认真思考：平时到底有哪些 Token 是花在了真正有价值的地方，哪些只是被浪费掉了？ 今天就分享一下我最近总结的几条 Token 节省心得。 Token 不是用得多，而是浪费得多一开始我以为，节省 Token 的方法就是少用 AI。但实际用下来发现，这个方向完全搞反了。 很多时候，Token 不是因为任务太复杂才消耗得多，而是因为上下文不断膨胀、重复信息反复传输，导致每一轮真正用于解决问题的内容只占很小一部分。 以 Cursor 为例，每轮对话有相对固定的基础成本，会话越长，历史上下文带来的额外消耗越明显。到了后期，一轮输入可能是前期的很多倍，但真正解决问题的内容并没有增加多少。 第 5 轮：上下文较短，主要处理当前问题第 50 轮：开始反复携带前面的大量历史第 100 轮：输入规模明显膨胀，真正有效的信息占比下降 很多 ...

从前端到 AI 应用开发：我想通了什么样的能力更不容易被替代今天 GPT-5.6 开放使用，我也第一时间试了试。 说实话，还是被震惊到了。 前端能力又往前走了一大截。以前需要自己反复调整的像素、手写的组件、手动处理的响应式，现在只要把需求描述清楚，模型很快就能给出一个能运行、能交互、甚至还挺像样的结果。 爽是真的爽，但也让人有点后怕。 以前大家讨论 AI 会替代什么，最常见的说法是“替代重复性劳动”或者“替代低端岗位”。最近在工作之余，我一直在想这个问题，慢慢有了一个不太一样的答案： AI 替代的不是做得不好的人，而是不会做决定的人。 如果代码能力不再稀缺，还剩下什么试想一下，一个中级前端，代码干净，组件合理，评审几乎没有问题，交付也很稳定。放在以前，这样的人很容易成为团队里的核心骨干。 但现在，模型也能越来越快地做到这些事情，而且成本更低、速度更快。 那这个人还剩下什么？ 我觉得答案不是“什么都不剩”，而是评价标准开始变化了。写出一段正确代码只是基础，真正重要的是： 这个需求到底应不应该这样做 哪个方案更适合当前业务，而不是看起来更炫 哪些地方存在安全隐患和长期维护成本 什么时 ...

Page Agent：在网页中实现自然语言操作传统的网页自动化通常依赖固定选择器和脚本。开发者需要提前知道按钮、输入框和页面结构，然后通过代码完成点击、输入和滚动。 Page Agent 提供了另一种思路：让 Agent 直接运行在网页中，根据用户的自然语言理解当前页面，并操作真实的 DOM。 它可以做什么用户可以输入类似这样的指令： 把筛选条件改成最近一个月，选择状态为已完成，然后导出结果。 Agent 需要先理解目标，再识别页面中对应的输入框、下拉框和按钮，按照顺序完成操作。最终用户不需要记住每个功能位于哪个菜单下面。 和传统自动化的区别Playwright 或浏览器自动化脚本通常是确定性的： await page.locator('#date-range').click()await page.locator('text=最近一个月').click()await page.locator('#export').click() 这种方式执行速度快、结果稳定，但页面结构变化后可能需要重新维护选择器。 Page Agent ...

AI Native 产品不是给传统应用加一个聊天框现在很多产品都会增加一个 AI 功能：一个聊天入口、一个智能问答框，或者一个自动生成按钮。这些功能确实能提升效率，但不一定意味着产品已经变成 AI Native。 我在整理相关资料时看到一个比较有启发性的判断：如果拿掉 AI 之后，产品的核心链路仍然可以按照原来的方式运行，那么它更像是传统产品叠加了 AI 功能。 传统产品加 AI 是什么样传统产品通常已经有稳定的页面、菜单和操作流程，AI 负责其中某一个环节，例如： 在搜索页增加自然语言搜索 在编辑器中增加文案生成 在客服页面增加问答助手 在表单中增加自动填写 这些功能可以很有用，但产品的核心结构仍然是原来的页面和流程。用户还是需要按照系统预设的路径完成主要任务。 AI Native 从什么出发AI Native 更关注用户真正想完成的目标，而不是要求用户先理解产品有哪些页面和按钮。 例如用户说“帮我找一家适合三个人、预算五百元、距离地铁近的餐厅”，传统产品可能要求用户先搜索地点、填写人数、设置价格和筛选条件；AI Native 产品可以先理解意图，再自行拆解任务、调用能力并给出结 ...

从 ChatBot 到 Agent：理解 Agent Loop普通 ChatBot 通常是一问一答：用户提出问题，模型生成回复，一轮交互就结束了。 Agent 的工作方式更像一个持续执行的循环。它先理解目标，再决定是否需要调用工具，根据工具结果继续判断，直到完成任务或需要用户介入。 Agent Loop 的基本过程一个比较典型的 Agent Loop 可以抽象成下面几步： 接收任务 ↓理解目标并制定下一步计划 ↓调用工具 ↓读取工具结果 ↓判断是否完成 ├─ 未完成：继续循环 └─ 已完成：输出结果 模型本身不一定需要知道所有事情，但它需要在每一轮根据当前上下文决定下一步做什么。工具调用结果会成为下一轮判断的一部分。 ReAct：推理、行动和观察ReAct 是 Agent 中很常见的一种思路，可以概括为 Reasoning、Action、Observation： Reasoning：分析当前目标和已有信息 Action：选择一个工具并生成参数 Observation：读取工具执行结果 问题：查找某个项目最近的发布记录分析：需要访问发布记录接口行动：调用 g ...

MCP 工具调用设计：从接口定义到权限控制AI 应用如果只负责生成文本，功能相对简单。但当它需要查询数据库、读取文件、创建工单或触发部署时，就必须和外部工具建立连接。 MCP（Model Context Protocol）提供了一种比较统一的方式，让模型通过 MCP Server 获取资源和调用工具。它解决的不只是“怎么调用接口”，还涉及工具描述、参数结构和执行结果如何返回给模型。 MCP 中的三类对象MCP 常见的核心对象可以分成三类： Resources：模型可以读取的资源，例如文档、文件和查询结果 Tools：模型可以请求执行的动作，例如搜索、创建记录和发送通知 Prompts：可以复用的提示模板 简单来说，资源更偏向“读什么”，工具更偏向“做什么”，提示模板则是“如何组织一次任务”。把这几类对象区分开后，应用的职责会更清晰。 工具描述为什么重要模型是否能正确调用工具，很大程度上取决于工具描述是否清楚。一个工具至少需要明确： 工具名称和用途 参数名称和数据类型 必填参数 参数取值范围 可能返回的结果 失败时的错误信息 例如，一个查询订单的工具，不应该只暴露一个模糊的 qu ...

AI Agent 中的上下文工程与记忆系统刚开始接触 Agent 时，我更关注模型本身的能力：能不能理解问题，能不能调用工具，能不能生成比较完整的答案。 但任务变复杂之后，真正影响效果的往往不只是模型，而是模型在每一次执行时能看到什么信息。上下文太少，Agent 不知道背景；上下文太多，又会让信息变得混乱，甚至增加无关内容对判断的干扰。 所以，AI 应用开发中有一个很重要的方向叫上下文工程（Context Engineering）。它关注的不是单纯写一段更长的 Prompt，而是如何组织、筛选和更新 Agent 在运行过程中需要的信息。 上下文不只是 Prompt一个 Agent 的上下文通常包括几类内容： 用户当前的问题 历史对话和任务状态 业务规则和系统约束 检索到的文档或数据 可调用的工具描述 其他 Agent 返回的中间结果 这些内容如果全部直接拼接到 Prompt 中，短任务可能还能工作，长任务就容易出现上下文膨胀、重复信息和重点不清晰的问题。 我理解上下文工程的核心，就是在每次执行前回答一个问题：当前这一步真正需要哪些信息？ 短期记忆和长期记忆短期记忆主要服务于当前任务 ...

requestAnimationFrame：实现更流畅的前端动画浏览器需要不断执行 JavaScript、计算样式、布局页面并绘制画面。常见设备的刷新率是 60Hz，也就是一帧大约只有 16.67ms。如果某一帧的工作时间太长，动画就会出现卡顿。 以前写简单动画时，比较容易想到 setInterval 或 setTimeout。但它们的执行时间和浏览器绘制时机并不一定同步，回调可能在一帧的中间或末尾执行，最终造成丢帧。 requestAnimationFrame 会在浏览器准备绘制下一帧之前调用回调，更适合实现连续动画。 一个简单的动画示例下面的代码让元素在一秒内向右移动 300 像素： const box = document.querySelector('.box')let startTimefunction animate(timestamp) { if (!startTime) startTime = timestamp const progress = Math.min((timestamp - startTime) / 1000, 1) ...

Web Worker：解决前端计算阻塞问题浏览器中的 JavaScript 通常运行在主线程上。页面渲染、用户点击、输入响应和脚本执行都会受到主线程状态的影响。如果一段计算运行时间太长，页面就可能出现卡顿，甚至暂时无法响应操作。 Web Worker 提供了一个独立的后台线程，可以把不依赖 DOM 的计算任务交给它处理。主线程负责页面交互，Worker 负责数据计算，计算结束后再把结果传回来。 一个简单的使用方式主线程创建 Worker，并通过 postMessage 发送数据： const worker = new Worker('./worker.js')worker.postMessage({ type: 'calculate', data: largeList})worker.onmessage = (event) => { console.log('计算结果：', event.data) worker.terminate()} worker.js 中接收数据，完 ...

AI 应用开发中的四类协议：从 MCP 到 AG-UIAI 应用逐渐从单轮问答走向工具调用、多 Agent 协作和实时界面交互。随着系统变复杂，单靠一段 Prompt 很难解决不同组件之间的通信问题。 我在整理 Agent 相关资料时，遇到了一组比较容易混淆的协议：MCP、A2A、ACP 和 AG-UI。它们都和 Agent 有关，但解决的不是同一层问题。 先看整体分层可以先用下面的方式理解： 协议 主要连接对象 解决的问题 MCP Agent 与工具、数据 Agent 如何调用外部能力 A2A Agent 与 Agent 不同 Agent 如何协作 ACP Agent 与 Agent 消息的语义和协商方式 AG-UI Agent 与用户界面 Agent 如何实时驱动 UI 它们不是简单的替代关系，更像是不同层次的协议。 MCP：连接工具和数据MCP 可以理解为 Agent 使用外部工具和上下文的统一接口。它采用客户端与服务端的模式，由 MCP Server 暴露资源和工具，Agent 通过 MCP Client 进行调用。 MCP 常见的三个核心概念是： ...