之前做小区边缘功率控制仿真时最让我疲惫的往往不是算法推导而是围绕算法展开的一连串重复劳动查文献、设计实验、改参数、跑仿真、整理数据、再改参数。这个过程通常要持续很多天而真正属于“研究者判断”的时间反而被挤占得很少。这篇笔记想和你聊一个新方向Agentic Autoresearch以及它在 Cell-Edge Power Control 这一具体问题中如何把研究者从实验流水线上解放出来。文章适合三类读者一是做无线通信和功率控制的在校学生或工程师二是想了解 Agentic AI 如何落地到科研场景的 AI 开发者三是对“自动化学术研究”这个概念好奇、想自己搭一个最小闭环的人。读完你会有四个收获理解 Agentic Autoresearch 的核心思想知道 Cell-Edge Power Control 的建模要点亲手跑通一个可扩展的自动研究 Agent 示例以及了解把 Agent 引入研究流程时的常见坑和工程建议。整个项目围绕“研究者定义问题Agent 执行探索人类审查结论”这条主线展开。下面我们先从背景概念开始逐步拆解到完整代码。1. 背景与核心概念1.1 从重复实验中解放研究者无线通信方向的实验研究有很强的“流水线”属性先设定场景接着写仿真代码然后调参数跑完一批结果后画图分析根据分析结论再改参数循环往复。这里有个很尴尬的事实真正需要人类智慧和学术品味的环节是“下一个实验应该验证什么假设”而不是“把这个脚本里的 alpha 从 0.7 改成 0.8 再跑一遍”。Agentic Autoresearch 想解决的问题正是这一块重复投入。它不是一个单独的算法而是把 Agentic AI 的方法论应用到研究工作流上让一个自主系统去完成实验设计、仿真执行、结果分析和策略更新而研究者负责更高层的判断和决策。我理解的 Autoresearch核心不是“自动写论文”而是“自动做实验”。系统内部通过多轮决策不断提出候选方案、执行仿真、评估效果并把评估结果作为下一轮决策的依据。研究者的角色则从“亲手写每个循环”变成“定义目标和约束审查系统产出的证据决定是否采纳结论”。1.2 什么是 Agentic AIAgentic AI 是最近非常热的概念。不同于传统 AI 模型那样“输入一个样本输出一个预测”Agentic AI 具备更强的自主性它可以感知环境状态规划多步行动调用外部工具并基于反馈修正自己的行为。你可以把它理解为“一个会自己动手做事的 AI 系统”而不是“一个只会回答问题的模型”。这个领域延伸出了不少子方向。例如 Agentic RAG强调用 Agent 来调度检索、阅读、验证流程解决普通 RAG 在多跳问答中的碎片化问题又例如 Agentic RL强调用强化学习的方式训练 Agent 在复杂环境中做长程决策社区里甚至出现了专门评估 Agentic RL 稳定性的统一框架。这些方向的核心都指向同一个趋势AI 系统从“单次推理”走向“多轮决策闭环”。在科研场景中这种“多轮决策闭环”恰恰是实验研究的天然形态。因此借用 Agentic 的思路来重构研究流程是非常自然的一步。更前沿的探索还包括元上下文工程也就是让 Agent 在多次实验中积累经验把历史结论提炼成新的上下文或技能用来提升下一轮实验的效率。这一点我们后面的项目里也会看到雏形。1.3 什么是 AutoresearchAutoresearch 可以直译为“自动化研究”但它的内涵比“自动化跑脚本”更深。一个完整的 Autoresearch 系统至少应该具备四个能力理解研究目标研究者给出“我想优化边缘用户吞吐量”系统能把它拆解为可执行的实验计划。执行实验自动调用仿真器或环境完成数据采集。分析结果从实验数据中提取关键指标形成结论或建议。更新策略根据上一轮结论调整下一轮的实验参数或方向。这里面最关键的是系统要形成闭环。如果只是批量跑参数网格搜索那叫并行计算不叫 Autoresearch。真正的 Autoresearch 应该像一个有经验的研究助理它会根据上一轮实验的失败或成功主动修正下一轮实验方案并在日志里留下“为什么这么做”的判断痕迹。当然Autoresearch 也有边界。它不能替代研究者判断“这个研究问题重不重要”也不能替代统计假设检验。它擅长的是在一个目标明确、评价标准清晰的场景里把从假设到结论的探索过程自动化。Cell-Edge Power Control 正是这种场景目标函数明确约束清晰仿真环境可控每次实验都有定量指标反馈。2. Cell-Edge Power Control 问题与现状2.1 小区边缘用户为什么难优化在蜂窝移动通信系统里小区边缘用户是最难照顾的一群人。简单来说他们有“两座大山”第一距离服务基站较远路径损耗大有用信号到达基站或终端时已经衰减很多。第二相邻小区通常复用相同的频谱资源边缘用户会同时收到来自多个基站的同频干扰。信号弱干扰强两者叠加导致 SINR 很低吞吐量自然上不去。从系统优化的角度看边缘用户的功率控制是一个典型的折中问题如果让边缘用户提升发射功率确实能改善它的信号质量但也会对相邻小区的用户造成更多干扰如果压低功率整个网络的干扰水平会下降但边缘用户的覆盖又会变差。这个矛盾使得功率控制成为小区间干扰协调中的关键一环也是 3GPP 长期研究的热点话题。2.2 功率控制的经典做法工程上最常见的是一种静态或半静态的功率控制方法叫分数功率控制。它的基本思想可以写成一个公式[ P_i \min(P_{max}, P_0 \alpha \cdot PL_i) ]其中 (P_i) 是用户 (i) 的发射功率(P_0) 是目标接收功率(PL_i) 是用户到服务基站的路径损耗(\alpha) 是路径损耗补偿系数。(\alpha0) 表示完全不补偿所有用户用差不多的功率(\alpha1) 表示完全补偿边缘用户会被分配到更高的功率。实际系统里 (\alpha) 通常取 0.6 到 0.9 之间的某个值。这个方法的问题在于参数是全局配置的而且不太容易针对“当前这组用户分布、这小块信道环境”做精细调整。另一种常见做法是直接用优化算法在满足用户最大功率和系统总功率约束的前提下最大化一个与 SINR 相关的网络效用函数。这个方法更灵活但往往需要多轮仿真验证计算开销大。2.3 现有研究流程的瓶颈我在实际跑仿真时感受最深的一点是“参数搜索”和“结果分析”占据了太多时间。假设你要研究不同信道环境下的最优 (\alpha) 和 (P_0)最朴素的做法是把两个参数分别取 10 个候选值组合起来就是 100 组实验。每组实验跑一次系统级仿真可能就要几分钟甚至更久。跑完之后还要人工汇总表格找出规律再决定下一个搜索方向。如果是小规模问题还能接受一旦场景扩大到多小区、多用户、多信道快照这个流程基本没法靠手工完成。更麻烦的是仿真过程中经常会出现一些非预期的现象比如某个用户功率很高但 SINR 反而下降这种时候需要人去分析原因然后调整下一轮实验方向。现有的“网格搜索 人工分析”模式在这个环节上效率很低。这正是 Agentic Autoresearch 的用武之地让一个自主系统去承担实验执行和初步分析把“下一步往哪个方向搜索”这个决策也变成自动化流程的一部分研究者只需要在关键节点做最终判断。3. Agentic Autoresearch 的核心研究闭环3.1 从手工流水线到 Agent 闭环把传统研究流程改造成 Autoresearch 闭环并不需要一开始就上很复杂的系统。核心是引入一个循环结构每一次循环都包含“提出实验方案、执行仿真、分析结果、形成下一步建议”这四个步骤。我把它称作“研究闭环”。它的外形和强化学习里的 agent-environment 交互很像但语义更偏科研环境是仿真器智能体是研究助手动作是实验参数奖励是目标函数指标而整个系统的输出不是最优策略而是经过多轮探索得到的一系列“研究结论”。这个闭环的价值在于它让“实验决策”本身也变成了可以被自动化的对象。传统网格搜索是提前把所有实验定义好然后并行跑完Autoresearch 则是每跑完一轮就利用这轮结果决定下一轮怎么做。这样一来同样的实验预算下系统能把更多计算花在有希望的方向上。3.2 闭环中的四个关键组件一个最小可用的 Autoresearch 系统通常由四个组件组成我整理成了下面的表格组件职责示例实现Planner根据研究目标和历史结果生成下一组实验参数随机搜索、进化策略、大模型规划Simulator在给定参数下运行仿真返回性能指标自研 Python 仿真、ns-3、系统级链路仿真器Analyzer从仿真结果中提取结论判断当前方案是否值得推进计算均值和最差值、生成研究建议Study Coordinator维护整个闭环循环记录历史调度前三者一个主控 Python 类这里需要注意的是Planner 不一定是大模型。在最简版本里一个带自适应方差的随机搜索就能完成 Planner 的职责。后续如果你想提升系统的“智能程度”可以把随机搜索替换成进化策略或者接入大模型 API让大模型根据历史日志生成下一轮实验方案。关键是接口要保持统一这样替换成本才低。3.3 研究者角色的重新定义引入 Autoresearch 之后研究者的角色会发生本质变化。过去研究者是“实验执行链条上最重要的一环”写代码、调参、看数据、改方案全都亲力亲为。现在研究者更像一个“研究项目的负责人”主要做三件事第一定义研究问题。例如“在边缘用户比例较高的场景下总功率约束应该怎么分配最合理”。问题定义得越清晰Agent 越容易把目标翻译成可优化的目标函数。第二审查 Agent 产出的证据。Agent 说“第 5 轮实验里用户 3 功率提升后系统效用变好了”研究者需要判断这个结论在不同信道快照下是否稳定是否存在过拟合风险。第三决定是否终止或转向。当 Agent 连续多轮都没有显著提升时研究者可以终止当前方向或者调整研究目标重新启动一轮新的 Autoresearch。换句话说Agent 负责“怎么找”研究者负责“找什么”和“结果可信吗”。这是一个更接近管理者而非执行者的角色定位。4. 仿真场景建模与目标函数在进入代码之前我们需要先明确仿真场景。这个场景不能太复杂否则代码会把概念淹没但也不能太简单否则无法体现空间功率分配的必要性。4.1 场景参数设计我设计的场景包含 7 个用户分别位于 7 个相邻小区的边缘区域。每个用户属于一个小区所有用户复用同一份频谱资源因此彼此之间存在同频干扰。参数设定如下用户数 (N 7)单个用户最大发射功率 (P_{max} 10) mW系统总功率约束 (P_{total} 25) mW接收噪声功率 (N_0 10^{-9}) mW总功率约束的存在非常关键。如果没有这个约束每个用户都可以单独提升功率来提高自己的 SINR系统无法体现出“功率分配”的博弈属性。加上总功率约束之后问题变成“如何在 7 个边缘用户之间分配有限的功率资源使得整体性能最优”这才是一个有研究价值的功率控制问题。4.2 信道模型与 SINR 计算为了让代码简洁我使用了一个随机的信道增益矩阵来模拟路径损耗和阴影衰落。定义一个矩阵 (G)其中 (G_{i,j}) 表示用户 (j) 的发射信号到达小区 (i) 基站的信道增益。服务链路的增益通常远高于干扰链路。我设置服务链路 (G_{i,i})在 0.8 到 1.2 之间随机生成干扰链路 (G_{i,j})(i \neq j)在 0.01 到 0.1 之间随机生成这样用户 (i) 在服务基站处的 SINR 可以写成[ \text{SINR}i \frac{P_i \cdot G{i,i}}{\sum_{j \neq i} P_j \cdot G_{i,j} N_0} ]这个公式的物理解释很直观分子是有用信号功率分母是来自其他 6 个用户的同频干扰加上接收机噪声。某个用户提高功率一方面提升了自己在分母中的信号项另一方面也增加了它对其他用户的干扰项这正是功率控制问题需要权衡的核心矛盾。4.3 优化目标与约束条件目标函数选用网络效用函数[ U(P) \sum_{i1}^{N} \log(1 \text{SINR}_i) ]为什么用这个函数因为它能同时兼顾吞吐量和公平性。SINR 越高(\log(1\text{SINR})) 越大系统总吞吐量越好同时由于对数函数在数值较小的地方增长更快系统会自动倾向于照顾 SINR 很低的用户。如果只优化所有用户 SINR 之和系统很可能把所有功率都分配给信道最好的用户导致边缘用户被饿死。优化问题可以写成[ \max_P \quad \sum_{i1}^{N} \log(1 \text{SINR}_i) ]约束条件[ 0 \leq P_i \leq P_{max}, \quad \forall i ][ \sum_{i1}^{N} P_i \leq P_{total} ]这是一个非凸优化问题在真实系统中很难直接求全局最优解。但这不影响我们的目标我们不是要证明某个算法的全局最优性而是要让 Autoresearch Agent 在这个约束空间里自动探索出比简单基线策略更好的方案。4.4 基线策略为了评估 Agent 的效果我设置一个简单的基线策略等功率分配。等功率分配就是让每个用户分到相同的功率[ P_i \frac{P_{total}}{N} ]在 7 个用户、总功率 25 mW 的条件下每个用户分到约 3.57 mW。这个基线策略不需要任何优化适合作为对比参考。如果 Agent 在搜索结束后能找到一个效用高于等功率分配方案的功率向量说明整个 Autoresearch 闭环是有意义的。5. 完整实战从零搭建 Autoresearch Agent现在进入代码环节。下面的例子用 Python 编写依赖库只需要 NumPy因此非常适合本地跑通。我建议你按照下面的步骤一步步操作不要直接复制全部代码了事。5.1 项目结构设计我先规划了这样的项目结构agentic_power_control/ ├── environment.py ├── agent_pipeline.py ├── run_study.py └── research_notes.md三个 Python 文件职责明确environment.py负责信道生成、SINR 计算、效用计算、功率约束投影。agent_pipeline.py包含 Planner、Analyzer、StudyCoordinator 三个类构成 Autoresearch 闭环。run_study.py主程序组装组件并运行整个研究闭环。research_notes.md会在运行结束后自动生成记录每一轮实验的关键结论。这是 Autoresearch 的“研究笔记本”。5.2 编写仿真环境先看environment.py。这个文件的核心是CellEdgeEnv类。# 文件路径agentic_power_control/environment.py import numpy as np class CellEdgeEnv: 小区边缘功率控制仿真环境。 场景说明 - N 个用户位于不同小区边缘共用同一份频谱资源 - gain[i, j] 表示用户 j 的发射信号到达小区 i 基站的信道增益 - 每个用户的最大发射功率为 p_max系统总功率约束为 p_total。 def __init__(self, n_users7, p_max10.0, p_total25.0, noise1e-9, seed42): self.n_users n_users self.p_max p_max self.p_total p_total self.noise noise self.rng np.random.default_rng(seed) self.gain None self._init_channel() def _init_channel(self): 随机初始化信道增益矩阵。 服务链路增益明显高于干扰链路增益以此模拟小区边缘场景。 n self.n_users g self.rng.uniform(0.01, 0.1, size(n, n)) for i in range(n): g[i, i] self.rng.uniform(0.8, 1.2) self.gain g def compute_sinr(self, power): 根据功率向量计算每个用户的 SINR。 SINR_i P_i * G[i, i] / (sum_{j ! i} P_j * G[i, j] noise) p np.asarray(power, dtypefloat) n self.n_users signal p * np.diag(self.gain) sinr np.zeros(n) for i in range(n): interference 0.0 for j in range(n): if j ! i: interference p[j] * self.gain[i, j] sinr[i] signal[i] / (interference self.noise) return sinr def compute_utility(self, power): 计算 sum log(1 SINR)作为网络效用。 该目标函数同时兼顾吞吐量和公平性。 返回值为 (utility, sinr)。 sinr self.compute_sinr(power) utility float(np.sum(np.log1p(sinr))) return utility, sinr def project_power(self, power): 将功率向量投影到可行域内。 约束 1. 0 P_i p_max 2. sum(P_i) p_total p np.asarray(power, dtypefloat) p np.clip(p, 0.0, self.p_max) total np.sum(p) if total self.p_total: p p * (self.p_total / total) return p重点解释三个方法compute_sinr按公式逐用户计算 SINR。我用循环而不是矩阵运算是为了让代码更直白读者可以一眼看出信号和干扰的来源。实际仿真规模大时可以用矩阵乘法一次性算出所有用户的干扰。compute_utility返回效用值和 SINR 数组。注意这里返回的是float方便 Planner 比较大小。project_power是约束处理的关键。它先对所有分量做上下界裁剪再判断总功率是否超限。如果超限就按比例压缩整个功率向量使总功率恰好等于上限。这个函数保证了 Planner 无论生成多离谱的功率向量最后送入仿真环境的方案一定是可行解。5.3 实现 Planner、Analyzer 与 Coordinator接下来是agent_pipeline.py它包含三个组件。先看 Planner。# 文件路径agentic_power_control/agent_pipeline.py import numpy as np from environment import CellEdgeEnv class RandomSearchPlanner: 基于自适应随机搜索的 Planner。 在实际项目中这个类可以替换为大模型 Planner。 当前实现不依赖外部服务便于读者在没有额外资源的情况下跑通闭环。 def __init__(self, noise_scale2.0, pop_size30, seed0): self.noise_scale noise_scale self.pop_size pop_size self.rng np.random.default_rng(seed) self.best_power None self.best_utility -np.inf def propose(self, env, iteration, history): 生成一组候选功率向量。 策略围绕历史最优解加入高斯噪声并随着迭代次数增加逐渐缩小探索范围。 n env.n_users candidates [] if self.best_power is None: base np.full(n, env.p_total / n) base env.project_power(base) else: base self.best_power scale self.noise_scale / (1.0 0.1 * iteration) for _ in range(self.pop_size): candidate base self.rng.normal(0, scale, sizen) candidate env.project_power(candidate) candidates.append(candidate) return candidates def update(self, env, candidates, utilities): 从候选集中选最优解并记录全局历史最优。 best_idx int(np.argmax(utilities)) if utilities[best_idx] self.best_utility: self.best_utility utilities[best_idx] self.best_power candidates[best_idx].copy()这个 Planner 本质上是一个带自适应步长的随机搜索。它有两个参数noise_scale控制初始探索范围pop_size控制每轮生成的候选数量。随着 iteration 增大探索范围逐渐收缩系统从“广撒网”过渡到“精细搜索”。这里的history参数暂时没有在方法内部使用但它作为接口占位符非常重要。未来如果替换成一个大模型 Planner这个参数可以让模型阅读历史实验记录从而生成更智能的实验方案。然后是 Analyzer。class StudyAnalyzer: 根据实验结果生成研究建议。 def analyze(self, env, power, utility, sinr, iteration): 分析当前最优实验输出关键指标与研究建议。 min_idx int(np.argmin(sinr)) min_sinr float(sinr[min_idx]) mean_sinr float(np.mean(sinr)) max_sinr float(np.max(sinr)) total_power float(np.sum(power)) notes [] if min_sinr 1.0: notes.append( f第 {iteration} 轮用户 {min_idx} 的 SINR 偏低{min_sinr:.3f} f建议提高边缘用户功率或降低强干扰用户功率。 ) if mean_sinr 3.0: notes.append( f第 {iteration} 轮平均 SINR 达到 {mean_sinr:.3f}网络整体质量良好。 ) if total_power env.p_total * 0.95: notes.append( f第 {iteration} 轮总功率接近上限注意发射功率受限。 ) if max_sinr / min_sinr 10: notes.append( f第 {iteration} 轮用户间 SINR 差异较大公平性需要关注。 ) suggestion { iteration: int(iteration), utility: float(utility), mean_sinr: mean_sinr, min_sinr: min_sinr, max_sinr: max_sinr, total_power: total_power, power: [float(round(p, 6)) for p in power], notes: notes, } return suggestionAnalyzer 的职责是“把实验数据翻译成人类能读懂的结论”。它不只记录指标还会根据规则生成建议。例如当某个用户 SINR 很低时它会提示“提高边缘用户功率”当用户间 SINR 差异过大时它会提示“公平性需要关注”。这些建议在真实研究中可以后续反馈给 Planner作为下一轮实验的指导。最后是 StudyCoordinator。class StudyCoordinator: Autoresearch 主控流程。 职责循环调度 Planner、Environment、Analyzer 把分析结果写回历史记录形成完整研究闭环。 def __init__(self, env, planner, analyzer, max_iterations30): self.env env self.planner planner self.analyzer analyzer self.max_iterations max_iterations self.history [] def run(self): for iteration in range(self.max_iterations): candidates self.planner.propose(self.env, iteration, self.history) utilities [] sinr_list [] for power in candidates: utility, sinr self.env.compute_utility(power) utilities.append(utility) sinr_list.append(sinr) self.planner.update(self.env, candidates, utilities) best_idx int(np.argmax(utilities)) best_power candidates[best_idx] best_utility utilities[best_idx] best_sinr sinr_list[best_idx] result self.analyzer.analyze( self.env, best_power, best_utility, best_sinr, iteration ) self.history.append(result) return self.historyStudyCoordinator是整个闭环的“导演”。每一轮迭代里它调用 Planner 生成候选功率向量逐个送入环境计算效用让 Planner 更新历史最优再用 Analyzer 对当前轮最优实验做分析最后把分析结果存入历史。这里有一个设计细节值得注意当前实现是“每一轮记录本轮最优”而不是“只记录全局最优”。这样研究日志能完整呈现系统探索的轨迹读者可以看到效用值如何随着轮次提升也可以看到 Agent 在中间阶段提出的各种建议。5.4 编写 
长河君 · 2026/8/30 14:28:55 · 阅读 1.2k Agentic Autoresearch：让AI自动闭环驱动小区边缘功率控制优化
之前做小区边缘功率控制仿真时最让我疲惫的往往不是算法推导而是围绕算法展开的一连串重复劳动查文献、设计实验、改参数、跑仿真、整理数据、再改参数。这个过程通常要持续很多天而真正属于“研究者判断”的时间反而被挤占得很少。这篇笔记想和你聊一个新方向Agentic Autoresearch以及它在 Cell-Edge Power Control 这一具体问题中如何把研究者从实验流水线上解放出来。文章适合三类读者一是做无线通信和功率控制的在校学生或工程师二是想了解 Agentic AI 如何落地到科研场景的 AI 开发者三是对“自动化学术研究”这个概念好奇、想自己搭一个最小闭环的人。读完你会有四个收获理解 Agentic Autoresearch 的核心思想知道 Cell-Edge Power Control 的建模要点亲手跑通一个可扩展的自动研究 Agent 示例以及了解把 Agent 引入研究流程时的常见坑和工程建议。整个项目围绕“研究者定义问题Agent 执行探索人类审查结论”这条主线展开。下面我们先从背景概念开始逐步拆解到完整代码。1. 背景与核心概念1.1 从重复实验中解放研究者无线通信方向的实验研究有很强的“流水线”属性先设定场景接着写仿真代码然后调参数跑完一批结果后画图分析根据分析结论再改参数循环往复。这里有个很尴尬的事实真正需要人类智慧和学术品味的环节是“下一个实验应该验证什么假设”而不是“把这个脚本里的 alpha 从 0.7 改成 0.8 再跑一遍”。Agentic Autoresearch 想解决的问题正是这一块重复投入。它不是一个单独的算法而是把 Agentic AI 的方法论应用到研究工作流上让一个自主系统去完成实验设计、仿真执行、结果分析和策略更新而研究者负责更高层的判断和决策。我理解的 Autoresearch核心不是“自动写论文”而是“自动做实验”。系统内部通过多轮决策不断提出候选方案、执行仿真、评估效果并把评估结果作为下一轮决策的依据。研究者的角色则从“亲手写每个循环”变成“定义目标和约束审查系统产出的证据决定是否采纳结论”。1.2 什么是 Agentic AIAgentic AI 是最近非常热的概念。不同于传统 AI 模型那样“输入一个样本输出一个预测”Agentic AI 具备更强的自主性它可以感知环境状态规划多步行动调用外部工具并基于反馈修正自己的行为。你可以把它理解为“一个会自己动手做事的 AI 系统”而不是“一个只会回答问题的模型”。这个领域延伸出了不少子方向。例如 Agentic RAG强调用 Agent 来调度检索、阅读、验证流程解决普通 RAG 在多跳问答中的碎片化问题又例如 Agentic RL强调用强化学习的方式训练 Agent 在复杂环境中做长程决策社区里甚至出现了专门评估 Agentic RL 稳定性的统一框架。这些方向的核心都指向同一个趋势AI 系统从“单次推理”走向“多轮决策闭环”。在科研场景中这种“多轮决策闭环”恰恰是实验研究的天然形态。因此借用 Agentic 的思路来重构研究流程是非常自然的一步。更前沿的探索还包括元上下文工程也就是让 Agent 在多次实验中积累经验把历史结论提炼成新的上下文或技能用来提升下一轮实验的效率。这一点我们后面的项目里也会看到雏形。1.3 什么是 AutoresearchAutoresearch 可以直译为“自动化研究”但它的内涵比“自动化跑脚本”更深。一个完整的 Autoresearch 系统至少应该具备四个能力理解研究目标研究者给出“我想优化边缘用户吞吐量”系统能把它拆解为可执行的实验计划。执行实验自动调用仿真器或环境完成数据采集。分析结果从实验数据中提取关键指标形成结论或建议。更新策略根据上一轮结论调整下一轮的实验参数或方向。这里面最关键的是系统要形成闭环。如果只是批量跑参数网格搜索那叫并行计算不叫 Autoresearch。真正的 Autoresearch 应该像一个有经验的研究助理它会根据上一轮实验的失败或成功主动修正下一轮实验方案并在日志里留下“为什么这么做”的判断痕迹。当然Autoresearch 也有边界。它不能替代研究者判断“这个研究问题重不重要”也不能替代统计假设检验。它擅长的是在一个目标明确、评价标准清晰的场景里把从假设到结论的探索过程自动化。Cell-Edge Power Control 正是这种场景目标函数明确约束清晰仿真环境可控每次实验都有定量指标反馈。2. Cell-Edge Power Control 问题与现状2.1 小区边缘用户为什么难优化在蜂窝移动通信系统里小区边缘用户是最难照顾的一群人。简单来说他们有“两座大山”第一距离服务基站较远路径损耗大有用信号到达基站或终端时已经衰减很多。第二相邻小区通常复用相同的频谱资源边缘用户会同时收到来自多个基站的同频干扰。信号弱干扰强两者叠加导致 SINR 很低吞吐量自然上不去。从系统优化的角度看边缘用户的功率控制是一个典型的折中问题如果让边缘用户提升发射功率确实能改善它的信号质量但也会对相邻小区的用户造成更多干扰如果压低功率整个网络的干扰水平会下降但边缘用户的覆盖又会变差。这个矛盾使得功率控制成为小区间干扰协调中的关键一环也是 3GPP 长期研究的热点话题。2.2 功率控制的经典做法工程上最常见的是一种静态或半静态的功率控制方法叫分数功率控制。它的基本思想可以写成一个公式[ P_i \min(P_{max}, P_0 \alpha \cdot PL_i) ]其中 (P_i) 是用户 (i) 的发射功率(P_0) 是目标接收功率(PL_i) 是用户到服务基站的路径损耗(\alpha) 是路径损耗补偿系数。(\alpha0) 表示完全不补偿所有用户用差不多的功率(\alpha1) 表示完全补偿边缘用户会被分配到更高的功率。实际系统里 (\alpha) 通常取 0.6 到 0.9 之间的某个值。这个方法的问题在于参数是全局配置的而且不太容易针对“当前这组用户分布、这小块信道环境”做精细调整。另一种常见做法是直接用优化算法在满足用户最大功率和系统总功率约束的前提下最大化一个与 SINR 相关的网络效用函数。这个方法更灵活但往往需要多轮仿真验证计算开销大。2.3 现有研究流程的瓶颈我在实际跑仿真时感受最深的一点是“参数搜索”和“结果分析”占据了太多时间。假设你要研究不同信道环境下的最优 (\alpha) 和 (P_0)最朴素的做法是把两个参数分别取 10 个候选值组合起来就是 100 组实验。每组实验跑一次系统级仿真可能就要几分钟甚至更久。跑完之后还要人工汇总表格找出规律再决定下一个搜索方向。如果是小规模问题还能接受一旦场景扩大到多小区、多用户、多信道快照这个流程基本没法靠手工完成。更麻烦的是仿真过程中经常会出现一些非预期的现象比如某个用户功率很高但 SINR 反而下降这种时候需要人去分析原因然后调整下一轮实验方向。现有的“网格搜索 人工分析”模式在这个环节上效率很低。这正是 Agentic Autoresearch 的用武之地让一个自主系统去承担实验执行和初步分析把“下一步往哪个方向搜索”这个决策也变成自动化流程的一部分研究者只需要在关键节点做最终判断。3. Agentic Autoresearch 的核心研究闭环3.1 从手工流水线到 Agent 闭环把传统研究流程改造成 Autoresearch 闭环并不需要一开始就上很复杂的系统。核心是引入一个循环结构每一次循环都包含“提出实验方案、执行仿真、分析结果、形成下一步建议”这四个步骤。我把它称作“研究闭环”。它的外形和强化学习里的 agent-environment 交互很像但语义更偏科研环境是仿真器智能体是研究助手动作是实验参数奖励是目标函数指标而整个系统的输出不是最优策略而是经过多轮探索得到的一系列“研究结论”。这个闭环的价值在于它让“实验决策”本身也变成了可以被自动化的对象。传统网格搜索是提前把所有实验定义好然后并行跑完Autoresearch 则是每跑完一轮就利用这轮结果决定下一轮怎么做。这样一来同样的实验预算下系统能把更多计算花在有希望的方向上。3.2 闭环中的四个关键组件一个最小可用的 Autoresearch 系统通常由四个组件组成我整理成了下面的表格组件职责示例实现Planner根据研究目标和历史结果生成下一组实验参数随机搜索、进化策略、大模型规划Simulator在给定参数下运行仿真返回性能指标自研 Python 仿真、ns-3、系统级链路仿真器Analyzer从仿真结果中提取结论判断当前方案是否值得推进计算均值和最差值、生成研究建议Study Coordinator维护整个闭环循环记录历史调度前三者一个主控 Python 类这里需要注意的是Planner 不一定是大模型。在最简版本里一个带自适应方差的随机搜索就能完成 Planner 的职责。后续如果你想提升系统的“智能程度”可以把随机搜索替换成进化策略或者接入大模型 API让大模型根据历史日志生成下一轮实验方案。关键是接口要保持统一这样替换成本才低。3.3 研究者角色的重新定义引入 Autoresearch 之后研究者的角色会发生本质变化。过去研究者是“实验执行链条上最重要的一环”写代码、调参、看数据、改方案全都亲力亲为。现在研究者更像一个“研究项目的负责人”主要做三件事第一定义研究问题。例如“在边缘用户比例较高的场景下总功率约束应该怎么分配最合理”。问题定义得越清晰Agent 越容易把目标翻译成可优化的目标函数。第二审查 Agent 产出的证据。Agent 说“第 5 轮实验里用户 3 功率提升后系统效用变好了”研究者需要判断这个结论在不同信道快照下是否稳定是否存在过拟合风险。第三决定是否终止或转向。当 Agent 连续多轮都没有显著提升时研究者可以终止当前方向或者调整研究目标重新启动一轮新的 Autoresearch。换句话说Agent 负责“怎么找”研究者负责“找什么”和“结果可信吗”。这是一个更接近管理者而非执行者的角色定位。4. 仿真场景建模与目标函数在进入代码之前我们需要先明确仿真场景。这个场景不能太复杂否则代码会把概念淹没但也不能太简单否则无法体现空间功率分配的必要性。4.1 场景参数设计我设计的场景包含 7 个用户分别位于 7 个相邻小区的边缘区域。每个用户属于一个小区所有用户复用同一份频谱资源因此彼此之间存在同频干扰。参数设定如下用户数 (N 7)单个用户最大发射功率 (P_{max} 10) mW系统总功率约束 (P_{total} 25) mW接收噪声功率 (N_0 10^{-9}) mW总功率约束的存在非常关键。如果没有这个约束每个用户都可以单独提升功率来提高自己的 SINR系统无法体现出“功率分配”的博弈属性。加上总功率约束之后问题变成“如何在 7 个边缘用户之间分配有限的功率资源使得整体性能最优”这才是一个有研究价值的功率控制问题。4.2 信道模型与 SINR 计算为了让代码简洁我使用了一个随机的信道增益矩阵来模拟路径损耗和阴影衰落。定义一个矩阵 (G)其中 (G_{i,j}) 表示用户 (j) 的发射信号到达小区 (i) 基站的信道增益。服务链路的增益通常远高于干扰链路。我设置服务链路 (G_{i,i})在 0.8 到 1.2 之间随机生成干扰链路 (G_{i,j})(i \neq j)在 0.01 到 0.1 之间随机生成这样用户 (i) 在服务基站处的 SINR 可以写成[ \text{SINR}i \frac{P_i \cdot G{i,i}}{\sum_{j \neq i} P_j \cdot G_{i,j} N_0} ]这个公式的物理解释很直观分子是有用信号功率分母是来自其他 6 个用户的同频干扰加上接收机噪声。某个用户提高功率一方面提升了自己在分母中的信号项另一方面也增加了它对其他用户的干扰项这正是功率控制问题需要权衡的核心矛盾。4.3 优化目标与约束条件目标函数选用网络效用函数[ U(P) \sum_{i1}^{N} \log(1 \text{SINR}_i) ]为什么用这个函数因为它能同时兼顾吞吐量和公平性。SINR 越高(\log(1\text{SINR})) 越大系统总吞吐量越好同时由于对数函数在数值较小的地方增长更快系统会自动倾向于照顾 SINR 很低的用户。如果只优化所有用户 SINR 之和系统很可能把所有功率都分配给信道最好的用户导致边缘用户被饿死。优化问题可以写成[ \max_P \quad \sum_{i1}^{N} \log(1 \text{SINR}_i) ]约束条件[ 0 \leq P_i \leq P_{max}, \quad \forall i ][ \sum_{i1}^{N} P_i \leq P_{total} ]这是一个非凸优化问题在真实系统中很难直接求全局最优解。但这不影响我们的目标我们不是要证明某个算法的全局最优性而是要让 Autoresearch Agent 在这个约束空间里自动探索出比简单基线策略更好的方案。4.4 基线策略为了评估 Agent 的效果我设置一个简单的基线策略等功率分配。等功率分配就是让每个用户分到相同的功率[ P_i \frac{P_{total}}{N} ]在 7 个用户、总功率 25 mW 的条件下每个用户分到约 3.57 mW。这个基线策略不需要任何优化适合作为对比参考。如果 Agent 在搜索结束后能找到一个效用高于等功率分配方案的功率向量说明整个 Autoresearch 闭环是有意义的。5. 完整实战从零搭建 Autoresearch Agent现在进入代码环节。下面的例子用 Python 编写依赖库只需要 NumPy因此非常适合本地跑通。我建议你按照下面的步骤一步步操作不要直接复制全部代码了事。5.1 项目结构设计我先规划了这样的项目结构agentic_power_control/ ├── environment.py ├── agent_pipeline.py ├── run_study.py └── research_notes.md三个 Python 文件职责明确environment.py负责信道生成、SINR 计算、效用计算、功率约束投影。agent_pipeline.py包含 Planner、Analyzer、StudyCoordinator 三个类构成 Autoresearch 闭环。run_study.py主程序组装组件并运行整个研究闭环。research_notes.md会在运行结束后自动生成记录每一轮实验的关键结论。这是 Autoresearch 的“研究笔记本”。5.2 编写仿真环境先看environment.py。这个文件的核心是CellEdgeEnv类。# 文件路径agentic_power_control/environment.py import numpy as np class CellEdgeEnv: 小区边缘功率控制仿真环境。 场景说明 - N 个用户位于不同小区边缘共用同一份频谱资源 - gain[i, j] 表示用户 j 的发射信号到达小区 i 基站的信道增益 - 每个用户的最大发射功率为 p_max系统总功率约束为 p_total。 def __init__(self, n_users7, p_max10.0, p_total25.0, noise1e-9, seed42): self.n_users n_users self.p_max p_max self.p_total p_total self.noise noise self.rng np.random.default_rng(seed) self.gain None self._init_channel() def _init_channel(self): 随机初始化信道增益矩阵。 服务链路增益明显高于干扰链路增益以此模拟小区边缘场景。 n self.n_users g self.rng.uniform(0.01, 0.1, size(n, n)) for i in range(n): g[i, i] self.rng.uniform(0.8, 1.2) self.gain g def compute_sinr(self, power): 根据功率向量计算每个用户的 SINR。 SINR_i P_i * G[i, i] / (sum_{j ! i} P_j * G[i, j] noise) p np.asarray(power, dtypefloat) n self.n_users signal p * np.diag(self.gain) sinr np.zeros(n) for i in range(n): interference 0.0 for j in range(n): if j ! i: interference p[j] * self.gain[i, j] sinr[i] signal[i] / (interference self.noise) return sinr def compute_utility(self, power): 计算 sum log(1 SINR)作为网络效用。 该目标函数同时兼顾吞吐量和公平性。 返回值为 (utility, sinr)。 sinr self.compute_sinr(power) utility float(np.sum(np.log1p(sinr))) return utility, sinr def project_power(self, power): 将功率向量投影到可行域内。 约束 1. 0 P_i p_max 2. sum(P_i) p_total p np.asarray(power, dtypefloat) p np.clip(p, 0.0, self.p_max) total np.sum(p) if total self.p_total: p p * (self.p_total / total) return p重点解释三个方法compute_sinr按公式逐用户计算 SINR。我用循环而不是矩阵运算是为了让代码更直白读者可以一眼看出信号和干扰的来源。实际仿真规模大时可以用矩阵乘法一次性算出所有用户的干扰。compute_utility返回效用值和 SINR 数组。注意这里返回的是float方便 Planner 比较大小。project_power是约束处理的关键。它先对所有分量做上下界裁剪再判断总功率是否超限。如果超限就按比例压缩整个功率向量使总功率恰好等于上限。这个函数保证了 Planner 无论生成多离谱的功率向量最后送入仿真环境的方案一定是可行解。5.3 实现 Planner、Analyzer 与 Coordinator接下来是agent_pipeline.py它包含三个组件。先看 Planner。# 文件路径agentic_power_control/agent_pipeline.py import numpy as np from environment import CellEdgeEnv class RandomSearchPlanner: 基于自适应随机搜索的 Planner。 在实际项目中这个类可以替换为大模型 Planner。 当前实现不依赖外部服务便于读者在没有额外资源的情况下跑通闭环。 def __init__(self, noise_scale2.0, pop_size30, seed0): self.noise_scale noise_scale self.pop_size pop_size self.rng np.random.default_rng(seed) self.best_power None self.best_utility -np.inf def propose(self, env, iteration, history): 生成一组候选功率向量。 策略围绕历史最优解加入高斯噪声并随着迭代次数增加逐渐缩小探索范围。 n env.n_users candidates [] if self.best_power is None: base np.full(n, env.p_total / n) base env.project_power(base) else: base self.best_power scale self.noise_scale / (1.0 0.1 * iteration) for _ in range(self.pop_size): candidate base self.rng.normal(0, scale, sizen) candidate env.project_power(candidate) candidates.append(candidate) return candidates def update(self, env, candidates, utilities): 从候选集中选最优解并记录全局历史最优。 best_idx int(np.argmax(utilities)) if utilities[best_idx] self.best_utility: self.best_utility utilities[best_idx] self.best_power candidates[best_idx].copy()这个 Planner 本质上是一个带自适应步长的随机搜索。它有两个参数noise_scale控制初始探索范围pop_size控制每轮生成的候选数量。随着 iteration 增大探索范围逐渐收缩系统从“广撒网”过渡到“精细搜索”。这里的history参数暂时没有在方法内部使用但它作为接口占位符非常重要。未来如果替换成一个大模型 Planner这个参数可以让模型阅读历史实验记录从而生成更智能的实验方案。然后是 Analyzer。class StudyAnalyzer: 根据实验结果生成研究建议。 def analyze(self, env, power, utility, sinr, iteration): 分析当前最优实验输出关键指标与研究建议。 min_idx int(np.argmin(sinr)) min_sinr float(sinr[min_idx]) mean_sinr float(np.mean(sinr)) max_sinr float(np.max(sinr)) total_power float(np.sum(power)) notes [] if min_sinr 1.0: notes.append( f第 {iteration} 轮用户 {min_idx} 的 SINR 偏低{min_sinr:.3f} f建议提高边缘用户功率或降低强干扰用户功率。 ) if mean_sinr 3.0: notes.append( f第 {iteration} 轮平均 SINR 达到 {mean_sinr:.3f}网络整体质量良好。 ) if total_power env.p_total * 0.95: notes.append( f第 {iteration} 轮总功率接近上限注意发射功率受限。 ) if max_sinr / min_sinr 10: notes.append( f第 {iteration} 轮用户间 SINR 差异较大公平性需要关注。 ) suggestion { iteration: int(iteration), utility: float(utility), mean_sinr: mean_sinr, min_sinr: min_sinr, max_sinr: max_sinr, total_power: total_power, power: [float(round(p, 6)) for p in power], notes: notes, } return suggestionAnalyzer 的职责是“把实验数据翻译成人类能读懂的结论”。它不只记录指标还会根据规则生成建议。例如当某个用户 SINR 很低时它会提示“提高边缘用户功率”当用户间 SINR 差异过大时它会提示“公平性需要关注”。这些建议在真实研究中可以后续反馈给 Planner作为下一轮实验的指导。最后是 StudyCoordinator。class StudyCoordinator: Autoresearch 主控流程。 职责循环调度 Planner、Environment、Analyzer 把分析结果写回历史记录形成完整研究闭环。 def __init__(self, env, planner, analyzer, max_iterations30): self.env env self.planner planner self.analyzer analyzer self.max_iterations max_iterations self.history [] def run(self): for iteration in range(self.max_iterations): candidates self.planner.propose(self.env, iteration, self.history) utilities [] sinr_list [] for power in candidates: utility, sinr self.env.compute_utility(power) utilities.append(utility) sinr_list.append(sinr) self.planner.update(self.env, candidates, utilities) best_idx int(np.argmax(utilities)) best_power candidates[best_idx] best_utility utilities[best_idx] best_sinr sinr_list[best_idx] result self.analyzer.analyze( self.env, best_power, best_utility, best_sinr, iteration ) self.history.append(result) return self.historyStudyCoordinator是整个闭环的“导演”。每一轮迭代里它调用 Planner 生成候选功率向量逐个送入环境计算效用让 Planner 更新历史最优再用 Analyzer 对当前轮最优实验做分析最后把分析结果存入历史。这里有一个设计细节值得注意当前实现是“每一轮记录本轮最优”而不是“只记录全局最优”。这样研究日志能完整呈现系统探索的轨迹读者可以看到效用值如何随着轮次提升也可以看到 Agent 在中间阶段提出的各种建议。5.4 编写