上一期我们聊了 Agent 的三种编排方式：ReAct、Plan-and-Execute 与 Workflow Graph。编排解决的是任务接下来往哪里走，工具负责把模型提出的行动交给真实系统执行。

到这里，我们要思考一个问题：这些行动究竟发生在哪里？

比如，一个 Coding Agent 要修改文件，得有代码仓库和文件系统；运行测试，需要有依赖、终端、进程和数据库；Browser Agent 点击按钮要面对一个正在运行的网页；Computer Use Agent 操作软件，还要面对窗口、鼠标、键盘和操作系统状态。

这些让 Agent 能行动，并随着行动持续发生变化的外部世界，就是 Agent 的环境。

## 懒人图解版

![](https://developer.qcloudimg.com/http-save/yehe-12464096/678061fd9d921fed76b23c4162824e5c.png)

## 环境的边界

之前的 Agent 小知识提到过一个简化公式：

```Plain
Agent = LLM + Context + Tool
```

LLM 负责判断和决策，Context 提供当前决策所需的信息，Tool 提供与外界交互的接口。但 Agent 要真正完成任务，还需要这些接口连接着的外部对象。

对于 Coding Agent，这个外部世界有：

```Plain
代码仓库
文件系统
Git 分支
依赖环境
Shell 会话
运行中的进程
数据库
网络服务
```

对于 Browser Agent，环境就变成了网页、DOM、登录状态、Cookie、当前页面和浏览器进程；对于机器人，它们面对的则是传感器、机械结构和物理空间。

所以，Agent 环境的范围比代码沙箱更大。浏览器、远程桌面、软件工程工作区，甚至真实物理空间，都可以构成 Agent 面对的任务环境；虚拟机、容器和沙箱则可以用来承载和隔离这些执行环境。

从 Agent 的角度来看，环境中保存着文件、进程、网页、数据库等对象的当前状态。Agent 每执行一次操作，都可能让这些状态发生变化。

```Plain
┌──────────── Agent ────────────┐
│ LLM                           │
│ Context                       │
│ Tool / Harness                │
└─────────────┬─────────────────┘
              │ 观察 / 行动
              ↓
┌───────── Environment ─────────┐
| 文件 / Git / 进程 / 数据库      |
| 网页 / 浏览器 / API / 用户      |
└───────────────────────────────┘
```

## 两种状态

谈到环境，这里先区分两个容易混淆的概念：**任务状态和环境状态。**

上一期讲 Agent 编排时，我们用过这样一组状态：

```Plain
当前目标：发布到测试环境
当前阶段：运行测试
构建结果：成功
测试结果：失败
最近错误：数据库连接超时
```

这类记录任务当前推进到哪一步的信息，我们称之为**任务状态**。编排系统会根据当前的任务状态，判断下一步进入测试、诊断、审批还是部署等环节。

**环境状态**关注的则是外部世界此刻处于什么情况。例如：

```Plain
当前分支：feature/login
auth.py：有未提交修改
数据库容器：停止
当前目录：/workspace/app
PORT：8080
dev server：运行中
```

两种状态会互相影响，环境中的观察结果经常会被写入任务状态，供编排系统继续判断。此外，侧重点有所不同。

任务状态回答的是：事情做到哪一步了？环境状态回答的是：外部世界现在是什么样？

假设任务状态显示“准备重新运行测试”，但测试数据库此时发生了故障。任务仍处于同一个执行阶段，但此时环境状态却发生了变化。如果 Agent 继续依据之前的环境信息行动，就可能在错误前提下反复重试。

因此，长任务除了记录“当前做到了哪一步”，还要持续确认“当前面对的环境处于什么状态”。

## 观察与行动空间

Agent 面对一个环境，并不代表它能感知其中的全部信息，也不代表它能操作所有的对象。Agent 与环境之间的交互边界，可以从两个方面来描述：**观察空间和行动空间。**

![](https://developer.qcloudimg.com/http-save/yehe-12464096/4fa08d958832bb4b46f6299baa9b0023.png)

观察空间规定 Agent 能从环境中获取哪些信息。Coding Agent 可以读取文件、查看 Git 状态、获取 Shell 命令输出，也可以拿到测试结果和报错信息。

不同类型的 Agent，观察环境的方式也不同。Browser Agent 可以读取 DOM 或页面截图；Computer Use Agent 可以获取当前屏幕；机器人则可以通过摄像头、距离传感器、力传感器等设备感知外部环境。

行动空间规定 Agent 能对环境执行哪些操作。比如：

```Plain
read_file      → 读取文件
write_file     → 修改文件
run_shell      → 执行命令
click          → 点击界面
send_email     → 发送消息
deploy         → 修改线上环境
```

这也进一步说明了工具与环境之间的关系。

**工具定义 Agent 与外部世界交互的接口，环境则承载这些接口所连接的对象及其当前状态。**

以同一个代码仓库为例，如果 Agent 只有 `read_file` 和搜索工具，它只能读取和分析代码；加入 `write_file` 后，就获得了修改能力；再接入 Shell 和测试环境，便可以形成“修改—运行—验证”的闭环；如果继续开放部署接口，它还能进一步影响线上系统。

因此，即使使用同一个模型，观察空间和行动空间不同，Agent 最终具备的能力边界也会不同。

## 部分可观测性

其实，还有一个问题需要解决，那就是 Agent 每次获得的信息只是环境中的局部信息。

一个代码仓库里可能有数万个文件，但 `git status` 只能展示哪些文件发生了变化，无法告诉 Agent 文件内部的具体内容。测试日志也是一样，它只能反映本次执行暴露出来的问题，很难覆盖整个系统的完整状态。

浏览器环境更明显。一张截图记录的是当前画面，DOM 提供的是页面结构，两者都只能呈现环境的一部分。面对复杂环境，Agent 每次感知到的其实都是一个局部视图。

因此，一次完整的感知过程可以拆成：

```Plain
完整环境状态
      ↓
观察接口
      ↓
获得局部观察
      ↓
上下文管理
      ↓
模型本轮看到的信息
```

这正好可以和前面讲过的上下文预算接起来。

上下文篇提到，只有进入当前上下文的信息，模型才能在这一轮决策中使用。到了环境这一层，还需要再向前看一步：环境中的信息，首先要被 Agent 感知到，之后才有可能进入上下文。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/9fee2e1dbc461d3908b12f09b4dceb2b.png)

所以，信息可能在两个位置丢失：

```Plain
环境
│
|─ 没有被观察到
│
↓
观察结果
│
|─ 没有被选入上下文
│
↓
模型
```

这也解释了为什么 Agent 需要不断搜索、读取、截图和查询状态。很多时候，限制下一步判断的并非推理能力，而是关键的环境信息还没有被获取。

例如测试失败后，Agent 可以先查看报错日志；信息不足，再检查数据库进程；仍无法定位，再读取相关配置文件。每一次观察，都会进一步缩小未知范围。

## 状态转移

Agent 获得环境信息后，会基于当前观察选择下一步行动。行动落到环境中后，环境状态也会随之发生变化。

这一过程可以用一个简单的状态转移来表示：

```Plain
环境状态 S₀
    ↓
Agent 执行动作 A₀
    ↓
环境状态 S₁
    ↓
重新观察
    ↓
决定下一步动作 A₁
```

比如：

```Plain
数据库：停止
    ↓
start_database
    ↓
数据库：运行
```

或者：

```Plain
auth.py：旧代码
    ↓
write_file
    ↓
auth.py：新代码
```

这里还需要区分一件事：**工具调用成功，只能说明动作完成，环境是否进入预期状态，还需要进一步验证。**

例如，`write_file` 返回成功，只能说明文件完成写入；新代码能否正常运行，还要通过编译或测试确认。`start_server` 命令执行结束后，也需要检查进程状态或健康检查结果；浏览器完成点击后，还要确认页面是否进入预期状态。

因此，一次完整的 Agent 行动，还应包含对环境变化的再次观察和验证：

```Plain
观察当前状态
    ↓
选择行动
    ↓
执行行动
    ↓
重新观察
    ↓
验证状态变化
```

工具篇关注的是调用本身：工具如何被调用，以及执行后返回什么结果。到了环境这一层，关注点会进一步延伸到：**行动发生之后，外部环境是否真的发生了预期变化。**

因此，测试、编译、健康检查和页面状态检查这类反馈都很重要。它们能帮助 Agent 判断当前行动是否生效，以及环境是否进入了下一步任务所需要的状态。

## 变化中的环境

前面的示例还隐含了一个前提：Agent 完成观察后，环境会保持不变，等待下一步行动。

但在真实任务中，环境本身也会持续变化。Agent 读取网页后，页面内容可能刷新；读取代码后，另一个进程可能修改文件；分析服务日志期间，服务可能发生故障；模型还在判断下一步时，后台构建任务也可能完成。

这就带来了另一个问题：**Agent 获取到的环境观察会过期。**

```Plain
10:00:00  Agent 读取环境
10:00:05  环境发生变化
10:00:10  Agent 根据旧观察行动
```

模型这一轮的判断本身可能没有问题，但它依赖的信息已经落后于当前环境。

这也是环境工程和普通文本问答之间一个很重要的区别。文档内容在模型阅读期间不会自行变化，而运行中的软件系统会持续产生新的状态。

因此，在执行影响较大的操作前后，Agent 都需要重新确认关键状态是否仍然有效。修改文件前，可以检查文件有没有被其他进程改动；操作网页前，可以确认目标元素是否还存在；部署前，也要重新核对目标版本、测试结果和审批状态。

Agent 面对真实环境时，除了判断“下一步该做什么”，还要持续确认另一个问题：**我现在看到的，还是当前真实的环境吗？**

```Plain
我刚才看到的世界，现在还是那个世界吗？
```

## 环境生命周期

环境和长任务还有一个紧密相关的工程问题：**哪些状态需要保留下来。**

Coding Agent 的执行环境中，会存在很多不会显式写进任务状态的运行信息，例如当前工作目录、环境变量、安装的依赖、正在运行的开发服务器，以及工作区中尚未完成的文件修改。

假设 Agent 连续执行：

```Plain
cd /workspace/app
export NODE_ENV=test
npm run dev
```

如果每次 Shell 调用都启动一个新的执行环境，上一轮设置的工作目录、环境变量和后台进程就可能丢失。这样一来，Agent 虽然记得之前做过什么，下一步面对的执行现场却已经发生了变化。

因此，长任务中的环境设计需要同时处理两类需求。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/dd1d1aaff7e7e08f034ae29cb38d2eaf.png)

一类是**连续性**。工作区、文件修改和必要的运行状态要能够跨步骤保留，让 Agent 在同一个执行现场继续工作。

另一类是**隔离性**。Agent 能执行 Shell、安装依赖、修改文件甚至访问网络时，这些行为不能无限扩散到用户设备和其他任务。虚拟机、容器和沙箱的价值，就在于给 Agent 划出一个受控的行动范围。

环境保存得越完整，任务恢复越方便，但旧进程、缓存、临时文件和错误配置也可能继续留在现场。环境清理得越彻底，执行起点更干净，但重建依赖和运行状态的成本也会增加。

因此，环境生命周期本身也是 Agent 系统的一项工程设计：哪些状态持久保存，哪些按任务重新建立，哪些环境在任务结束后销毁，都需要根据任务连续性、成本和安全边界来决定。

## 结语

回头再看 Agent 系统中的几个概念，它们之间的边界会更加清楚。

上下文决定模型这一轮能够看到哪些信息；工具定义 Agent 与外部环境交互的接口；编排决定任务按照什么路径推进；环境则承载文件、网页、进程、数据库等外部对象的真实状态，并随着 Agent 的行动持续发生变化。

要完成一个持续推进的任务，Agent 需要不断观察环境、采取行动，再根据新的环境状态判断行动是否生效。环境越复杂，Agent 面对的未知状态、过期观察、隐式依赖和行为风险也会越多。

因此，Agent 环境设计最终要回答三个问题：**它能看到什么，它能改变什么，以及行动之后如何确认环境真的发生了预期变化。**

上一期我们聊了 Agent 的三种编排方式：ReAct、Plan-and-Execute 与 Workflow Graph。编排解决的是任务接下来往哪里走，工具负责把模型提出的行动交给真实系统执行。

Agent 小知识｜Agent 环境工程：部分可观测性、状态转移与执行隔离

Agent环境是其执行动作的外部世界，涵盖代码仓库、数据库、网页等动态对象。它决定Agent能观察什么、改变什么，并需持续验证状态变化是否符合预期，是任务落地的关键支撑。

人工智能

编程语言

开发工具

Agent环境是任务执行的外部世界载体，涵盖文件、进程、网页及物理空间等动态对象。区分任务状态与环境状态，通过观察空间和行动空间限定交互边界。长任务需应对部分可观测性和环境变化，保持连续性同时隔离风险，验证行动是否真正改变状态。

2026上云采购 | AI焕新·智启新局

agsx

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Agent 小知识｜Agent 环境工程：部分可观测性、状态转移与执行隔离-腾讯云开发者社区-腾讯云

Agent 小知识｜Agent 环境工程：部分可观测性、状态转移与执行隔离

Agent 小知识｜Agent 环境工程：部分可观测性、状态转移与执行隔离

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐