结论：信息化、数字化仍是智能化的基础，但部分旧系统、旧流程正在成为包袱。 个人认为 AI离不开数据、接口、权限和业务规则，这些都来自前两者；没有它们，智能化只能停留在演示。但如果数字化只是把低效流程搬到线上、制造数据孤岛、让人围着系统转，AI只会放大低效。 真正该淘汰的不是数字化，而是“固化流程、堆叠系统”的旧数字化。未来需要的是开放、实时、可调用的数字底座。

哪个项目不是这样的？难道还有demo一般般上线很惊艳的项目？

如果预算只够认真做一层，我会优先补检查点与失败接管这一层。原因是：线上“模型变强但成功率不动”，往往不是推理能力不够，而是失败后无法收敛与恢复（超时、工具副作用、状态丢失导致反复重试）。有了检查点与可恢复状态，Agent 才能在预算耗尽、工具失败、异常注入时降级退出、回滚或续跑；这直接提升稳定性与可用性。权限清单与评测隔离也重要，但它们通常是“优化与治理”，而检查点/失败接管是“生存底座”。

说说个人愚见。题目是：中国 To B 交付，现在有了 FDE 加上 AI，到底有没有机会解开？ 这里有几个关键字，中国 to B。好了我们就定语部分进行展开。要知道中国 to B。这和to B不一样。 就像足球和中国足球的区别一样。 FDE在有了成功案例，是客观事实。但是那是在美国。同样我们看微软、甲骨文。一个操作系统，一个数据库。都是美国赚钱的公司。 你再看看中国的操作系统和数据库公司。操作系统的公司是不是赚钱了我没数据。反正巅峰时候中国300多家数据库公司就3家盈利。而且现在健在的都不要巅峰时候一半了。 余窃以为这和文化等诸多因素有关。在欧美高度认同人的服务和知识产权。别说是商用产品，你就是用开源产品，找人服务同样有意愿付费。 而我国是用Oracle都不给钱的，用开源还付费？小兵张嘎中的台词：老子在城里下馆子都不给钱，吃你几个西瓜还要钱？ 你和领导汇报开源不等于免费，这个是可以得到认可的。但是说买个服务？领导也会说开源也不意味着就一定要花钱嘛。 当你会一个开发语言和会5个开发语言薪酬是5倍关系吗？掌握一个技术栈和10个技术栈薪酬是线性关系吗？ 好了基于以上的描述有没有异议？如果没有，那么我们看。 FDE这种在中国 toB能不能走通？可能极少数可以（毕竟国内还是有尊重人和知识的） 还有一点就是虽然基本上大家都不是技术驱动的公司，但是技术人不是别人的附属。先做到对技术人平等对待，才可能解决。 达到了一定条件，FDE是真的可以解决中国的 to B问题。

ENAMETOOLONG 在 Windows 上基本就是 CreateProcess 的环境块超了 32767 字符上限。WorkBuddy 把所有 connector 配置序列化成 CODEBUDDY_MCP_CONFIG 塞进环境变量，几十个连接器加起来轻松破 36KB，CRON 走显式传环境块的路径直接撞墙。交互式 shell 能跑是因为走继承父进程环境，不校验这个限制。临时方案：精简 mcp.json，把不用的 connector 配置删掉，降到 32KB 以下就行。治本得靠 WorkBuddy 改环境注入方式，别把整个配置塞环境变量，用临时文件或管道传更靠谱。

按精力来分配。

说实话，靠挤时间很难持续，关键是把学习和日常工作绑定起来。遇到新框架别急着看文档，直接拿它写个真实的小工具，哪怕就是个内部脚本。踩坑的过程比刷教程有效十倍。另外别贪多，一年深入一个方向比浅尝辄止五个方向有用得多。碎片时间看技术趋势够了，但真正的深度学习需要整块时间，建议每周固定留两小时，像守会议一样守住这个时段。最重要的一点：学的东西要能用上，用不上的技术很快就忘，不如不学。

生产级 Agent 运行时中将 Harness 拆分为“路由层（Router）+ 多策略执行器（Executor）”的目的，是把自由 think-act-observe 循环里容易失控的不确定性（如停止时机、策略切换、降级回退、安全触发、成本与时延）通过路由层前置“控制面”而钉住；路由层根据请求特征与风险信号先决定使用哪种执行器，并下发停止/预算、工具与权限边界、合规安全规则以及输出结构合同，使执行器在固定策略下完成任务并输出可验证结果。若不拆合并在一层，线上最先暴露的往往是控制失效类故障，例如预算或停止条件失控导致成本与延迟爆炸、工具滥用/权限越界、合规与拒答策略不一致引发概率性事故，以及由于缺乏分层决策记录而造成可观测性与可复现性下降；因此当意图不适合自由循环、证据链不足、预算接近阈值、安全风险升高或历史轨迹显示发散时，应由路由层将其降级为确定策略而非继续自由循环。

蓝屏基本是驱动冲突或内核级问题，应用层软件很少直接触发 BSOD。WorkBuddy 基于 Electron，如果安装后蓝屏，大概率是自带的某个系统级组件和现有驱动打架——比如 GPU 硬件加速触发显卡驱动崩溃，或者安全模块和杀毒软件内核驱动冲突。排查步骤：先开机进安全模式，如果能正常启动就基本确认是驱动问题。禁用 GPU 硬件加速试试，命令行加 --disable-gpu 启动。另外看下蓝屏 dump 文件，用 WinDbg 分析哪个驱动抛的异常，能精确定位。如果是企业版杀毒软件拦截，加白名单试试。

从技术视角看，智慧军营本质上是一个超大规模的边缘计算加物联网集成项目。感知层是各类传感器、摄像头、门禁、定位设备；平台层需要一个统一数据中台把所有子系统打通，难点不在技术选型而在数据孤岛——军营里安防、后勤、训练各用各的系统，接口都不统一。应用层倒是好做，关键是底层数据治理。架构上建议走边缘预处理加中心聚合模式，敏感数据在营区内闭环处理，只把汇总数据上报，既满足安全合规又降低带宽压力。核心不是堆设备，是打通数据流。

最终方案：A + C，不要 B 结论已经定了：按模型物理隔离 + 网关路由，短请求水平扩展，长序列单独部署 + 队列削峰。不做统一集群 + 优先级抢占。 为什么这么定： 短请求会被长序列拖住 —— 会。长序列 decode 占着批槽位，短请求排队进不来，p99 就崩。所以必须隔离，同一个队列里靠调度救不回来。 KV 会被挤爆 —— 会。7B 和 70B 的 KV 占用差一个数量级，共池必然挤压。各自独立实例、独立 KV 池、各自 max_seq_len，谁也不碰谁。 优先级抢占会饿死长序列 —— 会。抢占一次就丢 KV、重新 prefill，短请求一直来，长序列永远做不完。这条路直接否决。 prefix cache 跨模型不值 —— KV 是模型特定的，跨模型不通用，只在同模型内复用才划算。 落地分工： 网关：按负载类型路由，各自独立队列、独立背压。 7B：水平扩展，浅队列快速失败，收紧序列长度，保 p99。 70B：单独部署，深队列削峰，大批量 + 长序列，保吞吐。 前缀缓存：只在同模型内做，不跨模型。 一句话收尾：隔离 + 各自调参，别抢占。

没有吧，只要是真实实践、有技术干货和个人思考，原则上都是可以发布的。如果文章多次被驳回，建议重点看一下是否存在以下情况： 1️、文章主要是产品介绍/功能罗列，技术实践和个人观点比较少； 2️、对比内容偏“产品宣传/推荐”，技术分析不够深入； 3️、内容中包含较多推广、引流信息； 4️、原创度或内容质量不足，比如大量引用产品官方资料； 5️、标题或内容存在比较明显的夸大、贬低或不够客观的表述。

健康有益自研、完成国家网信办算法备案的HealthHope健康垂类大模型，深度赋能HealthAuto智慧健康座舱。区别于通用大模型，该大模型沉淀千万级权威健康数据与循证医学标准，搭建四维动态知识网络，在多领域实现落地应用。 1）语音识别交互层面：打造随车健康顾问，支持语音、文字双模式健康问答，完成指标解读、慢病咨询、应急健康指导，适配车内嘈杂的行车环境，拓展车机语音的健康服务能力。 2）个性化服务层面：结合用户健康档案、行车过程采集的健康数据，推送定制化健康课程、起居打卡任务；依托人车家生态，根据车内健康状态生成居家干预任务，联动家居设备模式，实现千人千面的跨场景服务。 3）健康管理层面：对摄像头、雷达、可穿戴设备、体检报告等多源异构健康数据做融合解析；输出健康评分、健康风险预测、异常指标解析；生成膳食营养、运动、就医建议等个性化方案；针对晕厥、路怒、晕车等高风险场景分级研判，输出科学合规、可追溯的健康评估结果。 同时该大模型底座具备良好设备兼容能力，可以对接各类车载终端，适配不同车型快速落地。

对程序员来说远程办公其实天然适配，代码协作本来就是异步的，Git、PR、Issue 这些工具链不依赖物理位置。真正的问题不在模式本身，在于团队有没有建立起异步沟通的纪律。远程最怕的是既不同步也不异步——开会讨论不到位，文档又懒得写，最后只能靠即时消息碎片化沟通。能做好远程的团队，异步文档能力通常比坐班团队强一截。建议把每日站会改成文字同步，决策都留文档痕迹，每周保留一次视频同步拉齐方向就够了。

Harness 负责“执行过程的正确性与可验证性”：在相同输入/上下文下，Agent 如何被驱动、如何被约束、如何被评估，以及失败时如何回滚/重试/降级。 Infra 负责“运行所需能力与资源的稳定交付”：模型/工具/检索/存储/队列/并发/网关/权限/审计/观测等基础能力如何提供、如何扩容、如何隔离。 Harness（控制面 / 运行护栏）通常包括： 流程管控：状态机/编排（step、guard、fallback、max iterations、停止条件） 并发与调度策略：面向单次 Agent 运行的 SLA/策略，如并发策略、超时/重试/降级规则 独立验证与评估闭环：对产物进行校验（rule-based / rubric / 反向采样 / 自检代理 / E2E eval）以及验证失败后的处理 安全与合规护栏：工具调用白名单、输出格式约束、PII 处理、越权拦截、审计与告警策略（“何时审计、审计什么、判定规则”偏 Harness；落盘可能在 Infra） 可回放、可追责的运行轨迹：用于复盘与回归测试（依赖 Infra 的日志系统，但由 Harness 决定记录策略与最小必要上下文） 关键点：Harness 关注“这次运行是否按预期完成、是否被验证过、失败时如何兜底”。 Agentic Infra（数据面 / 能力底座）通常包括： 模型与推理网关：多模型路由、灰度、限流、成本控制、超时与熔断（可替换的基础能力） 工具执行与运行环境：沙箱、函数调用服务、浏览器/代码执行运行时、密钥管理与权限体系（工具“怎么跑”） 外化记忆/检索/向量库/数据访问层：检索策略支持、embedding 服务、权限过滤、索引更新机制 基础调度与资源隔离：队列、worker、租户隔离、可扩展性、缓存、幂等等（“怎么规模化地跑起来”） 通用观测与审计存储：日志/指标/链路追踪/告警平台（Infra 提供；Harness 决定采哪些与如何触发）

现在来看 FDE 就像一个外包驻场到客户的全栈工程师，大多数甲方不想花太多钱来弄一个这样的存在，更或者说现在编制名额有限

我也是技术爱好者之一，说实话，我自己的技术成长路径就是靠人脉打开的。刚入行时跟着前辈学，中间阶段靠同行交流拓宽视野，现在很多机会也是从圈子里来的。技术是敲门砖，但人脉是帮你把门推开的那双手。

CodeBuddy 默认对命令执行有确认机制，想全自动跑的话在设置里找权限相关的选项。路径大概是 Settings -> Tools -> Permissions，把 Auto-approve 或类似选项打开，可以选择全部自动批准或只批准特定命令。注意全开有风险，如果 AI 生成了 rm -rf 或者 git push --force 之类的命令也会直接执行。建议只对读类命令（ls、cat、grep）和项目内的构建命令开放自动批准，写操作和危险命令还是保留确认。如果设置里找不到，试试在 .codebuddy 配置文件里加 permissions 规则。

我之前写过一篇，我作为过来人还是有很多感受，https://cloud.tencent.com/developer/article/2611857

派你的猫猫出去旅行每次可获得少量积分