今天看来灵神的第一期视频，两数之和到三数之和

双指针第一步排序！！！！有序的数组后才能双指针

167.两数之和2

要点：双指针

class Solution {
    public int[] twoSum(int[] numbers, int target) {
        //有序 - 找两个数
        int left = 0;
        int right = numbers.length -1;
        
        while(left < right){
            int sum = numbers[left] + numbers[right];
            if(sum == target){
                break;
            }else if(sum < target){
                left++;
            }else{
                right--;
            }
        }

        return new int[]{left+1, right+1};
    }
}

三数之和

要点：双指针+去重，i里面直接continue跳过

class Solution {
    public List<List<Integer>> threeSum(int[] nums) {
        //a + b+ c = 0
        List<List<Integer>> ans = new ArrayList<>();
        Arrays.sort(nums);
        int n = nums.length;
        for(int i = 0; i < n-2; i++){
           
            if(i != 0 && nums[i-1] ==nums[i]){
                //不能修改i
                continue;
            }
            int a = nums[i];

            int left = i+1;
            int right = n -1;

            while(left < right){
                int sum = a + nums[left] +nums[right];
                if(sum == 0){
                    ans.add(new ArrayList<>(Arrays.asList(a,nums[left], nums[right])));
                    //ans.add(new ArrayList<>(Arrays.asList(a, left, right)));
                    left++;
                    right--;
                    while(left < right && nums[left] == nums[left -1]){
                        left++;
                    }

                    while(left < right && nums[right] == nums[right+1]){
                        right--;
                    }
                }else if(sum < 0){
                    left++;
                }else{
                    right--;
                }


            }



        }

        return ans;

    }
}

随机知识

一、四个 Case 是否属于智能体及其类型分析

Case A：超级计算机

• 是否属于智能体：不是（仅具备算力，无感知-决策-行动闭环）。

• 理由：它没有传感器感知环境，没有目标驱动的决策能力，也没有执行动作影响环境。虽然能高速计算，但本质上是被动执行指令的工具。

---

Case B：特斯拉自动驾驶（高速紧急决策）

• 是否属于智能体：是。

• 类型分析：

  • 按决策方式：反应式智能体（毫秒级直接映射传感器输入→刹车/变道，不使用复杂状态模型）。

  • 按环境交互：动态、实时、部分可观察。

  • 按学习能力：非学习（预设模型），但实际系统可能包含离线学习模型，在这个瞬间行为上表现为反应式。

---

Case C：AlphaGo 对弈

• 是否属于智能体：是。

• 类型分析：

  • 按决策方式：基于模型的深思熟虑型智能体（蒙特卡洛树搜索 + 价值/策略网络，模拟未来多步）。

  • 按环境确定性：确定性的、回合制。

  • 按学习能力：学习型智能体（训练后固定，但在对局中不实时学习）。

---

Case D：ChatGPT 客服

• 是否属于智能体：是（若具备查询订单等工具调用能力）。

• 类型分析：

  • 按决策方式：目标驱动的智能体（理解用户问题 → 信息查询 → 分析 → 生成回复）。

  • 按环境交互：部分可观察（不能直接感知用户真实情绪），动态（对话历史变化）。

  • 按架构：基于大语言模型的智能体，可归为符号与神经结合型（自然语言理解与推理 + 外部API调用）。

---

二、智能健身教练 – PEAS 及环境特性

PEAS 描述

维度	内容
P（性能指标）	训练效果（减脂/增肌/耐力提升）、用户满意度、动作准确率、心率保持在目标区间的时间比例、饮食建议的可行性
E（环境）	用户的身体（心率、动作、疲劳度）、可穿戴设备、运动器材、生活环境（饮食条件）、时间（训练周期）
A（执行器）	语音播报（指导、纠正）、手机APP显示（计划调整、饮食建议）、震动提醒（强度过高）
S（传感器）	心率传感器、加速度计（运动强度）、GPS（户外跑步）、用户手动输入（饮食、主观感受）

环境特性分析

• 部分可观察：无法直接测量用户的肌肉疲劳、血糖水平、睡眠质量（只能间接通过心率等推测）。

• 随机性：用户可能突然不适、设备断连、环境干扰（如噪音影响语音识别）。

• 动态性：用户状态随时间变化（心率、耐力），需要实时调整计划。

• 连续性：时间、运动强度、心率为连续值。

• 多智能体：否（单个用户与教练智能体）。

• 完全可观察性：否。

---

三、Workflow vs Agent 处理售后退款

方案A（Workflow）优缺点

• 优点：可解释性强、成本低、稳定、易审计、无幻觉风险。

• 缺点：僵化（无法处理边缘情况）、无法学习用户行为模式、易被钻规则漏洞。

方案B（Agent）优缺点

• 优点：灵活、能理解复杂情况、可适应新政策、可综合考虑用户历史行为（如高价值用户优先退款）。

• 缺点：可能产生不可预期的错误（幻觉）、需要持续维护、可解释性差、安全风险（如被诱导错误批准）。

何时更合适

• Workflow 合适：商品类型标准、金额阈值明确、政策稳定、业务量大且重复性高、要求强审计。

• Agent 合适：退款原因复杂（如质量问题、物流损坏）、需考虑用户长期价值、政策经常变动、需要个性化处理。

个人倾向

• 作为负责人，我会采用 方案C：混合模式。

• 方案C设计：

  • 80% 标准情况走 Workflow（快速、低成本）。

  • 20% 的边缘/异常/高价值/投诉升级走 Agent 评估。

  • Agent 决策可被 supervisor 一键覆盖或导出规则反哺 Workflow。

  • 例如：金额<500且≤7天自动通过；金额>500或超7天或特殊商品 → Agent 分析用户历史、商品状况、退货率等 → 输出通过/拒绝/人工复审。

---

四、智能旅行助手 – 添加记忆、备选、反思功能

基于 Thought-Action-Observation 循环，修改如下：

1. 记忆功能

• 设计：增加一个 长期记忆存储模块（如向量数据库或键值存储）。

• 修改：每次 Thought 前先检索用户偏好（“历史文化景点”、“预算<3000元”）。

• 在循环中：

  text

  Thought: 检索记忆 → 获取偏好 → 生成推荐计划
  Action: 查询景点信息
  Observation: 返回结果
  Memory Update: 记录用户本次接受/拒绝的景点类型

2. 门票售罄 → 备选推荐

• 思路：当 Observation 返回“门票已售罄”，触发 备选生成策略，不直接结束循环。

• 循环中：

  text

  Action: 查询景点 A 门票
  Observation: 已售罄
  Thought: 根据记忆中用户偏好，生成相似景点 B/C
  Action: 查询 B/C 状态

3. 连续拒绝 3 次 → 反思调整策略

• 设计：维护一个 拒绝计数器。连续拒绝 3 次后，进入 反思模式。

• 反思内容：

  • 分析被拒绝景点的共同特征（是否偏离偏好？是否价格超标？）。

  • 主动询问用户：“我注意到您几次拒绝了推荐，是否我误解了您的偏好？更喜欢博物馆还是自然风光？”

  • 调整推荐模型参数（如降低“热门度”权重，提高“预算匹配”权重）。

---

五、系统1与系统2协同 – 医疗诊断助手场景

场景：急诊分诊与初步诊断智能体

系统1（快速直觉）处理任务

• 根据生命体征（心率、血压、血氧）快速判断是否危重（如休克、心梗）。

• 根据主诉关键词（“胸痛”、“呼吸困难”）立即触发警报。

• 标准流程识别（如感冒症状匹配常见病模板）。

系统2（慢速推理）处理任务

• 罕见病或复杂混合症状的鉴别诊断（如狼疮 vs 类风湿）。

• 分析检查报告（影像、实验室数据）的深层关联。

• 制定长期治疗方案，考虑药物相互作用、患者历史病历。

协同机制

• 层级触发：系统1优先运行（毫秒级），若判断“低风险”则唤醒系统2进行细致分析；若判断“高风险”直接发出分诊指令并同时通知系统2准备详细报告。

• 反馈校正：系统2发现系统1误判（例如把焦虑引起的胸痛误判为心梗），则调整系统1的规则/阈值。

• 资源调度：系统1占用低算力常驻运行，系统2按需激活。

---

六、大模型智能体的局限

1. 为什么会产生“幻觉”？

• 原因：大模型本质是概率性的 token 预测，没有内在的真值校验机制。当训练数据中缺乏相关知识，或推理路径过长导致概率分布发散时，模型会生成统计上合理但事实错误的续写。

• 在智能体中加剧的因素：观察→思考→行动循环中的错误累积，以及没有直接的环境反馈来纠正事实错误。

2. 无最大循环次数限制会导致什么问题？

• 无限循环：例如，推荐 A → 用户拒绝 → 推荐 A'（与 A 相似）→ 再次被拒 → 陷入同质推荐循环。

• 资源耗尽：每次行动可能调用外部 API（如查询航班），无限循环会产生成本和延迟。

• 发散行为：反思机制可能导致不断修改自身计划，永远不落地行动。

• 错误放大：早期一个微小错误在循环中不断被当作前提，导致严重偏离目标。

3. 如何评估“智能”程度？仅用准确率足够吗？

不够。应综合评估：

• 有效性：任务完成率（如成功订到符合偏好的酒店）。

• 效率：完成任务的步数、时间、token 成本。

• 鲁棒性：面对干扰（信息缺失、异常输入）的恢复能力。

• 可解释性：用户或开发者能否理解决策过程。

• 安全性：是否产生有害行为（如泄露隐私、恶意操作）。

• 适应性：在新环境或任务上无需重新训练即能达到可用水平。

• 样本效率：需要多少交互经验才能学会任务（对学习型智能体）。

准确率仅适用于分类任务，无法衡量规划、探索、权衡、长期记忆利用等智能体核心能力。

1. 物理符号系统假说

充分性论断与必要性论断

• 充分性论断：如果一个系统是物理符号系统，那么它就具备了产生智能行为的充分条件（即物理符号系统 ⇒ 智能）。

• 必要性论断：任何能够表现出智能的系统，必然是一个物理符号系统（即智能 ⇒ 物理符号系统）。

符号主义智能体遇到的挑战（对充分性的质疑）

• 符号接地问题：符号如何与真实世界中的意义连接？机器人无法仅靠符号运算理解“红色”。

• 知识获取瓶颈：人工编写所有规则极其困难，系统无法自动从数据中学习。

• 脆弱性：规则稍有不匹配就完全失效，缺乏鲁棒性和容错能力。

• 组合爆炸：现实问题需要大量规则，相互冲突且难以维护。

大语言模型智能体是否符合该假说？

• 观点：不完全符合。

• 理由：LLM 虽然处理的是符号（token），但其内部表示不是经典意义上的离散物理符号系统（没有显式的逻辑规则和符号推理链条）。它们是亚符号系统，通过向量和分布式表示运作。若严格按 Newell & Simon 的定义，LLM 不是标准物理符号系统；若放宽要求（只要处理符号就可以），则可勉强归入，但丧失了该假说的原意——符号操作是智能的充要条件。

---

2. 专家系统 MYCIN 的局限与改进

阻碍应用的更多因素

• 伦理责任：诊断错误时谁负责？医生、开发方还是医院？

• 法律风险：系统建议与医生判断冲突时，法律上难以采信。

• 用户接受度：医生不愿被“黑箱”建议代替，感到权威受挑战。

• 时效性与更新：医学知识快速变化，规则库更新困难。

• 数据隐私：患者敏感信息需本地处理，但专家系统通常需集中知识库。

• 交互笨拙：固定问答流程，无法自然对话。

设计现代医疗诊断智能体的改进方案

• 架构：大语言模型（自然对话）+ 知识图谱（医学知识）+ 规则引擎（指南） + 深度学习模型（影像识别）。

• 克服局限：

  • 知识获取：从医学文献/病历中自动抽取并更新知识图谱。

  • 脆弱性：结合概率推理（贝叶斯网络）和不确定性量化。

  • 交互：自然语言理解 + 追问澄清，像医生一样对话。

  • 责任：作为“辅助诊断工具”，输出带置信度和依据的推荐，最终由医生决定。

  • 隐私：本地微调小模型 + 联邦学习。

规则专家系统仍优于深度学习的领域

• 需要完全可解释且风险极低的场景：例如税务申报审核（规则由税法明文规定）、企业合规检查（如是否违反某条法规）、航空航天发射前安全检查（逻辑明确，不能有黑箱）。

• 数据极少或无法收集：如核电站应急处理流程，无法用深度学习从“事故数据”中学习。

---

3. ELIZA 扩展实践

新增规则示例（关键词匹配模式）

关键词	响应模板
工作	“您在工作中感到压力吗？能具体说说吗？”
学习	“学习新技能很有趣，也会遇到挑战。您在学习什么？”
爱好	“您的爱好很有意义，它带给您什么感受？”
名字	“很高兴认识您，{name}。这个名字有什么含义吗？”
年龄	“{age}岁正是积累人生经验的好时候。”

上下文记忆实现思路

• 使用字典 memory = {"name": None, "age": None, "job": None}。

• 匹配规则时，如果用户说“我叫张三”，则 memory["name"]="张三"。

• 后续对话可引用：“张三，您之前提到的工作压力还在影响您吗？”

扩展 ELIZA vs ChatGPT 的本质差异（3个维度）

维度	扩展ELIZA	ChatGPT
理解机制	模式匹配 + 模板替换，无真实语义	深度神经网络 + 注意力机制，具备语义理解
泛化能力	只能处理预设模式，未见过的表达就失败	可处理无限种类的自然语言表达
上下文长度	手动记忆少数槽位	数千甚至数万 token 的长期上下文

组合爆炸的数学说明

假设每句话有 nn 种可能的用户意图，每种意图需要 mm 种响应模式，系统需要覆盖 n×mn×m 条规则才能自然对话。
实际语言中 nn 和 mm 可以巨大且连续（并非离散有限），规则数 R=O(nL)R=O(nL)，其中 LL 是对话轮数。
开放域下，n→∞n→∞，规则无法枚举。即使有限词汇，组合数也远超宇宙原子数（例如1000个词组成10个词的句子，可能组合数 100010=1030100010=1030）。

---

4. 心智社会理论

GRASP 失效的影响及去中心化优劣

• 后果：积木塔无法稳定抓取，整个建塔任务失败。但其他智能体（如 MOVE、RELEASE）不会崩溃，只是无法完成高层次目标。

• 优势：容错性（单个体失效不影响全系统）、易扩展、可并行。

• 劣势：协调开销大、整体行为难以预测、可能出现死锁或资源竞争。

与传统多智能体系统的对比

• 关联：都是多个智能体协作完成复杂任务；每个智能体相对简单。

• 不同：

  • 心智社会中智能体是极简、无意识的过程（如“抓”智能体只知道抓）。

  • 现代系统（MetaGPT等）中的智能体通常是LLM驱动的，具备推理、角色扮演、自然语言通信能力，更为复杂。

心智社会理论是否过时？

• 不过时。LLM 智能体可视为心智社会中的“强大单个智能体”，但整体系统仍可由多个 LLM 智能体协作构成（如一个负责规划、一个负责执行、一个负责检查）。明斯基的核心洞见——智能通过协作涌现——在 LLM 时代反而更易实现。

---

5. 强化学习 vs 监督学习

AlphaGo 的试错学习机制

• 自我对弈（self-play）：不断与自己对弈，输赢作为奖励信号。

• 策略网络：更新参数以提高赢棋概率（相当于试错中学习哪些走法好）。

• 价值网络：评估局面胜率，长期回报指导当前决策。

强化学习适合序贯决策的原因

• 需考虑当前动作对未来的影响，而监督学习假设各样本独立同分布。

• 数据需求差异：

  • 监督学习：需要（状态，最优动作）标签，通常由人类专家提供。

  • 强化学习：只需要奖励信号，不需要最优动作标签，通过探索获得。

超级马里奥游戏数据需求对比

• 监督学习：需要大量（游戏画面，人类玩家的正确操作）对，但人类不可能穷尽所有状态。

• 强化学习：只需定义奖励（过关+，死亡-，金币+），智能体自己探索。

• 更合适：强化学习，因为状态空间巨大且无法人工标注所有最优动作。

RL 在大语言模型中的作用

• RLHF（人类反馈强化学习）：让 LLM 从偏好比较中学习对齐人类意图（而不是只做下一个词预测）。

• 关键作用：减少有害输出、提高有用性、抑制幻觉、保持对话策略一致。

---

6. 预训练-微调范式

预训练解决知识获取瓶颈

• 符号主义：知识需人工编码为规则或逻辑谓词，费时、不完整、难更新。

• 预训练模型：从海量文本自动学习分布式知识表示（嵌入向量、权重矩阵），不需要人工显式编码。

• 本质区别：符号知识是离散、显式的；预训练知识是连续、隐式的、可微分的。

互联网数据带来的问题与缓解

• 问题：偏见（性别/种族）、虚假信息、隐私泄露、有害内容、版权问题。

• 缓解方法：

  • 数据清洗与去偏。

  • 人类反馈强化学习（RLHF）调整输出。

  • 差分隐私训练。

  • 检索增强生成（RAG）引用可靠来源。

预训练-微调会被取代吗？

• 可能长期存在，但形态变化：从一次性预训练转向持续学习、模型合并、上下文学习（ICL）、模型即服务中在线适应。

• 若有更高效的知识表示与压缩方法（如极大规模稀疏专家模型、生物启发学习），也可能替代，但目前未见革命性突破。

---

7. 智能代码审查助手：三个时代的对比

符号主义时代（1980年代）的实现与困难

• 实现：手写规则（如“函数长度 > 100 行则警告”、“未使用变量”），用 Lisp 或 Prolog 实现静态分析。

• 困难：

  • 无法理解代码语义（只能语法模式匹配）。

  • 规则数量爆炸，无法检测逻辑错误（如死循环、空指针）。

  • 难以概括代码意图（PR 描述与代码是否一致）。

深度学习时代（2015年左右）

• 实现：用图神经网络（GNN）分析抽象语法树（AST），训练分类器检测常见 bug 类型；用序列模型（LSTM）处理代码序列。

• 局限：需要大量标注好的 bug 数据；不能生成自然语言解释；难以处理长距离依赖和项目上下文。

LLM 智能体时代（当前）

• 架构设计（参考图2.10）：

  • 感知模块：PR diff + 历史评论 + 项目文档。

  • 计划模块：确定审查要点（逻辑、风格、安全、性能）。

  • 工具使用模块：调用静态分析工具（如 linter）、测试运行器。

  • 记忆模块：记住项目特有约定、以往 PR 的典型问题。

  • 推理模块：LLM 核心，生成代码概括、bug 分析与修改建议。

  • 行动模块：输出评论 + 建议代码补丁。

技术演进如何使任务从“几乎不可能”变为“可行”

• 1980：只能做语法检查，无法理解意图。

• 2015：可检测部分语义 bug，但无法生成流畅解释，且跨文件理解弱。

• 2023+：LLM 具备代码与自然语言的联合理解能力，可以“读懂”代码逻辑、概括功能、发现深层错误（如并发问题），并给出易于开发者理解的建议。结合工具调用（执行测试、检查类型）进一步提高了可靠性

碎碎念：后续会更新每天学习的八股和算法 题，开始准备秋招的第15天。努力连续更新100天！以后每天就按，秋招项目【java+agent】，科研，必做项目，算法，八股，锻炼身体来总结。今天效率一般。明天加油！！！

总结：不要放弃呀，

1.算法要系统过一遍【灵神】1/27

2.秋招项目【java可能ok？】【agent继续加油】，算是跑通了，准备看代码开始背

3.科研要跑一下，无

4.必搞项目也得总结文档，无，

5.训练项目看看先选择好，无

6.背八股，无

7.锻炼身体，无

昨天睡太晚了啊啊啊，明天加油加油！！！

【最后最后，请相信自己可以的！！！！！】