传统 Agent 的能力在诞生时就固定了——给什么工具就用什么工具。真正的自进化 Agent 应该能在运行时识别能力缺口，自主扩展工具集。

何时需要动态工具

典型场景：

1. 批量文件重命名：没有 rename 工具，但 Agent 可以写一个 Python 脚本
2. API 数据聚合：需要组合多个接口的结果，现成工具不支持
3. 格式转换：CSV → JSON、Markdown → HTML，临时需要
4. 测试辅助：需要一个 mock 服务或数据生成器

工具创建流程

识别缺口 → 编写代码 → 安全审查 → 注册到 Tool Registry → 可用

识别缺口

Agent 在以下情况触发工具创建：

• 工具调用连续失败（“没有这个工具”）
• 用户明确请求不存在的功能
• 任务需要多步组合但无现成路径

编写代码

Agent 根据需求生成工具脚本，关键约束：

• 输入输出必须有明确 schema
• 必须包含错误处理
• 不能访问超出工作目录的路径

安全审查

这是最关键的一步。Agent 生成的代码必须经过：

• 语法检查：确保可执行
• 沙箱试运行：用测试数据验证
• 权限边界：不读取敏感文件、不发起外部网络请求
• 用户确认（可选）：高风险操作需人工批准

注册与生命周期

# 工具注册伪代码
tool_registry.register(
    name="batch_rename",
    description="批量重命名文件，支持正则匹配",
    parameters={
        "pattern": {"type": "string", "description": "正则匹配模式"},
        "replacement": {"type": "string", "description": "替换字符串"},
        "directory": {"type": "string", "description": "目标目录"}
    },
    handler="tools/batch_rename.py",
    scope="session"  # session / persistent
)

工具作用域：

主控制器是 Agent 的"大脑"——它决定何时思考、何时行动、何时停止。理解主控制器的设计，就理解了 Agent 的运作范式。

核心循环（Core Loop）

主控制器的本质是一个状态机：

接收输入 → 理解意图 → 选择工具 → 执行调用 → 处理结果 → 判断是否结束 → 输出/继续

这个循环的关键设计点：

1. 意图识别

不是简单的关键词匹配，而是结合上下文、历史、用户状态的综合判断。同一个"搜索一下"，在项目初期是搜技术方案，在部署阶段是搜报错日志。

2. 工具路由

主控制器维护一个工具注册表（Tool Registry），包含：

• 工具名 + 描述（供 LLM 选择）
• 参数 schema（JSON Schema）
• 权限等级（只读 / 可写 / 危险）
• 超时策略

路由逻辑：LLM 输出 tool_call → 控制器校验权限 → 注入上下文 → 执行 → 截断超长输出 → 返回结果。

3. 终止条件

这是最容易被忽略的环节。Agent 必须知道"够了"：

• 显式终止：用户说"停"或任务完成标记
• 隐式终止：连续 3 次工具调用返回相同/空结果
• 预算终止：token 消耗超过阈值，强制总结当前进展

生命周期管理

会话级生命周期

创建 → 活跃 → 空闲 → 重置 → 销毁

• 创建：加载用户上下文、历史摘要、可用工具列表
• 活跃：正常处理请求，维护对话历史
• 空闲：N 分钟无请求后，压缩历史为摘要
• 重置：用户显式 /new，清空当前会话但保留记忆
• 销毁：服务重启或长时间无活动

任务级生命周期

一个复杂任务可能跨多轮：

构建一个真正能用的 AI Agent，不是调 API 写段对话就完事。你需要的是：能接工具、能记忆、能扩展、能上线的完整系统。

技术选型

模型选择

部署平台

Vertex AI（推荐 GCP 用户）：

• 统一接口管理多个模型
• VPC 内调用，安全可控
• ADC 认证，无需手动管理 key

Gemini Developer API（快速原型）：

• 免费额度够日常用
• API Key 简单直接
• 适合单机开发阶段

核心架构

用户输入
    ↓
主控制器（LLM 决策）
    ├── 工具调用 → Shell / File / Web / API
    ├── 记忆读写 → 持久化存储
    └── 子代理 → 并行任务
    ↓
输出生成

1. 工具层

基础工具集：

第四篇：AI 代理与浏览器控制 (MCP)

在现代自动化中，浏览器不仅是测试工具，更是 AI 代理（Agent）的“视觉与肢体”。本篇重点讲解如何利用 Playwright 作为 AI 的执行引擎，并结合 MCP (Model Context Protocol) 让 LLM 实现对网页的自主决策。

1. 核心架构：LLM + 浏览器

AI 代理控制浏览器的核心流程通常为：

1. 视觉分析：获取 DOM 或页面截图。
2. 决策循环：LLM 分析页面信息并下达命令（如“点击搜索按钮”）。
3. 执行与反馈：Playwright 执行指令并返回 DOM 变化。

2. Playwright MCP 服务器实现

要让 LLM 能够控制浏览器，最优雅的方式是通过 MCP 服务器。以下是一个基础的浏览器交互层示例：

# playwright_agent_exec.py
from playwright.sync_api import sync_playwright

def run_agent_task(url: str, action: str):
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=False)
        page = browser.new_page()
        page.goto(url)
        
        # 简化版：AI 代理决策逻辑映射
        if action == "search_and_click":
            page.get_by_placeholder("搜索").fill("Hermes Agent")
            page.get_by_role("button", name="搜索").click()
            
        # 获取当前页面上下文供 LLM 分析
        content = page.content()
        print(f"Action Completed. Page Title: {page.title()}")
        browser.close()
        return content

# 示例：让 AI 代理自动搜索
# run_agent_task("https://www.google.com", "search_and_click")

3. 让 Agent 具备“观察”能力

AI 不仅要“做”，更要“看”。我们可以通过解析 DOM 结构，将其转化为 LLM 可理解的简要文本：