WorkBuddy operates the browser with Browser Use. Indeed, very nice!

Recently, the most prominent capability in the AI circle over the past half year is letting AI operate software automatically. There are two representatives:

• One is browser use, AI controlling the browser itself, opening pages, clicking buttons, filling forms;
• The other is computer use, directly controlling applications on the whole computer.

These two capabilities did not appear out of thin air. computer use was first released by Anthropic in October 2024 with Claude 3.5 Sonnet. The term browser use was popularized by an open-source project of the same name; by 2025 it had become one of the most popular open-source browser automation frameworks.

Large-scale use by ordinary users began in April this year. OpenAI's Codex desktop app bundled computer use with a built-in browser, letting you use one sentence to have AI click pages and run operations for you. Developers abroad played with it in all sorts of ways. But few people in China have actually tried it; overseas subscriptions and network barriers kept most out.

Recently, Tencent's WorkBuddy also launched its browser use capability. No overseas account, no fiddling with the network—install a client and you can use it.

If you haven't used WorkBuddy, watch the one-minute intro below. If you're familiar, skip to the feature section.

What is WorkBuddy?

If you've never encountered it, spend half a minute getting to know it.

WorkBuddy is Tencent's AI office workbench, made by Tencent Cloud's CodeBuddy team. You give it tasks in plain language, and it breaks down and executes the tasks itself—writing documents, making spreadsheets, writing code, all can be assigned. You can log in directly with WeChat, QQ, or WeChat Work accounts. It's available on computer, mobile, and WeChat mini-program.

[image]

Its popularity has surged in the past six months. In July, monthly visits exceeded 20 million, far ahead of similar products, ranking first in domestic AI office desktop products.

Tencent is clearly pouring resources into it. In October, it was bidirectionally integrated with WeChat Work, and it can call on WeChat Work capabilities like messages, documents, meetings, and cloud storage. It is said that WorkBuddy has become Tencent's third strategic product after QQ and WeChat.

This browser control is one step in its rapid iteration. Those familiar with it can read on.

---

WorkBuddy's update is quite powerful

WorkBuddy recently added a new feature that lets AI directly control your browser. The common name for this kind of capability is browser use. Install a browser extension, and it can in your already-logged-in browser open pages, click buttons, and scroll.

It works in a separate tab group with its own cursor, doesn't grab your mouse, and doesn't occupy the window you're viewing. It runs its own thing; you can switch to replying to messages or reading documents. With the mobile app, you can also assign tasks to your computer anytime, without having to stay in front of the screen.

When I saw this feature, my first thought was, isn't this just browser automation? Letting a machine operate a browser for humans is already a rich field. Early on it relied entirely on writing scripts, from Selenium to Playwright. Suddenly there's something that says no scripts needed—one sentence and it clicks by itself. Worth a try.

Compared with traditional scripting, what's the difference

The old way of letting browsers do work for people, in the testing industry, is writing scripts. Element location, explicit waits, assertions, reports—built layer by layer. The two most painful problems are login state and the fact that when the frontend is redesigned, locators fail en masse.

browser use bypasses both. It operates the already-logged-in browser you're using, so login state is naturally not an issue. It also doesn't rely on locators to find elements; AI looks at the page itself and recognizes which is the search box, which is the next-page button. If the page changes, if buttons move or change style, it can still find them.

There are costs, and they're not small. A run takes a few minutes, and the path may differ each time. These two factors mean it can't replace regression scripts for now. I'll go into that later. First, let's install the feature and try it.

Installing it first

The entry point is in the client's settings. Update WorkBuddy to the latest version, open settings, find the agent section, and there's the browser extension installation entry.

[image]

I use Chrome. Select Chrome extension, click Go to Install, it jumps directly to the Chrome Web Store, click Add to Chrome. The extension also supports Edge and QQ Browser; install whichever you use.

[image]

Don't close the settings page after installing; you also need to turn on the "Allow WorkBuddy to control browser" switch. With both the extension and the switch done, it can actually control your browser. It won't work without either.

[image]

First task: go mess with my website

Once installed, you can use it. Open WorkBuddy's dialog, select the /workbuddy-browser-use skill, and send your request in plain language.

[image]

The task I gave it: open my test website, find the interview question bank section, pick the 10 most popular questions, and prepare a summary of answer points for each.

After receiving the task, it first opened the site itself, found the "interview question bank" column, and then went through each category page to collect questions. One detail I watched for a while: the list page only shows the first few questions by default. After reading them, it scrolled down on its own to read the rest. No one taught it that step.

[image]

When it finished, it handed back a list: 10 questions, each with a summary of answer points, neatly formatted.

[image]

Throughout the whole process, I gave it no code, no element locator, just one sentence. Finding the entry, traversing categories, scrolling, aggregating and formatting—all done by itself. That's the most intuitive difference between browser use and writing scripts. You describe clearly what you want; it decides how to do it.

An interlude: it quietly changed its counting criterion

Normally, "most popular" should be sorted by page views. In the final list it gave, the selection basis was written as "based on the frequency of appearance in current job postings." I initially thought it misunderstood. I opened the site and saw the page view numbers were empty—the statistics were broken again.

Each question on my website has page views; the counting uses a free third-party frontend library. This library has a known bug, sometimes working, sometimes not. When WorkBuddy went to read it, it happened to hit a broken moment and got no data. So it judged that the website has no page view metric. Actually it has one, just broken at that moment.

After deciding, it didn't stop to ask me. It switched its own criterion and picked the 10 questions by job-posting frequency. The result looked plausible, but the basis had been changed, and it didn't volunteer that.

Two things are worth remembering here.

The fallback capability is genuinely good. When data couldn't be read, it found a sensible criterion and finished the job without delay. But when verifying AI output, looking only at the result isn't enough; you have to verify the basis too. What standard did it use? Where did the data come from? Ask one more question during acceptance. Otherwise, you might not know the criterion has changed. This applies generally to using AI for testing work in the future.

The other is an unexpected bonus. If it hadn't tried to read the page views, I wouldn't have known the stats were broken again. It effectively did an online inspection, and I got a bug lead for free.

Second task: assigning multi-step tasks

After the interview question order finished, I tried something closer to daily use. Still on this learning website, I assigned three steps in one go. The exact phrasing is below.

Help me on the AI Test Development Learning Route website currently open in Chrome:
1. First, click the Test Eight-Stock Essay menu and summarize what's worth learning under this menu.
2. Second, click the Interview Question Bank menu and calculate how many interview questions there are in total.
3. Third, click the Resource Navigation menu and tell me how many tools are currently collected.

This time, something was different from last time. Last time, it opened the URL itself, and it was opened in WorkBuddy's built-in browser. This time, I wrote "the website currently open in Google Chrome" in my prompt, and it directly took over the tab I already had open. A prompt at the top of the browser first showed "WorkBuddy has started debugging this browser." It only started after I confirmed.

It sequenced the three steps itself: first click Test Eight-Stock Essay to summarize content, then go to Interview Question Bank to flip through categories and count questions, finally go to Resource Navigation to count tools. At each step, the dialog updated in parallel. Actions like loading skills and clicking elements were all recorded. By the second step, it had already been processing for nearly two minutes.

[image]

What other tasks can you give it?

After two rounds of hands-on testing, I roughly have a sense of it. I then went through the standard of "work a person would click in a browser" and ran a few common tasks. I'll list them below as a reference for you.

Testing

• Fast smoke tests after release. Something like: "Open the order system in the test environment, run login, create order, and refund each once. Wherever a page fails to open, reports an error, or a button can't be clicked, take a screenshot and record it." After it finishes, you get a checklist with screenshots. Blank pages, 404s, and broken buttons surface first. Writing a script for this is too heavy, and manually clicking is tedious; finally there's a place for it.
• Online inspection. List core pages and have it open them one by one on a fixed weekly schedule, checking titles, buttons, and errors. The page-view incident already proved this path works. Dispatch it from your phone during your Monday commute and the results are ready by the time you get to the office.

Development

• Self-test before submitting for testing. After writing a feature, let it click through the page flow for you, take the necessary screenshots, and avoid letting low-level issues leak to the testers.
• Dependency upgrade inventory. For libraries you want to upgrade, have it go to GitHub's Releases page, flip through recent changelogs, and pull out breaking changes into a separate list. Then decide whether to upgrade.

Product

• Experience walkthrough. Have it play a first-time user, start from the homepage, go through core features, and record everything that's confusing, un-findable, or un-passable. It's like a fresh pair of eyes.
• Feedback categorization. Have it go through app store comments and community posts, categorize by issue, and summarize. Much faster than reading one by one.
• Competitor research. Have it open features on a competitor's official website one by one and compile a list with screenshots, saving you half a day.

Office

• OA processes. For reimbursement, leave requests, approvals—give it the form info and have it fill in each step per the process.
• Weekly and monthly reports. Have it pull the numbers you need from backend systems and fill them into templates.
• Recruitment comparison table. Have it browse job sites, compile JDs for target positions into a comparison table with requirements, salary, and skill keywords at a glance.

Repetitive data entry

• Test data creation, operations bulk listing, admin moving spreadsheets—anything that's "copying from one page to another" can be tried with one sentence. For operations involving submissions, it will first list what it's about to submit and ask for confirmation.

A few boundaries to note before using

CAPTCHAs and sliders it cannot pass; it stops and waits for you to take over. Slow page loads or temporary site redesigns may cause failure; retry or run at another time.

More importantly, these two points. The path it takes each time may differ. The same task might go through navigation one time and search another. That's fine for exploration, but it's a fatal flaw for regression, which requires the exact same every time. It also has no concept of assertions; it checks results by self-reporting plus your spot checks. For strict validation of critical paths, scripts are still the boss.

On top of that, each run takes a few minutes, and high-frequency regression can't wait that long. So my approach is division of labor: hand it the one-off, low-frequency tasks that need human eyes; leave stable, high-frequency regression to Playwright.

---

This feature doesn't cost extra; just install the extension to try it.

My suggestion: don't start with a big task. First throw it the smallest annoying thing on your plate—post-release smoke testing, an inspection you've put off, competitor documentation sorting. Pick any one and stand there watching it open pages one by one. You'll quickly learn its temperament—which tasks you can safely hand over, and which you have to watch even after handing over.

After reading, you can probably feel that what's valuable is the sentence you use to assign the task. What should it look up, by what standard should it count, where does the basis come from—once you've thought these through, you can send a single sentence with confidence. If you haven't, no matter how hard it works, it's just replaying your vague requirements in the browser.