Cordis：DeepSeek Harness 为什么把 Agent 运行时重写成一套"可逆的组件系统" 核心问题：为什么 DeepSeek Harness 选择 Cordis？它解决了传统 Agent Harness 的什么问题？它是否代表了 Agent Runtime 的一种新架构？ 本文基于源码级研究：deepseek-ai/deepseek-harness、cordiverse/cordis（v4.x）、论文 arXiv:2608.25512。所有关键结论标注来源性质：【源码事实】（可直接从仓库代码/文档证明）、【论文观点】（来自论文摘要与 README 原文）、【研究推论】（本文作者基于前两者的判断）。论文 HTML 全文在本次研究中不可得，涉及论文细节均只引用摘要原文。 1. 开头：为什么 Agent 需要 Runtime 大多数 Agent 框架解决的是两个问题：下一轮对话模型看见什么（Prompt Composition），以及进程之间怎么调用（MCP 之类的工具协议）。但只要一个 Agent 活得足够久——长会话、热改工具、动态挂载能力——第三个问题就会浮出水面： 同一个进程里的能力，如何动态地出现、消失、替换，而不影响其他组件？ 传统答案是"重启进程"。但对一个跑着 30 个会话、持有浏览器连接、缓存着向量索引、正在执行长任务的 Agent Harness 来说，重启意味着一切归零。这不是 Prompt 层的问题，也不是进程层的问题，而是运行时层的问题。 DeepSeek 的 Harness 项目给出的答案是一个叫 Cordis 的框架。README 里一句话点明了架构【源码事实，deepseek-harness/README.md:7】： It is built on an everything-is-a-plugin architecture and powered by Cordis, whose design is described in A Programming Paradigm for Spatiotemporal Composability. ...

核心问题：当 YOLO、人脸、人手三个模型同时跑在一条手机摄像头流上，怎么让快的检测器不被慢的拖死，让该响的警报一秒都不迟到？ 第一次真机测试：警报迟到了八秒 凌晨一点，把 APK 装到真机上，对着摄像头闭眼。预期：闭眼 1.2 秒后疲劳警报响起。实际：我闭着眼睛数了快十秒，屏幕上的"闭眼时长"读数还在几百毫秒徘徊，警报才不情不愿地响起来。 第一反应是推理太慢。但看监控数据完全不是这么回事——MediaPipe 人脸关键点单帧只要几毫秒，YOLO 手机检测也就三五十毫秒，加起来远够不到十秒。问题出在别处。 这个项目是个"AI 检测助手"：一条 CameraX 取流管线，两种模式——车损分析（后摄，YOLO 检测车辆）和驾驶模式（前摄，同时跑 YOLO 手机检测 + MediaPipe 疲劳检测 + 手部验证）。从 23:30 的 init 提交到 00:45 的最后一个提交，75 分钟里踩的每一个坑，都值得记下来。 一条管线，三个检测器，谁也不许拖累谁 先交代架构。整个 App 只有一个 ImageAnalysis 分析器，模式切换只是改分发分支，不重绑相机——只有手动切前后摄才重新 bind。 graph LR A[CameraX 取流<br/>RGBA_8888] --> B[转 Bitmap] B --> C{YOLO 手机类} B --> D{FaceLandmarker<br/>疲劳} B --> E{HandLandmarker<br/>按需} C --> F[叠框 + 状态机] D --> F E --> F F --> G[声音警报 / 叠框] 几个值得说的技术选择： ...

开场：告别内网穿透的“开盲盒”体验 在多设备办公和 HomeLab 运维中，远程访问内网资源一直是个痛点： frp / 端口映射：家宽没有公网 IP，或者公网 IP 隔三差五变动，还要针对每个端口配置穿透规则。 ZeroTier / Tailscale：虽然方便，但依赖第三方中央控制平面，国内网络偶发打洞失败或握手延迟飙升。 传统 OpenVPN / IPsec：配置繁琐、代码庞大，在笔记本睡眠唤醒或 Wi-Fi 切换后重连极慢。 WireGuard 的出现彻底解决了这些问题： 代码精简：仅约 4,000 行核心代码，直接集成进 Linux 内核，吞吐量接近线速。 现代密码学：基于 Noise 协议框架与 Curve25519、ChaCha20-Poly1305，没有臃肿的握手协商。 极简身份机制：每个节点一对公私钥，无状态（Stateless）UDP 通信，原生支持移动漫游（Roaming）。 本文将从零开始，手把手记录一套完整的 Ubuntu 云端中继 + 家庭设备 + macOS 终端极客接入 的生产级配置方案，并深度复盘在 macOS 上实现系统级 LaunchDaemon 开机常驻与事件驱动自愈重连的实战经验。 1. 架构设计与网络规划 WireGuard 在协议层没有严格的“客户端”与“服务端”之分，所有节点都是平等的 Peer。但在实际拓扑中，我们通常将拥有固定公网 IP 的云服务器作为汇聚与中继节点。 拓扑规划 ┌───────────────────────────────┐ │ Ubuntu 云服务器 (Node A) │ │ 公网 IP: 198.51.100.1 │ │ 虚拟 IP: 10.100.0.1/24 │ └──────────────┬────────────────┘ │ WireGuard UDP :51820 ┌────────────┴────────────┐ │ │ ┌────────┴────────┐ ┌────────┴────────┐ │ 家庭 NAS / PC │ │ MacBook 笔记本 │ │ (Node B) │ │ (Node C) │ │ 虚拟 IP: │ │ 虚拟 IP: │ │ 10.100.0.2/24 │ │ 10.100.0.3/24 │ └─────────────────┘ └─────────────────┘ 节点分配表 节点 角色 真实网络 虚拟 IP (wg0) 监听端口 / 对端 Node A 云端中继网关 拥有固定公网 IP 10.100.0.1/24 监听 51820 (UDP) Node B 家庭服务器（Ubuntu 24 Server） 家庭宽带内网 (NAT) 10.100.0.2/24 对端指向 Node A Node C macOS 办公本 移动办公 / Wi-Fi (NAT) 10.100.0.3/24 对端指向 Node A 网段选择提示：虚拟子网建议使用 10.100.0.0/24 等不常用网段，避免与家庭路由器默认的 192.168.1.0/24 发生网段冲突。 ...

背景 办身份证、社保卡、护照、港澳通行证、驾照，都需要证件照和回执。线下照相馆收 ¥10~20，线上小程序也差不多。 其实只要两步： 拍照：微信搜「智绘免费证件照制作」小程序，手机拍就行 回执：上 rzzx.com.cn「证件数码相片质量检测中心」，官方渠道只要 ¥1.5 但很多同学拍出来的照片背景杂乱（白墙有阴影、灰底、杂色），不符合要求。下面这个工具可以直接在浏览器里完成 AI 自动抠图 + 换纯白/蓝/红底色，全程本地处理，照片不出浏览器。 证件照要求速查 背景必须纯白、红或蓝色（严禁灰色背景） 禁止翻拍纸质照片（尤其翻拍身份证） 禁止模糊、水印、变形 禁止 AI 生成的证件照（但抠图换底色属于正常修图，没问题） 头顶与照片上边距要有一定距离 在线工具 直接在下面操作，上传照片 → 选规格 → 选底色 → 生成下载： 📷 AI 证件照生成工具 纯本地计算 · 零上传 · 杂色背景换纯白/证件蓝/红 1. 上传自拍照（支持拍照或相册选择） 2. 证件照尺寸规格 标准 1 寸 (25mm × 35mm / 295×413 px) 标准 2 寸 (35mm × 49mm / 413×579 px) 大 1 寸 / 护照 / 签证 (33mm × 48mm) 保持原图比例 (仅换底色) 3. 选择底色 开始生成证件照 ...

为什么三个生态面对同一个"版本冲突"问题，给出了截然相反的答案？ 那个让我加班到凌晨三点的依赖冲突 去年一个周五晚上，生产环境突然爆出 NoSuchMethodError。排查了两个小时，最终发现是一个同事在公共模块里升级了 Guava，而另一个模块还在用旧版 API。Maven 的"就近原则"在本地构建时选了新版，到了 fat jar 打包时又选了旧版——同一个项目，两种行为，取决于你从哪个子模块触发构建。 那天晚上我一边修 bug 一边想：为什么 Go 的项目从来没遇到过这种事？为什么前端项目几百个 node_modules 嵌套也没炸？ 答案藏在三个生态对同一个问题的不同哲学选择里。 三种哲学：强约束、隔离共存与极简主义 Maven 的"大一统"：宁可痛苦，不要歧义 Maven 的核心信条是一个项目里，同一个库只能有一个版本。 这听起来很武断，但背后有深刻的理由。Java 运行在 JVM 上，类加载器的行为决定了：如果同一个类（全限定名相同）被两个不同版本的 jar 同时加载，轻则方法签名不匹配抛 NoSuchMethodError，重则序列化反序列化直接炸掉。这不是"可能出问题"，而是"一定会出问题"。 所以 Maven 选择了最暴力的策略——Dependency Mediation（依赖裁决）： <!-- Maven 的冲突裁决逻辑（简化版） --> <!-- 1. 路径最短优先 --> <!-- 2. 路径相同时，pom.xml 中先声明的赢 --> <!-- 3. 你可以在 dependencyManagement 里强行指定 --> <dependencyManagement> <dependencies> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>33.0.0-jre</version> <!-- 我说用哪个就用哪个 --> </dependency> </dependencies> </dependencyManagement> 这种策略的代价是升级是一场战争。你不能只升级直接依赖，还必须处理所有传递依赖的兼容性。大厂的 Java 项目每年花大量时间在"依赖版本升级周"上，这不是笑话，是真实的企业级成本。 ...

核心理念：零依赖、极速加载、纯原生实现暗黑科技风动效。 🎬 完整动效 Demo（复刻官方风格）：https://fxio.site/harness-demo/ 在线体验（可直接交互） 下面的 iframe 内嵌了完整 Demo 页面 —— 粒子网络背景、3D 旋转线框环面、鼠标跟随发光卡片、SVG 数据流、终端复制、滚动渐显全部可用。点击右上角链接可在新窗口打开。 在新窗口打开完整 Demo ↗ 效果拆解 本 Demo 包含四个核心动效组件： 鼠标跟随发光卡片 (Glow Cards) — 鼠标移动时卡片产生跟随光晕 SVG 节点数据管道流动 (Flowing Lines) — 模拟数据在节点间流动 极简终端代码框 — 暗黑风格的命令行展示 滚动平滑渐显 (Scroll Reveal) — 基于 IntersectionObserver 的懒加载动画 01. 鼠标跟随发光卡片 Everything is a plugin 基于 Cordis 插件系统架构，模型、工具、Skills、Session 均为可解耦插拔组件。 Every run is traceable 所有上下文与工具调用均重现于 Session 日志中，支持 fork, search 与 replay。 ...

Windows 10 精简版就像一辆拆掉安全气囊的赛车：跑得快，但一撞就出事。Office 部署就是那根容易断的安全带——你得自己把它装回去。 开场：我帮朋友装 Office，装出了连环崩溃 上周一个朋友甩给我一台「优化版」Windows 10，说系统启动只要 8 秒，桌面干净得能照镜子。 然后他说：「帮我装个 Office。」 我满口答应，打开 Office 安装包，进度条走到一半—— 蓝屏。 重启再试，进度条又卡在 60%，报了个 0x4004F00C，搜了半天发现是激活服务被砍了。 第三遍，安装是成功了，打开 Word 弹窗报错，说缺组件。 这时候我意识到：Windows 10 精简版装 Office，不是「下载 → 下一步 → 完成」这么简单。 你得知道系统被砍掉了什么、Office 需要什么、以及怎么把缺的东西补回来。 Windows 10 精简版到底砍掉了什么 「精简版」不是一个标准概念，各种第三方精简方案砍的东西各不相同。但根据我踩过的坑，以下几样东西是 Office 最怕被砍的： Windows Update 服务：Office Click-to-Run 依赖它来检查和安装更新。服务被禁用或删除后，Office 可能装不上或装完无法更新。 .NET Framework 运行时：Office 安装程序和部分组件依赖 .NET 4.x，精简版经常把它精简掉。 Visual C++ 运行时库：Office 的很多底层组件依赖 VC++ Redistributable，缺了它会报各种 DLL 错误。 系统证书和信任链：激活和更新需要联网验证，如果证书被清理或 hosts 文件被改，激活会失败。 Windows Installer 服务：部分 Office 组件安装依赖 MSI，服务被禁用会导致安装卡死。 建议： 安装 Office 前，先检查这些服务是否正常运行： ...

摘要：前几天做了 Awesome Mac 检索页，这次轮到 Windows 了。基于 GitHub 上的 0PandaDEV/awesome-windows（2.7k star）清单，生成了一个面向开发者的单页检索站：361 款软件、36 个分类，IDE / 终端 / 命令行 / 版本控制等 12 个开发者分类置顶，还有一键「💻 开发者必备」筛选。在线地址：fxio.site/p/awesome-windows.html 和 Mac 版的区别：主题面向开发者 Windows 软件清单里混着大量普通用户工具，而开发者找东西时只关心那一小撮：编辑器、终端、包管理、调试器、容器工具。所以这一版做了两处针对性设计： 开发者分类置顶：IDE 集成开发环境、文本编辑器、终端、命令行工具、版本控制、开发者工具、API 开发、数据库客户端、本地 AI、网络工具、代理与 VPN、虚拟化——这 12 个分类排在筛选栏最前面 「💻 开发者必备」一键筛选：点一下只看开发相关工具，其它分类全部隐藏 其余能力和 Mac 版一致：Fuse.js 模糊全文搜索、关键词高亮、开源/推荐/付费标签过滤、分页、/ 键聚焦搜索框。 数据源说明 原始的 Awesome-Windows/Awesome 仓库已经 404，目前社区维护最活跃的是 0PandaDEV/awesome-windows（2.7k star），条目质量有门槛——维护者明确拒绝凑数工具，清单比较精。 维度 数据 软件总数 361 款 分类数 36 个 开发者分类 12 个（置顶 + 一键筛选） 最大分类 系统工具 32、效率工具 24、安全 17 自动更新 和 Mac 版一样挂了每周定时任务（周一 09:30）：拉取上游最新代码 → 重新解析生成页面 → 上传预览服务器，新增软件一周内自动收录。 ...

摘要：GitHub 上的 jaywcjlove/awesome-mac 是最大的 macOS 软件清单之一，但 1000+ 条目堆在一个 Markdown 里，找东西全靠肉眼滚。我做了一个单页检索版：把整份清单解析成结构化数据，支持即时搜索、分类筛选、标签过滤，收录 1110 款软件、24 个分类，并且每周自动跟随上游更新。在线地址：fxio.site/p/awesome-mac.html 为什么不直接看 GitHub 仓库？ awesome-mac 仓库很好，但它本质上是一份超长 Markdown： 1100+ 款软件按目录顺序排列，找一个「录屏工具」要滚很久 没有搜索框，浏览器 Ctrl+F 只能匹配文字，匹配不到分类语义 无法按「免费 / 开源 / App Store」快速过滤 检索页把 README 解析成 JSON，前端纯静态渲染，解决了这三个问题。 功能一览 功能 说明 🔍 即时搜索 按名称、描述、分类模糊匹配，命中关键词高亮 📂 分类筛选 24 个分类：开发者工具、设计和产品、AI 工具、音视频、阅读写作等 🏷️ 标签过滤 开源 / 免费 / App Store / 原生，一键筛选 📦 GitHub 直达 开源项目卡片直接带 GitHub 链接 🔗 点击即开 点卡片直接打开软件官网 整页是单个 HTML 文件（约 334KB），数据全部内嵌，无后端依赖，离线也能用。 数据规模（2026-08-05） 1110 款软件，24 个分类 前三大类：其它实用工具 307、开发者工具 202、设计和产品 126 AI 工具分类已有 39 款，是最近增长最快的分类 自动更新 本地配了一个每周定时任务：拉取 awesome-mac 最新代码 → 重新解析生成页面 → 上传到预览服务器。上游新增软件一周内自动收录。 ...

Presto 与 Doris 企业应用场景研究：一个「借灶炒菜」，一个「自建中央厨房」 同为 OLAP 赛道的明星项目，Presto 和 Doris 却代表了两种截然不同的企业数据架构路线。本文从真实企业场景出发，拆解两者的架构基因、适用边界与组合打法，给选型一个不模棱两可的答案。 一、先说结论：它们根本不是同一类物种 很多企业选型时的第一个错误，是把 Presto 和 Doris 放进同一张跑分表里比快慢。这就像拿「外卖平台」和「自建中央厨房」比出餐速度——它们解决的不是同一个问题。 一句话定性： Presto（含 Trino）是「查询引擎」：自己不存数据，靠 Connector 对接 Hive/S3/MySQL 等存储，强项是跨源联邦与即席分析。借灶炒菜，灶台是别人的。 Doris 是「实时数仓」：自带存储引擎（列存 + 索引），数据要导进来，换来的是高并发、低延迟、可更新的全套数仓能力。自建中央厨房，从采购到出餐全包。 这个「存不存数据」的分野，决定了后面所有场景的适配差异。 二、架构基因对照 维度 Presto/Trino Apache Doris 定位 联邦查询引擎（计算层） MPP 实时分析型数据库（存算一体，3.0 起支持存算分离模式） 数据形态 不存数据，Connector 现拉 数据导入自有存储（列存 + 排序键 + 倒排索引） 执行模型 内存流水线，失败整体重跑 MPP + Pipeline 向量化执行，支持落盘容错 写入能力 基本只读（INSERT 有限） 支持实时更新（Unique Key）、流批一体导入（Kafka/Flink/Routine Load） 并发能力 中低并发大查询 高并发短查询友好（数千 QPS 点查场景可扛） 生态协议 ANSI SQL + JDBC/BI 全兼容 MySQL 协议兼容，BI 工具直连 运维形态 无状态计算集群 + 外部存储 有状态集群，3.0 存算分离模式后亦云原生化 注意 Doris 3.0 这个变量：它也支持了存算分离（数据放对象存储、计算节点弹性伸缩、缓存加速），还强化了湖仓一体能力（直接查 Hudi/Iceberg/Paimon）。也就是说，Doris 正在往 Presto 的领地伸手——但底色依然是「有存储、有索引、可更新」的数仓。 ...