2025-10-11 16:04:20
团队内部最近常出现一种论调：“现在做 Agent 很简单，用 LangChain、百炼、Flowise 搭一搭就能跑。”
这句话乍一听确实无法反驳 —— 框架确实降低了门槛。但那种“简单”，更像是复杂性暂时被平台吸收后的假象。从技术层面看，Agent 开发涉及：
这些环节并不是写几个 prompt 就能搞定的。 当开发者觉得“简单”其实是因为——复杂性被平台吸收了。 Agent 之难，不在跑通 Demo，而在让它长期、稳定、可控地运行。
从表面看，我们站在了一个 AI 爆炸的年代，各种平台与工具层出不穷。确实写几个 prompt、拼几层链路，一个“能动”的 Agent 就诞生了。但这并不是复杂性消失的标志，而是——复杂性被转移了位置。
我把这层“简单”拆成三种幻觉：
框架帮你拼接 prompt、裁剪 context，让开发者远离细节，但调试、trace、状态恢复这些底层骨架，仍无人替你承担。
以 LangChain 为例，只需几行代码即可创建一个 “能回答问题” 的 Agent：
from langchain.agents import initialize_agent, load_tools
from langchain.llms import OpenAI
llm = OpenAI(temperature=0)
tools = load_tools(["serpapi", "llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description")
agent.run("给我查一下新加坡现在的天气，并换算成摄氏度")
这段代码几乎隐藏了所有复杂性：
看似“简单运行”，实则丧失了可观测与调试的接口。
Memory、RAG、Embedding 全交由平台托管，代价是失去了干预与解释的能力。在 LangChain 中，你可以快速添加“记忆”：
from langchain.memory import ConversationBufferMemory
memory = ConversationBufferMemory(memory_key="chat_history")
但这只是短期记忆缓冲，它不会处理：
当 Agent 规模扩大，内存一致性与状态清理反而成了新的系统复杂度。
它不会消失，只会在运行阶段重新显现：
能跑起来并不等于能长期跑得对。所谓简单，其实是我们暂时不用面对复杂。
Agent 系统的复杂性体现在可运行、可复现、可进化。当下的 Agent 框架大多解决了「可运行性」，但「可复现性」与「可进化性」仍是系统工程难题。
| 层次 | 核心目标 | 工程关键词 | LangChain 示例说明 |
|---|---|---|---|
| 可运行性（Run） | 让 Agent 能启动并执行任务 | prompt、context、工具调用、执行流 | 通过 initialize_agent 快速组装可执行链路 |
| 可复现性（Reproduce） | 让行为可控、可调试 | memory、状态、日志、版本化 | 无内建版本追踪，Memory 状态漂移需人工管理 |
| 可进化性（Evolve） | 让系统能持续变聪明 | RAG、反馈回路、协作、安全边界 | 支持向量检索，但缺少自我评估与强化学习机制 |
在“可运行性”层面，以LangChain为代表的框架的抽象设计确实高效。但若要让 Agent 行为稳定、可解释、可持续优化，仍需额外引入日志系统、prompt 版本管理、feedback loop 等基础设施。
从系统工程角度看，Agent 的难点并非在“生成”而在“执行”。所有平台最终都会在这两条生命线上暴露代价。
| 维度 | 定义 | 常见问题 | 本质 |
|---|---|---|---|
| 正确性（Correctness） | 每次决策是否正确 | 幻觉、误调用、逻辑偏差 | 输出逻辑错 |
| 稳定性（Stability） | 系统是否可复现 | 状态漂移、死循环、随机波动 | 行为不确定 |
在落地阶段，稳定性往往比正确性更关键。只有稳定性存在，正确性才有被验证和优化的可能性。
智能的不确定性必须以工程的确定性为支撑。稳定与可观测，是 Agent 真正可演化的前提。
如上图所示，同样的模型(qwen-max)，同样的时间、同样的prompt，产生的结果缺不一样，这就是LLM的不确定性带给Agent的放大效应。相对于开发者最熟悉的传统软件系统的开发，Agent带来的复杂和难点就源于它被 LLM 的不确定性和语义层次的逐级放大了。假设一次LLM交互正确率为90%，一个Agent系统需要10次LLM的交互，那么这个Agent系统的正确率就只有35%，一个Agent系统需要20次LLM的交互，那么这个Agent系统的正确率只有12%。
相比传统软件的状态管理来说（是确定性的，例如数据库里有啥就是啥），Agent 的memory依赖 LLM 的解析、embedding、检索，结果高度不确定，所以memory不是存取问题而是语义一致性问题，这是 Agent 特有的。
传统系统里编排（workflow/orchestration）是固定的流程，预定义好。Agent 里编排常常是 LLM 动态决定下一步调用哪个工具、如何调用。这意味着编排问题不仅是“顺序/并发”的问题，而是决策空间爆炸，导致测试、监控、优化都更复杂。
传统软件可预测：给定输入 → 预期输出。Agent 的输出是概率分布（LLM 输出 token 流），没有严格确定性。所以测试不能只用单元测试，而要引入 回放测试、对比基线测试、模拟环境测试，这就远超普通应用测试的难度。
有人说，Agent开发的时候我修改修改提示词也能达到目标，是否是我自己放大了问题并不是Agent放大了上面提到的不确定性。
“改改提示词就能跑通”，本质上其实在说：短期目标 + 容忍度高 = 足够好，而Agent系统的目标是：长期目标 + 工程级可靠性 = 难度激增。
先看看为什么改改prompt就能跑通，很多 Agent Demo 或 POC（Proof of Concept）目标是 一次性任务，比如“帮我写个总结”“调用下 API”，在这种低要求场景里，LLM 本身的强大能力掩盖了很多问题：
是我放大了问题还是Agent系统放大了问题，其实需要从需求出发，因为当需求从 “Demo” → “持续可用系统” 时，问题会迅速被放大：
Prompt 修改 ≠ 可靠性保证，改提示词可能解决眼前 bug，但没有保证同类问题不会在别的 case 再次出现。你其实没有建立可复现、可维护的决策逻辑，只是调参式“玄学优化”。Prompt 修改 ≠ 可扩展性，在单任务 Agent 下，prompt hack 有效。但在多工具、多场景 Agent 里，prompt 的复杂度指数级增长，最终失控。Prompt 修改 ≠ 工程可控性，传统软件能写测试 case 保证逻辑覆盖，但是 prompt 只能部分缓解 LLM 的概率波动，没法做强保证。所以最终需要更结构化的 memory、编排和测试手段 —— Agent系统化。
以Langchain框架为例，看看框架是否能够解决Agent三层复杂度的问题。LangChain 提供了基础的 CallbackManager 与 LangSmith（或Lanfuse） 集成，用于追踪 Agent 的执行过程。这部分功能通常被忽略，却是理解「可复现性」与「可观测性」的关键。
from langchain.callbacks import StdOutCallbackHandler, CallbackManager
from langchain.llms import OpenAI
from langchain.agents import initialize_agent, load_tools
# 创建一个简单的回调管理器
handler = StdOutCallbackHandler()
manager = CallbackManager([handler])
llm = OpenAI(temperature=0, callback_manager=manager)
tools = load_tools(["llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description")
agent.run("计算一下 (15 + 9) * 2 是多少？")
执行时，LangChain 会在终端输出每一次 思考（Thought） 与 动作（Action）：
Thought: 我需要使用计算工具。
Action: Calculator
Action Input: (15 + 9) * 2
Observation: 48
Thought: 我现在知道最终答案了。
Final Answer: 48
看似简单的输出，其实揭示了三个重要事实：
LangSmith 提供了更完善的可视化 trace，但依然属于外部观测工具，Agent 框架本身仍未内建可验证机制。也就是说，框架给你“看”的能力，却不会替你“控”的问题。
虽然Langchain这样的框架已经有意思的在解决Agent系统中的复杂问题，但是不得不承认当前大部分工程维度仍然是未解决的（简言之，框架解决了“调用 LLM 做事”的问题，但没有解决“让 LLM 做事像系统那样可控、可持续、可扩展”的问题）：
| 模块 | 当前框架提供 | 未覆盖 / 待工程化部分 |
|---|---|---|
| 推理层 (LLM Layer) | 模型调用、Prompt 模板 | 输出稳定性、任务上下文约束、幻觉检测 |
| 工具层 (Tools Layer) | API 调用、函数路由 | 工具调用安全沙箱、权限控制、错误恢复 |
| 记忆层 (Memory Layer) | 基本向量检索、会话上下文 | 长期记忆压缩、冲突检测、记忆衰减策略 |
| 协调层 (Orchestration) | 简单 loop 或链式调用 | 多任务调度、计划优化、Agent 间依赖图 |
| 评估层 (Evaluation) | 少量 tracing、benchmark | 自动指标体系（成功率、可控性、成本监控） |
| 安全与合规 (Safety & Compliance) | 几乎缺失 | 执行边界、权限模型、审计日志、沙箱执行 |
| 部署与运维 (Ops) | 少量 SDK、CLI 工具 | 持久化、弹性伸缩、版本管理、A/B 测试机制 |
| 框架 | 可运行性 | 可复现性 | 可进化性 | 说明 |
|---|---|---|---|---|
| LangChain | ✅ 链式调用成熟 | ⚙️ 部分可观测 | ⚙️ 手动调优 | 工具多，但状态不稳 |
| AutoGen | ✅ 多 Agent 协作 | ⚙️ 初级记忆 | ❌ 缺乏学习机制 | 灵活但难复现 |
| CrewAI | ✅ 任务编排便捷 | ⚙️ 状态不稳定 | ❌ 无反馈优化 | 强交互，弱管控 |
| 阿里云百炼 | ✅ 拖拽式搭建 | ⚙️ 平台日志 | ⚙️ 内置知识中心 | 平台吸收复杂性，但黑箱严重，控制粒度受限 |
LangChain 让 Agent “能搭”，却让系统失去了“能解释”的能力。复杂性并未消失，只是从代码层迁移到了运行时。
我们再来深入的分析一下运行时的复杂度，即Agent系统带来的新问题——它不仅要运行，还要「持续思考」，而思考的副作用就是不稳定性。这些复杂性不是「传统的代码复杂度」，而是「智能行为带来的系统不确定性」。它们让 Agent 工程更像在管理一个复杂适应系统 ，而非线性可控的软件。
| 新增复杂性维度 | 描述 | 示例场景 |
|---|---|---|
| 上下文漂移 (Context Drift) | 模型在多轮推理中误解或遗忘关键任务目标 | 多轮对话中 Agent 偏离任务语义，执行无关动作 |
| 语义非确定性 (Non-determinism) | 同样输入可能产生不同输出，导致流程不可重放 | Prompt 调试后结果不稳定、自动测试难以覆盖 |
| 任务分解与规划 (Decomposition) | LLM 生成的计划质量不稳定、任务边界模糊 | AutoGen 的“plan+execute”模式中，子任务溢出或循环 |
| 记忆污染 (Memory Pollution) | 长期存储的上下文引入噪声或冲突信息 | Agent 学会错误知识，导致后续执行偏差 |
| 控制权与边界模糊 (Control Ambiguity) | Agent 的执行与人类/系统控制层之间界限不清 | 人工指令被覆盖、重复任务、资源滥用 |
| 自适应演化风险 (Self-Adaptation Drift) | Agent 基于反馈学习错误模式或行为 | RLHF/反思循环中强化了幻觉响应 |
| 多Agent 协同复杂性 (Coordination) | Agent 间通信、角色分配、冲突解决 | CrewAI 等多角色系统中任务重复或冲突 |
Memory + 知识库保证 Agent 能学到、积累下来，不是每次都重造轮子。Prompt Hack/Demo Agent 能解决的是“小问题”，系统化 Agent 才能解决“扩展性、可靠性、沉淀”的问题。这些问题现在可能不明显，但随着使用时间和范围扩大，必然会爆发。
Demo Agent 确实能解决问题，但只能解决今天的问题，系统化 Agent 才能解决明天和后天的问题。
| 维度 | Demo Agent（能跑起来） | 系统化 Agent（可持续运行） |
|---|---|---|
| 目标 | 单次任务/POC 成功 | 连续、可重复、多人依赖的业务 |
| 记忆/知识 | 聊天记录直塞；偶尔向量检索 | 分层记忆（会话/短期/长期+RAG 策略）；一致性与版本化 |
| 编排/状态 | 顺序调用/简单 ReAct；无显式状态 | 显式状态机/图（并发、回滚、重试、超时、容错） |
| 可靠性与测试 | 以“能过样例”为准；不可复现 | 回放集/基线对比/ fuzz 测；SLO 与失败模式设计 |
| 可观测性 | 打几行日志 | 端到端 tracing、调用链、指标、审计 |
| 安全/权限 | Prompt 里写约束 | 细粒度权限/沙箱/审计轨迹/越权防护 |
| 扩展性 | 场景一多，Prompt 失控 | 模块化组件/模型路由/工具治理 |
| 成本曲线 | 前期快/便宜；后期维护飙升 | 前期工程化投入；后期稳定、可扩展 |
以史为镜，可以知兴替；以人为镜，可以明得失，我在Agent系统开发过程中碰到的问题一定不止我一个人，我让ChatGPT帮我搜索了Reddit、GitHub、Blog中关于Agent开发的案例，想借助别人的案例来验证我自己的思考和反思是否一致：
__aenter__）：显示依赖/版本锁定与回归测试的必要性，AgentExecutor ainvoke stopped working after version upgrade
一年多的Agent开发，我经历Agent很简单到Agent真复杂的认知变化，最开始把框架当黑盒，写 prompt 拼拼凑凑，就能跑个 demo，随着场景复杂性提升需要往Agent系统研发的深处走时，难点就逐步暴露出来。我尝试把这个“简单 → 真难”的过程拆了一下：
用 LangChain / CrewAI 之类的框架，几行代码就能跑起来，大多数停在“能对话”、“能调用工具”这层，所以觉得“AI Agent 开发不过如此”。
随着Agent解决问题的复杂度提升，慢慢会碰到LLM context窗口装不下，需要裁剪、压缩、选择（即Context 管理问题），然后又发现向量检索、数据获取的结果经常无关、答非所问，需要优化预处理、query 重写（RAG知识管理），渐渐地我认识到简单场景能跑，但是稍微复杂点就掉坑。
再进一步，Agent随着工具调用、上下文管理增加（例如复杂安全威胁建模过程），需要保证跨会话、跨任务一致性，必须考虑持久化、版本控制、冲突解决。单个Agent无法适应复杂任务（例如复杂的漏洞风险评估任务），需要多 Agent 协同，此时就必须解决 deadlock、任务冲突、状态回滚。任务的复杂性上来了Agent 流程调试就不是改改 prompt 能解决的，要加 tracing、可观测性工具。
Langchain框架、百炼平台等确实让Agent“起步门槛”变低，但没有降低“落地门槛”。第三阶段、第四阶段很多问题，我也是摸着石头过河，当下还总结不出任何经验和结论。
我一直围绕自己工作中涉及到的漏洞安全评估开发Agent系统，在经历上面提到的四个Agent开发的时候，我对Agent的思考和理解也在变化：
结合当下对Agent的理解，当前我对Agent的定位是将其视作一个系统组件而非智能机器人，我的目标不是“偶尔惊艳”而是“持续可靠”。基本原则：
好像有人说过2025是Agent元年，经过将近一年的Agent技术迭代，Agent也从工程角度有了比较长足的发展，Langchain基本上已经成为Agent system后端的优先选项，Agent研发也经历 prompt engineering → context engineering的演变（如下图所示）。
最后，我想分享一下当下Agent工程上最新进展以及Agent system最新的工程经验值得借鉴与学习：
最后，也许未来的框架能进一步吸收这些复杂性。但工程师的角色不会因此消失。我们要做的，是在复杂性被隐藏的地方，重新建立秩序 —— 让智能不只是可调用，更是可驯服。
2025-10-03 19:50:24
E41 孟岩对话阿娇：我的另一面，也想被注视和欣赏
播客对谈刚开始（22:42）的一段对话，跟去年的付航给我的感受很相似：
孟岩：我还是会好奇那些，为什么一个人可以变成这样的，可以去解决任何问题的人
阿娇：我没有，我没有
阿娇说「我没有」的时候，喉咙是略带干涩的，一段明显的停顿之后再次强调了一下「我没有」。第一次听这一段的时候，我正好在开车通勤，当时鼻子一酸，到现在我还是不知道用什么语言描述我当时内心的感受。
这期播客中有非常多的停顿，孟岩的、阿娇的，有各自一度语塞的、有阿娇身体不适的杂音、有喝水的咕噜声等等，在追求严谨、品质、精致的播客里这无疑是惨不忍睹的。但是我很珍惜这一期播客，小宇宙里唯一收藏的就是它了，相比当下社交媒体为大众营造的美好、精致、暖心、振奋，它足够真实，还原了这个世界本来的样子，可以有口癖、有粗口、有空白。
这期播客我听了很多遍，因为心境不同，其实前几遍的时候，我并不太理解阿娇和孟岩对谈的一些话。
「这几个月，我反反复复在想，也反反复复有人在聊的东西——为什么死亡已经迫在眉睫，看起来这世间一切都即将与我无关，可欲望没有退潮？为什么我对自己的诸多想象，我的诸多理想主义，我的追求，我的欲念，它未曾消退？我以为会一切返璞归真，去伪存真，最后只剩一两件要紧的事，一两个要紧的人，但是偏偏不，我还是有那么多想做的事情。」
「真正的外部评价无法刺穿的屏障，是只有我自己能刺穿的。」
「正是因为我有很多想说的，那不说也好，不说也好。把那些话留着，让我自己去消化，然后把那些表达欲留着，让我自己去消化，我们之间留一些无人知晓的留白。 可能在你以后几十年的生命里，我不知道你会不会再想起我，（可能）某一次晚霞，或是某一次海口的落日，会让你再想起我这个人，然后你再回味时，你回味起的，也许就是我想跟你说的话。」
阿娇期待别人的注视，特别是与高手的对谈，但是她不喜欢别人用标签的滤镜来关注她，阿娇的心境与我过往写的一篇博文不谋而合（如何减少标签对自己分享带来的压力）。作为一个被医生预测只能活到今年八月份的晚期病人，她自己都没法预测下一周能否「完美交付」，所以她更加希望珍惜自己每次的「在场」，我想当下对阿娇而言Everything matters，她渴望的是被看见和尊重的专业能力、平等的智识交流、完整且立体的女性。
所以孟岩提到的「你要是能够有钱做投资，一定会是一个很好的投资人」，其实说明他是没有真正理解傲娇，还是带着「柱子哥」的标签来看待阿娇。我也能理解孟岩在问阿娇「我们交流了之后还觉得我是高手吗？」，阿娇没有正面的回答，但我觉得已经给出答案了，一个被阿娇认为非常charming、智慧的孟岩也并没有真正的看到懂得如何注视阿娇。阿娇追求的是在命运的巨大不确定性面前，夺回对自己生命叙事的定义权，其实在跟孟岩的交流中就已经给出答案了：「我，阿娇，首先是一个有能力的专业人士，一个热爱生活的独立女性，其次，才是一个病人。」
这期播客里孟岩像是一个客人，言语之间充满了谨慎，他的语调与提问，随时在自我提醒：这一步会不会冒犯到的。那份小心并不傲慢冷漠，反而带着温度——一种想要守护的敬意。
我能理解，孟岩的谨慎来自悲悯以及对话题重量的清醒认知，更是来自健康者难以跨越的距离感。阿娇的坦然，并不是无能为力的自我安慰，而是带着遗憾地一次次与死亡的直面、与痛苦的缠斗。她已把死亡当作生活里不可回避的「考题」，用一种近乎平常心的姿态谈论它。
我能理解也更感谢孟岩，在这期的对谈没有运用任何技巧和引导（这是孟岩擅长的，却是对阿娇的误解和亵渎），孟岩没有让他们的对话陷入对苦难的消费，也没有流于空洞的正能量，他守住了边界与尊严，坦然赋予了厚度与真实。那些停顿、噪点与呼吸，比流畅的表达更有力量——它们让人听见了生命最真实的质感。
我重复听了很多遍这期播客，阿娇让我想到了自己的一位远赴异国的老友阿楠，她们两个给我的感受很像，聪明能干、倔强要强、直面挑战和对抗。也不知道经历了生活的磨砺之后，现在的老友有没有改变，不过我知道她现在很开心很幸福，这是让我觉得好的地方。至少，在生命体验的角度阿娇跟阿楠是不一样的，我的朋友是无比幸运且幸福的。
2025-09-14 14:57:24
最近在复盘松烟阁管理的时候，我用朱雀检测测试了一下最近的两篇博文，结果还挺精确：
两篇文档都是出自我手，我非常清楚其中的细节以及写作的过程，第一篇是我纯手写，第二篇表格部分是我用Gemini生成的，由此可以见检测结果与事实完全正确。
自从AI能够生成高质量内容就是，创作者群里就一种声音表达自己对内容的洁癖，比较激进的甚至会表达类似「只要是AI生成的内容就不愿意付出精力和时间去阅读」。我一直努力在克制自己创作内容中掺入AI生成的部分，不过确实要承认在结构化思考和表达上AI更优秀，起码比我自己的表现是要好的，慢慢地我可以接受自己为文章内容提供灵魂，而AI为我的文章内容提供装饰品。
AI正在深刻的改变我们生活的方方面面，我想写作上就是这样的，而怎么控制好以及怎么区分是否来自AI，这就是我今后要逐步积累和锻炼的能力。
换个视角，其实这两篇检测报告也从另一个方面证实了一个AI和人是有区别的。
AIGC的本质就是将人类语言通过分词进行向量化，通过神经网络将文本、语言问题转换成了矩阵运算的问题，无论是余弦相似度或者是欧几里得距离表示生成内容与输入内容的相关性，这些向量都是人类语言在高维空间的映射表示。
而朱雀检测能够通过大模型区分出人写的和AI生成的，其实意味着人自己写的东西在高维空间是有非常显著特征的，只是生活中三维空间的人普遍没办法感知到而已。朱雀检测其实就量化的证明了，在某个未知的高维空间里面可以非常清晰地区分人写的内容与AI生成的内容的。
从这个角度来看，我一直输出写作是有意义的，因为数学说明了在这个时空的某个维度我的内容具备了AI没法取代我的特征（至少目前为止AI做不到取代我），这样的经历让重新对人的创作有了信心。做一个坚定的人类相信者，拥抱和享受AI给我们带来的变化吧。
最后，致敬那些一直在坚持自己博客的朋友，以此共勉！
2025-09-07 17:26:45
最近职场槽点真的有点多，这周开会的时候大老板在质疑AI投入的必要性问题，其中有一句我个人觉得可以列入年度金句了：“没有用AI之前，xxx问题有什么影响？我看大家都觉得没什么问题都能扛得住，我承认它是「屎」，但是不是大家也能忍着，也没出什么事......”
说这句话是基于大老板对于当前AI的认识：
在大厂环境中，上面提到的大老板的这些潜台词无可厚非，我不打算做更多的吐槽，我打算思考一个问题：怎么判断一段内容是AI生成的，它的特点和根因是什么。
只有了解通用大模型生成内容的原理以及特点，才能继续评价Agent的价值和发展，这个问题留待下一篇职场生存实录文章探讨吧。
读一段文字，你有没有过那种感觉？哪儿都对，就是心里不得劲，通顺有逻辑，但就是没人味儿。当时我还纳闷，后来才反应过来，这就是所谓的“AI味”。
一开始我也觉得，是AI还不够牛，等它再进化几代就好了。利用周末的时间我研究了一下这个问题，我感觉这根本不是技术问题，换言之模型进化未必能解。AI的本质是个超级厉害的统计学模型能算出哪个词后面跟哪个词的概率最高——它知道“心碎”这个词旁边经常出现“眼泪”和“夜晚”——但它跟人不一样没有自己的「心」，所以它根本不知道心碎是种什么感觉，这些具身数据的缺失注定它没办法真正“体验”，就像一个人照着菜谱念菜名，词儿都对但没有锅气。
为了可以识别“AI味”，我觉得可以从结构、语言、语调和内容深度四个维度来分析“AI”内容的特点：
| 类别 | 具体标志 | 示例 |
|---|---|---|
| 结构 | 公式化的文章结构 | 严格遵循“引言-论点1-论点2-论点3-结论”的模板。 |
| 冗余的总结 | 在文章结尾反复用不同措辞总结相同的内容。 | |
| 词汇与短语 | 重复的过渡短语 | 频繁使用“总而言之”、“此外”、“值得注意的是”等。 |
| 通用、空洞的词汇 | 滥用“变革者”、“前所未有的”、“至关重要”等词语。 | |
| 语调与声音 | 过度的中立性 | 对有争议的话题采取绝对中立，缺乏明确立场。 |
| 缺乏个人声音 | 语调统一、平淡，听起来不像任何一个特定的人。 | |
| 内容与实质 | 缺少个人轶事 | 仅陈述事实和数据，没有个人故事或案例来支撑。 |
| 表面化的分析 | 解释“是什么”，但很少深入探讨“为什么”或“如何”。 |
生成式大模型的核心运作机制是基于统计概率预测下一个最可能出现的词或短语，而非真正的理解。这个过程天然地导向一种“向平均值回归”（regression to the mean）的趋势。因为模型旨在生成最“安全”、最“普遍”的输出，所以它会频繁地使用那些在训练语料库中统计上最常见的通用短语和陈词滥调 。它擅长的是复制，而非真正的原创 。
同时，因为缺乏人生活中接触的超越文本数据之外的共享语境数据，大模型的具身认知（embodied cognition）是缺失的，AI无法捕捉情感的细腻纹理和道德的复杂性，无法理解讽刺、反语或微妙的文化隐喻的原因就在于此。
大模型的架构和训练机制引发的“浅输入，浅输出”即奖励机制导致大模型追求平均和正确，也就是正确的废话，这也侧面说明了AI输出的质量与输入的质量、上下文深度直接相关 。一个笼统的提示词，如“写一篇关于人工智能的博客”，没有提供任何具体背景，迫使AI只能从其训练数据中最通用、最宽泛的部分提取信息 。
这样“AI味”的原理就清晰了：浅层输入导致AI调用通用模式，表现为刻板结构和通用短语，最终产出固定模式的文本也就是“AI味”。
宝玉老师推荐的怎么用大模型去掉“AI”味，本质上就是“让大模型主动露拙，模仿人的随机性”，具体prompt如下：
1. 用词与句式
- 70% 句子长度 < 18 词；偶尔插入 < 6 词的独立短句。
- 使用常见口语连接：and, but, so, anyway, you know.
- 每段至少包含一个具象细节（气味、手感、具体对象）。
2. 叙事与结构
- 采用第一人称或“我/我们”叙述，加入个人小片段（真实或拟真）。
- 不做完整封闭结论，最后一段留一点未决疑问。
3. 语用特征
- 保留一两处自我否定或转折（“其实…但回头想想…”）。
- 允许一两个轻微重复或改写，而不影响理解。
1. 技术采样参数（如需）
- temperature 0.9–1.1；top_p 0.9；top_k 40–60。
- frequency_penalty 0.3；presence_penalty 0.6。
以下是一些范文参考：
{text}
最后我把上面的思考内容喂给NotebookLM，让它给我一个关于“AI味”的Overview：
2025-08-31 22:21:10
工作当中的烦恼真的让人无力和恼怒，在做的一个CVE相关的AI项目，在误报阶段已经有60-70%的CVE可以被AI处理，准确率也达到了90%，接下来阶段就是对非误报的CVE进行安全风险评估，包括安全技术分析、攻击向量模拟、可利用性评估、修复难易评估、Patch修复、发布Errata，这里涉及到的数据、工作量极其繁杂，一个40+人的团队在投入但是人力上还是捉襟见肘。Leader决定拉起一个「数字员工」的项目，将AI引入全部的CVE处理流程，用来提升CVE处理的效率解决人力的问题。
我们作为安全团队，除了负责AI Infra的建设之外，要做的一个事情就是为CVE漏洞给出安全风险评估，包括安全技术性分析、攻击向量模拟甚至CVE利用的PoC等等，这里面涉及到很多安全数据和模型，发挥AI的能力是比较自然的思路，于是大家一致同意把这个纳入到上面提到的「数字员工」项目中。
公司将AI作为公司级别的战略，所以AI应用在公司内部属于百花齐放的阶段，跟创业类似的，周边团队在开发AI应用的时候碰到Agent幻觉等问题，导致在收益上比较微薄也就是常说的ROI不高，但也确实的减少了几乎一半的工作量。面对这种经验，Leader们泛起嘀咕——现阶段大力投入AI是不是会收益微薄甚至项目失败，不妨等技术成熟一点再加大投入。于是Leader在项目讨论会上，一直push我们要求给数据、给指标，一个没有跑起来的项目当然没有符合老板预期的数据和指标，甚至连数据打标点都还在设计中，可想而知项目的推进阻力会如何之大。
这期间还发生一个让我无言以对的事情，我的直系Leader问我「CVE这么多繁琐的流程，如果我跳过所有的前序步骤，来一个CVE我就用AI merge修复patch这样是不是也可以？」。面对一个企业级的操作系统产品，这个问题有很多角度来分析和论述：
面对革命性的技术浪潮，到底是想清楚再做还是先做然后调整呢？我的理念是「想都是问题，做才是答案」，同样都是付出成本与代价，与其在想这件事情上浪费人力物力，不如把成本放在做这件事情。想出一个 90 分的方案再去执行，相比一个 60 分的方案加后续再打磨完善，后者更能在过程过获得做事的成就感，形成一个输入和输出的正循环。
抛开理性分析，安全团队不是应该专注于自己领域的问题的研究和解决吗？把自己的Ego和Scope扩展到这么大，是不是太把自己当回事了，大厂这样的巨无霸面前不会真由基层员工来掌控方向的，都是螺丝钉就别给自己加戏了。大厂这样环境给人太多枷锁了，一直在被要求回答：我是谁，我在做什么，我为什么要做，为什么是我做，Blablabla……作为小团队的Leader没有这样清醒的意识，真的会「累死三军」
这篇文章没什么总结更没什么思考，只是感慨跟我类似的这些困在大厂里的「牛马」，慢慢的你会越来越清醒的意识到一个道理：“在大厂永远不会得到精神自由”！
2025-08-09 21:30:37
简单总结Vibe Coding：人利用AI生成代码完成大部分的软件开发任务。
我个人理解Vibe Coding的本质就是开发工作中的一种新的协作关系 —— 人专注于差异性工作，把能交给大模型做的工作尽量交给它去完成，充分发挥AI的可塑性、高效性等。
随着大模型底层基础能力的飞速迭代（例如Qwen3-Coder），AI的能力范畴正在变得越来越大，Vibe Coding的发展趋势就是自底向上蚕食程序员的工作范畴。
以Cursor和Claude Code为代表Vibe Coding工具正在快速迭代，Vibe Coding的架构是时刻在演进和变化，我根据自己的理解比较理想化给出Vibe Coding的分层架构，与上面发展趋势图相对应，Vibe Coding发展到最后就是这张图只剩下蓝色框框没有其他颜色🥳。
关于Vibe coding的八卦，一图胜千文，其实目的还是想让好奇AI Assistant Coding的人知道它的优缺点，以及需要注意的事项。
我总结了主流的几个AI Code Agent的架构：
综合来看，当下AI Code Agent的技术架构基本上都是类似的，主要的差异就是工具、策略等方面选择的差异。
以Cline架构为例对AI Code Agent架构进行管中窥豹
除了基础模型造成的差异之外，Cline建立的AI Coding的差异化竞争力主要在：
我们更进一步来拆解这些优势：
| 竞争力项目 | Cline | Cursor | RooCode |
|---|---|---|---|
| Human in the loop | ✅ | ✅ | ✅ |
| MCP生态支持 | ✅ | ✅ | ✅ |
| 工具生态 | AST | RAG | AST + RAG |
| 混合上下文管理 | Context Management | Automated Context Management + Context Priority Management | Intelligent Context Condensing |
| Agentic AI Model | ✅ | ✅ | ✅ |
| Model | ❌ | apply edit 小模型 | ❌ |
AI Code在卷哪些技术一目了然。
Vibe Coding 大致上有两种使用方法：
实践中，我发现方法1可以极大释放人力，有的时候AI给出的结果超出预期，唯一存在的问题就是人对于代码的信任度。方法2效率提升不如方法1，但是基本的代码实现以及项目进展情况人能够掌控，能够有效的避免AI Coding的几个问题：
基于上述经验，我对Vibe coding的采取的是不信任的态度，原子化任务保证我能够review检查代码（神仙也很难在2万行代码的PR里面准确挑出2-3个bug）。同时，如果是比较明确的任务并且已经有参考（例如已经有sqlite实现了，让AI完成mysql的实现）我就会采用方法1来提升效率。
另外，还有一种方式（我使用相对较少）—— 结对编程的方式，即向AI描述问题或者需求，然后AI规划方案，人来修改或者补充形成 todo list（plan），然后由AI实现。
最后，总结一下Vibe Coding的个人思考：想写一个demo直接扔给AI自动完成，当下的AI已经能够保证试错成本和效率了。想写一个生产使用的软件，自己把控方案设计和技术架构让Vibe coding作为帮助生成代码的工具，同时对Vibe coding始终抱着不信任的态度，时时review、处处检查。
由于每个人使用AI Code工具以及编程习惯都不一样，所以有一些关键原则是需要注意的，其他可以自由发挥。
<|im_start|>assistant<tool_call>{"name": "xxx"来控制工具调用的模式（自动、必需、指定等）；能够跨多个文件读取和修改代码的 AI。用自然语言描述更改，Agent 会执行这些更改。
定义 AI 行为的自定义指令。设置编码标准、框架偏好和项目特定约定。
持久存储项目上下文和过往对话中的决策。在未来的交互中自动引用。
对代码库进行语义分析。支持代码搜索、引用查找和上下文感知建议。
在代码生成过程中提供给 AI 模型的信息。包括文件、符号和对话历史。
Rule的设置是为了让Cursor了解项目结构以及开发约定，包括：
Rule编写时应该注意：
rules 结构示例如下图所示
另外一种Rule设置方法（来自Cline），Task Manager + Todo List的方式管理active context：
Task Manager的方式使用AI Code工具是比较进阶的使用方式，项目开发周期的缘故我还没生产实际中使用过，后续再研究和分享。目前这块有一些比较不错的实践经验可以参考：
我会在项目的docs目录中放置所有的项目相关的问题，包括技术选型、架构设计、模块说明、部署架构、使用手册等等，这样可以让人和AI都能够及时了解项目详细情况，一般修复问题或者新增feature的时候，我会将对应的文档添加到上下文中（@docs/xxx.md），帮着Agent能够更好的完成任务。
随着项目迭代和演进文档需要及时更新，不然会对AI形成误导导致无法正确地完成任务，所以我会形成固定的文档更新工作流。
