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

真正可靠的任务看板，不是“WebSocket 一直在线”，而是：状态先成为可恢复的事实，通知只负责让事实更快到达，任何一层短暂故障后都能重新收敛到正确状态。

文件解析、AI 生成、视频转码、报表导出这类异步任务，通常会经过多个服务和步骤。用户真正关心的往往不是复杂的工作流编排，而是几个朴素问题：

• 我的新任务是否已经创建？
• 当前是等待、运行、成功，还是失败？
• 当前由哪个服务执行什么功能，不同功能的数据该如何展示？
• 哪个步骤正在执行，已经用了多久？
• 步骤失败、自动重试或执行器失联时，用户如何收到明确告知？
• 页面断线、刷新或切到后台后，会不会永远停在旧状态？
• 服务多副本、节点重启、网络闪断时，状态通知是否仍能恢复？

本文设计一套专注于任务状态、步骤状态和耗时展示的生产链路。它不负责启动下一步、不替代工作流引擎，也不把实时消息系统当数据库。

最终方案可以概括为：

Business API 创建 workflowId 与独立 taskId
  → Worker 按 taskId 上报状态
  → Task Status Service 事务校验与落库
  → 同事务写 MySQL Outbox
  → Outbox Relay 领取并调用 Centrifugo 发布
  → 用户摘要频道 + 任务详情频道
  → 前端按 version 合并
  → 恢复失败时重新读取数据库快照

外部使用 REST，不代表内部也必须使用 REST；内部使用 gRPC，也不代表每个语言都要各自维护证书、重试、负载均衡和访问控制。Istio 的价值，是把跨语言的网络治理收敛到统一的数据平面和策略层。

本文不从 Bookinfo 示例开始，而是搭建一条更接近真实生产系统的链路：

外部客户端
  → HTTPS / REST
  → Istio Ingress Gateway
  → Java Web API
  → gRPC
  → Go Order Service
  → gRPC
  → Rust Inventory Service
  → PostgreSQL

三个服务只实现业务协议，Istio 负责入口、东西向 mTLS、工作负载身份、流量分配、超时、异常实例摘除和基础遥测；应用仍负责业务权限、幂等、事务、数据加密和 Trace Context 传播。

过去的浏览器 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。本文以官方手册和当前主流终端工作流为基础，按“先能用、再顺手、最后可扩展”的顺序展开。