从会说到会干：豆包工作 Agent 正式发布，这次是真的夯

Z_suger7

121人浏览 · 2026-08-31 16:45:43

Z_suger7 · 2026-08-31 16:45:43 发布

8 月 25 日，字节把「豆包工作」正式独立成一个 Agent 品牌。这不是又一次"AI 助手改名"，而是把 AI 从"陪你聊"推到了"替你干"。本文拆它的技术骨架，也聊一个几乎所有 Agent 评测文章都忽略、但决定你能不能真跑起来的东西——网络出口层。

一、先说结论：这次"夯"在哪

"夯"这个字最近被用烂了，但放在豆包工作身上其实挺准确——它不是花活儿，是往下砸的地基。

先摆事实。8 月 24 日，字节先把 TRAE、扣子（Coze）团队整体并入豆包体系；8 月 25 日，豆包工作独立品牌+独立桌面客户端发布。这个节奏很说明问题：先把做 Agent 的人和做 IDE 的人塞进一个屋，再对外发产品。 一个是从代码侧理解"任务怎么被拆解和验证"，一个是从工作流编排侧理解"工具怎么被调用和串起来"，两拨人合流之后推出的东西，和单纯在对话框上加个"深度思考"按钮，不是一个物种。

它的能力清单我按技术层次重新排一下，比官方宣传口径更清楚：

层次	能力	技术含义
规划层	目标 → 任务拆解 → 长流程推进	有 planner，不是单次 completion
工具层	技能（Skills）、连接器（Connectors）、工作伙伴（多 Agent 协作）	有可插拔的 tool-use 接口与调度
执行层	浏览器操作、电脑操作、云电脑托管、手机远程遥控	有 runtime sandbox，能跨进程操作真实软件
上下文层	飞书深度打通，继承权限内的聊天/文档/日程	有企业级 RAG + 权限继承，不是临时上传文件
安全层	设备接入、权限、额度管控、加密、操作审计	全链路审计，企业能过合规

看懂这张表，你就明白它跟"会写周报的 ChatGPT"的差距在哪了。

关键在于执行层。前四层大家都在做，最后一层——让 AI 真的伸手去操作浏览器、打开 Excel、填表单、翻页抓数据——才是 Agent 从 demo 走向生产的门槛。而这一层，恰恰也埋着最大的坑。

二、技术拆解：Agent 为什么"能干"比"会说"难十倍

2.1 从 completion 到 loop

传统 AI 助手是一次性的：input → model → output。Agent 是循环：

目标 → 规划 → [ 调用工具 → 观察结果 → 修正计划 ] × N → 交付物

这个循环听起来简单，工程上要命的地方在三点：

第一，状态管理。 一个"帮我复盘上周 Q3 项目进展"的任务，中间可能读 12 个飞书文档、拉 3 张多维表格、跑 2 次浏览器查外部数据。任何一步失败，你得知道从哪重试，而不是从头再来。豆包工作把中间产物沉淀回飞书，本质上是把 checkpoint 存在了企业知识库里——这个设计很聪明，既解决了状态持久化，又顺手解决了"知识复用"。

第二，可观测性。 长流程跑 20 分钟，中间黑箱，用户会疯。你看到的"正在打开浏览器 / 正在创建文件"这种执行日志，不是 UI 装饰，是 Agent 产品的生命线。没有它，调试成本会从"改一句提示词"变成"重跑一遍祈祷"。

第三，容错边界。 哪些步骤能自动重试，哪些必须停下来问人，这个策略比模型本身更能决定体验。豆包工作在关键写操作前会停下确认，这是负责任的设计——宁可多问一次，也别把用户的 Excel 覆盖掉。

2.2 "指哪改哪"是个被低估的工程优化

官方重点讲的"框选局部修改，无需整体重新生成"，营销口径是"省时间、省算力"。但站在工程视角，它解决的是长上下文任务的收敛问题。

生成一份 30 页的 PPT，你要改第 17 页的一个图表。如果每次都全量重生成，你会遇到两个问题：一是幻觉累积（改 A 处，B 处悄悄变了），二是成本失控。局部 diff 编辑把"生成"变成了"打补丁"，让长任务具备可收敛性。这是从"AI 写手"到"AI 同事"的关键一步——真人改文档也是打补丁，不是重写。

2.3 飞书打通：真正拉开差距的地方

这一条值得单独说。

大部分 Agent 是失忆的天才：能力很强，但不认识你的同事、不知道你们上周吵了什么、没看过那份只有内网能打开的项目文档。你每次都得重新喂上下文，喂完它还可能理解偏。

豆包工作用飞书账号登录后，继承的是权限范围内的企业上下文。注意"权限范围内"这五个字——它不是粗暴地把企业数据全灌进模型，而是复用飞书既有的权限体系。这在技术上意味着 Agent 必须有身份（identity）、有权限边界（scope）、有审计轨迹（audit trail）。

这就是为什么我说它是"企业级 Agent"而不是"个人效率工具"。个人工具拼的是模型智商，企业工具拼的是权限模型和数据治理。后者难做，但一旦做通，护城河比模型能力深得多。

三、被忽略的一层：Agent 的"网络出口"

现在聊点别的评测文章不太讲的东西。

豆包工作可以操作浏览器、抓网页、跨软件采集信息——这很酷。但只要你真跑过这类任务，就会撞上一堵墙：

Agent 打开第 3 个竞品网站 → 403
Agent 换一个 → 验证码
Agent 再换一个 → 数据显示"该地区不可访问"
Agent 继续 → IP 被临时封禁，整个任务链断在第 7 步

问题不在模型，在网络层。

一个运行在你本机（或云电脑）上的 Agent，所有请求走的是同一个公网 IP、同一个 TLS 指纹、同一个地理位置。目标站的风控系统看到的是：一个 IP 在 30 秒内以非人类节奏访问了 200 个页面。对人类用户来说这叫"正常办公"，对风控系统来说这叫"爬虫"。

于是出现一个荒诞的局面：你的 Agent 有 130 的智商，但网络出口是裸奔的。

而且这个问题会随着 Agent 能力增强而加剧。以前人工采集，一天翻 50 页，风控阈值内；现在 Agent 一小时翻 500 页，直接踩线。能力越强，越容易被掐。

3.1 三类典型翻车场景

场景 A：竞品/行业调研 Agent
“帮我调研 20 家竞品官网的定价页、产品更新日志、招聘 JD 里的技术栈。” 20 个站里通常有 5-8 个有反爬，2-3 个有区域限制。任务链在中间断掉，前 6 步白跑。

场景 B：电商比价 / 舆情采集
这类站点对 IP 频率最敏感。单 IP 连抓几百条，失败率会随时间陡增，越到后面数据越脏——最麻烦的不是抓不到，是抓到了错误的"限流页"并被当成正常数据写进报告。

场景 C：海外信息获取
Agent 说"帮我看看这个产品在海外的定价和用户评价"，然后你发现国内出口 IP 看到的价格、内容、甚至页面结构都跟本地不一样。这不是抓取问题，是出口地理属性问题。

四、解法：给 Agent 配一个"能用的网络层"

讲到这里，该说方案了。

思路其实很朴素：Agent 负责思考和编排，网络出口交给专业的基础设施做。 你不需要让 Agent 学会对抗风控——那是另一个领域的问题，交给代理层。

4.1 为什么是隧道代理，而不是自己攒 IP 池

自己维护 IP 池听起来很极客，实际上是个无底洞：找货源、写探活、做故障转移、处理 IP 污染、应对目标站策略变化……这些活儿跟你的核心业务毫无关系，且需要持续投入。

隧道代理的思路是把复杂度收进云端：

采集端 → 固定入口地址（tun.16yun.cn:8000）→ 云端智能调度 → 动态出口 IP 池 → 目标站
              ↑                                      ↑
        客户端只配一个地址                    毫秒级切换，客户端无感

代码侧接入就是一个代理 URL，业务逻辑一行不用改。

4.2代码：Python 侧怎么接

httpx 接入隧道代理（适合接口类采集）：

"""通过亿牛云隧道代理发送请求，适合高频、无状态的接口采集。"""

import os
import httpx
from typing import Any

# 隧道代理入口：固定地址，出口 IP 由云端自动轮换
# 凭证走环境变量，不要硬编码进源码或提交到 Git
PROXY_URL = os.environ["YINIU_PROXY_URL"]  # http://user:pass@tun.16yun.cn:8000


def fetch_json(url: str, *, timeout: float = 10.0) -> dict[str, Any]:
    """经代理隧道拉取 JSON 数据。

    Args:
        url: 目标接口地址。
        timeout: 单请求超时秒数。

    Returns:
        解析后的 JSON 字典。

    Raises:
        httpx.HTTPStatusError: 目标站返回 4xx/5xx。
        httpx.RequestError: 网络或代理层异常。
    """
    with httpx.Client(proxy=PROXY_URL, timeout=timeout, follow_redirects=True) as client:
        resp = client.get(url)
        resp.raise_for_status()
        return resp.json()

Playwright 接入（适合浏览器自动化，跟 Agent 的浏览器操作天然契合）：

"""为 Playwright 配置亿牛云隧道代理，解决浏览器自动化场景的出口封禁问题。"""

import os
from playwright.sync_api import sync_playwright

YINIU_PROXY = {
    "server": os.environ.get("YINIU_PROXY_SERVER", "http://t.16yun.cn:31111"),
    "username": os.environ["YINIU_PROXY_USER"],
    "password": os.environ["YINIU_PROXY_PASS"],
}


def crawl_with_proxy(urls: list[str]) -> list[dict[str, str]]:
    """批量抓取页面标题，出口 IP 每次请求自动轮换。

    Args:
        urls: 待抓取的页面地址列表。

    Returns:
        每个页面的 URL 与标题组成的字典列表。
    """
    results: list[dict[str, str]] = []
    with sync_playwright() as p:
        browser = p.chromium.launch(
            headless=True,
            proxy=YINIU_PROXY,
            # 关掉自动化特征标记，降低被识别为 bot 的概率
            args=["--disable-blink-features=AutomationControlled"],
        )
        context = browser.new_context(locale="zh-CN")
        for url in urls:
            page = context.new_page()
            try:
                page.goto(url, timeout=30_000, wait_until="domcontentloaded")
                results.append({"url": url, "title": page.title()})
            except Exception as exc:  # 单个页面失败不影响整批任务
                results.append({"url": url, "title": f"[FAILED] {exc}"})
            finally:
                page.close()
        browser.close()
    return results

几个实战要点：

凭证必须走环境变量或配置中心。 见过太多把代理账密码硬编码进仓库、然后被扫到的案例。
隧道代理按流量/请求数计费，要配合限流。 用信号量压住并发，随机化请求间隔，别让你的 Agent 变成烧钱机器。
并发度不能超过套餐通道上限，否则请求会在代理层排队，延迟反而飙升。
动态转发不适合需要保持登录态的浏览器任务，这类场景选动态短效代理（有会话亲和）。
代理层要有降级和告警。 代理挂了不等于业务挂了，代码里得有直连兜底 + 失败告警，否则半夜任务静默失败，第二天才发现数据是空的。

4.3 跟 Agent 怎么配合

如果你在豆包工作里跑采集类任务，实际操作是分两层：

┌─────────────────────────────────────┐
│  Agent 层（豆包工作）                │
│  任务规划 · 页面理解 · 字段抽取      │
│  结构化整理 · 写入飞书表格            │
└──────────────┬──────────────────────┘
               │ 调用浏览器 / 执行脚本
┌──────────────▼──────────────────────┐
│  基础设施层（代理 / 环境）            │
│  出口轮换 · 地理定位 · 并发控制      │
│  失败重试 · 告警                     │
└──────────────┬──────────────────────┘
               ▼
          目标站点

Agent 负责"理解和组织"，代理层负责"出去和回来"。两者解耦，各自演进。这也是为什么我不建议让 Agent 自己处理反爬——职责混在一起，出了问题你不知道该改提示词还是改网络。

五、冷静三秒：Agent 落地的几个现实约束

前面吹了一通，也得说说坑。

1. 长任务的可靠性还是概率问题。
10 步任务，每步 95% 成功率，整体成功率只有 60%。这是 Agent 产品当前最大的数学难题。所以"云电脑托管 + 手机遥控 + 断点续跑"这类能力，比模型能力提升 5% 更能改善实际体验。选工具时盯着这个看。

2. 上下文权限是把双刃剑。
飞书打通很爽，但 Agent 继承权限意味着它的操作半径跟你一样大。企业部署前必须想清楚：审计日志谁看？误操作怎么回滚？敏感文档要不要设黑名单？豆包工作做了全链路审计，但策略层面还得企业自己定。

3. 采集类任务的合规边界要划清。
这一点说三遍都不多：代理解决的是出口分布问题，不豁免任何合规义务。 采集公开信息用于学习、研究、内部分析，和把他人原创内容直接搬运发布，是两件完全不同的事。具体到操作层面：遵守 robots.txt 和服务条款、不突破登录壁垒、不采集个人信息、不对目标站造成可用性影响。技术上能做的事，不等于应该做的事。

4. 成本要算清楚。
Agent 跑长任务烧额度，代理烧流量，云电脑烧时长。一个"全天候竞品监控"任务跑起来之前，先估一下月成本。很多 Agent 项目不是死在技术上，是死在账单上。