之所以将代码编辑器从vscode切换为trae，是因为最近vscode越来越卡，经过一番搜索之后，得知是微软在后台启动了一个报告进程，这个常驻进程会消耗大量的内存和计算资源，虽然可以关掉，但是copilot以及很多扩展无法拒绝，即使勉强使用，还是会越来越卡。而且vscode用国内的编程助手（我用的灵码），会在后台启进程，在活动查看器发现开销非常大，也是拖慢编辑器的原因之一。而现在的trae性能非常好，它自带了AI Agent，可以连MCP，不需要额外挂扩展，因此节省额外的开销，所以，现在赶紧用起来性能就非常好。当然，后续它会不会像剪映一样搞收费，或者功能越加越多也变慢，这个先不管咯，等到那时，在物色一个新编辑器就好了。
即使强如google，也在Safari的视频播放上折戟沉沙
前几天我写了《Safari中无法播放视频，“Failed to load resource: 插件处理的载入” 或 “尝试载入资源时发生错误。”》一文，本来是记录自己在开发过程中遇到的问题和解决过程。然而，今天我在访问gemini特设的veo3页面时，发现视频也都无法播放。在访问replicate的详情页，也遇到了相同问题。没想到，就连google、replicate这样的大公司，竟然也都不在safari上做测试。
右侧这个视频无法播放的界面，是safari标志性的“侮辱”信号。
在上一篇文章中，其实我已经详细阐述了造成这个问题的原因，是safari特殊的视频资源读取逻辑。它严格按照Range Request的模式来请求视频资源，而且同时，它会在第一个请求时读取0-1 bytes来得到完整长度，而且立马丢掉（请求呈红色），然后再重新计算后严格按照Range Request来读取视频的buffer进行播放。
基于Range来读取视频数据虽然理想丰满，但是现实骨感。我打开网络面板，找到了卡住的Range请求，如下：
在这一个请求中，后端要返回14.2M的数据包，这……也太坑了吧，既然你都用Range请求了，为啥不请求一个只有1M的Range呢？而Range包的大小，则是由浏览器（也就是safari）发出的Range请求头决定的，后端也无法决定。
因此，最后其实不是google工程师没有考虑到，而是safari坑。
随后，我将默认浏览器切换成了chrome。
我的mackbook pro是2017年底去香港苹果店买的，到今天已经用了8年了，时间如此之快，恍如昨天。虽然是2017年的电脑，但是现在用来还是很正常，不会有太多的卡顿。不足之处有两点，一是intel的芯片拖后腿，比起现在的M芯片，不仅耗电厉害，而且由于时代久远，稍微跑一点吃计算的程序就风扇呼呼响，开始卡；二是电池，得一直插着电源。我还是很喜欢这台笔记本的，不过电池问题一直是给心头结，没法带着电脑出去装X，有点失望。在纠结很久之后，终于在网上下单了一组电池，今早自己动手给换了，虽然有点笨手笨脚，但是靠着狗屎运没有出一点岔子，现在已经非常愉快的丢开电源用了，内心还是挺喜悦的。芯片没法改，就不计较了，毕竟我现在一直在mini上工作，这台电脑就是偶尔应急或者手持来装的，感觉还能再战10年。
“什么是Agent”的终极解释
2025年的今天，我们终于可以给出Agent的终极定义，即“智能化自动化的应用程序或服务”。
首先，Agent是应用或服务，而非AI。虽然，我们现在默认AI是驱动Agent的基础，但是，Agent不只意味着AI，那些对AI（特别是LLM）简单套壳的应用不是Agent。Agent本身依赖AI，但不必须依赖特定AI，AI只是它的一个组件，且可以随时切换为更高智能的AI。Agent本质上是应用，就像Java程序以来数据库服务一样，Agent依赖AI，但不参与AI本身的开发。
其次，Agent具有自主性，即无需人工干预自主实现目标。与以往应用程序需要程序员撰写精确逻辑的代码不同，Agent应用中，程序员不实现业务逻辑本身，而是实现逻辑的调度，通过这个调度让程序自动选择业务逻辑节点去执行，如果在Agent框架的加持下，程序员甚至不需要实现这个调度，而只需要实现业务逻辑的节点，应用启动后，每个业务节点在什么时候被执行，完全是由Agent根据用户的输入和当前的状态来决定。
最后，Agent具有单一通识能力，即一个Agent就可以帮用户解决所有问题，包括不同专业领域、不同业务场景、不同目标需求。比如，用户既可以让Agent为自己下一个外卖单（生活场景），也可以让它帮自己完成数据统计（工作场景）。虽然目前来说，市面上的Agent大部分还是倾向于专业能力，例如cursor专注于编程，但是这主要是发展程度不够决定的，未来，cursor这样的工具一定会被淘汰。
