WEBVTT
Kind: captions
Language: zh

00:00:02.966 --> 00:00:04.766
This video is a little different

00:00:04.766 --> 00:00:06.533
It is a real debugging story from practice

00:00:06.733 --> 00:00:09.833
I asked an AI agent to make a daily AI trend analysis for me

00:00:10.066 --> 00:00:11.033
During the run

00:00:11.033 --> 00:00:13.100
it had actually obtained the correct data

00:00:13.100 --> 00:00:15.533
but in the end it made up a fake report for me

00:00:15.700 --> 00:00:16.833
What is even more interesting is

00:00:16.833 --> 00:00:18.266
after I fixed this problem

00:00:18.266 --> 00:00:19.500
and the system went live

00:00:19.500 --> 00:00:21.033
I fell into another trap

00:00:21.166 --> 00:00:23.300
You may run into both of these traps too

00:00:23.500 --> 00:00:24.700
Let me start with the background

00:00:24.833 --> 00:00:26.533
As an AI channel creator

00:00:26.533 --> 00:00:28.933
I need to track hot topics in AI every day

00:00:28.933 --> 00:00:29.666
to choose video ideas

00:00:29.666 --> 00:00:31.933
So I wanted an AI agent every early morning

00:00:31.933 --> 00:00:33.433
to collect data for me automatically

00:00:33.700 --> 00:00:35.100
from three sources

00:00:35.100 --> 00:00:36.900
popular AI posts on X

00:00:39.700 --> 00:00:41.700
AI projects on GitHub Trending

00:00:45.866 --> 00:00:48.400
and related trend movements on Google Trends

00:00:49.433 --> 00:00:50.766
When I open my computer in the morning

00:00:50.766 --> 00:00:52.666
I can see the topic report for the day

00:00:53.033 --> 00:00:55.100
I currently run two AI agents in parallel

00:00:55.100 --> 00:00:57.400
OpenClaw and Hermes agent

00:00:57.700 --> 00:00:59.333
On one hand I use them for topic selection

00:00:59.366 --> 00:01:01.000
and on the other hand I test their capabilities

00:01:01.200 --> 00:01:03.933
On the Hermes agent side, by building its own skill

00:01:04.033 --> 00:01:06.166
it can already complete this report fairly well

00:01:06.300 --> 00:01:08.166
But OpenClaw had a problem

00:01:08.333 --> 00:01:09.700
because of fake IP restrictions

00:01:09.700 --> 00:01:10.833
and Web fetch restrictions

00:01:10.833 --> 00:01:13.033
it could not get the latest X data

00:01:13.200 --> 00:01:15.033
I did not want to use the X API for now

00:01:15.033 --> 00:01:16.500
so I decided to try another approach

00:01:16.600 --> 00:01:17.766
Let OpenClaw

00:01:17.766 --> 00:01:19.733
directly control a Chrome browser already logged in to X

00:01:19.733 --> 00:01:21.633
and use the browser to collect the data

00:01:21.766 --> 00:01:23.000
Now let us start the setup

00:01:23.400 --> 00:01:26.100
Step one, enable Chrome remote debugging

00:01:26.333 --> 00:01:28.933
Step two, modify the OpenClaw config file

00:01:29.133 --> 00:01:31.433
Configure a profile called xbrowser

00:01:31.700 --> 00:01:33.066
specifically for this project

00:01:33.266 --> 00:01:34.666
and set the port properly

00:01:34.866 --> 00:01:35.600
Step three

00:01:35.600 --> 00:01:38.433
use a command to start Chrome in debug mode

00:01:38.700 --> 00:01:41.700
Step four, log in to your X account in this Chrome

00:01:41.833 --> 00:01:43.266
Finally, verify it with a command

00:01:43.266 --> 00:01:45.333
to see whether OpenClaw can take over this page

00:01:45.433 --> 00:01:46.833
From Chrome we can see

00:01:46.833 --> 00:01:48.966
it opened a page that is already logged in

00:01:49.133 --> 00:01:50.200
The takeover worked

00:01:50.366 --> 00:01:52.133
There is one trap here to be aware of

00:01:52.333 --> 00:01:54.233
Starting from Chrome 136

00:01:54.466 --> 00:01:57.333
remote debugging port and remote debugging pipe

00:01:57.533 --> 00:01:59.966
can no longer attach to the default user directory

00:01:59.966 --> 00:02:02.833
They must be used with a non default user data dir

00:02:02.833 --> 00:02:05.233
This is a change Chrome made for security reasons

00:02:05.400 --> 00:02:06.133
So here

00:02:06.133 --> 00:02:08.933
I created a dedicated profile called xbrowser

00:02:09.200 --> 00:02:11.400
After setup, I ran the first test

00:02:11.566 --> 00:02:13.133
and sent the prompt to OpenClaw

00:02:13.433 --> 00:02:14.700
The result came back quickly

00:02:14.866 --> 00:02:16.066
It looked pretty good

00:02:16.333 --> 00:02:17.733
Wait, something is wrong

00:02:17.900 --> 00:02:19.866
Look at the GitHub Trending section

00:02:19.933 --> 00:02:21.833
Why are the recent popular projects missing

00:02:22.033 --> 00:02:23.466
For example Hermes agent

00:02:23.633 --> 00:02:25.500
And why are there crypto projects

00:02:25.666 --> 00:02:27.700
I opened the original GitHub Trending page

00:02:27.700 --> 00:02:28.566
to compare it

00:02:28.766 --> 00:02:31.066
Number one is Andrej Karpathy skills

00:02:31.366 --> 00:02:32.866
Number two is Claudemem

00:02:33.100 --> 00:02:36.300
But these projects are not in the OpenClaw report at all

00:02:36.766 --> 00:02:37.833
What is going on

00:02:38.100 --> 00:02:39.566
Let us investigate step by step

00:02:39.833 --> 00:02:41.166
First, look at OpenClaw

00:02:41.533 --> 00:02:44.066
and see what raw data it got from the browser

00:02:44.400 --> 00:02:45.900
With these two commands, we can see

00:02:45.900 --> 00:02:49.066
the raw snapshot output is in snapshot

00:02:49.433 --> 00:02:52.833
Andrej Karpathy skills and Claude mem are both there

00:02:52.900 --> 00:02:54.266
So the data is correct

00:02:54.433 --> 00:02:56.300
Was OpenClaw lying

00:02:56.466 --> 00:02:58.966
So I added stronger constraints to the prompt

00:02:59.133 --> 00:03:01.300
requiring it to use only the snapshot data

00:03:01.500 --> 00:03:02.633
But the result still failed

00:03:02.833 --> 00:03:04.933
It still used data from who knows where

00:03:05.166 --> 00:03:06.900
It looked like the LLM was lying

00:03:06.966 --> 00:03:10.300
In other words, the MiniMax M2.7 I was using was lying

00:03:10.300 --> 00:03:12.533
I asked Claude separately about this phenomenon

00:03:12.733 --> 00:03:14.133
and it gave me an explanation

00:03:14.433 --> 00:03:16.000
It said this was context neglect

00:03:16.000 --> 00:03:19.500
combined with hallucination from prior

00:03:19.700 --> 00:03:22.533
context neglect means

00:03:22.666 --> 00:03:25.633
the model received new data but ignored it

00:03:25.833 --> 00:03:28.700
hallucination from prior means

00:03:28.833 --> 00:03:30.400
the model instead outputs

00:03:30.400 --> 00:03:32.466
old content it remembered from training data

00:03:32.633 --> 00:03:34.066
The theory is too dry

00:03:34.066 --> 00:03:35.833
Let us explain it with three analogies

00:03:36.100 --> 00:03:38.266
First, reciting is easier than reading

00:03:38.400 --> 00:03:39.800
It is like during an exam

00:03:39.933 --> 00:03:41.800
there is reference material next to the question

00:03:41.966 --> 00:03:43.366
but the student is too nervous

00:03:43.533 --> 00:03:45.400
and directly recites what they studied before

00:03:45.566 --> 00:03:49.400
Projects like system-design-primer have dominated Trending for a long time

00:03:49.666 --> 00:03:51.900
and appeared countless times in training data

00:03:52.133 --> 00:03:53.466
When the model sees GitHub Trending

00:03:53.466 --> 00:03:56.366
it automatically associates it with these familiar names

00:03:56.733 --> 00:03:58.900
Second, weak instruction following

00:03:59.100 --> 00:04:00.366
Use only snapshot data

00:04:00.366 --> 00:04:01.233
This instruction

00:04:01.433 --> 00:04:04.100
requires the model to actively suppress its prior knowledge

00:04:04.200 --> 00:04:05.766
But small models and distilled models

00:04:05.766 --> 00:04:07.400
cannot do this kind of precise control

00:04:07.766 --> 00:04:09.733
MiniMax is exactly this kind of model

00:04:09.966 --> 00:04:12.366
Third, attention decay in long context

00:04:12.433 --> 00:04:14.133
The snapshot data is very long

00:04:14.333 --> 00:04:16.033
The model may not have read it carefully

00:04:16.300 --> 00:04:17.966
and lazily used the default answer

00:04:18.233 --> 00:04:19.100
What should we do

00:04:19.200 --> 00:04:21.300
Try a smarter model

00:04:21.500 --> 00:04:25.733
So I switched the model from MiniMax M2.7 to GPT 5.4

00:04:25.900 --> 00:04:26.933
with the same prompt

00:04:26.933 --> 00:04:28.566
and the same snapshot data

00:04:28.800 --> 00:04:31.566
GPT 5.4 produced a completely correct result

00:04:31.566 --> 00:04:34.000
consistent with the current GitHub Trending page

00:04:34.100 --> 00:04:35.533
You can clearly feel that

00:04:35.633 --> 00:04:38.133
for long text plus strong constraint tasks like this

00:04:38.333 --> 00:04:39.733
models such as ChatGPT and Claude

00:04:39.733 --> 00:04:41.200
and Gemini

00:04:41.400 --> 00:04:42.800
are indeed better at reading context

00:04:42.800 --> 00:04:44.333
and suppressing prior assumptions

00:04:44.433 --> 00:04:45.900
by a noticeable level

00:04:46.366 --> 00:04:48.033
So how do we prevent this kind of issue

00:04:48.333 --> 00:04:50.700
First, add protection at the prompt level

00:04:50.766 --> 00:04:52.966
Make rules and constraints as specific as possible

00:04:53.233 --> 00:04:55.633
Second, use a stronger model for critical tasks

00:04:55.633 --> 00:04:57.133
for example GPT 5.4

00:04:57.300 --> 00:04:59.166
Third, and most importantly

00:04:59.433 --> 00:05:01.733
never blindly trust AI output

00:05:01.866 --> 00:05:04.633
just like every AI itself reminds you

00:05:04.833 --> 00:05:05.866
AI can make mistakes

00:05:05.866 --> 00:05:06.733
Always check the results

00:05:06.733 --> 00:05:10.233
After switching the model to GPT 5.4

00:05:10.366 --> 00:05:12.700
I added this into the OpenClaw scheduled task

00:05:12.733 --> 00:05:14.633
and the system officially went live

00:05:16.100 --> 00:05:18.733
But the next day, when I opened the report, there was another problem

00:05:19.000 --> 00:05:22.066
The system reported a timeout error and did not get X data

00:05:22.266 --> 00:05:25.266
But I saw that the background Chrome X page was actually open

00:05:25.500 --> 00:05:28.333
My first reaction was to keep adjusting the prompt

00:05:28.533 --> 00:05:30.666
and keep changing the OpenClaw system config

00:05:30.833 --> 00:05:32.000
But the more I tuned, the messier it became

00:05:32.000 --> 00:05:34.666
until I remembered the control group, Hermes agent

00:05:34.900 --> 00:05:36.666
Hermes had the same task

00:05:36.800 --> 00:05:39.166
and had been steadily outputting AI trend reports

00:05:39.333 --> 00:05:41.933
It was still using MiniMax M2.7

00:05:42.066 --> 00:05:44.066
and had not switched to GPT 5.4

00:05:44.133 --> 00:05:45.366
At that moment I realized

00:05:45.600 --> 00:05:47.400
this problem might not be in the model

00:05:47.566 --> 00:05:49.066
but in the execution method

00:05:49.266 --> 00:05:51.500
Did Hermes agent have a better method

00:05:51.700 --> 00:05:54.000
I found the skill generated by Hermes itself

00:05:54.366 --> 00:05:56.800
and asked Claude to break down what it was doing

00:05:57.000 --> 00:06:00.100
Claude found that Hermes bypassed the snapshot path

00:06:00.100 --> 00:06:03.100
It directly used Python plus WebSockets to connect to CDP

00:06:03.366 --> 00:06:05.633
which is Chrome DevTools Protocol

00:06:05.966 --> 00:06:09.033
Then it executed JavaScript to extract tweet data directly

00:06:09.233 --> 00:06:11.466
Fast, stable, and not dependent on browser operations

00:06:11.666 --> 00:06:12.300
The key point is

00:06:12.300 --> 00:06:14.700
this method can be migrated to OpenClaw completely

00:06:14.900 --> 00:06:16.066
I asked Claude to write a set

00:06:16.066 --> 00:06:18.166
of Python programs for OpenClaw

00:06:18.366 --> 00:06:19.966
with a new matching prompt

00:06:20.166 --> 00:06:22.200
The updated process is roughly like this

00:06:22.433 --> 00:06:24.300
X data is collected by a Python program

00:06:24.300 --> 00:06:26.700
which interacts with Chrome through CDP

00:06:26.966 --> 00:06:28.000
GitHub Trending

00:06:28.000 --> 00:06:31.200
is collected directly with HTTP requests plus regular expressions

00:06:31.366 --> 00:06:34.300
Google Trends is collected with the pytrends library

00:06:34.733 --> 00:06:35.600
In this way

00:06:35.800 --> 00:06:36.866
at the data source layer

00:06:36.866 --> 00:06:38.633
we no longer depend on expensive browser based

00:06:38.633 --> 00:06:39.600
automation

00:06:39.800 --> 00:06:42.333
The model is only responsible for summarizing and analyzing the data

00:06:42.500 --> 00:06:43.833
Stability improved

00:06:44.033 --> 00:06:45.866
and execution speed became much faster

00:06:46.066 --> 00:06:47.666
A 10x improvement is not exaggerated

00:06:48.000 --> 00:06:49.266
The task went live again

00:06:49.433 --> 00:06:51.133
and has been running stably for several days

00:06:51.300 --> 00:06:52.500
The result is also very satisfying

00:06:52.733 --> 00:06:54.533
This task can pause here for now

00:06:54.666 --> 00:06:56.300
I will keep observing it later

00:06:56.500 --> 00:06:57.333
Looking back

00:06:57.333 --> 00:06:59.033
I have three thoughts from this hands on test

00:06:59.266 --> 00:06:59.866
First

00:06:59.866 --> 00:07:02.833
AI agents really can directly control your browser

00:07:02.933 --> 00:07:04.433
but this method is unstable

00:07:04.633 --> 00:07:05.900
and it also slows things down

00:07:06.100 --> 00:07:07.866
Second, AI can make mistakes

00:07:08.000 --> 00:07:09.066
especially small models

00:07:09.066 --> 00:07:11.033
and models trained with distillation techniques

00:07:11.200 --> 00:07:13.033
Do not save money here for critical tasks

00:07:13.300 --> 00:07:15.300
Third, and the most interesting point

00:07:15.333 --> 00:07:17.266
when one AI agent cannot do something well

00:07:17.433 --> 00:07:20.233
you can let it learn from another AI agent approach

00:07:20.400 --> 00:07:22.200
Other stones can polish jade

00:07:22.433 --> 00:07:25.033
This old saying also applies in the AI field

00:07:25.133 --> 00:07:26.933
That is it for this episode

00:07:27.133 --> 00:07:28.700
If this episode helped you

00:07:28.700 --> 00:07:30.100
please like and subscribe

00:07:30.266 --> 00:07:33.333
In the next episode, I will continue sharing more AI practice experience

00:07:33.533 --> 00:07:34.533
See you next time