企业官网建设流程全解析

1. 从“单机版”到“联网版”：Agent-Reach 到底在解决什么问题

做 AI Agent 开发的朋友应该都有这种体会：模型本身的能力边界越来越宽，但真正卡住我们的，往往不是模型“脑子不够用”，而是它“够不着”想要的东西。你的 Agent 想查个实时天气，得有人给它接天气 API；想操作数据库，得有人给它写好 SQL 执行器；想让多个 Agent 协作完成一个复杂任务，得先解决它们之间“谁说了算”“消息怎么传”的问题。

这就是 Agent-Reach 这个方向要解决的核心矛盾：智能体怎么触达它需要的外部世界。我当初接触这个概念的时候，刚做完一个客服机器人项目，最大的痛点就是看起来什么都“会”，实际上什么都“够不着”——知识库数据接不进来、内部系统调不到、多轮对话里想调一个工具还经常找不到对的参数。说白了，Agent 的能力上限 = 模型推理能力 × 触达能力，后者才是真正拉开差距的地方。

Agent-Reach 可以理解为一套围绕“智能体触达边界”的设计思想和工程实践，它关心的问题包括：智能体通过什么渠道获取信息、调用哪些工具、如何与其他智能体协作、怎样在受限环境下依然保持可用性。它不是一个具体软件，而是一类问题的统称。这篇内容主要适合三类人：正在做 Agent 应用的工程师、想给现有系统接入智能能力的架构师、以及被“Agent 看起来啥都能干但落地处处碰壁”困扰的团队。

下文我会从概念拆解、机制设计、工程落地、踩坑实录四个维度展开，把自己的实操经验一并放进去。

2. Agent 触达能力的核心设计思路

2.1 触达的本质：从“模型会答”到“系统会做”

先抛开技术黑话，用个生活化的类比。你雇了一个非常聪明的助理，他熟读各种手册、逻辑推理能力极强，但他坐在一个没有电话、没有网络、没有文件的房间里，只有一扇小窗口能递纸条出来。这时候你问他“帮我查一下明天的航班”，他只能回答“我不知道”，或者根据训练时见过的数据编一个。这个助理的“智力”没有变，但“触达能力”几乎为零，能发挥的价值也就大打折扣。

AI Agent 的情况几乎一模一样。LLM（大语言模型）即使拥有再强的推理能力，它本身也不自带实时数据、不连接业务系统、不操作任何硬件。它像一个超级大脑，却没有手和脚。Agent-Reach 要做的就是给这个大脑接上手脚——通过 API 调用、工具注册、知识检索、多智能体通信等手段，让它能够真正“碰到”外部世界。

这里有一个关键的认知误区：很多人以为给 Agent 接个 API 就算有触达能力了。其实远不止如此。触达能力应该分层来看：

• 信息层触达：能不能拿到需要的信息（知识库、数据库、网页、文件）
• 行动层触达：能不能对目标系统执行操作（发消息、写记录、改配置、下单）
• 协作层触达：能不能和其他智能体、其他人、上下游系统协作
• 感知层触达：能不能感知环境变化（定时触发、事件监听、用户行为反馈）

这四层不是并列关系，而是递进关系。大部分团队停留在第一层，认为做个 RAG（检索增强生成）就是 Agent 了。但真正的生产级应用，几乎都需要同时打通多层的触达能力。

2.2 设计取舍：为什么“全部打通”不是最优解

在考虑 Agent 触达架构的时候，最容易犯的错是“贪多求全”。什么都要接，什么都要通，最后系统复杂度爆炸，稳定性拉垮。

我参与过的一个供应链调度 Agent 项目，最初的设计方案是让 Agent 直接调用 ERP、WMS、TMS 三个系统的几十个接口，同时还要实时读数据库、对接外部物流平台。听起来很美好，实际上开发了两个月，联调了三个月，最后稳定运行的接口不到一半，因为每个系统的鉴权方式不同、数据结构不同、错误码含义不同，Agent 光是搞清楚“该调哪个接口”就耗掉大量上下文窗口。

后来我们做了一个特别重要的设计决策：给 Agent 的触达范围划定边界。不是所有接口都直接暴露给 Agent，而是封装成有限的、语义清晰的“能力单元”。Agent 只能看到十几个工具，每个工具做一件明确的事，输入输出都经过标准化处理。

这个取舍背后的逻辑其实很简单：Agent 的推理能力是宝贵的有限资源（上下文窗口、token 预算），如果让它耗费大量精力去理解“这个接口是要传 JSON 还是 XML”，那真正用于任务规划的算力就少了。触达设计得好不好，不是看“能接多少系统”，而是看“用最少的学习成本拿到最多的结果”。

另外，也要考虑安全边界。你不可能让 Agent 直接拿到数据库的 root 权限，这不只是技术问题，更是责任问题。封装一层、收窄权限，既是为了稳定性，也是为了出事的时候能定位和追溯。

2.3 Agent-Reach 的原则性设计框架

根据我的实操经验，一个合理的 Agent 触达架构，应该遵循这样几条设计原则：

第一条原则是工具即接口。Agent 不直接面对系统，而是面对一组工具（Tools/Functions）。每个工具封装一次具体的系统交互，有明确的名称描述、参数说明、返回值格式。当前主流做法是用 JSON Schema 描述工具，模型根据“函数调用（Function Calling）”机制生成调用指令，由执行层解析并拉起真实操作。

第二条原则是感知与行动分离。Agent 先“感知”（查状态、拿数据、看反馈），再“行动”（调接口、写数据、发指令），不要把感知混在行动里。很多项目 Agent 出错，就是因为感知不全就贸然行动，结果越改越乱，甚至产生了预料之外的副作用。

第三条原则是有损可用。有些触达可能会失败——网络不通、接口超时、权限不够。设计时必须预设失败路径：重试机制、降级策略、人工兜底。我最常见到的低级错误是把 Agent 写的“信誓旦旦”，实际后端全挂了，而 Agent 还在一本正经地编造成功结果。

这三条原则不是一个标准答案，但照着做，至少能让你少踩我踩过的那些坑。

3. 深入解析 Agent 触达外部世界的四种核心机制

3.1 工具调用机制：给 Agent 装上手和脚

工具调用（Function Calling / Tool Use）是 Agent 触达物理世界最直接的方式。你可以把它理解为给模型发了一张“菜单”，菜单上每道菜就是一个函数，模型根据用户需求“点菜”——生成一段结构化指令，告诉系统该执行哪个函数、传什么参数。

实际工程中，工具定义的质量直接决定触达效果。我的经验是，工具描述要“足够笨、足够清楚”。举例来说：

{ "name": "get_weather_by_city", "description": "查询指定城市的实时天气信息。城市名称需为中文全称，如'北京'、'上海'，不接受缩写或拼音。", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市中文全称"} }, "required": ["city"] } }

这个描述看起来啰嗦，但它能有效避免两类错误：一类是模型把“北京”传成“BJ”，另一类是模型把“北京市”和“北京”当成两个不同的城市去反复请求。工具描述本质上是给模型看的“使用说明书”，越明确，模型越不容易犯错。

有人可能会问，为什么不用让 Agent 直接调 API？因为工具调用在模型与 API 之间作了一个关键的翻译层：它把 API 的参数结构、鉴权逻辑、错误处理统统藏起来，模型只关注“做什么”，不用管“怎么做”。从 Agent-Reach 的角度看，工具调用机制决定了触达的“精度”——模型能不能准确选中正确的工具、填充正确的参数。

边界情况特别值得留意。当工具数量超过二三十个时，模型选错工具的几率会明显上升。此时需要做工具分组（比如“查询类”“写入类”“管理类”），或者让 Agent 先走一步“路由”，决定去哪一组工具里找答案。

3.2 检索增强生成：扩大信息触达的“内存”

如果说工具调用是手脚，那 RAG（Retrieval-Augmented Generation）就是 Agent 的外接大脑皮层。它解决的是“知道”的问题：把企业内部文档、知识库、历史工单等非结构化数据切块、向量化、建索引，然后在生成回答前先做相关性检索，把最相关的文本片段塞进上下文。

RAG 在 Agent-Reach 体系里的定位非常特殊——它让 Agent 不需要靠“记住一切”来回答问题，而是像人一样“现查现用”。我见过太多团队在第一版就试图做一个“大而全”的知识库 Agent，把所有文档全部塞进向量库，也不管质量。结果检索出来的文本经常是错的、过时的，或者根本和问题无关，Agent 被带偏，回答质量远不如直接用 LLM 常识回答。

实操环节有几个指针可以分享。第一，切片策略很重要：按语义边界切而不是死板按字数切。比如一个技术文档里，“安装步骤”和“常见问题”虽然挨在一起，但语义上属于不同单元，强行切在中间会让检索结果“半截话”。第二，检索结果要有“相关性阈值”意识：不要总是取 Top-5，而是根据分数动态决定取几条，低于阈值的直接不取，避免噪声。第三，块和摘要并存是一种很实用的手法：向量检索只检索摘要，答案生成则用完整块，兼顾精度与信息量。

做 RAG 的时候要有一个自觉：Agent 的“触达”不保证“正确”。检索系统返回的永远是“可能相关”，不是“事实正确”。Agent 拿到检索片段后，还需要经过自身推理去判断哪部分能用、哪部分是干扰。这也是为什么我会在检索之后加一层“证据过滤”，把明显矛盾或者来源可信度低的信息筛掉。

3.3 多智能体协作机制：让触达能力“联网”

单体 Agent 的触达范围是有限的，方向一旦定了，就往深处挖。当任务复杂度提升时，一个更现实的思路是让多个 Agent 分工协作：一个负责规划，一个负责检索，一个负责写代码，一个负责验证，每个 Agent 专注做好一件事，互相传递中间结果。

多智能体协作在 Agent-Reach 里解决的是“触达的广度”问题。人类团队为什么比一个人效率高？不是每个人更聪明，而是每个人各有所长、分工明确。多智能体同理。

但是，多智能体协作也是翻车重灾区。最常见的翻车模式是“群体空转”——Agent 之间互相甩锅，你让我查数据，我让你写报告，绕了一大圈什么结论都没有。根本原因在于缺少任务收敛机制。我现在的做法是：必须有明确的“驾驶员”角色（Planner / Orchestrator），它负责任务拆解、进度跟踪、结果汇合。子 Agent 不能随意创造新任务，只能按计划执行，否则系统立刻发散。

通信机制上也踩过大坑。如果所有子 Agent 的对话历史都共享给所有人，上下文很快就塞爆，模型开始胡言乱语。后来改为“分阶段广播”：每轮只允许相关 Agent 接收必要信息，汇总阶段才由驾驶员收集全部结果。这类似于项目中“各人写各人的模块，只在接口处对接”，而不是所有人围观所有人的每一行代码。

多智能体协作还有一个现实问题：成本成倍上升。每多一个 Agent，就意味着多一份 token 消耗、多一份延迟。我的实用策略是“单体能搞定就不要上多体”，多智能体的引入应该是为了解耦复杂度，而不是炫技。

3.4 事件与感知机制：让 Agent 从“被动应答”变为“主动响应”

前三种机制都是“用户问，Agent 动”的模式。但真实业务里，有大量场景需要 Agent 主动响应变化：库存低于阈值要补货提醒、系统日志出现关键字要告警、新邮件到达要自动分类。这时候需要事件感知机制。

事件感知的本质，是给 Agent 接上“眼睛和耳朵”——通过监听消息队列、数据库变更、定时任务、Webhook 等方式感知环境变化，然后触发相应的 Agent 流程。它把 Agent 从一个“问答盒子”变成了一个“响应式系统”。

我在实践中常把事件机制分成两个层次：

被动感知是最基础的，通过定时轮询或者消息订阅判断“有没有发生什么事”。主动感知则更进一步，Agent 可以基于历史规律主动设置检查点，比如“如果这个客户连续三天没登录，主动发一条关怀消息”。后者的智能程度更高，但风险也更大——如果误判，会打扰用户。

有一类问题特别容易在事件感知场景中爆发：重复触发。消息队列重试、定时任务重叠执行，都可能导致同一个事件被处理两次。解决方法是引入幂等机制——每次事件带上唯一 ID，处理前先查重。这个细节看起来小，不处理的话后果很严重：用户可能收到两条相同消息，订单可能被提交两次。

4. 实操落地：我来跑通一个完整的 Agent-Reach 方案

4.1 场景选择：给一个“项目周报生成 Agent”装上触达能力

理论讲太多容易飘，直接上手一个具体项目更有价值。我选一个常见的场景：让 Agent 自动生成项目周报。这个任务看起来简单，但要把“周报 Agent”真正落地，会完整覆盖 Agent-Reach 的四个机制。

传统的周报生成方式是什么？人肉收集 Git 提交记录、看看项目管理工具里的任务状态、汇总线上事故和进展、再写成一段文字。这个过程至少花费半小时，且容易遗漏。

Agent 来做这件事，看起来好像很轻松——毕竟“写周报”是 LLM 的舒适区。但真正难点在于，Agent 必须触达研发流程中的零散信息源：代码仓库的提交记录、任务面板的状态变动、监控系统的事件、团队成员填写的进展说明。这些信息源分散在不同系统，格式各不相同，正是 Agent-Reach 要解决的核心场景。

我建议的架构是：规划 Agent 作为唯一入口，负责理解本周时间范围、生成信息收集清单、最终写周报；工具层提供 Git 提交查询、任务状态查询、监控事件查询三类工具——每个工具负责触达一个外部系统；知识层放一份团队文档模板和一个周报历史样例库，帮助 Agent 理解“什么样的周报符合团队风格”；最后引入一个人工确认环节，Agent 生成初稿后由负责人审核，再自动发送。

这个方案的亮点在于“触达系统多，但 Agent 不需要知道细节”。Agent 只需要说“查一下本周 master 分支上的所有提交”，执行层负责把它变成真正的 git 命令，跑通认证、分组、格式化。这种“意图到执行”的解耦，正是 Agent-Reach 设计的核心思想。

4.2 工具选型：每一步我为什么这么选

先说开发框架。目前主流的 Agent 开发框架有多种选择，但我在这个项目里用了轻量化的自研封装 + 标准 Function Calling 接口，而不是引入一个重型框架。原因是：周报场景的工具链相对固定，不需要复杂的 Agent 自主规划能力，自研封装的灵活性和可控性更强。

工具实现上，Git 仓库我直接调用了本地的 git CLI 而不是走 Git API。之所以这么做，是因为团队仓库在内网，走 HTTP API 需要单独配 token，而 CLI 可以通过 SSH 密钥直接鉴权，少一层网络链路就少一层故障源。执行命令时一定要加超时控制，防止仓库过大时 git log 卡住整个 Agent。

任务面板我用的是开源的看板工具，有现成的 REST API。这里有个特别容易踩的坑：它的 API 分页默认是一页 20 条，如果不处理分页，周报会漏掉一部分任务。我在封装工具时特意写了一个自动拉取多页的逻辑，确保工具对 Agent 暴露的是“完整的任务列表”而不是“第一页”。

监控事件系统我采用 Webhook 模式：在监控平台上配置了一个每日上午的定时上报，把前一天的事件聚合消息推送到 Agent 的消息入口。选择 Webhook 而不是轮询，是因为轮询的时间间隔不好定——太密了浪费资源，太疏了会漏数据。Webhook 让源系统主动“推”，Agent 只负责接收和处理，是事件感知机制的最简单落地方式。

4.3 给 Agent 写工具定义：从需求反推 Schema

工具定义是整个 Agent-Reach 方案里最需要耐心的一环。很多人一上来就写 Schema，写了半天发现模型老是理解错。我建议反过来——先想清楚“Agent 要完成这个任务，最少需要哪些信息”，再倒推工具定义。

对于周报 Agent，我设计了三个工具：

第一个是查询 Git 提交记录。参数有仓库路径、分支名、起始日期、结束日期、作者（可选）。起始日期和结束日期是必填的，格式限定为 YYYY-MM-DD，在描述里明确说明“日期为提交产生日期，非当前日期”。这样能避免 Agent 默认用当前时间导致统计错位。

第二个是查询任务状态。参数有项目 ID、状态过滤条件、时间范围。这里我刻意把“状态”设计成枚举值，只允许“进行中”“已完成”“已延期”三个合法输入。否则模型可能会传“in progress”或者“进行”等各种不规范写法，工具层还得做一堆容错。

第三个是查询监控事件。参数有环境、级别、时间段。我同样限制了级别只能是“warning”“critical”二选一，不给模型自由发挥的空间。

写工具描述有个技巧：把“为什么需要这个参数”“常见错误用法”直接写进描述。比如查询任务状态的描述里我写了这样一句话：“不要使用 '所有' 作为状态过滤条件，如需要全部状态，请勿传入该参数。”这句话看着多余，实际上能显著降低模型传错参的概率。我做过对比，加了这类说明之后，工具调用的参数合法率从 82% 提升到 96% 左右。

4.4 数据链路打通与联调实录

工具定义好了，接下来就是工程联调。这个阶段我的习惯是“先打通一条通路，再铺开全部”。

第一个联调的是 Git 提交查询。我先手动执行了一遍 git log 命令，确认输出格式，再写一个 Python 脚本解析输出、转为 JSON。注意 git log 输出里包含 commit hash、作者、日期、标题、变更文件列表等信息，如果全部塞给 Agent，token 消耗会很惊人。我做了裁剪：只保留 hash、作者、标题、日期。变更文件列表在周报场景意义不大，但如果后续要做代码评审 Agent，可以再扩展。

联调中遇到过一个比较典型的问题：git log 的日期过滤参数有两个——--since和--until，它们按“提交时间”过滤没问题，但当有人用--amend修改过提交历史时，提交时间会变，导致统计结果不稳定。最终我改为按--author-date过滤而不是默认的--committer-date，让“作者什么时候写了这段代码”成为统计口径，更符合周报场景的逻辑。

任务面板的联调相对顺一些，因为 REST API 文档齐全。主要工作量在字段映射上——面板 API 返回的任务状态字段是一个字符串 ID，比如 “status: 102”，映射到“已完成”“进行中”需要一份对照表，我在工具封装层做掉了这层映射，Agent 永远只看到中文字段。

监控事件的接入最值得注意。Webhook 推过来的消息格式是 JSON，但负载里有一个多行文本字段，包含事件描述的完整内容。如果不处理，这个字段会让 Agent 的上下文一下子撑大。我可以选择截断或者摘要，最终保留了原始内容，因为周报场景里事件详情往往需要完整信息。如果传的是告警场景，我会建议用一个小模型先做结构化摘要再传给 Agent，成本更可控。

4.5 人工确认环节的设计：Agent 可以“写”，但“发”要有人签字

一个很多人忽略但极其重要的问题：Agent 生成的内容能不能直接发？我的原则是，影响面越大的动作，越需要人工确认。周报会发送给整个团队和管理层，如果 Agent 生成了错误内容直接发出，影响是很糟糕的。

所以我在方案里加了一个 confirm 工具：Agent 生成周报初稿后，不直接调用发送接口，而是调“提交送审”工具，把草稿写入待审队列，同时推送通知给项目负责人。负责人点开链接看一遍，改几个字，点确认后由后台自动发送。这个设计只加了一个步骤，就避开了 Agent 输出 “一本正经胡说八道” 的直接风险。

可能有人会觉得这样不够“自动化”，但你要明白 Agent 替代的是“整理信息”的体力活，而不是“承担责任”的决策活。现阶段任何团队让我做 Agent 系统，我都建议至少留一个人工审批节点——这既是基于落地的稳，也是基于责任边界的诚意。

这条经验放大了讲：Agent 项目上线时要先做“建议权”再升级“执行权”。第一周只生成草稿给人工参考，跑半个月模型不出大错，才放开半自动。Agent-Reach 的触达能力越强，对“哪些能自动、哪些要人工”的定义就越重要。

5. 常见问题与排查技巧实录

5.1 工具调用错误的经典翻车现场

项目做多了，工具调用相关的坑基本都见过。列几个典型的：

参数幻觉：模型明明没有获取到当前时间，却自己编了一个“今天是 2025-06-18”然后传给工具。这种情况最容易出现在模型没有时间感知能力、系统提示里也没给当前时间的时候。解决方案是在 System Prompt 里动态注入当前真实时间，每次请求都拼进去。

工具选择漂移：工具少的时候模型选得准，工具多了就开始乱选。比如明明有“查询天气”工具，模型偏要调“查询城市信息”工具，拿城市人口当温度用。解决方案是工具描述里加上“用途边界”，比如在天气工具描述结尾写“本工具仅用于查询天气，不提供城市简介”。

连续调用死循环：模型调完一个工具发现结果不对，也不换思路，就换个参数继续调同一个工具，来回折腾十几轮。处理方法是设置最大调用轮数，比如 5 轮，超过直接终止并让模型总结当前已获取到的信息。

这些问题的共性根因是：模型不理解外部世界的真实约束。工程师不要指望模型“天生就会正确使用工具”，而是要设计外围机制去约束、纠偏、兜底。

5.2 检索质量差，是“切块方案”还是“Embedding 模型”的锅？

做 RAG 的同学几乎都会遇到一个问题：检出来的东西跟问题不相关，或者相关但信息不完整。遇到这个情况，我习惯按顺序排查三个环节：

第一个环节是查询改写。用户的问题往往很长很口语化，直接拿整句话去向量检索效果一般。例如“我们上周上线的那个新功能现在有没有出什么问题”这个句子，直接向量化后包含太多不关键的字，匹配的文档很发散。我建议先用一个轻量模型把问题改写成检索友好的查询词：“新功能 上线 问题”，效果会好很多。

第二个环节是切块粒度。我踩过的教训是：太长的块检索命中率高但信息密度低——抽中一块，里面只有一句话有用，其他全是废话，浪费上下文。太短的块又容易信息不完整——抽中三块，每块都是半截话，拼不起来。后来采用“分块并写摘要”的策略：向量索引存的是摘要，返回给生成模型的却是完整块。这样既保证了检索精度，又保留了信息完整性。

第三个环节才是 Embedding 模型。说实话，很多检索质量问题不完全在模型本身，优先去调整前面两者一定会收益更大。Embedding 模型在下游效果不佳时再换不迟，一般更换模型对结果的提升幅度不会超过前面两项优化。

5.3 多智能体协作时“信息串味”怎么排查

监控协作任务的时候，最让人头疼的是“信息串味”。A 智能体负责分析用户情绪，B 智能体负责写解决方案，结果 B 生成的方案文字风格跑偏，一查发现 B 的上下文里混进了 A 的分析过程，模型被冗余信息带偏了。

排查这个问题的思路是“上下文审计”。给每个子 Agent 单独打开日志，看它实际收到的上下文究竟包含哪些内容。如果发现公共信息过多，就调整通信机制，把“广播模式”改为“定向投递”——只把某 Agent 需要的消息发过去，不相关的统统过滤掉。

另一个实际操作中要留意的点：不要把所有子 Agent 的思考过程都放进最终汇总里。汇总 Agent 只需要每个子 Agent 的结论和置信度，不需要看它们的推理细节。推理细节等于噪声，塞进去只会拉低最终输出质量。

5.4 触达系统的可观测性：Agent 出错，至少要知道错在哪一步

最后分享一个容易忽略的工程习惯：给 Agent 系统做“过程日志”，而不只是“结果日志”。普通的 API 日志只记录“请求了什么、返回了什么”，但 Agent 是多步推理过程，如果只记录最终回答，出错时几乎无法排查是模型理解错了、工具选错了、还是外部系统返回了异常数据。

我现在的做法是：每一步都打结构化日志，包含四个字段——当前节点名（比如“工具调用-查询任务状态”）、输入内容摘要、模型决策（选了哪个工具、为什么）、工具执行结果摘要。这样出问题时，我能快速定位到具体环节：如果工具选择与语义明显不符，那就是提示词问题；如果工具结果正常但最终答案错了，那就是生成阶段的问题；如果工具本身超时，那就是外部系统稳定性问题。

再补充一个运维技巧：给 Agent 配置“自动截图”能力——将每次 Agent 运行的完整过程（提示词、工具调用链、每步结果）存储起来，再加个 tag 对应业务请求 ID。前端用户说“周五那次报告错了”，我们通过业务 ID 直接回放整个过程，找到问题点，这个能力在排查定位中真的能节省大量时间。

6. 一些实在话与进阶方向

Agent-Reach 本质上不是一个“新框架”或者“新算法”，它更像是一种思考 Agent 系统的视角——把注意力从“模型多聪明”转向“模型能够到多远”。在做这个周报 Agent 的过程里，我加深了一个体会：所有看似神奇的 Agent 能力，拆到最后都是工程问题，是权限怎么给、工具怎么封装、数据怎么流转、失败怎么兜底。

如果让我给刚入坑的团队一个建议，我会说：先别急着写代码，先画一张“触达地图”。把你要 Agent 完成的任务、需要访问的系统、必须拿到的数据、可能出错的地方全部列出来。这张地图比任何架构图都重要。然后再思考，哪些触达可以直接做、哪些要封装、哪些该拒绝。

这个方向后续还能继续延展：比如给 Agent 加记忆能力，让它记住不同项目的周报风格偏好；再比如从单“周报场景”扩展到“项目健康度巡检”，让 Agent 每天早上主动检查仓库活跃度、任务阻塞、监控告警，有异常才打扰人。这些场景本质上还是 Agent-Reach 的范畴，只不过触达的范围更广、主动性更强。

根据我自己的项目体会，Agent 的触达能力做得越好，使用者的信任度提升得越快。信任有了，才有可能获得更大的权限，形成正向循环。而这正是 Agent 从“玩具”走向“生产力工具”的关键一步。