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 的项目或组。

标题里写的是 mitmprox，实际使用的工具名是 mitmproxy。 这篇文章只做一件事：在 macOS 上用 mitmproxy 抓一次 Codex 发送 hello 的请求，并把请求体导出成文本文件。 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.

导读 本信息搜集整理自网络，内容仅供参考。 智能体软件工程 #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.

让 ChatGPT 对 DeepSeek-R1-671B 和 DeepSeek-R1-Distill-Qwen-14B 解读的数据报告进行对比分析 1. 数据规模 14B报告：全国互联网宽带接入用户总数为63,586.2万户，相对较高的FTTH/O用户占比（约95%），100M速率以上用户和1000M速率以上用户分别为59,994.6万户和15,657.6万户。 671B报告：全国互联网宽带用户为6.36亿户，FTTH/O用户为6.06亿户，千兆用户为1.57亿户。671B报告中的用户规模较14B报告更全面，覆盖了更高的数据层面。 2. 区域分布 东部地区在14B报告中占全国用户总数的42%，领先于其他地区。在671B报告中，东部地区用户占比保持在42.0%，千兆用户占比为44.5%。 中部地区：14B报告显示中部地区占25%，671B报告称其为25.3%，变化不大，但671B报告指出该地区增速潜力较大。 西部地区：在14B报告中占27%，而671B报告显示为26.9%，说明整体用户基数仍然较高，但千兆渗透率偏低。 东北地区：14B报告中占6%，671B报告中占5.9%，均显示该地区规模最小，上行升级的需要明显。 3. 用户速度与技术渗透 在14B报告中，100M以上用户数量为59,994.6万户，且1000M用户为15,657.6万。671B报告中，100M及以上用户占比94.4%，而千兆用户渗透率为24.6%，显示出整个市场的提升空间。 671B报告的技术渗透率（如FTTH/O和千兆用户渗透率）分析更为详细，强调了各地区在技术普及上的差距，尤其是东北地区。 4. 重点省份表现 14B报告中提供了具体省份的用户数量和贡献，如北京、广东、四川等，明显指出了各省的主力贡献者。 671B报告同样列出了多个省份的千兆用户规模和渗透率，指出了省间的差异，并提出了关键关注和改进建议。 5. 改进建议 14B报告中建议各地区继续加大投入，特别是西部和东北地区应加强对超高速宽带的建设。 671B报告的建议更加细化，强调技术升级、差异化营销、和区域策略，如针对东北地区的千兆套餐补贴。 6. 未来展望 14B报告对未来发展持乐观态度，认为随着网络技术的普及，用户数量将持续增长。 671B报告则侧重于千兆用户的年增长空间和重点布局区域的选择，显示出其发展潜力的规划性。 总结 14B报告更侧重于用户数量和各地区的基本情况，而671B报告则强调了技术渗透率和未来发展的潜力。 对于运营商来说，671B报告提供的建议和分析更具指导意义，尤其是在如何解决当前问题方面。 希望这个对比分析能够帮助你更好地理解和评估这两个报告的内容！如果需要更深入的分析或具体细节，请告诉我。

使用 DeepSeek-R1-671B 解读数据 模型：DeepSeek-R1-671B 数据：2023年11月互联网宽带接入用户分省情况 来源：内蒙古自治区通信管理局政务公开数据 提示工程 我是运营商的经营分析人员，请根据以下数据生成分析报告 | 地区 | 互联网宽带接入用户 | FTTH/O用户 | 100M速率以上用户 | 1000M速率以上用户 | |--------------|---------------------|------------|-------------------|-------------------| | 全国 | 63586.2 | 60609.3 | 59994.6 | 15657.6 | | **东部地区** | 26694.7 | 25175.8 | 25177.7 | 6965.8 | | 北京 | 934.8 | 901.5 | 891.3 | 221.7 | | 天津 | 672.7 | 655.1 | 658.8 | 196.0 | | 河北 | 3178.7 | 2980.7 | 2908.

使用 DeepSeek-R1-Distill-Qwen-14B 解读数据 模型：DeepSeek-R1-Distill-Qwen-14B 数据：2023年11月互联网宽带接入用户分省情况 来源：内蒙古自治区通信管理局政务公开数据 提示工程 我是运营商的经营分析人员，请根据以下数据生成分析报告 | 地区 | 互联网宽带接入用户 | FTTH/O用户 | 100M速率以上用户 | 1000M速率以上用户 | |--------------|---------------------|------------|-------------------|-------------------| | 全国 | 63586.2 | 60609.3 | 59994.6 | 15657.6 | | **东部地区** | 26694.7 | 25175.8 | 25177.7 | 6965.8 | | 北京 | 934.8 | 901.5 | 891.3 | 221.7 | | 天津 | 672.7 | 655.1 | 658.8 | 196.0 | | 河北 | 3178.7 | 2980.7 | 2908.