很多服务器不能直接访问互联网。常见原因不是机器坏了，而是它处在内网、受出口策略限制，或者云上环境没有配置公网出口。 这时很多人的第一反应是：给服务器装代理、改防火墙、开公网出口、加 NAT 网关。 这些办法都可以，但它们改变的是服务器所在网络的出口结构。权限不够时，往往做不了；临时排障时，也太重。 还有一种更轻的办法：如果你的客户端机器已经能访问互联网，并且本地已经有一个代理端口，比如 127.0.0.1:10808，就可以用 SSH 反向端口转发，把这个代理能力挂到服务器上。服务器访问自己的 127.0.0.1:18080，实际流量会穿过 SSH 隧道，转到客户端的 127.0.0.1:10808。 先假设有这样一组配置： 服务器地址：203.0.113.10 服务器 SSH 端口：2222 服务器 SSH 用户：ops 客户端本地代理地址：127.0.0.1 客户端本地代理端口：10808 服务器侧代理入口：127.0.0.1:18080 基于这组配置，核心命令如下： ssh -p 2222 \ -R 18080:127.0.0.1:10808 \ ops@203.0.113.10 这条命令的重点在 -R。 这条命令真正做了什么 先看完整结构： ssh -p 2222 \ -R 18080:127.0.0.1:10808 \ ops@203.0.113.10 含义是： -p 2222：连接服务器 203.0.113.10 的 SSH 端口 2222 ops@203.0.113.10：以用户 ops 登录服务器 -R 18080:127.0.0.1:10808：在服务器侧监听 18080，并把连接转发到客户端侧的 127.0.0.1:10808 连接建立后，链路变成这样： 服务器上的程序 -> 127.0.0.1:18080 -> SSH 反向隧道 -> 客户端 127.0.0.1:10808 -> 客户端本地代理 -> 互联网 注意，这不是让客户端访问服务器的端口，而是让服务器借用客户端的端口。

记录在 macOS 上通过 PyCharm 连接远程 Ubuntu GPU 主机开发 Isaac ROS 的推荐环境结构、配置步骤、调试方式与常见坑。

本文记录如何在 Amazon Lightsail 上搭建 WireGuard VPN，并使用 macOS 客户端连接。示例使用 Debian 13 (Trixie)，VPN 网段使用 10.66.66.0/24，WireGuard 监听 UDP 58222。 适用场景 需要一个轻量、配置简单的个人 VPN 使用 Amazon Lightsail VPS 作为公网入口 macOS 通过 WireGuard 官方客户端连接 希望所有流量都走 VPN，或者只让指定网段走 VPN 一、Lightsail 准备 1. 创建 Lightsail 实例 建议配置： 项目 建议值 Platform Linux/Unix Blueprint Debian 13 (Trixie) Plan 1 GB 内存以上 Storage 8 GB 以上 Public IP 建议绑定 Lightsail Static IP 如果只是个人使用，最低配通常已经足够。建议创建后立即绑定 Static IP，避免实例 stop/start 后公网 IP 变化。 2. 配置 Lightsail 防火墙 在 Lightsail 实例页面进入：

梳理 NVIDIA 在 AI Agent、Physical AI、机器人仿真、世界模型、边缘部署与治理平台上的产品布局，并分析其与具身智能大脑的协作边界。

最近需要将一个 Git 仓库 A 的 master 分支定期同步到另一个 GitLab 仓库 B，并且要求： 保留 A 的所有 commit 历史 B 最终以 A 为准 后续支持定期同步 最终整理了一套稳定可复用的方案。 场景 源仓库 A： ssh://git@example.com:10022/group/source-repo.git 目标仓库 B： http://gitlab.example.com/group/target-repo.git 目标： A/master -> B/master 并且： 保留所有 commit 后续支持自动同步 为什么不使用 git push –mirror 一开始尝试： git push --mirror target 会遇到： deny updating a hidden ref 因为 GitLab 内部存在： refs/merge-requests/* 这些隐藏 refs 不允许推送。 另外： master -> master (forced update) 说明： A/master 与 B/master 历史不一致 因此：

Codex 接第三方平台，只改 config.toml 两段： model_providers：声明网关地址、协议和密钥变量 profiles：绑定 provider 和具体模型参数 如果你是第一次找这个文件，默认位置通常是 $CODEX_HOME/config.toml，很多机器上会落在 ~/.codex/config.toml。 本文配置在 OpenAI Codex v0.123.0 下验证。版本变化快，后续行为以官方文档和 release notes 为准。 配置完成后，通过 profile 切换模型。 配置片段 # 模型平台 [model_providers.aliyuncs] name = "dashscope aliyuncs" base_url = "https://dashscope.aliyuncs.com/compatible-mode/v1" supports_websockets = false env_key = "MY_API_KEY" # 模型配方 [profiles.minimax] model_provider = "aliyuncs" model = "MiniMax-M2.5" model_context_window = 131072 model_max_output_tokens = 8192 关键字段说明 base_url: 第三方网关根路径，示例为 https://dashscope.aliyuncs.com/compatible-mode/v1。 supports_websockets: 是否启用 WebSocket 通道。这个配置走 HTTP，请设为 false。 env_key: 读取 API Key 的环境变量名，示例为 MY_API_KEY。 model_provider: profile 绑定的 provider 名，必须与 [model_providers.

导读 本文只讨论一个问题：把具身智能系统拆开以后，具身智能大脑到底负责哪一段。 这个问题不能靠抽象定义回答，只能放进具体场景里看。下面用一个动态非结构化实验室危险品二次分类场景，把执行层、空间智能、世界模型、具身智能大脑的边界拆开。 先把几个词说清楚，后面会轻松很多： SO101：一种低成本桌面机械臂，这里把它当作具身平台的代表 空间智能：负责理解几何关系、障碍物和局部物理安全的层 世界模型：用于估计动作发生后环境可能如何演化的预测模型 具身智能大脑：负责处理意图、风险和重规划的治理层 层级 职责 执行层 把指令转成电机和关节级控制 空间智能 识别几何关系并维持即时安全 世界模型 预测接下来可能发生什么 具身智能大脑 重建执行计划并做治理性决策 场景设定：动态非结构化环境下的实验室危险品二次分类 这里选一个适合 SO101 这类低成本机械臂平台的任务作为分析基准： 动态非结构化环境下的实验室危险品二次分类与意外处置。 选这个场景，有三个现实前提。 第一，没有昂贵的机械臂本体。分析对象不是高自由度、高精度的工业级平台，而是类似 SO101 这样的低成本机械臂。所以讨论重点不能压在本体性能上，只能压在系统层的任务组织、异常治理和风险控制上。 第二，搭不起复杂实验环境。没有高规格实验室，没有大规模传感器阵列，也没有完整的工业安全隔离设施。场景必须能在有限的桌面环境里复现，同时还能把任务目标、环境扰动和安全约束之间的冲突暴露出来。 第三，场景本身得能说明问题。它不能只是一个静态抓取 demo，不然看到最后还是感知和轨迹执行，执行层、空间智能、世界模型、具身智能大脑的边界都拉不开。实验室危险品二次分类这个任务同时带着语义目标、动态扰动和风险后果，正好能把系统真正要回答的问题逼出来。 这个场景同时带着三类复杂性： 指令是模糊的，需要做语义对齐 环境是动态的，执行中会发生突变 决策带有安全后果，不能只追求动作完成 用它来检验这四层的边界，够用了。 边界零：执行层负责驱动机械臂，不负责理解任务 这里的执行层包括运动控制、轨迹跟踪、伺服驱动、夹爪开合、关节级控制和底层安全联锁。它接收上层给出的目标位姿、轨迹段、速度约束、抓取力度或停止指令，再把这些东西变成电机、关节和末端执行器真正能执行的控制信号。 执行层的职责包括： 将目标位姿或轨迹转换为关节级控制命令 保证轨迹跟踪、速度控制和夹爪执行 在控制周期内维持伺服稳定性和执行精度 响应急停、限位、力控阈值等底层保护机制 这一层管的是动作怎么稳定、可重复地落到机械臂上。 边界一：具身智能大脑处理意图，不直接下沉到动作控制 先看任务输入。 把桌面上所有带红色标签的试剂盒放进回收箱，不要碰到那个蓝色烧杯。 这句话看上去很简单，但里面已经埋了很多约束： “所有带红色标签的试剂盒"不是一个固定坐标，而是一类语义目标 “放进回收箱"不是单步动作，而是一串子任务 “不要碰到蓝色烧杯"不是建议，而是一个硬约束 这里关键不是动作序列，而是执行计划。 这一阶段，具身智能大脑负责意图对齐： 识别用户到底想处理什么对象 明确哪些对象是可操作目标 明确哪些对象是绝对不能碰的约束物 把自然语言指令拆成可执行的子目标链 把模糊的人类目标，整理成带约束的执行计划。 边界二：空间智能看几何变化，具身智能大脑重建执行计划 再看一个执行中断事件。 SO101 正在抓取一盒带红色标签的试剂盒，实验室工作人员意外碰撞了桌面。结果有两个变化同时发生： 药盒相对原位置偏移了大约 5 厘米 蓝色烧杯朝机械臂原有运动路径方向倾斜 空间智能负责什么 空间智能负责对几何变化做快速感知和即时响应。 它看到的是： 目标位置变了 障碍物姿态变了 原路径的碰撞风险变高了 它先保物理安全闭环。

这篇文章记录一次小范围实践：在 AI 开发时代，如何通过 Harness Engineering 给协作者加上清楚的边界。 问题并不抽象。代码库里已经出现了新的协作者。它可能是 Codex、Claude Code、Cursor。它能读代码、改文件、跑命令、提 PR。风险也随之变化了。关键不再只是“它会不会答错”，而是“它有没有权力改不该改的东西”。 只靠提示词约束不够。上下文会漂移，任务会扩张，模型会误判，人也会口头越权。更稳妥的做法，是把边界从提示层压到执行层。 为什么 AI 协作者更需要隔离 传统团队协作里，权限问题很多时候由人来兜底。一个经验足够的工程师通常知道什么目录不能碰，什么配置不能改，什么操作需要再次确认。AI 协作者没有这种默认判断： 它行动很快，但不天然理解组织边界。 它能执行很多事，但不天然知道哪些事情不该做。 它在单次任务里看起来“理解了约束”，不代表下一轮仍然稳定遵守。 所以安全隔离的重点，不只是“让模型更听话”，而是让越界本身更难发生。这也是这里对 Harness Engineering 的理解：先把边界做成可读取、可检查、可执行的工程约束。 这次实践：把仓库变成一个带边界的执行 Harness 这套机制不复杂，重点是先把最小边界立起来。做法大体有四步：识别协作者身份、加载对应权限、按目录最小授权、把扩权能力留在人手里。 1. 用 Git 身份识别当前协作者 进入仓库后，先读取： git config user.name 这里把这个值当作协作者身份入口，而不只是提交记录上的一个名字。后续权限文件直接按这个名字映射，比如： docs/access_policy/<user.name>.md 这样做的好处很直接：人类和 AI 可以共用同一套身份入口。 2. 默认只读，而不是默认可写 如果没有找到与 user.name 对应的权限文件，就回退到： docs/access_policy/default.md 默认策略里没有任何 Writable Dirs，也就意味着整个仓库只读。 这样做把安全模型从“默认信任，出问题再收缩”改成了“默认拒绝，明确授权后再开放”。对 AI 协作者来说，这比单纯依赖提示词稳得多。 3. 权限按目录白名单定义 每个协作者都有一个独立的权限文件，里面至少定义四部分： Identity Writable Dirs Read Only Dirs No Read Dirs Rules 这意味着协作者拿到的不是整个仓库的写权限，而是自己负责区域的写权限。这样至少能缩小误改和误操作的半径。 4. 策略文件只能由人维护，AI 不能自行扩权 这套机制里最关键的一条，是“谁有资格改授权”。docs/access_policy/ 被明确设为人类维护区，并在 AGENTS.

rtk 的定位很直接：它不是替代命令行，而是把命令行输出先做一层压缩、过滤和摘要，再交给 LLM。 对 Codex 这类 agent 来说，真正烧 token 的往往不是一句指令，而是后面那一大段命令输出： ls -la 把一整个目录细节全喷出来 git diff 带出大量上下文 pytest、pnpm test、cargo test 输出几百上千行日志 cat 一个大文件，直接把无关内容塞进上下文 所以想让 Codex 省 token，最有效的方法之一不是“少问一句”，而是减少无效输出进入上下文窗口。rtk 干的就是这个事情。 macOS 安装 如果你在 macOS 上，只想先快速用起来，最简单的是直接用 Homebrew： brew install rtk rtk --version 官方仓库还提供了安装脚本、cargo install --git 和预编译二进制等方式。 如果你不是 macOS，或者想看最新安装说明、初始化 hook 的方法，直接看官方仓库： https://github.com/rtk-ai/rtk rtk 是怎么帮 Codex 省 token 的 从 rtk --help 可以看到，它的描述是： A high-performance CLI proxy designed to filter and summarize system outputs before they reach your LLM context.

本文内容总结自 ABB 官方培训教程《Getting started with GoFa™ Tutorial》 1. 引言 如果从一般产品介绍的角度描述机械臂，常见写法通常会集中在负载、速度、臂展和应用行业上。但从软件工程师和系统集成工程师的视角来看，这样的介绍远远不够。因为在实际项目里，机械臂并不是一个孤立设备，而是一个需要接入控制系统、配置安全策略、定义工具模型、完成示教调试、接入上位系统并持续维护的工程对象。 机械臂的价值，不只在于它是一台协作机器人，更在于它围绕“机器人如何真正进入生产系统”提供了一整套较完整的工程链路。官方教程材料已经覆盖了这一链路的关键环节：从开箱、接线、控制器接口，到安全配置、手动引导、可视化编程，再到虚拟仿真和后续支持。把这些材料重新组织后，可以更清楚地看出机械臂在工程实施中的真实定位。 本文将不再沿用传统“产品亮点罗列”的方式，而是按照软件工程更熟悉的分析框架来介绍机械臂：先明确系统边界，再分析组成结构、接口与安全，再看开发方式、交互机制以及它在完整自动化系统中的职责分工。 产品 GoFa SWIFTI YuMi（单臂） Dual-arm YuMi（双臂） 型号代表 ABB GoFa CRB 15000 ABB SWIFTI CRB 1300 ABB YuMi IRB 14050 ABB YuMi IRB 14000 定位 通用协作机器人 高速工业协作机器人 小型精密单臂协作机器人 双臂精密协作机器人 轴数 6 轴 6 轴 7 轴 14 轴（每臂 7 轴） 最大负载 5–12 kg 7–11 kg 0.5 kg 0.5 kg/臂 最大臂展 0.95–1.62 m 0.9–1.4 m 559 mm 559 mm/臂 重复定位精度 ±0.