2026-09-06 16:46:16
欢迎来到第 132 期的【视野修炼 - 技术周刊】，下面是本期的精选内容简介
下面开始本期内容的介绍ღ( ´･ᴗ･` )比心。
许多高质的效果，copy 即用。
收藏了！
多种颜色/形状可调整，可以做动画编排。
有趣！☺️
支持 Node ，Deno，Bun。不需要额外再写胶水代码。
基于物理的 CSS 光照系统。定义好光源后，所有的阴影、高光和表面渐变都从它推导而来
周刊部分内容来源如下渠道，推荐大家关注。
2026-08-29 08:00:00
欢迎来到第 131 期的【视野修炼 - 技术周刊】，下面是本期的精选内容简介
下面开始本期内容的介绍ღ( ´･ᴗ･` )比心。
一个 chrome 插件可以在页面里插入移动设备的 UI 视图。
可以同时对比不同尺寸设备下的展示效果
很不错哦。
做 AI 助手的思考动画话可以可以试试个效果组件。
底层语言从 Zig 到 Rust。Node 兼容性进一步提升。
u1s1 速度确实比 Node.js 快很多，笔者新项目基本都是 Bun Monorepo 服务端也拿 Bun + Hono
还支 repl 模式的语法高亮。
装上一个试试，效果如下。
底层从 TS 换到 Rust 了，性能又是飞跃。
npm 里 latest 是11
# 升级操作
pnpm self-update next-12给 PDF 搞了个深色模式。
Tauri 实现的客户端，比较轻量。也有 Docker 镜像。
基于 Vecto 引擎的图片转 SVG 工具:上传位图自动矢量化,分割视图对比。
还原度还可以。
收藏
周刊部分内容来源如下渠道，推荐大家关注。
2026-08-23 17:46:23
欢迎来到第 130 期的【视野修炼 - 技术周刊】，下面是本期的精选内容简介
又 🕊 了好几个月了，VibeCoding 多了都没顾上刷资讯了，最近补一下，有趣的还挺多。
类似手机助手唤起时（如苹果的 Siri/超级小爱）周围的柔和发光效果。
基于浏览器原生滚动 API 的轮播组件。部分场景可以实现0外部依赖，
支持 React、Vue、Solid 等，API 简单。
| Vue | React |
|---|---|
 |
 |
先收藏，以后没准能用上
印象之前有一个插件也是类似这样，会将访问过的网站收集一个按钮。
Button Stealer
使用熟悉的dom API 来操作构建终端应用。
C 语言构建的 JavaScript 运行时，仅 9MB。
可用于创建可灵活拖拽的大盘页面。
多运行时支持的日志库，运行时 0 外部依赖。
看着不错，引入项目里用用看。
7月底进入 stage 3，延迟加载模块的语法。
在此之前动态加载的版办法。
// cjs
exports.renderReport = function (data) {
const chartRenderer = require('chart-renderer')
return chartRenderer.render(data)
}
// esm
export async function renderReport(data) {
const { render } = await import('chart-renderer')
return render(data)
}defer 语法。
// 此时会导入，但不执行
import defer * as ns from "some-module";
function useFeature() {
// 首次读取的时候才执行模块里的代码
return ns.feature(); // reading this is what triggers evaluation
}
// or 动态导入
const ns = await import.defer("some-module");又学到一手
支持读写XLSX、CSV、ODS、JSON、NDJSON、XML等格式。服务端客户端都可以使用。
将TS脚本编译成可执行文件。
周刊部分内容来源如下渠道，推荐大家关注。
2026-08-19 00:50:00
最近得闲，学 Agent 过程中顺便做了一个 AI 应用。
最近对💰比较敏感了 😄，就想搞搞记账这件事。
于是自己做了一个，叫 妙蛙记账。
目前支持 Web 和 Android：https://miaowa.sugarat.top/docs/
核心功能就是：自然语言描述，自动记账和完成数据查询。
自然语言描述账单信息
午饭花了 32（自动归类到餐饮-午餐）咖啡 18，地铁 4，午饭 35（一次记 3 笔；账本没有的二级分类会自动建）昨天晚饭花了 68（时间自动识别为昨天）发工资收入 8000
打车 25 记到交通、拼多多购物 50（会落到购物 · 拼多多，没有就自动建这个二级）直接用大白话跟它“查账”：
这个月花了多少？ / 今天餐饮花了多少？
这个月餐饮按二级展开 / 这个月都花哪了
上一次吃黄焖鸡是什么时候？ / 哪几天喝了奶茶？
| 汇总查询 | 最近消费查询 |
|---|---|
 |
 |
除了 AI 交互，该有的基础功能也有：
💻 官网（包含网页版入口与 Android 下载）：https://miaowa.sugarat.top/docs/
网页未登录是只读演示，登录后才是自己的账本，也能真正跟 AI 对话。
这还是个比较早期的版本，主打极简和实用，后续会加入识图，Native 侧的一些快速识别记账等功能。
欢迎试用反馈建议，帮助产品迭代。
交流群：
2026-08-18 20:05:00
为我造过的轮子与写过的项目,书写传记
个人精力有限,感兴趣有能力的朋友可以帮忙迭代维护
2026-08-10 10:26:33
本文仅代表作者个人观点，如果内容有错误或和你理解上有所出入，欢迎交流与指正。
学习过程参考了 Pi Agent 的源码。按照其分层思路和一些实现方案，笔者自行实现了一个 MVP 版本的 Harness。
本文主要分享一下整个过程中的一些学习心得和个人的一些想法。
“Agent” 从最开始文本对话式，到多模态（语音/图片/视频）智能体，再到现在的 Agent（能够辅助办公、开发、生成完整项目等），不同阶段 Agent 的定义也不一样。
最近的一阶段是 "Model + Harness = Agent"。
之前是高频使用各种智能体辅助写文档，改项目代码。
最近一段时间准备做一些带 Agent 能力的 AI 应用，所以先学习一下 Harness 相关的知识，知己知彼😋。
开局先来一张图
Harness 算是模型的运行时，各家 Agent 的差异也就在这部分，模型都是可以随时切换的。
所以没有 Harness 的「Agent」，大部分就是纯聊天。
先小小总结一下几个主要模块
| 各个模块 | 作用 |
|---|---|
| Model | 读 Context，产出文本或结构化 tool_calls
|
| Context | 本轮真正送进模型的内容，不单单是「用户输入的那一句话」 |
| Tools | 实际做外部调用，真正改文件、跑命令 |
| Harness | 负责 循环、校验、执行、上下文组装、回写、权限、资源控制等行为 |
| Agent | 模型跑在 Harness 上、冲着目标多步往前推进，直到完成或达到终止条件 |
Tools 是模型和外部沟通的桥：模型只负责发出结构化调用，真正去改文件、跑命令、调 API 的是具体 Tool 实现；调度和校验则由 Harness 来做。
Function Calling（现在大部分时候也叫 Tool Calling）解决的问题是：
避免模型用自然语言描述去说明要调用的工具，而是让它输出可解析的调用结构。
没有这套约定时，模型可能写
我需要调用 get_weather(上海) 来获取天气信息
应用侧很难可靠地解析。有了 Function Calling：
tool_calls（调用谁、参数是什么、本次调用的 id）tool 消息写回贴一张官方的图：function-calling#how-it-works
下面是我画的一版 Model / Harness / Tools 怎么流转起来的（对应上面 1→4 步）：
下面来个最简 demo（OpenAI Chat Completions，非流式），看一下调用结构：
// 1）准备工具声明（schema）——只描述能力，不含实现
const tools = [
{
type: 'function',
function: {
name: 'get_weather',
description: '查询某城市当前天气',
parameters: {
type: 'object',
properties: {
city: { type: 'string', description: '城市名，如上海' },
},
required: ['city'],
additionalProperties: false,
},
},
},
]
const messages = [
{ role: 'user', content: '上海今天天气怎么样？' },
]
// 2）一次请求：messages + tools
const res = await fetch(`${OPENAI_API_BASE_URL}/v1/chat/completions`, {
method: 'POST',
headers: {
'Authorization': `Bearer ${OPENAI_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
model: 'gpt-5.6', // 模型 id
messages,
tools,
tool_choice: 'auto', // 模型自己决定是否调用工具，也可设为 none / required / 指定某个工具
}),
})
const data = await res.json()
const message = data.choices[0].message
// ↓ 输出释义见下方示例一次成功响应（需要调工具时）大致长这样：
// data 示意（省略 usage 等）
{
id: "chatcmpl-xxx",
choices: [
{
index: 0,
finish_reason: "tool_calls", // 因工具调用结束本轮；最终文本常见 "stop"
message: {
role: "assistant",
content: null, // 也可能是一段说明；有 tool_calls 时经常为 null
tool_calls: [
{
id: "call_abc123",
type: "function",
function: {
name: "get_weather",
arguments: '{"city":"上海"}', // 注意：是字符串，不是对象
},
},
],
},
},
],
}返回结果里，重点关注这几个：
message.tool_calls：决定是否需要执行工具tool_calls[].id：回写结果时需要一一对应上idtool_calls[].function.name / arguments：工具名和参数finish_reason："tool_calls" 表示「需要执行工具」；"stop" 表示本轮结束Harness 处理工具调用的核心逻辑是：校验 → 执行 → 回写 → 再请求。
// 1）先把本轮 assistant（含 tool_calls）写入 messages，下一轮还要带上
// 保持 OpenAI 原始结构即可
messages.push({
role: 'assistant',
content: message.content,
tool_calls: message.tool_calls,
})
// 2）解析参数 → 校验 → 执行 → 回写
for (const tc of message.tool_calls) {
// 格式化一下参数
const call = {
id: tc.id,
name: tc.function.name,
arguments: JSON.parse(tc.function.arguments || '{}'), // 字符串 → 对象
}
// 按 schema 校验；不合法则回写错误
if (isInvalid(call)) {
messages.push({
role: 'tool',
tool_call_id: call.id,
content: '参数不合法',
})
continue
}
// 执行工具
const result = await executeTool(call)
// 回写结果到上下文中
messages.push({
role: 'tool',
tool_call_id: call.id,
content: result.content, // 字符串
})
}
// 3）带着更新后的 messages 再请求模型
const res = await fetch(`${OPENAI_API_BASE_URL}/v1/chat/completions`, {
// ... 其他参数
body: JSON.stringify({ messages, tools, tool_choice: 'auto' }),
})
const data = await res.json()
// 模型再次回复，可能包含 tool_calls 或继续自然语言回复
const message = data.choices[0].message下面是第二次请求模型的 messages 示例，包含了工具调用结果：
[
{ "role": "user", "content": "上海今天天气怎么样？" },
{
"role": "assistant",
"content": null,
"tool_calls": [
{
"id": "call_abc123",
"type": "function",
"function": {
"name": "get_weather",
"arguments": "{\"city\":\"上海\"}"
}
}
]
},
{
"role": "tool",
"tool_call_id": "call_abc123",
"content": "{\"temp\":28,\"unit\":\"C\"}"
}
]tool_calls 参数tool_call_id 回写 → 再请求真正办事的 Agent，需要把上面的流程自动循环起来：组装上下文 → 请求模型 → 有调用就执行回写 → 再请求，直到给出最终答复，或被约束条件强制停掉。
当然我这里只是一个最简单的实现（用「有没有 tool_calls」来决定要不要自动推进），实际的循环推进条件可能还有其它的策略。
async function runAgent(state) {
while (true) {
// 1）组装本轮真正进模型的 Context
const messages = assembleContext(state)
// 2）请求模型
const assistant = await adapter.stream({ messages, tools: state.tools })
// 3）判断有没有 tool_calls
if (!assistant.tool_calls?.length) {
return assistant.content
}
// 4）有调用：校验 → 执行 → 回写
state.messages.push({
role: 'assistant',
content: assistant.content,
tool_calls: assistant.tool_calls,
})
for (const call of assistant.tool_calls) {
const result = await executeTool(call)
state.messages.push({
role: 'tool',
tool_call_id: call.id,
content: result.content,
})
}
// 5）带着工具结果进入下一轮 while
}
return assistant.content
}和纯对话的差别就在第 4 步：模型输出调用指令，Harness 调度 Tools，用执行结果继续推进。
以 Pi: agent-loop 为例，默认仍是「本轮有没有工具调用」驱动自动续跑，同时还会看下面这些条件：
1）工具结果不一定需要回传
terminate: true 字段来决定是否回传terminate: true，就不需要再请求模型// 示意：结构化输出工具跑完就结束本轮自动续跑
async execute(_id, params) {
return {
content: [{ type: "text", text: "已保存结构化结果" }],
details: params,
terminate: true,
};
}2）shouldStopAfterTurn（回合结束后可选停）
内置钩子：回合结束后由调用方决定是否继续；也可在这里选择性地压缩上下文。
3）steering / follow-up
这两个都是「往 Loop 里塞用户消息」，时机不同：
| 名词 | 白话 | 典型时机 |
|---|---|---|
| steering | Agent 还在跑时，用户可以临时插一句进来，改变执行方向 | 当前回合工具跑完后、下一次请求模型前注入 |
| follow-up | Agent 准备结束了，队列里还有一句比如「顺便再总结一下」 | 内层循环要退出前从队列里取出；有则继续跑 |
相关 loop 代码大概就 100 来行，比较容易理解。
tool_calls 则）执行工具 → 再请求进行下一轮Loop 能跑起来之后，接着就是：怎么让它停得住。
Prompt 只能做一些软约束：不可逆操作、调用死循环、反复执行等，需要在 Harness 代码里做硬约束。
const controller = new AbortController()
await runAgent({
maxSteps: 8, // 最大执行回合数
timeoutMs: 60_000, // 整次 Run 的超时时间
stopOnToolError: false, // false：错误写回，模型来纠正
signal: controller.signal,
onConfirm: async (call) => {
// 高危工具执行前二次确认；拒绝则写成错误 tool 结果，不调真实 handler
if (call.name === 'rm' || call.name === 'bash') {
return window.confirm(`允许执行 ${call.name}？`)
}
return true
},
})
// controller.abort(); 主动取消执行工具调用前加一层执行前校验：校验 schema，工具是否存在，参数是否合法等。
异常情况可以回写错误的 Tool 消息，让模型可以自主的重试，用户也能感知到。
循环的终止与工具调用安全边界，靠 Harness 代码硬约束。
执行沙箱等下来仔细研究一下，后面再单开文章。
上下文组装也是 Context Engineering 在 Harness 里的应用。
每次给模型推送的，不只是「用户刚输入的那一句」，而是 Harness 组装出来的完整上下文，常见包括：
role: "tool" 消息
const context = assembleContext({
system: [identity, ...rules], // ① 系统提示 + Rules
tools: toolDefs, // ③ schemas（含 MCP 归一后的）
history: messages, // ②④ 历史里已含 tool 结果；或先摘要
user: currentUserMessage, // ⑤ 本轮输入
// skillCatalog / skillBody // ⑥ SKILL：SKILL 目录和相关SKILL 描述，全文按需注入
// memoryHits / ragChunks // ⑥ Memory / RAG：外置命中 → 注入
})这块的细节实现，待我下去再多研究几个项目，单独出一期文章。
可以看成是解决某类问题或完成某项任务的流程规范文档（SOP）。
SKILL 不是 Tool，可以看做是一大段提示词，实际执行仍是通过内部的指令描述调用 Tool 来完成任务。
常见就是一份 Markdown（可带 frontmatter），大致三块：
| 部分 | 内容 |
|---|---|
| 元数据 |
name、description（何时该用）；可选权限（允许的工具） / 依赖说明 |
| 正文 | 步骤、约束、输出格式、决策规则（真正的 SOP） |
| 其它 | (可选) references/、模板、脚本、workflow 等，这块一般是渐进式披露的 |
---
name: weather-brief
description: 用户要天气简报时使用
---
1. 先调 get_weather …
2. 再按固定结构输出 …学到的几种方式：
| 方式 | 谁决定加载全文 | 全文怎么进 |
|---|---|---|
| 手工 / 显式 | 用户指定（如 /skill:name） |
直接写入 Context |
| Harness 匹配 | 按 SKILL 描述与用户输入做简单的关键词匹配 | 匹配到的正文写入 Context |
| 模型决定 | 模型自己选要加载哪个 | 先把SKILL目录里的（name + description）给模型，模型决策后，再调工具 load_skill，SKILL 正文以 tool 结果回写 |
三种方式的逐步流程（同一例子 weather-brief）：
SKILL 可以由 Harness 发现并注入上下文，也可以给模型披露一些基本信息让模型自己决定加载哪个。
MCP（Model Context Protocol）是一套开放协议，用来标准化 AI 应用怎么连接外部系统（数据、工具等）。
本文先只看 Tools 部分：统一发现与调用。
收到 tool_calls 后的执行路径：
Harness → 选则 Client → Server → 返回的结果回写 Context。
| 角色 | 职责 |
|---|---|
| MCP Host | 创建/管理多个 Client，这里就是 Harness 去负责管理 |
| MCP Client | 与单个 Server 的会话连接：提供listTools、callTool 等常用方法 |
| MCP Server | 暴露 Tools 并执行（本地进程或远程服务；另有 Resources / Prompts，本文不展开） |
传输：本地多用 stdio，远程多用 Streamable HTTP；数据传输协议使用 JSON-RPC。
// mcp-server.mjs —— Host spawn 的就是这个进程
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
const server = new McpServer({ name: 'demo', version: '1.0.0' })
server.registerTool(
'add',
{
description: '计算两个数字之和',
inputSchema: {
a: z.number().describe('加数 a'),
b: z.number().describe('加数 b'),
},
},
async ({ a, b }) => ({
content: [{ type: 'text', text: String(a + b) }],
}),
)
const transport = new StdioServerTransport()
await server.connect(transport) // stdout 专给 JSON-RPC；日志用 console.error下面提到的 registry 可以看做是 Harness 里负责管理工具注册和发现的模块
包含本地 Tools + MCP Tools 的管理
import { Client } from '@modelcontextprotocol/sdk/client/index.js'
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js'
// 连接 MCP Server
const transport = new StdioClientTransport({
command: 'node',
args: ['./mcp-server.mjs'],
})
const client = new Client({ name: 'my-harness', version: '0.1.0' })
await client.connect(transport) // spawn + initialize
const { tools } = await client.listTools()
for (const t of tools) {
// 写入 Harness 工具表
registry.register({
name: t.name,
description: t.description ?? '',
parameters: t.inputSchema ?? { type: 'object', properties: {} },
source: { kind: 'mcp', client },
})
}
async function executeTool(call: ToolCall): Promise<ToolResult> {
const meta = registry.get(call.name)
if (meta?.source.kind === 'mcp') {
const res = await meta.source.client.callTool({
name: call.name,
arguments: call.arguments,
})
return {
toolCallId: call.id,
content: JSON.stringify(res.content),
isError: Boolean(res.isError),
}
}
return localHandlers[call.name](call)
}CLient 连接是长生命周期的：
new Client → connect → listTools 注册一次工具；callTool，复用之前的连接；close()。MCP 还包含 Resources 和 Prompt 能力，这块还要再下来研究一下与 Harness 的联动机制
到这里 0-1 搞一个 MVP 版可跑的 Agent 应该是妥妥的了
下一篇（Part 2）大概会是以下的内容：
