Lei Zhang

智能体软件工程：AI在软件开发中的应用与挑战

导读本信息搜集整理自网络，内容仅供参考。智能体软件工程 #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 的产出速度，然后在"哇，这么快？“和"等等，它真能做到吗？“之间反复横跳。

Codex + Spec-Kit 开发 LeRobot Agent 的实践与反思

“现在问题解决了，但请你重新 Review 一下今天的几轮修改，看看是不是补丁叠补丁式的修改，如果是的话，重构成最优解”，这是我在这个项目里对 AI 说得最多的一句话。你也可以说 “review the code, think from greenfield” 或者 “/samplify”，但不管怎么说，这句话的核心意思是：当 AI 在一个已经快速迭代过的代码库里继续修改时，它很容易陷入“补丁叠补丁”的陷阱，而不是停下来重新思考最优解。过去一周，我做了个基于 LeRobot 的 SO-101 机械臂 PoC。最初只是一个能跑起来的遥操作脚本，后来长成具备配置驱动、基础测试、服务接口和调试界面的 MVP。这个项目并不是我一个人独立完成的。我主要搭起了大约 60% 的骨架和核心功能，包括命令行入口、配置体系、API 分层、Web 服务、调试面板（dashboard），以及大部分基础测试。到了后期，团队里的同事也逐步参与进来，补上了模型推理、训练以及一些更贴近业务场景的能力。现在的结构：命令行入口：teleoperate、record、replay、serve Python API 分层：src/api FastAPI 服务：src/webapi React 调试面板：dashboard/ 单元测试：tests/unit 配置文件：config/agent.toml 一句话概括：用 Spec-Kit 管"要做什么"，用 Codex 管"怎么更快做出来" 但这不是一个"AI 加 Spec-Kit 就一路顺风"的故事。中间有很多反复、修正和取舍。Spec-Kit 帮了我不少，也带来过混乱；Codex 让我省了很多重复劳动，也把我前端、协作和问题表达上的短板照得很清楚。这篇文章讲的就是这些真实经验。一、为什么一开始没有直接写代码表面上看这是个"硬件 + Python"工具，但做起来才发现是一整条链路的问题：读取 SO-101 的 follower、leader、camera 配置跑通 teleoperate（遥操作）支持 record（数据采集）和 replay（回放）把能力暴露成 HTTP / WebSocket 服务，方便外部调用做调试面板，把串口、相机、控制状态、任务状态可视化后续接入推理和 LLM，而不是推翻重来直接写代码很容易在第 3 步以后失控。配置解析、硬件连接、任务生命周期、Web 接口、前端调试、测试替身——这些边界一旦不清，后面每加一个功能都牵一发而动全身。

使用 API 接入 Github Copilot 提供的模型

使用 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 证书安装与自动续期

适用场景使用 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 vLLM性能基准测试：wrk压力测试详细报告

配置 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.

Awesome Text to Image Prompts

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.

DeepSeek-R1-671B vs DeepSeek-R1-Distill-Qwen-14B 数据解读对比

让 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 解读数据模型：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 解读数据模型：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.

Benchmark for BAAI/bge-3m on an Nvidia A800/CPU/Mac M1