本文内容总结自 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.

这篇文章只做一件事：在 macOS 上用 mitmproxy 抓 OpenClaw 在 onboard 引导流程中发送的请求包，拆开它的提示工程、Tool Loop 和长期记忆设计。 装包工具的使用可以参考 使用 mitmproxy 抓取 codex 数据包，这里不赘述。 因为每一步的 tools 内容都一样，所以除 Step 1 以外的步骤我就省略了这部分。 可以看到整个引导过程完全通过提示工程驱动工具完成。 Step 1. 系统启动后主动给大模型发送消息 Sender (untrusted metadata):\njson\n{\n \"label\": \"openclaw-tui (gateway-client)\",\n \"id\": \"gateway-client\",\n \"name\": \"openclaw-tui\",\n \"username\": \"openclaw-tui\"\n}\n\n\n[Mon 2026-03-16 22:15 GMT+8] Wake up, my friend! { "model": "coder-model", "messages": [ { "role": "system", "content": "You are a personal assistant running inside OpenClaw.\n## Tooling\nTool availability (filtered by policy):\nTool names are case-sensitive.

Qodo 的开源 PR-Agent 可以直接接入 GitLab Merge Request，在 MR 页面里生成描述、Review 结论和改进建议。对于内网自建 GitLab，最稳妥的方式是把 PR-Agent 作为一个本地 webhook 服务跑在 Docker 中，再通过 GitLab Webhook 把 MR 事件转给它。 本文记录一套在本地 GitLab 中落地的最小可用方案，目标是： 使用 Docker 部署 PR-Agent 接入本地 GitLab 在 Merge Request 中通过评论触发 /review、/describe、/improve 说明：本文使用 webhook 模式，适合自建 GitLab 和内网环境。对应镜像标签可使用 codiumai/pr-agent:0.32-gitlab_webhook。 前置条件 部署前先准备好下面几项： 一个可以访问 GitLab 的 Docker 主机 一个本地 GitLab 实例，例如 http://localhost:8080 一个 OpenAI 兼容模型 一个专门给 PR-Agent 使用的 GitLab 机器人账号 建议不要直接使用管理员账号，而是新建一个 pr-agent-bot 用户。 第一步：在 GitLab 中准备机器人账号 先在 GitLab 中创建一个专用用户，例如 pr-agent-bot，然后把它加入需要接管 Review 的项目或组。

这篇文章只做一件事：在 macOS 上用 mitmproxy 抓 Claude Code 发送请求包，拆开它的上下文工程、Agent Runtime 和工具编排方式。 装包工具的使用可以参考 使用 mitmproxy 抓取 codex 数据包，这里不赘述。 一次问答 Step 1. 会话标题生成阶段 不是交给大模型立即开始 Loop，认识问题重生成，此时不装配任何工具和技能 会话标题生成：该请求并非真正执行“分析项目”，而是先根据用户输入生成一个 3–7 个词的会话标题。 用户输入原样保留：messages 中直接保留用户原始请求，用于推断本次 session 的主题。 多模态消息格式：content 采用数组 block 结构，即使当前只有文本，也兼容后续插入图片、文件、工具结果等内容。 分层 System Prompt：system 被拆成多个 text block，分别承担计费信息、产品身份、具体任务说明。 平台元信息内嵌：通过 x-anthropic-billing-header 传递客户端版本、入口来源、计费标识等信息。 明确产品身份：固定注入 “You are Claude Code, Anthropic’s official CLI for Claude.”，确保模型始终以 Claude Code 身份响应。 示例驱动约束：system prompt 中提供了 Good / Bad examples，用于约束标题长度、大小写和表达方式。 严格结构化输出：通过 json_schema 强制要求只返回 { "title": "..." }。 禁止额外字段：additionalProperties: false 表示模型不能输出除 title 外的任何内容。 无工具调用：tools: [] 说明这一轮没有读取项目文件、执行命令或调用外部能力。 前置子任务设计：标题生成被拆成独立请求，通常发生在真正的代码分析和工具调用之前。 统一推理管线：即使只是生成标题，也仍然走完整的模型调用流程，包括 system、schema、stream、temperature 等字段。 流式输出复用：stream: true 表示即使是极小任务，也统一采用流式传输协议。 默认参数复用：max_tokens: 32000 明显超出需求，说明客户端复用了统一的大模型参数模板。 保留一定创造性：temperature: 1 让标题表达略有变化，但通过 schema 和示例避免输出失控。 面向机读而非聊天：整个请求设计更像“结构化子任务接口”，而不是传统自然语言聊天。 { "model": "qwen3.

这篇文章只做一件事：在 macOS 上用 mitmproxy 抓 Codex 发送请求包，拆开它的上下文工程、工具协议和运行时边界。 Step 1. 安装 mitmproxy brew install mitmproxy 确认安装成功： mitmdump --version Step 2. 启动抓包代理 打开第一个终端，执行： mitmdump --listen-host 127.0.0.1 --listen-port 8080 -w codex-hello.mitm 这一步会： 在本机启动代理 127.0.0.1:8080 把抓到的流量保存到 codex-hello.mitm 这个终端先不要关。 Step 3. 安装 mitmproxy 根证书 第一次启动 mitmproxy 后，会在本机生成证书： open ~/.mitmproxy 在 macOS 中操作： 双击 mitmproxy-ca-cert.pem 导入到“登录”钥匙串 打开“钥匙串访问” 找到 mitmproxy 证书 双击证书，展开“信任” 把“使用此证书时”改成“始终信任” 关闭窗口并输入密码保存 Step 4. 让 Codex 走本地代理 打开第二个终端，执行： export HTTP_PROXY="http://127.0.0.1:8080" export HTTPS_PROXY="http://127.0.0.1:8080" export ALL_PROXY="http://127.0.0.1:8080" export SSL_CERT_FILE="$HOME/.

导读 本信息搜集整理自网络，内容仅供参考。 智能体软件工程 #1｜智能体原生工作估算 《智能体软件工程》可能是一系列文章，记录我从传统软件工程向智能体软件工程的迁移过程。 一个老程序员的顿悟 我写了近二十年代码了。估算工期这件事，早已刻进肌肉记忆——拆任务、排优先级、乘以经验系数、加上联调和 buffer（冗余量），最后给出一个"两到三周"。这套方法论伴随我度过了瀑布、敏捷、DevOps 的每一次范式迁移，从未失灵。 直到 AI 编程到来。 我最近用 AI Agent 做一个 CLI 工具。脑子里的第一反应是这个工具的实现过程：解析参数、核心转换、校验逻辑、错误处理、测试，一整套下来，按古法编程怎么也得两三天。结果 Agent 从动手到交付，连半小时都没用完。 效率提升了吗？表面上看，当然。 但更深层的问题随之浮现：我甚至无法正确预判 AI 需要多久。 我的整个估算框架是锚定在"人类开发者"这个基座上的。多少行代码、多少次 debug、多少轮 code review。当执行者从人变成智能体，这套尺子就彻底失灵了。 更讽刺的是，AI Agent 自己也犯同样的错。你问 Claude 或 GPT：“做这个功能要多久？“它会一本正经地告诉你"大约 2-3 天”。因为它的训练数据里，Stack Overflow 和技术博客就是这么写的。Agent 在用人类的经验估人类的时间，然后自己十分钟干完。 我开始意识到，当软件工程迈向智能体软件工程（Agentic Software Engineering）的过程中，第一个需要变化的，就是这种"拿人的尺子量 AI 的活"的心态。 所以我写了一个 Skill，agent-estimation，专门解决这个问题。 问题的根源：人类时间锚定 我把这个现象叫做 Human-Time Anchoring（人类时间锚定）。 它的运作机制是这样的： AI Agent 在生成估算时，会不自觉地调用训练数据中的"集体经验”。一个 REST API 项目？论坛上说要一周。一个带实时图表的全栈 Dashboard？技术负责人在 Sprint Planning 里估了三个迭代。这些数字是人类开发者在人类的认知带宽、上下文切换成本、沟通损耗下产出的经验值。它们对人类成立，但对一个可以每 3 分钟完成一轮"思考→写码→执行→验证→修复"循环的 Agent 来说，完全不适用。 这导致了一个系统性偏差：AI 几乎总是高估自己的工期。 而我们这些老程序员，反过来也在犯同样的错：我们拿自己过去的经验去预期 AI 的产出速度，然后在"哇，这么快？“和"等等，它真能做到吗？“之间反复横跳。

使用 API 接入 Github Copilot 提供的模型 1. 获取 GitHub access token（Device Flow） 1.1 申请 device code export CLIENT_ID="Iv1.123456" export SCOPE="read:user" curl -sS -X POST "https://github.com/login/device/code" \ -H "Accept: application/json" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "client_id=${CLIENT_ID}" \ --data-urlencode "scope=${SCOPE}" {"device_code":"9c2e1edec2cb88521acfeda02f1cb23sb4ceedfa","user_code":"E12E-8762","verification_uri":"https://github.com/login/device","expires_in":899,"interval":5} 你会得到 JSON：device_code, user_code, verification_uri, expires_in, interval。 1.2 打开浏览器授权 访问 verification_uri，输入 user_code，同意授权。 1.3 轮询换 GitHub access token export DEVICE_CODE="9c2e1edec2cb88521acfeda02f1cb23sb4ceedfa" curl -sS -X POST "https://github.com/login/oauth/access_token" \ -H "Accept: application/json" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "client_id=${CLIENT_ID}" \ --data-urlencode "device_code=${DEVICE_CODE}" \ --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:device_code" {"access_token":"ghu_af2cHWUGwwyJ3SOKh7crBAHUplj72900zMne","token_type":"bearer","scope":""} 成功返回 access_token 后：

适用场景 使用 AWS Lightsail 托管服务器 使用 Lightsail / Route53 管理 DNS 使用 Nginx（宿主机或 Docker） 需要 通配符证书（*.example.com） 希望 证书自动续期、无人值守 一、整体架构说明（非常重要） Let’s Encrypt │ │ DNS-01 验证 ▼ Route53 / Lightsail DNS（权威） │ │ TXT _acme-challenge ▼ Certbot（dns-route53 插件） │ │ 自动续期 ▼ Nginx（reload 生效） ⚠️ 关键原则 _acme-challenge TXT 只能由 certbot 自动管理 禁止手动添加或残留 TXT NS（Name Server）必须与 DNS Zone 完全一致 二、前置条件检查清单 1. 域名 DNS 已交由 Lightsail 管理 在 Lightsail 控制台应看到： ✅ You are using Lightsail to manage the DNS records for your domain.

配置 DeepSeek-R1-Distill-Qwen-14B NVIDIA A40 vLLM vllm/vllm-openai:v0.8.5 NVIDIA-SMI 560.35.03 Driver Version: 560.35.03 CUDA Version: 12.6 wrk 测试方法 创建一个请求文件 cat > post.lua << 'EOF' wrk.method = "POST" wrk.body = '{"model":"deepseek-14b","messages":[{"role":"user","content":"写一个50字的短文"}],"max_tokens":50}' wrk.headers["Content-Type"] = "application/json" wrk.headers["Authorization"] = "Bearer your-api-key" EOF 10 线程 20 并发持续测试一分钟 [root@myserver wrk-4.2.0]# ./wrk --timeout 30s -t10 -c20 -d60s -s post.lua http://10.1.2.100:8080/v1/chat/completions Running 1m test @ http://10.1.2.100:8080/v1/chat/completions 10 threads and 20 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.07s 38.

Jesse Faden’s Double exposure, Midjourney style, merging, blending, overlay double exposure image, Double Exposure style, An exceptional masterpiece by Yukisakura revealing a fantastic double exposure composition of Jesse Faden’s (control) silhouette harmoniously intertwined with the visually striking details of a cyberpunk metropolis. While the road’s details are outwardly echoing through the fabric of the figure, beautiful tension climbs as the contrasting use of monochrome in the background maintains razor-sharp focus on the remarkable double exposure image.