楼上两位说的都很有道理，不过我觉得最根本的还是拥抱变化！与其花大力气去预测和应对接口变更，不如设计一个足够灵活的 Skills，能够快速适应新的接口。比如，可以将接口请求的参数和处理逻辑进行模块化，方便替换和更新。当然，前提是你的代码架构要足够优秀。
这个问题问得好！我的理解是，Workflow 更适合那些流程固定、逻辑简单、对结果准确性要求极高的场景。比如，银行转账、订单处理等。在这些场景下，我们需要确保每一步都严格按照预定的流程执行，不允许出现任何偏差。而 Skills 更适合那些流程不确定、需要灵活应变、对结果容错率较高的场景。比如，内容创作、客户服务等。在这些场景下，我们需要根据实际情况调整策略，而不是一味地执行预设的流程。
如果公司安全策略实在太严格，无法使用 agent-browser，可以考虑使用 API 的方式获取数据。如果内网系统提供了 API，可以直接调用 API 获取数据。如果没有 API，可以与内网系统的开发人员沟通，让他们提供 API。当然，这需要一定的沟通成本。
Workflow 在流程非常固定、逻辑极其简单的场景下，可能更高效。如果每一步骤都明确，不需要太多 AI 介入，Workflow 的确定性反而是一种优势，能保证执行结果的稳定。比如：简单的审批流程，从A到B到C，每一步骤都明确，那workflow就足够了。
这确实是个难题。一个比较通用的方案是，在 agent-browser 前面再套一层代理服务，由代理服务来负责处理身份验证。代理服务可以对接企业的 IAM 系统，拿到用户的授权 token，然后再传递给 agent-browser。
这个思路让我想到了“可观测性”。本质上，就是把原本隐藏在系统内部的行为（例如接口调用、资源消耗）暴露出来，然后加以分析和利用。所以，我觉得只要是需要对系统行为进行分析和优化的领域，都可以借鉴这个思路。
从软件工程的角度来看，Workflow和Skills代表了两种不同的编程范式。Workflow更像是命令式编程，通过预先定义好的流程来执行任务。而Skills更像是声明式编程，通过描述任务的目标来实现。在选择时，需要考虑任务的复杂度和可变性。对于复杂且频繁变化的任务，Skills的优势更加明显。但对于简单且稳定的任务，Workflow的效率更高。
其实Markdown的优点还在于它的简洁性。相比于其他格式，Markdown的语法非常简单，学习成本很低。这使得更多的人可以参与到Skills的编写和维护中来。此外，Markdown格式的Skills也更容易被转化为其他格式。比如，可以将其转换为HTML格式进行展示，或者转换为JSON格式进行机器处理。这种灵活性使得Markdown格式的Skills具有更广泛的应用前景。
我觉得Copy as fetch这招简直是神器！除了文章里说的工单分析，在爬虫方面也能大显身手。很多网站的反爬机制会检测用户行为，直接用爬虫框架模拟点击很容易被 ban。但如果用Copy as fetch，就能直接拿到请求链接，相当于绕过了前端的重重校验，效率杠杠的！不过要注意别爬太狠，小心被请喝茶。
我更关注的是’监控’和’告警’。如果Skills在执行过程中出现错误，或者数据异常，应该及时发出告警，通知相关人员处理。 另外，可以记录Skills的执行日志，方便后续排查问题和优化性能。
维护成本我觉得要分情况看。如果Skills只是简单地调用几个API，那维护起来肯定比复杂的Workflow容易。但如果Skills涉及到复杂的逻辑判断和数据处理，那维护起来可能就需要专业的AI工程师了。 而且，Skills的’可持续进化’也可能带来维护负担。如果AI把Skills改坏了，或者引入了新的bug，那排查起来可能比传统的代码更困难。
我觉得作者说的有道理，但也有trade-off。Workflow确实不够灵活，但是胜在易于上手，可视化界面对非技术人员也很友好。 Skills这种’自然语言编排’的方式，虽然理论上更灵活，但对用户的提示词编写能力要求更高，相当于把一部分复杂度转移到了用户身上。 短期来看，Workflow可能更容易推广；但长期来看，Skills的可进化性更强，更有潜力。
与其说是学习成本，不如说是思维方式的转变。Workflow是’命令式’的，告诉计算机’怎么做’；Skills更像是’声明式’的，告诉计算机’要什么’。 习惯了Workflow的人，可能一开始会觉得Skills不太好理解。但一旦掌握了这种思维方式，就会发现Skills的威力。
歪个楼，有没有想过如果员工离职了，但是他之前Copy as fetch的脚本还留在Skills里，会不会有风险？万一有人不小心执行了这些脚本，还能拿到数据吗？ 从权限管理的角度看，应该建立一套完善的机制，定期审查和清理不再需要的Skills，以及撤销离职员工的相关权限。或者，可以考虑把这些脚本变成’一次性’的，执行完就失效。
我觉得这个方案最大的风险在于，如果攻击者能够入侵到用户的开发环境或者电脑，就有可能窃取到fetch请求的详细信息，包括headers，cookie等敏感信息，从而模拟用户发起恶意请求。 企业可以考虑对agent-browser eval的执行环境做隔离或者限制，只允许在特定的安全沙箱中运行。另外，定期审查和清理DevTools中的敏感数据也很重要。