上周AWS有个更新值得关注——不是新Instance类型发布也不是哪个Region扩容了而是一个看着不大的改动Lambda控制台加了一个一键复制Agent提示词的按钮。这玩意怎么说呢 不是那种会出现在头条上的功能但对天天跟AI编程工具打交道的开发者来说可能比一个新技术发布更实用。一个按钮解决的实际问题过去半年用AI编程Agent写Lambda函数的人越来越多了。Claude Code、Cursor、GitHub Copilot、Codex——市面上主流的AI编程工具都在往这个方向走。但一直有个烦人的问题每个工具需要的配置都不一样MCP Server地址、权限配置、函数模板你得一个一个去查文档。翻了下AWS的官方说明他们这次做了三件事第一写了一个标准化的Agent配置提示词。直接复制、粘贴到你的AI编程工具里工具就知道怎么调用Lambda的API了。第二集成了Serverless MCP Server。这意味着Agent可以直接读取你的Lambda函数列表、查看代码、甚至执行部署操作——不需要你自己写那些胶水代码。第三发布了Agent Toolkit for AWS。这东西更直接给你的AI工具一个当前AWS知识库的接口——不只是Lambda是整个AWS服务的操作指南。说实话从实际使用来看最有用的是第一条。以前配置一个AI编程Agent来操作Lambda至少需要翻三篇文档、写十几行配置文件。现在复制一段提示词就行。GPT-5.6来了 Bedrock第一时间接入AWS同期的另一个动作是OpenAI GPT-5.6系列已经可以在Amazon Bedrock上直接用了。这里容易被忽略的是Bedrock接入GPT-5.6的方式跟直接在OpenAI调用不太一样。在Bedrock上你可以直接跟VPC内的其他AWS服务打通——Lambda、S3、DynamoDB——API调用不走公网延迟更低安全审计也更方便。一个具体的场景你用AI编程Agent写了一个Lambda函数这个函数调用了GPT-5.6来做内容分类。整个链路——Agent写代码、代码部署到Lambda、Lambda调用Bedrock上的GPT-5.6——全部在AWS内部完成不需要申请额外的API Key也不用担心网络延迟。看到这里的时候愣了几秒这其实是一个挺大的变化。以前你要把AI能力集成到自己的应用里需要单独管理OpenAI的API Key、配额、计费。Bedrock接入后这些全走AWS的IAM和账单体系。工具链在变 开发者的工作方式也在变但从另一个角度看这些变化也带来了一些新问题。Agent Toolkit虽然方便但它给AI工具的权限怎么控制如果你的Claude Code或者Cursor有了直接操作Lambda的能力一个写错的提示词可能导致函数配置被改、权限被提升、甚至资源被删除。AWS在安全方面倒是做了设计——Agent Toolkit默认遵循IAM最小权限原则Agent只能操作用户已授权的资源。但实际操作中很多开发者为了方便会给Agent分配一个比较宽松的角色。真正麻烦的是后面日志审计能不能跟上权限变更能不能追溯这些在Agent驱动的开发流程中还不是特别清晰。另一个值得关注的是当AI工具变成了基础设施操作的一部分传统的开发-测试-部署的分界线开始模糊了。以前写代码是写代码部署是部署。现在Agent可能在你写代码的中间顺手就做了部署——为了验证一个函数的返回格式。这种边界的模糊在快速迭代时是好事但在生产环境中就值得谨慎了。上周我跟一个在用Amazon Q Developer做Serverless开发的朋友聊了聊。他说了一个很有意思的情况Agent生成的Lambda函数代码质量不错但每次部署后CloudWatch日志里总会多出一些奇怪的调试信息——Agent测试时印上去的忘了清理。这种事不大但在生产环境里看着就很别扭。不是大问题但反映了Agent生成代码时收尾环节的缺失。对普通开发者来说这个变化其实意味着你不需要记住Lambda的所有参数和配置选项了但你需要理解你的Agent在做什么、以及为什么这么做。信任但验证——这个软件工程的老原则在AI时代反而变得更重要了。但换个角度看AWS这次的一键配置还有另一个重要的信号——AWS认为AI编程工具已经足够成熟值得为它们专门优化开发体验。两年前你绝对看不到AWS为一个AI工具的配置问题出补丁。这说明在AWS眼里Agent驱动的开发方式已经不是可能未来会火而是已经在发生了。那问题来了这种趋势下传统DevOps工程师的角色会不会被重新定义目前看来还不太会——AI能写代码能部署但出了问题还是得人来看。不过可以确定的是熟练掌握AI工具配置和调试的能力正在变成一种新的职业门槛。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
上周AWS有个更新值得关注——不是新Instance类型发布也不是哪个Region扩容了而是一个看着不大的改动Lambda控制台加了一个一键复制Agent提示词的按钮。这玩意怎么说呢 不是那种会出现在头条上的功能但对天天跟AI编程工具打交道的开发者来说可能比一个新技术发布更实用。一个按钮解决的实际问题过去半年用AI编程Agent写Lambda函数的人越来越多了。Claude Code、Cursor、GitHub Copilot、Codex——市面上主流的AI编程工具都在往这个方向走。但一直有个烦人的问题每个工具需要的配置都不一样MCP Server地址、权限配置、函数模板你得一个一个去查文档。翻了下AWS的官方说明他们这次做了三件事第一写了一个标准化的Agent配置提示词。直接复制、粘贴到你的AI编程工具里工具就知道怎么调用Lambda的API了。第二集成了Serverless MCP Server。这意味着Agent可以直接读取你的Lambda函数列表、查看代码、甚至执行部署操作——不需要你自己写那些胶水代码。第三发布了Agent Toolkit for AWS。这东西更直接给你的AI工具一个当前AWS知识库的接口——不只是Lambda是整个AWS服务的操作指南。说实话从实际使用来看最有用的是第一条。以前配置一个AI编程Agent来操作Lambda至少需要翻三篇文档、写十几行配置文件。现在复制一段提示词就行。GPT-5.6来了 Bedrock第一时间接入AWS同期的另一个动作是OpenAI GPT-5.6系列已经可以在Amazon Bedrock上直接用了。这里容易被忽略的是Bedrock接入GPT-5.6的方式跟直接在OpenAI调用不太一样。在Bedrock上你可以直接跟VPC内的其他AWS服务打通——Lambda、S3、DynamoDB——API调用不走公网延迟更低安全审计也更方便。一个具体的场景你用AI编程Agent写了一个Lambda函数这个函数调用了GPT-5.6来做内容分类。整个链路——Agent写代码、代码部署到Lambda、Lambda调用Bedrock上的GPT-5.6——全部在AWS内部完成不需要申请额外的API Key也不用担心网络延迟。看到这里的时候愣了几秒这其实是一个挺大的变化。以前你要把AI能力集成到自己的应用里需要单独管理OpenAI的API Key、配额、计费。Bedrock接入后这些全走AWS的IAM和账单体系。工具链在变 开发者的工作方式也在变但从另一个角度看这些变化也带来了一些新问题。Agent Toolkit虽然方便但它给AI工具的权限怎么控制如果你的Claude Code或者Cursor有了直接操作Lambda的能力一个写错的提示词可能导致函数配置被改、权限被提升、甚至资源被删除。AWS在安全方面倒是做了设计——Agent Toolkit默认遵循IAM最小权限原则Agent只能操作用户已授权的资源。但实际操作中很多开发者为了方便会给Agent分配一个比较宽松的角色。真正麻烦的是后面日志审计能不能跟上权限变更能不能追溯这些在Agent驱动的开发流程中还不是特别清晰。另一个值得关注的是当AI工具变成了基础设施操作的一部分传统的开发-测试-部署的分界线开始模糊了。以前写代码是写代码部署是部署。现在Agent可能在你写代码的中间顺手就做了部署——为了验证一个函数的返回格式。这种边界的模糊在快速迭代时是好事但在生产环境中就值得谨慎了。上周我跟一个在用Amazon Q Developer做Serverless开发的朋友聊了聊。他说了一个很有意思的情况Agent生成的Lambda函数代码质量不错但每次部署后CloudWatch日志里总会多出一些奇怪的调试信息——Agent测试时印上去的忘了清理。这种事不大但在生产环境里看着就很别扭。不是大问题但反映了Agent生成代码时收尾环节的缺失。对普通开发者来说这个变化其实意味着你不需要记住Lambda的所有参数和配置选项了但你需要理解你的Agent在做什么、以及为什么这么做。信任但验证——这个软件工程的老原则在AI时代反而变得更重要了。但换个角度看AWS这次的一键配置还有另一个重要的信号——AWS认为AI编程工具已经足够成熟值得为它们专门优化开发体验。两年前你绝对看不到AWS为一个AI工具的配置问题出补丁。这说明在AWS眼里Agent驱动的开发方式已经不是可能未来会火而是已经在发生了。那问题来了这种趋势下传统DevOps工程师的角色会不会被重新定义目前看来还不太会——AI能写代码能部署但出了问题还是得人来看。不过可以确定的是熟练掌握AI工具配置和调试的能力正在变成一种新的职业门槛。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
![[具身智能-600]：人眼每秒感知多少帧：人眼分辨明暗闪烁的极限频率](http://pic.xiahunao.cn/yaotu/[具身智能-600]：人眼每秒感知多少帧：人眼分辨明暗闪烁的极限频率)
