标签：#Python

Imagine waking up to a notification on your phone: "Your blood sugar levels are dipping. I've already analyzed your recent CGM (Continuous Glucose Monitor) trends and added low-GI complex carbs to your grocery cart." 🚀 This isn't science fiction anymore. With the rise of Autonomous Agents and specialized libraries like Browser-use , we can now bridge the gap between health data analysis and real-world actions. In this tutorial, we are building a personalized Nutritionist Agent that monitors health metrics and navigates the web just like a human to fulfill your dietary needs. By leveraging LangChain for logic and Browser-use for web automation, we’re moving beyond simple chatbots to "Action-Oriented AI." 🏗 The Architecture: From Insight to Action The workflow involves three main layers: the Data Input (CGM reports), the Brain (LangChain Agent), and the Hands (Browser-use + Playwright/Selenium). graph TD A[CGM Sensor Data] -->|GraphQL/JSON| B(LangChain Agent) B -->|Analyze Risk| C{Hypoglycemia Detected?} C -->|Yes| D[Identify Low-GI Foods] D -->|Navigate Browser| E[Browser-use Controller] E -->|Automate Shopping| F[Fresh Grocery Site] F -->|Action| G[Add to Cart & Notify User] C -->|No| H[Continue Monitoring] 🛠 Prerequisites To follow along, you’ll need a Python environment and the following stack: LangChain : For orchestrating the LLM logic. Browser-use : The star of the show for AI-driven browser navigation. Playwright/Selenium : To handle the underlying browser instance. OpenAI/Anthropic API : To power the reasoning engine. Step 1: Analyzing the Health Data First, we need to process the CGM (Continuous Glucose Monitor) data. We'll use GraphQL to fetch the latest metrics and LangChain to determine if the user needs a nutritional intervention. import os from langchain_openai import ChatOpenAI from langchain.prompts import PromptTemplate # Mocking a CGM Data Fetcher via GraphQL logic def fetch_cgm_metrics (): # In a real scenario, use a GraphQL client to query your he

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 7, I closed on a line worth expanding: "I built an agent" vs "I built an agent I can actually operate." The difference between those two sentences is the sixth and final component of the harness. It's called Observability , and without it, everything else you've read in this series is a bet you can't check. Every previous component in this series does something the agent needs to work. Observability does something the engineer needs — to see what happened, to know when things are going wrong, and to have any hope of making the harness better over time. What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Part 5: Context Engineering Part 6: The Filesystem & Environment Part 7: The Memory Layer Observability ← You are here Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what Observability actually is, why non-deterministic multi-step systems can't be operated without it, and the three properties — full-fidelity logs, session-level traces, and fixed evals — that separate a real observability setup from an aspirational one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. Wh

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 6, we closed on a limitation the previous four components can't solve on their own: the agent forgets. Once a session ends — or the context window fills up mid-task — everything the agent learned, discovered, or decided vanishes. Next time the user comes back, the agent greets them like a stranger. Next time the token budget runs out, earlier turns get truncated away, and the agent's earlier reasoning is just gone. That's the gap this article closes. The Memory Layer is how the harness gives the agent persistence — inside a task, and across sessions. What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Part 5: Context Engineering Part 6: The Filesystem & Environment The Memory Layer ← You are here Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what a Memory Layer actually is, why short-term and long-term memory are two different systems (not one with a dial), and the three design decisions — flavor, write triggers, and bounded retrieval — that separate a real memory system from a naive one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. What The

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 5, we looked at the Context — the payload the model sees on every call. Now we look at what happens after the model, having seen that Context, decides to do something. The model calls a tool. The tool has to execute somewhere. That somewhere is the Environment . It's easy to under-appreciate. The Environment feels like plumbing — the filesystem, the shell, the network, the machine underneath. But it's where every side effect the model requests actually lands, and how you design it is what separates "an AI agent doing things on your behalf" from scary to routine . What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Part 5: Context Engineering The Filesystem & Environment ← You are here Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what the Environment actually is, why every tool with side effects depends on it, and the three properties (bounded, reproducible, inspectable) that separate a production-ready environment from a demo one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. What The Environment Is The Environment is

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 4, we looked at the Tools — the set of functions the model can call. But there's still one big open question hanging over every turn of the Loop: what does the model actually see when the Loop calls it? The answer is: whatever the harness put in the payload. That payload — the entire package of instructions, history, retrieved documents, tool definitions, and everything else — is called the Context . Some readers know this territory under an older name: prompt engineering . That name isn't wrong, but it's narrow. A prompt sounds like something you write once and ship. The reality of running an agent is that the payload changes every turn, and designing what goes in it is an ongoing discipline. Hence the newer, more accurate term: context engineering . What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop Part 4: The Tool Layer Context Engineering ← You are here Part 6: The Filesystem & Environment Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what the Context actually is, why every turn forces you to answer "what should the model know right now?" from scratch, and the three moving pieces (system prompt, history, retrieval) that make up a well-designed context. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, a

Building FinSaathi: A Voice-First AI Financial Assistant Financial information can be difficult to understand. Banking terms, loans, credit scores, payments, and other financial decisions can quickly become overwhelming when users have to navigate everything through forms and complicated interfaces. So I wanted to explore a simpler interaction: What if financial guidance could start with a conversation? That idea became FinSaathi , a voice-first AI financial assistant. What I Built The first goal was simple: get a real-time voice assistant working end-to-end and deploy it. The current architecture is: Next.js Frontend → LiveKit → Python AI Agent → Voice/AI Services The frontend is deployed on Vercel, while the LiveKit agent is deployed on Railway. Users can open the application, start a conversation, and interact with the FinSaathi agent through voice. The Tech Stack Frontend Next.js React TypeScript LiveKit Components Tailwind CSS Vercel Backend Python LiveKit Agents UV Docker Railway Voice / AI LiveKit Murf AI/LLM services Data SQLite for application memory and call-related data The Part That Took More Time Than Expected Getting the agent to work locally was relatively straightforward. Getting the same system to actually run in production was a different problem. The Railway deployment initially failed with: python: can't open file '//src/agent.py': [Errno 2] No such file or directory The problem turned out to be related to how the application path and startup command were being handled inside the Docker deployment. After fixing the container and Railway startup configuration, the deployment moved further — and exposed another issue. Because the container runs the application as a non-root user, UV initially could not create its cache directory: Permission denied: '/app/.cache/uv' Fixing the permissions allowed the actual LiveKit AgentServer to start successfully. The production logs then showed the agent listening for connections and registering its worker with L

Welcome back to the Harness Engineering series — a 10-part journey from raw language model to production-ready agentic system. Made by builders. For builders. In Part 3, we looked at the Loop — the outermost machinery of a harness, the piece that drives everything else. But a Loop on its own is a hollow shell. It calls the model. The model responds. And then, if the model wants to affect anything outside the text it just produced, it needs to reach for a tool. That's what this article is about: the Tool Layer. The set of functions the harness makes available to the model, and the design decisions that separate a tool surface a model can actually use from one that constantly frustrates it. What's ahead: Part 1: The Raw Model Problem Part 2: Defining the Harness — The Six Components Part 3: The Control Loop The Tool Layer ← You are here Part 5: Context Engineering Part 6: The Filesystem & Environment Part 7: The Memory Layer Part 8: Observability Part 9: The Harness Architecture Part 10: Decomposing Claude Code By the end of this article, you'll know what tools actually are, why they exist, and — more usefully — how to tell a well-designed tool surface from a badly-designed one the moment you look at one. Let's get started. 📚 Want to go deeper than the articles? While you follow along with this series, I've put together two hands-on resources that go further than any single article can: Build a Harness from Scratch — Udemy Course — A self-paced course where I walk you through building a production-grade agentic harness from the ground up, in code. Harness Engineering for AI Agents — Live Maven Workshop — A live, cohort-based workshop for builders who want direct feedback, Q&A, and to work through the material with peers. Both are optional — the series stands on its own. But if you want the full studio-quality version, that's where it lives. What The Tools Are The Tools are the set of functions the harness exposes to the model. Concretely: the harness tells the model "

Quieres mandar la misma notificación a varios sitios: Slack, Discord, un webhook, un email. La primera versión es un for de tres líneas: for canal in canales : canal ( mensaje ) Y funciona en las demos. Hasta que un día Discord devuelve un 500, canal(mensaje) lanza, y el email y el Slack que iban detrás nunca salen . Peor: te enteras por el usuario que no recibió la alerta, no por un log. Dos cosas fallan en ese for : No aísla. La primera excepción corta el reparto entero. No reporta. O cada canal se traga su error en un try/except disperso, o el fallo se pierde. La forma correcta Aísla cada canal y recoge el resultado. Lo empaqueté como fanout-broadcast —Python puro, sin dependencias— porque lo reescribía en cada proyecto: from fanout_broadcast import Broadcaster bc = Broadcaster () bc . add ( " discord " , a_discord ) bc . add ( " telegram " , a_telegram ) bc . add ( " email " , a_email , enabled = False ) # apagado por ahora report = bc . broadcast ( " ¡Nueva versión publicada! " ) if not report . ok : for o in report . failed : log . error ( " %s falló: %s " , o . name , o . error ) broadcast llama a todos los canales habilitados, captura la excepción de cada uno por separado , y sigue con el siguiente. Un Discord caído ya no impide que salga el email. Al final tienes un reporte: report . ok # ¿ningún canal falló? report . delivered # los que entregaron report . failed # los que lanzaron (cada uno con su .error) report . skipped # los que estaban deshabilitados Encender y apagar sin ramificar el código Cada canal tiene un interruptor, en runtime o por variable de entorno: from fanout_broadcast import env_enabled bc . add ( " discord " , a_discord , enabled = env_enabled ( " discord " )) # mira DISCORD_ENABLED Esto importa más de lo que parece: separa qué canales existen de cuáles están activos hoy , sin comentar código ni meter if por todos lados. Apagas un canal problemático con una variable de entorno, no con un despliegue. Escalar, pero después de intentarlo

Seed three events into an audit database, then reach past the application and change one row by hand: $ sqlite3 audit.db "UPDATE audit_log SET principal='attacker' WHERE id=2" $ trelix audit verify --db audit.db Audit chain TAMPERED — first divergent entry id: 2 $ echo $? 1 Delete the newest row instead and it still catches it, naming id 3, even though the surviving rows form a perfectly valid chain. Point it at something SQLite cannot open and it exits 2 rather than 0, because "I could not check" and "I checked and it is clean" must never collapse into the same green build. None of that existed six releases ago. trelix audit verify is one command out of six feature areas that landed in trelix v3.0.0, and it is the one that most changes what the project is for. What the major bump actually is The span from v2.11.0 to v3.1.1 is six releases — v2.11.1, v2.12.0, v3.0.0, v3.0.1, v3.1.0 and v3.1.1, the last of them dated 2026-08-15 — 68 commits, 137 files changed, +19,829/-1,211 lines. v2.11.0 closed out the Jira and Linear connector work, which has its own story. Everything after it is a different kind of release. v3.0.0 carries six new feature areas: Anthropic extended thinking, a model-aware context budget, a VS Code extension that acts instead of merely displaying, a hash-chained append-only audit trail, OIDC SSO, and query-conditioned context compression. Alongside them, an opt-in FTS5 declaration boost for keyword ranking. It is a major bump because of scope, not breakage. Every one of those six is additive and off by default: TRELIX_AUDIT_ENABLED=false , TRELIX_OIDC_ENABLED=false , TRELIX_LLM_THINKING_ENABLED=false , TRELIX_RETRIEVAL_COMPRESSION=false , declaration_boost_enabled False, and context_token_budget still the exact 12_000 integer it was in v2.12.0. A default v3.0.0 install assembles context byte-identically to a default v2.12.0 install, and there is a test that proves it rather than a release note that asserts it. An audit trail you can hand to somebody

GitHub热门项目 | SGLang-Omni empowers high-performance serving for TTS, ASR, speech and omni models. | Stars: 816 | 11 stars today | 语言: Python

If you work with external APIs, you know the problem. There is no dev.github.com , no staging.api.companieshouse.gov.uk , no test endpoint for the thing you actually depend on. Production is the only source. So how do you get a development environment without re-fetching everything you already have? The usual answer is to copy: duplicate the warehouse, or keep a separate dev database and sync it periodically. Both are slow, both drift, and both cost storage in proportion to the number of people on the team. Interlace does something else. An environment is not a copy of your data, it is a set of views over it. Fingerprints first Every model gets a fingerprint: a hash of its canonical SQL — or its Python source — together with its strategy configuration and its upstream fingerprints. A build writes an immutable physical table named after that fingerprint. interlace__main.orders__a1b2c3 That table never changes. If the model's definition changes, the new version gets a new fingerprint and a new table, and the old one stays exactly where it is. An environment is then just a set of views pointing at fingerprinted tables. Production is the unprefixed namespace; every other environment prefixes its schema. Environment View for main.orders prod main.orders dev dev__main.orders pr-142 pr-142__main.orders Consumers and BI tools connect to main.orders and never learn that a fingerprint exists. There is no environment list to configure, either — an environment exists once something has been promoted to it. Why the sandbox is free Here is where the re-fetching problem disappears. Applying to a sandbox does not rebuild models whose fingerprint already exists. It points the sandbox's views at the tables production already built. interlace apply --env dev Change one model out of forty and the sandbox builds one model. The other thirty-nine are reused — not copied, reused, the same physical tables production is reading. The expensive source extract that ran this morning is the table

In 2009, Craig Gentry proved that it is possible to compute on encrypted data without ever decrypting it, and the result was widely treated as a theoretical curiosity. Sixteen years later, homomorphic encryption has crossed from conference papers into production pipelines: banks screen transactions against encrypted watchlists, hospitals run diagnostic models on data that never leaves their custody, and in August 2026 Google announced private AI features built on the same primitives. The gap between "possible in theory" and "usable in practice" is still wide, but it is no longer an argument against trying. This guide walks through what homomorphic encryption actually computes, how the CKKS scheme turns encrypted vectors into a workable substrate for machine learning, and the cost model that decides whether a private inference pipeline is worth building at all. The Promise: Compute Without Reading Ordinary encryption has a hard property: a ciphertext reveals nothing about the plaintext. AES-CTR, ChaCha20, RSA — all of them scramble data so thoroughly that an attacker holding the ciphertext and a supercomputer cannot recover the message without the key. That property is also the problem. If a server stores customer data encrypted at rest, every query requires shipping the data (or the key) somewhere a human or a process can read it. The moment the data is decrypted for computation, the confidentiality boundary moves from the storage layer to the memory of whatever process is doing the work. Homomorphic encryption changes the terms. A homomorphic scheme is one where operations on ciphertexts correspond to operations on plaintexts: Enc(a) ⊕ Enc(b) = Enc(a + b) . A server can add, multiply, and combine encrypted values and return the encrypted result, and the client — the only party holding the key — decrypts the final answer. The server learns nothing about the inputs, the intermediate values, or the output. For inference, this is the entire ballgame: the model owner ne

It was during the peak monsoon season when I read a distress report from a family stranded on their rooftop. Power was flickering, rain was hammering against the walls, and cellular data was down to a crawling 2G edge. They had a phone with 14% battery, but opening an emergency app or downloading heavy government disaster PDFs was impossible. All they could do was place a direct phone call. That moment stayed with me. When panic sets in and water is rising inside your living room, you don't navigate drop-down menus or type search queries into a browser. You need to speak, and you need a voice that answers immediately with verified life-saving relief info. That became the driving mission behind Sentinel — an autonomous, real-time Voice AI emergency dispatcher that I built over 10 days during the #VoiceForBharat challenge. The Problem I Wanted to Solve In emergency response across India, victims and disaster managers face three immediate hurdles: Information Fragmentation: Emergency guidelines, live rainfall alerts, and shelter capacities exist across different departments. A caller in panic needs instant answers (e.g., "Is there a shelter in Guwahati with medical support and space for pets?" ). The Friction of Touch UIs: Wet screens, low digital literacy, and high adrenaline make text interfaces fail. Voice is the most natural, accessible lifeline. Context Collapse: When standard chatbots escalate a user to another team or system, they drop the context and force the distressed victim to repeat their story from scratch. How Sentinel Works Under the Hood To make Sentinel feel like a natural human dispatcher, every millisecond of latency had to be eliminated. The system streams voice bidirectionally through a unified WebRTC pipeline: Speech-to-Text (STT): Deepgram Nova-3 transcribes incoming audio streams in real time with multilingual code-mixing support (English & Hindi). Brain & Reasoning (LLM): Google Gemini handles real-time disaster triage, safety guardrails, and

Over the last 10 days, I built Anisha, a voice agent for Learning & Literacy that can talk with users, remember them, provide learning exercises, make outbound calls, escalate to humans, track outcomes, and hand conversations to specialist agents. 👋 Meet Anisha Anisha is built using: Python LiveKit for real-time voice Murf Falcon for text-to-speech LLM for reasoning Custom tools and memory Human escalation Call analytics Specialist handoff The core flow is: User → STT → LLM → Tools / Memory / Specialist → Murf Falcon → User She can also handle Hindi and natural Hinglish, making the experience more suitable for Indian learners. 🧠 What Did I Build? Instead of trying to build everything at once, I added capabilities step by step. Memory — Anisha can remember relevant information about returning users. Learning Tools — She can provide exercises and track successful completion. Outbound Calls — I connected the agent to an outbound calling workflow. Human Escalation — Conversations that need human help can be escalated and tracked. Call Analytics — I added outcome tracking to understand whether conversations led to successful learning interactions. Math Specialist — Anisha can hand mathematics-related conversations to a dedicated specialist agent. This turned a basic voice assistant into a small multi-capability voice AI system. 😅 The Bug That Taught Me the Most The specialist handoff looked simple: Anisha → Math Specialist But there was a problem. The Math Specialist was being triggered correctly, yet its introduction was being spoken using Anisha's voice. The issue wasn't the text. It was the interaction between the active agent, session, and TTS configuration. I changed the handoff flow so Anisha doesn't speak the specialist's introduction. The specialist takes over and uses its own configured Murf voice. That taught me: In real-time voice AI, changing the agent also means managing the audio pipeline and agent state correctly. 🔧 What I Learned The biggest lesson from t

图表不会画？跟AI说句话就行 写代码画图这件事，劝退过不少人。编辑器打开了，文件是空的，脑子里想的是"画个折线图"，手却不知道往哪放。查文档、调参数、处理日期格式、挪图例……折腾半小时，数据还没理清楚。我太懂了，因为我自己就是这么过来的。 现在情况不一样了。ChatGPT、Claude、Copilot，随便挑一个，你跟它说"我想看什么样的图表"，它就把代码给你写好了，而且一次跑通的概率不低。这不是什么科幻设定，我天天这么干活。 AI到底在干嘛？ 说白了，AI不负责画图，它负责把你想画的东西翻译成代码。你说人话，它出Python、R或者JavaScript，然后你的数据就变成图了。常用的搭配大概是这些： Python配Matplotlib或Seaborn，做静态图、论文插图，稳 Python配Plotly，要交互、能缩放能悬停的那种 R配ggplot2，学术界和统计人的心头好 JavaScript配ECharts或D3，网页上动的图 老板只要Excel图？AI也能写VBA宏 API不用背，你直接说："我有个CSV，两列，一列日期一列销售额，帮我画折线图加趋势线，中文标题，X轴标签转45度，存成PNG。"代码马上给你。 关键是说人话 AI给不给力，很大程度看你问得清不清楚。我总结了一个公式，特别好用： 要干什么 + 数据啥样 + 用啥工具 + 图长啥样 + 存成啥格式 举个例子。你手上有个sales.csv，里面是月份和金额，想做柱状图，红色边框，高清图。 你要是说"帮我画个图"，谁也帮不了你。 但你要是说："用Python读sales.csv，第一列是月份，第二列是销售额。用matplotlib画柱状图，柱子天蓝色，边框红色，柱子上方标数值，标题写'月度销售额'，保存成300dpi的png。"AI给的代码基本就是能直接跑的。 一个真实的操作过程 拿Python举例，整个过程就三步。 第一步，让AI先读数据。"我有个data.csv，三列：date、product、revenue，格式是2024-01-01这种，写段Python代码读进来并打印前五行。" import pandas as pd df = pd . read_csv ( ' data.csv ' , parse_dates = [ ' date ' ]) print ( df . head ()) 跑一下，确认数据没错。 第二步，画图。"用Seaborn画每个月的总收入折线图，x轴月份，y轴收入，带数据点标记，标题'月度收入趋势'，图例去掉。"AI会一次性给你把分组聚合和绘图代码都写好。 第三步，跑，报错就贴给AI，改完再跑。五分钟搞定。 别把脑子扔了 AI写代码，你得把关。至少得看得懂它在干嘛：数据读得对不对，列名有没有搞错；按月求和还是逐条画，逻辑对不对；坐标轴排序有没有问题，标签重没重复；输出路径能不能找到。 AI有时候会一本正经地胡说八道——编个不存在的参数，或者用了个过时的库版本。这时候你得会看报错，会去查文档。说到底，AI是加速器，不是方向盘。 还能让AI干点别的 有时候图难看，真不怪画图代码，是数据太脏。你可以直接让AI洗数据："revenue列空值填0，删掉product列里带'测试'的行，日期列转成标准格式。"一行提示词，pandas代码给你安排好。 你也可以把一部分数据贴给AI，问它："这是我用户的年龄分布，你觉得用啥图展示比较合适？"它会跟你推荐直方图、箱线图或者小提琴图，还会解释为什么——等于白嫖一个懂行的顾问。 各家AI怎么选 ChatGPT（GPT-4系列），综合能力强，中文对话舒服，解释得很细，适合从零开始 Claude（Opus或者Sonnet），写代码比较稳，长代码上下文不容易丢，调试的时候给力 GitHub Copilot，装在编辑器里，你写它补，适合本来就在写项目的人 通义灵码、文心快码，国产的，中文响应快，跟国内开发环境更搭 哪个最强不好说，顺手最重要。我自己习惯先用ChatGPT把框架搭出来，再用Copilot改细节。 几个常见的坑 Matplotlib默认不认识中文，画出来全是方块，得加 plt.rcParams['font.sans-serif'] = ['SimHei'] 和 axes.unicode_minus = False 。 Windows路径里反斜杠容易转义出错，让AI用正斜杠，或者加个 r 前缀，再不行就上 pathlib 。 列名里带空格或特殊字符的话，AI可能写成 df.Revenue ，其实得 df['Revenue (M)'] 。把列名原样粘给AI，别让它猜。 Plotly在Jupyter里死活不显示？那是renderer没设置。 批量出图，才是真省事 文件多的时候，让AI写个循环。比如"文件夹里一

Building voice AI sounds deceptively clean on paper: capture speech, stream it to an STT engine, prompt an LLM, and synthesize audio back in real time. In reality, building a real-time, multilingual voice assistant that handles high-stress banking fraud while running on desktop hardware in 30°C heat with unstable power is a completely different story. As a Class 12 student diving into my first-ever hackathon, I spent the last 10 days of the #VoiceForBharat Challenge building Raksha —an empathetic, multi-agent voice assistant designed to protect Indian citizens from cyber scams, verify official government schemes, and escalate active financial fraud to human coordinators. Here is the honest breakdown of how Raksha evolved from Day 1 to Day 10, the absurd hurdles along the way, and what it actually takes to build reliable voice systems. 1. The Core Problem: Panic & Digital Banking Scams India's digital payments ecosystem is scaling at lightspeed, but so is financial fraud. Every day, people receive panic-inducing SMS messages claiming: "Your bank account is blocked. Update KYC immediately or share OTP." When someone is panicked, reading a 5-page PDF advisory is the last thing they will do. They need immediate, reassuring spoken advice in accessible Hinglish: "Ghabraiye mat. Bank kabhi phone ya message par OTP nahi mangta. Yeh poori tarah fraud hai." Voice is the most natural medium for this. If an AI agent can step in during those critical first 60 seconds, it can prevent immediate financial loss. 2. The 10-Day Journey: Power Cuts, Audio Hacks & Architecture Days 1–3: The Rocky Start & The Audio Hack Day 1 was pure chaos. I was battling 404s and gRPC hanging issues while connecting Gemini and LiveKit. Exactly 16 minutes before the midnight deadline, the power cut out completely. When it returned a minute past midnight, my desktop greeted me with a blue SrtTrail.txt Windows repair screen—and then another storm knocked the grid out again. I thought I was out on Day 1, b

The fastest way to trust a generated API is not to read the code and not even to run its tests locally; it is to make the code stand up as an actual HTTP server and answer real requests before you let it anywhere near a merge request. Most failures in LLM-generated backend code hide between static correctness and runtime truth: a missing dependency that only matters when the process starts, an assumption about a default host, a path parameter that works in pseudocode but not in the framework's route parser, or a response shape that drifts from what the client expects. A local unit test can pass while every one of those problems remains invisible, because the test never starts the process, binds a port, or sends a request over a socket. The loop worth describing is deliberately narrow. Use a free model to draft a small HTTP endpoint from a short specification, then deploy that draft to a disposable server where you can send it real requests, observe the response, and decide whether the generated code deserves to become part of your project. MonkeyCode's free model access and free server option make that loop easy to try without paying for a host or hand-rolling a local container, but the workflow is useful with any model and any temporary runtime you already have. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Start by asking the model for something tiny but externally observable. A health route plus an echo route is enough, because the point is not to demonstrate cleverness but to prove that the generated service can bind, route, validate query parameters, and return JSON under real HTTP conditions. Have it generate a FastAPI application, for example: from fastapi import FastAPI from pydantic import BaseModel app = FastAPI () class Echo ( BaseModel ): message : str @app.get ( ' /health ' ) def health (): return { ' status ' : ' ok ' } @app.post ( ' /echo ' ) def echo ( body : Echo ): return { ' received ' : body . message } That code

A small team shipped a CSV validation service. It passed on a workstation. It died three seconds after starting on a free server. This article reconstructs that failure as a reproducible case. It is not a benchmark and not a product review. The point is to show a workflow for finding display dependencies before they reach production. Two availability points made the loop cheap: free model access to draft a fix and a free server option to run headless checks. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The article does not assert model names, quotas, hardware, or uptime guarantees beyond those availability points. The case began with a small request. The service needed to read a CSV file, reject rows with missing columns, and write a short JSON report. The requirement said nothing about a desktop interface. The generated entry point looked ordinary. def main ( argv = None ): args = parse_args ( argv ) if not args . input : from tkinter import Tk from tkinter.filedialog import askopenfilename root = Tk () root . withdraw () args . input = askopenfilename () validate_csv ( args . input ) The local smoke test passed because it always supplied a file. python csv_check.py --input sample.csv That path never touched the fallback. The application then moved to a free server where the default start command had no file argument. The server process reached the Tk() call and failed. _tkinter.TclError: no display name and no $DISPLAY environment variable The problem was not a hallucinated algorithm. The model added a graphical file picker as a hidden fallback. On the workstation that fallback was harmless. On a headless server it was a startup-time dependency. A code review might have missed it because tkinter is a standard-library module and the fallback looked like convenience logic. The environment mismatch only became visible when the no-argument path ran on a machine without a display. The team turned the failure into a deploy gate. The fi

Real transaction data is never clean — and the worst part is that it looks clean. This is a short story from a real dataset (UCI Online Retail: 541,909 e-commerce transactions) about the quietest way to destroy data: silent type coercion. All numbers below come verbatim from an executed notebook. The head looks perfect Peek at the first rows of the file and InvoiceNo parses as clean integers — 100% parse rate, full confidence. Any type-inference step, mine included, would call it int64 and move on. Measure the whole file instead of the head, and the number drops to ~98%. The other 2%: invoice numbers starting with "C" — which in this dataset marks a cancellation . Coerce the column to numeric and every one of them becomes NaN : Invoice numbers destroyed by numeric coercion: 9,291 DextraLoaderWarning: load: ambiguous decision(s): column 'InvoiceNo': ambiguous - float64 at parse_rate=0.98 An entire class of business events — silently gone. No exception, no crash. That's what makes coercion the quietest bug in data work: the pipeline succeeds . Why those 9,291 rows matter They are not noise. They are the returns side of the business : cancelled orders worth 8.4% of everything sold. Lose them and every revenue number downstream is quietly wrong. One example of what they catch: the dataset's apparent #1 bestseller, "PAPER CRAFT, LITTLE BIRDIE" (168,470 GBP), is a phantom — a single 80,995-unit order entered at 09:15 and fully cancelled at 09:27 the same morning. Only the preserved cancellation rows expose it. The genuine bestseller is a cake stand. The fix: identifiers are labels, not quantities No library can know that "InvoiceNo" is an ID — that's domain knowledge. What a tool can do is disclose its guess and hand you a replayable plan you can correct: naive , plan = dx . load ( CSV_PATH , return_params = True ) # warns: ambiguous at 0.98 plan [ " columns " ][ " InvoiceNo " ][ " dtype " ] = " object " # invoices are labels plan [ " columns " ][ " StockCode " ][ " dtype

Building Roshni: An Ultra-Low Latency, Multi-Agent Financial Voice Assistant for Bharat 🇮🇳 How I built an end-to-end, multilingual financial voice AI using Murf Falcon, LiveKit Agents, Deepgram Nova-3, Google Gemini, and Next.js during the 10 Days of AI Voice Agents Challenge. 🌟 1. The Problem & Why Voice Matters for Bharat In India, financial inclusion has accelerated rapidly with UPI, digital banking, and government-backed credit initiatives. However, navigating complex interest rates, eligibility criteria for government schemes (like PM Mudra or Sukanya Samriddhi Yojana), and understanding formal banking terms remains intimidating for millions of citizens—especially in regional and tier-2/3 heartlands where digital interfaces can be overwhelming. Text-first interfaces fail where voice thrives. When rural entrepreneurs or first-time bank customers have questions, they don't want to navigate complex web forms or read dense PDFs. They want to ask a direct question in their language and get an immediate, clear, spoken answer. To solve this, I built Roshni AI (and her specialist counterpart, Vikram ) — an ultra-low latency, conversational financial assistant engineered for natural voice interactions in English, Hindi (Devanagari script), and Hinglish. 🏗️ 2. High-Level Architecture & Tech Stack Building a real-time conversational agent requires synchronizing four core pipelines with sub-second latency: [ 👤 User Microphone ] │ (WebRTC Audio Stream) ▼ ┌─────────────────────────────┐ │ LiveKit Agents Worker │ └──────────────┬──────────────┘ │ ┌───────────────────────┼───────────────────────┐ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │ Deepgram │ ────► │Google Gemini│ ────► │ Murf Falcon │ │ Nova-3 │ │ (LLM) │ │ Fast TTS │ │ (Fast STT) │ │ │ │ (Anisha / Samar)│ └─────────────┘ └──────┬──────┘ └────────┬────────┘ │ (Tool / Handoff) │ ▼ ▼ ┌───────────────┐ [ 🔊 Audio Output ] │ SQLite Memory │ │ & Analytics │ └───────────────┘ The Stack: TTS (Text-to-Speech):