Posts on lx技术笔记

一文读懂AI自动化核心：Workflow与Agent的区别，建议收藏

Sat, 14 Mar 2026 00:00:00 +0000

今天我们聊一个近期 AI 圈里的热门话题 — 和 Agent**。**

一提到 AI，大家总说“让 AI 帮我干活”，可真要让 AI 落地做事，离不开 Workflow 与。这俩到底在 AI 里扮演了什么角色，又有什么区别？

今天我们就来详细聊聊**，揭开 AI 自动化的秘密**。

1 Workflow：深耕多年的“流程老管家”

Workflow，也叫。很多人以为它是 AI 带火的新词，其实它早就在各行业成熟应用了。比如：

职场人熟悉的审批流：请假时，从提交申请到审批通过，每一步都有固定顺序，缺一不可；
程序员常用的持续集成：代码提交后，自动触发编译→测试→部署，全程按预设步骤走，无需人工干预；

这些场景的本质就是提前把规则写死，严格按照预设步骤执行。就像工厂里的流水线，螺丝拧几圈、零件放哪里，早就定好了，工人只要按流程走就行。

它的核心工作流也不复杂，主要分为四步：

触发：谁来启动这条流程？

满足某个条件就自动开跑，比如点击提交、到达某个时间点、检测到有文件上传。

编排：接下来按哪条路走？

先做什么、后做什么，遇到不同情况走哪条分支，都提前设计好，相当于流程的“路线图”。

执行：具体怎么干活？

按照路线图真正去办事：比如提交后的发送消息通知、计算汇总数据、调用外部接口等，把每一步操作落地。

结束：怎么收尾？

流程跑完后，再把结果告知相关人，更新状态、保存记录，让这件事有一个完整闭环。

可以说，传统 Workflow 就像一套按部就班、严谨执行的固定“剧本”，不会自主思考、也不会灵活变通。

而当 AI 时代到来，Workflow 也迎来了新的角色与价值。

AI 的落地离不开（LLM），但大模型再智能，也只是一个擅长理解生成、却不懂统筹调度的“超级大脑”。当我们需要把零散的思考变成可执行的步骤时，就需要一个统一调度的角色 — Workflow。它会决定什么时候调用大模型、让它处理什么内容、结果传给谁、下一步怎么走。

正是这样，传统工作流才真正具备了理解意图、生成内容的智能能力，升级为 AI Workflow。

比如 AI 智能客服，它的流程非常清晰：

用户咨询 → 大模型识别意图 → 生成应对答案 → 回复用户。

还有常用的 AI 生成社交文案的流程：

输入需求 → 大模型提取关键词 → 生成文案 → 人工微调 → 发布

Agent-browser浏览器自动化CLI

Wed, 11 Mar 2026 00:00:00 +0000

跨平台、功能丰富、极快：重新定义AI上下文通信的优先紧凑文本输出。

对于者来说，在开发AI Agent时与浏览器交互是一个频繁的过程。让AI Agent更高效地操作浏览器是一个具有挑战性的问题。最近，在搜索AI测试解决方案时，我发现了Vercel开源的agent-browser，这是一款专为AI Agent设计的自动化CLI。

agent-的特性：

基于引用：快照返回带有引用的可访问树。
Agent优先：高效利用AI上下文，节省token。
会话：支持多个具有独立身份验证的隔离浏览器实例。
功能完整：支持超过50个命令，包括导航、表单操作和截图。
跨平台：支持macOS、Linux和Windows平台。

1、安装agent-browser

在安装agent-browser之前，请确保您的计算机上已安装Node.js。

在命令行中输入以下命令。-g选项表示全局安装。

npm install -g agent-browser

成功安装agent-browser CLI后，继续输入命令agent-browser install，这将开始下载Chromium浏览器。

安装Chromium浏览器...
需要安装以下软件包：
playwright@1.58.2
确定继续？(y) y

成功安装Chromium浏览器后，命令行将输出成功安装的消息。

正在下载Chrome for Testing 145.0.7632.6 (playwright chromium v1208)...
162.3 MiB [====================] 100% 0.0s
...
✓ Chromium安装成功

2、使用agent-browser

2.1 打开网页

agent-browser open https://agent-browser.dev/

输出：

✓ 无头浏览器自动化 for AI
  https://agent-browser.dev/

2.2 获取当前网页的可访问树

agent-browser snapshot -i

输出：

- 链接 "Made with love by Vercel" [ref=e1]
- 链接 "agent-browser" [ref=e2]
- 链接 "16k" [ref=e3]
- 链接 "npm" [ref=e4]
...
- 按钮 "Ask AI" [ref=e26]

2.3 使用引用进行交互

agent-browser click @e3

输出：

开发板常见问题

Wed, 04 Mar 2026 00:00:00 +0000

问题类型	占比	可预防性
过热降频/关机	40%	⭐⭐⭐⭐⭐（加风扇即可）
电源不足	25%	⭐⭐⭐⭐（换好电源）
内核/驱动崩溃	20%	⭐⭐⭐（升级内核）
内存/存储故障	10%	⭐⭐（依赖硬件质量）
工具/配置错误	5%	⭐⭐⭐⭐（规范操作）

原文链接: 开发板常见问题作者: lixusocool

浏览器自动化agent体验（brower-use，magentic-ui-fara7B）

Tue, 03 Mar 2026 00:00:00 +0000

	优点	缺点
brower-use	使用官网SDK写一个python的api，挺好用的能识别网页绿色框框数量	官网api收费，使用免费的api不太好用github的部署麻烦，没有成功
magentic-ui-fara7B	部署简单成功也能识别绿色框框	调用的qubrid的api，几下就用完了。。。需要设置docker的普通用户权限

原文链接: 浏览器自动化agent体验（brower-use，magentic-ui-fara7B）作者: lixusocool

成功破解geetestv4极验滑动验证码

Mon, 16 Feb 2026 00:00:00 +0000

花了我两三天，结果还是好的达到了我的预期 (o゜▽゜)o☆[BINGO!]

先看下效果：

如图所示脚本运行可以自动点击join按钮和滑动按钮，按时签到薅羊毛！

我采用的是pyautogui+方式，非传统自动化工具如Selenium和Playwright，不过使用了DrissionPage来获取缺口图和背景图。

已经适配windows和debian系统，最新的浏览器（其他没试）。

分享源码给大家一起学习测试使用（不可用做非法用途！发生的非法事件与本人无关特此声明）

：https://github.com/haolixu/geetest-auto

：https://gitee.com/haolixu/geetest-auto

那个依赖我没搞定，尝试了pip > requirements.txt和pipreqs . –encoding=utf-8 –force

但是没啥用。。。还是缺依赖，你们有什么好的方法吗？

需要注意的是浏览器需要设置一下：

win：D:\浏览器\QQBrowser\QQBrowser.exe -sc=desktopshortcut -fixlaunch=0 —debugging-port=9222

：/usr/bin/qqbrowser-browser-stable %U -sc=desktopshortcut -fixlaunch=0 –remote-debugging-port=9222

原文链接: 成功破解geetestv4极验滑动验证码作者: lixusocool

Agent记忆技术及落地实践

Mon, 17 Nov 2025 00:00:00 +0000

做记忆模块搭建的相关研发工作，一开始认为agent的记忆就是维护上下文，应该和chatbot的对话管理差不多，但真的做一段时间之后，才发现和对话管理相比还是区别比较大的，而且记忆模块对agent的实现效果以及后期可扩展性有比较重要的影响。

agent记忆与chatbot上下文的区别

我们拿agent记忆与上下文来作下比较，暂且不考虑长期记忆，就拿短期记忆来作对比，短期记忆(工作记忆)主要就是维护上下文，更官方一点的说法就是上下文工程，那chabot的对话管理不是也是在维护上下文吗？那两者有什么区别呢？

目标

agent记忆和chatbot上下文的目标看上去是一致的:给LLM/agent添加合适的状态来做下一步的决策。但是从服务对象，组织形式和维护重点的扩展来看有比较大的区别。

服务对象

虽然两者都算是人机交互，拿服务的对象都可以算作是人，但从现阶段的主要技术实现来看，服务对象还是存在差异的。

chatbot的服务对象是人这个毋庸置疑，做图灵测试也是为了验证对面和你说话的那个AI，有没有可能骗过你，而从让你以为它是个人，chatbot展开的多轮对话也是围绕人的实际需求展开。

agent虽然也存在与人的交互，agentic workflow中一般也会有人工输入的节点，但现阶段我们搭建agent的主要任务，更多时候是在自动完成一个复杂任务，因此服务对象可以认为是复杂任务。

组织形式

从组织形式上来看，由于agent具备了行动能力，所以和chabot产生了组织形式的不同。

chatbot主要的构成是一问一答的形式，包括我们调用大模型api一般也遵循这个结构，可以表示为{[q0,a0],[q1,a1],…[qt,at]}。

agent记忆的构成以最常见的react模式为例，主要是动作(tool)和动作结果(tool_result)的时序集合，可以表示为{a0,o0,a1,01,…at,ot}。

维护重点

对于记忆和上下文，很重要的一个功能是维护，但维护的侧重点也是有所不同的。

chabot的上下文虽然也存在前后关联，不会每一轮都紧密联系，但会存在频繁的意图切换，如何理解意图并且实现有效的意图切换识别是上下文维护的重点。

而agent记忆的每一个步骤都是按迭代规划进行的，缺失某个步骤或跳过某个步骤都可能会导致任务失败，因此它的维护重点是如何在有限的窗口中记录对下一步决策产生影响的所需关键信息。

另外agent和chatbot还存在一个很大不同的点是的必要性。对于chatbot，长期记忆主要是记住个人信息和偏好用于个性化服务。而对于agent，长期记忆需要通过情景记忆来记住之前的迭代轨迹，这样不仅能通过检索的方式来获取与当前决策相关的上下文信息，还可以实现经验复用，在下一次遇到类似任务时，可以将之前的经验作为参考,马普所今年2月份发这篇论文时候就指出情景记忆是当前agent所缺少的[1]。

agent短期记忆-业界技术分享

anthropic

anthropic提到agent在长程任务上的三种管理上下文方式[2]包括:压缩,结构化笔记和采用子agent架构。

压缩通过对上下文关键内容的提取，改写和无关内容删除实现上下文瘦身；

结构化笔记是把关键信息以结构化形式存入笔记，让agent可以阅读到关键信息；

子agent架构则是通过子agent维护自己的独立上下文再将关键结果返回主agent实现上下文解耦。

oepnai

openai的短期记忆管理[3]则是围绕agent sdk来谈到管理短期记忆的两个主要方式:裁剪（trimming）和压缩（summarizing）。

压缩和anthropic的compact是一样的，裁剪就是把旧的历史信息直接剪掉。

trimming的好处是实现比较简单，延时友好而且不会引入偏移信息（相比压缩），但缺点也显而易见，裁剪的内容可能包含当前决策需要的信息，所以一般适用于任务独立，上下文关联不大，低延迟要求场景。

langchain & manus

langchain与最近的一次交流[4]提到manus的三种上下文管理方式:reduce ，offload context和isolate context。

reduce context包括将工具执行结果进行压缩放在窗口内，而降完整结果保存在文件系统中，在上下文触发窗口限制时对整个轨迹进行整体压缩；

context isolate类似于anthropic的sub agent方法，但细分为两种方式：对于简单任务main agent通过function call的方式将指令传递给子agent，子agent在自己的窗口执行任务；而对于复杂任务，子agent会和主agent共享上下文。

context offloading和anthropic的结构化笔记虽然都是将内容存入文件，但处理思路不一样。manus的方式是将大多数操作卸载到沙盒层，在沙盒中通过bash工具就可以实现多样化的文件读写操作，这样就可以把工具执行结果保存到文件，在需要时通过bash的grep等查询命令进行访问。另外manus的这个设计相当于把大部分先验知识文件化，让agent按需通过读取文件内容获取先验来指导行动，anthropic的skill实现应该也是类似的思路。

agent记忆-项目实践

初版记忆实现

在实际搭建agent时，工具模块，记忆模块，提示词模块是三个重要的基础模块。工具模块和提示词模块相对简单或者说比较成熟的方案，而记忆模块的搭建则有不同的设计思路和实现方式，但核心思路一致 - “给agent提供恰当的上下文”，但难就难在"恰当"，首先受限于LLM的上下文窗口，所以累计上下文就不能过长。

另外上下文中堆积无关或者重复的内容不但会影响推理规划，也是不经济的。还有一个重要原因是上下文中的内容对于agent来说不是等权重的，对于当前决策而言，有的内容相对其它内容就会更重要，类似于需要一个attention机制来选择关键信息，那以什么形式来管理上下文获取更相信的信息加入就尤为关键了。

在近期的一个agent项目实践中，实现记忆模块的初始版本，设定的原则是"状态是记忆的投影"，以记忆作为事实的唯一来源，同时要求不在agent中维护状态，把记忆事实作为状态来源，放入agent的上下文中让agent自己进行决策。思路看上去是没有问题，但实际测试后就发现想简单了。

对于agent而言本身依赖的LLM是无状态的，所以agent也可以认为是无状态的，但是记忆的目的就是为了让agent具有状态。在初版的实现里，每一轮迭代都把obs写入工作记忆，同时读取当前轮之前的工作记忆中的结构化历史信息，把obs作为上下文唯一来源，直接注入到下一轮迭代的上下文，这样做是比较省事，但是一旦agent内部迭代出现问题，因为obs和工作记忆之间的这种耦合设计，很难追溯问题来源。

第二版记忆重构优化

在发现第一版的问题后，开始进行第二版改进。第二版的改进主要是基于看到的相关的技术博客和论文，重新设计了记忆方案。首先记忆模块的目录设计应该把短期记忆和长期记忆做清晰分划分，维护当前agent迭代执行任务所需上下文的就是短期记忆(工作记忆)，而记录完整迭代过程的是长期记忆（情景记忆），产生对应产出的也是长期记忆(语义记忆)。其中比较容易混淆的是工作记忆和情景记忆，从持久化的角度来说，把工作记忆持久化就可以理解为情景记忆，但实际上是存在差别的。

对于一个agent的迭代轨迹{a0,o0,a1,o1,…at,ot},可以直接把这个迭代轨迹放入上下文，也可以对这个迭代轨迹的每一步进行摘要提取，仅保留关键信息和引用，比如某步生成了一个很大的结构化，在进入下一轮时没有必要把整个json全部放入上下文，可以只放入一个引用，但是会把完整的json存入情景记忆，在下一轮迭代使用这个引用时再从情景记忆中取出这个对应的json，这样能避免大段内容直接进入到上下文中。

同时还需要考虑到上下文长度限制和成本问题，一般的工作记忆还会考虑使用最近k轮的策略，上下文只保留最近k轮的迭代记录，但是全局信息以结构化的信息记录，把这个结构化信息也注入到上下文中，这样也不至于让agent丢失掉全局信息。而第一版的问题就在这里，状态不应该只是记忆的投影，状态是对记忆的删减和加工，实际上的改进就是在短期记忆和长期记忆之间加一个桥接适配层，来实现短期记忆和长期记忆的搭配使用。

而为了agent项目的阶段性扩展和迭代，在前期工程化实现时就应该考虑长期记忆。在一个agent的迭代循环里，如果迭代轮数比较长，上下文窗口和LLM的上下文利用效率已经开始明显下降，就需要考虑结合长期记忆使用了。而为了缩减上下文，在删减掉比较早期的迭代信息后，需要识别出长期记忆中已保存的迭代记录中，哪些记忆内容会对当前轮决策有用，就选择加入到上下文。这个一般会使用retrival的方法，从长期记忆中进行检索。技术实现上会结合结构化和向量检索，而实际的实践需要根据场景需求去做设计和调整记忆存储和读写方式，可以使用slot，sql数据库，向量数据库，图数据库等等。

实践过程汇总有一个原则可以参考：记忆模块在开始实现之初，就应该把短期记忆和长期记忆进行解耦设计，这不但为上下文管理留有比较大的优化空间，在符合可审计性原则之外还为经验复用和未来可能的RL积累数据基础。

同时第二版的改进上，还有一个比较重要的改进点是还原了obs的单纯职责，obs只应该对当前轮的act和执行结果进行记录，不应该注入历史内容，obs保持职责单一只把当前轮的执行和执行结果(或摘要)放到工作记忆，工作记忆再去通过记忆模块补充历史上下文，这样修改之后，obs和工作记忆的职责也分的比较清晰了。

另外在agent的工层化实现过程中，造成可审计比较困难的一个点就是对工程化实现过程的不同组件的职责理解和划分不清晰，一旦出了bug，bug溯因就会因为这种不清晰的边界设计增加debug的难度，所以需要在设计之初就厘清不同模块的边界再动手进行实现。

agent记忆相关研究进展

上面提到RL微调，就再展开谈一下在agent在记忆管理方向的相关研究。agent记忆管理是一个很复杂的问题，从工程角度来看，agent的记忆管理可以分为两类技术方案，一种将复杂问题简化，另外一种是自动化。目前相关的记忆研究在这两个方向论文也比较多，找到了几篇比较有代表性的论文。前者是提供系统化/可插拔的记忆管理底座框架，如[5]，A-MEM[6]，后者是将手动/规则维护记忆的方式转为自动化，如Memory‑R1[7]，MEM1[8]，Memp[9]， MEMSearcher[10]等。

服务器测试整理

Tue, 11 Nov 2025 00:00:00 +0000

(一) 测试工具（服务器）

/etc/systemd/system/natapp.service

编号	名称	版本	用途	工具状态
1	Unixbench	5.1.3	测试操作系统综合处理能力。	开源工具
2	Spec2006	2006	测试 CPU 性能。	商用软件
3	iozone	4.3.0	测试磁盘读写性能（Mb/s），包括随机、顺序读写、最大最小和平均读写速度等。	开源工具
4	Netperf	2.7.0	测试网络传输速率、网络吞吐率、网络响应时间等，包括 TCP、UDP 流吞吐速率、TCP 请求/响应、丢包率、误包率等。	开源工具
5	SPECjvm2008	2008	测试 JAVA 虚拟机的性能。	开源工具
6	LMbench	3.0	测试操作系统性能	开源工具
7	LTP	LTP 20160510	测试系统稳定性	开源工具
8	Stream	5.09	测试内存带宽性能	开源工具
9	FIO	2.1.10	测试磁盘读写性能	开源工具

(2) uos

deb http://mirrors.163.com/debian stable main
内核更新：
apt install linux-image* linux-header*
卸载多余内核：

apt remove linux-image-5.6.0-2-arm64

deb https://uos.deepin.cn/uos eagle main contrib non-free
deb https://enterprise-packages.chinauos.com/server-enterprise fou/sp2 main contrib non-free
apt-key adv –keyserver keyserver.ubuntu.com –recv-keys
deb https://professional-store-packages.chinauos.com/appstore eagle appstore
麒麟v10源：

deb http://archive.kylinos.cn/kylin/KYLIN-ALL 10.0 main restricted universe multiverse
deb http://archive.kylinos.cn/kylin/partner juniper main

定制版uos：

mkdir /tmp/livecd
mount -o loop uos*.iso /tmp/livecd
mkdir -p livecd/cd
rsync --exclude=/live/filesystem.squashfs -a /tmp/livecd/ livecd/cd
mkdir livecd/squashfs&&mkdir livecd/custom
modprobe squashfs
mount -t squashfs -o loop /tmp/livecd/live/filesystem.squashfs livecd/squashfs
cp -a livecd/squashfs/* livecd/custom
cp /etc/resolv.conf livecd/custom/etc/
cp /etc/apt/sources.list livecd/custom/etc/apt/sources.list
chroot livecd/custom apt install xrdp htop gnome-disk*
rm -rf livecd/custom/recovery*
mksquashfs livecd/custom ./filesystem.squashfs && chmod -R 777 ./*.squashfs

uos无需激活即可root：

nano /etc/pam.d/su
#auth    requisite           deepin_security_verify.so

命令行激活试用：uos

uos-activator-cmd -t

(3) unixbench

wget http://github.itzmx.com/1265578519/unixbench/master/5.1.3/unixbench.sh
chmod 777 *.sh && ./unixbench.sh
多核的话改一下run文件，第 109,110,111,112 行修改数字为当前系统 CPU 核数，然后./Run -c 核数
nano Makefile ，47行

1GL_LIBS = -lGL -lXext -lX11 lm

nano Run，111行

# '3d'  => { 'name' => "3D Graphics Benchmarks",'maxCopies' => 8 },

make all && ./Run graphics
1

(4) iozone

wget http://www.iozone.org/src/current/iozone3_487.tar
tar -xvf iozone3_487.tar
cd iozone3_487/src/current/
make linux
./iozone -a -i 0 -i 1 -i 2 -f /mnt/testfile -r 16m -s 8G | tee -a iozone.log
./iozone -a -i 0 -i 1 -i 2 -f /mnt/testfile -r 16m -s 16G | tee -a iozone.log
./iozone -a -i 0 -i 1 -i 2 -f /mnt/testfile -r 16m -s 32G | tee -a iozone.log
wgethttps://gitee.com/haolixu/test/raw/master/iozone.sh&& bash iozone.sh

(5) 远程桌面

apt install xrdp
apt install gnome*
echo “gnome-session –session=gnome-classic” > ~/.xsession
/etc/init.d/xrdp start

19.12.23更新！

Agent接口测试中实践

Mon, 10 Nov 2025 00:00:00 +0000

在接口测试中实现“自动解析文档→生成用例”的核心是通过**“文档结构化解析→元数据提取→场景规则映射→用例自动化编排”**的全流程自动化，结合的语义理解与测试领域知识，将非结构化的接口文档转化为覆盖全面、可直接执行的测试用例。

一、整体流程框架

整个过程分为4个核心阶段，由“接口解析Agent”和“用例生成Agent”协同完成，依赖“文档同步模块”“元数据存储模块”“规则引擎”三大支撑组件：

graph TD
    subgraph 准备阶段
        A[接口文档同步] --> A1[对接Swagger/OpenAPI]
        A --> A2[监听文档变更（Webhook）]
        A --> A3[历史文档版本管理]
    end
    
    subgraph 解析阶段（接口解析Agent）
        B[元数据提取] --> B1[基础信息：路径/方法/描述]
        B --> B2[参数信息：类型/约束/位置]
        B --> B3[响应信息：状态码/schema/字段]
        B --> B4[依赖关系：前置接口/动态参数]
    end
    
    subgraph 生成阶段（用例生成Agent）
        C[场景规则映射] --> C1[正向场景：合法参数组合]
        C --> C2[异常场景：参数校验失败]
        C --> C3[边界场景：临界值/极限值]
        C --> C4[依赖场景：接口调用链]
    end
    
    subgraph 输出阶段
        D[用例格式化] --> D1[Postman/JMeter格式]
        D --> D2[pytest脚本格式]
        D --> D3[测试管理工具格式（TestRail）]
    end

二、具体步骤与技术实现

阶段1：同步——确保解析源实时准确

目标：获取最新接口文档（如/OpenAPI），并监控变更以触发后续解析流程。

具体操作：

文档接入方式：

主动拉取：通过定时任务（如每小时）调用接口文档地址（如https://api.example.com/v3/api-docs），获取JSON格式的Swagger文档；
被动接收：配置Git Webhook，当接口文档代码（如后端项目的Swagger配置）提交时，自动推送最新文档至Agent系统。

文档版本管理：将每次获取的文档存储在版本库（如Git），标记版本号（如v2.3.1），便于后续对比变更（如参数新增/删除）。

阶段2：元（接口解析Agent核心工作）

目标：从接口文档中提取结构化元数据（基础信息、参数、响应、依赖），为用例生成提供“原材料”。

CSDN博客文章批量导出

Wed, 22 Oct 2025 00:00:00 +0000

脚本依赖环境安装指南

以下是为运行 CSDN 博客导出脚本（如 export_csdn_cf.py）而准备 Linux 系统环境所执行的一系列有效命令。这些命令主要用于安装运行时、及其依赖库。

# 1. 安装 Python 包管理工具 pip3
apt install python3-pip -y

# 2. 安装文件传输和解压工具
apt -y install lrzsz                    # 提供 rz/sz 命令，用于终端文件上传下载
apt -y install zip unzip                # 用于处理 zip 和 unzip 格式的压缩包

# 3. 安装重命名工具
apt install rename                      # 强大的 Perl 脚本，用于批量重命名文件

# 4. 配置 Google Chrome 浏览器安装源 (使用清华镜像加速)
#    下载并添加 Google 的 GPG 公钥以验证软件包完整性
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
#或者上传执行如下的命令
# cat linux_signing_key.pub |sudo apt-key add -
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

#    将清华镜像的 Chrome 源写入 APT 源列表
echo "deb [arch=amd64] https://mirrors.tuna.tsinghua.edu.cn/google-chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list

# 5. 更新软件包索引并安装 Chrome 及其系统依赖
apt update                            # 同步最新的软件包列表
# 安装稳定版 Google Chrome
# 下载 && dpkg -i去安装
https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
# 修复相关的依赖
apt --fix-broken install -y

# 6. 安装 Chrome 运行所需的底层库 (确保 headless 模式正常工作)
apt install -y \
    wget \
    unzip \
    libxss1 \
    libappindicator1 \
    libindicator7 \
    fonts-liberation \
    libasound2 \
    libatk-bridge2.0-0 \
    libgtk-3-0 \
    libdrm-common

# 7. （可选）修复可能存在的依赖问题
apt --fix-broken install -y           # 如果之前的安装出现中断或依赖错误，此命令可尝试自动修复

说明：

虽然核心抓取脚本export_csdn_cf.py使用的是cloudscraper，它不直接依赖浏览器，但如果您后续计划使用selenium或playwright等基于真实浏览器的自动化工具来应对更复杂的反爬机制（如 Turnstile 验证码），那么安装 Chrome 是必需的。
此处列出的lib*库是 Chrome 在无头（headless）模式下运行时常见的依赖项，能避免因缺少图形或音频库而导致的启动失败。
使用清华（TUNA）镜像可以显著加快在境内网络环境下下载 Chrome 的速度。

步骤一：安装 pip3 依赖

在开始编写和执行脚本之前，我们需要先配置好运行环境并安装必要的第三方库。

ARM硬件测试面试题

Fri, 01 Aug 2025 00:00:00 +0000

开发板有哪些存储，存储如何测试
如何决定测试标准，和老板开发开会决定还是用行业标准
你觉得你有什么长处在测试方面
蓝牙如何测试，命令是什么
自动测试有哪些方面的应用
串口是什么协议，WiFi有哪些协议
WiFi如何测试
USB接口如何测试
固件如何测试
python深拷贝和浅拷贝区别
python进程通信有哪些

原文链接: ARM硬件测试面试题作者: lixusocool

从单 Agent 到多 Agent 的案例落地实践

Mon, 02 Jun 2025 00:00:00 +0000

大家好，我是玄姐。

▼最近直播超级多，预约保你有收获

关于 Agent 的定义目前还没有形成共识，目前有3个代表性的定义：

流行最广的是前 OpenAI 研究与安全副总裁 Lilian Weng 对 Agent 的定义：Agent = LLM + Planning + Tools + Memory。

除此之外，LangChain 对 Agent 的定义为：使用 LLM 决定应用程序控制流的系统。

OpenAI 对 Agent 的定义是：Agent 是能够代表用户自主完成任务的系统。

尽管目前对 Agent 的定义还没形成共识，但是大家对 Agentic System（智能系统）基本的共识是：Agentic System 是一种有目标、基于环境的决策系统。与 LLM 最大的区别在于，Agentic System 可以与现实世界交互，从感知环境开始，做出决策并执行，影响环境，然后基于反馈调整，不断持续迭代循环。

—1—

Agentic System 架构设计剖析

一个完整的 Agentic System 架构包含四个核心组成部分：

感知：为大模型构建上下文信息。常见的方法包括检索增强生成（RAG），查询结构化数据（比如：数据库、网页内容）或者检索历史记录（比如：长短期记忆）。
决策：本质上是 Planning 规划过程。可以通过规则引擎（Workflow）实现，也可以由大语言模型（LLM）驱动（自主 Agent），或者借助外部规划器。在设计时需要权衡泛化能力和准确性–LLM 驱动的决策泛化能力强，但不确定性较高；而基于规则的工作流泛化能力较弱，但更可控。
执行：通过调用工具来改变环境。包括 API 调用（比如：REST、RPC、SQL、函数调用）或与图形软件的集成（比如：Anthropic 的 Computer use）。
反馈：用于评估和迭代的机制。反馈可以通过人工标注、规则或模型生成，更新可以是离线的或在线的。

使用cloudfare实现免费内网穿透

Fri, 24 May 2024 00:00:00 +0000

我系统是ubuntu18.04.6 LTS
执行以下命令：

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
 
sudo dpkg -i cloudflared.deb
 
cloudflared tunnel login
#这里会打开浏览器窗口登录cloudfare，我这里是之前绑定了域名，建议大家也绑定域名
 
cloudflared tunnel create vm1
#这里会生成下面所需的json文件
mkdir ./cloudflared && cd cloudflared/
 
nano config.yaml
#添加以下内容
tunnels: vm1
credentials-file: /home/lixu/.cloudflared/95b49dcc-XXXX.json
protocol: http2
ingress:
  - hostname: vm.nb404.cn
    service: http://127.0.0.1:80
    originRequest:
      disableChunkedEncoding: true
      noTLSVerify: true
  - service: http_status:404
 
 
cloudflared tunnel --config config.yaml route dns vm1 vm.nb404.cn
#这句命令会给域名增加vm的dns记录
 
cloudflared tunnel --config ./config.yaml run vm1
#这里就可以访问了，大家记得改成自己的域名

enjoy

解决ubuntu20+不能在vmare17复制粘贴的麻烦解决方案

Sat, 18 May 2024 00:00:00 +0000

先安装ubuntu18的版本，使用典型安装，因为它会自动安装open vm工具实现复制粘贴桌面自动大小功能，同时不要尝试手动安装open vm工具，我试过在ubuntu20+上面试过没用。
输入相关信息直接自动化一键安装。
重启后，执行以下命令升级系统，这个阶段可能需要等30min+

sudo apt upgrade
sudo do-release-upgrade -c

重启即可

24.5.19更新：

缺点：snap install node 会导致nodejs无法使用，缺少依赖

原文链接: 解决ubuntu20+不能在vmare17复制粘贴的麻烦解决方案作者: lixusocool

nano在centos7下中文乱码

Fri, 17 May 2024 00:00:00 +0000

nano ~/.bashrc
 
 
export LC_ALL=en_US.UTF-8  
export LANG=en_US.UTF-8

保存退出，重新登录终端让修改生效！

原文链接: nano在centos7下中文乱码作者: lixusocool

aws的linux其他端口无法访问问题

Thu, 16 May 2024 00:00:00 +0000

安全组设置：
一定要关闭本地代理才能访问，比如clash！

原文链接: aws的linux其他端口无法访问问题作者: lixusocool

linux的ollama卸载

Sun, 05 May 2024 00:00:00 +0000

  sudo systemctl stop ollama
  sudo systemctl disable ollama
  sudo rm /etc/systemd/system/ollama.service
  sudo rm $(which ollama)
  sudo rm -r /usr/share/ollama
  sudo userdel ollama
  sudo groupdel ollama

我是用官方安装的，卸载比较麻烦

建议用 install ollama

卸载也方便snap remove

原文链接: linux的ollama卸载作者: lixusocool

解决docker容器不能问本机网络

Fri, 03 May 2024 00:00:00 +0000

查看网络：

docker network list

选择一个bridge网络，重新部署容器的时候加进去– 1panel-network：

 docker run -d -p 3001:8080  --network 1panel-network

这样容器就可以引入本机网络的或者其他端口，建议关闭

原文链接: 解决docker容器不能问本机网络作者: lixusocool