---
type: study
created: 2026-08-11
updated: 2026-08-11
sensitivity: private
status: active
tags:
  - study
  - langchain
  - managed-deep-agents
  - reliability
topic: Managed Deep Agents Python 渠道、调度与评估
sources:
  - https://docs.langchain.com/langsmith/python/managed-deep-agents-channels
  - https://docs.langchain.com/langsmith/python/managed-deep-agents-channels-slack
  - https://docs.langchain.com/langsmith/python/managed-deep-agents-schedules
  - https://docs.langchain.com/langsmith/python/managed-deep-agents-evals
last_verified: 2026-08-11
---
# Managed Deep Agents：渠道、调度与评估

## Channels

Channel 把外部消息系统连接到已部署 agent：验证并规范化 inbound event，解析 identity 与 thread，触发 agent run，再把响应投递回原会话。每个 `channels/<name>.py` 导出一个 `channel`，文件名同时决定运行时名称和 `POST /channels/<name>/events` 路径。

Channel-originated run 可从 tools/middleware 读取 `runtime.channel`。普通 HTTP run 和 scheduled run 没有 originating channel；scheduled run 要投递结果时必须显式使用命名 channel 与目的地。

## Slack 集成

Slack 是 bring-your-own-app：项目维护可编辑 manifest template，MDA 生成包含 deployment Events URL 的最终 manifest。

关键行为：

- 支持 app mention、direct message 和 agent 已参与 thread 的后续回复。
- conversation mapping 可选 `thread`、`conversation` 或 `message`；默认 mention 按 thread，DM 按 conversation。
- 顶层未 mention 消息、bot 消息、应用自身消息、不支持 subtype 和 filter 拒绝事件不会触发运行。
- `auto_reply` 默认发送最终回答；如果 tool 使用 `runtime.channel.post(..., {final: true})` 发了最终消息，会抑制重复自动回复。
- channel-originated run 只能发回 originating Slack thread；schedule 必须通过 `deliver_to` 指定 channel ID。
- Slack identity 形如 `slack:<team>:<user>`，与 HTTP caller identity 分离；暂不支持 account linking。

安全与可靠性边界：

- 每个请求使用 raw body 验签，并拒绝超出五分钟窗口的 replay。
- Slack Connect shared conversation 当前不支持。
- provider token 不暴露给 `runtime.channel`。
- 事件去重目前是进程内的；Slack retry 或多副本可能让同一逻辑事件运行多次。所有外部副作用工具必须幂等。
- manifest template 是配置真源；生成目录属于构建产物，凭据只放 `.env`。

## Schedules

每个 `schedules/<name>.py` 导出静态 `schedule` 声明。编译阶段提取配置，因此只能使用可静态序列化的字面量或顶层常量，不能读取环境变量、调用函数或动态计算。

- 必须且只能指定 `prompt` 或结构化 `input` 之一。
- cron 是标准五字段表达式；省略 timezone 时使用 UTC。
- 默认每次运行创建临时 thread 并在结束后删除。
- 只有需要跨次积累 thread state 时才使用固定 persistent thread。
- Slack 投递使用 `deliver_to` 和明确 channel conversation ID。
- waited deploy 在 deployment 达到 `DEPLOYED` 后删除并重建 MDA 管理的 cron，使其与本地声明对齐；删除本地 schedule 后重新部署也会删除远端对应 cron。
- `mda deploy --no-wait` 在远端 build 完成前退出，因此本次不会执行 schedule reconciliation。

## Harbor Evals

MDA 没有创造第二套 eval 格式。`evals/tasks/` 是 Harbor 的规范数据集；`evals/scaffold/` 只是可选起点。

两条工作流：

1. 直接在 `evals/tasks/<task>/` 编写完整 Harbor task、环境和 verifier。
2. 用 `mda evals init` 建 scaffold，再用 `mda evals compile` 单向编译到同名 canonical task。

注意：

- 编译某个 scaffold 会替换同名 `evals/tasks/<name>/` 整个目录；scaffold 才是该任务的源。
- 未选中的 canonical tasks 会保留。
- MDA 只编译 agent artifact、adapter、task 和 `harbor-job.json`，不会替 Harbor 运行 trials。
- verifier 必须在 Harbor 约定路径写数值 reward/metrics。
- Harbor 不加载项目 `.env`；job config 只写 `${VAR}` placeholder，运行前必须把凭据导出到 Harbor 进程环境。
- `evals/` 不进入 agent deployment build，trial 输出也不应提交版本库。

## 验证矩阵

| 能力 | 必测场景 |
|---|---|
| Slack | 验签失败、过期 replay、重复 event、mention/DM/thread 映射、无权限、重复回复抑制 |
| Schedule | timezone、临时/持久 thread、失败重试、移除声明后的远端清理、`--no-wait` 差异 |
| Tool side effect | 同一 event 多次到达仍只产生一次业务效果 |
| Eval | scaffold 覆盖边界、Harbor credential 注入、verifier reward、失败 artifact 保留 |