由于汇报关系调整 我现在又回头做端到端研发D2C相关的工作。
这次主管给的课题是通过D2C解决低码搭建上用户写jsx的乱象。已经不是抽象了 是我根本不认可。但是毕竟是牛马 该做还是得做。
先说为什么不认可，
1.用户写jsx的原因是组件限制高文本需要格式化和数据组合。 那么小面积格式化使用jsx是最灵活的 而且jsx编写面板也配备了智能编码。 为什么要单独变成npm包才行呢？它也不复用呀。
2.业务组件npm是by站点引入的，原本只有一个页面单次使用的格式化 变成组件资源后 所有页面都要引入，影响性能（公司历史 低码物料是应用维度按需引用非页面）
3. 这些老页面的jsx 页面跑的好好的 改它干啥。作为中台为什么要卷业务开发这些没有价值的事情。
最后 问题归问题，活该做还是得做。 因为为什么做这个事情 本身不影响我对这个事情的研究。无端给我一个研究的理由也挺好的。
另外在B端系统 我认为组件的收敛和规范化还是很重要的不应该那么随意。真正解决问题的应该是设计开放型组件 在样式风格尺寸上有约束 剩下的交给ai。否则页面看起来可能就百花齐放了。对于C端页面还好 而B端严谨的页面确不太合适了。
再者 业务组件如此灵活自由 那么一个页面做一个组件的乱象也不远了。

最近和算法沟通了几次，并实际写了些代码后后我的想法有所变化：
其实又变得有点杂乱了。
1. 页面可做mvp 这个观点依然没有变化。但是应该是结合到个人agent上 ，无开发者参与的场景。
2. 低码schema强化浏览器操作。这点有点不看好了。 我们找到了另一条路，通过强化训练browser use 操作记录来增强操作准确性。
2.1 训练任务和操作流程的组织
2.2 训练 dom结构和指令以及指令action参数的关联度 强化单步操作的准确性。
目前先等等看算法同学的训练效果吧。
------
其实思路还是借鉴了rpa ，rpa是固化的操作流。只是换成了大模型的训练结果去记忆这部分流程。

昨天在公司ai专项会上演示了一下低码页面做mcp 的demo。 收获了几个项目组的合作意向。demo 只包含4个功能
1.登录
2. 从标准表格查询页面取数
3. 给标准表单页填数
4. 判断页面是那种类型的低码页面。
我判断为什么大家喜欢这个。 现在大家用接口转mcp普遍遇到几个卡点
1. 历史接口直接转会遇到登录 权限等问题，新接口开发又没那么多人投入这种不确定性的项目。
2. 重新开发业务能力mcp难以实现短期规模化使用AI。所以短期内这种不需要业务团队付出成本的策略最受欢迎。
3.页面本身包含了复杂的业务逻辑 不仅仅是一个接口。
4. 大家现在对应用的认知也是来自页面，不会直接理解数据表。
----
同时会后交流获得了一个更好的启发：
我可以用之前做过的一个能力： 将多个表格页面的过滤条件暂存并在dashboard一起直出的能力。
将这个能力改造成mcp factory 然后做用户自己查询偏好的查询数据mcp。
下一步试试。 这个过程初步yy 是可行的

mcp和open API以及传统http的一些思考：
1. agent client相当于过去的前端开发。消费的接口使用mcp。 就像过去我们用个axois连接请求一样。这个就是mcp client transport。
2. 传统接口分为应用内部接口 和公开openapi。同理mcp也是一样，也分为公共通用mcp和Agent 私有mcp。
3.私有mcp 核心是为Agent量身定制。
4.所以企业内的mcp市场是需要瑧别哪些是适合公开的，哪些是私有的。私有也分为Agent私有和业务线私有。设计公开mcp应该以设计openapi的严谨度来设计。

讲道理 ai下的低码组件真的class类组件是对AI最友好的。 属性和方法，对AI理解和使用组件最友好的。
包括运行态AI可以直接操作组件，而不是dom。

#关于前端页面“MCP”
1.今天实现了输入页面url 返回页面操作指引。使用低码shcema有点小惊喜。比起dom和截图 schema解读出来了隐藏在弹窗内的功能。并且能告知具体的操作路径。
2.同时登录逻辑都是贴着公司几种固定登录态搞的，又可以多账号托管，登录过程不需要调用AI，又省了不少token。
3. 既然ai能够识别页面功能。如果换个思路，我的toolsList要是可以根据我的页面功能动态生成呢，效果会如何？ 还是说我用一个通用tool Function？

主管给了个抽象的命题： 将公司的低码页面MCP化。
原因是高层大佬说大家尽快将公司的现有数据、服务接口、页面MCP化。方便数字员工Agent建设。作为前端的我收到的命题就是应用页面MCP化。这真的好抽象(´･_･`)。
想了挺久终于有些思路了。陆陆续续记录一下。
1. 其实大佬关心的是Agent如何精确操作页面。类似manus中使用browser use那样。
2. 只是提供一个MCP并不能有什么实际价值。browser-use-mcp 就能做到，虽然token消耗巨大 成功率也比较低。所以核心价值应该是在预设进企业级应用的规律，大幅度减少token，同时因为有既定的规律 可以大幅提升操作精准度。非标页面保持browser-use的方式。 事实上这继承了当初页面即服务的思路。以应用页面为工作单元进行拆解任务。
3. 对比一下RPA，相当于rpa是预先设定好流程 重复播放。而如果是数字员工 那就是预设好节点，但执行流程由Agent自规划。
4. 其实这已经不是纯粹的MCP了，不过概念什么的没那么重要。我需要验证一些我的思路设计。让组里的同学做Agent client端 我也期望能是一个Agent Factory。 按照某种方式组合作技能和MCP 能够生成不同的Agent。
...
还有好多思路，需要持续不断的验证并慢慢记录

来到即刻的第一天。