17 篇博文 含有标签「教程」

过去的浏览器 Agent 想在网站上完成任务，通常需要截图、识别按钮、滚动页面、填写输入框，再猜测下一步该点哪里。它能工作，却像让一个只拿到监控画面的机器人操作控制台：页面布局一改、按钮被遮挡、文案稍有歧义，整条任务链就可能失败。

WebMCP 提出了另一种思路：网站主动把自身能力声明为结构化工具，由浏览器在页面和 Agent 之间完成发现、权限检查、调用与结果传递。

Agent 不再只看到“一个蓝色按钮”，而是能看到一份接近函数契约的描述：

{
  "name": "book_appointment",
  "description": "预约一个仍有空位的咨询时段。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "date": { "type": "string", "format": "date" },
      "slot": { "type": "string" }
    },
    "required": ["date", "slot"]
  }
}

这不是要消灭图形界面，而是让同一个 Web 应用同时拥有两种可用界面：

• 人类使用视觉 UI；
• Agent 使用工具名、自然语言描述和 JSON Schema；
• 两者共享同一标签页、登录状态、应用状态和可见结果。

这也是 OpenAI 发起 WebMCP Challenge 的核心命题：构建一个在人与 Agent 共同使用时会变得明显更好的 Web 应用。

创建 goroutine 的代码，也必须能说明谁等待它、谁取消它、它什么时候退出。

本期把 goroutine 从语法糖升级为受管理的生命周期。我们实现两种核心结构：请求内 fan-out/fan-in，以及跨请求的有界 worker pool。

2026 年 8 月 19 日，OpenAI 将 Codex 更清晰地定义为一个可供开发者构建产品的 开放 Agent Harness。这句话容易被误读成“Codex 模型开源了”，实际开放的是模型周围的运行时与集成面：会话、Agent Loop、工具执行、沙箱、审批、事件流、CLI、SDK 与 App Server。

用一句话概括：

模型决定下一步做什么，Harness 决定它能看到什么、可以怎样做、需要谁批准，以及整个过程如何被恢复和观察。

这篇文章会回答三个问题：

1. openai/codex 到底开放了什么，没开放什么；
2. 面对庞大的 Rust 工作区，应当怎样学习 Agent Harness 的原理；
3. 如何选择 codex exec、Codex SDK 或 App Server，构建自己的应用。

2026 年 8 月，DeepSeek 开放了 DeepSeek Harness 的开发者预览与源代码。它不是“又一个 DeepSeek 模型”，也不是只把聊天框套在模型 API 外面；它是一套让模型能够读取环境、调用工具、维持会话、接受审批并持续完成任务的 Agent 运行时。

官方给出的公式很直接：

Agent = Model + Harness

模型负责推理与决策，Harness 负责把推理接到真实世界：上下文从哪里来、工具如何注册、命令在哪里执行、状态怎样恢复、危险动作由谁批准、失败以后能否重放。本文会从“能跑起来”一直讲到“如何基于它开发自己的应用”。

2026 年 7 月 28 日发布的 Model Context Protocol 最新规范 不是一次普通增量更新。它移除了协议级会话和初始化握手，把版本与能力协商移到每一个请求，用 MRTR 重构服务器向客户端索取信息的方式，并将长任务移出核心协议。

如果把早期 MCP 看成“为桌面 AI 应用连接本地工具的会话协议”，那么这次修订更像是“可穿过网关、负载均衡器和无状态计算平台的 Agent 基础设施协议”。

AI 编程工具进入 2026 年之后，一个很明显的变化是：我们不再只把 Claude Code、Codex、Gemini CLI、Aider 当成“聊天式代码助手”，而是开始把它们当成能在项目里持续执行的本地代理。

但单独开一个 AI CLI 很快会遇到瓶颈：

• 一个任务在跑测试时，你只能等；
• 一个任务需要你补充上下文时，整个队列就停住；
• 两个任务同时改代码，很容易把本地工作区弄乱；
• AI 改了什么，你必须不断切窗口、看 diff、查分支；
• 任务失败后，清理临时分支和 worktree 又是一堆手工活。

Claude Squad 解决的正是这个问题。它是一个终端 TUI 应用，可以在一个界面里管理多个本地 AI agent 实例，包括 Claude Code、Codex、Gemini CLI、Aider 等。每个任务都有自己的 tmux 会话、自己的 git worktree、自己的分支和自己的 diff 预览。你可以同时让一个 agent 修 bug，另一个补文档，第三个探索重构方案，然后逐个 review、追问、推送或丢弃。

截至 2026-06-26，官方仓库最新 release 是 v1.0.19，项目使用 Go 编写，许可证是 AGPL-3.0。官方 README 对它的定位很直接：管理多个本地 AI terminal agents，让你同时处理多个任务。

Kubernetes 的对象很多，kubectl get、kubectl describe、kubectl logs、kubectl exec、kubectl port-forward 足够强，但当你每天都要在 Pod、Deployment、Service、ConfigMap、Secret、Node、Namespace、CRD 之间来回跳转时，纯命令行会变成大量重复输入。

K9s 解决的正是这个问题：它把 Kubernetes API 变成一个可搜索、可过滤、可跳转、可执行操作的终端 UI。你仍然使用 kubeconfig、context、namespace 和 RBAC；K9s 只是把这些能力组织成更高效的交互界面。

截至 2026-06-26，K9s GitHub 最新 release 是 v0.51.0，发布时间是 2026-06-06。本文按当前官方文档、README 与 v0.51.x 系列行为整理。

Zsh 是一个面向交互式使用非常强的 Unix shell。它既能像 Bash 一样执行脚本和命令，又在补全、历史记录、路径展开、提示符、键绑定、函数 autoload、插件生态和交互体验上给了用户更大的可塑性。

如果你只是把 Zsh 当成“能装 Oh My Zsh 的 shell”，会错过它最有价值的部分。真正好用的 Zsh 配置不是堆满插件，而是把你的日常命令、项目入口、搜索、跳转、Git、容器、Kubernetes、远程开发和编辑器工作流组织成一套可维护的个人命令系统。

截至 2026-06-26，Zsh 官方 News 页面显示最新 release 是 5.9.1，发布时间是 2026-05-31。本文以官方手册和当前主流终端工作流为基础，按“先能用、再顺手、最后可扩展”的顺序展开。

如果你经常在终端里写代码、跑服务、看日志、连远程机器，tmux 基本是绕不开的工具。它解决的不是“终端不够漂亮”，而是一个更工程化的问题：终端会话应该像项目状态一样可恢复、可组织、可迁移。

iTerm2 已经是 macOS 上非常强的终端应用，支持标签页、分屏、Hotkey Window、Profile、Trigger、字体主题和快捷键。但 iTerm2 的窗口状态主要活在本机 GUI 里；一旦 SSH 断开、终端关闭、机器重启，很多运行中的上下文就消失了。tmux 则运行在 shell 里面，可以把一个项目的 editor、server、test、log、AI CLI 都放进同一个持久会话。

最推荐的分工是：

iTerm2 = macOS 原生窗口、字体、主题、全局唤起、Profile
tmux   = 项目会话、窗口、pane、远程保活、布局恢复
Shell  = 命令入口、目录跳转、项目启动脚本
Neovim = 编辑器 split、LSP、搜索、Git、代码修改

这篇文章会按“先能用，再顺手，最后可定制”的顺序介绍 tmux。

"站在巨人的肩膀上。" — WebRTC 标准化团队的共识（Curious — 历史）

本系列最后一篇，整合 Ch0–Ch14 全部知识，构建可部署的生产级视频会议系统。Serge Lachapelle 在 Curious 访谈 中回顾：从 Marratech 的瑞典企业网实验，到 Google Meet 的全球部署，WebRTC 的终极形态不是某个协议细节，而是一套可运维、可扩展、可观测的实时通信系统。

配套代码：examples/webrtc-lab/（全栈整合）